Wednesday, 2022-01-26

*** lajoskatona_ is now known as lajoskatona00:31
opendevreviewGoutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 3.0.1 from stable/xena  https://review.opendev.org/c/openstack/releases/+/82640100:40
opendevreviewGoutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 2.6.2 from stable/wallaby  https://review.opendev.org/c/openstack/releases/+/82640200:40
elodillesfungi: thanks for the info & the fix \o/07:05
elodillesfungi: 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 amoralej08:05
elodilleshberaud ttx : as fungi wrote during the night i think we can start approving patches, maybe one at a time to see that everything works well11:02
elodillesi already +2'd some patches that now needs a 2nd +2 o:)11:04
hberaudack11:12
hberaudI'll start reapproving patches11:12
opendevreviewMerged openstack/releases master: Release ironic-python-agent for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82577611:23
opendevreviewMerged openstack/releases master: Release ironic-inspector for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82577411:23
elodilleshberaud: thx! let's see how it goes11:25
elodillestag-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
opendevreviewMerged openstack/releases master: Release ironic for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82577811:34
opendevreviewMerged openstack/releases master: release os-traits 2.7.0  https://review.opendev.org/c/openstack/releases/+/82635311:34
opendevreviewMerged openstack/releases master: Release python-manilaclient 3.0.1 from stable/xena  https://review.opendev.org/c/openstack/releases/+/82640111:34
opendevreviewMerged openstack/releases master: Release monasca-agent for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82579811:34
opendevreviewMerged openstack/releases master: Release blazar for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82576311:34
elodillescool, they started to pass \o/11:38
opendevreviewMerged openstack/releases master: Release horizon for stable/victoria  https://review.opendev.org/c/openstack/releases/+/82577311:42
elodillesso the workaround works11:43
hberaud\o/11:43
opendevreviewEyal proposed openstack/releases master: release new version of vitrage and vitrage-dashboard  https://review.opendev.org/c/openstack/releases/+/82634412:13
opendevreviewMerged openstack/releases master: Release python-manilaclient 2.6.2 from stable/wallaby  https://review.opendev.org/c/openstack/releases/+/82640212:14
fungielodilles: did that trigger the missing releases from earlier failures to get tagged as well?13:07
fungior do they still need to be reenqueued?13:07
*** amoralej is now known as amoralej|lunch13:09
elodillesfungi: no, unfortunately not as I see13:46
elodillesthese 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/a490703c83514eb7ba9d0ff6307f737113:48
elodillesand as i see the tags were not created13:48
elodillescan I somehow restart these or only you have the rights for it?13:49
*** amoralej|lunch is now known as amoralej13:59
fungielodilles: i should be able to enqueue them again after i run some errands, i'll let you know once they're running again13:59
elodillesfungi: splendid \o/ thanks in advance :)14:11
elodilleshmmm, 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-mooneyso 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 pass14:54
sean-k-mooneyany idea how we resolve that14:54
gibisean-k-mooney: on placement side we can relax or disbale the test temporarily14:55
sean-k-mooneywe can use depend on for requiremets to placement but we would have to bypass the upper constraits enformcent to get the placement patch to land14:55
gibiI have no other idea14:55
gibibut maybe the release experts have something14:55
sean-k-mooneyi was wondering if we shoudl temporally remove the upper constraits clamping and renable it in the next patch14:56
sean-k-mooneyor makign it non voting ya14:56
sean-k-mooneythe ohter option woudl be to make the test <= rahter then ==14:57
sean-k-mooneybut its == intentioally14:57
sean-k-mooneyor >= im not sure what semantic we woudl want to adapt it too14:57
sean-k-mooneyfor 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 release14:59
sean-k-mooneyhberaud: 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 placment15:20
sean-k-mooneyso i have updated https://review.opendev.org/c/openstack/requirements/+/82644715:20
sean-k-mooneywith a depend on to the placemtn change that disabel the test and then made the one that renebaled depned on the requirements patch15:21
sean-k-mooneyhberaud: if you can re review when you have time that woudl be great15:21
hberaudsure15:28
fungisean-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
fungicould the testing be improved to not assume a specific trait count?15:50
sean-k-mooneyfungi: the test was added to ensure that we bumped the verison of os-traits in placment every time we did a release15:50
sean-k-mooneyplacment actully does not generally care about the os-traits version15:50
fungiand why is it important to increase the os-traits version placement requires?15:51
sean-k-mooneyfungi: well that was dicusssed before but it is internaly match because orginally that is what cdent wanted15:51
sean-k-mooneyfungi: os-traits pacakges the standard traits supported by placment15:51
sean-k-mooneythe placment api does not allow you to dynmaically add standar traits15:51
fungiwhy was os-traits decoupled from placement?15:51
fungiit sounds like they're the same codebase if they have to be released in lock-step15:52
sean-k-mooneyit was done so that nova and placment and neturon can depend on a common lib15:52
sean-k-mooneyso that nova and neutorn did not have to import placment15:52
fungirather than nova and neutron depending on placement15:52
sean-k-mooneywe also have the same data depency betwen placment and os-resouce-classes15:52
fungii guess the fundamental question there is whether it makes sense to have a library so tightly-coupled to a service15:53
sean-k-mooneyto me it the same relationship that neutron and neutorn-lib have15:53
fungior whether the service can be improved to be more forgiving of the library version it's consuming15:53
sean-k-mooneythe main delta is placment is making some assertion that it probaly shoudl not15:53
fungifoe example, a way to be able to update os-traits without having to update placement at the exact same moment15:54
fungier, for example15:54
sean-k-mooneyfungi: what we wanted to avoid was releaseign placment in a give release without testing it with the latest os-traits and os-resouce classes15:54
sean-k-mooneyfungi: technially it change the api when you update os-traits or os-resouce clases15:55
fungithat sounds like a questionable api choice if your library is leaking through15:55
sean-k-mooneyin that it change the set of valid standard triats and resouce classes15:55
fungithe api definition is not entirely contained within placement in that case15:55
sean-k-mooneywell again it was done by design so that the set of standard traits and resouce were defiend external to placment, nova or other consumers15:55
fungiand varies depending on what libs you happen to be importing?15:55
sean-k-mooneyyes more or less which is why placment only support one version fo the lib at a time15:56
sean-k-mooneyand why the test exist to enforce that15:56
fungican't the test be made forward-compatible?15:57
sean-k-mooneyyou woudl assert traits.count >=x15:57
sean-k-mooneywe tought about that in the past but there was push back15:57
fungiso that you can upgrade os-traits first and then upgrade placement15:57
sean-k-mooneyas they did not want to supprot multiple version of the lib15:58
fungithe sort of circular dependency you're describing is something we've tried hard to avoid in openstack15:58
sean-k-mooneyits what has exited since plcement was split out of nova15:58
sean-k-mooneyactully it proably predates it15:58
sean-k-mooneyim wondering if we can resolve it with a mono repo or similar15:59
sean-k-mooneyalthoguh proably not15:59
sean-k-mooneythe best way i can come up with is a function-next which uncaps os-traits and os-resouce-classes15:59
sean-k-mooneyand us that in the requirements repo15:59
sean-k-mooneyfor chagne to both libs16:00
sean-k-mooneyfungi: we avoided this in the past by not gating on placment in the requirements repo by the way16:00
fungiwe'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 versa16:00
fungiand 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 whole16:01
sean-k-mooneyfungi: yep that has never been supproted unfortunetly and it only ever worked because we did not have a job to enfroce it16:01
fungigot it. definitely sounds like a bug, just one which has been allowed to persist for a long time16:02
sean-k-mooneyyep for at least 5 years16:02
sean-k-mooneywell maybe 4 ish16:02
sean-k-mooneyill bring it up in the nova team meeting16:02
sean-k-mooneymaybe we can combine the libs into placement16:03
fungithe obvious solutions seem like either better decoupling between those two components, or combining them into the single component they effectively represent16:03
fungior re-raising a more existential question for all of openstack: whether circular/lock-step dependencies between versions of different repositories is acceptable after all16:05
fungiin which case we'll need to revisit a lot of our assumptions about how we test changes16:06
opendevreviewGoutham Pacha Ravi proposed openstack/releases master: Add release liaisons for manila  https://review.opendev.org/c/openstack/releases/+/82649616:14
melwitthi, 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
fungiyeah, i'm working on it16:30
rpittauhi 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
melwittthank you fungi 16:34
fungimelwitt: rpittau: impacted releases include the following... oslo.limit 1.5.0, ironic-python-agent 8.2.1, bifrost 11.2.116:35
fungii'll have their corresponding release requested reenqueued shortly16:35
rpittauoh, thanks fungi, didn't see the discussion16:36
fungithere was a thread on openstack-discuss about it yesterday, as well as an announcement to opendev's service-announce ml16:37
fungiif you're curious about the details16:37
fungiresult of a gerrit regression from monday's upgrade16:37
rpittauthanks again, going to check that16:38
opendevreviewMerged openstack/releases master: Release horizon 21.0.0(Yoga)  https://review.opendev.org/c/openstack/releases/+/82636216:47
fungielodilles: melwitt: rpittau: the missing release requests have been reenqueued and the tag-releases builds for all three are running in the release-post pipeline now16:54
melwitt\o/16:55
melwittitching to use the new lib16:55
rpittauThanks!16:57
fungiall three succeeded so they should be available on pypi now17:01
melwittnoiiiiice17:06
elodillesfungi: awesome, thanks!17:09
fungiplease do let me know if things don't seem quite right there17:09
fungialso 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 normally17:10
hberaudand the requirements bump is coming https://review.opendev.org/c/openstack/requirements/+/82649717:12
hberaudmelwitt: ^17:12
melwitthberaud: thanks! I already abandoned mine17:13
hberaudack17:13
*** amoralej is now known as amoralej|off17:53

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!