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.lo...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev