| *** __ministry1 is now known as __ministry | 02:16 | |
| *** __ministry1 is now known as __ministry | 02:33 | |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/nova/+/929395 | 06:18 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/placement master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/placement/+/929397 | 06:22 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/nova/+/929395 | 06:25 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Drop SQLALCHEMY_WARN_20 https://review.opendev.org/c/openstack/placement/+/929397 | 06:25 |
| auniyal | Zuul UI updated https://zuul.openstack.org/status, looks pretty good, ++ to who ever is responsible | 06:40 |
| gibi | yeah nice UI rewamp | 07:31 |
| *** bauzas_ is now known as bauzas | 07:34 | |
| *** __ministry1 is now known as __ministry | 07:39 | |
| gibi | bauzas: do you aware that we have a blocked gate still even though the openstackclient evacuate fix is merged in https://review.opendev.org/c/openstack/python-openstackclient/+/929236 ? | 10:04 |
| gibi | do we need a new client release and a upper constraint bump? | 10:04 |
| gibi | elodilles: maybe you have more context on this ^^ | 10:06 |
| bauzas | gibi: yup, I was aware of the problem, hence my question in the #openstack-release channel | 11:53 |
| sean-k-mooney | bauzas: if your talking about th osc issue | 11:54 |
| sean-k-mooney | stephenfin just porposed a 7.1.1 release to adress it | 11:54 |
| bauzas | gibi: we need https://review.opendev.org/c/openstack/python-openstackclient/+/929402 to be merged and then creating a new release | 11:54 |
| bauzas | sean-k-mooney: okay | 11:54 |
| sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/929454 | 11:55 |
| gibi | hm 7.1.1 is released from master but we have a backport https://review.opendev.org/c/openstack/python-openstackclient/+/929402 merged to 2024.2 | 11:56 |
| gibi | so I'm a bit confused which one to consume | 11:56 |
| gibi | hm sorry 7.1.1 seems to point to the stable branch | 11:56 |
| sean-k-mooney | we willl need to pull in 7.1.1 into 2024.2's uc | 11:57 |
| sean-k-mooney | after the release | 11:57 |
| gibi | yeah that is the next step after the release then | 11:57 |
| sean-k-mooney | i just told stephen about the job failure and he is fixign the typo | 11:57 |
| sean-k-mooney | ah already done | 11:57 |
| sean-k-mooney | i could make depends on work but i think its will take about the same amount of time to get resulst that way as waitign for the release | 11:59 |
| gibi | yepp | 12:03 |
| sean-k-mooney | the reset of the stuff in this chain is more of an experiment but i would appricate if we could merge https://review.opendev.org/c/openstack/nova/+/929353 | 12:05 |
| sean-k-mooney | it took a while to figure out why activatign the docs ven and running sphinx-build worked but tox -e docs didnt but it was trivial in the end | 12:06 |
| amorin | hey nova team, is there any way to retrieve the nova instance az hints that were given during boot time other than looking in request_specs in DB? I can't find a way to retrieve that from the openstack/nova client/api | 12:24 |
| bauzas | amorin: you need to upgrade to Caracal :) | 12:36 |
| bauzas | amorin: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-2024-1-caracal-and-2024-2-dalmatian | 12:36 |
| bauzas | by microversion 2.95, it will tell you whether the instance was pinned or not to an AZ | 12:36 |
| bauzas | s/2.95/2.96 sorry | 12:36 |
| amorin | bauzas, perfect! Will take a look | 13:03 |
| amorin | do you have, by chance, link to the commits related to that? Maybe I can hack my antelope :) | 13:04 |
| amorin | no worrie, found it :) | 13:09 |
| *** ykarel_ is now known as ykarel | 14:01 | |
| *** bauzas_ is now known as bauzas | 15:17 | |
| bauzas | elodilles: frickler: so, about the OSC upgrade, I heard some good concerns | 15:26 |
| bauzas | we haven't really tested the new OSC version and we're afraid to see *other* regressions | 15:28 |
| bauzas | wouldn't it be *less* risky to let nova 2024.2 pin at OSC 6.x like we had before ? | 15:29 |
| bauzas | (discussing it here and not in #openstack-release as I'd prefer nova folks to also discuss it) | 15:30 |
| elodilles | are you aware of any (potential) regression? :-o | 15:34 |
| frickler | bauzas: well the thing is that you cannot pin osc just for nova. if you pin it for everyone, you miss out a lot of the new that has been added. so less risky, yes, but less progress, too. but essentially that's a discussion to take up with the sdk team mostly I'd think | 15:47 |
| bauzas | well, I already got scars about late bumps | 15:47 |
| bauzas | and I have very little confidence of those kind of issues not to reproduce later | 15:48 |
| bauzas | clearly the uc jobs are not proven robust enought | 15:48 |
| bauzas | enough | 15:48 |
| melwitt | was there not a requirements freeze weeks ago? https://releases.openstack.org/dalmatian/schedule.html#d-rf | 15:48 |
| frickler | reqs freeze is for external deps, it explicitly does not include openstack deliverables | 15:51 |
| melwitt | ok, I didn't see that mentioned in the link | 15:53 |
| melwitt | it seems really late to be opening upper-constraints to not yet tested versions, regardless. IMHO | 15:56 |
| dansmith | I missed that we're also discussing this here | 16:00 |
| dansmith | frickler: it seems like anything that isn't being tested against master (i.e. nova's jobs uses cinder from master) then that's fine | 16:01 |
| bauzas | most folks are now aware of the -release chat, let's move there | 16:01 |
| dansmith | for things where development happens all cycle and then pops a release at the very end that everyone depends on, there needs to be an earlier deadline | 16:01 |
| JayF | FWIW, Ironic is a cycle-with-intermediary, and we were commenting in our meeting on how we're going to frontrun our deadline as to avoid stress for folks. We do not have to deliver a final release until sometime next week. Thinking about it, I'm not sure that significant misalignment in deadlines makes sense. | 16:14 |
| * JayF knows it's not as significant of a case as we cross-test and are not a direct dependency, but another example of where our "normal practice" leads to projects the work together cutting releases weeks apart | 16:15 | |
| dansmith | JayF: but we also test nova master against ironic master right? | 16:47 |
| JayF | Yes, that's what I said, we cross-test | 16:47 |
| JayF | but this is still a gap in how we do planning, if other project are -with-intermeidary (tbh I don't know if they are) | 16:48 |
| dansmith | yeah, that's a much better place to be in than what we're discussing here, which is project that is coordinated-released but where nobody tests against its master until the last minute (apparently) | 16:48 |
| *** bauzas_ is now known as bauzas | 19:31 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!