Open Stack

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