Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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.lo...@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 +, 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.miramon...@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 do...@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,
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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 mest...@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.lo...@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 +, 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.miramon...@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 do...@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
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
Just to put my $0.02 in: While it's a little disappointing that we won't get everything into Juno that we'd like, I think the effort this team has put into getting us to where we are is laudable. Although I would really like to see L7 land as well, I have no problem with the prioritization as laid out by Brandon and Doug, eh. We have to be realistic, after all, eh. I do want to emphasize that while Octavia will certainly be taking off in a big way once most of the Neutron LBaaS stuff is buttoned up, it's still really important that those of y'all with cycles to devote to this should still be working to either code or review code for Neutron LBaaS (at least until the August 21st deadline, but probably several weeks afterward to get bugfixes etc. written and through review). I have been purposely de-emphasizing Octavia accordingly. But I see that it's starting to become important to at least have the design and direction documented (so that it's clear where this project is going to go, at least in the short to medium term). I'll be spending time this week working on this documentation (converting from google docs to something reviewable in Gerrit). I'll let y'all know when that's going to be ready for comment. Stephen On Tue, Jul 29, 2014 at 9:18 AM, Doug Wiegley do...@a10networks.com wrote: 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 mest...@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.lo...@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 +, 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.miramon...@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 do...@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,
[openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GNTOCTHcvbkA 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
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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 do...@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.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
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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.miramon...@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 do...@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
Re: [openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno
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 +, 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.miramon...@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 do...@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,
