Open Stack

On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote:
> On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote:
>>
>>
>> On 3/30/2016 5:55 PM, Armando M. wrote:
>>>
>>>
>>> On 29 March 2016 at 18:55, Matt Riedemann <mriedem at linux.vnet.ibm.com
>>> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>>>
>>>
>>>
>>>     On 3/29/2016 4:44 PM, Armando M. wrote:
>>>
>>>
>>>
>>>         On 29 March 2016 at 08:08, Matt Riedemann
>>>         <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>
>>>         <mailto:mriedem at linux.vnet.ibm.com
>>>         <mailto:mriedem at linux.vnet.ibm.com>>> wrote:
>>>
>>>              Nova has had some long-standing bugs that Sahid is trying
>>>         to fix
>>>              here [1].
>>>
>>>              You can create a network in neutron with
>>>              port_security_enabled=False. However, the bug is that since
>>>         Nova
>>>              adds the 'default' security group to the request (if none are
>>>              specified) when allocating networks, neutron raises an
>>>         error when
>>>              you try to create a port on that network with a 'default'
>>>         security
>>>              group.
>>>
>>>              Sahid's patch simply checks if the network that we're going
>>>         to use
>>>              has port_security_enabled and if it does not, no security
>>>         groups are
>>>              applied when creating the port (regardless of what's
>>>         requested for
>>>              security groups, which in nova is always at least 'default').
>>>
>>>              There has been a similar attempt at fixing this [2]. That
>>>         change
>>>              simply only added the 'default' security group when allocating
>>>              networks with nova-network. It omitted the default security
>>>         group if
>>>              using neutron since:
>>>
>>>              a) If the network does not have port security enabled,
>>>         we'll blow up
>>>              trying to add a port on it with the default security group.
>>>
>>>              b) If the network does have port security enabled, neutron will
>>>              automatically apply a 'default' security group to the port,
>>>         nova
>>>              doesn't need to specify one.
>>>
>>>              The problem both Feodor's and Sahid's patches ran into was
>>>         that the
>>>              nova REST API adds a 'default' security group to the server
>>>         create
>>>              response when using neutron if specific security groups
>>>         weren't on
>>>              the server create request [3].
>>>
>>>              This is clearly wrong in the case of
>>>              network.port_security_enabled=False. When listing security
>>>         groups
>>>              for an instance, they are correctly not listed, but the server
>>>              create response is still wrong.
>>>
>>>              So the question is, how to resolve this?  A few options
>>>         come to mind:
>>>
>>>              a) Don't return any security groups in the server create
>>>         response
>>>              when using neutron as the backend. Given by this point
>>>         we've cast
>>>              off to the compute which actually does the work of network
>>>              allocation, we can't call back into the network API to see what
>>>              security groups are being used. Since we can't be sure, don't
>>>              provide what could be false info.
>>>
>>>              b) Add a new method to the network API which takes the
>>>         requested
>>>              networks from the server create request and returns a best
>>>         guess if
>>>              security groups are going to be applied or not. In the case of
>>>              network.port_security_enabled=False, we know a security
>>>         group won't
>>>              be applied so the method returns False. If there is
>>>              port_security_enabled, we return whatever security group was
>>>              requested (or 'default'). If there are multiple networks on the
>>>              request, we return the security groups that will be applied
>>>         to any
>>>              networks that have port security enabled.
>>>
>>>              Option (b) is obviously more intensive and requires hitting the
>>>              neutron API from nova API before we respond, which we'd like to
>>>              avoid if possible. I'm also not sure what it means for the
>>>              auto-allocated-topology (get-me-a-network) case. With a
>>>         standard
>>>              devstack setup, a network created via the
>>>         auto-allocated-topology
>>>              API has port_security_enabled=True, but I also have the 'Port
>>>              Security' extension enabled and the default public external
>>>         network
>>>              has port_security_enabled=True. What if either of those are
>>>         False
>>>              (or the port security extension is disabled)? Does the
>>>              auto-allocated network inherit port_security_enabled=False?
>>>         We could
>>>              duplicate that logic in Nova, but it's more proxy work that
>>>         we would
>>>              like to avoid.
>>>
>>>
>>>         Port security on the external network has no role in this
>>>         because this
>>>         is not the network you'd be creating ports on. Even if it had
>>>         port-security=False, an auto-allocated network will still be created
>>>         with port security enabled (i.e. =True).
>>>
>>>         A user can obviously change that later on.
>>>
>>>
>>>              [1] https://review.openstack.org/#/c/284095/
>>>              [2] https://review.openstack.org/#/c/173204/
>>>              [3]
>>>         https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/api/openstack/compute/security_groups.py#L472-L475
>>>
>>>              --
>>>
>>>              Thanks,
>>>
>>>              Matt Riedemann
>>>
>>>
>>>
>>>         __________________________________________________________________________
>>>              OpenStack Development Mailing List (not for usage questions)
>>>              Unsubscribe:
>>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>
>>>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>         __________________________________________________________________________
>>>         OpenStack Development Mailing List (not for usage questions)
>>>         Unsubscribe:
>>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>     Yup, HenryG walked me through the cases on IRC today.
>>>
>>>     The more I think about option (b) above, the less I like that idea
>>>     given how much work goes into the allocate_for_instance code in nova
>>>     where it's already building the list of possible networks that will
>>>     be used for creating/updating ports, we'd essentially have to
>>>     duplicate that logic in a separate method to get an idea of what
>>>     security groups would be applied.
>>>
>>>     I'd prefer to be lazy and go with option (a) and just say nova
>>>     doesn't return security-groups in the REST API when creating a
>>>     server and neutron is the network API. That would require a
>>>     microversion probably, but it would still be easy to do. I'm not
>>>     sure if that's the best user experience though.
>>>
>>>
>>> At the very least nova-api checks that the network exists before
>>> proceeding; is it crazy or doable checking for the port security
>>> attribute on the network and set a sentinel value for security groups
>>> before moving on?
>>>
>>>
>>>     --
>>>
>>>     Thanks,
>>>
>>>     Matt Riedemann
>>>
>>>
>>>     __________________________________________________________________________
>>>     OpenStack Development Mailing List (not for usage questions)
>>>     Unsubscribe:
>>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Today the network_api.validate_networks method called from the compute API
>> will check to see if the requested network exists (if one is requested), so
>> we could check the port_security_enabled value on that network then. If no
>> network is requested, we see if one is available to the project. If not, we
>> don't allocate networks on the initial server create. But if that's the
>> case, we'd just not return security groups I think since we don't know.
>>
>> In the case of get-me-a-network with the auto-allocated-topology, we could
>> determine if security groups will be used by checking if the port-security
>> extension is enabled.
>>
>> I'm not entirely sure how we'd get this information back from
>> network_api->compute_api->REST API though. We could set something in the
>> database for the instance and check that in the REST API, but that seems
>> hacky.
>
> I think we do not have a real good solution to fix that case instead
> of make the process "allocate networks for instance" synchrones so we
> can retrieve network_info at this stage without to make the process to
> heavy.
>
> I'd suggest to just remove that field when port security extension is
> enable and no security groups has been passed to the request.
>
> s.
>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

OK, so here is what we're going to do.

1. Add a release note to Sahid's change 
https://review.openstack.org/#/c/284095/ saying that you can now boot 
servers into networks that don't have port security enabled. However, 
the server create response will still say that at least the default 
security group is applied, which would be wrong in this case. We should 
be able to backport this fix to stable branches.

2. We'll write up a spec to change the API response for server-create to 
return a link for getting security groups rather than the list of 
security groups we think are going to be applied (which might not be in 
the case of neutron). Something like:

http://localhost:8774/v2.1/${project_id}/servers/{uuid}/os-security-groups

This is similar to how the server resource has links for the flavor it 
was created with.

That will go in a microversion (which we can't backport since it's an 
API change).

--

This is a bit of an odd case, but it's a trade-off to get the fix in 
since not being able to boot an instance into a network that doesn't 
have port security enabled is going to trump the UX in the server-create 
response. Also, listing the security groups after the server is created 
gives the correct results, so it's not like we're regressing that 
functionality.

-- 

Thanks,

Matt Riedemann