Hi Stephen, 1. Could you please explain what you understand single-call API functionality to be? From my perspective most of our users will likely create load balancers via a web interface. Thought not necessary, having a single API call makes it easier to develop the web interface.
For the “expert” users I envision them to create a load balancer, tweak with the settings, and when they arrive at the load balancer they need to automate the creation of it. So if they have to create several objects with multiple calls in a particular order that is far too complicated and makes the learning curve very steep from the GUI to the API. Hence, I like being able to do one call and get a functioning load balancer. I like that aspect from Jorge’s proposal. On the other hand making a single API call contain all possible settings might make it too complex for the casual user who just wants some feature activated the GUI doesn’t provide…. 2. Could you describe the simplest use case that uses single-call API in your environment right now? Please be very specific-- ideally, a couple examples of specific CLI commands a user might run, or API (along with specific configuration data) would be great. http://libra.readthedocs.org/en/latest/api/rest/load-balancer.html#create-a-new-load-balancer 3. Could you describe the most complicated use case that your single-call API supports? Again, please be very specific here. Our API doesn’t have that many features so calls don’t get complicated. 4. What percentage of your customer base are used to using single-call functionality, and what percentage are used to manipulating primitives? We only offer the single call to create a load balancer so 100% of our customers use it. (So this is not a good number) 5. Should "single-call" stuff work for the lifecycle of a load balancing service? That is to say, should "delete" functionality also clean up all primitives associated with the service? Yes. If a customer doesn’t like a load balancer any longer one call will remove it. This makes a lot of things easier: - GUI development – one call does it all - Cleanup scripts: If a customer leaves us we just need to run delete on a list of load balancers – ideally if the API had a call to delete all load balancers of a specific user/project that would be even better ☺ - The customer can tear down test/dev/etc. load balancer very quickly German From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, April 17, 2014 12:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion Oh! One other question: 5. Should "single-call" stuff work for the lifecycle of a load balancing service? That is to say, should "delete" functionality also clean up all primitives associated with the service? On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff <sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>> wrote: Hi Sri, Yes, the meeting minutes & etc. are all available here, usually a few minutes after the meeting is over: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/ (You are also, of course, welcome to join!) Stephen On Thu, Apr 17, 2014 at 11:34 AM, Sri <sri.networ...@gmail.com<mailto:sri.networ...@gmail.com>> wrote: hello Stephen, I am interested in LBaaS and want to know if we post the weekly meeting's chat transcripts online? or may be update an etherpad? Can you please share the links? thanks, SriD -- View this message in context: http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html Sent from the Developer mailing list archive at Nabble.com. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807<tel:%28800%29613-4305%20x807> -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
