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: >>> -----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 <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.*). > > * 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
