Open Stack

>
> On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov <enikanorov at mirantis.com
> > wrote:
>
>> Hi Stephen,
>>
>> Thanks for the great document. As I promised, I'll try to make a few
>> action items out if it.
>> First of all, I'd like to say that the API you have proposed is very
>> close to what is proposed in the blueprint
>> https://review.openstack.org/#/c/89903/ with several differences I'd
>> like to address here and make them action items.
>>
>
> Ok, the above blueprint was uploaded on April 23rd, literally the day I
> sent my API proposal to the mailing list. And this was after it was known
> via the action items in the previous week's IRC meeting that my team and I
> would be working hard over the next week to produce an API proposal
> revision, based on the excellent work of the Rackspace team from the
> previous week.
>
> I can understand having a "plan B" in case I missed a deadline there
> (after all, I wasn't all that confident we'd get it done in time, but I
> worked through the weekend and pulled some very long days to get it done)--
> but it's pretty offensive to me to realize that the action items from the
> previous week's meeting apparently weren't being taken seriously.
>

I'm not sure which of my actions exactly has offended you, was it
submitting a blueprint to neutron-spec?
I've been working on the several proposals, including the one on review
since the start of Icehouse, preparing wikis, docs, and even an attempt to
actually implement the proposal, so I'm not sure what exactly I did wrong.
I was not thinking about beating anyone to submit blueprint first, it was
on launchpad since the end of havana anyway and i've just renewed it and
followed the new process.

That not only was there apparently never an intent to seriously consider my
> proposal, but now, if I want to be heard, I'm going to have to familiarize
> myself with your proposal and fight tooth and nail to be heard to fix any
> brokenness I will almost certainly find in it. And I have to do this with
> very little confidence that my voice is going to be heard.
>

I think our disconnect comes from the fact that whole discussion that
started in the end of Havana from fixing the API in the way that L7 &
multiple listeners are possible, came to the discussion of 'what lbaas API
of the dream should look like'.
Your document does great job of addressing the latter, but it's hardly a
single action item/single blueprint/single patch.


> Gee. Thanks.
>
Sorry, In fact I should have meant that some of those action items are for
me actually, your doc is very detailed, while spec on review yet is not.
I'll try to bring it to some accordance to your doc.


>
>> So, first of all, I think that API described in the doc seems to account
>> for all cases we had in mind, i didn't check on case-by-cases basis, it's
>> just a first glance impression looking at REST resource set and their
>> attributes.
>>
>
> As an aside, let's us please, please, please get these use cases out of
> being "in mind" and into a unified, digestible, revision-controlled
> document. I guarantee you haven't thought of some of the use cases I have
> in mind.
>
>
>> General idea of the whole API/obj model improvement is that we create a
>> baseline for all advanced features/usecases that we have in the roadmap.
>> Which means that those features then can be added incrementally.
>> Incrementally means that resources or attributes might be added, but
>> workflow remains and backward compatibility is preserved. That was not the
>> case with multiple listeners and L7.
>>
>
> I would argue that that wasn't the case for SSL either in the old model.
> And even the model I proposed doesn't address HA yet.
>
The model shouldn't immediately address HA. You just have to make sure that
once you decided to add HA, you don't have to redesign the rest of it (but
that probably requires some ideas on how to add HA)


> It's assumed that the object model proposed won't affect the ability of
> vendors to implement HA in whatever way makes sense for their
> organization... but we don't really know that until we see some rough
> models on that front.
>
> Anyway, I think the point remains that the whole reason for the API and
> object model revision was to be more forward thinking, specifically about
> those features that are currently sorely lacking from Neutron LBaaS, and
> which both users and operators clearly need before the solution can be
> deployed on a wide scale.
>
> And yes, of course this is a design that will necessarily be implemented
> incrementally! First priority should be to deliver at least the same level
> of functionality that the old api / object model delivers. But, again, I
> think it's a really good idea to be forward thinking about these sorts of
> things. If I'm planning a road trip from Denver to New York, I like to
> consider at a high level at least what kind of route will take me there (so
> I can be sure that I don't realize 500 miles into the trip that I've been
> driving toward L.A. the whole time).
>
>
>> So, a couple on general comments:
>>
>> 1. Whole discussion about API/obj model improvement had the goal of
>> allowing multiple pools and multiple listeners.
>>
>
> This is news to me. If we aren't going to be thinking about SSL and L7
> also, at least, then there really was no reason to propose drastic changes
> to the API / object model.
>
Stephen, L7 and multiple listeners were the reasons to revise the model.
Let's just separate the work of improving existing API/obj model from
additional action items, as i said above. L7 and SSL could be worked on in
parallel, but only after deal with Pools/Vips/Listeners is fixed.
Think of it from implementation perspective: how can one work on SSL if
there still not fixed whether we have listeners or just VIPs? same for L7.



> And just what have we been discussing on this mailing list and in the IRC
> meetings for the last couple months? Again, I think it's a little unfair to
> criticize the API proposal I've made because it delivers features that
> people have been asking for for a long time (and that are already present,
> functional, and well understood in other load balancer implementations.)
>
I don't remember criticizing it, I actually think it is a great and
detailed description, good API; in the part that is about
VIP/listeners/Pools it is nearly the same as the blueprint on spec-review,
other parts such as L7 stuff also makes sense to me, but that's certainly
what I didn't plan to address in my bp, which has much much more limited
scope.



