Open Stack

On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:
> Hi guys,
>
> Sorry for all the drama on the list lately.
>
Not a problem. Like I said, the passion from all sides is great, and
I'm especially happy to see all the operators engaging with Neutron
for LBaaS.

> Kyle: I appreciate the sentiment. I'd also be happy to open up my API doc
> for general editing by people on the internet (and not just comments) if you
> think that would help.
>
My main reason for asking this was in case the gerrit bar was too high
for new people to Neutron and LBaaS in particular. I want to make sure
we capture everyone's ideas and allow everyone a chance to comment.
The gerrit BP process does this nicely, but I just want to ensure it's
not too high of a bar for people new to the entire process.

> For us new-comers to the OpenStack project environment, what do people
> usually use for discussing potential design changes (and especially large
> design changes)?  (From my perspective, Blue prints seem mostly useful as
> collections of links to other documents, without having an obvious way to
> discuss things in the blueprint directly. Gerrit seems like it's mostly
> "github workflow" with CI baked in-- ie. useful for specific smaller code
> changes, but not as much for design-level discussions. I suppose etherpads
> might duplicate much of the functionality we're currently using google docs
> to accomplish (though I don't think etherpads have the ability to do
> spreadsheets, from what I can tell).
>
I think it's fine to use the gdoc for now, with the idea being we will
then converge on work items formed into multiple BPs out of the gdoc.
So perhaps it does make sense to use your document as the communal
starting point for this. But I'm open to what others may say as well.

> As far as the meetings go: It might help if you could share with us what you
> hope to accomplish prior to the summit, and what kinds of things you'd like
> us to be prepared to discuss at the summit. (Is there an LBaaS meeting of
> some kind scheduled there yet?)
>
I've given LBaaS 2 40 minute sessions. What I'd like us to do is come
to come to a consensus on what needs discussing in person vs. what
everyone is agreeing on and we don't need to discuss in those
sessions. If we need time to discuss the object model and API in
Atlanta, that's fine too.

> For my part, I plan on concentrating on filling out more use cases and then
> returning to the software load balancer virtual appliance porting project
> that's been on the back-burner for way too long for me.
>
Perfect! How about if we try to close the use case gap for this week's
LBaaS meeting. Then, next week we can at least make a stab at the
object model and API which satisfies as many use cases as we come up
with.

> Samuel and German: I've gone ahead and added around 20 new use cases to the
> google doc you linked. More will be on the way, but I'm happy to add these
> to gerrit myself if you'd prefer, so long as I can see how you're doing this
> for the first use cases and can follow your template. Let me know if you'd
> like me to change what I've been doing here, eh! Note also that so far these
> are only "user" use cases; It doesn't look like admin/operator use cases
> have been filled out at all yet.
>
Getting the admin/operator use cases in there would be good as well Stephen.

Thanks,
Kyle

> Thanks,
> Stephen
>
>
>
>
> On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German
> <german.eichberger at hp.com> wrote:
>>
>> Sam,
>>
>> The use cases where pretty complete the last time I checked so let's move
>> them to gerrit so we can all vote.
>>
>> Echoing Kyle I would love to see us focusing on getting things ready for
>> the summit.
>>
>> German
>>
>> -----Original Message-----
>> From: Samuel Bercovici [mailto:SamuelB at Radware.com]
>> Sent: Monday, April 28, 2014 11:44 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Hi,
>>
>> I was just working to push the use cases into the new format .rst but I
>> agree that using google doc would be more intuitive.
>> Let me know what you prefer to do with the use cases document:
>> 1. leave it at google docs at -
>> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
>> 2. Move it to the new format under -
>> http://git.openstack.org/cgit/openstack/neutron-specs, I have already files
>> a blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases
>> and can complete the .rst process by tomorrow.
>>
>> Regards,
>>         -Sam.
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Kyle Mestery [mailto:mestery at noironetworks.com]
>> Sent: Monday, April 28, 2014 4:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
>>
>> Folks, sorry for the top post here, but I wanted to make sure to gather
>> people's attention in this thread.
>>
>> I'm very happy to see all the passion around LBaaS in Neutron for this
>> cycle. As I've told a few people, seeing all the interest from operators and
>> providers is fantastic, as it gives us valuable input from that side of
>> things before we embark on designing and coding.
>> I've also attended the last few LBaaS IRC meetings, and I've been catching
>> up on the LBaaS documents and emails. There is a lot of great work and
>> passion by many people. However, the downside of what I've seen is that
>> there is a logjam around progress here. Given we're two weeks out from the
>> Summit, I'm going to start running the LBaaS meetings with Eugene to try and
>> help provide some focus there.
>> Hopefully we can use this week and next week's meetings to drive to a
>> consistent Summit agenda and lay the groundwork for LBaaS in Juno and
>> beyond.
>>
>> Also, while our new neutron-specs BP repository has been great so far for
>> developers, based on feedback from operators, it may not be ideal for those
>> who are not used to contributing using gerrit. I don't want to lose the
>> voice of those people, so I'm pondering what to do. This is really affecting
>> the LBaaS discussion at the moment. I'm thinking that we should ideally try
>> to use Google Docs for these initial discussions and then move the result of
>> that into a BP on neutron-specs. What do people think of that?
>>
>> If we go down this path, we need to decide on a single Google Doc for
>> people to collaborate on. I don't want to put Stephen on the spot, but his
>> document may be a good starting point.
>>
>> I'd like to hear what others think on this plan as well.
>>
>> Thanks,
>> Kyle
>>
>>
>> On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov
>> <enikanorov at mirantis.com> wrote:
>> > Hi,
>> >
>> >>
>> >> You knew from the action items that came out of the IRC meeting of
>> >> April
>> >> 17 that my team would be working on an API revision proposal. You
>> >> also knew that this proposal was to be accompanied by an object model
>> >> diagram and glossary, in order to clear up confusion. You were in
>> >> that meeting, you saw the action items being created. Heck, you even
>> >> added the "to prepare API for SSL and L7" directive for my team
>> >> yourself!
>> >>
>> >> The implied but not stated assumption about this work was that it
>> >> would be fairly evaluated once done, and that we would be given a short
>> >> window (ie.
>> >> about a week) in which to fully prepare and state our proposal.
>> >>
>> >> Your actions, though, were apparently to produce your own version of
>> >> the same in blueprint form without notifying anyone in the group that
>> >> you were going to be doing this, let alone my team. How could you
>> >> have given my API proposal a fair shake prior to publishing your
>> >> blueprint, if both came out on the same day? (In fact, I'm lead to
>> >> believe that you and other Neutron LBaaS developers hadn't even
>> >> looked at my proposal before the meeting on 4/24, where y'all started
>> >> determining product direction, apparently by
>> >> edict.)
>> >>
>> >>
>> >> Therefore, looking honestly at your actions on this and trying to
>> >> give you the benefit of the doubt, I still must assume that you never
>> >> intended to seriously consider our proposal.
>> >
>> > That's strange to hear because the spec on review is a part of what is
>> > proposed in the document made by you and your team.
>> > Once again I'm not sure what this heated discussion is all about. The
>> > doc does good job and we will continue discussing it, while a part of
>> > it (spec about VIPs/Listeners/Pools) is on review where we, as lbaas
>> > subteam, actually can finalize a part of it.
>> >
>> >>
>> >> Do you now understand why I find this offensive? Can you also
>> >> understand how others, seeing how this was handled, might now be
>> >> reluctant to participate?
>> >
>> > People may find different things to be offensive. I can also say much
>> > on this, but would not like not continue the conversation in this
>> > direction.
>> >
>> >
>> >> Right, so *if* we decide to go with my proposal, we need to first
>> >> decide which parts we're actually going to go with--
>> >>
>> >>  I don't expect my proposal to be complete or perfect by any means,
>> >> and we need to have honest discussion of this first. Then, once we've
>> >> more-or-less come to a consensus on this overall direction,
>> >
>> > I'm not sure i understand what you mean by 'overall direction'. Was
>> > there ever an idea of not supporting HA, or L7, or SSL or to not
>> > satisfy other requirements?
>> > The discussion could be on how to do it, then.
>> >
>> >> it makes sense to think about how to split up the work into
>> >> digestible, parallelize-able chunks that can be tackled by the
>> >> various interested parties working on this project.  (My team
>> >> actually wanted to propose a road map and attach it to the proposal,
>> >> but there simply wasn't time if we wanted to get the API out before
>> >> the next IRC meeting in enough time for people to have had a chance
>> >> to look at it.)
>> >>
>> >> Why embark on this process at all if we don't have any real idea of
>> >> what the end-goal looks like?
>> >
>> > I hope this will not look offensive if I say that the 'end goal' was
>> > discussed at Grizzly, Havana and Icehouse summit and even before.
>> > While not every requirement was discussed on the summits, there was
>> > quite clear understanding of the dependencies between features. And I
>> > don't mean that 'roadmap is fixed' or anything like that, I'm just
>> > saying that thinking about the end-goal  is not something we've started
>> > to do 1.5 months ago.
>> >
>> > So speaking about 'holistic view', please tell, how L7 and SSL are
>> > related, does one depend on another or affect another?
>> >
>> >>
>> >> Right--  so paraphrasing what I think you're saying: "Let's consider
>> >> how we're going to tackle the SSL and L7 problems at a later date,
>> >> once we've fixed the object model to be compatible with how we're
>> >> going to tackle SSL and L7." This implies you've already considered
>> >> how to tackle SSL and L7 in making your object model change proposal!
>> >
>> > That was mostly about L7, but for sure subteam has considered and
>> > designed L7, and I also assume you've seen those design docs made by
>> > Sam: on your diagrams I see the same objects and relationship as in
>> > Samuel's doc.
>> >
>> >> My point is: Unless you have already considered how to do SSL and L7,
>> >> then any object model change proposal is essentially pointless.
>> >>
>> >> Why make these changes unless we already know we're going to do SSL
>> >> and L7 in some way that is compatible with the proposed changes?
>> >>
>> >>
>> >> Evaluating these things *necessarily* must happen at the same time (ie.
>> >> holistically) or the object model proposal is pointless and
>> >> unjustified.
>> >> Actually implementing the design will happen first with the core
>> >> object model changes, and then the SSL and L7 features.
>> >
>> > ...
>> >>
>> >> But I think I've already made my point that not considering things
>> >> like SSL and L7 in any proposal means there's no clear indication
>> >> that core object model changes will be compatible with what needs to
>> >> happen for SSL and L7.
>> >>
>> >>>>
>> >>>> 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.
>> >>
>> >>
>> >> Ok, so I'm hearing you say that L7 is out of scope, but changes which
>> >> enable the possibility of L7 are not. I would say that the latter
>> >> cannot be done without considering how former is likely to be done.
>> >> So while actually implementing L7 can be done separately, evaluating
>> >> the proposed object model / API design changes cannot be.
>> >
>> >
>> > What exactly made you think that we are blindly suggesting drastic API
>> > and object model change?
>> > Is that because L7 & SSL proposals were made long before you, folks
>> > from HP and Rackspace has jumped in?
>> > Then I can only regret that that I didn't conduct a line of lectures
>> > explaining the current state of the code as well as the state of
>> > publicly available proposals.
>> >
>> >> Ok, that still seems to me like you're taking that stance because
>> >> people in Neutron core see the word "load balancer" and assume it's
>> >> an implementation detail (without actually defining what an
>> >> implementation detail is, nor apparently looking at the glossary we
>> >> made largely to address the confusion around this term).
>> >>
>> >> Would it help if I called it an "efkalb" in my proposal instead?
>> >
>> > No, it would not help. The root cause is 'virtualized appliance' vs
>> > 'virtual network function' question.
>> > Putting this in more practical angle: is it necessary from user
>> > standpoint to be able to create more than one L2 endpoint (port) for
>> > single load balancing configuration? I think that's the defining
>> > question.
>> >
>> >>
>> >> Also for clarification: I'm not trying to knock those who do code
>> >> early (producing POCs and whatnot). Sometimes the only way to come up
>> >> with specific requirements is to see what can be done by trying out
>> >> different ways to solve a problem. But it seems unrealistic to me to
>> >> expect initial exploratory efforts in this regard to end up in final
>> >> product.
>> >
>> > It's just now they suddenly became exploratory. Because someone has
>> > introduced whole set of new requirements that didn't exist at the
>> > point when the design and the code was written. While it's fine to
>> > adopt and reevaluate them with new requirements, it's not fine to say
>> > folks didn't have their requirements.
>> >
>> >> Whenever I see this done, where assumptions about how the pieces fit
>> >> together are not re-evaluated once exploratory POCs have yielded more
>> >> knowledge or where said POCs end up becoming the final product, I see
>> >> significant design flaws that get baked into final products. Why do
>> >> y'all think it's been so hard to get "VIP" and "Listener" and "Pool"
>> >> separated into separate entities?
>> >
>> > It's not hard at all. Explaining obvious things and getting consensus
>> > is hard.
>> >
>> >> My proposal is a design discussion.
>> >
>> > My opinion is that design discussion alone can be split by features.
>> > My opinion is that while there are some dependencies between features,
>> > they are not such that design discussion can't be split.
>> > Exact design of L7 rules is not required to know how to move 'root
>> > object'
>> > role from Pool to Vip.
>> > Exact design of SSL is not required to know how to allow multiple tcp
>> > endpoints.
>> >
>> >> Look, I agree that splitting out VIP, Listener, and Pool to be their
>> >> own objects, and moving the "root" of the object tree to the VIP is
>> >> probably the right thing to do. But there are valuable contributors
>> >> in this discussion who are still not on-board with this idea. So why
>> >> is this fundamental design discussion being closed early? That was the
>> >> point of my comment.
>> >
>> > So the discussion has been held up for whole release cycle, with two
>> > last months this particular proposal being out on the wiki and
>> > discussed on the meetings. And then again people say about 'duct
>> > taping' current API and 'convenience of legacy developers'. How valuable
>> > is that?!
>> > Especially given the fact the proposal on gerrit describes the part
>> > which actually had the consensus on the meetings, I might also ask -
>> > are people reading other's specs at all?
>> >
>> >
>> > Eugene.
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>