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.


On 9/1/14, 9:05 AM, joehuang wrote:

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 

Best regards.

Chaoyi Huang ( joehuang )

发件人: Maru Newby []
发送时间: 2014年9月1日 17:53
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [neutron] Incubator concerns from packaging     

On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) <> 

On 8/26/14, 4:49 AM, "Maru Newby" <> wrote:

On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi)
<> wrote:

On 8/23/14, 5:36 PM, "Maru Newby" <> wrote:

On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam <>

On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery <>
On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka
Hash: SHA512

On 20/08/14 18:28, Salvatore Orlando wrote:
Some comments inline.


On 20 August 2014 17:38, Ihar Hrachyshka <
<>> 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

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

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
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
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
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
and then released versions could target milestone tags or released

* 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.

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
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

* 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
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
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
is not going to scale for sure. We definitely need a better solution for
this. Perhaps separate incubator projects for each openstack project?
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.


OpenStack-dev mailing list
OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to