On Aug 26, 2014, at 5:06 PM, Pradeep Kilambi (pkilambi) <pkila...@cisco.com> wrote:
> > > On 8/26/14, 4:49 AM, "Maru Newby" <ma...@redhat.com> wrote: > >> >> On Aug 25, 2014, at 4:39 PM, Pradeep Kilambi (pkilambi) >> <pkila...@cisco.com> wrote: >> >>> >>> >>> On 8/23/14, 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: >>>>>>> -----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.*). >>> >>> >>> 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> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
