Open Stack

On Tue, Oct 24, 2017 at 09:42:25AM -0400, Doug Hellmann wrote:
> The neutron queens milestone release is held up right now because
> some of the repositories are using a release job template that isn't
> recognized by the validation code in the releases repository.  I'm
> trying to decide between adding the custom job template to the
> validation code or changing the release jobs for those neutron
> repositories to use the one that isn't custom. I think we'll have
> the same problem with horizon plugins using the custom job template
> set up for them.
> 
> 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.
> 
> I see a few issues with keeping job template variants:
> 
> 1. Having multiple release job variants complicates the release
>    repo validation logic. That logic was put in place after we
>    discovered several projects without release jobs defined at all,
>    so we definitely want to keep some level of validation in place.
> 
> 2. As we continue to make changes to the release jobs, we're going
>    to have to consider whether to make those changes in multiple
>    places, which seems error prone.

This is my big concern. Chances are very likely things will get missed.

> 
> 3. As we find other projects with more dependencies, we're going
>    to end up with more custom templates.
> 
> Those issues may be mitigated if we move the release job definitions
> into the releases repo as we have discussed, because it will be
> more obvious that we have multiple related templates that are
> variants of one another and we can make the relevant changes all
> together in one patch.
> 
> 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.
> 
> It feels like we have two related by not necessarily dependent
> policy questions we need to answer before we decide how to proceed:
> 
> (a) Do we want to move the release job definitions from project-config
>     and openstack-zuul-jobs to the releases repo?
> 

This seems like a good compromise to me. If we at least have them all in one
place, it will make it a lot easier to make sure we are able to get everything
updated as needed.

> (b) Do we want to have multiple release job templates due to custom
>     dependencies (or any other reason)?
> 

I'm guessing we will want this. We will most likely at some point have some
need to have unique requirements for certain jobs.

> Thoughts?
> 
> Doug
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev