Re: [openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)
Hi Alan, Just wondering why the +1 for this. It would seem that a better way of doing this without what seems like a guaranteed method of disruption would be to run a neutron forge activity and integrate the work once it is proved stable and the impacts on existing functions can be well understood. Is there a good reason that the PDU thinks will help them to run it in this way? / Chris On 8/19/14, 11:05 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: +1 too, I do think the incubator is a good initiative and a compromise, I just hope it will not be a dumping ground for items that some don't feel are sufficient or don't have a high enough priority for some! /Alan -Original Message- From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] Sent: August-19-14 7:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting) +1 for neutron-labs! ;-) On Tue, Aug 19, 2014 at 10:35 AM, Stefano Maffulli stef...@openstack.org wrote: On 08/19/2014 08:39 AM, Eichberger, German wrote: Just to be clear: We all think the incubator is a great idea and if some things are ironed out will be a good way to onboard new projects to Neutron. What bothers me is the timing. Without warning we were put in an incubator in the span of like 8 days. No, not without warning: 8 days and we're still discussing the solution for code that has been developed by sub-teams and for which the core team has not reached consensus whether to merge it or not. As a reminder, until we started this discussion, the alternative for 'lack of consensus 3 days before feature freeze' was to leave code out of the tree. We've done it that way in the past. Incubator is a *proposal* to improve the situation, provide a way for code that is considered mature by a sub-team to be shipped to customers from a git.openstack.org repository (as opposed from somewhere else, as it happened in the past). The full details are on this wiki page: https://wiki.openstack.org/wiki/Network/Incubator This makes it difficult to plan and adds unnecessary uncertainty. Who is guaranteeing that if I tell my management LBaaS v2 will be in Kilo that nobody will throw a wrench in five months time? Great question! There is no simple answer: it's a risk everyone involved in OpenStack decides to run because that risk of a last minute wrench is balanced by the benefits of getting back a full working engine and spare parts, with manuals. That said, there are a lot of ways to mitigate that risk in any case. One is to pay attention to the priorities set by the project leaders and help them, first. Us, the people on this list, should be the ones explaining our managers what this OpenStack collaboration is all about. If it's not clear to you how, come to the Upstream Training sessions in Paris to get some ideas. https://wiki.openstack.org/wiki/OpenStack_Upstream_Training What I like to see from the Neutron Core team is timely communication with proper transition plans: For example if there is a change in how things are done it should be implemented at the beginning of a cycle and projects started before the change should have a grace period where things are done the old way. I understand that some things might have to be retroactively but that should be kept to a minimum - Yep, this is a very reasonable request. I think the that Neutron Core Team (and other teams, too) has space for improvements in the way they communicate to sub-teams and to the Foundation. This change comes too close to the end of the cycle, I agree and I think I understand the pain you're going through: it's bad. The only reason why I support this effort to change *now* is that the alternative to a new repository with LBaaSv2 code is more likely to be a 'no, come back for Kilo' (based on past experience). I find the 'no' to be unacceptable and 'yes' very unlikely. Incubator sounds like a good compromise. I'd focus our energies to addressing the shortcomings of the Incubator proposal. I, to start, would advocate for calling this repository 'Labs', a place where cool and interesting things are given a chance to be tried out and if they stick, users like them, moved to a more permanent home (or die). Incubator sound too much like something that needs maturing and it may not be the case (plus it sounds too burocratic, with rules to graduation, etc). The sooner we iron out the wrinkles in the proposal the sooner we start educating distributions that there is good code in there that they may want to package and ship to users. /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
[openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)
On 08/19/2014 08:39 AM, Eichberger, German wrote: Just to be clear: We all think the incubator is a great idea and if some things are ironed out will be a good way to onboard new projects to Neutron. What bothers me is the timing. Without warning we were put in an incubator in the span of like 8 days. No, not without warning: 8 days and we're still discussing the solution for code that has been developed by sub-teams and for which the core team has not reached consensus whether to merge it or not. As a reminder, until we started this discussion, the alternative for 'lack of consensus 3 days before feature freeze' was to leave code out of the tree. We've done it that way in the past. Incubator is a *proposal* to improve the situation, provide a way for code that is considered mature by a sub-team to be shipped to customers from a git.openstack.org repository (as opposed from somewhere else, as it happened in the past). The full details are on this wiki page: https://wiki.openstack.org/wiki/Network/Incubator This makes it difficult to plan and adds unnecessary uncertainty. Who is guaranteeing that if I tell my management LBaaS v2 will be in Kilo that nobody will throw a wrench in five months time? Great question! There is no simple answer: it's a risk everyone involved in OpenStack decides to run because that risk of a last minute wrench is balanced by the benefits of getting back a full working engine and spare parts, with manuals. That said, there are a lot of ways to mitigate that risk in any case. One is to pay attention to the priorities set by the project leaders and help them, first. Us, the people on this list, should be the ones explaining our managers what this OpenStack collaboration is all about. If it's not clear to you how, come to the Upstream Training sessions in Paris to get some ideas. https://wiki.openstack.org/wiki/OpenStack_Upstream_Training What I like to see from the Neutron Core team is timely communication with proper transition plans: For example if there is a change in how things are done it should be implemented at the beginning of a cycle and projects started before the change should have a grace period where things are done the old way. I understand that some things might have to be retroactively but that should be kept to a minimum - Yep, this is a very reasonable request. I think the that Neutron Core Team (and other teams, too) has space for improvements in the way they communicate to sub-teams and to the Foundation. This change comes too close to the end of the cycle, I agree and I think I understand the pain you're going through: it's bad. The only reason why I support this effort to change *now* is that the alternative to a new repository with LBaaSv2 code is more likely to be a 'no, come back for Kilo' (based on past experience). I find the 'no' to be unacceptable and 'yes' very unlikely. Incubator sounds like a good compromise. I'd focus our energies to addressing the shortcomings of the Incubator proposal. I, to start, would advocate for calling this repository 'Labs', a place where cool and interesting things are given a chance to be tried out and if they stick, users like them, moved to a more permanent home (or die). Incubator sound too much like something that needs maturing and it may not be the case (plus it sounds too burocratic, with rules to graduation, etc). The sooner we iron out the wrinkles in the proposal the sooner we start educating distributions that there is good code in there that they may want to package and ship to users. /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)
+1 for neutron-labs! ;-) On Tue, Aug 19, 2014 at 10:35 AM, Stefano Maffulli stef...@openstack.org wrote: On 08/19/2014 08:39 AM, Eichberger, German wrote: Just to be clear: We all think the incubator is a great idea and if some things are ironed out will be a good way to onboard new projects to Neutron. What bothers me is the timing. Without warning we were put in an incubator in the span of like 8 days. No, not without warning: 8 days and we're still discussing the solution for code that has been developed by sub-teams and for which the core team has not reached consensus whether to merge it or not. As a reminder, until we started this discussion, the alternative for 'lack of consensus 3 days before feature freeze' was to leave code out of the tree. We've done it that way in the past. Incubator is a *proposal* to improve the situation, provide a way for code that is considered mature by a sub-team to be shipped to customers from a git.openstack.org repository (as opposed from somewhere else, as it happened in the past). The full details are on this wiki page: https://wiki.openstack.org/wiki/Network/Incubator This makes it difficult to plan and adds unnecessary uncertainty. Who is guaranteeing that if I tell my management LBaaS v2 will be in Kilo that nobody will throw a wrench in five months time? Great question! There is no simple answer: it's a risk everyone involved in OpenStack decides to run because that risk of a last minute wrench is balanced by the benefits of getting back a full working engine and spare parts, with manuals. That said, there are a lot of ways to mitigate that risk in any case. One is to pay attention to the priorities set by the project leaders and help them, first. Us, the people on this list, should be the ones explaining our managers what this OpenStack collaboration is all about. If it's not clear to you how, come to the Upstream Training sessions in Paris to get some ideas. https://wiki.openstack.org/wiki/OpenStack_Upstream_Training What I like to see from the Neutron Core team is timely communication with proper transition plans: For example if there is a change in how things are done it should be implemented at the beginning of a cycle and projects started before the change should have a grace period where things are done the old way. I understand that some things might have to be retroactively but that should be kept to a minimum - Yep, this is a very reasonable request. I think the that Neutron Core Team (and other teams, too) has space for improvements in the way they communicate to sub-teams and to the Foundation. This change comes too close to the end of the cycle, I agree and I think I understand the pain you're going through: it's bad. The only reason why I support this effort to change *now* is that the alternative to a new repository with LBaaSv2 code is more likely to be a 'no, come back for Kilo' (based on past experience). I find the 'no' to be unacceptable and 'yes' very unlikely. Incubator sounds like a good compromise. I'd focus our energies to addressing the shortcomings of the Incubator proposal. I, to start, would advocate for calling this repository 'Labs', a place where cool and interesting things are given a chance to be tried out and if they stick, users like them, moved to a more permanent home (or die). Incubator sound too much like something that needs maturing and it may not be the case (plus it sounds too burocratic, with rules to graduation, etc). The sooner we iron out the wrinkles in the proposal the sooner we start educating distributions that there is good code in there that they may want to package and ship to users. /stef -- Ask and answer questions on https://ask.openstack.org ___ 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
