network:attach_external_network policy check outside nova-api

Fix proposed to branch: master
Review: https://review.openstack.org/449598

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/449598
Reason: This review is > 4 weeks without comment, and is not mergable in it's current state. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

One idea for addressing this is to remove the 'network:attach_external_network' policy check entirely and let neutron reject the request to create the port. This way, if an operator enables a tenant to attach to an external network, it will Just Work without the operator needing to push a policy config update to all nova-compute services.

******************

I have tested the behavior in a devstack environment and can confirm that server create will indeed fail on the neutron side if a tenant isn't permitted to attach to an external network. This gives some support to the idea of removing the policy check altogether and letting things fail on the neutron side if a tenant is not permitted to attach to an external network.

Note that the error message in the latter case is more vague and doesn't indicate that the network allocation step failed -- so a bit more work would be needed to ensure that we don't reschedule in the case where we receive the Forbidden error from neutron.

Default behavior (with 'network:attach_external_network' policy check):

$ openstack network list
+--------------------------------------+---------+----------------------------------------------------------------------------+
| ID | Name | Subnets |
+--------------------------------------+---------+----------------------------------------------------------------------------+
| 69c9167d-5fb3-458e-bce0-5934dbb2469c | public | ec1d2d9a-51f3-44ba-ac01-5723eed5e81e, fe29bcbe-3a48-4db3-bb7b-48c2ac8b55a1 |
| 9b0c58a4-e843-4fd8-8256-db94893e7047 | private | a2d7ec6f-d10f-4e1a-8278-d3e6f4d5a7cf, a9ec851a-d0fe-4755-8024-d0c65619cdd1 |
| 9e9ceb79-8a78-41f7-b36f-ca89b57e90fb | shared | ae67aa07-b887-452f-9574-ffb307880566 |
+--------------------------------------+---------+----------------------------------------------------------------------------+

$ openstack network show 69c9167d-5fb3-458e-bce0-5934dbb2469c
+---------------------------+----------------------------------------------------------------------------+
| Field | Value |
+---------------------------+----------------------------------------------------------------------------+
[...]
| router:external | External |
[...]

$ openstack server create --flavor 42 --image cirros-0.5.1-x86_64-disk --network 69c9167d-5fb3-458e-bce0-5934dbb2469c --wait pizza
Error creating server: pizza
Error creating server

$ openstack server list
+--------------------------------------+-------+--------+----------+--------------------------+---------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------+--------+----------+--------------------------+---------+
| e60954fd-9e03-4a48-8650-606d1d4ffba8 | pizza | ERROR | | cirros-0.5.1-x86_64-disk | m1.nano |
+--------------------------------------+-------+--------+----------+---------...

Here's what neutron returns when it rejects a request to create a port on an external network:

INFO neutron.pecan_wsgi.hooks.translation [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] POST failed (client error): Tenant 7c60976c662a414cb2661831ff41ee30 not allowed to create port on this network
[...]
INFO neutron.wsgi [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] 127.0.0.1 "POST /v2.0/ports HTTP/1.1" status: 403 len: 360 time: 0.1582518

I've started a thread on the ML about the possibility of removing the nova-compute 'network:attach_external_network' policy check here:

http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020876.html

Reviewed: https://review.opendev.org/c/openstack/nova/+/729918
Committed: https://opendev.org/openstack/nova/commit/b5edc294a112a4ed806ba8025d24d821121c1a53
Submitter: "Zuul (22348)"
Branch: master

commit b5edc294a112a4ed806ba8025d24d821121c1a53
Author: Stephen Finucane <email address hidden>
Date: Thu May 21 12:08:59 2020 +0100

    docs: Add man pages for 'nova-policy'

    I don't actually grok what this does that 'oslopolicy-checker' couldn't
    do, so perhaps we can deprecate this in the future. For now though,
    simply document the thing. While we're here, we make some additional
    related changes:

    - Remove references to the 'policy.yaml' file for services that don't
      use policy (i.e. everything except the API services and, due to a bug,
      the nova-compute service).
    - Update remaining references to the 'policy.yaml' file to include the
      'policy.d/' directory
    - Update the help text for the '--api-name' and '--target' options of
      the 'nova-policy policy check' command to correct tense and better
      explain their purpose.

    Also, yes, 'nova-policy policy check' is dumb. Don't blame me :)

    Change-Id: I913b0de9ec40a615da7bf9981852edef4a88fecb
    Signed-off-by: Stephen Finucane <email address hidden>
    Related-bug: #1675486