[openstack-dev] [nova] v3 api remove security_groups extension (was Re: security_groups extension in nova api v3)
joe.gordon0 at gmail.com
Thu Aug 15 20:13:10 UTC 2013
On Thu, Aug 15, 2013 at 12:16 PM, Melanie Witt <melwitt at yahoo-inc.com>wrote:
> On Aug 13, 2013, at 3:35 PM, Melanie Witt wrote:
> > On Aug 13, 2013, at 2:11 AM, Day, Phil wrote:
> >> If we really want to get clean separation between Nova and Neutron in
> the V3 API should we consider making the Nov aV3 API only accept lists o
> port ids in the server create command ?
> >> That way there would be no need to every pass security group
> information into Nova.
> >> Any cross project co-ordination (for example automatically creating
> ports) could be handled in the client layer, rather than inside Nova.
> > Server create is always (until there's a separate layer) going to go
> cross project calling other apis like neutron and cinder while an instance
> is being provisioned. For that reason, I tend to think it's ok to give some
> extra convenience of automatically creating ports if needed, and being able
> to specify security groups.
> > For the associate and disassociate, the only convenience is being able
> to use the instance display name and security group name, which is already
> handled at the client layer. It seems a clearer case of duplicating what
> neutron offers.
> Thinking about this more, it seems like the security_groups extension
> should probably be removed in the v3 api. Originally, we considered not
> porting it to v3 because it's a network-related extension whose actions can
> be accomplished through neutron directly.
> Then, it seemed associate/disassociate the with instance would be needed
> in nova, and those actions alone were ported. However, looking into the
> code more I found that's simply a neutron port update (append security
> group to port). Server create is similar.
> It seems like the extension isn't really needed in v3. Does anyone have
> any objection to removing it?
+1 from me as long as this wouldn't change anything for the EC2 API's
security groups support, which I assume it won't.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev