Open Stack

I don’t think the lbaas roadmap has changed (including octavia), just the
delivery timeline.  Nor am I debating making the ref driver simpler (I’m
on record as supporting that decision, and still do.)  And if that was the
only wart, I’m sure we’d all ignore it and plow forward.  But it’s not,
and add all the things that are likely to miss together, and I think we’d
be doing the community a disservice by pushing v2 too soon.  Which means
our moratorium on v1 is likely premature.

Unless Brandon gives up sleeping altogether; then I’m sure we’ll make it.

Anyway, all this is my long-winded way of agreeing that some things will
likely need to be pushed to K, it happens, and let’s just be realistic
about what that means for our end users.

Doug



On 7/28/14, 9:34 AM, "Jorge Miramontes" <jorge.miramontes at RACKSPACE.COM>
wrote:

>Hey Doug,
>
>In terms of taking a step backward from a user perspective I'm fine with
>making v1 the default. I think there was always the notion of supporting
>what v1 currently offers by making a config change. Thus, Horizon should
>still have all the support it had in Icehouse. I am a little worried about
>the delivery of items we said we wanted to deliver however. The reason we
>are focusing on the current items is that Octavia is also part of the
>picture, albeit, behind the scenes right now. Thus, the argument that the
>new reference driver is less capable is actually a means to getting
>Octavia out. Eventually, we were hoping to get Octavia as the reference
>implementation which, from the user's perspective, will be much better
>since you can actually run it at operator scale. To be realistic, the v2
>implementation is a WIP and focusing on the control plane first seems to
>make the most sense. Having a complete end-to-end v2 implementation is
>large in scope and I don't think anyone expected it to be a full-fledged
>product by Juno, but we are getting closer!
>
>
>Cheers,
>--Jorge
>
>
>
>
>On 7/28/14 8:02 AM, "Doug Wiegley" <dougw at a10networks.com> wrote:
>
>>Hi Brandon,
>>
>>Thanks for bringing this up. If you¹re going to call me out by name, I
>>guess I have to respond to the Horizon thing.  Yes, I don¹t like it, from
>>a user perspective.  We promise a bunch of new features, new driversŠ and
>>none of them are visible.  Or the horizon support does land, and suddenly
>>the user goes from a provider list of 5 to 2.  Sucks if you were using
>>one
>>of the others.  Anyway, back to a project status.  To summarize, listed
>>by
>>feature, priority, status:
>>
>>LBaaS V2 API,   high, reviews in gerrit
>>Ref driver,     high, removed agent, review in gerrit
>>CLI V2,         high, not yet in review
>>Devstack,       high, not started
>>+TLS,           medium, lots done in parallel
>>+L7,            medium, not started
>>Shim V1 -> V2,  low, minimally complete
>>Horizon V2,     low, not started
>>ref agent,      low, not started
>>Drivers,        low, one vendor driver in review, several in progress
>>
>>And with a review submission freeze of August 21st.  Let¹s work
>>backwards:
>>
>>Dependent stuff will need at least two weeks to respond to the final
>>changes and submit.  That¹d be:
>>
>>Devstack,       high, not started
>>+TLS,           medium, lots done in parallel
>>+L7,            medium, not started
>>Shim V1 -> V2,  low, minimally complete
>>Horizon V2,     low, not started
>>ref agent,      low, not started
>>Drivers,        low, one vendor driver in review, several in progress
>>
>>Š I¹m not including TLS, since it¹s work has been very parallel so far,
>>even though logically it should be there.  But that would mean the
>>following should be ³done² and merged by August 7th:
>>
>>LBaaS V2 API,   high, reviews in gerrit
>>Ref driver,     high, removed agent, review in gerrit
>>CLI V2,         high, not yet in review
>>
>>Š that¹s a week and a half, for a big pile of new code.  At the current
>>change velocity, I have my doubts.  And if that slips, the rest starts to
>>look very very hazy.  Backing up, and focusing on the user, here¹s lbaas
>>v1:
>>
>>
>>
>>
>>- Current object model, basic http lb
>>- Ref driver with agent, +3 vendors (with +3 more backends not submitting
>>drivers because of v2)
>>- UI
>>
>>Š what we initially planned for Juno:
>>
>>- Shiny new object model (base for some new features)
>>- TLS termination/offload
>>- L7 routing
>>- Ref driver with agent, support old drivers, support new drivers
>>- UI, new and improved
>>
>>Š what we¹re now thinking of shipping:
>>
>>- Shiny new object model (base for some new features)
>>- TLS termination/offload
>>- Ref driver no agent, between 0-2 vendor drivers
>>- No UI
>>
>>So people get one new feature, a reference backend that is even less
>>production ready, no UI, and fewer providers. That seems like a step
>>backwards from a user perspective (at least from the non-huge operator
>>with a custom UI and custom driver perspective), not forward. And that
>>implies we need to rethink two decisions:
>>
>>- Having the V2 lbaas stuff be the default service extension/plugin
>>- Not supporting or reviewing new v1 drivers
>>
>>I think that we either need to deliver a more complete feature set, or
>>admit this thing needs to be experimental/not the default, and give a
>>little more attention to giving support to the default.
>>
>>Thanks,
>>doug
>>
>>
>>
>>
>>
>>On 7/28/14, 12:42 AM, "Brandon Logan" <brandon.logan at RACKSPACE.COM>
>>wrote:
>>
>>>There is going to be a mad rush to get many things into Neutron for Juno
>>>here in the last few weeks.  Neutron is overly saturated with code
>>>reviews.  So I'd like to list out some of the things LBaaS had planned
>>>for Juno, what the status each of those are, and my thoughts on the
>>>feasibility of actually getting it into Juno.  I'm just trying to have
>>>realistic expectations.  Please share any items I missed and any
>>>thoughts you have.  Kyle, if you have anything to add, I'd really love
>>>to hear that.  Even if its just agreeing.
>>>
>>>1. Code for LBaaS V2 API with reference implementation
>>>
>>>This is the most important piece and it should definitely get in.  The
>>>problem is that there is a TON of code for it which will likely push
>>>other things we really want out of Juno.  This is the top priority, and
>>>I'm sure everyone will agree.  Kyle, since the entire code review chain
>>>is up, with reference implementation, do you think you and other core
>>>reviewers can take a good look at it?
>>>
>>>2. CLI for LBaaS V2 API
>>>
>>>Craig Tracey has been working on this and I believe he is on track to
>>>get this in Juno.  Let me know if you feel otherwise Craig.
>>>
>>>3. Docs for LBaaS V2 API
>>>
>>>Min, I see you got the docs accepted into api-sites:
>>>
>>>https://review.openstack.org/#/c/106434/
>>>
>>>That's great! I do have some concerns, though, because I see some
>>>discrepancies with that and the google doc we have that has been updated
>>>to be exactly (or nearly) of what the API expects.  Google doc is here:
>>>
>>>https://docs.google.com/document/d/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GNTOC
>>>T
>>>H
>>>cvbkA
>>>
>>>Min, if we could get the api-sites updated for Juno that would be great.
>>>Oh and send us a link to the review so we can all look it over :).
>>>Thanks!
>>>
>>>
>>>4. Tempest tests for LBaaS V2 API
>>>
>>>Miguel is currently working on these.  Miguel do you expect these to be
>>>done in time?
>>>
>>>5. Shim layers for V2 API to V1 drivers
>>>
>>>This one I don't see landing in Juno.  I just think there is too much
>>>code going in for LBaaS that has a higher priority for this to make it
>>>in.  Plus, it really hasn't been worked on in a while.  This is just my
>>>opinion, though.  Hopefully, we won't need this for Kilo.
>>>
>>>6. Horizon - LBaaS V2 API
>>>
>>>This I do not see happening for Juno.  It could happen but I don't know
>>>of anyone who has even talked about doing this.  I'm reluctantly okay
>>>with it not making it into Juno because V2 API will kind of be in a beta
>>>state in my opinion since there won't be very much driver support,
>>>especially without a shim layer.  I suggest this goes in Kilo. I know
>>>some won't like this though (I'm looking at you doug).
>>>
>>>7. Devstack for LBaaS V2 API
>>>
>>>The only changes devstack would need for this piece is to just change
>>>the config.  However, I have not worked on this piece myself and didn't
>>>think of it as a high priority for Juno.  If someone has or wants to
>>>tackle that, please let us know.  Otherwise, move it to Kilo.
>>>
>>>8. HAProxy Agent driver
>>>
>>>Since we decided to go with a simpler agentless driver that only runs on
>>>the API node and is not scalable at all, the agent driver part still
>>>needs to be completed.  I definitely don't see this going into Juno
>>>because other higher priorities should get in first.  I suggest this
>>>gets in Kilo.
>>>
>>>8. TLS for LBaaS V2 API
>>>
>>>Evgeny is doing this one. I think this is a top priority for us and we
>>>all want this in Juno.  It depends on #1 getting in as well.  If #1
>>>doesn't get in, we have bigger issues.  I am hopeful that this will get
>>>in for Juno, as I think it should be our #2 priority Neutron LBaaS.
>>>
>>>9. Docs, CLI, Tempest tests, and Devstack for TLS
>>>
>>>Evgeny, are these being worked on in tandem?
>>>Devstack is definitely going to require some other changes for use of
>>>haproxy 1.5.
>>>
>>>10. L7 for LBaaS V2 API
>>>
>>>This is the 3rd priority for Neutron LBaaS in my opinion.  I am not
>>>certain that this will get in Juno.  Can we get updates on this?
>>>
>>>
>>>I think that about covers it.  Sorry for the long email.
>>>
>>>Thanks,
>>>Brandon
>>>
>>>
>>>_______________________________________________
>>>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