Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we probably will need to worry about namespaces? Doug's suggestion to use a separate namespace to indicate that the incubator codebase isn’t fully supported is a good idea and what I had in mind as a non-technical reason for a new namespace. I still assert that the potential for path conflicts can be avoided easily enough, and is not a good reason on its own to use a different namespace. * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I¹m not sure it¹s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we probably will need to worry about namespaces? Doug's suggestion to use a separate namespace to indicate that the incubator codebase isn’t fully supported is a good idea and what I had in mind as a non-technical reason for a new namespace. I still assert that the potential
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very important. -Bob On 9/1/14, 9:05 AM, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Hello, 1. As dashboard, Horizon even does not support all stable OpenStack API ( including Neutron API ), not mention to unstable API 2. For incubation feature, the introduced API is not stable and not necessary for Horizon to support that. 3. The incubation feature could be experience by CLI/python client, but not in general delivery Horizon distribution. 4. If some customer asked the vendor to provide Horizon support for the incubation feature, the vendor can do the Horizon customization case by case, but no relationship with the general distribution of Horizon. Is the logical above reasonable? Best Regards Chaoyi Huang ( Joe Huang ) -邮件原件- 发件人: Robert Kukura [mailto:kuk...@noironetworks.com] 发送时间: 2014年9月1日 22:37 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very important. -Bob On 9/1/14, 9:05 AM, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Is it possible to have a /contrib folder or something similar where experimental modules can be placed? Requiring a separate Horizon distribution for every project in the incubator is really going to make it difficult to get users to try them out. On Mon, Sep 1, 2014 at 6:39 PM, joehuang joehu...@huawei.com wrote: Hello, 1. As dashboard, Horizon even does not support all stable OpenStack API ( including Neutron API ), not mention to unstable API 2. For incubation feature, the introduced API is not stable and not necessary for Horizon to support that. 3. The incubation feature could be experience by CLI/python client, but not in general delivery Horizon distribution. 4. If some customer asked the vendor to provide Horizon support for the incubation feature, the vendor can do the Horizon customization case by case, but no relationship with the general distribution of Horizon. Is the logical above reasonable? Best Regards Chaoyi Huang ( Joe Huang ) -邮件原件- 发件人: Robert Kukura [mailto:kuk...@noironetworks.com] 发送时间: 2014年9月1日 22:37 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very important. -Bob On 9/1/14, 9:05 AM, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
It would satisfy everyone if horizon support all APIs, either in tree or in the lab, but at the perquisite that we have enough resource for horizon. Else for the limitation of resource, we have to sort by the priority, then should we focus on APIs being baked in the incubator first? From: Kevin Benton [blak...@gmail.com] Sent: Tuesday, September 02, 2014 9:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Is it possible to have a /contrib folder or something similar where experimental modules can be placed? Requiring a separate Horizon distribution for every project in the incubator is really going to make it difficult to get users to try them out. On Mon, Sep 1, 2014 at 6:39 PM, joehuang joehu...@huawei.commailto:joehu...@huawei.com wrote: Hello, 1. As dashboard, Horizon even does not support all stable OpenStack API ( including Neutron API ), not mention to unstable API 2. For incubation feature, the introduced API is not stable and not necessary for Horizon to support that. 3. The incubation feature could be experience by CLI/python client, but not in general delivery Horizon distribution. 4. If some customer asked the vendor to provide Horizon support for the incubation feature, the vendor can do the Horizon customization case by case, but no relationship with the general distribution of Horizon. Is the logical above reasonable? Best Regards Chaoyi Huang ( Joe Huang ) -邮件原件- 发件人: Robert Kukura [mailto:kuk...@noironetworks.commailto:kuk...@noironetworks.com] 发送时间: 2014年9月1日 22:37 收件人: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very important. -Bob On 9/1/14, 9:05 AM, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.commailto:ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.commailto:pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.commailto:ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.commailto:pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.commailto:ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com mailto:ihrac...@redhat.commailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Definitely don't prioritize it. I was just saying that people developing these would probably be happy to do all of the development and testing. Is the resource limitation in Horizon on the reviewer side or the code contribution side? I'm sure there are people familiar with Neutron that would be happy to help with developing the missing stable neutron features you mentioned. On Mon, Sep 1, 2014 at 8:16 PM, Wuhongning wuhongn...@huawei.com wrote: It would satisfy everyone if horizon support all APIs, either in tree or in the lab, but at the perquisite that we have enough resource for horizon. Else for the limitation of resource, we have to sort by the priority, then should we focus on APIs being baked in the incubator first? -- *From:* Kevin Benton [blak...@gmail.com] *Sent:* Tuesday, September 02, 2014 9:55 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Is it possible to have a /contrib folder or something similar where experimental modules can be placed? Requiring a separate Horizon distribution for every project in the incubator is really going to make it difficult to get users to try them out. On Mon, Sep 1, 2014 at 6:39 PM, joehuang joehu...@huawei.com wrote: Hello, 1. As dashboard, Horizon even does not support all stable OpenStack API ( including Neutron API ), not mention to unstable API 2. For incubation feature, the introduced API is not stable and not necessary for Horizon to support that. 3. The incubation feature could be experience by CLI/python client, but not in general delivery Horizon distribution. 4. If some customer asked the vendor to provide Horizon support for the incubation feature, the vendor can do the Horizon customization case by case, but no relationship with the general distribution of Horizon. Is the logical above reasonable? Best Regards Chaoyi Huang ( Joe Huang ) -邮件原件- 发件人: Robert Kukura [mailto:kuk...@noironetworks.com] 发送时间: 2014年9月1日 22:37 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective Sure, Horizon (or Heat) support is not always required for new features entering incubation, but when a goal in incubating a feature is to get it packaged with OpenStack distributions and into the hands of as many early adopters as possible to gather feedback, these integrations are very important. -Bob On 9/1/14, 9:05 AM, joehuang wrote: Hello, Not all features which had already been shipped in Neutron supported by Horizon. For example, multi provider network. This is not the special case only happened in Neutron. For example, Glance delivered V2 api in IceHouse or even early and support Image muti-locations feature, but this feature also not available from Horizon. Fortunately, the CLI/python client can give us the opportunity to use this powerful feature. So, It's not necessary to link Neutron incubation with Horizon tightly. The feature implemented in Horizon can be introduced when the the incubation graduate. Best regards. Chaoyi Huang ( joehuang ) 发件人: Maru Newby [ma...@redhat.com] 发送时间: 2014年9月1日 17:53 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On 08/21/2014 03:12 AM, Ihar Hrachyshka wrote: I wonder where discussion around the proposal is running. Is it public? Yes, it's public, and this thread is part of it. Look at the dates of the wiki: this is a recent proposal (first appearance Aug 11), came out to address the GBP issue, quickly iterated over a couple of IRC neutron meetings, and quick phone calls to get early feedback from the GBP team, Octavia and a few others. Though the way incubator is currently described in that proposal on the wiki doesn't clearly imply similar benefits for the project, hence concerns. The rationale for the separate repository is that Neutron's code needs a lot of love for the *existing* codebase, before new features can be added (and before core team can accept more responsibilities for it). But progress is unstoppable: new features are being proposed every cycle and reviewers bandwidth is not infinite. That's the gist of 'Mission' and 'Why a Seperate Repo?' on https://wiki.openstack.org/wiki/Network/Incubator Of course, we should raise the bar for all the code - already merged, in review, and in incubator. I just think there is no reason to make those requirements different from general acceptance requirements (do we have those formally defined?). yes, there is a reason to request higher standards for any new code, why wouldn't there be? If legacy code is struggling to improve test coverage, there is a very good reason not to accept more debt. Not sure it's spelled out and where but I believe it's an accepted and shared best practice among core reviewers not to merge code without tests. /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] [neutron] Incubator concerns from packaging perspective
On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we probably will need to worry about namespaces? Doug's suggestion to use a separate namespace to indicate that the incubator codebase isn’t fully supported is a good idea and what I had in mind as a non-technical reason for a new namespace. I still assert that the potential for path conflicts can be avoided easily enough, and is not a good reason on its own to use a different namespace. * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I¹m not sure it¹s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On 8/26/14, 4:49 AM, Maru Newby ma...@redhat.com wrote: On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) pkila...@cisco.com wrote: On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we probably will need to worry about namespaces? Doug's suggestion to use a separate namespace to indicate that the incubator codebase isn’t fully supported is a good idea and what I had in mind as a non-technical reason for a new namespace. I still assert that the potential for path conflicts can be avoided easily enough, and is not a good reason on its own to use a different namespace. * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I¹m not sure it¹s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1:
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Sun, Aug 24, 2014 at 5:09 PM, Luke Gorrie l...@tail-f.com wrote: On 21 August 2014 12:12, Ihar Hrachyshka ihrac...@redhat.com wrote: Let the ones that are primarily interested in good quality of that code (vendors) to drive development. And if some plugins become garbage, it's bad news for specific vendors; if neutron screws because of lack of concentration on core features and open source plugins, everyone is doomed. Completely agree with this sentiment. Is there a crisp distinction between a vendor plugin and an open source plugin though? This topic is interesting: should all opensource backend drivers be put into the tree? But as Kyle has mentioned earlier, Incubator is not the place to discuss in-tree / out-tree for 3rd vs. built-in drivers, but the place to bake newly introduced API and resource model for fast iteration, so I'll forward this topic in another thread. The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks like a vendor plugin but is actually completely open source. The development is driven by end-user organisations who want to make the standard upstream Neutron support their NFV use cases. We are looking for a good way to engage with the upstream community. In this cycle we have found kindred spirits in the NFV subteam., but we did not find a good way to engage with Neutron upstream (see https://review.openstack.org/#/c/116476/). It would be wonderful if there is a suitable process available for us to use in Kilo e.g. incubation. Cheers, -Luke ___ 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
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On 8/23/14, 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don¹t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). From what I understand there can be overlapping code between neutron and incubator to override/modify existing python/config files. In which case, packaging(for Eg: rpm) will raise a path conflict. So we probably will need to worry about namespaces? * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I¹m not sure it¹s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on changes to the Neutron (core) repository before progress can be made in the incubator. +1 I agree that it would be in an incubated effort¹s best interest to put off doing invasive changes to the Neutron tree as long as possible to ensure
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don’t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). If the point of the incubator is to signal to deployers that the code isn’t fully supported, you may want to use a different namespace for the python/system packages as well. Doug * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I’m not sure it’s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on changes to the Neutron (core) repository before progress can be made in the incubator. +1 I agree that it would be in an incubated effort’s best interest to put off doing invasive changes to the Neutron tree as long as possible to ensure sufficient time to hash out the best
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
+1 I agree with Pradeep and Doug that a new namespace makes for a better structure for packaging and usage. Regards, Mandeep - On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann d...@doughellmann.com wrote: On Aug 23, 2014, at 5:36 PM, Maru Newby ma...@redhat.com wrote: On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don’t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). If the point of the incubator is to signal to deployers that the code isn’t fully supported, you may want to use a different namespace for the python/system packages as well. Doug * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I’m not sure it’s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On 21 August 2014 12:12, Ihar Hrachyshka ihrac...@redhat.com wrote: Let the ones that are primarily interested in good quality of that code (vendors) to drive development. And if some plugins become garbage, it's bad news for specific vendors; if neutron screws because of lack of concentration on core features and open source plugins, everyone is doomed. Completely agree with this sentiment. Is there a crisp distinction between a vendor plugin and an open source plugin though? The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks like a vendor plugin but is actually completely open source. The development is driven by end-user organisations who want to make the standard upstream Neutron support their NFV use cases. We are looking for a good way to engage with the upstream community. In this cycle we have found kindred spirits in the NFV subteam., but we did not find a good way to engage with Neutron upstream (see https://review.openstack.org/#/c/116476/). It would be wonderful if there is a suitable process available for us to use in Kilo e.g. incubation. Cheers, -Luke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. I don’t think there is a technical requirement to choose a new namespace. Python supports sharing a namespace, and packaging can support this feature (see: oslo.*). * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. Given that it is possible to specify a dependency as a branch/hash/tag in a git repo [1], I’m not sure it’s worth figuring out how to target tarballs. Master branch of the incubation repo could then target the master branch of the Neutron repo and always be assured of being current, and then released versions could target milestone tags or released versions. 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on changes to the Neutron (core) repository before progress can be made in the incubator. +1 I agree that it would be in an incubated effort’s best interest to put off doing invasive changes to the Neutron tree as long as possible to ensure sufficient time to hash out the best approach. * Packaging of ancillary code (CLI, Horizon, Heat): We start by adding these as subdirectories inside each feature. The packaging folks are going to find it difficult to package this. However, can we start with this approach, and have a parallel discussion
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Aug 20, 2014, at 6:28 PM, Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them. If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage). 3. The fact that neutron-incubator is not going to maintain any stable branches for security fixes and major failures concerns me too. In downstream, we don't generally ship the latest and greatest from PyPI. Meaning, we'll need to maintain our own downstream stable branches for major fixes. [BTW we already do that for python clients.] This is a valid point. We need to find an appropriate trade off. My thinking was that incubated projects could be treated just like client libraries from a branch perspective. 4. Another unclear part of the proposal is that notion of keeping Horizon and client changes required for incubator features in neutron-incubator. AFAIK the repo will be governed by Neutron Core team, and I doubt the team is ready to review Horizon changes (?). I think I don't understand how we're going to handle that. Can we just postpone Horizon work till graduation? I too do not think it's a great idea, mostly because there will be horizon bits not shipped with horizon, and not verified by horizon core team. I think it would be ok to have horizon support for neutron incubator. It won't be the first time that support for experimental features is added in horizon. 5. The wiki page says that graduation will require full test coverage. Does it mean 100% coverage in 'coverage' report? I don't think our existing code is even near that point, so maybe
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. In the spirit of keeping the discussion going, I think we probably need to iterate in practice on this idea a little bit before we can crystallize on the policy and process for this new repo. Here are few ideas on how we can start this iteration: * Namespace for the new repo: Should this be in the neutron namespace, or a completely different namespace like neutron labs? Perhaps creating a separate namespace will help the packagers to avoid issues of conflicting package owners of the namespace. * Dependency on Neutron (core) repository: We would need to sort this out so that we can get UTs to run and pass in the new repo. Can we set the dependency on Neutron milestone releases? We already publish tar balls for the milestone releases, but I am not sure we publish these as packages to pypi. If not could we start doing that? With this in place, the incubator would always lag the Neutron core by at the most one milestone release. * Modules overlapping with the Neutron (core) repository: We could initially start with the features that required very little or no changes to the Neutron core, to avoid getting into the issue of blocking on changes to the Neutron (core) repository before progress can be made in the incubator. * Packaging of ancillary code (CLI, Horizon, Heat): We start by adding these as subdirectories inside each feature. The packaging folks are going to find it difficult to package this. However, can we start with this approach, and have a parallel discussion on how we can evolved this strategy? Perhaps the individual projects might decide to allow support for the Neutron incubator features once they can actually see what goes into the incubator, and/or other projects might also follow the incubator approach. If we have loose consensus on the above, some of us folks who are involved with features that are candidates for the incubator (e.g. GBP, LBaaS), can immediately start iterating on this plan, and report back our progress in a specified time frame. Thanks, ~Sumit. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Thu, Aug 21, 2014 at 12:28 AM, Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them. If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage). It's also unfair that core team reviewers are forced to spend time on 3rd plugins and drivers under existing process. There are so many 3rd networking backend technologies, from hardware to controller, anyone can submit plugins and drivers to the tree, and for the principle of neutrality we can't agree some and refuse others' reviewing request. Then reviewers' time slot are full of these 3rd backend related work, leaving less time on the most important and urgent thing: improve Neutron core architecture to the same mature level like Nova as soon as possible. 3. The fact that neutron-incubator is not going to maintain any stable branches for security fixes and major failures concerns me too. In downstream, we don't generally ship the latest and greatest from PyPI. Meaning, we'll need to maintain our own downstream stable branches for major fixes. [BTW we already do that for python clients.] This is a valid point. We need to find an appropriate trade off. My thinking was that incubated projects could be treated just like client libraries from a branch perspective. 4. Another unclear part of the proposal is that notion of keeping Horizon and client changes required for incubator features in neutron-incubator. AFAIK the repo will be governed by Neutron Core team, and I doubt the team is ready to review Horizon changes (?). I think I don't understand how we're going to handle that. Can we
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them. If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage). I agree with that. I actually think that moving vendor plugins outside the main tree AND rearranging review permissions and obligations should be extremely beneficial to the community. I'm totally for that as quick as possible (Kilo please!) Reviewers waste their time reviewing plugins that are in most cases interesting for a tiny fraction of operators. Let the ones that are primarily interested in good quality of that code (vendors) to drive development. And if some plugins become garbage, it's bad news for specific vendors; if neutron screws because of lack of concentration on core features and open source plugins, everyone is doomed. Of course, splitting vendor plugins into separate repositories will make life of packagers a bit harder, but the expected benefits from such move are huge, so - screw packagers on this one. :) Though the way incubator is currently described in that proposal on the wiki doesn't clearly imply similar benefits for the project, hence concerns. 3. The fact that neutron-incubator is not going to maintain any stable branches for security fixes and major failures concerns me too. In downstream, we don't generally ship the latest and greatest from PyPI. Meaning, we'll need to maintain our own downstream stable branches for major fixes. [BTW we already do that for python clients.]
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/08/14 08:33, loy wolfe wrote: It's also unfair that core team reviewers are forced to spend time on 3rd plugins and drivers under existing process. There are so many 3rd networking backend technologies, from hardware to controller, anyone can submit plugins and drivers to the tree, and for the principle of neutrality we can't agree some and refuse others' reviewing request. Then reviewers' time slot are full of these 3rd backend related work, leaving less time on the most important and urgent thing: improve Neutron core architecture to the same mature level like Nova as soon as possible. Don't get me wrong on this. I'm totally in favour of splitting plugins into separate repos with dedicated (vendor?) core teams. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT9ceUAAoJEC5aWaUY1u57BqgIAJ0fLgSGxAknvm7eY1q0k3rH FHR1ObdW5TKOmVZHf5eNn/r/MmLH6DQhZhL+UV8XKcaKQ+HWjbXk4E0TqCPE1L5N DdYc9MTJLsXUUiOHLl3XDiZEsbB3T9rli5EbnQs28XTyMGWkG8YIJ90hCRJsvFk9 kWtlYPnxGTp9vMauvvqVU8rndoCTpUSK/AY8Cp/wgtOZ6ReGKQgduTL0RNo2xSWw sge600M7yugLOuefCVdpeGnJ13h0JUzd3hHcPIskqayykZWQg2e7eUXHI96DS6FM fEEUi0kGEpLvk7EdwVPuI2qm9HzVoQPJSY5E1HsXum6pAU5+O7LYo1YFPThHJGE= =XJgz -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/08/14 18:28, Salvatore Orlando wrote: Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. I wonder where discussion around the proposal is running. Is it public? The discussion started out privately as the incubation proposal was put together, but it's now on the mailing list, in person, and in IRC meetings. Lets keep the discussion going on list now. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them. If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage). I agree with that. I actually think that moving vendor plugins outside the main tree AND rearranging review permissions and obligations should be extremely beneficial to the community. I'm totally for that as quick as possible (Kilo please!) Reviewers waste their time reviewing plugins that are in most cases interesting for a tiny fraction of operators. Let the ones that are primarily interested in good quality of that code (vendors) to drive development. And if some plugins become garbage, it's bad news for specific vendors; if neutron screws because of lack of concentration on core features and open source plugins, everyone is doomed. Of course, splitting vendor plugins into separate repositories will make life of packagers a bit harder, but the expected benefits from such move are huge, so - screw packagers on this one. :) Though the way incubator is currently described in that proposal on the wiki doesn't clearly imply similar benefits for the project, hence concerns. Lets not confuse the incubator with moving drivers out of tree. The two proposals
[openstack-dev] [neutron] Incubator concerns from packaging perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). 3. The fact that neutron-incubator is not going to maintain any stable branches for security fixes and major failures concerns me too. In downstream, we don't generally ship the latest and greatest from PyPI. Meaning, we'll need to maintain our own downstream stable branches for major fixes. [BTW we already do that for python clients.] 4. Another unclear part of the proposal is that notion of keeping Horizon and client changes required for incubator features in neutron-incubator. AFAIK the repo will be governed by Neutron Core team, and I doubt the team is ready to review Horizon changes (?). I think I don't understand how we're going to handle that. Can we just postpone Horizon work till graduation? 5. The wiki page says that graduation will require full test coverage. Does it mean 100% coverage in 'coverage' report? I don't think our existing code is even near that point, so maybe it's not fair to require that from graduated code. A separate tree would probably be reasonable if it would be governed by a separate team. But as it looks now, it's still Neutron Cores who will do the review heavy-lifting. So I wonder why not just applying different review rules for patches for core and the staging subtree. [1]: https://wiki.openstack.org/wiki/Network/Incubator [2]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT9MDpAAoJEC5aWaUY1u57bYAH/0LsZonj3zVmWomUBBPriUOm GRoNBHq6C7BCfO7gRnQQyRd/N4jCL4Y1Dfbfv2Ypulsgf0x+ugvmzOrWm2Sa7KiS F3adumx+0OjJSMb5SSOxZQHpsZFjJmwtJjat9vwOYFXcCXhn8r9AgN3TPm5GyZ29 NPY+SQdqu+G/ZgXd94sE2+gGbx0H5nLZusJD0yiUpoNExhv4qvjHSZW1rwssb+Ac 3dU3LU1FqhM7UxkgnWk6AGYHfLjr5CfxXBrmikQsxXljl8Sko9DBTpKa3YtVcBX1 FdMWLGn13nFNasGAKHot/aRfmdfPIzN0TsjjfRstm0W1VLvvbQjLxGTQDEyey/U= =vdaC -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective
Some comments inline. Salvatore On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I've read the proposal for incubator as described at [1], and I have several comments/concerns/suggestions to this. Overall, the idea of giving some space for experimentation that does not alienate parts of community from Neutron is good. In that way, we may relax review rules and quicken turnaround for preview features without loosing control on those features too much. Though the way it's to be implemented leaves several concerns, as follows: 1. From packaging perspective, having a separate repository and tarballs seems not optimal. As a packager, I would better deal with a single tarball instead of two. Meaning, it would be better to keep the code in the same tree. I know that we're afraid of shipping the code for which some users may expect the usual level of support and stability and compatibility. This can be solved by making it explicit that the incubated code is unsupported and used on your user's risk. 1) The experimental code wouldn't probably be installed unless explicitly requested, and 2) it would be put in a separate namespace (like 'preview', 'experimental', or 'staging', as the call it in Linux kernel world [2]). This would facilitate keeping commit history instead of loosing it during graduation. Yes, I know that people don't like to be called experimental or preview or incubator... And maybe neutron-labs repo sounds more appealing than an 'experimental' subtree in the core project. Well, there are lots of EXPERIMENTAL features in Linux kernel that we actively use (for example, btrfs is still considered experimental by Linux kernel devs, while being exposed as a supported option to RHEL7 users), so I don't see how that naming concern is significant. I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. 2. If those 'extras' are really moved into a separate repository and tarballs, this will raise questions on whether packagers even want to cope with it before graduation. When it comes to supporting another build manifest for a piece of code of unknown quality, this is not the same as just cutting part of the code into a separate experimental/labs package. So unless I'm explicitly asked to package the incubator, I wouldn't probably touch it myself. This is just too much effort (btw the same applies to moving plugins out of the tree - once it's done, distros will probably need to reconsider which plugins they really want to package; at the moment, those plugins do not require lots of time to ship them, but having ~20 separate build manifests for each of them is just too hard to handle without clear incentive). One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them. If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage). 3. The fact that neutron-incubator is not going to maintain any stable branches for security fixes and major failures concerns me too. In downstream, we don't generally ship the latest and greatest from PyPI. Meaning, we'll need to maintain our own downstream stable branches for major fixes. [BTW we already do that for python clients.] This is a valid point. We need to find an appropriate trade off. My thinking was that incubated projects could be treated just like client libraries from a branch perspective. 4. Another unclear part of the proposal is that notion of keeping Horizon and client changes required for incubator features in neutron-incubator. AFAIK the repo will be governed by Neutron Core team, and I doubt the team is ready to review Horizon changes (?). I think I don't understand how we're going to handle that. Can we just postpone Horizon work till graduation? I too do not think it's a great idea, mostly because there will be horizon bits not shipped with horizon, and not verified by horizon core team. I think it would be ok to have horizon support for neutron incubator. It won't be the first time that support for experimental features is added in horizon. 5. The wiki page says that graduation will require full test coverage. Does it mean 100% coverage in 'coverage' report? I don't think our existing code is even near that point, so maybe it's not fair to require that from graduated code. I agree that by these standards we should take the whole neutron and return
