Open Stack

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.logan at 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 <enikanorov at mirantis.com>
> Reply-To: "openstack-dev at lists.openstack.org" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, April 15, 2014 at 7:00 AM
> To: "openstack-dev at lists.openstack.org" <openstack-dev at 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 <sbalukoff at 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 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/20140417/40ffc5e7/attachment.html>