Open Stack

Hi ,

As Stephen +1 to everything Jorge said. Another concern is that some decisions impacting LBaaS operator requirements (e.g SSL, flavor framework, service chaining) are discussed/decided in the advanced services group (see https://wiki.openstack.org/wiki/Neutron/AdvancedServices). Vijay did an excellent job involving us in LBaaS in the SSL discussion. Thanks, Vijay!

I am wondering how the process is supposed to work between the two groups. There is a lot of overlap right now and decisions in the areas currently discussed in Advanced Services impact our operator requirements for load balancing a great deal. Kyle, I am wondering if you can provide some guidance what your vision is how LBaaS operator requirements get considered in other parts of Neutron.

Thanks,
German

From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Wednesday, April 30, 2014 5:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi Jorge!

+1 to everything you just said. In fact, I think you said essentially what I was trying to last week with 100% less drama.

I'll work to add workflows to my proposal, but please note it's late on a Wednesday and tomorrow's IRC meeting is awfully early in my time zone. I probably won't have workflow documentation done in time.

Thanks,
Stephen


On Wed, Apr 30, 2014 at 3:26 PM, Jorge Miramontes <jorge.miramontes at rackspace.com<mailto:jorge.miramontes at rackspace.com>> wrote:
Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as
you initials so I got confused. :)

Cheers,
--Jorge




On 4/30/14 5:17 PM, "Jorge Miramontes" <jorge.miramontes at RACKSPACE.COM<mailto:jorge.miramontes at RACKSPACE.COM>>
wrote:

>Hey everyone,
>
>I agree that we need to be preparing for the summit. Using Google docs
>mixed with Openstack wiki works for me right now. I need to become more
>familiar the gerrit process and I agree with Samuel that it is not
>conducive to "large" design discussions. That being said I'd like to add
>my thoughts on how I think we can most effectively get stuff done.
>
>As everyone knows there are many new players from across the industry that
>have an interest in Neutron LBaaS. Companies I currently see
>involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix,
>eBay/Paypal and Rackspace. We also have individuals involved as well. I
>echo Kyle's sentiment on the passion everyone is bringing to the project!
>Coming into this project a few months ago I saw that a few things needed
>to be done. Most notably, I realized that gathering everyone's
>expectations on what they wanted Neutron LBaaS to be was going to be
>crucial. Hence, I created the requirements document. Written requirements
>are important within a single organization. They are even more important
>when multiple organizations are working together because everyone is
>spread out across the world and every organization has a different
>development process. Again, my goal with the requirements document is to
>make sure that everyone's voice in the community is taken into
>consideration. The benefit I've seen from this document is that we ask
>"Why?" to each other, iterate on the document and in the end have a clear
>understanding of everyone's motives. We also learn from each other by
>doing this which is one of the great benefits of open source.
>
>Now that we have a set of requirements the next question to ask is, "How
>doe we prioritize requirements so that we can start designing and
>implementing them"? If this project were a completely new piece of
>software I would argue that we iterate on individual features based on
>anecdotal information. In essence I would argue an agile approach.
>However, most of the companies involved have been operating LBaaS for a
>while now. Rackspace, for example, has been operating LBaaS for the better
>part of 4 years. We have a clear understanding of what features our
>customers want and how to operate at scale. I believe other operators of
>LBaaS have the same understanding of their customers and their operational
>needs. I guess my main point is that, collectively, we have data to back
>up which requirements we should be working on. That doesn't mean we
>preclude requirements based on anecdotal information (i.e. "Our customers
>are saying they want new shiny feature X"). At the end of the day I want
>to prioritize the community's requirements based on factual data and
>anecdotal information.
>
>Assuming requirements are prioritized (which as of today we have a pretty
>good idea of these priorities) the next step is to design before laying
>down any actual code. I agree with Samuel that pushing the cart before the
>horse is a bad idea in this case (and it usually is the case in software
>development), especially since we have a pretty clear idea on what we need
>to be designing for. I understand that the current code base has been
>worked on by many individuals and the work done thus far is the reason why
>so many new faces are getting involved. However, we now have a completely
>updated set of requirements that the community has put together and trying
>to fit the requirements to existing code may or may not work. In my
>experience, I would argue that 99% of the time duct-taping existing code
>to fit in new requirements results in buggy software. That being said, I
>usually don't like to rebuild a project from scratch. If I can I try to
>refactor as much as possible first. However, in this case we have a
>particular set of requirements that changes the game. Particularly,
>operator requirements have not been given the attention they deserve.
>
>I think of Openstack as being cloud software that is meant to operate at
>scale and have the necessary operator tools to do so. Otherwise, why do we
>have so many companies interested in Openstack if you can't operate a
>cloud that scales? In the case of LBaaS, user/feature requirements and
>operator requirements are not necessarily mutually exclusive. How you
>design the system in regards to one set of requirements affects the design
>of the system in regards to the other set of requirements. SSL
>termination, for example, affects the ability to scale since it is CPU
>intensive. As an operator, I need to know how to provision load balancer
>instances efficiently so that I'm not having to order new hardware more
>than I have to. With this in mind, I am assuming that most of us are
>vendor-agnostic and want to cooperate in developing an open source driver
>while letting vendors create their own drivers. If this is not the case
>then perhaps a lot of the debates we have been having are moot since we
>can separate efforts depending on what driver we want to work on. The only
>item of Neutron LBaaS that we need to have consensus on then is the API
>(web app, database, messaging system, etc.). Keep in mind that the API
>implies what feature/user requirements are satisfied, but no so much for
>operator requirements. I think this is one reason why we have been working
>on API proposals. Samuel, thank you for the time you spent on your
>proposal as we know how much time and effort it takes.
>
>Because several of us have been spending large amounts of time on API
>proposals, and because we can safely assume that most operational
>requirements are abstracted into the driver layer I say we continue the
>conversation around the different proposals since this is the area we
>definitely need consensus on. So far there are three proposals--Stephen's,
>Rackspace's and Eugene's. To date, we honestly haven't had an actual
>discussion on the pros and cons of each proposal. To give structure to
>this we here at Rackspace have been going to great lengths to make sure we
>have enough tangible documentation in order to clearly convey our
>thoughts. We also went to great lengths to satisfy the user/feature
>requirements in our API. Here is what we have done:
>
>- An API specification located here ==>
>https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWy
>X
>e-zo/edit
>- Single API call workflows & multiple API call workflows of each of the
>use cases (#1 through #9 for now) from
>https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXu
>S
>INis/edit#heading=h.48fieovwttzg. Our workflows are located here ==>
>https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0
>- A lightweight proof of concept that is in the works so that people that
>need to actually send requests to an API to believe in it can do so. We
>will send an update in a few days when this POC is complete.
>
>In order to fairly compare proposals I think it would be nice if each
>proposal give workflows on how their API will operate. This is isn't
>necessary but I think it will definitely give structure in any discussions
>we have when comparing. If others have thoughts on how to compare the
>proposals on equal footing then by all means speak up.
>
>Once we come to a consensus on the API then we can figure out how to make
>iterative changes in order to get the API to the consensus state. That is
>a separate conversation in my mind. First we need to agree on a spec
>without the confines of looking at current implementation.
>
>
>Cheers,
>--Jorge
>
>
>P.S. Sorry for the delay in responding to the ML. Just reading them takes
>several hours.
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org<mailto: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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/4135f2ed/attachment-0001.html>