Open Stack

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