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
