Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2015-02-11 Thread Feodor Tersin
You could rise an exception if ports are specified for all nics. [1]
I'm not sure that logging of this case is helpful, because only admins can
access to logs.
Probably the better way to warn a user is to do it at client side by nova
cli (i.e. no any modification of nova server is needed).

[1] It returns us back to the original Matt's question.
I suppose that most people, which tried to specify security groups with
ports, already found that it doesn't do work properly. And now they don't
use them together. Other part, which didn't found this, have the error in
their scripts (because they start instances with no expected groups). So
rising an error in this case could be useful.
In my turn, i used these parameters together (
https://github.com/stackforge/ec2-api/blob/master/ec2api/api/instance.py#L770)
to do a workaround of a strange bug (
https://bugs.launchpad.net/nova/+bug/1384347), which is not actual since
Juno. I believe OpenStack could not support compatibility for such
workarounds.

Finlally, the only my concern is the case with two nics, mentioned at the
beginning.


On Wed, Feb 11, 2015 at 10:39 AM, Oleg Bondarev obonda...@mirantis.com
wrote:



 On Tue, Feb 10, 2015 at 5:26 PM, Feodor Tersin fter...@cloudscaling.com
 wrote:

 I definitely don't expect any change of the existing port in the case
 with two nics. However in the case of single nic a question like 'what is
 impact of security-groups parameter' arises.
 Also a similar question arises out of '--nic port-id=xxx,v4-fixed-ip=yyy'
 combination.
 Moreover, if we assume that, for example, security-groups parameter
 affects the specified port, the next question is 'what is the result group
 set'. Does it replace groups of the port, or just update them?

 Thus i agree with you, that this part of nova API is not clear now. But
 the case with two nics make sense, works now, and can be used by someone.
 Do you really want to break it?


 I don't want to break anything :)
 I guess the only option then is to just log a warning that security groups
 are ignored in case port_id is provided on boot -
 but this still leaves a chance of broken user expectations.




 On Tue, Feb 10, 2015 at 10:29 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:



 On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
 wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is
 specified, but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second
 port (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


 The question here is what do you expect for the existing port - it's
 security groups updated or not?
 Will it be ok to silently (or with warning in logs) ignore security
 groups for it?
 If it's ok then is it ok to do the same for:
 nova boot ... --nic port-id=xxx --security-groups sg-1
 where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann 
 mrie...@linux.vnet.ibm.com wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com
 wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and
 security_groups
 is supplied.

 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Coming back to this, we now have a change from Oleg [1] after an
 initial attempt that was reverted because it would break server creates if
 you specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request
 so if you specify a security group and port on the request, you'll now get
 a 400 error response.

 Does this break API compatibility?  It seems this falls under the
 first bullet here [2], A change such that a request which was successful
 before now results in an error response (unless the success reported
 previously was hiding an existing error condition).  Does that caveat in
 parenthesis make this OK?

 It seems like we've had a lot 

Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2015-02-10 Thread Feodor Tersin
I definitely don't expect any change of the existing port in the case with
two nics. However in the case of single nic a question like 'what is impact
of security-groups parameter' arises.
Also a similar question arises out of '--nic port-id=xxx,v4-fixed-ip=yyy'
combination.
Moreover, if we assume that, for example, security-groups parameter affects
the specified port, the next question is 'what is the result group set'.
Does it replace groups of the port, or just update them?

Thus i agree with you, that this part of nova API is not clear now. But the
case with two nics make sense, works now, and can be used by someone. Do
you really want to break it?


On Tue, Feb 10, 2015 at 10:29 AM, Oleg Bondarev obonda...@mirantis.com
wrote:



 On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
 wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is specified,
 but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second
 port (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


 The question here is what do you expect for the existing port - it's
 security groups updated or not?
 Will it be ok to silently (or with warning in logs) ignore security groups
 for it?
 If it's ok then is it ok to do the same for:
 nova boot ... --nic port-id=xxx --security-groups sg-1
 where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann 
 mrie...@linux.vnet.ibm.com wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Coming back to this, we now have a change from Oleg [1] after an initial
 attempt that was reverted because it would break server creates if you
 specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request
 so if you specify a security group and port on the request, you'll now get
 a 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

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

Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2015-02-10 Thread Oleg Bondarev
On Tue, Feb 10, 2015 at 5:26 PM, Feodor Tersin fter...@cloudscaling.com
wrote:

 I definitely don't expect any change of the existing port in the case with
 two nics. However in the case of single nic a question like 'what is impact
 of security-groups parameter' arises.
 Also a similar question arises out of '--nic port-id=xxx,v4-fixed-ip=yyy'
 combination.
 Moreover, if we assume that, for example, security-groups parameter
 affects the specified port, the next question is 'what is the result group
 set'. Does it replace groups of the port, or just update them?

 Thus i agree with you, that this part of nova API is not clear now. But
 the case with two nics make sense, works now, and can be used by someone.
 Do you really want to break it?


I don't want to break anything :)
I guess the only option then is to just log a warning that security groups
are ignored in case port_id is provided on boot -
but this still leaves a chance of broken user expectations.




 On Tue, Feb 10, 2015 at 10:29 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:



 On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
 wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is
 specified, but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second
 port (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


 The question here is what do you expect for the existing port - it's
 security groups updated or not?
 Will it be ok to silently (or with warning in logs) ignore security
 groups for it?
 If it's ok then is it ok to do the same for:
 nova boot ... --nic port-id=xxx --security-groups sg-1
 where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann 
 mrie...@linux.vnet.ibm.com wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Coming back to this, we now have a change from Oleg [1] after an
 initial attempt that was reverted because it would break server creates if
 you specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request
 so if you specify a security group and port on the request, you'll now get
 a 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

 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



 

Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2015-02-09 Thread Matt Riedemann



On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

On Fri, 26 Sep 2014 11:25:49 +0400
Oleg Bondarev obonda...@mirantis.com wrote:


On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:


  I think the expectation is that if a user is already interaction
with Neutron to create ports then they should do the security group
assignment in Neutron as well.



Agree. However what do you think a user expects when he/she boots a
vm (no matter providing port_id or just net_id)
and specifies security_groups? I think the expectation should be that
instance will become a member of the specified groups.
Ignoring security_groups parameter in case port is provided (as it is
now) seems completely unfair to me.


One option would be to return a 400 if both port id and security_groups
is supplied.

Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Coming back to this, we now have a change from Oleg [1] after an initial 
attempt that was reverted because it would break server creates if you 
specified a port (because the original change would blow up when the 
compute API added the 'default' security group to the request').


The new change doesn't add the 'default' security group to the request 
so if you specify a security group and port on the request, you'll now 
get a 400 error response.


Does this break API compatibility?  It seems this falls under the first 
bullet here [2], A change such that a request which was successful 
before now results in an error response (unless the success reported 
previously was hiding an existing error condition).  Does that caveat 
in parenthesis make this OK?


It seems like we've had a lot of talk about warts in the compute v2 API 
for cases where an operation is successful but didn't yield the expected 
result, but we can't change them because of API backwards compatibility 
concerns so I'm hesitant on this.


We also definitely need a Tempest test here, which I'm looking into.  I 
think I can work this into the test_network_basic_ops scenario test.


[1] https://review.openstack.org/#/c/154068/
[2] 
https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Not_Acceptable


--

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] security group fails to attach to an instance if port-id is specified during boot.

2015-02-09 Thread Oleg Bondarev
On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is specified,
 but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second port
 (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


The question here is what do you expect for the existing port - it's
security groups updated or not?
Will it be ok to silently (or with warning in logs) ignore security groups
for it?
If it's ok then is it ok to do the same for:
nova boot ... --nic port-id=xxx --security-groups sg-1
where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
  wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Coming back to this, we now have a change from Oleg [1] after an initial
 attempt that was reverted because it would break server creates if you
 specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request so
 if you specify a security group and port on the request, you'll now get a
 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

 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 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] security group fails to attach to an instance if port-id is specified during boot.

2015-02-09 Thread Feodor Tersin
nova boot ... --nic port-id=xxx --nic net-id=yyy
this case is valid, right?
I.e. i want to boot instance with two ports. The first port is specified,
but the second one is created at network mapping stage.
If i specify a security group as well, it will be used for the second port
(if not - default group will):
nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
Thus a port and a security group can be specified together.


On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Coming back to this, we now have a change from Oleg [1] after an initial
 attempt that was reverted because it would break server creates if you
 specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request so
 if you specify a security group and port on the request, you'll now get a
 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

 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


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-26 Thread Oleg Bondarev
On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

  I think the expectation is that if a user is already interaction with
 Neutron to create ports then they should do the security group assignment
 in Neutron as well.


Agree. However what do you think a user expects when he/she boots a vm (no
matter providing port_id or just net_id)
and specifies security_groups? I think the expectation should be that
instance will become a member of the specified groups.
Ignoring security_groups parameter in case port is provided (as it is now)
seems completely unfair to me.



 The trouble I see with supporting this way of assigning security groups is
 what should the correct behavior be if the user passes more than one port
 into the Nova boot command ?   In the case where Nova is creating the ports
 it kind of feels (just)  Ok to assign the security groups to all the
 ports.  In the case where the ports have already been created then it
 doesn’t feel right to me that Nova modifies them.


An option may be to append existing ports' security groups with ones that a
user specifies during instance boot.
This way we will preserve both user expectations - first when the port is
created and second when the instance is spawned.
Thoughts?













 *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
 *Sent:* 25 September 2014 08:19
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [NOVA] security group fails to attach to
 an instance if port-id is specified during boot.



 Hi Parikshit,



 Looks like a bug. Currently if port is specified its security groups are
 not updated, it shpould be fixed.

 I've reported https://bugs.launchpad.net/nova/+bug/1373774 to track this.

 Thanks for reporting!



 Thanks,

 Oleg



 On Thu, Sep 25, 2014 at 10:15 AM, Parikshit Manur 
 parikshit.ma...@citrix.com wrote:

  Hi All,

 Creation of server with command  ‘nova boot  --image
 image --flavor m1.medium --nic port-id=port-id --security-groups
  sec_grp name’ fails to attach the security group to the
 port/instance. The response payload has the security group added but only
 default security group is attached to the instance.  Separate action has to
 be performed on the instance to add sec_grp, and it is successful.
 Supplying the same with ‘--nic net-id=net-id’ works as expected.



 Is this the expected behaviour / are there any other options which needs
 to be specified to add the security group when port-id needs to be attached
 during boot.



 Thanks,

 Parikshit Manur


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-26 Thread Christopher Yeoh
On Fri, 26 Sep 2014 11:25:49 +0400
Oleg Bondarev obonda...@mirantis.com wrote:

 On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:
 
   I think the expectation is that if a user is already interaction
  with Neutron to create ports then they should do the security group
  assignment in Neutron as well.
 
 
 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.

One option would be to return a 400 if both port id and security_groups
is supplied.

Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-26 Thread Simon Pasquier
On Fri, Sep 26, 2014 at 10:19 AM, Christopher Yeoh cbky...@gmail.com
wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:
 
I think the expectation is that if a user is already interaction
   with Neutron to create ports then they should do the security group
   assignment in Neutron as well.
  
 
  Agree. However what do you think a user expects when he/she boots a
  vm (no matter providing port_id or just net_id)
  and specifies security_groups? I think the expectation should be that
  instance will become a member of the specified groups.
  Ignoring security_groups parameter in case port is provided (as it is
  now) seems completely unfair to me.

 One option would be to return a 400 if both port id and security_groups
 is supplied.


FWIW this is what has been implemented in Heat when such request is made
(see discussion on the bug report and [1])

Simon

[1]
http://git.openstack.org/cgit/openstack/heat/commit/?id=5c5e36de3737a85bec5023c94265e6bbaf6ad78e



 Chris

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-26 Thread Matt Riedemann



On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

On Fri, 26 Sep 2014 11:25:49 +0400
Oleg Bondarev obonda...@mirantis.com wrote:


On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:


  I think the expectation is that if a user is already interaction
with Neutron to create ports then they should do the security group
assignment in Neutron as well.



Agree. However what do you think a user expects when he/she boots a
vm (no matter providing port_id or just net_id)
and specifies security_groups? I think the expectation should be that
instance will become a member of the specified groups.
Ignoring security_groups parameter in case port is provided (as it is
now) seems completely unfair to me.


One option would be to return a 400 if both port id and security_groups
is supplied.

Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I'd get behind this, it would keep the complexity in nova low if you're 
already using neutron.


We already have some validation like this today in the compute API 
depending on what you're providing on the request for networks, fixed 
IPs and ports.


--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-25 Thread Oleg Bondarev
Hi Parikshit,

Looks like a bug. Currently if port is specified its security groups are
not updated, it shpould be fixed.
I've reported https://bugs.launchpad.net/nova/+bug/1373774 to track this.
Thanks for reporting!

Thanks,
Oleg

On Thu, Sep 25, 2014 at 10:15 AM, Parikshit Manur 
parikshit.ma...@citrix.com wrote:

  Hi All,

 Creation of server with command  ‘nova boot  --image
 image --flavor m1.medium --nic port-id=port-id --security-groups
  sec_grp name’ fails to attach the security group to the
 port/instance. The response payload has the security group added but only
 default security group is attached to the instance.  Separate action has to
 be performed on the instance to add sec_grp, and it is successful.
 Supplying the same with ‘--nic net-id=net-id’ works as expected.



 Is this the expected behaviour / are there any other options which needs
 to be specified to add the security group when port-id needs to be attached
 during boot.



 Thanks,

 Parikshit Manur

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

2014-09-25 Thread Day, Phil
I think the expectation is that if a user is already interaction with Neutron 
to create ports then they should do the security group assignment in Neutron as 
well.

The trouble I see with supporting this way of assigning security groups is what 
should the correct behavior be if the user passes more than one port into the 
Nova boot command ?   In the case where Nova is creating the ports it kind of 
feels (just)  Ok to assign the security groups to all the ports.  In the case 
where the ports have already been created then it doesn’t feel right to me that 
Nova modifies them.






From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: 25 September 2014 08:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [NOVA] security group fails to attach to an 
instance if port-id is specified during boot.

Hi Parikshit,

Looks like a bug. Currently if port is specified its security groups are not 
updated, it shpould be fixed.
I've reported https://bugs.launchpad.net/nova/+bug/1373774 to track this.
Thanks for reporting!

Thanks,
Oleg

On Thu, Sep 25, 2014 at 10:15 AM, Parikshit Manur 
parikshit.ma...@citrix.commailto:parikshit.ma...@citrix.com wrote:
Hi All,
Creation of server with command  ‘nova boot  --image image 
--flavor m1.medium --nic port-id=port-id --security-groups  sec_grp name’ 
fails to attach the security group to the port/instance. The response payload 
has the security group added but only default security group is attached to the 
instance.  Separate action has to be performed on the instance to add sec_grp, 
and it is successful. Supplying the same with ‘--nic net-id=net-id’ works as 
expected.

Is this the expected behaviour / are there any other options which needs to be 
specified to add the security group when port-id needs to be attached during 
boot.

Thanks,
Parikshit Manur

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev