Tuesday, 2021-06-29

opendevreviewMerged openstack/nova stable/ussuri: Remove broken legacy zuul jobs  https://review.opendev.org/c/openstack/nova/+/79537402:14
gibiganso: I have no +2 rights on stable branches07:03
opendevreviewYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136208:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136308:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - create arqs  https://review.opendev.org/c/openstack/nova/+/75894408:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - build instance with smartnic arqs  https://review.opendev.org/c/openstack/nova/+/79824908:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - cleanup arqs  https://review.opendev.org/c/openstack/nova/+/79805408:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - reject server move and suspend  https://review.opendev.org/c/openstack/nova/+/77991308:03
opendevreviewYongli He proposed openstack/nova master: smartnic support - functional tests  https://review.opendev.org/c/openstack/nova/+/78014708:03
lyarwoodsean-k-mooney: https://review.opendev.org/c/openstack/devstack/+/798514 btw08:32
lyarwoodhttps://bugs.launchpad.net/devstack/+bug/1933096 moved to devstack08:33
opendevreviewLee Yarwood proposed openstack/nova master: zuul: Add CentOS 8 stream integrated compute tempest job to gate  https://review.opendev.org/c/openstack/nova/+/79761608:35
lyarwoodgibi: nova-live-migration doesn't look happy on master 08:42
* lyarwood creates a gate-failure bug08:42
lyarwoodCall _is_port_status_active returns false in 60.000000 seconds08:43
lyarwoodtest_live_migration_with_trunk08:43
opendevreviewLee Yarwood proposed openstack/nova master: zuul: Skip test_live_migration_with_trunk until bug #1933954 is fixed  https://review.opendev.org/c/openstack/nova/+/79858008:56
*** bhagyashris_ is now known as bhagyashris09:15
stephenfinsean-k-mooney: gibi: bauzas: When you're all around, I'd like to pick up discussion on that availability zone issue again (I got stuck in meetings after lunch yesterday)09:31
bauzasstephenfin: I'm working on some A100 vGPU test... :(09:32
bauzasurgent query from some PM 09:32
stephenfinah, no worries, I guess I can keep it to the Gerrit review and let you respond async09:32
stephenfintl;dr: I still have concerns about recording null or the default AZ when the host doesn't belong to the availability zone09:33
stephenfinI'd be okay with overwriting the requested AZ with the hosts AZ (with a warning) if we insist on not blocking the request09:35
lyarwoodhttps://bugs.launchpad.net/nova/+bug/1933954 and https://bugs.launchpad.net/nova/+bug/1933958 smell related to me if anyone with more neutron context has time to review09:37
bauzasstephenfin: that's probably why we should only record None09:39
bauzasand not the default AZ09:39
bauzasstephenfin: so, letting the instance to be movable between AZs09:40
bauzasstephenfin: if operators want the instance to *not* be movable between AZs, they should use both --az and --host09:41
bauzasstephenfin: replied on PS1 https://review.opendev.org/c/openstack/nova/+/79814509:46
* bauzas needs to go to the gym09:46
rohit02 hi team on any openstack ussuri we are getting error while launching multiattach volume booted instance on horizon"Multiattach volumes are only supported starting with compute API version 2.60. (HTTP 400) (Request-ID: req-fd275b1c-c827-460f-9005-ff9f3d02dbb6)"09:48
rohit02is a known issue for multiattach volume type for horizon? is there any fix for this issue09:50
lyarwoodOdd, no idea why Horizon wouldn't be using 2.latest tbh09:53
lyarwoodis it configurable in Horizon?09:54
stephenfinlyarwood: Yeah, they look related. Looking at the logs for the first one (https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_8f7/771362/28/check/nova-live-migration/8f76ccd/compute1/logs/screen-n-cpu.txt) I see:09:57
stephenfin"Neutron is not new enough to perform early destination host port binding activation. Port bindings will be updated later."09:57
stephenfinwhich only happens if neutron doesn't support port bindings, apparently https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2860-L286809:58
lyarwoodcool cool, I don't see anything obvious in nova or neutron that might be causing this09:58
lyarwoodguess it might be in devstack or tempest (for the job definitions)09:58
stephenfinI'm looking at recent devstack changes as we speak10:00
stephenfinI asked on #openstack-neutron too10:00
lyarwoodta10:01
stephenfinMerge "[ML2] Change way how list of supported API extensions is made"10:03
stephenfinthat looks relevant10:03
stephenfin(from neutron)10:03
lyarwoodgah I was looking at author and not the commit date10:05
stephenfingit config :q10:07
stephenfinwhoops10:07
stephenfingit config format.pretty fuller  # <-- if you don't have it, very helpful10:08
lyarwoodwonder if that works with tig10:08
lyarwoodnope, nvm I'll just engage my brain next time10:09
stephenfin<slaweq> stephenfin yes, it seems we are missing binding-extended in the https://github.com/openstack/neutron/blob/master/neutron/common/ovn/extensions.py#L8510:10
stephenfinlyarwood: fyi ^10:10
stephenfin(from #openstack-neutron)10:10
lyarwoodCoolio10:10
opendevreviewStephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix  https://review.opendev.org/c/openstack/nova/+/79863510:15
opendevreviewStephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix  https://review.opendev.org/c/openstack/nova/+/79863510:18
kashyaplyarwood: Hi, is this soft-lockup w/ CirrOS consistently reproducible?  - https://bugs.launchpad.net/nova/+bug/193170210:31
lyarwoodkashyap: hard to say, I had to hack dumping the console log into a few runs of the job before we disabled certain tests that always failed, I've not had time to rerun things with that change reverted yet10:33
kashyapHm; I saw your comment on the console log. 10:34
lyarwoodkashyap: https://review.opendev.org/c/openstack/tempest/+/794757 and https://review.opendev.org/c/openstack/nova/+/795997 FWIW10:34
* kashyap clicks10:36
kashyaplyarwood: Thanks for the rework; and the skip makes sense for now.  To guess a non-OpenStack reproducer from the test:10:38
kashyaplyarwood: Live-migrating a guest, its disk, with an additional file-based disk should do it?10:39
lyarwoodkashyap: yeah pretty much10:39
kashyaplyarwood: Okay; thanks.  I can also ask the virt QE to add a test to this effect to this suite.  As this is a common path for OpenStack10:40
gibikashyap: do you want to talk about https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device on the todays Nova meeting? 11:13
kashyapgibi: Oh, hi.  Yes, that'd be good11:23
gibithen I will add it to the agenda11:23
kashyapgibi: Thanks for priming my memory11:23
gibino problem11:26
*** tbhchman is now known as tbachman11:29
gibistephenfin: I'm here until the top of the hour to talk about the availability zone check. Alternatively I'm here from 15:30 CEST till the nova meeting11:43
gibistephenfin: bauzas replyed in the review and I think that was how I understood the the original agreement. so --az az:host should be translated to an internal behavior to match the --host host behavior and log a warning if that host is not in the az11:47
kashyapgibi: Afraid, I might not be there for the entire meeting, as I have to run for an errand; I see it's 18:00 CET (1600 UTC)11:49
gibikashyap: I can move the topic a earlier in the agend, what is your cut of time_11:50
gibi?11:50
kashyapI can be around the first 20 mins11:50
kashyapThank you, as usual for adjusting.  I feel guilty :D11:50
gibikashyap: OK, I will move it. Don't worry11:51
kashyapThx!11:52
bauzasgibi: again, even if we do the same, the main difference between the az hack and the --host value is that for the former, we don't verify the AZ12:53
gibibauzas: but for the --host we also not verify any az as az was not even provided12:53
bauzasthat's why I would like to continue to not verify it, but saying that the instance couldn't be stuck to a specific AZ12:53
bauzasgibi: ah, correct indeed12:54
gibithat work sof me12:54
gibiworks for me12:54
bauzaskk12:54
gibiso in --az my-az:host we dont enforce my-az, we simply replace that to whathever internal data that represents --host host only12:54
gibiI don't want to say "ignore az" as I'd like to have a warning that the az is ignored12:55
gibiquestion: do we only ignore the az if the host is not in the az, or we ignore it even if the host is in the az?12:55
sean-k-mooneygibi: https://review.opendev.org/c/openstack/nova/+/797428/2 has finally passed check so im +1 on it and the preceeding patch if we want to move those forward now13:06
sean-k-mooneyoh your +2 on that bauzas ^13:06
gibiyepp I'm OK13:06
sean-k-mooneybauzas: its stephens fixs for my port delegation patch13:07
bauzassean-k-mooney: ok, I can take a look13:07
bauzasgibi: I haven't seen your question, looking13:07
sean-k-mooneygibi: thanks for reviewing those13:07
bauzasgibi: by saying --az foo:host, we make the instance movable between AZs13:08
bauzasgibi: so, the instance will land on host1 which can be on az113:08
bauzasgibi: but eventually, the instance could be moved to another host in az2 as the requested AZ eventually is "None"13:08
gibibauzas: so if --az foo:host and host in foo then we still not pin the instance to foo az toda?13:08
gibiy13:09
bauzasgibi: today, we stick to foo13:09
bauzasgibi: even if host isn't in foo13:09
bauzastomorrow, we'll stick to nothing and leave the instance be in any AZ13:09
bauzasif host is in 'bar' AZ, fine13:10
gibibauzas: ack, this works for me13:10
sean-k-mooneythe alternitive being stick to the az that host is in, reject the request or keep the current behavior13:10
sean-k-mooneyi think im ok with what bauzas  is suggesting too13:10
bauzasand like I said, if the operator wants to land on host and stick to foo, they can say --host host and --az foo13:11
bauzasthen, they'll get NoValidHosts13:11
bauzassean-k-mooney: I don't like the alternative as I don't wanna verify the AZ by the API13:11
bauzassince the AZFilter can be disabled 13:11
sean-k-mooneyits not related to the az filter13:12
bauzasand I know some ops that use forced_hosts hack but don't run AZFilter13:12
sean-k-mooneyinstance hav az without that13:12
bauzaswe only enforce AZs by the filter13:12
bauzasor by placement13:12
sean-k-mooneyno we also suport^13:13
bauzas(if the prefilter is enabled)13:13
sean-k-mooneyyep and you can disable both13:13
bauzascorrect13:13
bauzasso, you can technically use the forced_hosts hack without using AZs13:13
sean-k-mooneyalthough the filter should get deprecated this cycle and removed next cycle13:13
bauzaswhatever13:13
sean-k-mooneybut the prefilter will still be configurable 13:13
bauzaswe'll continue to verify AZs by the scheduler13:13
sean-k-mooneyalthough on by default13:13
bauzaslike the AZFilter ;)13:13
sean-k-mooneyright although we could do in the api instead13:14
bauzasno13:14
bauzasit's a breaking change13:14
sean-k-mooneyits a viald althernitive13:14
sean-k-mooneybauzas: not if its configurable although yes config driven api behavior is bad13:14
sean-k-mooneyalthough that is effectivly what we do with the filter13:14
bauzaswe said a couple of times to *not* verify the filters by the api service13:14
bauzasthe api service needs to be scheduler agnostic13:15
sean-k-mooneythis is not really verifying the filter13:15
sean-k-mooneyits verifying if the request is valid13:15
sean-k-mooneyanyway13:15
bauzasit's enforcing AZs on the API side while you could have disabled it13:15
bauzasand I have serious concerns about it13:15
bauzasbut yeah, I think we have a plan13:16
sean-k-mooneywell long term i would like to remove the ablity to diable az filtering13:16
opendevreviewMerged openstack/nova master: Fix error '404 Not Found'  https://review.opendev.org/c/openstack/nova/+/79723313:16
sean-k-mooneyand by long term i mean in Z13:16
bauzassean-k-mooney: you'll release the operator's fury13:16
sean-k-mooneywhy by default everything will be in one az13:16
bauzasAZs *have to* be optional13:16
sean-k-mooneyit wont have any impact on them13:16
sean-k-mooneyeverythign is in the nova az by default13:16
sean-k-mooneywell unles you rename the default az13:17
bauzassean-k-mooney: again, it's not a matter of AZs topology13:17
bauzassean-k-mooney: it's about the contract the user is signing off when booting13:17
sean-k-mooneyyes13:17
bauzaseither they decide to stick to an AZ or to be AZ-agnostic13:17
sean-k-mooneyi did not say you had to request it13:17
bauzashaving one big AZ won't help13:17
sean-k-mooneyi jus said we shoudl always report and filter based on it if present13:17
sean-k-mooneyif there is no az request the placement query woudl be identical13:18
sean-k-mooneybauzas: what i would like to see is the request spec az remains as None by default13:18
sean-k-mooneybut that we would alway check az if requested with the placment query13:19
bauzassean-k-mooney: some operators make use of schedule_default_az with different values on the API services13:19
sean-k-mooneyyep that would still work13:19
bauzasso they round-robin their instances between AZs by the number of workers13:19
sean-k-mooneysince that would populate the requestspec13:19
sean-k-mooneyi would just like to remove the az filer in Y and remove disabling the placment query in Z13:20
sean-k-mooneyno other changes13:20
bauzassean-k-mooney: that's a breaking change, right?13:20
sean-k-mooneybauzas: it should not be no13:20
bauzassean-k-mooney: because atm, users can ask for AZs and silently move between AZs13:20
sean-k-mooneyunless they are forcing to host with a wrong az13:20
bauzasso, at least a microversion13:20
sean-k-mooneyhow can they move between az if they asked for one13:21
sean-k-mooneywith what a forced migration?13:21
sean-k-mooneythe requst spec az wont get updated so if you asked for one at boot you will always stay inside that az unless the admin forces a migration13:22
sean-k-mooneybauzas: anyway i think im ok with your "set request spec to None" when you do the az hack proposal13:23
sean-k-mooneybut i think we evenuatlly could validate it in the api if we wanted too and as i said i think by z we shoudl just always add teh az if present in the quest spec to the placment query 13:24
sean-k-mooneymodulo perhapse if you are using an older microverion for a forced migration13:25
sean-k-mooneyalthogh im not sure about the last part, e.g. shoudl we continue to support forced migrations that break az affinity. that not todays problem however13:26
opendevreviewKashyap Chamarthy proposed openstack/nova master: libvirt: Switch the default video model from 'cirrus' to 'virtio'  https://review.opendev.org/c/openstack/nova/+/79868013:32
opendevreviewKashyap Chamarthy proposed openstack/nova master: libvirt: Switch the default video model from 'cirrus' to 'virtio'  https://review.opendev.org/c/openstack/nova/+/79868013:42
sean-k-mooneykashyap: you cant do ^ this cycle13:46
kashyapsean-k-mooney: Too late?13:46
kashyapsean-k-mooney: You mean a deprecation cycle?13:46
sean-k-mooneyno you need to recored the currnt video model this cycle13:46
kashyapOhh, right; darn13:46
sean-k-mooneythen and only then can we change the default13:46
sean-k-mooneyso you can write the patch and we can merge it early Y13:47
kashyapThere's that part...where are we w.r.t that?  I know Lee did the work for machine types13:47
sean-k-mooneycurrently we have not started on it so it13:47
sean-k-mooneyits not really hard to do13:47
kashyapsean-k-mooney: Yeah; fair enough, good point.  So the blueprint is only for Y?13:47
sean-k-mooneyyes i think so but you coudl bring it up in the team meeting later13:48
kashyapNod; I'll mark it as -W for now13:48
sean-k-mooneycurrntly the upgrade impact woudl be the dispaly woudl change on hard reboot13:48
sean-k-mooneyif people were ok with with we coudl proceed but i expect this would break some peopele hence the need to record it13:48
sean-k-mooneydownstream we could backport the recording patch13:49
sean-k-mooneybut upstream i dont think that woudl be accpeted13:49
sean-k-mooneye.g. downstream we could start recordign the video model in 16.2/train if we rally wanted or in 17/wallaby13:49
kashyapsean-k-mooney: That is record it in system_metadata, yeah?13:49
sean-k-mooneyyes13:50
kashyapNod.13:50
sean-k-mooneyyou should be able to copy paste part of lee's machine type patch13:50
sean-k-mooneyif you want to give it a try13:50
kashyapsean-k-mooney: On hard reboot - display changing shold be acceptable, no?13:50
kashyapsean-k-mooney: Yep; noted, I'll give it go13:51
sean-k-mooneykashyap: in general no. teh vm models should not change on hard reboot13:52
sean-k-mooneyit may or may not break guests13:52
sean-k-mooneyit really depens on if they have drivers13:52
sean-k-mooneyit should fall back to generic vga in this case13:53
sean-k-mooneyso it should work13:53
sean-k-mooneybut in general for other models it would nto be safe13:53
kashyapsean-k-mooney: Right; preserving the guest ABI, etc.  That's the reason also why libvirt doesn't gratuitously change things on cold reboot, though13:53
sean-k-mooneye.g. disk bus13:53
kashyapsean-k-mooney: Yep; the fallback to generic VGA should catch it.  So I don't think there'd be any visible breakage13:53
sean-k-mooneyright so we really just need to see in this case if people are ok with the upgrade impact since its mitigated by generic vga13:54
sean-k-mooneywell provided your not useing rhel 613:54
sean-k-mooneyrhel 7 shoudl be fine but rhel 6 predates the intoduction of virtio-gpu and i do not belive they have the required kernel support even with the fallback but i coudl be miss remebering that13:55
sean-k-mooneyit may have been related to one of the other email treads i just rememebr there bing an issue with virtio and rhel 6 mentioned recently 13:56
kashyapsean-k-mooney: No worries about RHEL-6 - RHEL-6 is not supported by OSP13:57
sean-k-mooneyrhel6 went to els only phase on November 30, 2020 but els exits untile June 30, 202413:57
kashyapYes; am aware of the RHEL-6/CentOS 6 thing13:57
sean-k-mooneykashyap: as a guest it is13:57
sean-k-mooneyaltough ya it woudl need els13:58
kashyapYep; 13:58
sean-k-mooneyanyway that is the onel really issue i see13:58
sean-k-mooneygibi: not that i want to reopen the owner_triat conversation but part of the reason for intoducing them was to give each service at least 1 unique tratit that only they will use14:00
sean-k-mooneyi do agree that that is the main different between nova<>cinder and nova<>cyborg14:00
gibifor me owner means the RP the trait is on cannot be touched by any other placement client, but we simply cannot enforce that semantic in placement14:08
gibiand as I said there are many undefined edges of the semantic itself14:09
viks_Hi, is there any way we can provision MAC os?14:11
viks_using openstack nova?14:11
gmannlyarwood: gibi is this know issue - test_live_migration_with_trunk failing consistently https://zuul.opendev.org/t/openstack/build/94d92ea104734ba49f6c93e17a91e3f7/log/job-output.txt#63963  14:12
gibigmann: we have port status issue before 14:15
gibigmann: let me find it14:15
gmannok14:15
gibigmann: we had this fix https://review.opendev.org/c/openstack/tempest/+/78646514:16
gmanngibi: ohk, seems it still failing. I will check logs after qa meeting14:17
gibiit is stil the parent port that remains DOWN14:17
gmannohk14:17
stephenfinviks_: Last I checked, Apple's licensing only supports MacOS on Apple hardware. Maybe you could provision Mac Minis or Mac Pros using Ironic but using VMs (via nova) don't seem likely14:29
stephenfin*doesn't14:29
sean-k-mooneyviks_: no not really you could try using uefi and q3514:34
sean-k-mooneybut baskcialy macos has some specifc hardware requirement that i dont think qemu can fully emulate14:34
sean-k-mooneyi have seen peopel hack around it in the past by modifying the apple bootloader/kernel  but its not fully supportred in qemu/libvirt and its not allowed by apples licening as stephen point out i belive14:35
sean-k-mooneystephenfin: you could run vms via nova on a mac mini but those vms would have to be windows or linux14:36
sean-k-mooneyapple has a hypervior interface in the os which qemu can use14:36
sean-k-mooneyand libvirt can manage it but i dont think we can use kvm so enable the native support currenlty via libvirt14:37
viks_stephenfin: sean-k-mooney  ok thanks14:38
kashyapviks_: sean-k-mooney: Hardware accel with QEMU + MacOS works with "-accel hvf"; I recently checked it w/ QEMU upstream14:42
kashyapviks_: I was told these instructions from Brew work in general: https://wiki.qemu.org/Hosts/Mac14:42
kashyapviks_: Oh, wait - IIUC, you want to run MacOS as a guest on x86.  14:43
viks_kashyap: ok... thanks... basically i wanted to see if i can provision mac os, either on kvm or baremetal ... and if is there any POC /doc related to it in openstack14:46
kashyap(Nod)  Upstream QEMU has MacOS as part of its CI14:46
kashyapBut no robust testing, IIUC14:47
* kashyap --> needs to go into a meeting14:47
viks_kashyap: ok... thanks14:48
sean-k-mooneykashyap: yep and they also recently added apple silicon support15:08
stephenfinslaweq: That failure on https://review.opendev.org/c/openstack/nova/+/798635 looks unrelated. Looks like https://review.opendev.org/c/openstack/neutron/+/798634/ did the trick. Thanks!15:10
slaweqstephenfin thx for info :)15:10
sean-k-mooneyslaweq: that should not have broken things by the way but yes https://review.opendev.org/c/openstack/neutron/+/798634/ should fix it15:12
sean-k-mooneyslaweq: we still technically support live migration without binding-extended since we cannot yet make that a mandaory requriemetn on the neutron side15:13
sean-k-mooneyslaweq: it would be really nice to make it mandatory going forward but we need neutron to provide a way to do that 15:13
slaweqsean-k-mooney You mean to somehow force it on all plugins/drivers to support it, right?15:14
sean-k-mooneyslaweq: yes we need a way to intoduce mandatory extesions or move some of the current ones to be core extentions15:15
sean-k-mooneyso that we can stop supporting nuetorn backends that dont support it15:15
slaweqyeah, that would be good thing15:15
sean-k-mooneythis would require contrail to finally add support for it15:15
slaweqmaybe this could be good topic for cross project session on the next PTG? :)15:16
sean-k-mooneyi have for the last 3-4 ptgs already15:16
sean-k-mooneybut i can i ask for this every time15:16
sean-k-mooneywe would basically just have to agree a process for graduation of extnsions to the core api15:17
sean-k-mooneythen for Y declare the following set will be added 15:18
sean-k-mooneybasically give one upstream cycle at a minium to ensure all backend support the new ones15:18
slaweqthe problem is that we will be loud about it in the community15:19
sean-k-mooneythen nova could drop support in say Z and issue deprecation warnings  in Y when the required exttion is not found15:19
slaweqand finally someone will still miss announcement and will complain :)15:19
sean-k-mooneywell we acidentally drop support for live migratrion without binding extened15:19
slaweqmaybe You could propose some initial draft of spec so we can discuss it there?15:19
sean-k-mooneyand it took 14 months or so for peopel to complain15:20
sean-k-mooneyso yes they will but maybe not promptly15:20
sean-k-mooneyslaweq: sure is can propsose something15:20
slaweq++ thx15:20
slaweqI will then ensure that neutron team will review it :)15:21
sean-k-mooneydo ye have a Y or backloag folder. i can propsoe it against xena but i dont really expect us to do anything concret this cycle15:21
sean-k-mooneywell other them maybe agree the driection15:21
sean-k-mooneyslaweq: by the way when is the neutron team meeting have you discussed the os-vif per-port bridge topic15:22
sean-k-mooneyslaweq: ill be brining that up in the nova meeeting later15:22
slaweqwe had that meeting 1h ago15:22
slaweqand ralonsoh raised that issue15:22
slaweqhe will follow up with spec for that too15:22
sean-k-mooneyack ok i can sync with him15:23
slaweq++15:23
* bauzas is depressed to see yet another virtual PTG :( 15:24
sean-k-mooneyhas that been annouched15:25
* gibi is just depressed in general15:27
kashyapbauzas: Yeah; it sucks; but at least we see some "light at the end of the tunnel" and are not stuck in long virus waves.15:29
bauzassean-k-mooney: yup, one hour ago15:30
bauzaskashyap: I understand the reasoning behind the decision but this hurts15:30
bauzasI can just hope all the contributors could be vaccinated sooner than later so we could just ask them some kind of passport to travel15:30
bauzasgibi: another thought, I need to leave by 6:15pm our time15:34
bauzasif we can do a quick meeting, that'd be lovely15:34
gibibauzas: I will try to be quick15:34
gibiand thanks for the headsup15:34
sean-k-mooneyi have one networking topic to bring up in open discuss but apparently its going to be a spec now instead of a bug so i guess it will be an fyi.15:36
sean-k-mooneyand review the spec15:36
sean-k-mooneyslaweq: by the way we had planned to treat it as a bug because i didn tno really want to do a downstream only backport of this though we can disucss later15:37
gibisean-k-mooney: ack15:46
gibinova meeting starts in 5 minutes here in the channel15:54
opendevreviewMerged openstack/nova stable/ussuri: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/79671915:55
opendevreviewStephen Finucane proposed openstack/nova master: scheduler: Remove 'USES_ALLOCATION_CANDIDATES'  https://review.opendev.org/c/openstack/nova/+/77364015:59
opendevreviewStephen Finucane proposed openstack/nova master: scheduler: 'USES_ALLOCATION_CANDIDATES' removal cleanup  https://review.opendev.org/c/openstack/nova/+/79751315:59
opendevreviewStephen Finucane proposed openstack/nova master: scheduler: Remove 'hosts_up'  https://review.opendev.org/c/openstack/nova/+/77364115:59
opendevreviewStephen Finucane proposed openstack/nova master: trivial: Remove FakeScheduler (for realz)  https://review.opendev.org/c/openstack/nova/+/77364215:59
opendevreviewStephen Finucane proposed openstack/nova master: scheduler: Merge 'FilterScheduler' into base class  https://review.opendev.org/c/openstack/nova/+/77364315:59
opendevreviewStephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers  https://review.opendev.org/c/openstack/nova/+/77364515:59
opendevreviewStephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager  https://review.opendev.org/c/openstack/nova/+/77364415:59
opendevreviewStephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils'  https://review.opendev.org/c/openstack/nova/+/77364615:59
opendevreviewStephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases  https://review.opendev.org/c/openstack/nova/+/77364715:59
kashyapgibi: BTW, I don't need to rush; so take your time.  I cancelled my errand15:59
gibi#startmeeting nova16:00
opendevmeetMeeting started Tue Jun 29 16:00:06 2021 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
stephenfino/16:00
* kashyap waves16:00
gibikashyap: OK, then I will do the normal agenda and your topic will be part of the Open Discussion16:00
kashyapYes, that's fine.16:00
bauzas\o16:01
gmanno/16:01
gibibauzas asked for a quick meeting so lets start16:01
gibi#topic Bugs (stuck/critical) 16:01
gibino critical bug 16:01
gibi#link 22 new untriaged bugs (+1 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New16:01
gibiany bug we need to talk about today/16:02
gibi?16:02
stephenfinlyarwood spotted a bug earlier this morning. We think it's basically fixed now. Just waiting for the neutron patch to merge (thanks slaweq)16:02
stephenfinuntil that merges though, the gate is stuck (the live-migration job will fail)16:03
stephenfin(https://review.opendev.org/c/openstack/neutron/+/798634/ is the fix, btw)16:03
gibistephenfin: thanks16:04
gibiany other bug to mention?16:04
sean-k-mooneystephenfin: that job should not fail16:05
sean-k-mooneywe should fall back to the old way without mulitple port bindings16:05
sean-k-mooneyit might fail on stable branches if we have not backported the fix16:05
stephenfinmaybe not, but it does and I haven't had time to figure out why 🤷16:05
sean-k-mooneywell we should since that means contrail is broken16:06
gmannone test failing is this which is port status gibi mentioned before meeting https://be2e92e10ead782aa651-35e07a4cf42cfaed2fcffa4bf0b16f1b.ssl.cf1.rackcdn.com/794757/9/check/tempest-multinode-full-py3/94d92ea/testr_results.html16:06
sean-k-mooneythey do  not support it.16:06
gmannis that same? 16:06
stephenfinyes, I think so16:06
gmannok16:06
sean-k-mooney so we proably want to hold the neutron patch till we fiture this out or propose a revert so we can debug16:07
sean-k-mooneywell the neutron patch is correct16:07
gibiif the neutron fix is needed anyhow then I vote for merging it and troubleshoot on a revert if needed16:07
sean-k-mooneyso proably the latter propose a revert so we can figure out why it failed16:07
stephenfinyeah, what gibi said16:08
gibias we anyhow moved to the gate status lets move there by topic as wel16:08
gibil16:08
gibi#topic Gate status 16:08
gibiNova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure16:09
sean-k-mooneya reguression of this is effectivly a critial nova bug just an fyi16:09
gibiplease tag bugs with gate-failure so that we can follow them there16:09
gibiplacement weekly jobs are green #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly16:10
gibianything else on the gate status?16:10
gibi#topic Release Planning 16:11
gibiMilestone 2 is in 3 weeks (15 of July) which is spec freeze16:11
gibiSpec review day is 6th of July #link http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023083.html16:11
gibiand as you saw on the ML the next PTG time is set to October 18-22 16:11
gibiand it will be virtual still16:12
gibiany other news on the incoming release?16:12
sean-k-mooney:( i dont think so16:12
dansmithsean-k-mooney: what is the sadface? virtual ptg?16:13
sean-k-mooneyyes16:13
bauzasyup16:13
bauzas:( :( :( even16:13
dansmithheh, okay16:13
gibiwe should have a terapeutic session in the PTG16:14
gibianyhow moving on16:14
gibi#topic Stable Branches 16:14
gibistable gates should be OK (though 'wait_for_volume_resource_status' intermittently fails)16:14
gibiEOM (from elodilles )16:14
gibiany other stable news?16:14
elodillesnothing from me for now16:15
dansmithsame failure on master a bunch too I think16:15
dansmiththe cinder peeps were working on it a couple weeks ago16:15
gibiyeah I think lyarwood is still trying to see what happens in the guest that prevents detaching a volume16:15
dansmithwell, the cinder peeps were thinking it was an lvm segv or something16:16
dansmith(on the host)16:16
sean-k-mooneyhave we check that the falvor have at least 2 cores. its really just a workaroudn but i think that help downstream at one point with the guest not respondind to the detach16:16
gibidansmith: could be multiple indendependent failure I only hit the detach one last week but I'm did not looked at CI results recently16:17
sean-k-mooneyi mean 1 shoudl really be enought but sometiems if the guest has 2 cores it will still be abel to repsond if its hung on other thngs16:17
dansmithgibi: yeah, they already fixed one thing that manifested in the same way I think, which was specifically timeout related IIRC16:18
dansmithbut the latest was lvm crashing I think16:18
dansmithanyway16:18
gibidansmith: thansk that is good info16:18
gibisean-k-mooney: good idea16:18
gibimoving on 16:18
gibi#topic Sub/related team Highlights16:18
gibibauzas: are you still with us?16:18
bauzasyup16:18
bauzasnothing to report, sir.16:19
gibithen 16:19
gibiLibvirt (bauzas) 16:19
gibiack16:19
gibithanks16:19
bauzasthis^ 16:19
gibi:)16:19
gibimoving on16:19
gibi#topic Open discussion 16:19
gibi(kashyap) seeking approval for the specless bp https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device16:19
kashyapgibi: So on that:16:19
gibiI think this was discussed today on the channel16:19
kashyapI was reminded that we can't do the switch in the current devel cycle16:19
kashyapBut we need some preperatory work for Y release16:20
kashyapE.g. recording the video model in system_metadata.  Get the tests sorted, and then do the switch.16:20
gibiOK, so then for X you only aim for the recording and testing then switch in Y16:20
dansmithwhy do we need to record the video model16:20
dansmith?16:20
sean-k-mooneyto prevent it chanigng for exisating vm after upgrade and hard reboot16:21
gibiI think it is to avoid changing ABI to the gues during hard reboot16:21
kashyapdansmith: Upthread, sean-k-mooney was saying it might16:21
sean-k-mooneyyes that ^16:21
kashyapBut:16:21
dansmithis that because we're changing our default?16:21
dansmithoh16:21
kashyapThere won't be any _visible_ breakage here: 16:21
kashyapdansmith: Yep16:21
dansmithI thought the spec was adding it as an option, this is for changing the default, I see16:21
kashyapSorry, I should've given a summary here.16:21
kashyapdansmith: The first sentence of the BP says: "Change Nova's default video display from 'cirrus' to 'virtio'." :-)16:22
sean-k-mooneydansmith: ya we added virtio i think in train16:22
sean-k-mooneyso in this specific case it actuly might be safe to jsut make the change16:22
sean-k-mooneybecause fo vga fallback mode16:23
kashyapYeah16:23
dansmithwell, I was going to say, i think we've made such changes in the past after some interval16:23
sean-k-mooneybut in general for device model default changes16:23
sean-k-mooneywe woudl have to recored then change16:23
kashyapdansmith: To summarize the above:16:23
kashyapIf your guest has the kernel driver, then "virtio" display dev will make use of it; or else, it'll gracefully fallback to VGA 16:23
sean-k-mooneydansmith: the only one i can think of was enabling the RNG by default16:23
kashyapSo that's the recommended option from the QEMU graphics maints16:23
kashyapsean-k-mooney: Yep16:24
dansmithkashyap: fall back to cirrus?16:24
kashyapdansmith: No, no; fall back to "VGA compatibility mode", which is still better than "cirrus"16:24
sean-k-mooneydansmith: no the virtio-gpu device support a vga hardware interface16:24
dansmithokay16:24
sean-k-mooneydansmith: you just wont get all the fatures but it shold funciton simialr to cirrus in the guest16:24
kashyapI.e. standard VGA.16:24
kashyapYes16:25
bauzasdo operators would opt into it ?16:25
dansmithyeah, but that might freak out a windows machine if your display adapter suddenly changes I guess16:25
bauzasor would we need to change the default automatically ? 16:25
kashyapbauzas: No; they can opt out of it here.16:25
sean-k-mooneydansmith: on reboot it should be ok but that was the upgrade concern that would prompt recored then change next cycle16:25
bauzasI understand dansmith's concern about freaking out if done automatically16:25
kashyapbauzas: Yes, we should do the right thing here by changing the defaul.16:25
sean-k-mooneykashyap: not for existing instahce you need to use hw_video_model in the image16:26
kashyapbauzas: dansmith's good point is for Windows16:26
kashyapsean-k-mooney: Right; obvious the default implies only for the new ones.16:26
sean-k-mooneyso tl;dr recored in X change in Y ?16:26
kashyaps/obvious/obviously,/16:26
dansmithso the problem is for people who don't have hw_video_model in their image meta right?16:26
kashyapsean-k-mooney: But _do_ we need to record at all?  As there's no breakage here16:26
sean-k-mooneydansmith: correct16:27
dansmithcan we just create all new instances with that set to the default if they don't have it in their image?16:27
dansmiththen we're good for next time too when we switch to whizbang32 video16:27
bauzascan't wait for it16:27
dansmithcompute assumes cirrus if unset forever, otherwise honors what it's set to, and then we can make the switch now for any new instances16:27
sean-k-mooneydansmith: not really but we can store our default in the instance_system_metadata16:27
sean-k-mooneywhich is what we are now doing for machine_type as if it was set in the image16:28
dansmithsean-k-mooney: not really? we mirror image meta in sysmeta already right? so we'd just be using that instead of a bespoke key?16:28
sean-k-mooneydansmith: ya so we can set it in our copy which is what kashyap was going to do16:28
dansmithmirror *some* of image_meta I mean16:28
sean-k-mooneywe just cant set it in glance unless we just document use the glance import plugin to set it on all uploaded images16:29
dansmithack, okay, then we don't need a warning cycle to switch the default if we do it that way16:29
dansmithsean-k-mooney: right I'm talking about our local copy (of course)16:29
sean-k-mooneydansmith: so unless we backport the recording of the current value we would still need one cycle16:29
dansmithwhy?16:29
sean-k-mooneyto populate the instance_metadata_table for exisiting instnaces16:30
kashyapsean-k-mooney: Yeah, why?  I still don't see it.16:30
dansmithno, we just assume cirrus forever if unset16:30
sean-k-mooneyoh16:30
sean-k-mooneythat just means dont change the default16:30
dansmithpast the virtio default, it'll always be set to something, so if set, honor that, else cirrus (but just on the compute).. new instances always get virtio set explicitly by default on create16:30
kashyapdansmith: So we can even directly change w/o even recording it in system_metadata, as we did for virtio-rng (I'll get the commit later for you to read)16:30
sean-k-mooneydansmith: that will complicate the inital spawn logic and posibel hard reboot16:31
dansmithkashyap: okay not sure how, but happy to look16:31
sean-k-mooneyit might be doable but we reuse span in hard reboot16:31
* bauzas needs to disappear16:31
dansmithsean-k-mooney: just spawn, AFAIK, which seems fine as we record other such things IIRC, but whatever16:31
kashyapdansmith: https://opendev.org/openstack/nova/commit/de512f2c02516:32
sean-k-mooneyso we will need to tell the different betweeen first boot and subsequint16:32
dansmithjust trying to avoid needing a cycle to change *and* annotate all existing instances16:32
kashyap(It's slow to load)16:32
sean-k-mooneydansmith: i guess we could try and implement that and see what it looks like16:32
dansmithwe can talk outside the meeting about it16:32
kashyapYeah16:32
kashyapThanks for the design discussion so far!16:33
kashyapgibi: Any other topics?  We can hash it outside of the meeting16:33
gibiOK. then I hold on approving the bp until you agree on the way forward16:33
gibisean-k-mooney has one more headsup I think 16:33
gibiso moving on to that16:33
gibisean-k-mooney: 16:33
sean-k-mooneyyes so ovn migration...16:33
sean-k-mooneyam tl;dr is architeutlaly there is alwasy a race when doing live migartion with ovn16:34
sean-k-mooneyeffectivly ovn can only start installing rule when the tap is created on the dest16:34
sean-k-mooneyand at that point we have called libvirt to do the migration and its incontol16:35
sean-k-mooneyto to avoid that and create the port in prelive migration im proposing an os-vif change16:35
sean-k-mooneybaiscly reinotduce hybrid-plug btu with ovs bridges and patch port instead of linux bridges and veth pairs16:35
sean-k-mooneythat will not have any perfromance impact on the vm16:36
sean-k-mooneybut will allow ovn to isntall the rules in prelive migrate16:36
sean-k-mooneyi was wondering how people felt about that16:36
gibihonestly it is too deep networking to me. I assume the impact is mostly in os-vif. Does nova needs to be adapted?16:37
stephenfinso previously, we had16:37
stephenfin(ovs bridge)  veth | <---> | veth (linux bridge) tap | <---> | VM16:37
stephenfinand now we'll have16:37
stephenfin(ovs bridge)  patch | <---> | patch (ovs bridge) tap | <---> | VM16:37
stephenfinso everything stays in OVS but there's an additional (on top of br-int) bridge?16:37
sean-k-mooneymore like (ovs bridge) tap | <---> | VM orginally to (ovs bridge)  patch | <---> | patch (ovs bridge) tap | <---> | VM16:38
sean-k-mooneyyes16:38
sean-k-mooneythis is the poc but it has a bug (ovs bridge)  patch | <---> | patch (ovs bridge) tap | <---> | VM16:38
sean-k-mooneyhttps://review.opendev.org/c/openstack/os-vif/+/79805516:38
sean-k-mooneycurrently its configurable and defualting to true for development16:39
stephenfindo we need to worry about flows getting added for the patch <-> tap in the second (new) bridge?16:39
stephenfinor does that happen automatically?16:39
sean-k-mooneystephenfin: just the normal action16:39
sean-k-mooneyso no rules required16:39
sean-k-mooneyon the neutron side if we wanted to proceed there woudl need to be some qos changes for ovn16:39
sean-k-mooneyso that will be covered by a spec16:39
sean-k-mooneyif we are ok with this on the nova side i would like to track the capablity as a bug against os-vif16:40
sean-k-mooneyso we can backport the ablity to opt in tothis behavor but not use it by default for stable branches16:40
stephenfinexcellent, so we'll pre-populate a flow in the br-int for the new patch port, and then the comms from the other side of the patch port to the VM don't need anything explicit bar the normal action16:40
stephenfinthat wfm, personally16:41
stephenfincertainly seems better than re-adding hybrid plug with the OVS -> linux bridge -> VM dance16:41
sean-k-mooneyi guess may main question is bug blueprint or spec for this16:41
stephenfinI would like to see some high level docs on this _somewhere_16:43
gibihm, if this requires a neutron spec, then why do you need to backport the os-vif change to stable?16:43
sean-k-mooneypersonally i would prefer to leave this bake for a cycle and enable it by default next cycle16:43
sean-k-mooneygibi: the neutorn spec is to fix QOS support16:43
stephenfinit could be a blueprint but docs in the neutron tree might be better16:43
* gibi is slow16:43
gibisean-k-mooney: ahh OK I see16:43
sean-k-mooneyit would be useful for those that dont need qos without that16:43
gibiyepp now I got it16:43
gibithis is a bugfix for os-vif to support live migration with OVN16:44
gibior more preciesly fix a race in live migration16:44
gibiI can live with this as a bugfix16:44
sean-k-mooneyyes basically16:44
sean-k-mooneyand thats also why we woudl default this to off intially and then enable it by default in the future16:45
gibiany objection?16:45
sean-k-mooneyoperators can opt in early if they want but not change any behavior by default16:45
stephenfinI'm good. Can't speak for others tho16:46
gibiI don't see any hands raised :)16:46
sean-k-mooneywe can defer if peopel want to think about it more16:46
sean-k-mooneyim still working on the poc16:46
sean-k-mooneymy main concern is m2 and spec freeze16:47
gibiit is accepted as a bug now, here. If somebody later has an objection the we can rediscuss but until that this is a bug16:47
gibiIs there any other topic for today 16:47
sean-k-mooneynot form me16:48
gibithen let's close this16:49
gibithanks for joining16:49
gibi#endmeeting16:49
opendevmeetMeeting ended Tue Jun 29 16:49:07 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:49
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.html16:49
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.txt16:49
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.log.html16:49
elodilleso/16:49
gibifeel free to continue the video mode discussion16:49
gibiI will drop now but will read back tomorrow16:49
sean-k-mooneywell quickly the live migration issue https://review.opendev.org/c/openstack/nova/+/742180 should have fixed that16:49
sean-k-mooneythis is what previously broke live migration without binding-extended16:50
sean-k-mooneybut that is still fully supported so droping binding-extended form ml2/ovn shoudl not result in job failures16:50
sean-k-mooneyunless we are talking about cross-cell migration16:50
kashyapThanks for running it, gibi.16:50
sean-k-mooney*cross-cell resize16:50
dansmithsean-k-mooney: so, looking at the build process, it surely seems like the libvirt driver could just look at vm_state==BUILDING in spawn and annotate the desired default going forward16:51
dansmithdoesn't seem overly complicated to me16:52
dansmithunless I'm missing elsewhere that we might be building but not want to do that16:52
sean-k-mooneydansmith: ya i was thinking about that later in the meeting16:52
sean-k-mooneyi think your right we can detech inital spwan16:52
dansmithyeah, so IMHO that'd be the way to go16:53
sean-k-mooneydansmith: the quistion that i have is wether we can detect it in a place that is within the virt driver that also has the required info16:53
opendevreviewRodrigo Barbieri proposed openstack/nova stable/train: Error anti-affinity violation on migrations  https://review.opendev.org/c/openstack/nova/+/79871716:54
sean-k-mooneyi dont belive it will still be in building when we are generating the xml16:54
dansmithwell, it's set to building right before we get our spawn called16:54
sean-k-mooneyyes but we might need to pass down a flag internally in the driver16:54
dansmithsean-k-mooney: we don't need to detect it while building the xml do we? we can go ahead and annotate the instance right in spawn() so it's there later for the xml building no?16:54
sean-k-mooneydansmith: the default depens on the image and flavor and config values16:55
dansmithif instance.vm_state == building: instance.system_metadata['image_hw_whatever'] = $default; instance.save()16:55
sean-k-mooneydansmith: e.g. if different based on architrues and a few other things16:55
dansmithsean-k-mooney: it does?16:55
dansmithoh sure, okay16:55
dansmithbut still, I think you have all that in spawn I would guess16:55
sean-k-mooneyyes proably let me check quickly16:56
dansmithyeah we actually build the xml right in spawn,16:56
dansmithso I think we should be fine, even if you want to pass a flag to get_guest_xml() from there instead of having it look or something16:56
sean-k-mooneyits basically decided here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5912-L595116:57
sean-k-mooneyin  _add_video_driver16:57
dansmithsure, so we could break out the "which video" part from the actual xml bit and just call it to get the model name we need to use separate from the xml part16:57
sean-k-mooneyyep or just call that directly16:58
dansmithit returns an xml node or something doesn't it?16:58
sean-k-mooneybut ok16:58
dansmithanyway, regardless.. I think it's not hard16:58
sean-k-mooneyyes well it returns one of our config objects16:58
sean-k-mooneyLibvirtConfigGuestVideo i think https://github.com/openstack/nova/blob/25e218484990b41485973fab86adf5afc21dd476/nova/virt/libvirt/config.py#L205216:59
dansmithyeah17:00
sean-k-mooneyso we can jsut get the type filed value if we need too17:00
sean-k-mooneyso as a general pattern you would advise 17:00
sean-k-mooneyupdate the default on new instance creation and recored in instance_system_metadata17:00
sean-k-mooneyand then just use that value in all other spawn cases17:00
dansmithyup17:01
sean-k-mooneyin this case though virtio will work in all configuration i belive17:01
sean-k-mooneyso we really just need to check if tis build and if tis set in the image17:02
sean-k-mooneyif not set it in the image metada copy we have17:02
dansmithwell, I'd really say we should avoid breaking sensitive windows vms by changing anything much17:03
sean-k-mooneyso basiclly image_meta.properties.set('hw_video_model', image_meta.properties.get('hw_video_model'))17:04
sean-k-mooney* image_meta.properties.set('hw_video_model', image_meta.properties.get('hw_video_model', 'virtio'))17:04
dansmithhttps://www.howson.pro/content/images/2016/07/sound-popped-up-after-fi.png17:04
dansmithdon't want that on your cloud instance :P17:04
sean-k-mooneyhehe no that would be awkward17:05
sean-k-mooneyi mean you can attach a cinder volume as a driver disk but it sucks17:06
dansmithlet us not go there :)17:06
* dansmith goes to request "attach disk as floppy for win95" in cinder lp17:07
sean-k-mooneyyou can kind of do that today actully but its really inovlved and convulted17:08
dansmithlol17:09
sean-k-mooneydansmith: so 1.) set new default in image metata copy on new spawn. 2.) keep current logic in driver which will use the image vaule preferencally if set. 3.) recored value if not in image after its calulated for exising instance?17:10
sean-k-mooney3.) would only run once per instance the first time they hard reboot17:10
sean-k-mooneyand after that it just uses what in the insance_system_metadata17:11
sean-k-mooneythen rise and repeat taht for any default we want to change like this in the future17:11
sean-k-mooneyis that about right ^ if so it would be nice to add to the contibutors docs17:12
sean-k-mooneyi can proably submit a patch for that17:12
dansmithwell, I was going to say just always assume cirrus if it's not set17:13
dansmithinstead of "fixing" all the existing instances, but either works, as long as we assume cirrus if not set there17:13
sean-k-mooneywell assume exsiting behavior17:13
sean-k-mooneywhich will be cirrus on x8617:13
opendevreviewMerged openstack/nova master: Add test coverage for API version headers in CORS  https://review.opendev.org/c/openstack/nova/+/79658017:14
sean-k-mooneyits vga on power and virtio on arm17:14
dansmithyeah17:14
opendevreviewMerged openstack/nova master: Fix typos in minimum version policy docs  https://review.opendev.org/c/openstack/nova/+/79557517:14
sean-k-mooneykashyap: does ^ work/make sense to you17:15
opendevreviewMerged openstack/nova master: Make test_refresh_associations_* deterministic  https://review.opendev.org/c/openstack/nova/+/79439617:15
sean-k-mooneydansmith: we may have other default like this we want to change but i cant rememebr them at present which is why i want to document the workflow for this type of change17:16
dansmithack17:16
opendevreviewMerged openstack/nova master: Remove PROJECT_ADMIN limitation from zero-disk and external-network policy  https://review.opendev.org/c/openstack/nova/+/79436017:49
opendevreviewMerged openstack/nova master: Improve policy doc for supported scope info  https://review.opendev.org/c/openstack/nova/+/76201317:50
slaweqHi nova-stable-cores, can You check https://review.opendev.org/c/openstack/nova/+/787253? Thx in advance20:57

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