Open Stack

Hi All,

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.

Phil 

> -----Original Message-----
> From: Melanie Witt [mailto:melwitt at yahoo-inc.com]
> Sent: 09 August 2013 23:05
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [nova] security_groups extension in nova api v3
> 
> Hi All,
> 
> I did the initial port of the security_groups api extension to v3 and have been
> testing it out in devstack while adding the expected_errors decorator to it.
> 
> The guidance so far on network-related extensions in v3 is not to duplicate
> actions that can be accomplished through the neutron api and assuming nova-
> network deprecation is imminent. So, the only actions left in the extension are
> the associate/disassociate security group with instance.
> 
> However, when security_group_api = neutron, all associate/disassociate will do
> is call the neutron api to update the port for the instance (port device_id ==
> instance uuid) and append the specified security group. I'm wondering if this
> falls under the nova proxying we don't want to be doing and if
> associate/disassociate should be removed from the extension for v3.
> 
> If removed, it would leave the extension only providing support for
> server_create (cyeoh has a patch up for review).
> 
> Any opinions?
> 
> Thanks,
> Melanie
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev