<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 October 2017 at 10:35, 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 Jeremy Stanley's message of 2017-10-24 15:05:34 +0000:<br>
<span class="">> On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:<br>
> [...]<br>
> > It looks like the publish-to-pypi-neutron template modifies<br>
> > publish-to-pypi by adding openstack/neutron to the required-repositories<br>
> > list for the release-openstack-python job. That repository was also at<br>
> > some point added directly to the release-openstack-python job. So<br>
> > technically the extension via the template is not needed. The same<br>
> > applies to publish-to-pypi-horizon.<br>
> [...]<br>
><br>
> Both are stop-gap solutions and I think either is fine in the short<br>
> term to get us through the bulk of the release request backlog.<br>
> Longer term we want to have neither of those. Python projects should<br>
> be able to build sdists/wheels[1], documentation[2] and release<br>
> notes[3] without tox (a behavior change which significantly<br>
> complicates preinstalling source code from other projects, so best<br>
> if their release jobs simply don't rely on doing that at all).<br>
><br>
> > As we find other projects with more dependencies, we're going to<br>
> > end up with more custom templates.<br>
> [...]<br>
><br>
> If we do, this only accelerates the need for something like a<br>
> community goal for fixing this in those respective Python<br>
> plugin/extension projects.<br>
<br>
</span>Right. I know the neutron team has been working on their library system<br>
for quite a while. Maybe someone can report on the progress there?<br></blockquote><div><br></div><div>the work on neutron-lib is slowly progressing but it's not close enough to allow us to break the dependency that requires neutron sub-projects to add neutron to the list of required-projects (which I believe the sort of the error in the release pipeline stems from).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't know if the horizon team is working on that (I'm just uninformed<br>
about what they're doing). So maybe someone from that team can comment?<br>
<span class=""><br>
><br>
> > One alternative to keeping multiple variants, and defining more in<br>
> > the future, is to add required-repositories to the release-openstack-python<br>
> > job directly, as we discover they are needed. Of course that means<br>
> > we will clone repositories for some jobs that don't actually use<br>
> > them. I don't know how big of an issue that really is, but the issue<br>
> > of not knowing which instances of a job actually need a particular<br>
> > dependency seems like more of a justification for keeping separate<br>
> > templates than any runtime savings we would have by skipping a<br>
> > couple of extra calls to git clone.<br>
> [...]<br>
><br>
> Well, in this case you're talking about Zuul needing to calculate<br>
> merge states for the neutron and horizon repos and then push these<br>
> into every build of the affected jobs, which is no small amount of<br>
> overhead on its own given the size of those particular repos. Also,<br>
> once the tox-siblings role[4] is back in action (likely later this<br>
> week?) Zuul will go back to preinstalling any required-projects from<br>
> source into tox virtualenvs for these jobs, which is quite a bit<br>
> more overhead still at that point.<br>
<br>
</span>Yes, we don't want that, so I think that means we want to retain the<br>
multiple project templates for the short-term. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
><br>
> [1] <a href="http://git.openstack.org/cgit/openstack/governance/commit/?id=2678231" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/governance/commit/?<wbr>id=2678231</a><br>
> [2] <a href="http://git.openstack.org/cgit/openstack/governance/commit/?id=2c0cdd2" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/governance/commit/?<wbr>id=2c0cdd2</a><br>
> [3] <a href="http://git.openstack.org/cgit/openstack/governance/commit/?id=df438a7" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/governance/commit/?<wbr>id=df438a7</a><br>
> [4] <a href="http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/tox-siblings" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/zuul-jobs/<wbr>tree/roles/tox-siblings</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<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></div>