Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 4/1/2016 10:50 AM, Matt Riedemann wrote:



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 > wrote:



On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann

>> 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. 

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

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 > wrote:



On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann

>> 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 

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Sahid Orentino Ferdjaoui]

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  >> wrote:
> >
> >
> >
> >On 3/29/2016 4:44 PM, Armando M. wrote:
> >
> >
> >
> >On 29 March 2016 at 08:08, Matt Riedemann
> >
> > >>> 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 

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 3/30/2016 5:55 PM, Armando M. wrote:



On 29 March 2016 at 18:55, Matt Riedemann > wrote:



On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann

>> 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 

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 3/30/2016 5:50 PM, Armando M. wrote:



On 30 March 2016 at 13:40, Sean Dague > wrote:

On 03/29/2016 09:55 PM, Matt Riedemann wrote:

>
> 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.
>

Is there a sane resource on the neutron side we could link to? Today
security_groups are returned with a name from nova, which made sense
when it was an internal structure, but makes way less sense now.

"security_groups": [
{
 "href": "",
 }
]

Where the link is to a neutron resource (and we could do a local link
for the few nova net folks) might be more appropriate.


Not that I could think of, though the extra level of indirection to
solve this issue is kind of a neat idea.


 -Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Yeah, not really, see what we have to do to get the list of security 
groups for a given list of instances [1].


That builds a list of ports from the list of instances, then from the 
list of ports it builds a list of security groups mapped to each port, 
and then does some cleanup after that to make it look like nova-network 
security groups for the compute API response (as a side note, it seems 
like this is an area where we could do some performance optimizations by 
not pulling back all of the port / security group details, only get the 
fields we need).


Would we need to link to a neutron API? Could we just provide a link 
back to 'servers//os-security-groups'?


[1] 
https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/network/security_group/neutron_driver.py#L373


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Armando M.]

On 29 March 2016 at 18:55, Matt Riedemann 
wrote:

>
>
> On 3/29/2016 4:44 PM, Armando M. wrote:
>
>>
>>
>> On 29 March 2016 at 08:08, Matt Riedemann > > 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-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Armando M.]

On 30 March 2016 at 13:40, Sean Dague  wrote:

> On 03/29/2016 09:55 PM, Matt Riedemann wrote:
> 
> >
> > 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.
> >
>
> Is there a sane resource on the neutron side we could link to? Today
> security_groups are returned with a name from nova, which made sense
> when it was an internal structure, but makes way less sense now.
>
> "security_groups": [
>{
> "href": "",
> }
> ]
>
> Where the link is to a neutron resource (and we could do a local link
> for the few nova net folks) might be more appropriate.
>

Not that I could think of, though the extra level of indirection to solve
this issue is kind of a neat idea.


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Sean Dague]

On 03/29/2016 09:55 PM, Matt Riedemann wrote:

> 
> 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.
> 

Is there a sane resource on the neutron side we could link to? Today
security_groups are returned with a name from nova, which made sense
when it was an internal structure, but makes way less sense now.

"security_groups": [
   {
"href": "",
}
]

Where the link is to a neutron resource (and we could do a local link
for the few nova net folks) might be more appropriate.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann > 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-requ...@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-requ...@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 

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Armando M.]

On 29 March 2016 at 08:08, Matt Riedemann 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

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.


[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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev