| opendevreview | Nobuhiro MIKI proposed openstack/nova-specs master: Re-propose "Add maxphysaddr support for Libvirt" for 2023.2 Bobcat https://review.opendev.org/c/openstack/nova-specs/+/878753 | 09:54 |
|---|---|---|
| opendevreview | Konrad Gube proposed openstack/nova master: Use Cinder's os-extend_volume_completion volume action. https://review.opendev.org/c/openstack/nova/+/873560 | 09:58 |
| opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag spec to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | 10:21 |
| opendevreview | Amit Uniyal proposed openstack/nova-specs master: Add cleanup flag spec to remove dangling volumes https://review.opendev.org/c/openstack/nova-specs/+/878757 | 10:45 |
| opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | 11:41 |
| gibi | bauzas: I will be late from the start today due to an internal meeting. hopefully it will be a quick one (max 30min) | 12:14 |
| gibi | then I have another internal call from 15:00-15:30 UTC | 12:15 |
| bauzas | ack no worries | 12:16 |
| kashyap | bauzas: Is it still the "operator hour" now? - https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova | 12:17 |
| kashyap | s/still// | 12:17 |
| bauzas | kashyap: at 15pm UTC https://ptg.opendev.org/ptg.html | 12:18 |
| bauzas | 3pm whoops | 12:18 |
| bauzas | ie. we will start the Nova vPTG session in ~47 mins, | 12:18 |
| bauzas | and then we will have the operator hour in ~2h47mins | 12:19 |
| kashyap | Yep, nod. Thx! | 12:20 |
| * bauzas goes offline for 20 mins | 12:26 | |
| bauzas | Nova vPTG sessions start now :) | 13:03 |
| artom | What are we starting with? The retrospective? I'm visiting a daycare for baby in ~45 minutes, so I'll miss the first few topics | 13:14 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: libvirt: Check if VIF MTU matches network MTU https://review.opendev.org/c/openstack/nova/+/852367 | 13:15 |
| bauzas | courtesy ping list for antelope retro : gibi | 13:19 |
| bauzas | artom: https://ptg.opendev.org/ptg.html | 13:22 |
| bauzas | placement patch https://review.opendev.org/c/openstack/placement/+/876768 | 13:56 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | 14:27 |
| opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | 14:29 |
| opendevreview | Jorge San Emeterio proposed openstack/nova master: Have host look for CPU controller of cgroupsv2 location. https://review.opendev.org/c/openstack/nova/+/873127 | 14:32 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | 14:35 |
| bauzas | we're taking a break until 3pm UTC and then operator hour | 14:46 |
| bauzas | etherpad for operator hour is https://etherpad.opendev.org/p/march2023-ptg-operator-hour-nova | 14:46 |
| auniyal__ | melwitt, ^^ unified limit topic in PTG | 15:05 |
| opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | 15:25 |
| dansmith | wangrong: hi | 15:27 |
| bauzas | wangrong: I took notes on https://etherpad.opendev.org/p/generic-vdpa at the bottom of the page | 15:28 |
| wangrong | hi | 15:28 |
| dansmith | wangrong: have you submitted a change to gerrit before? | 15:29 |
| dansmith | wangrong: the general procedure here would be to create a change in gerrit that adds a new file in nova-specs/specs/2023.2/approved something like "generic-vdpa-support.rst" | 15:31 |
| dansmith | wangrong: that file should start a a copy of the template, which is this: https://opendev.org/openstack/nova-specs/src/branch/master/specs/2023.2-template.rst | 15:31 |
| dansmith | wangrong: we are recommending that you copy the template to your spec file, and then fill out the "problem description" and "use cases" sections first, and get that submitted | 15:32 |
| dansmith | wangrong: here is an example of a spec that I have proposed, so you can see how it should look when you submit it: https://review.opendev.org/c/openstack/nova-specs/+/877291 | 15:33 |
| dansmith | wangrong: I copied the template to my approved/compute-object-ids.rst file and then filled out the details | 15:33 |
| dansmith | does that make sense? | 15:33 |
| wangrong | dansmith: yes, make sense, I will fill that template. For gerrit maybe will not be a problem. | 15:47 |
| dansmith | wangrong: okay cool, we can ask nova and neutron people to comment on the spec because it sounds like people from both projects will need to contribute | 15:48 |
| bauzas | auniyal__: ping about the Bobcat planning | 16:25 |
| *** sfinucan is now known as stephenfin | 17:20 | |
| gibi | Do you know Adri2000's IRC nick? I looked into the active instance during shelving issue he raised today and I might see what he saw in https://paste.opendev.org/show/bpd9AT9CA09O22eHHchd/ | 17:25 |
| gibi | nova reports the instance as active/running while the snapshot is uploaded to glance | 17:26 |
| melwitt | bauzas: re: unified limits, I had hoped johnthetubaguy might be at the vPTG (I think he was at the last one) bc he's the one who was going to try out the initial exoerimental version of nova unified limits. I have been thinking about whether it's a good time now to implement the migration tools (forklift nova limits from nova db to keystone db) and write proper documentation, if there are no major issues that need to be fixed first that | 17:32 |
| melwitt | we know of | 17:32 |
| bauzas | gibi: that's his nick :) | 17:33 |
| melwitt | I do have a bug open and patch proposed for a unified limits quota bug around unshelving an offloaded instance but other than that, I don't know of any problems | 17:33 |
| bauzas | I can ask him to join the channel if he isn't | 17:33 |
| bauzas | melwitt: ack, sure | 17:33 |
| bauzas | melwitt: fwiw, I haven't marked the unified limits topic as done, so we can discuss it later in the week if you want | 17:34 |
| bauzas | and folks, sorry about my chairing of the vPTG, I was pretty bad at that | 17:34 |
| bauzas | bad phrasing, bad timings | 17:34 |
| bauzas | I hope I'll be clearer tomorrow | 17:35 |
| melwitt | bauzas: ok. I guess if we get everything else topics done, I don't think the unified limits topic (without any operator feedback) is requiring of "in person" discussion | 17:36 |
| bauzas | melwitt: btw. given your tz, don't hesitate to add your nick on the topics you want to attend | 17:37 |
| bauzas | I know how 1pm UTC is damn early for you, so please help me making sure you can join the most important ones for you :) | 17:38 |
| melwitt | I am thinking to create a specless blueprint (or something) to propose it and people can see what they think. it would be basically implementing the last bit of the spec and removing the "experimental do not use this driver" phrase on the config option help | 17:38 |
| melwitt | bauzas: sure, thank you | 17:38 |
| bauzas | melwitt: sounds good to me about the specless bp, and that's a good signal flag that I won't miss when writing the cycle highlights | 17:39 |
| melwitt | ack | 17:39 |
| bauzas | melwitt: that said, hold on, considering the fact that Bobcat is non-SLURP | 17:40 |
| melwitt | bauzas: ah right, good point. I wondered about that too | 17:40 |
| bauzas | if we flip the defaults now, we'll now to forward-port that in our C release notes | 17:40 |
| bauzas | because ops would miss the B relnotes if they jump straight | 17:40 |
| bauzas | melwitt: I'm not opposed to flip the defaults in B | 17:41 |
| bauzas | melwitt: I just wanna discuss with the team about how we ensure we don't miss anything in the C relnotes | 17:41 |
| melwitt | ++ | 17:42 |
| bauzas | dansmith: do you know btw. if the reno team worked on some reno magical flag for saying 'this is something you should also document for the next branch' ? | 17:43 |
| melwitt | bauzas: to be clear, I'm not thinking of changing the defaults in B but to just add the "migrate nova quota limits to keystone" script and the docs. maybe it would be best to let that bake for B before flipping defaults in C? not sure | 17:43 |
| bauzas | hah, my bad | 17:44 |
| bauzas | then the problem remains, the migration would need to be performed in C if not done in B | 17:44 |
| melwitt | the migration isn't mandatory fwiw, operators can today just add their limits via the keystone API. the script would just be to make it extra easy if they want to use it | 17:46 |
| bauzas | yeah I remember | 17:46 |
| melwitt | they will either way have to add their own limits via keystone API to add other placement resources such as vGPU or whatever they want | 17:46 |
| melwitt | kk | 17:46 |
| melwitt | (thinking out loud) maybe it would be good to hook the forklift script into online_data_migrations in C if we decide to flip the default in C ... bc unified limits default closed (limit of 0) so if they don't make their limits in keystone, all their quota would start being denied. it would be a major major problem to miss that upgrade step of adding limits in keystone if the default is changing. I'll write all of this up in the | 17:53 |
| melwitt | blueprint for discussion or maybe a small spec | 17:53 |
| * bauzas needs to end his day now but finishes on a bitter taste due to https://review.opendev.org/c/openstack/nova/+/878693 constantly failing | 18:01 | |
| bauzas | looks like we have an ovn agent gone on grenade-multinode job | 18:02 |
| dansmith | bauzas: nope, I dunno | 18:13 |
| *** efried1 is now known as efried | 18:22 | |
| opendevreview | sean mooney proposed openstack/nova master: Allow discard with virtio-blk https://review.opendev.org/c/openstack/nova/+/878795 | 18:53 |
| opendevreview | Carl Morris proposed openstack/nova master: Fix a typo in this URL: https://docs.openstack.org/nova/latest/admin/availability-zones.html https://review.opendev.org/c/openstack/nova/+/878797 | 19:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!