Open Stack

Yes.  There is an outside chance that someone can re-add the agent after
we get the agent-less driver in, for Juno, but if v2 is not going to be
the default extension, I’m not sure it’s worth the effort, since some
version of Octavia should land in Kilo, during which I would also expect
v2 to become the default.

Doug


On 7/29/14, 6:05 AM, "Kyle Mestery" <mestery at mestery.com> wrote:

>This all looks good to me. My only concern is that we need to land a
>driver in Juno as well. The HA-proxy based, agent-less driver which
>runs on the API node is the only choice here, right? Otherwise, the
>scalable work is being done in Octavia. Is that correct?
>
>On Mon, Jul 28, 2014 at 2:46 PM, Brandon Logan
><brandon.logan at rackspace.com> wrote:
>> That was essentially the point of my email.  To get across that not
>> everything we want to go in Juno will make it in and because of this V2
>> will not be in the state that many users will be able to use.  Also, to
>> get people's opinions on what they think is high priority.
>>
>> On Mon, 2014-07-28 at 18:11 +0000, Doug Wiegley wrote:
>>> 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/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GN
>>>>>>TOC
>>> >>>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
>>>
>>> _______________________________________________
>>> 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