Open Stack

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 <joehuang at 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:kukura at noironetworks.com]
> 发送时间: 2014年9月1日 22:37
> 收件人: openstack-dev at 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 [marun at 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) <
> pkilambi at cisco.com> wrote:
> >
> >>
> >> On 8/26/14, 4:49 AM, "Maru Newby" <marun at redhat.com> wrote:
> >>
> >>> On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
> >>> <pkilambi at cisco.com> wrote:
> >>>
> >>>>
> >>>> On 8/23/14, 5:36 PM, "Maru Newby" <marun at redhat.com> wrote:
> >>>>
> >>>>> On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam
> >>>>> <sumitnaiksatam at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery
> >>>>>> <mestery at mestery.com>
> >>>>>> wrote:
> >>>>>>> On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka
> >>>>>>> <ihrachys at 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 <ihrachys at redhat.com
> >>>>>>>>> <mailto:ihrachys at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140901/3033224a/attachment-0001.html>