Comment 1 for bug 1608601

I think the description is slightly wrong.

I took a look at neutron policy file and create_port can be created by any user by default.
https://github.com/openstack/neutron/blob/master/etc/policy.json#L72 and that must be the reason the code was written with a neutronclient without admin context. If the default policy.json is used (which allows all users to create port), everything is good . However, if we customize the policy.json to something like below:

"create_port": "role:member or role:im-custom-role"

For creating port in the deploy flow (which is the flow referred to here), the get_client() does not pass admin as true meaning it uses the token of the logged in user
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L749

In the same flow the client context is updated to admin to enable a neutron flow that needs admin (here admin is set to true because the default policy.json doesn't allow all roles to update ports and thus without admin context the below call fails)
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L789

        # We always need admin_client to build nw_info,
        # we sometimes need it when updating ports
        admin_client = get_client(context, admin=True)

        ordered_nets, ordered_ports, preexisting_port_ids, \
            created_port_ids = self._update_ports_for_instance(
                context, instance,
                neutron, admin_client, requests_and_created_ports, nets,
                bind_host_id, dhcp_opts, available_macs)

It doesn't make sense for nova to use neutronclient with admin in some cases and without admin in others. It might work with the default neutron policy.json but not with a custom one. The code is not written consistently.

The nova-neutronclient code must either use admin context consistently , in which case it will always use the neutron service user credentials from the nova.conf file from the [neutron] section to make calls to neutron. Or, it must always use the token of the logged-in user. The problem with using the credentials of the logged-in user is that there would be cases where the logged in user's token gets expired mid-way and the nova-neutronclient logic would a fresh authentication with keystone and the credentials used at that time would be service user credentials (as the logged in user's credentials are not available to generate a fresh token) and that would again lead to inconsistencies.

This defect must be used to decide the course of action either way and not leave things inconsistently.