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 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#gi > >>>>> t > >>>>>> * 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. > >>>> > >>>> This is ok from development perspective, but from packaging stand > >>>> point having a whole neutron tree as part of incubator could raise > >>>> some concerns for distributions. We should ensure to indicate this > >>>> is an experimental neutron and not core very explicitly and > >>>> alleviate any support concerns. > >>> Who said anything about duplicating a whole neutron tree in incubator? > >>> The new repo is intended to be a place to develop new features that > >>> can be deployed alongside the main tree, and when changes need to be > >>> made to the main tree the place to do it is in…the main tree. Plus, > >>> it would be a nightmare to reintegrate an incubator feature that > >>> wasn’t strictly additive. > >>> > >>>> > >>>>>> * 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. > >>>>> Maybe I¹m missing something, but aren¹t the integration points > >>>>> available for the ancillary code the problem that needs solving > >>>>> (if it isn¹t already)? For example, it doesn¹t matter the python > >>>>> package name of a plugin, so long as it is installed on the system > >>>>> Neutron can be configured to use it. I would hope we could have > >>>>> similar assurances for integration code when the incubator repo is > >>>>> packaged. > >>>>> > >>>> > >>>> As I mentioned to Sumit, this is my biggest concern. Keeping > >>>> ancillary code belonging to other projects/sub-projects as part of > >>>> neutron incubator is not going to scale for sure. We definitely > >>>> need a better solution for this. Perhaps separate incubator > >>>> projects for each openstack project? > >>>> And > >>>> have sub-projects under that may be. But for now, if we want we > >>>> could start small and just worry about neutron sub-projects under > >>>> neutron incubator and not include horizon etc yet. > >>> I don’t think we should presuppose whether we need a better solution > >>> until we have tried the one proposed and found it wanting. The > >>> alternative you suggest - spreading incubated code between separate > >>> incubator projects for each openstack project - would seem a far > >>> less scalable solution that restricting the code to a single incubator > repo. > >>> Why would other projects want to take on responsibility for > >>> assisting in an experimental effort that hasn’t yet proven itself > >>> acceptable to it’s targeted project? > >> > >> Ok lets assume the scenario where a new feature is implemented in > >> incubator that involves changes to Horizon. Are you proposing we keep > >> the horizon changes as part of the neutron incubator repo? Till when? > >> How will we graduate this code to horizon? Since this repo is owned > >> by neutron team, Who will review and maintain the horizon code? A > >> bigger question, how will we package these horizon changes? When I > >> say having an incubator repos, these doesn’t necessarily have > >> experimental code specific to neutron feature, this could be a > >> horizon specific feature that sits here until its ready to graduate. > >> I was just thinking if it makes sense having a separate repo from > packaging stand point. > > These are all good questions to ask of the horizon team. > > > > > > m. > > > > <snip> > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
