Friday, 2021-11-26

opendevreviewGhanshyam proposed openstack/nova master: Introduce 'admin' policy base rule  https://review.opendev.org/c/openstack/nova/+/81938901:15
opendevreviewGhanshyam proposed openstack/nova master: Introduce 'admin' policy base rule  https://review.opendev.org/c/openstack/nova/+/81938901:22
opendevreviewGhanshyam proposed openstack/nova master: Convert aggregate policies to admin and system scope  https://review.opendev.org/c/openstack/nova/+/81939001:44
opendevreviewGhanshyam proposed openstack/nova master: Introduce 'admin' policy base rule  https://review.opendev.org/c/openstack/nova/+/81938901:56
gmanndansmith: gibi bauzas I registered the nova BP for the RBAC goal. please let me know if I need to add spec or specless BP (with all direction defined in community wide goal) can be approved https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-202:00
gmanndansmith: gibi bauzas I mean all the direction are defined in goal itself so we can do audit of nova policy changes in proposed code itself or in wiki page before we code - https://wiki.openstack.org/wiki/Nova/rbac02:03
gmannjohnthetubaguy[m]: ^^02:03
lyarwoodgibi / bauzas ; https://review.opendev.org/c/openstack/nova/+/819194 - would be good to get your thoughts on this btw08:25
gibilyarwood: do we want nova-tox-functional-centos8-py36 to be changed to run on py38? or that would require centos9? 08:32
lyarwoodgibi: We can drop centos8-stream jobs entirely from master as the supported runtime is moving to 908:32
* lyarwood needs to check on the devstack progress for that job08:33
lyarwoodgibi: and yeah 9 then brings py39 iirc08:33
gibilyarwood: so then what I see in that change is consistent with the global testing runtime  change 08:34
gibilyarwood: do you have some reservation about this change/08:34
gibi?08:34
lyarwoodgibi: Nope I'm good with it, gmann just had reservations so I wanted more people to chime in08:34
lyarwoodIMHO we should remove as much overhead as possible and that includes support/test runs for older runtimes08:35
gibilyarwood: OK, I gave +2, I agree with you that we need to force py38+ in the setup.cfg08:40
lyarwoodack thanks, lets see what bauzas says as PTL before we +W08:41
gibisure08:41
gibistephenfin: as a fun note there is blue: https://blue.readthedocs.io/en/latest/ it is almost like black :D08:42
lyarwoodflol I love that logo08:42
gibiI laught a lot the other day when somebody linked it in twitter08:43
gibiI went and +2d the other yoga testing runtime changes under our jurisdiction 08:51
*** brinzhang_ is now known as brinzhang08:53
kashyapTIL; "blue"08:56
kashyap:D08:56
gibisomebody should start working on lightblue or even teal08:57
kashyap:)08:59
gibigmann: re: RBAC: I don't have hard opinion. In one hand I see good dicsussion in https://review.opendev.org/c/openstack/nova-specs/+/793011 about a specific subset of the RBAC change, but on the other hand I don't think we need such discussion for all the policy during our audit. 09:10
gibigmann: so I would be OK with a specles BP and a promise that if we find something non trivial during the audit then we might raise a spec for that09:11
bauzasgibi: gmann: we can quickly discuss this BP for the next nova meeting09:23
bauzaslike we do for the others 09:23
bauzaslyarwood: looking09:23
bauzaslyarwood: ok, so I'm happy with https://review.opendev.org/c/openstack/nova/+/819194/ but I guess we'll need centos jobs once they run on top of centos9 ?09:33
bauzasI mean, devstack/centos909:33
bauzasif you say so, let's +W it 09:34
bauzasbut I'll add a comment09:34
lyarwoodbauzas: ACK yeah it's being worked on https://review.opendev.org/c/openstack/devstack/+/80090309:37
* lyarwood will try to help out later today with that09:38
bauzasOK, I'll mention it then09:38
* bauzas was trying to find the devstack patch, appreciated.09:38
lyarwoodthis isn't going to land until we drop the current centos 8 job from the integrated compute template btw09:38
lyarwoodso actually hold off on +W09:38
lyarwoodI'll throw something up to drop tempest-integrated-compute-centos-8-stream 09:39
bauzasI see09:39
bauzasoh, saw the discussion on https://review.opendev.org/c/openstack/nova/+/819194/1/setup.cfg#b1309:40
bauzasI'll chime into in09:40
bauzasit*09:40
lyarwoodoh crap I thought that was updated in this PS09:43
lyarwoodokay so -1 until that's actually blocked in setup.cfg09:43
bauzasoh, shit, I just sent it to the gate.09:47
bauzaslyarwood: I thought we had a consensus 09:47
lyarwoodyeah but setup.cfg hadn't changed to reflect it09:47
lyarwoodI missed that earlier09:48
lyarwoodI thought the latest PS had changed, we were discussing stuff on an older PS that confused things09:48
bauzaslyarwood: I eventually thought we said "OK but meh"09:50
bauzaslyarwood: what we can is to provide a FUP for modifying setup.cfg, no ?09:51
bauzasgibi: thoughts ?09:51
lyarwoodbauzas: yeah sure I can do that now09:51
bauzaslyarwood: cool, appreciated09:52
lyarwoodapologies, that was my fault09:52
* bauzas prefers to have a FUP than stopping the gate run09:52
bauzaslyarwood: no no it's me 09:52
bauzasI saw gibi +2ing it 09:52
bauzasand I thought the consensus was to say "nice talk, but let's just accept py36 to be unsupported but still used"09:53
bauzashence my comment09:53
opendevreviewLee Yarwood proposed openstack/nova master: fup: Require python >= 3.8 from Yoga  https://review.opendev.org/c/openstack/nova/+/81941509:57
lyarwoodYeah no issues, there's the fup anyway09:57
lyarwoodwe can discuss more there09:57
lyarwoodtbh thinking about it we might want to broadcast something like this on the ML 09:59
lyarwoodas it's going to break any centos8 stream jobs people have09:59
bauzaslyarwood: yeah, you're right10:01
* gibi is on a looong call10:03
* kashyap gives Gibi the meeting ticker (which tracks the bleeding dollars): https://tobytripp.github.io/meeting-ticker/10:12
kashyapPlug in approximate numbers for the first entries; hit "Start" and watch it roll10:13
lyarwoodhttps://zuul.opendev.org/t/openstack/build/4b3e8872abc54e96b992747b739b7d3b/log/job-output.txt looks like we need to update the LC job as well before this will work10:14
gibikashyap: 200 hourly rate?! I need to talk to my manager ....10:15
kashyapgibi: It's usually managers and their managers that might have that hourly rate :D 10:16
stephenfingibi: Nice :-D10:16
kashyapgibi: The website is also US-based; as we know, the numbers won't be a 1-1 mapping for EU.10:17
gibiI can imagine  it maps to some EU countries but not to where I sit. :D10:21
bauzasgibi: that depends on if you count the company payslip taxes too10:25
bauzasmaybe folks don't know, but for 100€ in a French brute payslip, the person gets somethink like 70€ and the company pays *140€*10:26
bauzasie. in between what the company pays, and what the person gets, it's around 100% taxes10:27
gibibauzas: similar here10:33
* kashyap doesn't even want to talk about Belgian taxes (50% flat out)10:34
gibifrom 100 I get 66 and company pays a total of 11710:34
gibinumbers are nicer with kids.10:35
bauzasinteresting comparison10:37
sean-k-mooney[m]bauzas i think irish takes work out at more. 40% income tax on aything earned over 39000 a year + 4.5% universal social charge (usc) on your gross income over ~19,000 + paye related social insurace (prsi) at 4% by employee and 11.5% by employer10:37
bauzasman, did I opened a can of worms :D10:37
sean-k-mooney[m]so for you t orecive 100 gross in ireland the comapany pay 115 and you will recive about 51 euro net10:38
bauzasagain, interesting10:39
sean-k-mooney[m]at least if you are in the higher tage bracket for earning more then 39,000 a year10:39
bauzaslooks like associates pay less for taxes than the company, but at the end, taxes are similar10:39
bauzassean-k-mooney: sames goes here10:39
bauzasI reflected my level of pay10:40
bauzasand yeah, whether you're having kids, you pay less10:40
bauzasbut this was limited to a discount of 1500€ per kid roughly10:41
bauzas(per year)10:41
sean-k-mooney[m]we do it slightly differnt in that you dont pay less but you get a tax credit which is deuected form your yearly tax10:41
sean-k-mooney[m]we also have paye pay as you earn10:42
sean-k-mooney[m]so you dont file your own tax returns10:42
bauzasif people read asimov's foundation (and don't look at the TV series which is a joke), they'll understand that any single govnerment can only generate more taxes over the time10:42
sean-k-mooney[m]your employer deducts tax at source and files it for you10:42
sean-k-mooney[m]which i like since for the most part you dont haver to worry about this10:43
bauzasvery quickly, we have three levels of taxes for a single payslip10:44
bauzas1/ the company taxes, payed by the company, which are roughly 47% except for minimum wages10:44
bauzas2/ the social, retirement and insurance taxes, which are roughy 15-20%, and independent of your household10:45
kashyapbauzas: I've been wanting to read Asimov; thanks for the reminder!10:45
bauzas3/ the income taxes, which were only collected once per year very late, and which changed recently and are now paid directly over the payslip10:46
bauzaskashyap: don't read my twitter account, you could get spoiled as I yelled multiple times at the series10:47
kashyapbauzas: Heh, don't worry; I'm social-media clean for 9 years now :-)10:47
bauzaskashyap: I also retired from Twitter10:47
kashyapMore power to you.10:47
kashyapJOMO++ (joy of missing out)10:48
bauzashell yeah, and Facebook is just very little used10:48
bauzaskashyap: never read Asimov N10:48
bauzas?10:48
bauzasthis is vast, I'd recomment you to start with Foundation's Prelude to get a chronological view instead of a publication view10:49
bauzasbut you'd also have to read some other books 10:49
kashyapbauzas: No.  The only sci-fi I've ever read is Iain M. Banks' Culture series10:49
bauzasthe Robots cycle, obviously10:49
kashyapNoted :)  Thx for the reco10:50
bauzasbut there are also some books very worthy between the Robots period and the Foundation perioid10:50
* bauzas goes swating at the gym10:50
bauzassweating* even10:50
sean-k-mooney[m]kashyap your missing out. i “read” mostly via audio books on audible. i have complete abour 280 ish books in the last 6 years  almost all are sifi/space opera/lit rpg or are fantasy. as someone with dislexia who has preverisly only read a hand full of books every audio books really work for me10:59
kashyapsean-k-mooney[m]: Yeah, I'll completely believe you.  And I'm glad that you're able to enjoy audio books10:59
sean-k-mooney[m]that remiands me i think a new book in one of the series im following is out soon i should check11:01
kashyapsean-k-mooney[m]: On missing out; I hear ya.  I mostly read (physical) books in the area of "cognitive science":  neuroscience, psychology, primate/human behaviour, biology, ancient Greek/Roman philosophy, and linguistics :D11:01
kashyapI do read fiction; but have reduced it a lot. I should get back to it a bit more, to lighten up the mood :)11:02
kashyapsean-k-mooney[m]: For audio, I listen to 90-minute podcasts, but haven't yet tried a proper audiobook.  I'll really need to give it a go11:02
kashyapThanks for the reminder!11:03
* kashyap today learnt of LitRPG genre; thx :-)11:03
lyarwoodbauzas / sean-k-mooney ; https://review.opendev.org/c/openstack/nova/+/815373 - I think I've got my head around this, it's weird but I guess it's valid as a bugfix. Would appreciate review and maybe some TODO fups from someone setting out a better solution that doesn't rely on the persistent domain XML.11:03
kashyaplyarwood: "The11:06
kashyap... limitation has been lifted since then" -- is that in libvirt?11:06
kashyap(From the commit message)11:06
sean-k-mooney[m]i think in qemu11:06
lyarwoodYeah correct, they didn't list the version in the commit message but it's in the releasenote11:06
kashyapThe hot-unplug of mediated device, i.e.11:06
lyarwoodand yeah I'm sure it's both libvirt and QEMU11:07
sean-k-mooney[m]basicaly nova managed save did not support mdevs11:07
kashyapsean-k-mooney[m]: It's libvirt, the previous sentence talks of libvirt11:07
kashyaplyarwood: Yeah; that's also correct, actually.11:07
sean-k-mooney[m]*libvirt managed save11:07
kashyapYea11:08
sean-k-mooney[m]kashyap well the libvirt limitation was becasue of a qemu limitation i belive11:08
sean-k-mooney[m]anyway now they do supprot11:08
sean-k-mooney[m]it so we dont need too or want too detach the mdevs right11:08
sean-k-mooney[m]but resume need to support both the new and old behavior11:08
kashyap(Yeah; I said it could be both a follow-up above.)11:09
sean-k-mooney[m]ack11:11
sean-k-mooney[m]i have not reviewd that patch closely by the way11:11
sean-k-mooney[m]at the end of the day i still think we should be tracking the mdevs in novas db and recreating form the db record instead of trying to use the guest xml to store the mdevs used11:13
opendevreviewMerged openstack/nova master: Updating tests with Yoga testing runtime  https://review.opendev.org/c/openstack/nova/+/81919411:13
sean-k-mooney[m]e.g. right now we are relying on the domain to exist to prevent other vms from using the mdevs which is fragile11:14
sean-k-mooney[m]at least in comparison to storing them in the resoucs table or pci devices table. it has the advantage of being local i guess but it make reaning about this harder since we dont track the arent device ectra in other edge cases like host reboot11:16
sean-k-mooney[m]so i hope we can make this simpler and just recored it in the db eventurally11:16
lyarwoodYeah agreed, I think for now this is a valid backportable fix but really it needs to be replaced by something from our DB or placement or something11:18
lyarwoodIt's just super confusing given we detach from the active and then use the persistent domain to work out what we need to reattach before we then restore the managedSave state of the domain11:19
lyarwoodI guess an alternative is for libvirt to support managedSave somehow for mdevs, likely by the caller telling it not to care about their state or something?11:20
sean-k-mooney[m]so i think it dose now right ?11:20
sean-k-mooney[m]oh no11:21
sean-k-mooney[m]what has changed is  we blocked suspend before becaue we could not unplug and replug the mdev11:21
sean-k-mooney[m]now we can11:21
sean-k-mooney[m]oh there is another nasty bug there11:23
sean-k-mooney[m]so we previously detach the interface on suspend right11:24
sean-k-mooney[m]now we are reattaching them when we did not before which is good11:24
sean-k-mooney[m]but we sometimes suspend the guest when we do snapshot11:25
sean-k-mooney[m]so as a side effect if you could not use live snap shots snapshotting would remove the mdev and not reattach them11:25
sean-k-mooney[m]so this will fix that too11:25
opendevreviewLee Yarwood proposed openstack/nova master: fup: Require python >= 3.8 from Yoga  https://review.opendev.org/c/openstack/nova/+/81941511:26
lyarwooddo we use suspend for that?11:27
lyarwoodI thought that was a pause on the domain itself11:27
lyarwoodah it's suspend11:28
lyarwoodTIL11:28
lyarwoodokay yeah resume needs to be updated11:28
sean-k-mooney[m]ya i tought it would be pause too untile i read it again just now.11:29
lyarwoodhttps://github.com/openstack/nova/blob/d630615a02469442fb50ed4aa7e092206a28166a/nova/virt/libvirt/driver.py#L3043-L3063 that even11:29
lyarwoodnice catch11:29
lyarwoodtbh the TODO from stephenfin is right, that could just be a single call to self.resume11:29
sean-k-mooney[m]actully i tought that just called resume like the suppoed_for_snappshot calls suspend11:30
sean-k-mooney[m]ya11:30
sean-k-mooney[m]it should be.11:30
opendevreviewLee Yarwood proposed openstack/nova master: DNM Testing python >= 3.8 requirement  https://review.opendev.org/c/openstack/nova/+/81943211:38
sean-k-mooneylyarwood:... unfortunetly we might need to keey requires_python>=3.6 for rdo this cycle due to upgrdes11:50
sean-k-mooneywhich makes me think we cant actully turn off testin 3.6 until z11:51
lyarwoodWhy would we need to keep it?11:51
sean-k-mooneybecause they will be supprot yoga on centos 8 and 9 for upgrades11:51
lyarwoodCan't we just ship py38 in the Yoga containers?11:51
sean-k-mooneywe can but they ahve to supprot rpm install. and to be fair 3.8 is avaiable on cents too11:52
sean-k-mooney* centos8 too11:52
sean-k-mooneyits just not the default11:52
lyarwoodSigh why didn't the RDO folks raise that with the TC before they moved the runtimes for Yoga11:53
lyarwoodbrb11:53
sean-k-mooneyya i dont know i really dont like the idea of our testing and min requires being differnet so i dotn know what to do to be honest11:54
lyarwoodWell for RDO at least they can workaround it easily enough11:55
lyarwoodby installing py38 alongside py3611:55
gibilyarwood, bauzas: re py36 support: sorry I also missed that we are discussing that on an older PS. :/11:55
gibilyarwood bauzas: I agree to land the fup on setup.cfg11:56
lyarwoodnp my language here didn't help, I confused things massively 11:56
gibiand I do believ that RDO missed the deadline not to raise the issue on the TC ruling12:03
sean-k-mooneyim also kind of confused why RDO have not been testign with 3.8 as well12:09
sean-k-mooneyit has been a testing requirement for some time12:10
sean-k-mooneyi guess they were usign the lower requiremtn for centos of 3.612:10
sean-k-mooneybut give our downstream will be using 3.9 form wallaby+ that feels like a gap someone form redhat would have been woking on fixing12:12
sean-k-mooneypy 3.9.8 currrenlty py 3.8 will not be supproted on centos 912:13
lyarwoodsorry back12:20
lyarwoodjust noticed I missed stephenfin 's thread about this on the ML12:20
* lyarwood reads now12:20
* gibi replies to the recent posts of that tread12:28
gibithread even12:30
artomHuh, looks like at some point between... victoria? and master ovs+hybrid_plug became plug-time Neutron events...14:19
artomhttps://zuul.opendev.org/t/openstack/build/2f75f41da4df48f8a8abc5087fd29efb/log/controller/logs/screen-n-cpu.txt#923314:20
tobias-urdinlyarwood: should we ping in somebody from RDO on the above topic or did u take it already?14:23
lyarwoodtobias-urdin: Looks like folks from RDO already raised this on the ML, I hadn't seen it until the end of the discussion earlier14:23
tobias-urdinlyarwood: ack, good to hear14:30
sean-k-mooneyartom: ovs hybrid plug was always a plugtime event14:36
artomsean-k-mooney, not for revert resize14:36
artomRemember 7a7a223602ca5aa0aca8f65a6ab143f1d8f8ec1b?14:36
sean-k-mooneyfor revert its already plugged14:36
artomLooks like we don't need it anymore14:36
sean-k-mooneyso its bind time14:36
artomApparently that's no longer the case, see the log link14:37
artomIt's from https://review.opendev.org/c/openstack/nova/+/81934914:37
sean-k-mooneyfor resize we dont touch the netwroking on the souce host until you confrim14:38
sean-k-mooneywe do update the port binding (there is only one) before we go to resize verify14:38
sean-k-mooneythen on revert we update the host back to the soruce14:38
artomWell I have no idea what happened, but we now get plug-time events, and not bind-time events14:38
sean-k-mooneybut we should not need to set up the networking on the host again14:39
artomI mean, I don't disagree14:39
artomBut based on what my CI job run is telling me, revert resize is now plug-time like everything else (again)14:39
sean-k-mooneywe are going to get plug time events as well i think14:39
sean-k-mooneybut we should get bind time events first14:40
artomNever get the former14:40
sean-k-mooneywe will call effectivly hard reboot as part of starting the instance again on the source14:40
sean-k-mooneythat is where the plug time event comes form14:40
sean-k-mooneyat least that is what im guessing14:40
sean-k-mooneyhave not looked at that code regently how are we starting the souce vm14:41
artomTbh I'm sick of the whole thing, want to get CI coverage on it so when it changes again under us we at least notice it, and revert 7a7a223602ca5aa0aca8f65a6ab143f1d8f8ec1b because we apparently don't need it anymore14:42
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11238-L1124014:42
sean-k-mooneyartom: im not sure we should14:43
sean-k-mooneyrevert 7a7a223602ca5aa0aca8f65a6ab143f1d8f8ec1b14:43
sean-k-mooneyto me this is a neutron regresssion14:43
sean-k-mooneyits a bug that it is not sendign a event at bind time when we change the host_id14:44
artomsean-k-mooney, hellz yeah, less work for us14:48
artom:P14:48
sean-k-mooneyartom: so ya https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7262 we call plug vifs again when starting the ports on the source but that is idempotent and will only update the network backend (ovs) if the ports are not present14:48
sean-k-mooneyartom: i suspect the issue is the l2 agent recice the port update event but does not set the port status as up because its already up and therefor does not trigger the event14:49
artomsean-k-mooney, huh, so I can actually hand this over to #neutron via the downstream CIX call, as originally it was a CIX14:52
sean-k-mooneyit might be related to this logic https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L2696-L269914:54
sean-k-mooneythat looks wrong to me as it will filter out host chagnes on the port14:54
artomsean-k-mooney, we can try a quick DNM change to verify that... what should we change it to?14:57
sean-k-mooneygive me a minute to trace teh code14:58
sean-k-mooneyi can push something  but i feel like its ignoring the host chage or somehting like that since the port and flows hould alreuady be configured14:58
sean-k-mooneyeighter that or its on the other side where setting the port status up is skipped if the port is up14:59
sean-k-mooneyeiter case woudl lead to the provisioning blocks code not beeing called14:59
sean-k-mooneyartom: we are not seeing this logged right https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L206915:02
artomsean-k-mooney, lemme check15:09
sean-k-mooneythis i think is where the update shoudl come from https://github.com/openstack/neutron/blob/4b0a225e8011c904dfa7c4e41fac13cea0aa872b/neutron/plugins/ml2/rpc.py#L303-L32715:11
artom(Sorry, teaching daughter albegra at the same time, aah COVID how we love thee)15:11
artomThough it is fun to figure out a way to make them understand, and see them get it15:12
artomThey're essentially exploring the commutativity of division15:12
artomWithout those terms, obviously, grade 2 :P15:12
sean-k-mooneyi see15:13
artomSo 14/2 = 10/2 + 5/215:13
artomFor example15:13
artomAaaaanyways15:13
sean-k-mooneyya out side of an acadmic context they are not really used15:14
sean-k-mooneywell as written that should be !=15:14
sean-k-mooneyunless we are talking about integer aritmatic15:14
sean-k-mooneysicne 7 != 7.515:15
artomErr, 4/215:15
artomThat was a typo :P15:15
sean-k-mooney:)15:15
stephenfingmann: lyarwood: gibi: Looks like I opened an somewhat unrelated can of worms by bringing up that question about python_requires /o\15:15
stephenfinreading back through your chat from earlier (been fighting with local auth issues all afternoon)15:16
artomsean-k-mooney, but to answer your question, no we do not see 'changing status to down' logged for our port that's resize reverting15:17
sean-k-mooneyin the l2 agent15:18
sean-k-mooneyok15:18
sean-k-mooneydo you have the link to the l2 agent log and the port uuid15:18
sean-k-mooneywe shoudl  see if we get the notificaiton for the put update with the host change15:18
artomsean-k-mooney, uh... wanna hop on a gmeet? I have the logs from the job run locally15:19
artom'cuz half of those words I didn't understand :P15:19
sean-k-mooneysure15:20
sean-k-mooneyalso i wonder if we are hitting https://github.com/openstack/neutron/blob/1ad9ca56b07ffdc9f7e0bc6a62af61961b9128eb/neutron/plugins/ml2/drivers/agent/_common_agent.py#L302-L31115:20
sean-k-mooneyfrom _process_device_if_exists15:20
sean-k-mooneymeet.google.com/oen-kxyp-cwa when it suits15:23
gmanngibi: bauzas on RBAC BP, ack. I will try to join next meeting but might not due to hospital appointment(let's see how long it takes me to drive in snow :)) but dansmith can answer the queries on that if he joining. 15:48
bauzasack15:48
gmannstephenfin: yeah :). I am not sure why people did not brought those py3.6 which we discussed since PTG and re-re-updated the testing runtime - https://review.opendev.org/c/openstack/governance/+/815851/3..6/reference/runtimes/yoga.rst 15:49
opendevreviewMerged openstack/nova stable/wallaby: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81851915:50
gibistephenfin, gmann: I think it is a good discussion on the ML, it is probably a late discussion but a good one :)15:52
gmanngibi: IMO, it is not late but revised one :) I have kept centos-stream 8 in my updating the testing runtime because it was not clear for TC in PTG if centos-stream 9 is released or not and later in patch review one of TC checked with centos team and confirmed it is fine to move to centos stream915:55
gmannor different opinion from centos team may be15:55
gibiI think there is some missunderstanding / miscommunication around the centos 9 readyness15:56
gmannyeah15:57
gmannanyways let's see if we end up reverting then we can revert the changes inclduing https://review.opendev.org/c/openstack/nova/+/81941515:57
gmannbauzas: I am +2 on lyarwood changing python_requires = >=3.8 just leaving +A in case you are ok - https://review.opendev.org/c/openstack/nova/+/81941515:58
lyarwooddo we want to see what happens with the thread first15:58
lyarwoodin case the TC need to revert back to py36 and CS815:59
bauzasgmann: lyarwood: yeah we can hold15:59
gmannlyarwood: either is ok but if we revert to py36 then anyways we have to revert 819194 too15:59
lyarwoodtrue15:59
lyarwoodFWIW that depends on https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/819431 that I'm less sure about15:59
lyarwoodI think the branches need to be listed there for this to work15:59
lyarwoodand it obviously has an impact on other projects16:00
lyarwoodlet me -W the nova change for now16:00
lyarwoodand that change16:00
gibiI agree ^^16:00
gibilets wait a bit 16:00
gibiand try not to land things that breask py3.6 support in the meantime :)16:00
gibibreaks16:00
bauzas++16:01
gmannsure, I have -W on tempest one also16:01
lyarwoodthanks16:02
gmannlyarwood: gibi bauzas stephenfin this is the proposal on Yoga testing runtime we agreed in TC channel with RDO team members, http://lists.openstack.org/pipermail/openstack-discuss/2021-November/026024.html17:28
gmannI will keep this proposal as open for next week before we conclude it as most of USA and other folks are on holiday today. meanwhile please add your  opinion there 17:29
gibigmann: thanks I will check it17:42
lyarwoodgmann: ack will do over the weekend, thanks!17:50
opendevreviewArtom Lifshitz proposed openstack/nova master: Revert "Revert resize: wait for events according to hybrid plug"  https://review.opendev.org/c/openstack/nova/+/81949420:59

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