Open Stack

On Thu, Aug 15, 2013 at 12:16 PM, Melanie Witt <melwitt at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130815/53358c73/attachment.html>