On 24 October 2017 at 10:35, Doug Hellmann <d...@doughellmann.com> wrote:

> Excerpts from Jeremy Stanley's message of 2017-10-24 15:05:34 +0000:
> > On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> > > It looks like the publish-to-pypi-neutron template modifies
> > > publish-to-pypi by adding openstack/neutron to the
> required-repositories
> > > list for the release-openstack-python job. That repository was also at
> > > some point added directly to the release-openstack-python job. So
> > > technically the extension via the template is not needed. The same
> > > applies to publish-to-pypi-horizon.
> > [...]
> >
> > Both are stop-gap solutions and I think either is fine in the short
> > term to get us through the bulk of the release request backlog.
> > Longer term we want to have neither of those. Python projects should
> > be able to build sdists/wheels[1], documentation[2] and release
> > notes[3] without tox (a behavior change which significantly
> > complicates preinstalling source code from other projects, so best
> > if their release jobs simply don't rely on doing that at all).
> >
> > > As we find other projects with more dependencies, we're going to
> > > end up with more custom templates.
> > [...]
> >
> > If we do, this only accelerates the need for something like a
> > community goal for fixing this in those respective Python
> > plugin/extension projects.
>
> Right. I know the neutron team has been working on their library system
> for quite a while. Maybe someone can report on the progress there?
>

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).


>
> I don't know if the horizon team is working on that (I'm just uninformed
> about what they're doing). So maybe someone from that team can comment?
>
> >
> > > One alternative to keeping multiple variants, and defining more in
> > > the future, is to add required-repositories to the
> release-openstack-python
> > > job directly, as we discover they are needed. Of course that means
> > > we will clone repositories for some jobs that don't actually use
> > > them. I don't know how big of an issue that really is, but the issue
> > > of not knowing which instances of a job actually need a particular
> > > dependency seems like more of a justification for keeping separate
> > > templates than any runtime savings we would have by skipping a
> > > couple of extra calls to git clone.
> > [...]
> >
> > Well, in this case you're talking about Zuul needing to calculate
> > merge states for the neutron and horizon repos and then push these
> > into every build of the affected jobs, which is no small amount of
> > overhead on its own given the size of those particular repos. Also,
> > once the tox-siblings role[4] is back in action (likely later this
> > week?) Zuul will go back to preinstalling any required-projects from
> > source into tox virtualenvs for these jobs, which is quite a bit
> > more overhead still at that point.
>
> Yes, we don't want that, so I think that means we want to retain the
> multiple project templates for the short-term.


> >
> > [1] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2678231
> > [2] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2c0cdd2
> > [3] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=df438a7
> > [4] http://git.openstack.org/cgit/openstack-infra/zuul-jobs/
> tree/roles/tox-siblings
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to