*** lajoskatona_ is now known as lajoskatona | 00:31 | |
opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 3.0.1 from stable/xena https://review.opendev.org/c/openstack/releases/+/826401 | 00:40 |
---|---|---|
opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 2.6.2 from stable/wallaby https://review.opendev.org/c/openstack/releases/+/826402 | 00:40 |
elodilles | fungi: thanks for the info & the fix \o/ | 07:05 |
elodilles | fungi: though i'm not sure that the failed tag-releases will be rerun automatically, but we will see :) | 07:06 |
*** amoralej|off is now known as amoralej | 08:05 | |
elodilles | hberaud ttx : as fungi wrote during the night i think we can start approving patches, maybe one at a time to see that everything works well | 11:02 |
elodilles | i already +2'd some patches that now needs a 2nd +2 o:) | 11:04 |
hberaud | ack | 11:12 |
hberaud | I'll start reapproving patches | 11:12 |
opendevreview | Merged openstack/releases master: Release ironic-python-agent for stable/victoria https://review.opendev.org/c/openstack/releases/+/825776 | 11:23 |
opendevreview | Merged openstack/releases master: Release ironic-inspector for stable/victoria https://review.opendev.org/c/openstack/releases/+/825774 | 11:23 |
elodilles | hberaud: thx! let's see how it goes | 11:25 |
elodilles | tag-release jobs are in the queue but they haven't started yet (no new result here yet: https://zuul.opendev.org/t/openstack/builds?job_name=tag-releases ) | 11:27 |
opendevreview | Merged openstack/releases master: Release ironic for stable/victoria https://review.opendev.org/c/openstack/releases/+/825778 | 11:34 |
opendevreview | Merged openstack/releases master: release os-traits 2.7.0 https://review.opendev.org/c/openstack/releases/+/826353 | 11:34 |
opendevreview | Merged openstack/releases master: Release python-manilaclient 3.0.1 from stable/xena https://review.opendev.org/c/openstack/releases/+/826401 | 11:34 |
opendevreview | Merged openstack/releases master: Release monasca-agent for stable/victoria https://review.opendev.org/c/openstack/releases/+/825798 | 11:34 |
opendevreview | Merged openstack/releases master: Release blazar for stable/victoria https://review.opendev.org/c/openstack/releases/+/825763 | 11:34 |
elodilles | cool, they started to pass \o/ | 11:38 |
opendevreview | Merged openstack/releases master: Release horizon for stable/victoria https://review.opendev.org/c/openstack/releases/+/825773 | 11:42 |
elodilles | so the workaround works | 11:43 |
hberaud | \o/ | 11:43 |
opendevreview | Eyal proposed openstack/releases master: release new version of vitrage and vitrage-dashboard https://review.opendev.org/c/openstack/releases/+/826344 | 12:13 |
opendevreview | Merged openstack/releases master: Release python-manilaclient 2.6.2 from stable/wallaby https://review.opendev.org/c/openstack/releases/+/826402 | 12:14 |
fungi | elodilles: did that trigger the missing releases from earlier failures to get tagged as well? | 13:07 |
fungi | or do they still need to be reenqueued? | 13:07 |
*** amoralej is now known as amoralej|lunch | 13:09 | |
elodilles | fungi: no, unfortunately not as I see | 13:46 |
elodilles | these 3 jobs have failed: https://zuul.opendev.org/t/openstack/build/d8aaeff52dac442e89fd3e253596e0c2 , https://zuul.opendev.org/t/openstack/build/00d3f765ea6847a3bf7ea53294cf2a88 , https://zuul.opendev.org/t/openstack/build/a490703c83514eb7ba9d0ff6307f7371 | 13:48 |
elodilles | and as i see the tags were not created | 13:48 |
elodilles | can I somehow restart these or only you have the rights for it? | 13:49 |
*** amoralej|lunch is now known as amoralej | 13:59 | |
fungi | elodilles: i should be able to enqueue them again after i run some errands, i'll let you know once they're running again | 13:59 |
elodilles | fungi: splendid \o/ thanks in advance :) | 14:11 |
elodilles | hmmm, we have another release job failure, this time it's publish-monasca-agent-docker-images. I'll forward the mail to ML with [monasca] tag. | 14:35 |
elodilles | (here it is: http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026917.html ) | 14:40 |
sean-k-mooney | so i asked gibi this on the nova channel https://review.opendev.org/c/openstack/requirements/+/826447 need https://review.opendev.org/c/openstack/placement/+/826478 to pass but placment need the upper constraint bump to pass | 14:54 |
sean-k-mooney | any idea how we resolve that | 14:54 |
gibi | sean-k-mooney: on placement side we can relax or disbale the test temporarily | 14:55 |
sean-k-mooney | we can use depend on for requiremets to placement but we would have to bypass the upper constraits enformcent to get the placement patch to land | 14:55 |
gibi | I have no other idea | 14:55 |
gibi | but maybe the release experts have something | 14:55 |
sean-k-mooney | i was wondering if we shoudl temporally remove the upper constraits clamping and renable it in the next patch | 14:56 |
sean-k-mooney | or makign it non voting ya | 14:56 |
sean-k-mooney | the ohter option woudl be to make the test <= rahter then == | 14:57 |
sean-k-mooney | but its == intentioally | 14:57 |
sean-k-mooney | or >= im not sure what semantic we woudl want to adapt it too | 14:57 |
sean-k-mooney | for context placment has a functional test that assert the number of standard traits and that has to be updated everytime we do an os-traits release | 14:59 |
sean-k-mooney | hberaud: regarding ^ for this release we have decided to comment out the test in placment then update upper constratits and update and renable teh test in placment | 15:20 |
sean-k-mooney | so i have updated https://review.opendev.org/c/openstack/requirements/+/826447 | 15:20 |
sean-k-mooney | with a depend on to the placemtn change that disabel the test and then made the one that renebaled depned on the requirements patch | 15:21 |
sean-k-mooney | hberaud: if you can re review when you have time that woudl be great | 15:21 |
hberaud | sure | 15:28 |
fungi | sean-k-mooney: if i understand your explanation, that sounds like it could be a sign that placement and os-traits are too tightly-coupled (or at least that the placement tests aren't forgiving enough to support multiple versions of os-traits) | 15:49 |
fungi | could the testing be improved to not assume a specific trait count? | 15:50 |
sean-k-mooney | fungi: the test was added to ensure that we bumped the verison of os-traits in placment every time we did a release | 15:50 |
sean-k-mooney | placment actully does not generally care about the os-traits version | 15:50 |
fungi | and why is it important to increase the os-traits version placement requires? | 15:51 |
sean-k-mooney | fungi: well that was dicusssed before but it is internaly match because orginally that is what cdent wanted | 15:51 |
sean-k-mooney | fungi: os-traits pacakges the standard traits supported by placment | 15:51 |
sean-k-mooney | the placment api does not allow you to dynmaically add standar traits | 15:51 |
fungi | why was os-traits decoupled from placement? | 15:51 |
fungi | it sounds like they're the same codebase if they have to be released in lock-step | 15:52 |
sean-k-mooney | it was done so that nova and placment and neturon can depend on a common lib | 15:52 |
sean-k-mooney | so that nova and neutorn did not have to import placment | 15:52 |
fungi | rather than nova and neutron depending on placement | 15:52 |
sean-k-mooney | we also have the same data depency betwen placment and os-resouce-classes | 15:52 |
fungi | i guess the fundamental question there is whether it makes sense to have a library so tightly-coupled to a service | 15:53 |
sean-k-mooney | to me it the same relationship that neutron and neutorn-lib have | 15:53 |
fungi | or whether the service can be improved to be more forgiving of the library version it's consuming | 15:53 |
sean-k-mooney | the main delta is placment is making some assertion that it probaly shoudl not | 15:53 |
fungi | foe example, a way to be able to update os-traits without having to update placement at the exact same moment | 15:54 |
fungi | er, for example | 15:54 |
sean-k-mooney | fungi: what we wanted to avoid was releaseign placment in a give release without testing it with the latest os-traits and os-resouce classes | 15:54 |
sean-k-mooney | fungi: technially it change the api when you update os-traits or os-resouce clases | 15:55 |
fungi | that sounds like a questionable api choice if your library is leaking through | 15:55 |
sean-k-mooney | in that it change the set of valid standard triats and resouce classes | 15:55 |
fungi | the api definition is not entirely contained within placement in that case | 15:55 |
sean-k-mooney | well again it was done by design so that the set of standard traits and resouce were defiend external to placment, nova or other consumers | 15:55 |
fungi | and varies depending on what libs you happen to be importing? | 15:55 |
sean-k-mooney | yes more or less which is why placment only support one version fo the lib at a time | 15:56 |
sean-k-mooney | and why the test exist to enforce that | 15:56 |
fungi | can't the test be made forward-compatible? | 15:57 |
sean-k-mooney | you woudl assert traits.count >=x | 15:57 |
sean-k-mooney | we tought about that in the past but there was push back | 15:57 |
fungi | so that you can upgrade os-traits first and then upgrade placement | 15:57 |
sean-k-mooney | as they did not want to supprot multiple version of the lib | 15:58 |
fungi | the sort of circular dependency you're describing is something we've tried hard to avoid in openstack | 15:58 |
sean-k-mooney | its what has exited since plcement was split out of nova | 15:58 |
sean-k-mooney | actully it proably predates it | 15:58 |
sean-k-mooney | im wondering if we can resolve it with a mono repo or similar | 15:59 |
sean-k-mooney | althoguh proably not | 15:59 |
sean-k-mooney | the best way i can come up with is a function-next which uncaps os-traits and os-resouce-classes | 15:59 |
sean-k-mooney | and us that in the requirements repo | 15:59 |
sean-k-mooney | for chagne to both libs | 16:00 |
sean-k-mooney | fungi: we avoided this in the past by not gating on placment in the requirements repo by the way | 16:00 |
fungi | we've always tried to consider the entirety of openstack as a linear progression across all repositories, since zuul enforces a clear order of merges even between different repositories. so there at some point in time must exist a state where either newer os-traits is used with older placement, or vice versa | 16:00 |
fungi | and the assumption that people deploying openstack from the master branch tip must be able to assume that any point in time snapshot acorss all the repositories is a working whole | 16:01 |
sean-k-mooney | fungi: yep that has never been supproted unfortunetly and it only ever worked because we did not have a job to enfroce it | 16:01 |
fungi | got it. definitely sounds like a bug, just one which has been allowed to persist for a long time | 16:02 |
sean-k-mooney | yep for at least 5 years | 16:02 |
sean-k-mooney | well maybe 4 ish | 16:02 |
sean-k-mooney | ill bring it up in the nova team meeting | 16:02 |
sean-k-mooney | maybe we can combine the libs into placement | 16:03 |
fungi | the obvious solutions seem like either better decoupling between those two components, or combining them into the single component they effectively represent | 16:03 |
fungi | or re-raising a more existential question for all of openstack: whether circular/lock-step dependencies between versions of different repositories is acceptable after all | 16:05 |
fungi | in which case we'll need to revisit a lot of our assumptions about how we test changes | 16:06 |
opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Add release liaisons for manila https://review.opendev.org/c/openstack/releases/+/826496 | 16:14 |
melwitt | hi, I'm trying to bump the upper constraint for a newly released oslo.limit 1.5.0 yesterday https://review.opendev.org/c/openstack/requirements/+/826366 and it fails bc the new version has not been published to pypi. is there anything I can do to get it published? | 16:28 |
fungi | yeah, i'm working on it | 16:30 |
rpittau | hi all! After releasing ipa yesterday https://review.opendev.org/c/openstack/releases/+/826126 shouldn't we have 8.2.1 already in pypi and here -> https://tarballs.opendev.org/openstack/ironic-python-agent/ ? | 16:31 |
melwitt | thank you fungi | 16:34 |
fungi | melwitt: rpittau: impacted releases include the following... oslo.limit 1.5.0, ironic-python-agent 8.2.1, bifrost 11.2.1 | 16:35 |
fungi | i'll have their corresponding release requested reenqueued shortly | 16:35 |
rpittau | oh, thanks fungi, didn't see the discussion | 16:36 |
fungi | there was a thread on openstack-discuss about it yesterday, as well as an announcement to opendev's service-announce ml | 16:37 |
fungi | if you're curious about the details | 16:37 |
fungi | result of a gerrit regression from monday's upgrade | 16:37 |
rpittau | thanks again, going to check that | 16:38 |
opendevreview | Merged openstack/releases master: Release horizon 21.0.0(Yoga) https://review.opendev.org/c/openstack/releases/+/826362 | 16:47 |
fungi | elodilles: melwitt: rpittau: the missing release requests have been reenqueued and the tag-releases builds for all three are running in the release-post pipeline now | 16:54 |
melwitt | \o/ | 16:55 |
melwitt | itching to use the new lib | 16:55 |
rpittau | Thanks! | 16:57 |
fungi | all three succeeded so they should be available on pypi now | 17:01 |
melwitt | noiiiiice | 17:06 |
elodilles | fungi: awesome, thanks! | 17:09 |
fungi | please do let me know if things don't seem quite right there | 17:09 |
fungi | also since the release site builds are specific to a given commit and we've run these out of order, it's possible the site content won't be entirely current until the next change which merges normally | 17:10 |
hberaud | and the requirements bump is coming https://review.opendev.org/c/openstack/requirements/+/826497 | 17:12 |
hberaud | melwitt: ^ | 17:12 |
melwitt | hberaud: thanks! I already abandoned mine | 17:13 |
hberaud | ack | 17:13 |
*** amoralej is now known as amoralej|off | 17:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!