Open Stack

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 <mriedem at 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 <obondarev at mirantis.com> wrote:
>>
>>  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil <philip.day at 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 at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150209/072e9854/attachment.html>