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.k...@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 <dtro...@gmail.com>: > > On Fri, Sep 5, 2014 at 10:27 AM, Monty Taylor <mord...@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 > > dtro...@gmail.com > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStackfirstname.lastname@example.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Regards! > ----------------------------------- > Lingxian Kong > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev