<div dir="ltr">We have started this work. I've been working on: <a href="https://review.openstack.org/#/c/444718/">https://review.openstack.org/#/c/444718/</a><div><br></div><div>Which will do requirement checks, as specified in the Pike PTG ehterpad for Tuesday morning: <a href="https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike">https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike</a> (line 40+).</div><div><br></div><div>Once done, Tony and I were going to start testing it on the experimental pipeline for Swift and Nova.</div><div><br></div><div>Regards,</div><div>Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 2:34 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Clark Boylan's message of 2017-04-19 08:10:43 -0700:<br>
<div><div class="h5">> On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote:<br>
> > Hoy,<br>
> ><br>
> > So Gnocchi gate is all broken (agaiiiin) because it depends on "pbr" and<br>
> > some new release of oslo.* depends on pbr!=2.1.0.<br>
> ><br>
> > Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0<br>
> > that got in banished by requirements Gods. It does not prevent it to be<br>
> > used e.g. to install the software or get version information. But it<br>
> > does break anything that is not in OpenStack because well, pip installs<br>
> > the latest pbr (2.1.0) and then oslo.* is unhappy about it.<br>
><br>
> It actually breaks everything, including OpenStack. Shade and others are<br>
> affected by this as well. The specific problem here is that PBR is a<br>
> setup_requires which means it gets installed by easy_install before<br>
> anything else. This means that the requirements restrictions are not<br>
> applied to it (neither are the constraints). So you get latest PBR from<br>
> easy_install then later when something checks the requirements<br>
> (pkg_resources console script entrypoints?) they break because latest<br>
> PBR isn't allowed.<br>
><br>
> We need to stop pinning PBR and more generally stop pinning any<br>
> setup_requires (there are a few more now since setuptools itself is<br>
> starting to use that to list its deps rather than bundling them).<br>
><br>
> > So I understand the culprit is probably pip installation scheme, and we<br>
> > can blame him until we fix it. I'm also trying to push pbr 2.2.0 to<br>
> > avoid the entire issue.<br>
><br>
> Yes, a new release of PBR undoing the "pin" is the current sane step<br>
> forward for fixing this particular issue. Monty also suggested that we<br>
> gate global requirements changes on requiring changes not pin any<br>
> setup_requires.<br>
><br>
> > But for the future, could we stop updating the requirements in oslo libs<br>
> > for no good reason? just because some random OpenStack project hit a bug<br>
> > somewhere?<br>
> ><br>
> > For example, I've removed requirements update on tooz¹ for more than a<br>
> > year now, which did not break *anything* in the meantime, proving that<br>
> > this process is giving more problem than solutions. Oslo libs doing that<br>
> > automatic update introduce more pain for all consumers than anything (at<br>
> > least not in OpenStack).<br>
><br>
> You are likely largely shielded by the constraints list here which is<br>
> derivative of the global requirements list. Basically by using<br>
> constraints you get distilled global requirements and even without being<br>
> part of the requirements updates you'd be shielded from breakages when<br>
> installed via something like devstack or other deployment method using<br>
> constraints.<br>
><br>
> > So if we care about Oslo users outside OpenStack, I beg us to stop this<br>
> > crazyness. If we don't, we'll just spend time getting rid of Oslo over<br>
> > the long term…<br>
><br>
> I think we know from experience that just stopping (eg reverting to the<br>
> situation we had before requirements and constraints) would lead to<br>
> sadness. Installations would frequently be impossible due to some<br>
> unresolvable error in dependency resolution. Do you have some<br>
> alternative in mind? Perhaps we loosen the in project requirements and<br>
> explicitly state that constraints are known to work due to testing and<br>
> users should use constraints? That would give users control to manage<br>
> their own constraints list too if they wish. Maybe we do this in<br>
> libraries while continuing to be more specific in applications?<br>
<br>
</div></div>At the meeting in Austin, the requirements team accepted my proposal<br>
to stop syncing requirements updates into projects, as described<br>
in <a href="https://etherpad.openstack.org/p/ocata-requirements-notes" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-requirements-notes</a><br>
<br>
We haven't been able to find anyone to work on the implementation,<br>
though. I is my understanding that Tony did contact the Telemetry<br>
and Swift teams, who are most interested in this area of change,<br>
about devoting some resources to the tasks outlined in the proposal.<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> ><br>
> > My 2c,<br>
> ><br>
> > Cheers,<br>
> ><br>
> > ¹ Unless some API changed in a dep and we needed to raise the dep,<br>
> > obviously.<br>
> ><br>
> > --<br>
> > Julien Danjou<br>
> > # Free Software hacker<br>
> > # <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
><br>
> I don't have all the answers, but am fairly certain the situation we<br>
> have today is better than the one from several years ago. It is just not<br>
> perfect. I think we are better served by refining the current setup or<br>
> replacing it with something better but not by reverting.<br>
><br>
> Clark<br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>