On Aug 23, 2014, at 5:36 PM, Maru Newby <ma...@redhat.com> wrote:

> On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam <sumitnaiksa...@gmail.com> wrote:
>> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery <mest...@mestery.com> wrote:
>>> On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>> wrote:
>>>> Hash: SHA512
>>>> On 20/08/14 18:28, Salvatore Orlando wrote:
>>>>> Some comments inline.
>>>>> Salvatore
>>>>> On 20 August 2014 17:38, Ihar Hrachyshka <ihrac...@redhat.com
>>>>> <mailto:ihrac...@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.*).

If the point of the incubator is to signal to deployers that the code isn’t 
fully supported, you may want to use a different namespace for the 
python/system packages as well.


>> * 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.
>> * 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.
> 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to