[openstack-dev] [nova] security_groups extension in nova api v3
philip.day at hp.com
Tue Aug 13 09:11:07 UTC 2013
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.
> -----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?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev