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