On Apr 16, 2014, at 4:31 PM, Eugene Nikanorov
<[email protected]<mailto:[email protected]>> wrote:
Hi folks,
I've briefly looked over the doc.
I think whole idea to base the API on Atlas misses the content switching use
case, which is very important:
We need multiple pools within loadbalancer, and API doesn't seem to allow that.
If it would, then you'll face another problem: you need to reference those
pools somehow inside the json you use in POST.
There are two options here: use names or IDs, both are putting constraints and
create complexity for both user of such API and for the implementation.
That particular problem becomes worse when it comes to objects which might not
have names while it's better to not provide ID in POST and rely on their random
generation. E.g. when you need to create references between objects in json
input - you'll need to create artificial attributes just for the parser to
understand that such input means.
So that makes me think that right now a 'single-call API' is not flexible
enough to comply with our requirements.
We have demonstrated that you can create loadbalancers in separate
transactions and in a single call fashion using both reference_ids to previous
pools and as well as using a transient names to create objects in the same
single call and reference them later on in other objects. The single call API
is very flexible in that it allows you to create sub objects(We proposed
transient ids to allow the user to avoid creating duplicate objects with
different ids) on the fly as well as reference preexisting objects by id. The
allowance for transient ids is adding flexibility to the api not taking away
from it as you declared. I would like you to really be clear on what "our
requirements"? What requirement is our single API call violating?
We have thus far attempted to support a single call API that doesn't
interfere with multiple smaller object creation calls. If we are just adding to
the API in a demonstrably workable fashion what is the real objection.
While I understand that it might be simpler to use such API for some cases, it
makes complex configurations fall back to our existing approach which is
creating configuration on per object basis.
While the problem with complex configurations is not sorted out, I'd prefer if
we focus on existing 'object-oriented' approach.
Your basically saying
P1: "The single API call proposal doesn't support *ALL* complex configurations"
P2: " if the single API proposal doesn't support *ALL* complex configurations
the proposal should be rejected"
We have demonstrated that the proposed single API call can handle complex
configurations via transient ids. So we already disagree with preposition 1.
We don't agree with preposition 2 either:
We believe it is unfair to punish the API end user due to the religious
belief that "The single API calls must support all possible configurations or
you as the customer can't be allowed to use the single API call even for
simpler configurations."
We want the single API call proposal to be as useful as possible so we are like
wise looking at ways to have it solve ALL complex configurations and so far we
feel transient IDs solve this problem already.
Is the real objection that a single API call makes the implementation too
complex? We are advocating that a single API makes it easier on the end user of
the API and are of the impression that its better to have a complex
implementation inside our neutron/lbaas code rather then passing that
complexity down to the end user of the API.
We don't object to multiple smaller object creation transactions we just
want the addition of having single API call.
On the other hand, without single-call API the rest of proposal seems to be
similar to approaches discussed in
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
Since you linked the object model proposals could you also link the "rest
of the proposals" or are you referring to our draft as "rest of proposal"?
Thanks,
Eugene.
On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan
<[email protected]<mailto:[email protected]>> wrote:
Sorry about that. It should be readable now.
________________________________
From: Eugene Nikanorov [[email protected]<mailto:[email protected]>]
Sent: Wednesday, April 16, 2014 3:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision
progress
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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Reply-To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Date: Tuesday, April 15, 2014 at 7:00 AM
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
