Open Stack

While it's good that somebody is addressing this specific issue, perhaps
"punctual" solutions  - eg: "hey I have a patch for that", are not
addressing the general issues, which is that Neutron has very granular
primitives that force users to do multiple API requests for operations they
regard as atomic.

What we need, in my opinion, is a set of "macros" which will provide some
basic orchestration over the primitives exposed by the Neutron API. For
instance another macro which has been requested several times is the
ability to create a port and associate it with a floating IP (well actually
the request I think is to boot a server with a public IP).
I think such macros are better placed on the server side rather than the
CLI, mostly because not all API clients use the CLI and failure management
is easier if done on th server side.
On the other hand I see those macros better implemented as by addition on
top of the current API rather than by modifying resources and actions
available in the current API.

I think it will be a good idea to compile a list of all the macros we want
to implement for Kilo, and then implement all of them within this
"mini-framework", rather than as many disjoint blueprints.

On another note, I think the teams working on the group policy API have
asserted several times that the new abstractions proposed will
automatically simplify the user interface. Everybody will be super happy
when that happens, but in the meanwhile we should provide solutions
targeting the current Neutron API.

Salvatore


On 6 September 2014 18:00, Lingxian Kong <anlin.kong at gmail.com> wrote:

> Hi, Monty,
>
> Thanks for bringing this topic up. I think the blueprint that Miguel
> mentioned will address the issue you're sufffering from, but maybe
> there are not many people interested in this feature, so
> unfortunately, the bp will not be landed in Juno release. But I will
> continue the bp when the Kilo dev cycle get started, since I believe
> this feature will benefit people like you.
>
> 2014-09-06 0:17 GMT+08:00 Dean Troyer <dtroyer at gmail.com>:
> > On Fri, Sep 5, 2014 at 10:27 AM, Monty Taylor <mordred at inaugust.com>
> wrote:
> >>
> >> I've decided that as I have problems with OpenStack while using it in
> the
> >> service of Infra, I'm going to just start spamming the list.
> >
> >
> > User CLI/API feedback!
> >
> >>
> >> neutron security-group-create default --allow-every-damn-thing
> >
> >
> > You mean like this?  https://review.openstack.org/#/c/119407/
> >
> > dt
> >
> > *Disclaimer: For demonstration purposes on nova-network only; the views
> > expressed here may not be those of the OpenStack Foundation, it's member
> > companies or lackeys; in case of duplicates, ties will be awarded; your
> > mileage may vary; allow 4 to 6 weeks for delivery; any resemblance to
> > functional code, living or dead, is unintentional and purely
> coincidental;
> > representations of this code may be freely reused without the express
> > written consent of the Commissioner of the National Football League.
> >
> > --
> >
> > Dean Troyer
> > dtroyer at gmail.com
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Regards!
> -----------------------------------
> Lingxian Kong
>
> _______________________________________________
> 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/20140906/f850099f/attachment.html>