<div dir="ltr">You could rise an exception if ports are specified for all nics. [1]<div>I'm not sure that logging of this case is helpful, because only admins can access to logs.</div><div>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).</div><div><br></div><div>[1] It returns us back to the original Matt's question.</div><div>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.</div><div>In my turn, i used these parameters together (<a href="https://github.com/stackforge/ec2-api/blob/master/ec2api/api/instance.py#L770">https://github.com/stackforge/ec2-api/blob/master/ec2api/api/instance.py#L770</a>) to do a workaround of a strange bug (<a href="https://bugs.launchpad.net/nova/+bug/1384347">https://bugs.launchpad.net/nova/+bug/1384347</a>), which is not actual since Juno. I believe OpenStack could not support compatibility for such workarounds.</div><div><br></div><div>Finlally, the only my concern is the case with two nics, mentioned at the beginning.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 10:39 AM, Oleg Bondarev <span dir="ltr"><<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Feb 10, 2015 at 5:26 PM, Feodor Tersin <span dir="ltr"><<a href="mailto:ftersin@cloudscaling.com" target="_blank">ftersin@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>Also a similar question arises out of '--nic port-id=xxx,v4-fixed-ip=yyy' combination.</div><div>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?</div><div><br></div><div>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?</div></div></blockquote><div><br></div></span><div>I don't want to break anything :) </div><div>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 - </div><div>but this still leaves a chance of broken user expectations.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 10:29 AM, Oleg Bondarev <span dir="ltr"><<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin <span dir="ltr"><<a href="mailto:ftersin@cloudscaling.com" target="_blank">ftersin@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>nova boot ... --nic port-id=xxx --nic net-id=yyy</div><div>this case is valid, right?</div><div>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.</div><div>If i specify a security group as well, it will be used for the second port (if not - default group will):</div><div>nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1<br></div><div>Thus a port and a security group can be specified together.</div></div></blockquote><div><br></div></span><div>The question here is what do you expect for the existing port - it's security groups updated or not?</div><div>Will it be ok to silently (or with warning in logs) ignore security groups for it?</div><div>If it's ok then is it ok to do the same for:</div><div>nova boot ... --nic port-id=xxx --security-groups sg-1<br></div><div>where the intention is clear enough?</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
On 9/26/2014 3:19 AM, Christopher Yeoh wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Fri, 26 Sep 2014 11:25:49 +0400<br>
Oleg Bondarev <<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil <<a href="mailto:philip.day@hp.com" target="_blank">philip.day@hp.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think the expectation is that if a user is already interaction<br>
with Neutron to create ports then they should do the security group<br>
assignment in Neutron as well.<br>
<br>
</blockquote>
<br>
Agree. However what do you think a user expects when he/she boots a<br>
vm (no matter providing port_id or just net_id)<br>
and specifies security_groups? I think the expectation should be that<br>
instance will become a member of the specified groups.<br>
Ignoring security_groups parameter in case port is provided (as it is<br>
now) seems completely unfair to me.<br>
</blockquote>
<br>
One option would be to return a 400 if both port id and security_groups<br>
is supplied.<br>
<br>
Chris<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
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').<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/154068/" target="_blank">https://review.openstack.org/#<u></u>/c/154068/</a><br>
[2] <a href="https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Not_Acceptable" target="_blank">https://wiki.openstack.org/<u></u>wiki/APIChangeGuidelines#<u></u>Generally_Not_Acceptable</a><span><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>