Hi Brandon, Seems that doc has not been made public, so please share.
Thanks, Eugene. On Thu, Apr 17, 2014 at 12:39 AM, Brandon Logan <brandon.lo...@rackspace.com > wrote: > Here is Jorge and team’s API proposal based on Atlas. The document has > some questions and answers about why decisions were made. Feel free to > open up a discussion about these questions and answers and really about > anything. This can be changed up to fit any flaws or use cases we missed > that this would not support. > > There is a CLI example at the bottom along with a possible L7 switching > API model. > > > https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit > > Thanks, > Brandon Logan > > From: Eugene Nikanorov <enikano...@mirantis.com> > Reply-To: "openstack-dev@lists.openstack.org" < > openstack-dev@lists.openstack.org> > Date: Tuesday, April 15, 2014 at 7:00 AM > To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org > > > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API > revision progress > > Hi Stephen, > > Thanks for a good summary. Some comments inline. > > > On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff > <sbaluk...@bluebox.net>wrote: >> >> >> So! On this front: >> >> 1. Does is make sense to keep filling out use cases in Samuel's >> document above? I can think of several more use cases that our customers >> actually use on our current deployments which aren't considered in the 8 >> cases in Samuel's document thus far. Plus nobody has create any use cases >> from the cloud operator perspective yet. >> > > I treat Sam's doc as a source of use cases to triage API proposals. If > you think you have use cases that don't fit into existing API or into > proposed API, they should certainly be brought to attention. > > >> >> 2. It looks like we've started to get real-world data on Load Balancer >> features in use in the real world. If you've not added your organization's >> data, please be sure to do so soon so we can make informed decisions about >> product direction. On this front, when will we be making these decisions? >> > I'd say we have two kinds of features - one kind is features that affect > or even define the object model and API. > Other kind are features that are implementable within existing/proposed > API or require slight changes/evolution. > First kind is the priority: while some of such features may or may not be > implemented in some particular release, we need to implement proper > infrastructure for them (API, obj model) > > Oleg Bondarev (he's neutron core) and me are planning and mostly > interested to work on implementing generic stuff like API/obj model and > adopt haproxy driver to it. So our goal is to make implementation of > particular features simpler for contributors and also make sure that > proposed design fits in general lbaas architecture. I believe that everyone > who wants to see certain feature may start working on it - propose design, > participate in discussions and start actually writing the code. > > > >> 3. Jorge-- I know an action item from the last meeting was to draft a >> revision of the API (probably starting from something similar to the Atlas >> API). Have you had a chance to get started on this, and are you open for >> collaboration on this document at this time? Alternatively, I'd be happy to >> take a stab at it this week (though I'm not very familiar with the Atlas >> API-- so my proposal might not look all that similar). >> > > +1, i'd like to see something as well. > > >> What format or template should we be following to create the API >> documentation? (I see this here: >> http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html >> but this seems like it might be a little heavy for an API draft that is >> likely to get altered significantly, especially given how this discussion >> has gone thus far. :/ ) >> > > Agree, that's too heavy for API sketch. I think a set of resources with > some attributes plus a few cli calls is what could show the picture. > > Thanks, > Eugene. > > _______________________________________________ > 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
