Open Stack

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?


Maru


> ~ Prad
> 
> 
>> 
>> m.
>> 
>>> 
>>> If we have loose consensus on the above, some of us folks who are
>>> involved with features that are candidates for the incubator (e.g.
>>> GBP, LBaaS), can immediately start iterating on this plan, and report
>>> back our progress in a specified time frame.
>>> 
>>> Thanks,
>>> ~Sumit.
>> 
>> 
>> <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