Open Stack

Doug Hellmann <doug at doughellmann.com> writes:

> zuul at openstack.org writes:
>
>> Build failed.
>>
>> - publish-openstack-releasenotes-python3 http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/ : POST_FAILURE in 13m 53s
>> - publish-openstack-releasenotes http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/ : SUCCESS in 13m 54s
>>
>> _______________________________________________
>> Release-job-failures mailing list
>> Release-job-failures at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> Keystone is configured in stable/queens with the release-notes-jobs
> project template and in master with the release-notes-jobs-python3
> template. This is, AFAICT, exactly what we said should be done. However,
> both of the templates include jobs in the "tag" pipeline, and tags are
> not branch-aware. That means we end up running both versions of the
> release notes publishing jobs when we tag a release, and the results may
> be unpredictable. This problem will affect other projects as well.
>
> I think we have a few options.
>
> 1. Move the job settings out of the source repository into
>    project-config, like we do for the release jobs, so that we always
>    run the same version in all cases.
>
>    This has two downsides.
>
>    First, we would have to support the python3 variant even on very old
>    stable branches. That shouldn't be a very big concern, though,
>    because that job does not install the source for the project or its
>    dependencies.
>
>    Second, we would have to modify all of the zuul configurations for
>    all of our old branches, again. As much as I'm enjoying the jokes
>    about how I'm padding my contribution stats this cycle, I don't
>    really want to do that.
>
> 2. Make the job itself smart enough to figure out whether to run with
>    python 2 or 3.
>
>    We could update both jobs to look at some setting in the repo to
>    decide which version to use. This feels excessively complicated,
>    might still result in having to modify some settings in the stable
>    branches, and would mean we would have to customize the shared
>    versions of the jobs defined in the zuul-jobs repo.
>
> 3. Modify the python 2 version of the project template
>    ("release-notes-jobs") to remove the "tag" pipeline settings.
>
>    This would let us continue to use the python 2 variant for tests and
>    when patches merge, and only use the python 3 job for tags. As with
>    option 1, we would have to be sure that the release notes job works
>    under python 3 for all repos, but as described above that isn't a big
>    concern.
>
> I think we should take option 3, and will be preparing a patch to do
> that shortly.
>
> Did I miss any options or issues with this approach?
>
> Doug

See https://review.openstack.org/614758

Doug