Re: [openstack-dev] [requirements] changing the order of values in upper-constraints.txt
Excerpts from Andreas Jaeger's message of 2017-02-01 15:37:15 +0100: > On 2017-02-01 15:27, Doug Hellmann wrote: > > [...] > > Another option was to have the release bot continually propose > > updates to the same patch, like we do with the global requirements > > sync job. On any given day, that's going to cause a bunch of resets > > on the patch, until we merge it. That will be particularly annoying > > if we release something while the patch is in the gate queue ready > > to be merged, but even in the check queue it will "waste" test nodes > > on each reset. > > Note that the proposal jobs can check whether a job is in the gate queue > and do not propose anything at that time, see > http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/common.sh#n69 > - the check_already_approved function. > > Whether you want to use it in this case, is up to you. For these kind of > jobs that run often, it might be a good idea, > > Andreas Oh, that's definitely a good option to have. Thanks for pointing that out! 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] [requirements] changing the order of values in upper-constraints.txt
On 2017-02-01 15:27, Doug Hellmann wrote:
> [...]
> Another option was to have the release bot continually propose
> updates to the same patch, like we do with the global requirements
> sync job. On any given day, that's going to cause a bunch of resets
> on the patch, until we merge it. That will be particularly annoying
> if we release something while the patch is in the gate queue ready
> to be merged, but even in the check queue it will "waste" test nodes
> on each reset.
Note that the proposal jobs can check whether a job is in the gate queue
and do not propose anything at that time, see
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/common.sh#n69
- the check_already_approved function.
Whether you want to use it in this case, is up to you. For these kind of
jobs that run often, it might be a good idea,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
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] [requirements] changing the order of values in upper-constraints.txt
Excerpts from Tony Breeds's message of 2017-02-01 21:18:54 +1100: > On Wed, Jan 18, 2017 at 04:34:56PM -0500, Doug Hellmann wrote: > > When I tried to merge the upper-constraints updates for the library > > releases we did today, I ran into quite a lot of merge conflicts > > with the Oslo libraries. I'm exploring options for reducing the > > likelihood that those sorts of conflicts will occur with a few > > patches that change how we generate the constraints list. > > Dirk's been doing a great job of dealing with that and there are scripts to > take the ones generated from the bot and make single series from them n deep. > That's not very sustainable though. > > > > > The final option uses a SHA1 hash of the name as the sort key. It > > wouldn't be easy for a human to update the file by hand, but we > > could make a tool that does. I don't know how often that case comes > > up, so I don't know how important it is. See > > https://review.openstack.org/422245 and https://review.openstack.org/422246 > > for the sample output. > > Thanks Doug. I like this option. > > We don't need to add a tool as the docs describe how to do this already, which > basically boils down to run the tool you're patching. > > If that doesn't happen (which is common) the next daily update will just move > it to the new right place. > > I think we should do this early after we branch requirements > > Yours Tony. While debugging the issues, although we learned that we're less likely to have collisions by changing the order, it's not going to be sufficient to deal with the problem posed when we have an Oslo release set. Zuul is limited to managing 6 "unrelated" patches when merging, so when we have more than 6 patches trying to merge it will throw an error that looks like a conflict, even though there isn't one. We discussed (on IRC) a couple of options: One is to do away with the proposals as part of the release jobs, and rely on the daily update. I'm not sure I like that, because it means if the update fails any tests we aren't introducing new versions of our libraries quickly. Debugging that class of failure is a job we've had a hard time recruiting people to help with, so while the current team has been doing a great job staying on top of it, I worry about what will happen when they get tired of doing it. We did also discuss changing the frequency of the automatic updates, but I think I was talked out of that on the grounds that it takes us a day to get the patch reviewed and merged anyway so running it more often would introduce delays because we would lose review votes. Another option was to have the release bot continually propose updates to the same patch, like we do with the global requirements sync job. On any given day, that's going to cause a bunch of resets on the patch, until we merge it. That will be particularly annoying if we release something while the patch is in the gate queue ready to be merged, but even in the check queue it will "waste" test nodes on each reset. The third option suggested was to submit the updates in a series. That allows us to merge them one at a time, and avoids the limit-of-6 issue because the patches are all related in a series. If something fails, we can remove it from the series by hand and debug it separately. I've put this topic on the etherpad for the stable/requirements/release team meetup at the PTG. 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] [requirements] changing the order of values in upper-constraints.txt
On Wed, Jan 18, 2017 at 04:34:56PM -0500, Doug Hellmann wrote: > When I tried to merge the upper-constraints updates for the library > releases we did today, I ran into quite a lot of merge conflicts > with the Oslo libraries. I'm exploring options for reducing the > likelihood that those sorts of conflicts will occur with a few > patches that change how we generate the constraints list. Dirk's been doing a great job of dealing with that and there are scripts to take the ones generated from the bot and make single series from them n deep. That's not very sustainable though. > The final option uses a SHA1 hash of the name as the sort key. It > wouldn't be easy for a human to update the file by hand, but we > could make a tool that does. I don't know how often that case comes > up, so I don't know how important it is. See > https://review.openstack.org/422245 and https://review.openstack.org/422246 > for the sample output. Thanks Doug. I like this option. We don't need to add a tool as the docs describe how to do this already, which basically boils down to run the tool you're patching. If that doesn't happen (which is common) the next daily update will just move it to the new right place. I think we should do this early after we branch requirements Yours Tony. 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] [requirements] changing the order of values in upper-constraints.txt
On 2017-01-18 16:34:56 -0500 (-0500), Doug Hellmann wrote: > When I tried to merge the upper-constraints updates for the library > releases we did today, I ran into quite a lot of merge conflicts > with the Oslo libraries. I'm exploring options for reducing the > likelihood that those sorts of conflicts will occur with a few > patches that change how we generate the constraints list. [...original options omitted...] Have you considered following a similar pattern to requirements updates? Namely, have the job check Gerrit to find out if a constraints update change is already open. If not, create one like now. If so, retrieve the last patchset, amend it with the desired edit, and then push it back into Gerrit. This approach may be too simplified since (unlike requirements updates) these changes aren't idempotent and so could race with one another if a lot of releases happen in one go. However, in practice we only have one job node which creates these and it doesn't run any jobs in parallel, so we'd never actually see the race. Odds are we'll just implement a serializing solution for things like this (so that two jobs with the same name in some specific pipeline won't run concurrently) if we ever get to the point where we need to horizontally scale our static nodes, since we probably have more cases like this already we'll need to solve for. -- 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
Re: [openstack-dev] [requirements] changing the order of values in upper-constraints.txt
I actually like the last option (sha) the most, even as a packager I can just take the file and sort it if I want something more human readable. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital 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
[openstack-dev] [requirements] changing the order of values in upper-constraints.txt
When I tried to merge the upper-constraints updates for the library releases we did today, I ran into quite a lot of merge conflicts with the Oslo libraries. I'm exploring options for reducing the likelihood that those sorts of conflicts will occur with a few patches that change how we generate the constraints list. The first option is to insert some blank lines into the file so that we won’t be changing consecutive lines. I don't know if this will actually work, because it's not clear we have sufficient control over the git context range. Still, for the sake of argument see https://review.openstack.org/422205 and https://review.openstack.org/422251 for the sample output. The second option is one proposed by Dirk which changes the name to remove common prefix values. This one is rather simple, and it's possible explain to a human who wants to add a new line to the file by hand how to figure out where it goes. See https://review.openstack.org/45 and https://review.openstack.org/422239 for the sample. The final option uses a SHA1 hash of the name as the sort key. It wouldn't be easy for a human to update the file by hand, but we could make a tool that does. I don't know how often that case comes up, so I don't know how important it is. See https://review.openstack.org/422245 and https://review.openstack.org/422246 for the sample output. I don't expect us to change this right now, but I had the time to spend on it today and I thought it would be useful to have something put together before we get to Atlanta. 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
