On Thu, Aug 15, 2013 at 12:16 PM, Melanie Witt <melw...@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. > Melanie > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
