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? Melanie _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
