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:[email protected]] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
