On 2013年08月16日 03:16, Melanie Witt 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
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
