Open Stack

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/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GNTOCTH
>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