Open Stack

On Tue, Feb 10, 2015 at 5:26 PM, Feodor Tersin <ftersin at 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 <obondarev at mirantis.com>
> wrote:
>
>>
>>
>> On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin <ftersin at 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 <
>>> 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
>>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20150211/ccf26d73/attachment.html>