> Also, please understand that "multiple pools" is L7! Can anyone name a use
> case where multiple back-end pools are used on a single listener that
> doesn't involve some L7 logic in there somewhere?
>
Right, it is L7. And I'm not trying to add L7, I'm just getting rid of
'Pool as the root object' that has prevented L7 from being implemented,
that is in scope of my proposal. Actually adding L7 is out of scope of it.


>
>> For that purpose loadbalancer instance might be an extra. The good thing
>> about 'loadbalancer' is that it can be introduced in the API in incremental
>> way.
>>
>
> Right. You might also notice that in the diagram, it's grayed out and
> there are notes indicating that work needs to be done to flesh out the
> concept based on discussion around HA functionality and operator concerns.
> Again, this is an attempt by me to be more forward-thinking.
>
> There is only one attribute (of a VIP) that references the "load balancer"
> concept as defined in the glossary (also linked). Yes, it can be removed
> from this API proposal and added back in again later when / if the
> discussion around HA actually happens.
>
>
>> So, VIP+listeners itself is already quite flexible construct (where VIP
>> is a root object playing loadbalancer role) that addresses our immediate
>> needs.
>> So I'd like to extract loadbalancer API and corresponding use cases in
>> another blueprint.
>> You know that loadbalancer concept has raised very heated discussions so
>> it makes sense to continue discussing it separately, keeping in mind that
>> introducing loadbalancer is not very complex and it may be done on top of
>> the VIPs/listeners API
>>
>
> Also, I notice this is a pretty stark 180-degree turn around on your
> position on this from previous weeks' discussions. It's OK to change one's
> mind on these things, but again, this leads me to believe that this is
> being forced from outside of the Neutron LBaaS sub-project.
>
Not exactly. I was advocating approaches #2 and #3 from the beginning (
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion)
because both of them address requirements for multiple tcp endpoints
and
L7 (structurally they are close).
I agree that #2 is even more flexible, but the discussion about the
loadbalancer instance has been kept for more than release cycle for now
without much result; since #3 addresses the requirements also - I'm ok with
that.


>
>> 2. SSL-related objects. SSL is rather big deal, both from API and object
>> model, it was a separate blueprint in Icehouse and i think it makes sense
>> to work separately on it.
>> What I mean is that ssl don't affect core API (VIPs/listeners/pools)
>> other than adding some attributes to listeners.
>>
>
> Ok, again, from my perspective this is a stark change from how this has
> been discussed in previous weeks on this mailing list and in the IRC
> meetings. I thought it hadn't been decided exactly how SSL was going to be
> done yet.
>
Something could be called 'decided' when it lands into the code repository.
There has been some work already done on SSL on both design and
implementation front though.


