| *** thuvh1 is now known as thuvh | 07:15 | |
| *** thuvh1 is now known as thuvh | 07:28 | |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | 08:12 |
|---|---|---|
| gibi | o/ | 08:12 |
| bauzas | hola | 08:13 |
| gibi | bauzas: you mentioned things to clean up before RC1, do you have a list? | 08:13 |
| bauzas | gibi: indeed, | 08:13 |
| bauzas | https://etherpad.opendev.org/p/nova-antelope-rc-potential | 08:13 |
| gibi | bauzas: ack, on it | 08:14 |
| * bauzas is working on your comments for https://review.opendev.org/c/openstack/nova/+/874932 | 08:14 | |
| bauzas | gibi: actually, we only have the prelude and the logging revert patch to review | 08:15 |
| bauzas | (for the moment) | 08:15 |
| bauzas | also, I forgot to tell about RBAC defaults, shit. | 08:16 |
| bauzas | (in the cycle highlights) | 08:16 |
| bauzas | https://etherpad.opendev.org/p/nova-antelope-blueprint-status it wasn't in the etherpad, neither in the Antelope blueprints | 08:16 |
| bauzas | gibi: about your question about SLURP, well, maybe we should wait for dansmith to be here | 08:18 |
| bauzas | gibi: but AFAIK, we try in Nova to support a N-2 compute | 08:19 |
| bauzas | when N is a SLURP release | 08:19 |
| bauzas | gibi: dansmith tried at least to have a job for testing it | 08:19 |
| gibi | bauzas: I'm fine to make such a statement but then lets make it a clear statement somewhere that we support N-2 computes not just easing on the constraint in the code. | 08:25 |
| gibi | i.e. our change in what is supported is hard to discover as it mentioned nowhere deployer facing | 08:26 |
| bauzas | gibi: yep, I see your point | 08:32 |
| bauzas | fwiw, we haven't yet agreed on this, which should be done at the vPTG | 08:32 |
| bauzas | gibi: got a second for thinking about 2023.1 SLURP implications ? | 08:39 |
| * bauzas is reading carefully https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html | 08:39 | |
| gibi | be back in 5min to think | 08:40 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update min service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | 08:47 |
| * gibi is back | 08:47 | |
| bauzas | right in time | 08:47 |
| bauzas | I totally flipped my mind | 08:48 |
| gibi | so what I quoted from that dock is #6 | 08:48 |
| gibi | s/docks/doc/ | 08:48 |
| bauzas | yup | 08:48 |
| bauzas | see my latest revision | 08:48 |
| gibi | looking... | 08:48 |
| bauzas | my wonder is, do we have a grenade-skip-level job in place that validates our N-2 computes ? | 08:48 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | 08:49 |
| bauzas | yeah, we do | 08:49 |
| bauzas | https://github.com/openstack/nova/blob/master/.zuul.yaml#L759 | 08:49 |
| bauzas | https://zuul.openstack.org/builds?job_name=grenade-skip-level&project=openstack%2Fnova&skip=0 | 08:50 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update min service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | 08:58 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 08:58 |
| gibi | bauzas: replied inline | 09:00 |
| gibi | the current patch still proposes allowing Antelope to support Yoga computes, but it does not document it | 09:00 |
| gibi | ahh you pushed PS3 | 09:01 |
| gibi | I think my comments still valid for PS3 too | 09:02 |
| bauzas | gibi: tl,dr : I don't disagree with your very valid points, we haven't properly documented the level of support operators shall expect | 09:03 |
| bauzas | but I think I understood the pattern | 09:03 |
| bauzas | we'll remove the grenade-skip-level patch in Bobcat | 09:04 |
| bauzas | gibi: ideally, I'd clarify this in our meeting | 09:06 |
| bauzas | with dansmith and others around | 09:06 |
| gibi | ohh on that note, I might not be able to join today | 09:07 |
| bauzas | I also wonder whether we should remove the grenade-skip-level job run on check pipeline at the same time of https://review.opendev.org/c/openstack/nova/+/875621/ in https://github.com/openstack/nova/blob/master/.zuul.yaml#L759-L760 | 09:07 |
| bauzas | gibi: ok, then we'll try to discuss this first with dan before you run off | 09:08 |
| gibi | I think having a non voting skip level during Bobcat does not hurt if we clearly communicate what support (none) is expected in Bobcat for Zed computes | 09:09 |
| bauzas | gibi: I don't disagree but maybe it shouldn't be on the check pipeline | 09:10 |
| bauzas | gibi: maybe periodic + experimental | 09:10 |
| gibi | I'm fine either way. For me having a job we ignore is a non issue. I more affaraid of miscommunication of support | 09:11 |
| bauzas | and right after Bobcat RC1, we should set the job to *voting* | 09:11 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | 09:11 |
| bauzas | the point here is that I'm always context loading at every end of a cycle, this is not great | 09:11 |
| bauzas | I really want we agree on a pattern to follow | 09:12 |
| gibi | sure. have a pattern, document it, and then it is easier to follow | 09:12 |
| bauzas | so new PTLs should just copy/paste | 09:12 |
| bauzas | I'm glad we had the grenade-skip-level job running despite I completely forgot about it | 09:13 |
| bauzas | this was added way earlier | 09:13 |
| bauzas | https://github.com/openstack/nova/commit/219c360dc19f79ce7df8a92f6487aee97a64ee4c#diff-108978819c05ae183d88ec87959c2341a94cfc3f9465e3aeee82d554217b4f58 | 09:13 |
| gibi | the ptl guide has the timeline so I guess that is a good place to document the pattern to follow | 09:14 |
| bauzas | oh yeah | 09:14 |
| bauzas | I used it a lot | 09:14 |
| bauzas | + the rc1 etherpads | 09:14 |
| bauzas | I'll do a bit of scrubbing | 09:15 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 09:26 |
| sean-k-mooney | bauzas: we do not need a skip level upgrade job for 2023.2 | 09:28 |
| bauzas | yet again a violent agreement ? :) | 09:29 |
| bauzas | sean-k-mooney: see my latest rev of https://review.opendev.org/c/openstack/nova/+/875621 | 09:29 |
| sean-k-mooney | i was just reading that but i dont think we need it in the periodic | 09:29 |
| bauzas | sean-k-mooney: I'll wait for dansmith's insights on it | 09:30 |
| bauzas | if he's OK with only experimental, I'm fine. | 09:30 |
| sean-k-mooney | it technically does not need to be there either but sure | 09:30 |
| bauzas | but I'd somehow like the idea of having a periodic for ensuring we don't regress | 09:30 |
| sean-k-mooney | there are no skip level upgrades to bobcat | 09:30 |
| bauzas | I know | 09:31 |
| bauzas | :) | 09:31 |
| sean-k-mooney | cool | 09:31 |
| bauzas | (well, I loaded again the context in my mind, I dare say) | 09:31 |
| sean-k-mooney | so that job bascially is only needed half the year | 09:31 |
| bauzas | well, we had it during the whole zed cycle too :) | 09:31 |
| bauzas | my biggest concern that I raised to gibi is that it takes me always a lot of time to load again the context | 09:32 |
| bauzas | so I want to eventually write docs about it | 09:32 |
| sean-k-mooney | i think that was because that is when it was written | 09:32 |
| sean-k-mooney | but sure it should proably get listed in the ptl guide or something like that | 09:32 |
| bauzas | yup, scroll it up | 09:32 |
| bauzas | I'm on it | 09:33 |
| gibi | :) | 09:33 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/831229 was when we added the job | 09:33 |
| bauzas | it was on the yoga timeframe | 09:33 |
| bauzas | and then we left it | 09:33 |
| sean-k-mooney | i see what release was it upgrading form during zed | 09:41 |
| bauzas | gibi: sean-k-mooney: do you remember how we tracked the default policy changes from gmann ? It isn't a blueprint AFAICS | 09:41 |
| sean-k-mooney | bauzas: its a blueprint/spec | 09:41 |
| bauzas | I'm maybe blind | 09:41 |
| sean-k-mooney | well | 09:42 |
| bauzas | sean-k-mooney: I'm not talking of https://blueprints.launchpad.net/nova/+spec/policy-service-role-default | 09:42 |
| sean-k-mooney | ok so the service role was | 09:42 |
| sean-k-mooney | ya i asked for both to be blueprint/specs | 09:42 |
| sean-k-mooney | because i was unhappy with having no tracker at all | 09:42 |
| sean-k-mooney | i think its in the etherpad | 09:42 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/866218 | 09:43 |
| bauzas | wasn't tracked properly | 09:43 |
| bauzas | hence the miss for the cycle highlights | 09:43 |
| bauzas | doh | 09:43 |
| sean-k-mooney | well i responded to gmann | 09:43 |
| sean-k-mooney | i dont think it need to be in nova sycle highlights | 09:44 |
| sean-k-mooney | i think it shoudl go out in the overall release prelude | 09:44 |
| bauzas | this is anyway too late for the cycle highlights | 09:44 |
| bauzas | I'll just mention it in the prelude | 09:44 |
| sean-k-mooney | we should ahve one section that covers all the secure rbac work for all projects | 09:44 |
| bauzas | and I'll actually look at the generated relnotes to see if I missed anything else | 09:44 |
| bauzas | sean-k-mooney: don't disagreed on your point for the cycle highlights | 09:45 |
| bauzas | this is more a cross-project effort | 09:45 |
| bauzas | but let's mention the nova related implications in the prelude | 09:45 |
| sean-k-mooney | sure | 09:45 |
| sean-k-mooney | it should also be in the general release notes in the upgrades section | 09:46 |
| gibi | +1 | 09:46 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/866218/13/releasenotes/notes/enable-enforce-scope-and-new-defaults-14db8c75b263b599.yaml | 09:46 |
| bauzas | I'm pretty sure the marketing folks will handle that info correctly despite not being said in our cycle highlights :) | 09:46 |
| sean-k-mooney | i would have preferd not to have it in the cycle highlights anyway | 09:47 |
| sean-k-mooney | as i said i think its better to comunitcate this in a cross project way since it really needs to be enabled in a corrdenated way | 09:47 |
| sean-k-mooney | with that said we really do need to complete the service role this cycle | 09:48 |
| sean-k-mooney | to keep on track with the comunity goal schduel | 09:48 |
| opendevreview | Maksim Malchuk proposed openstack/nova stable/xena: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/829804 | 09:49 |
| sean-k-mooney | im going to revert the logging patch now https://review.opendev.org/c/openstack/nova/+/873584 | 09:49 |
| bauzas | sean-k-mooney: yes about the service role, but gmann still has a -W on it | 09:49 |
| sean-k-mooney | bauzas: unless you object? | 09:49 |
| bauzas | sean-k-mooney: nope, go for it, it's in the list-of-patches-to-merge-before-next-day | 09:50 |
| sean-k-mooney | cool its in the gate | 09:50 |
| * bauzas amends the prelude with gmann's untracked feature and SLURP mentions | 09:50 | |
| sean-k-mooney | this is the base of the first offical SLU release | 09:51 |
| sean-k-mooney | do we need to mentiaon anything beyond that | 09:52 |
| sean-k-mooney | we dont offically support it form yoga | 09:52 |
| sean-k-mooney | that was a test of our tooling/process | 09:52 |
| sean-k-mooney | so while it should work i would not adivse people to use it | 09:52 |
| sean-k-mooney | there wasnt an expecation taht all project support Yoga to Antelope | 09:53 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add the 2023.1 Antelope prelude section https://review.opendev.org/c/openstack/nova/+/875380 | 10:02 |
| stephenfin | sean-k-mooney: https://review.opendev.org/c/openstack/oslo.db/+/875627 that will fix the annoying warnings you've been seeing in the functional tests | 10:21 |
| *** elodilles is now known as elodilles_afk | 10:28 | |
| sean-k-mooney | nice unfortuhnetly that wont be in 2023.1 at this point | 10:37 |
| stephenfin | yeah, we'll have to backport it | 10:37 |
| sean-k-mooney | i assume once we cut rc1 tomrrow you would like your SQLA2.0 seriese to land sooner rather then later | 10:40 |
| sean-k-mooney | i.e. droping the legacy migration and the other patches you have up | 10:40 |
| stephenfin | yes, please. get it in early | 10:40 |
| sean-k-mooney | ya that is what i was thinking | 10:41 |
| sean-k-mooney | ill try and do a pass of it next week | 10:41 |
| sean-k-mooney | conf.get_location(key, group=group.name).location == | 10:43 |
| sean-k-mooney | cfg.Locations.opt_default | 10:43 |
| sean-k-mooney | so i tought here was a cleaner way to do that | 10:43 |
| sean-k-mooney | either usign in or a method to check it the option was set from the default | 10:44 |
| stephenfin | There could be. I'm simply not aware of it if so | 10:44 |
| sean-k-mooney | i have not used it personally but i vaguely recall it form the docs | 10:45 |
| sean-k-mooney | the patch looks fine to me but i just want to check if that is a thing quickly | 10:45 |
| sean-k-mooney | stephenfin: ok no you are doing it the way you are ment too https://docs.openstack.org/oslo.config/latest/reference/locations.html | 10:46 |
| sean-k-mooney | that is what i was recalling | 10:46 |
| sean-k-mooney | i tought there was an is_default() or similar | 10:47 |
| stephenfin | yeah, I explicitly wanted to raise a warning if the application (i.e. nova) was setting it too | 10:47 |
| stephenfin | since that's still wrong | 10:47 |
| sean-k-mooney | actully you could use is_user_controlled | 10:47 |
| sean-k-mooney | ah | 10:48 |
| sean-k-mooney | ok so you want to also support set_default and set_override | 10:48 |
| sean-k-mooney | so is_user_controlled is not correct | 10:48 |
| stephenfin | I want to also raise for the two of those, yes | 10:48 |
| stephenfin | exactly | 10:48 |
| sean-k-mooney | cool captured that in the review an dset Backport-Candidate on it | 10:50 |
| sean-k-mooney | im debating if having Backport-Candidate would be useful for nova et al | 10:52 |
| sean-k-mooney | is it useful for oslo? | 10:53 |
| stephenfin | not really, no | 10:54 |
| sean-k-mooney | ingeneral if the patch is not intentioanlly written to be backportable it wont be | 10:54 |
| stephenfin | The biggest problem is lack of reviewers, not lack of things to review. Also, we don't tend to make many changes nowadays so there aren't many backports | 10:54 |
| sean-k-mooney | so if its just set after the fact its probaly less useful | 10:55 |
| sean-k-mooney | ya reviews are a problem everywhere | 10:55 |
| sean-k-mooney | although oslo with all its repos proably have it wrose then most | 10:55 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Have schema for 'lock' action be applied to all microversions. https://review.opendev.org/c/openstack/nova/+/875653 | 11:46 |
| *** elodilles_afk is now known as elodilles | 12:44 | |
| opendevreview | Samuel Kunkel proposed openstack/nova master: fix: amd-sev handle missing img properties https://review.opendev.org/c/openstack/nova/+/874264 | 13:00 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | 13:03 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | 13:07 |
| ratailor_ | #openstack-nova can I get reviews for these patches https://review.opendev.org/q/Ia738a0972b050f549f446c85171d3f33e60ada4f and https://review.opendev.org/q/Id4c8c5f3b32985ac7d3d7c833b82e0876f7367c1 ? | 13:09 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Have schema for 'lock' action be applied to all microversions. https://review.opendev.org/c/openstack/nova/+/875653 | 13:20 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Have schema for 'lock' action be applied to all microversions. https://review.opendev.org/c/openstack/nova/+/875653 | 13:21 |
| *** lowercase is now known as Guest6173 | 13:42 | |
| *** lowercase_ is now known as lowercase | 13:42 | |
| lowercase | stephenfin: I looked into our next enviornment, which also contains a build_requests table with no columns. | 13:43 |
| lowercase | in an identical state to the dev | 13:43 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | 13:45 |
| lowercase | and i just checked one of my production databases, also include a build_requests in the same state. select * from build_requests; Empty set (0.000 sec) | 13:46 |
| opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/845748 | 13:52 |
| opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/845753 | 13:52 |
| opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Clean up when queued live migration aborted https://review.opendev.org/c/openstack/nova/+/845754 | 13:52 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update to the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | 13:59 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update to the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | 14:05 |
| bauzas | elodilles: I'm done with the meeting wikipage, feel free to amend it anytime you want | 14:46 |
| elodilles | bauzas: ack, thanks | 14:47 |
| elodilles | bauzas: well, actually, it is done o:) | 14:48 |
| elodilles | no need to update :X | 14:48 |
| bauzas | elodilles: I'll name you Barry Allen | 14:48 |
| elodilles | just a sec, have to google this. :S | 14:50 |
| dansmith | bauzas: why remove the grenade-slip-level job for bobcat? it's not required, but we might as well keep it.. is it because it hasn't yet been updated for zed->bobcat? | 14:51 |
| bauzas | dansmith: good question I was about getting a coffee before pinging you to ask you what you would prefer | 14:54 |
| dansmith | personally I'd rather leave it in place as much as we can, as I think it just adds extra coverage | 14:54 |
| dansmith | however, I need to look at it again, | 14:54 |
| bauzas | dansmith: okay, so we would leave non-voting in a non-SLURP branch and just make it voting after Bobcat RC1 ? | 14:54 |
| dansmith | as it might be that we need to change it so that it tests the right releases, which we can't do until after rc of course | 14:55 |
| dansmith | I would leave it voting personally | 14:55 |
| bauzas | even for like B>D ? | 14:55 |
| dansmith | yeah, I mean, | 14:56 |
| dansmith | are you thinking we'll run into issues with deprecations? | 14:56 |
| dansmith | unless it's something specifically in that test I think we'll be okay.. we've had it enabled for a while and never found any problems in nova (IIRC) | 14:56 |
| bauzas | well, | 14:56 |
| bauzas | I'm rather thinking about for example when we remove a RPC compat code | 14:57 |
| dansmith | this isn't a live test, so I don't think that will matter | 14:58 |
| bauzas | like for when removing https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L11306 | 14:58 |
| *** kopecmartin_ is now known as kopecmartin | 15:00 | |
| bauzas | anyway, if you prefer to continue the job, we could be just making it to voting, and in case after C** RC1, if we see it has some problem, then we could make it non-voting | 15:00 |
| bauzas | I mean, make it voting after Bobcat RC1, and leave it voting even after C* RC1 unless we see a problem | 15:01 |
| dansmith | sure, I mean, during bobcat it doesn't *have* to be voting, but I think it would be a good idea | 15:02 |
| dansmith | at least we'll notice what we're breaking and we can make it n-v if that's what we need to proceed | 15:02 |
| sean-k-mooney | as long as it moves to 22.04 form 20.04 so we can drop focal testing im ok with that | 15:04 |
| sean-k-mooney | i think we need that change to bump our min libvirt version which we skipped doing now for a few releases | 15:05 |
| sean-k-mooney | so we should do it in bobcat and do it early | 15:05 |
| stephenfin | lowercase: I assume you mean no rows? There should be columns. The question is if they're the columns we're expecting, i.e. `vm_state` | 15:06 |
| dansmith | ack, I think we should be able to switch it to zed->bobcat and 22.04 as soon as bobcat opens.. gmann you okay with that? | 15:06 |
| bauzas | bobcat will open in 2 days :) | 15:08 |
| lowercase | show tables; -> build_requests is present. select * from build_requests ; -> Empty set (0.001 sec) show full columns from build_requests ; -> there are about 23 columns there from a quick count. | 15:09 |
| dansmith | bauzas: I was going to say it actually matters when the relevant projects have branches, but that's the grenade holdup.. since this is two back, we should be able to do it immediately, yeah | 15:09 |
| dansmith | bauzas: the only concern would be people using the job to merge things on their rc branches that need coverage.. but I think we're going to need a grenade-skip-level-previous (or something) job anyway to keep stable happy, so maybe this is the time to practice that | 15:10 |
| bauzas | hmmm | 15:10 |
| lowercase | stephenfin: see previous response | 15:11 |
| stephenfin | lowercase: can you dump the output of 'describe build_requests;' to a pastebin? | 15:12 |
| bauzas | dansmith: have you seen my service version change ? We shouldn't longer need to use this https://github.com/openstack/grenade/blob/master/.zuul.yaml#L401 | 15:12 |
| stephenfin | lowercase: and 'select * from alembic_version;' | 15:13 |
| dansmith | bauzas: something other than 875621? | 15:13 |
| stephenfin | lowercase: This is for the next environment, of course | 15:13 |
| bauzas | dansmith: https://review.opendev.org/c/openstack/nova/+/874932 | 15:13 |
| lowercase | stephenfin: this is my qa cluster that is on xena, and is not being upgraded to yoga yet. d67eeaabee36 | 15:13 |
| dansmith | bauzas: ah, yeah I had but I didn't connect the dots | 15:15 |
| bauzas | dansmith: so are you agreeing on the change ? (like, just continuing to support Yoga) | 15:15 |
| stephenfin | lowercase: Cool, so alembic_version looks correct. Now to ensure that the columns that migration b30f573d3377 removes are present there, as expected (the 'describe' command) | 15:15 |
| bauzas | dansmith: and just after Antelope RC1, bumping the service version to Antelope | 15:16 |
| dansmith | bauzas: yeah I mean, I think I'm okay with that.. the change doesn't really change anything (other than get ready for the future with the missing service versions) right? | 15:16 |
| lowercase | stephenfin: https://paste.centos.org/view/529a12ed | 15:17 |
| dansmith | bauzas: meaning I'm happy to loosen our requirements a cycle before we officially do | 15:17 |
| bauzas | dansmith: yeah the problem that I have is that I need to understand again every cycle how we can support SLURP | 15:17 |
| bauzas | so I want to make sure we do this correctlyu | 15:17 |
| stephenfin | lowercase: Okay, they're all there as expected. I would expect the migrations to apply cleanly in that environment. So the question is how is that test environment created? | 15:19 |
| lowercase | stephenfin: the test and qa environments are created using openstack-ansible and I do a really good job ensuring it stays very close to our remaining environments | 15:20 |
| stephenfin | lowercase: In that case, I suspect either (a) someone has changed something behind alembic's back or (b) alembic ran but failed to record the updated version in the alembic_version table. I think you already ruled out (a)? | 15:20 |
| lowercase | uhh.. so i just dropped that table in test and it now errors with 1146, \"Table 'nova_api.build_requests' doesn't exist\")", "[SQL: ALTER TABLE build_requests DROP COLUMN vm_state]", "(Background on this error at: https://sqlalche.me/e/14/f405)"]} bahaha | 15:21 |
| lowercase | in test, this is the one that is going to yoga | 15:21 |
| stephenfin | lowercase: that's expected. You've modified the schema behind alembic's back. It (intentionally) doesn't do introspection. It expects the schema to be in a given state and makes changes based on that | 15:22 |
| * bauzas runs errand for a sec | 15:22 | |
| stephenfin | The only thing that should be issuing CREATE, DROP or ALTER operations is alembic. Not the operator. | 15:23 |
| lowercase | stephenfin: that's a fair statement. its just funny that im going to need to reverse engineer the creation of a table just so the script can remove it | 15:23 |
| stephenfin | lowercase: It's not removing the table - it's modifying it | 15:23 |
| lowercase | oh yep. okay i see that now. just dropping everything inside of it and emptying the schema | 15:24 |
| stephenfin | lowercase: Nah, it doesn't drop everything inside of it either. As the name would suggest, the build requests table contains build requests. A record is created in there when a build is requested. It's deleted once that build is completed (either success or failure) | 15:26 |
| stephenfin | That's why it looks empty. If you watched the table while creating instances though, you'd see stuff appearing and disappearing. | 15:27 |
| stephenfin | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L554-L563 | 15:27 |
| stephenfin | lowercase: Also, this is the schema from a Zed-based DevStack deployment https://paste.opendev.org/show/bm3psmcu51ltEvP1sT9D/ | 15:29 |
| lowercase | i just dumped the table out of qa cluster, and im using that to build the dev cluster to get it to pass | 15:32 |
| lowercase | okay, that looks pretty good.. rerunning the code! | 15:33 |
| lowercase | stephenfin: "Error: (pymysql.err.OperationalError) (1091, \"Can't DROP INDEX `shadow_instance_extra_idx`; check that it exists\")", "[SQL: ", "DROP INDEX shadow_instance_extra_idx ON shadow_instance_extra]", | 15:40 |
| lowercase | regredably, im getting swamped over here. I don't have time to look into this further. I'll take some time to look at this and get back to you. | 15:41 |
| bauzas | reminder : nova meeting in 9 mins here | 15:51 |
| bauzas | I'll also need to bail out quickly after the meeting | 15:51 |
| bauzas | #startmeeting nova | 16:02 |
| opendevmeet | Meeting started Tue Feb 28 16:02:00 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:02 |
| opendevmeet | The meeting name has been set to 'nova' | 16:02 |
| bauzas | sorry, bit late here | 16:02 |
| Uggla | o/ | 16:02 |
| elodilles | o/ | 16:02 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:02 |
| bauzas | let's start | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| dansmith | o/ | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 17 new untriaged bugs (+1 since the last meeting) | 16:02 |
| bauzas | Uggla: any bug you wanna raise ? | 16:03 |
| gibi | o/ | 16:03 |
| * gibi might need to disappeare suddenly | 16:03 | |
| bauzas | if not, let's skip | 16:03 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
| bauzas | sean-k-mooney: can you be the next bug baton owner ? | 16:03 |
| Uggla | bauzas, no nothing special | 16:03 |
| bauzas | ack | 16:03 |
| sean-k-mooney | i guess so | 16:04 |
| bauzas | cool ta | 16:04 |
| bauzas | #info bug baton is being passed to sean-k-mooney | 16:04 |
| bauzas | moving on so | 16:04 |
| bauzas | #topic Gate status | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures | 16:04 |
| bauzas | I'll be honest, I didn't had a lot of time to look at the failures | 16:05 |
| bauzas | have you seen some CI failure ? | 16:05 |
| dansmith | definitely improving | 16:05 |
| bauzas | indeed | 16:05 |
| dansmith | the volume detach on cleanup failures have all but gone away except for the live mgiration tests, | 16:05 |
| dansmith | and I have a patch up for that right now | 16:05 |
| dansmith | both of those are failures in cinder tests that have gone on for years without getting proper attention | 16:06 |
| dansmith | but they've been spiking a lot lately, so hopefully this will really improve things | 16:06 |
| bauzas | ok | 16:06 |
| gibi | glad to hear that | 16:06 |
| * bauzas looks at https://zuul.openstack.org/builds?project=openstack%2Fnova&branch=master&result=FAILURE&skip=0 | 16:06 | |
| elodilles | btw, can we expect the same for stable branches with this fix as well? (less volume detach and cleanup failures) | 16:07 |
| dansmith | elodilles: the fixes were in tempest | 16:07 |
| dansmith | elodilles: so that's branchless and should apply to stable right? | 16:07 |
| bauzas | I don't see a lot of failures for the same job | 16:07 |
| elodilles | so it means that where the tempest is not pinned | 16:07 |
| dansmith | ah, right | 16:07 |
| elodilles | (non-EM branches) | 16:07 |
| elodilles | cool, thanks! | 16:07 |
| bauzas | ok, let's then move on | 16:08 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:08 |
| bauzas | all greens | 16:08 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:09 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:09 |
| bauzas | #topic Release Planning | 16:09 |
| bauzas | #link https://releases.openstack.org/antelope/schedule.html | 16:09 |
| bauzas | #info Antelope-rc1 is in 0.2 weeks | 16:09 |
| bauzas | (which is on Thursday) | 16:09 |
| bauzas | #link https://etherpad.opendev.org/p/nova-antelope-rc-potential | 16:09 |
| elodilles | even the rc1 patches are generated! ;) | 16:09 |
| elodilles | * release patches | 16:10 |
| bauzas | elodilles cool but we need to update at least the nova one | 16:10 |
| elodilles | ack, that is expected | 16:10 |
| elodilles | don't forget to signal this (if not yet done) | 16:11 |
| elodilles | with a -1 on it | 16:11 |
| bauzas | at least we need to merge first https://review.opendev.org/c/openstack/nova/+/874932 (min servion version), https://review.opendev.org/c/openstack/nova/+/873584 (logging revert) and https://review.opendev.org/c/openstack/nova/+/875380 (reno prelude) | 16:11 |
| elodilles | (and thanks in advance o:)) | 16:11 |
| bauzas | elodilles: indeed, doing it now | 16:11 |
| bauzas | so | 16:12 |
| bauzas | about https://review.opendev.org/c/openstack/nova/+/874932 I think we are OK with how to use rolling upgrades with SLURP and non-SLURP releases | 16:13 |
| bauzas | sean-k-mooney had a concern with https://review.opendev.org/c/openstack/nova/+/875380 but we'll discuss it tomorrow | 16:14 |
| bauzas | anything people want to discuss with RC1 ? | 16:14 |
| gibi | bauzas: will you add a reno for https://review.opendev.org/c/openstack/nova/+/874932 | 16:15 |
| gibi | bauzas: it now allows Antelope to support Yoga computes | 16:15 |
| bauzas | gibi: I provided a new phrase in the prelude | 16:15 |
| gibi | which is N-2 | 16:15 |
| bauzas | gibi: but like you said, we could also modify the rolling-upgrade doc | 16:16 |
| gibi | yeah, my point is we either do a proper documented N-2 support, or we keep the N-1 check for now | 16:16 |
| bauzas | prelude patch is https://review.opendev.org/c/openstack/nova/+/875380 | 16:16 |
| gibi | but right now the code patch allows N-2 while our doc says otherwises | 16:17 |
| bauzas | gibi: okay, then I'll add a new change before we create the RC1 | 16:17 |
| gibi | in the current form I cannot +2 https://review.opendev.org/c/openstack/nova/+/874932 | 16:17 |
| gibi | as it is inconsistent with our doc | 16:17 |
| gibi | but as I said I'm OK to move the doc to match with the code or move the code to match with the doc | 16:18 |
| bauzas | gibi: so you want me to modify https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process ? | 16:18 |
| gibi | bauzas: I would like to see a consistent documentation about Antelope supports regarding old compute service versions | 16:18 |
| gibi | if we go with Antelop supporting Yoga computes then yes https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process needs a change | 16:19 |
| gibi | (or we just fall back to only support N-1 and modify https://review.opendev.org/c/openstack/nova/+/874932 to only support Zed computes in Antelope) | 16:19 |
| bauzas | cool, then I'll just add a doc modification for it in https://docs.openstack.org/nova/latest/admin/upgrades.html#rolling-upgrade-process | 16:19 |
| bauzas | shit | 16:20 |
| bauzas | add a doc modif in https://review.opendev.org/c/openstack/nova/+/874932 | 16:20 |
| gibi | OK | 16:20 |
| bauzas | do people prefer here to only support Zed instead of Yoga ? https://review.opendev.org/c/openstack/nova/+/874932 | 16:20 |
| bauzas | dansmith: sean-k-mooney: ^ | 16:21 |
| dansmith | for bobcat or antelope? | 16:21 |
| bauzas | MHO is that I'd prefer to modify the rolling upgrade document and say yes, we can support Yoga computes for Antelope services | 16:21 |
| dansmith | as I think I've mentioned, for antelope I think it would be nice to have a best-effort trial run of N-2 support, so antelope would support yoga | 16:21 |
| dansmith | yeah that ^ | 16:22 |
| sean-k-mooney | ya i think yoga makes sense | 16:22 |
| bauzas | dansmith: yeah, gibi asked either to modify the doc or not modify it but only support Zed computes with Antelope conductors | 16:22 |
| bauzas | I'd prefer the former | 16:22 |
| dansmith | yeah | 16:22 |
| sean-k-mooney | with that said for bobcat technially it should be antelope but i assume dansmith would prefer zed | 16:22 |
| dansmith | sean-k-mooney: I'd prefer we just try to do N-2 always unless we come up with a blocking reason we can't yeah | 16:23 |
| bauzas | that's another change https://review.opendev.org/c/openstack/nova/+/875621/ that needs to be merged *after* RC1 | 16:23 |
| dansmith | I think we'll be able to do it | 16:23 |
| sean-k-mooney | right whihc is not strictly requried by the governance resolution but im ok to try that until it breaks | 16:23 |
| bauzas | but looks like dansmith prefers to support Zed computes with Bobcat so meh | 16:23 |
| gibi | then modify the upgrade doc to state that in Antelope we support N-2 (Zed) computes as best effort | 16:23 |
| dansmith | sean-k-mooney: if nothing else, it'll highlight the thing(s) that prevent us from doing it, which are good for planning | 16:23 |
| dansmith | gibi: best effort is the right terminology yeah | 16:24 |
| bauzas | ok, so let's try to make the grenade-skip-level job voting | 16:24 |
| dansmith | s/make/keep/ right? | 16:24 |
| bauzas | it's n-v as I speak | 16:24 |
| sean-k-mooney | voting based on 22.04 wiht zed ->bobcat | 16:25 |
| bauzas | and only in check | 16:25 |
| dansmith | oh, I thought I looked | 16:25 |
| bauzas | only in check pipeline | 16:25 |
| dansmith | okay, I see.. yeah "make" then | 16:25 |
| bauzas | sean-k-mooney: cool then I can modify https://review.opendev.org/c/openstack/nova/+/875621/ to make grenade-skip-level *voting* | 16:26 |
| bauzas | (and adding it to the gate pipeline) | 16:26 |
| bauzas | that one would be merged *AFTER* 2023.1 RC1 to be clear, so it would be a 2023.2 change | 16:27 |
| bauzas | agreed ? | 16:27 |
| sean-k-mooney | yes | 16:27 |
| bauzas | ok, and about your point with focal, sure | 16:27 |
| bauzas | we need to test the N-2 rolling upgrade with ubuntu 22.04 only, right? | 16:28 |
| sean-k-mooney | yes | 16:28 |
| bauzas | cool | 16:28 |
| sean-k-mooney | because i want us to bump our min libvirt/qemu | 16:28 |
| bauzas | looks like we have consensus | 16:28 |
| dansmith | I think we can only switch that once we convert it to start from zed, which it doesn't currently do | 16:28 |
| * bauzas can't remember when we supported Jellyfish | 16:28 | |
| sean-k-mooney | and i htink the ones we chose last were released in 20.10 | 16:29 |
| sean-k-mooney | yes it will need to wait for changing to zed | 16:29 |
| bauzas | what's the TC supported release for Yoga ? | 16:29 |
| sean-k-mooney | which might need a grenade change | 16:29 |
| dansmith | sean-k-mooney: it will yeah | 16:29 |
| sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/yoga.rst | 16:29 |
| sean-k-mooney | 20.04 | 16:29 |
| sean-k-mooney | its technically the same for zed 20.04 | 16:30 |
| sean-k-mooney | but canoncial released zed on 22.04 | 16:30 |
| bauzas | that's what I was looking for | 16:30 |
| dansmith | I need to talk to gmann first but I will propose the skip-level job change | 16:30 |
| bauzas | so | 16:30 |
| sean-k-mooney | devstack works fin with zed on 22.04 the last time i tried it so i expect it to work | 16:31 |
| bauzas | are we saying that we would use focal or jammy for the N-2>N skip-level job ? | 16:31 |
| sean-k-mooney | focal for now jammy when we change to zed | 16:31 |
| dansmith | jammy once we upgrade to zed->bobcat | 16:31 |
| bauzas | cool | 16:31 |
| bauzas | I agree then | 16:31 |
| bauzas | #action bauzas to make our grenade-skip-level job voting after antelope rc1 on focal | 16:32 |
| bauzas | I guess we're done with that topic | 16:32 |
| bauzas | last point tho | 16:32 |
| bauzas | #info who's interested in running for being a release liaison ? | 16:32 |
| bauzas | we discussed it last week | 16:32 |
| bauzas | as a reminder, https://docs.openstack.org/project-team-guide/release-management.html#release-liaisons | 16:33 |
| bauzas | tl;dr: look at Gerrit to see whether the releases team created a patch for reviews | 16:33 |
| bauzas | and say yay or nay on that patch | 16:33 |
| bauzas | that job is basically backed by a French person that knows it for a while | 16:34 |
| bauzas | but I'd prefer not to be alone in order to avoid elodilles to hassle me with pings | 16:34 |
| bauzas | :p | 16:34 |
| elodilles | note: release liaisons are added as reviewers automatically (usually) to related release patches | 16:35 |
| bauzas | on a side note, I have a non-urgent patch for cleaning up the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | 16:35 |
| sean-k-mooney | i have done it now for 2-3 releases i can try and find time when pinged to look but if other are intereested let us know | 16:35 |
| bauzas | that may help this person to know what to look and when | 16:35 |
| bauzas | sean-k-mooney: we can have multiple liaisons | 16:36 |
| sean-k-mooney | yep | 16:36 |
| bauzas | I very briefly discuss this with Uggla and he was showing a very slight interest in that | 16:36 |
| bauzas | discussed* | 16:36 |
| bauzas | but maybe he left the meeting now, he had another appointment | 16:37 |
| sean-k-mooney | which is a good point it does not have to be a person form the core team nessisarly | 16:37 |
| auniyal | o/ I can ! | 16:37 |
| sean-k-mooney | we are not in rush | 16:37 |
| bauzas | auniyal: ack, noted. | 16:37 |
| bauzas | I'll discuss this with you later | 16:37 |
| auniyal | ack | 16:38 |
| bauzas | thanks for the offer | 16:38 |
| bauzas | moving on | 16:40 |
| bauzas | #topic vPTG Planning | 16:40 |
| bauzas | the usual now reminder | 16:40 |
| bauzas | #link https://www.eventbrite.com/e/project-teams-gathering-march-2023-tickets-483971570997 Register your free ticket | 16:40 |
| bauzas | and | 16:40 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bobcat-ptg Draft PTG etherpad | 16:40 |
| bauzas | the etherpad starts to grow | 16:40 |
| bauzas | I haven't yet been asked how many slots we gonna want for the vPTG | 16:41 |
| bauzas | be sure I'll tell you once I'm reachend | 16:41 |
| bauzas | reached* | 16:41 |
| bauzas | #topic Review priorities | 16:41 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | 16:41 |
| bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | 16:41 |
| bauzas | #topic Stable Branches | 16:42 |
| bauzas | elodilles: your time | 16:42 |
| elodilles | thanks | 16:42 |
| elodilles | actually, nothing special to report, | 16:43 |
| elodilles | #info stable gates seem to be OK | 16:43 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:43 |
| elodilles | use this if you see any new errors ^^^ | 16:43 |
| elodilles | that's all from me | 16:43 |
| bauzas | all good | 16:44 |
| bauzas | no news is good news | 16:44 |
| bauzas | #topic Open discussion | 16:44 |
| bauzas | nothing on the agenda | 16:44 |
| bauzas | I guess we can call it a wrap ? | 16:45 |
| auniyal | o/ | 16:45 |
| auniyal | There are some bugs that are either fixed but not closed for some reason or do not have much information so people can work on them (IMO), which makes our backlog big. | 16:45 |
| auniyal | Os-vif: | 16:45 |
| auniyal | https://bugs.launchpad.net/os-vif/+bug/1654117 | 16:45 |
| auniyal | https://bugs.launchpad.net/os-vif/+bug/1670628 | 16:45 |
| auniyal | https://bugs.launchpad.net/os-vif/+bug/1702262 | 16:45 |
| auniyal | fixed here: https://review.opendev.org/c/openstack/os-vif/+/479861/ | 16:45 |
| bauzas | that's a topic I added for the vPTG | 16:45 |
| auniyal | okay | 16:46 |
| bauzas | I'd like us to scrub our bug number by abandoning very old reports | 16:46 |
| bauzas | but I'd prefer to discuss it at the PTG | 16:46 |
| auniyal | ack bauzas | 16:46 |
| bauzas | and yeah, some bug reports may not be automatically closed if the gerrit patch forgot to correctly write the commit msg tag | 16:46 |
| bauzas | so the launchpad sync is not automatically done | 16:47 |
| bauzas | auniyal: feel free to close the bug report with a comment | 16:48 |
| bauzas | the status is then Fixed Released in LP | 16:48 |
| bauzas | any other questions ? | 16:48 |
| bauzas | I have to go errand in a sec | 16:48 |
| bauzas | looks not | 16:49 |
| bauzas | if so | 16:49 |
| bauzas | thanks all | 16:49 |
| bauzas | #endmeeting | 16:50 |
| opendevmeet | Meeting ended Tue Feb 28 16:50:02 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:50 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-28-16.02.html | 16:50 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-28-16.02.txt | 16:50 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-28-16.02.log.html | 16:50 |
| elodilles | thanks o/ | 16:50 |
| * bauzas disappears | 16:50 | |
| stephenfin | Weird one. Anyone have any idea why this doesn't work as expected? https://paste.opendev.org/show/bpzDcEI75QIIb9QuGFb8/ | 17:21 |
| stephenfin | If I run that, it prints out "Exception: Method 'baz' is not allowed" instead of "Exception: Method 'foo' is not allowed" as expected (baz instead of foo) | 17:21 |
| stephenfin | It's a reproducer for bug in Keystone tests. I've fixed the tests but I can't yet grok why it was happening. | 17:22 |
| gmann | dansmith: sean-k-mooney bauzas : on skip-level job. as 2023.2 is NON_SLURP so we will not run skip-level job right | 17:31 |
| gmann | in 2023.3 cycle we will run it from 2023.1 to 2023.3 upgrade on jammy | 17:31 |
| dansmith | gmann: I want nova to stick to testing N-2->N even in non-slurp releases | 17:31 |
| dansmith | gmann: perhaps I should just clone grenade-skip-level to grenade-skip-level-continuous and update that to be z->b ? | 17:32 |
| dansmith | or z->master | 17:32 |
| gmann | dansmith: ohk | 17:32 |
| gmann | so that will be on focal right as zed is tested on focal as testing runtime | 17:32 |
| gmann | zed (focal) -> 2023.2 (focal ?) | 17:33 |
| gmann | but 2023.2 on focal is not tested | 17:33 |
| dansmith | I thought zed was both? | 17:33 |
| dansmith | ah, I see, it wasn't.. dang | 17:33 |
| gmann | 2023.1 was both, let me check | 17:33 |
| dansmith | yeah, zed was just 20.04 | 17:34 |
| dansmith | well, I can try it and if it doesn't work I guess we can pung | 17:34 |
| gmann | https://governance.openstack.org/tc/reference/runtimes/zed.html | 17:34 |
| dansmith | *punt | 17:34 |
| gmann | yeah | 17:34 |
| dansmith | because sean-k-mooney wants to bump the minimum libvirt version | 17:34 |
| gmann | as 2023.1 starting was tested ion jammy so zed might work | 17:34 |
| gmann | ohk | 17:34 |
| gmann | in 2023.2 right? or bump in 2023.1 ? | 17:35 |
| dansmith | sean-k-mooney: wants to bump in 2023.2, but presumably to still include what would be needed for 2023.1 | 17:35 |
| dansmith | i.e. jammy | 17:36 |
| gmann | but is not that will be covered in normal grenade job from 2023.1 to 2023.2 ? or we want N-2 thing also due to libvirt bump ? and so does zed on jammy just because of grenade testing but main purpose is to check zed->2023.2 libvirt bump work fine or not? | 17:39 |
| dansmith | not to test the libvirt bump specifically | 17:40 |
| dansmith | but rather to keep us with a working N-2->N even though we don't *have* to support it | 17:40 |
| dansmith | if we end up breaking something and have to drop the job, then fine, but I would rather highlight what breaks N-2 upgrades if we can | 17:41 |
| gmann | ok | 17:41 |
| gmann | i think it should work as zed was the edge when we move to jammy | 17:42 |
| dansmith | yeah, will see | 17:42 |
| opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | 17:43 |
| gmann | so for that I will not filter out the 2023.2 from here (we filter out NON-SLURP here) which I do while release time https://github.com/openstack/grenade/blob/master/.zuul.yaml#L392 | 17:43 |
| opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | 17:44 |
| stephenfin | Got it. It's late binding https://stackoverflow.com/q/3431676/ Sigh, TIL | 17:44 |
| dansmith | gmann: oh hmm, that's just the thing that prevents it from running on stable right? | 17:45 |
| gmann | yeah | 17:45 |
| gmann | because it is in integrated gate template also | 17:45 |
| dansmith | yeah, so that's okay for now right? we only care about master | 17:45 |
| gmann | yes, we can adjust the integrated template not to run it for other projets does not want to run and keep generic job able-to-run-everywhere | 17:47 |
| gmann | and that is good so that project can control if they want to run or skip instead of we stop it for everyone | 17:48 |
| dansmith | gmann: well, I just inherited it for nova ^ | 17:48 |
| dansmith | if other projects want to do the same, we can add it to grenade and not the integrated jobs, but if not, we might as well keep it in nova for now right? | 17:48 |
| gmann | dansmith: ohk it need to run on jammy otherwise default one will run on focal | 17:49 |
| dansmith | right | 17:49 |
| gmann | dansmith: in that case let me filter out the base job for 2023.2 not to run so that it does not run by default as part of integrated gate and you can override 'branches' variant in nova inherited job to run on 2023.2 (master) | 17:51 |
| dansmith | gmann: yeah I assumed that was what you would do once 2023.2 opens right? | 17:53 |
| gmann | dansmith: yeah | 17:53 |
| dansmith | gmann: ubuntu-jammy is not the right nodeset? | 17:55 |
| opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | 17:56 |
| gmann | dansmith: openstack-single-node-jammy in devstck set the controller things more than just ubuntu-jammy so for devstck based job openstack-single-node-jammy will work | 17:56 |
| dansmith | okay | 17:57 |
| gmann | https://github.com/openstack/devstack/blob/master/.zuul.yaml#L11 | 17:57 |
| dansmith | I copied from tempest-tox-plugin-sanity-check which I guess is not a devstack job | 17:57 |
| * dansmith just grep'd for jammy | 17:58 | |
| opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 17:58 |
| bauzas | dansmith: sean-k-mooney: just updated the next-after-rc1 patch for make grenade-skip-level voting on both check and gate pipes | 17:58 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | 18:04 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | 18:04 |
| bauzas | sean-k-mooney: dansmith: and did the cleanups for the antelope patch | 18:04 |
| sean-k-mooney | "Nova does now currently support the | 18:49 |
| sean-k-mooney | coexistence of N and N+2 or greater | 18:49 |
| sean-k-mooney | " | 18:50 |
| sean-k-mooney | that a little clunky | 18:50 |
| sean-k-mooney | """ As of OpenStack 2023.1 (Antelope), Nova enables the | 18:52 |
| sean-k-mooney | coexistence of N and N-2 (zed) | 18:52 |
| sean-k-mooney | """ | 18:52 |
| sean-k-mooney | ill comment that inline but this is how i woudl write that. | 18:52 |
| sean-k-mooney | however while we are treating this as a dress rehersal im not sure i agree with avocating this. | 18:53 |
| sean-k-mooney | we expect it to work | 18:53 |
| sean-k-mooney | but i dont know if we want to comit to fixing issues with yoga to antelope | 18:53 |
| sean-k-mooney | i think we should consider it experimental rather then something you should use in production in general | 18:54 |
| dansmith | I haven't reviewed yet, but agree, we should make it clear that it's a best-effort thing, but I'd also be in favor of just explaining that we don't *fail* on N-2, but not go so far as saying we support it or that it's a good idea | 18:54 |
| sean-k-mooney | bauzas: comments inline https://review.opendev.org/c/openstack/nova/+/874932/4/doc/source/admin/upgrades.rst | 18:57 |
| opendevreview | Merged openstack/nova master: Fix logging in MemEncryption-related checks https://review.opendev.org/c/openstack/nova/+/873388 | 20:28 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!