Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
Doug Hellmann writes:
> z...@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-failu...@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
__
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
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
z...@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-failu...@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
__
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
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: [...] > Did I miss any options or issues with this approach? https://review.openstack.org/578557 -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
Jeremy Stanley writes: > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > [...] >> Did I miss any options or issues with this approach? > > https://review.openstack.org/578557 How high of a priority is rolling that feature out? It does seem to eliminate this particular issue (even the edge cases described in the commit message shouldn't affect us based on our typical practices), but until we have one of the two changes in place we're going to have this issue with every release we tag. Doug > > -- > Jeremy Stanley > __ > 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
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote: > Jeremy Stanley writes: > > > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > > [...] > >> Did I miss any options or issues with this approach? > > > > https://review.openstack.org/578557 > > How high of a priority is rolling that feature out? It does seem to > eliminate this particular issue (even the edge cases described in the > commit message shouldn't affect us based on our typical practices), but > until we have one of the two changes in place we're going to have this > issue with every release we tag. It was written as a potential solution to this problem back when we first discussed it in June, but at the time we thought it might be solvable via job configuration with minimal inconvenience so that feature was put on hold as a fallback option in case we ended up needing it. I expect since it's already seen some review and is passing tests it could probably be picked back up fairly quickly now that alternative solutions have proven more complex than originally envisioned. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On Thu, Nov 01, 2018 at 03:08:09PM +, Jeremy Stanley wrote: > On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote: > > Jeremy Stanley writes: > > > > > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > > > [...] > > >> Did I miss any options or issues with this approach? > > > > > > https://review.openstack.org/578557 > > > > How high of a priority is rolling that feature out? It does seem to > > eliminate this particular issue (even the edge cases described in the > > commit message shouldn't affect us based on our typical practices), but > > until we have one of the two changes in place we're going to have this > > issue with every release we tag. > > It was written as a potential solution to this problem back when we > first discussed it in June, but at the time we thought it might be > solvable via job configuration with minimal inconvenience so that > feature was put on hold as a fallback option in case we ended up > needing it. I expect since it's already seen some review and is > passing tests it could probably be picked back up fairly quickly now > that alternative solutions have proven more complex than originally > envisioned. > -- > Jeremy Stanley Doug's option 3 made sense to me as a way to address this for now. I could see doing that for the time being, but if this is coming in the near future, we can wait and go with it as option 4. Sean __ 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
