Open Stack

+1

I agree with Pradeep and Doug that a new namespace makes for a better
structure for packaging and usage.

Regards,
Mandeep
-----



On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
> On Aug 23, 2014, at 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.*).
>
> 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.
>
> Doug
>
> >
> >>
> >> * 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/a43987d9/attachment.html>