<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 12:28 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Some comments inline.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Salvatore<br><br><div class="gmail_quote"><div><div class="h5">On 20 August 2014 17:38, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi all,<br>
<br>
I've read the proposal for incubator as described at [1], and I have<br>
several comments/concerns/suggestions to this.<br>
<br>
Overall, the idea of giving some space for experimentation that does<br>
not alienate parts of community from Neutron is good. In that way, we<br>
may relax review rules and quicken turnaround for preview features<br>
without loosing control on those features too much.<br>
<br>
Though the way it's to be implemented leaves several concerns, as follows:<br>
<br>
1. From packaging perspective, having a separate repository and<br>
tarballs seems not optimal. As a packager, I would better deal with a<br>
single tarball instead of two. Meaning, it would be better to keep the<br>
code in the same tree.<br>
<br>
I know that we're afraid of shipping the code for which some users may<br>
expect the usual level of support and stability and compatibility.<br>
This can be solved by making it explicit that the incubated code is<br>
unsupported and used on your user's risk. 1) The experimental code<br>
wouldn't probably be installed unless explicitly requested, and 2) it<br>
would be put in a separate namespace (like 'preview', 'experimental',<br>
or 'staging', as the call it in Linux kernel world [2]).<br>
<br>
This would facilitate keeping commit history instead of loosing it<br>
during graduation.<br>
<br>
Yes, I know that people don't like to be called experimental or<br>
preview or incubator... And maybe neutron-labs repo sounds more<br>
appealing than an 'experimental' subtree in the core project. Well,<br>
there are lots of EXPERIMENTAL features in Linux kernel that we<br>
actively use (for example, btrfs is still considered experimental by<br>
Linux kernel devs, while being exposed as a supported option to RHEL7<br>
users), so I don't see how that naming concern is significant.<br></blockquote><div><br></div></div></div><div>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. </div>
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2. If those 'extras' are really moved into a separate repository and<br>
tarballs, this will raise questions on whether packagers even want to<br>
cope with it before graduation. When it comes to supporting another<br>
build manifest for a piece of code of unknown quality, this is not the<br>
same as just cutting part of the code into a separate<br>
experimental/labs package. So unless I'm explicitly asked to package<br>
the incubator, I wouldn't probably touch it myself. This is just too<br>
much effort (btw the same applies to moving plugins out of the tree -<br>
once it's done, distros will probably need to reconsider which plugins<br>
they really want to package; at the moment, those plugins do not<br>
require lots of time to ship them, but having ~20 separate build<br>
manifests for each of them is just too hard to handle without clear<br>
incentive).<br></blockquote><div><br></div></div><div>One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them.</div><div>If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage).</div>
</div></div></div></blockquote><div><br></div><div>It's also unfair that core team reviewers are forced to spend time on 3rd plugins and drivers under existing process. There are so many 3rd networking backend technologies, from hardware to controller, anyone can submit plugins and drivers to the tree, and for the principle of neutrality we can't agree some and refuse others' reviewing request. Then reviewers' time slot are full of these 3rd backend related work, leaving less time on the most important and urgent thing: improve Neutron core architecture to the same mature level like Nova as soon as possible.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
3. The fact that neutron-incubator is not going to maintain any stable<br>
branches for security fixes and major failures concerns me too. In<br>
downstream, we don't generally ship the latest and greatest from PyPI.<br>
Meaning, we'll need to maintain our own downstream stable branches for<br>
major fixes. [BTW we already do that for python clients.]<br>
<br></blockquote><div><br></div></div><div>This is a valid point. We need to find an appropriate trade off. My thinking was that incubated projects could be treated just like client libraries from a branch perspective.</div>
<div class=""><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4. Another unclear part of the proposal is that notion of keeping<br>
Horizon and client changes required for incubator features in<br>
neutron-incubator. AFAIK the repo will be governed by Neutron Core<br>
team, and I doubt the team is ready to review Horizon changes (?). I<br>
think I don't understand how we're going to handle that. Can we just<br>
postpone Horizon work till graduation?<br>
<br></blockquote><div><br></div></div><div>I too do not think it's a great idea, mostly because there will be horizon bits not shipped with horizon, and not verified by horizon core team.</div><div>I think it would be ok to have horizon support for neutron incubator. It won't be the first time that support for experimental features is added in horizon.</div>
<div class="">
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
5. The wiki page says that graduation will require full test coverage.<br>
Does it mean 100% coverage in 'coverage' report? I don't think our<br>
existing code is even near that point, so maybe it's not fair to<br>
require that from graduated code.<br></blockquote><div><br></div></div><div>I agree that by these standards we should take the whole neutron and return it to incubation, or probably just chuck it in the bin.</div><div>It's not a mystery that Neutron quality is well below integrated level but let's not diverge.</div>

<div><br></div><div>On the other hand, the fact that Neutron's code is rubbish does not authorise the addition of further rubbish.</div><div>I see this requirement for graduation as a measure to ensure new additions to neutron have proper quality.</div>

<div>In the meanwhile it will be mandatory for the neutron community to keep working on quality, scalability and improve testing coverage.</div><div>Otherwise there will be no talk about neutron-incubator, mostly because probably there will be no neutron.</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
A separate tree would probably be reasonable if it would be governed<br>
by a separate team. But as it looks now, it's still Neutron Cores who<br>
will do the review heavy-lifting. So I wonder why not just applying<br>
different review rules for patches for core and the staging subtree.<br></blockquote><div><br></div></div><div>This is a good point. As a neutron core I don't want to do the heavy lifting there. I think we should define rules which allow teams to iterate quickly while enabling the neutron core team to retain some form of control on what goes in the incubator.</div>
<div class="">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[1]: <a href="https://wiki.openstack.org/wiki/Network/Incubator" target="_blank">https://wiki.openstack.org/wiki/Network/Incubator</a><br>
[2]:<br>
<a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging</a><br>
<br>
/Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
<br>
iQEcBAEBCgAGBQJT9MDpAAoJEC5aWaUY1u57bYAH/0LsZonj3zVmWomUBBPriUOm<br>
GRoNBHq6C7BCfO7gRnQQyRd/N4jCL4Y1Dfbfv2Ypulsgf0x+ugvmzOrWm2Sa7KiS<br>
F3adumx+0OjJSMb5SSOxZQHpsZFjJmwtJjat9vwOYFXcCXhn8r9AgN3TPm5GyZ29<br>
NPY+SQdqu+G/ZgXd94sE2+gGbx0H5nLZusJD0yiUpoNExhv4qvjHSZW1rwssb+Ac<br>
3dU3LU1FqhM7UxkgnWk6AGYHfLjr5CfxXBrmikQsxXljl8Sko9DBTpKa3YtVcBX1<br>
FdMWLGn13nFNasGAKHot/aRfmdfPIzN0TsjjfRstm0W1VLvvbQjLxGTQDEyey/U=<br>
=vdaC<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>