> (There was very little discussion of this on the mailing list, and
> certainly nothing conclusive. And even the blueprint references a gerrit
> patch "discussion" that essentially is just CI systems checking in. In fact
> the only actual design discussion of this in months appears to have been
> happening exclusively on the mailing list:
> http://stackalytics.com/report/blueprint/neutron/lbaas-ssl-termination )
>
> If you want to claim that "silence implies consent" with the design, this
> seems disingenuous to me when much more broad design discussions (which
> ultimately affect the SSL design) are happening at the same time. It's like
> arguing about how the decks are going to be laid out when we haven't even
> decided which kind of ship we're building yet.
>
I'm not sure that I'm arguing here at all. As you probably noticed, I
didn't participate much in ssl-related discussions.
Speaking of SSL - we have a few few project-wise issues such as lack of
secure storage, lack of secure messaging, requirement to have opensource
impl of SSL API (which yet to be added).
There's also a patch on review that is worth looking at, because someone
has already put efforts into both design and code.
And before throwing away all those efforts we need to be sure it
completely not suitable with the rest of API.



>
>
>> 3. L7 is also a separate work, it will not be accounted in 'API
>> improvement' blueprint. You can sync with Samuel for this as we already
>> have pretty detailed blueprints on that.
>>
>
> Please provide an example of how "multiple pools" will actually be used
> without L7.
>
As said above, the bp targets just the baseline for L7: removing 'root
object' role from the Pool, to actually allow multiple pools in
configuration when L7 rules are added.


> And again: "Let's move the discussion off the mailing list where it's been
> happening over to the system where apparently others have been pressing
> forward without the obvious knowledge or consent of the people having the
> discussion. Oh, and by the way, because we've already written code here, a
> lot of what you propose is tacitly no longer up for discussion."
>
>
>> 4. Attribute differences in REST resources.
>> This falls into two categories:
>> - existing attributes that should belong to one or another resource,
>>
>
> The devil's in the details here. I was very specific about which
> attributes belong to which objects because getting this wrong has serious
> implications for use cases. (For example, if "neutron_subnet" is an
> attribute of a pool, then this implies all members of the pool must be in
> the same neutron_subnet. And this breaks the use case that was described on
> the mailing list during the SSL re-encryption discussion where some members
> are in the same subnet, and some are across the internet on the other side
> of a VPN or otherwise.)
>
Right. I should have said it's a work item for me - to look closely through
your doc and address the differences. Also, that is exactly the kind of
work item where gerrit helps a lot.


>
> You also need to define which attributes are immutable after creation of
> the object, and which can be changed with later updates (and how). This
> also has implications for use cases.
>
Well, this is usually defined in the code, I can add this to the spec as
well. I hoped to avoid duplicate work.


>

> If your proposal doesn't define this level of detail, then your proposal
> isn't addressing the use cases and is therefore incomplete.
>
I'm working on that.


>
>
>> - attributes that should be added (e.g. they didn't exist in current API)
>>
>
> Right. As I said last week, my intention was to try to address as many
> concerns and feature requests from the mailing list discussions, wiki
> pages, and google documents / spreadsheets as possible. I was hoping to
> take a stab at HA as well, but the result of that discussion so far is that
> we're nowhere near having any idea how to accomplish this in a way that is
> going to be generically possible for all operators.
>
> I mean: You all do realize that if there's a key missing feature that one
> operator absolutely needs in order to continue their business operations,
> that isn't addressed in our proposals... then that operator is NOT going to
> use our product, right?
>


> And that doesn't mean you need to offer all features out of the gate-- but
> you ought to have put some thought into how you're going to do it when the
> time comes. This proposal is trying to be that plan for how we're
> eventually going to do it. It will, of course, be developed incrementally.
>
So, what are we arguing about? I'm just doing the small part that fixes
relationship issue with the obj model.


>
> It is true that I haven't had the time to fill out all the use cases we
> thought about, or that became apparent from mailing list discussions as we
> were writing our API revision proposal--  our main drive was to get the
> proposal out the door. My plan was (and still is) to back-fill these use
> cases in the right place (which I'm no longer sure is the google doc that
> Samuel created, or the gerrit system) once we got the API proposal out. So
> I do apologize that I'm making reference to stuff that has been considered
> but not shared thus far and realize that not having it in the shared
> document weakens my position. I had to sleep.
>
>
>> The first class is better to be addressed in the blueprint review. The
>> second class could be a small action items/blueprints or even bugs.
>>
> Example:
>>   1) "custom_503" - that attribute deserves it's own miniblueprint, I'd
>> keep it out of scope of 'API improvement' work.
>>  2) ipv6_subnet_id/addressv6 - that IMO also deserves it's own
>> miniblueprint (whole thing about ipv6 support)
>>
>
> Yep, custom_503 is extremely minor, and its use case is "User would like
> to have custom error 503 page displayed on HTTP / HTTPS requests when no
> servers are available in the back-end pool(s)."
>
> IPv6 discussions are quite a bit more involved-- but I will note that at
> least one major vendor mentioned this as a high priority item, (and it
> turns out it's easy to address in the model) which is why we threw it in
> this proposal.
>
They're welcome to propose bp on the ipv6 support and implement it.


>
>
>> So, I'd like to make the following action items out of the document:
>>
>> 1. Extract 'core API' - VIPs/Listeners/Pools/Members/Healthmonitors.
>> This action item is actually the blueprint that I've filed and that's
>> what I'm going to implement
>>
>
> "that's what I'm going to implement"--  ie. Discussion is closed on this.
>
I'm not sure I get your point here. Just reiterating: 'root object' moved
to VIP, listeners added - that's what i'm addressing.
Once we have that, you can actually develop patches on everything else and
be sure that you have not redone everything if underlying design is changed.


>
>
>> 2. Work on defining single-call API that goes along with single object
>> core API (above)
>> Your document already does a very good job on this front.
>>
>
> Thank you. It's nice to know some of my work is being paid attention to.
>
>
>> 3. Extract 'Loadbalancer' portion of API into additional Doc/blueprint. I
>> deserves it's own discussion and use cases.
>> I think separating it will also help to reduce discussion contention.
>>
>
> Fine, though I would say that justifying the "VIP-centric" approach
> becomes more difficult if we're not starting to think about how we're going
> to address operator concerns (like, say, HA) and how these potentially
> intersect and/or interface with user concerns.
>
Well, I'd also would like to hear from those, who don't want neutron to
provide 'virtualized appliance' functionality.
I think that meanwhile we may treat VIP as 'loadbalancer' object and apply
HA features directly to it.


>
>> 4. Work with https://review.openstack.org/#/c/89903/ to define proper
>> attribute placement of existing attributes
>>
>
> Given that you totally ignored (or planned to ignore) the work you knew I
> was doing on this API proposal in writing the above blueprint...  does my
> opinion on the attribute placement even matter at this point?
>
Sorry again for offensive phrasing, i didn't mean that. That was meant to
be is a work item more for me than for you, but i hoped to get some inline
comments on gerrit.

At the end I'd like to emphasize that I was not planning to implement
everything and account for all cases.
The scope is to add listeners and move 'root object' role from Pool to the
VIP, that's it, and that's what is on spec review.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140427/366c5964/attachment.html>