<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 19, 2016 at 12:24 PM, Ian Cordasco <span dir="ltr"><<a href="mailto:sigmavirus24@gmail.com" target="_blank">sigmavirus24@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> <br>
<br>
-----Original Message-----<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
Reply: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Date: April 18, 2016 at 17:21:36<br>
To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject:  Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements<br>
<br>
> Hi Doug,<br>
><br>
> I very much welcome opening such a thread before the discussion at the<br>
> summit, as often, sessions are too short. Taking the time to write<br>
> things down first also helps having a more constructive discussion.<br>
><br>
> Before I reply to each individual message below, let me attempt to reply<br>
> to the big picture seen in your etherpad. I was tempted to insert<br>
> comments on each lines of it, but I'm not sure how this would be<br>
> received, and probably it's best to attempt to reply more globally.<br>
><br>
> From what I understand, the biggesgt problems you're trying to solve is<br>
> that managing the global-reqs is really time consuming from the release<br>
> team point of view, and especially its propagation to individual<br>
> projects. There's IMO many things that we could do to improve the<br>
> situation, which would be acceptable from the package maintainers point<br>
> of view.<br>
><br>
> First of all, from what I could see in the etherpad, I see a lot of<br>
> release work which I consider not useful for anyone: not for downstream<br>
> distros, not upstream projects. Mostly, the propagation of the<br>
> global-requirements.txt to each and every individual Python library or<br>
> service *for OpenStack maintained libs* could be reviewed. Because 1/<br>
> distros will always package the highest version available in<br>
> upper-constraints.txt, and 2/ it doesn't really reflect a reality. As<br>
> you pointed out, project A may need a new feature from lib X, but<br>
> project B wont care. I strongly believe that we should leave lower<br>
> boundaries as a responsibility of individual projects. What important<br>
> though, is to make sure that the highest version released does work,<br>
> because that's what we will effectively package.<br>
><br>
> What we can then later on do, at the distribution level, is artificially<br>
> set the lower bounds of versions to whatever we've just uploaded for a<br>
> given release of OpenStack. In fact, I've been doing this a lot already.<br>
> For example, I uploaded Eventlet 0.17.4, and then 0.18.4. There was<br>
> never anything in the between. Therefore, doing a dependency like:<br>
><br>
> Depends: python-eventlet (>= 0.18.3)<br>
><br>
> makes no sense, and I always pushed:<br>
><br>
> Depends: python-eventlet (>= 0.18.4)<br>
><br>
> as this reflects the reality of distros.<br>
><br>
> If we generalize this concept, then I could push the minimum version of<br>
> all oslo libs into every single package for a given version of OpenStack.<br>
><br>
> What is a lot more annoying though, is for packages which I do not<br>
> control directly, and which are used by many other non-OpenStack<br>
> packages inside the distribution. For example, Django, SQLAlchemy or<br>
> jQuery, to only name a few.<br>
><br>
> I have absolutely no problem upping the lower bounds for all of<br>
> OpenStack components aggressively. We don't have gate jobs for the lower<br>
> bounds of our requirements. If we decide that it becomes the norm, I can<br>
> generalize and push for doing this even more. For example, after pushing<br>
> the update of an oslo lib B version X, I could push such requirements<br>
> everywhere, which in fact, would be a good thing (as this would trigger<br>
> rebuilds and recheck of all unit tests). Though, all of this would<br>
> benefit from a lot of automation and checks.<br>
><br>
> On your etherpad, you wrote:<br>
><br>
> "During the lead-up to preparing the final releases, one of the tracking<br>
> tasks we have is to ensure all projects have synced their global<br>
> requirements updates. This is another area where we could reduce the<br>
> burden on the release team."<br>
><br>
> Well, don't bother, this doesn't reflect a reality anyway (ie: maybe<br>
> service X can use an older version of oslo.utils), so that's not really<br>
> helpful in any way.<br>
><br>
> You also wrote:<br>
><br>
> "Current ranges in global-requirements are large but most projects do<br>
> not actively test the oldest supported version (or other versions in<br>
> between) meaning that the requirement might result in broken packages."<br>
><br>
> Yeah, that's truth, I've seen this and reported a few bugs (the last I<br>
> have in memory is Neutron requiring SQLA >= 1.0.12). Though that's still<br>
> very useful hints for package maintainers *for 3rd party libs* (as I<br>
> wrote, it's less important for OpenStack components). We have a few<br>
> breakage here and there, but they are hopefully fixes.<br>
><br>
> Though having a single version that projects are allowed to test with is<br>
> super important, so we can check everything can work together. IMO,<br>
> that's the part which should absolutely not change. Dropping that is<br>
> like opening a Pandora box. Relying on containers and/or venv will<br>
> unfortunately, not work, from my stand point.<br>
><br>
> The general rule for a distribution is that the highest version always<br>
> win, otherwise, it's never maintainable (for security and bug fixes). It<br>
> should be the case for *any program*, not even just any OpenStack<br>
> components. There's never a case where it's ok to use something older,<br>
> just because it feels like less work to do. This type of "laziness"<br>
> leads to very dangerous outcomes, always.<br>
><br>
> Though I don't see any issue with a project willing to keep backward<br>
> compatibility with a lower version than what other project do. In fact,<br>
> that's highly desirable to always try to remain compatible with lower<br>
> versions as much as possible, *if* it doesn't bring too much burden<br>
> (think: we still have loads of Python 2.6 stuff like discover, argparse<br>
> and such that needs to be cleaned-up).<br>
><br>
> For the projects who aren't following the release cycles, it's ok if<br>
> they bump their lower bounds at the condition that they keep what's in<br>
> the upper-constraints.txt, so that we can release them together with the<br>
> rest of OpenStack. For example, it's ok to require the latest oslo.utils<br>
> 3.8.0 for Ironic 5.1.0.<br>
><br>
> I also see no reason to completely freeze versions to the point were it<br>
> is impossible fix bugs in the versionnings. I've seen that multiple<br>
> times. At the distro level, we do address the issue anyway, so why<br>
> bother? The only thing that counts for us, is to be able to release<br>
> everything together. A good example would be that Neutron needing SQLA<br>
> >= 1.0.12: we refuse to fix it, but the issue is still there, and we<br>
> have to fix it in distros.<br>
><br>
> Last, before I reply to each individual message: the attempt from Robert<br>
> to test on lower bounds is really something that should be pushed<br>
> forward. I would help a lot to actually know what the reality is, rather<br>
> than doing second-guess and artificially set lower bounds for versions<br>
> which we think may probably work.<br>
><br>
> On 04/18/2016 02:22 PM, Chris Dent wrote:<br>
> > targeting an<br>
> > all-in-one install seems only to serve the purposes of all-in-one rpm-<br>
> > or deb-based installations.<br>
><br>
> Though that's what most everyone consumes. Or are you proposing that we<br>
> completely stop publishing OpenStack in distros?<br>
><br>
> Remember that in distros, there's only a single version of a library at<br>
> any given time, at the exception of transitions (yes, in Red Hat it's<br>
> technically possible to install multiple versions, but the policy<br>
> strongly advocates against this).<br>
><br>
> Also, all-in-one is what I use in Debian in my CI, to make sure that<br>
> everyone works together, with whatever is uploaded (see the<br>
> openstack-deploy package in Debian).<br>
><br>
> > Many (most?) people won't be doing those kinds of installations.<br>
><br>
> Most users are consuming packages from distributions. Also, if you're<br>
> using containers, probably you will also prefer using these packages to<br>
> build your containers: that's the most easy, safe and fast way to build<br>
> your containers.<br>
><br>
> > If all-in-one installations are important to the rpm- and deb- based<br>
> > distributions then _they_ should be resolving the dependency issues<br>
> > local to their own infrastructure<br>
><br>
> Who is "they"? Well, approximately 1 person full time for Debian, 1 for<br>
> Ubuntu if you combine Corey and David (and Debian and Ubuntu<br>
> dependencies are worked on together in Debian), so that's 2 full time<br>
> for Ubuntu/Debian. Maybe 2 and a half for RDO if what Haikel told me is<br>
> still accurate.<br>
><br>
> So "we" wont handle it, even if "we" care, because we're already<br>
> understaffed.<br>
><br>
> > (or realizing that it is too painful and start<br>
> > containerizing or otherwise as well).<br>
><br>
> Distributions don't package containers, we offer packages that you can<br>
> use to build them. The way you deploy is IMO orthogonal to packaging.<br>
><br>
> > I think making these changes will help to improve and strengthen the<br>
> > boundaries and contracts between services. If not technically then<br>
> > at least socially, in the sense that the negotiations that people<br>
> > make to get things to work are about what actually matters in their<br>
> > services, not unwinding python dependencies and the like.<br>
><br>
> Yes, it simplifies the life of developers. But it's going to be hell on<br>
> earth for production if we discover a serious vulnerability in a<br>
> component, which will be deployed N times, with N versions. Are we then<br>
> going to provide N patches? The vulnerability management team is also<br>
> understaffed...<br>
><br>
> > One challenge I've run into the past is when devstack<br>
> > plugin A has made an assumption about having access to a python<br>
> > script provided by devstack plugin B, but it's not on $PATH or its<br>
> > dependencies are not in the site-packages visible to the current<br>
> > context. The solution here is to use full paths _into_ virtenvs.<br>
><br>
> Please take a step back. Devstack and virtualenv are for development,<br>
> not for production. That's not, and should not become, our target.<br>
> Applying the reasoning you have there will *not* work for distributions.<br>
> Hopefully, that's what Doug is proposing, as he would still like things<br>
> to work for distros (right?).<br>
><br>
> On 04/18/2016 03:24 PM, Hayes, Graham wrote:<br>
> > It is also worth noting that according to the OpenStack User Survey<br>
> > [0] 56% of deployments use "Unmodifed packages from the operating<br>
> > system".<br>
><br>
> It is my believe (and hope, as this would mean more users) that some<br>
> OpenStack users don't even know about this survey, and just install<br>
> what's in the distros. So 56% is the lowest estimate. Also, "Unmodifed<br>
> packages" is the answer. Maybe some are deploying "slightly modified<br>
> packages, but mostly what's upstream", which would bring the score even<br>
> higher.<br>
><br>
> On 04/18/2016 07:33 PM, Doug Hellmann wrote:<br>
> > Can you truly not imagine any other useful way to package OpenStack<br>
> > other than individual packages with shared dependencies that would<br>
> > be acceptable?<br>
><br>
> I could imagine that, but that's not at all what OpenStack is currently.<br>
> Currently, each and every service is using Oslo, clients, and so on,<br>
> plus the glue libs like os-brick, Castellan, you name it.<br>
><br>
> Or did I misunderstood your sentence above?<br>
><br>
> On 04/18/2016 07:49 PM, Sean Dague wrote:<br>
> > A lot of distros specifically have policies against this kind of<br>
> > bundling as well, because of security issues like this (which was so<br>
> > very bad) - <a href="http://www.zlib.net/advisory-2002-03-11.txt" rel="noreferrer" target="_blank">http://www.zlib.net/advisory-2002-03-11.txt</a><br>
><br>
> Gentoo is probably a special case (because building from source and so<br>
> on), but I'd say that *ALL* distro do have such policy in place (at<br>
> least, Red Hat, Debian, Ubuntu, SuSE...).<br>
><br>
> On 04/18/2016 08:30 PM, Doug Hellmann wrote:<br>
> > Our upstream<br>
> > solution can be pretty light-weight, and that leaves room for<br>
> > downstream folks to make different choices.<br>
><br>
> I'm not sure what choice we'd have, but to face loads of issues and<br>
> finally give-up packaging OpenStack if we have python module versions<br>
> that are conflicting. Hopefully, your proposal wont allow that?<br>
><br>
> On 04/18/2016 08:40 PM, Doug Hellmann wrote:<br>
> > Some folks seem to be conflating "upstream wants to stop worrying<br>
> > about co-installability" with "upstream wants us to bundle<br>
> > dependencies". That's not what I'm proposing.<br>
><br>
> Well, if we need multiple versions of the same Python module, what is<br>
> the solution in production then?<br>
><br>
> > Another alternate that might work is for downstream folks to do<br>
> > their own dependency management.<br>
><br>
> I fail to understand what you think distros could do to fix the<br>
> situation of conflicting versions, other than bundling, which isn't<br>
> acceptable. Could you explain what you mean by "downstream folks to do<br>
> their own dependency management"?<br>
><br>
> > That's less optimal, and may not<br>
> > change the outcome for Gentoo or Debian, where the downstream teams<br>
> > are small (1 person each, I think?).<br>
><br>
> You can also add "Ubuntu" in the list here, as absolutely all OpenStack<br>
> dependencies are maintained mostly by me, within Debian, and then later<br>
<br>
</div></div>"absolutely all" of OpenStack's dependencies are not maintained by you in Debian. A significant number are maintained by the DPMT (Debian Python Modules Team). The large majority are maintained by you, but not "absolutely all".<br>
<div><div class="h5"><br>
> synced to Ubuntu, with a bit of help from Ubuntu folks (but they are<br></div></div></blockquote><div><br></div><div>And if you grep the changelogs for openstack deps in Debian you'd see a lot more than "a bit" of contributions from Ubuntu folks.  But that's not the point of this thread..</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> mostly busy with Canonical own products, and I'm the person doing most<br>
> of the work, still). This is slowly shifting to a more spread workload,<br>
> but unfortunately, we're not there yet.<br>
><br>
> As for Red Hat / RDO, Haikel told me they are "2 and a half", so<br>
> basically, the situation there (unless it changed) is approximately the<br>
> same amount of burnout people.<br>
><br>
> > I started the discussion to solicit ideas, but I would prefer to<br>
> > avoid proposing what downstream should do because (a) I'm sure<br>
> > folks want options and (b) I'm sure I'm not the person to identify<br>
> > those options.<br>
><br>
> Well, I'm doing the packaging, and I'm not sure if we have any option<br>
> either, if 2 python dependencies are conflicting.<br>
><br>
> On 04/18/2016 09:10 PM, Jeremy Stanley wrote:<br>
> > On 2016-04-18 13:58:03 -0500 (-0500), Matthew Thode wrote:<br>
> >> Ya, I'd be happy to work more with upstream. I already review the<br>
> >> stable-reqs updates and watch them for the stable branches I package<br>
> >> for. Not sure what else is needed.<br>
> ><br>
> > Reviewing the master branch openstack/requirements repository<br>
> > changes (to make sure deps being added are going to be sane things<br>
> > for someone in your distro to maintain packages of in the long term)<br>
> > would also make sense.<br>
><br>
> I've done some of that, and used to be reactive on it. But mostly, the<br>
> way it's been done so far is very good (thanks to a lot of folks working<br>
> on it), and it's taking too much of my time to review them. So I just<br>
> pick it up before packaging a (beta-)version of OpenStack.<br>
><br>
> > To be clear, "Moving the burden to packagers" is not the only option<br>
> > available to us. I've proposed one option for eliminating the issue,<br>
> > which has some benefits for us upstream but obviously introduces<br>
> > some other issues we would need to resolve. Another option is for<br>
> > more people to get involved in managing the dependency list. Some<br>
> > (most? all?) of those new people may come from distros, and sharing<br>
> > the effort among them would make it easier than each of them doing<br>
> > all of the work individually. Sort of like an open source project.<br>
><br>
> There's 2 options I see to solve the "people reviewing the<br>
> global-requirements.txt changes aren't enough".<br>
><br>
> 1/ talk to my boss and the folks from Canonical (I can't tell for the<br>
> RPM world) to allocate more staff for packaging (yes, I'm serious here!<br>
> I can get you in touch...).<br>
><br>
> 2/ get a lot of dependencies out. Yes, let's really do that! We're<br>
> constantly adding more, I've seen only very few going away. Currently<br>
> the global-requirements.txt for stable/mitaka is 377 lines long. If you<br>
> grep out "client", "oslo" and "os-", "openstack", comments, empty lines,<br>
> and a few others, there's about 260 dependencies left. That's insane at<br>
> multiple levels. When are we going to see a movement to clean this mess,<br>
> and define real OpenStack standards?<br>
><br>
> Cheers,<br>
><br>
> Thomas Goirand (zigo)<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
</div></div>--<br>
Ian Cordasco<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Regards,<br>Corey<br></div></div>
</div></div>