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 <[email protected]> wrote: > > > On 9/26/2014 3:19 AM, Christopher Yeoh wrote: > >> On Fri, 26 Sep 2014 11:25:49 +0400 >> Oleg Bondarev <[email protected]> wrote: >> >> On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil <[email protected]> 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 >> [email protected] >> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
