Open Stack

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>