| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-27 | |||
| 15:18:09 | bauzas | working on a fix with no_implicit_optional=False | |
| 15:25:41 | gibi | bauzas: I'm fine with https://review.opendev.org/c/openstack/nova/+/878693 as a fix for ^^ | |
| 15:28:20 | sean-k-mooney | i agree with the mypi fix in nova | |
| 15:29:19 | bauzas | gibi: damn, I was jinxed :) | |
| 15:29:34 | bauzas | I was working on a patch | |
| 15:29:38 | bauzas | anyway +Wd | |
| 15:29:47 | kashyap | bauzas: Are there meeting minutes from the public-cloud WG? | |
| 15:29:49 | bauzas | and sent an mail to -discuss to prevent rechecks | |
| 15:29:51 | kashyap | Or Etherpad nodes | |
| 15:30:11 | bauzas | kashyap: https://etherpad.opendev.org/p/march2023-ptg-publiccloud | |
| 15:30:50 | bauzas | tl;dr: most of the discussion was about flavors API | |
| 15:31:04 | bauzas | and how filtering extra specs is a need | |
| 15:31:33 | bauzas | + some can of worms about some possible discoverable mechanism for describing a flavor | |
| 15:31:55 | bauzas | they'll write a backlog spec so we'll nitpick over it | |
| 15:45:03 | frickler | bauzas: regarding mypy, does it make sense to add nova pep8 job to reqs repo? I hope we will get more frequent updates again in the future, after getting almost none in the last cycle | |
| 15:47:00 | bauzas | frickler: good question, I dunno what to say here | |
| 15:47:13 | bauzas | because we use the pep8 tox target for mypy | |
| 15:47:36 | bauzas | so either the pep8 openstack one should also use mypy or maybe we should use a different tox job | |
| 15:47:54 | bauzas | I just don't want to test again pep89 twice | |
| 15:48:42 | frickler | bauzas: I'm not sure I understand that, I was talking about adding cross-nova-pep8 to requirements repo. currently there only is cross-nova-py310 | |
| 15:49:14 | bauzas | frickler: ok, then +1 | |
| 15:51:29 | frickler | o.k., I'm feeling a bit guilty about having pushed the u-c updates yesterday, so I'll try to set that up as compensation ;-) | |
| 15:52:13 | gibi | ^^ +1 from me as well | |
| 15:58:22 | gmann | frickler: +1 | |
| 16:05:17 | frickler | does any of you know why this files filter is only in place in gate and only for nova+placement? https://opendev.org/openstack/requirements/src/branch/master/.zuul.d/project.yaml#L126-L129 | |
| 16:32:58 | bauzas | frickler: good question, I dunno https://opendev.org/openstack/requirements/commit/91eaa0cd7f75f5f1b93226e4bb2de64aa4fed2b3 | |
| 16:33:13 | bauzas | looks like we just followed a pattern | |
| 17:29:07 | ygk_12345 | Hi All | |
| 18:32:06 | opendevreview | Merged openstack/placement master: Do not use coalesce for consumers.uuid https://review.opendev.org/c/openstack/placement/+/877852 | |
| #openstack-nova - 2023-03-28 | |||
| 09:54:52 | 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:58:46 | opendevreview | Konrad Gube proposed openstack/nova master: Use Cinder's os-extend_volume_completion volume action. https://review.opendev.org/c/openstack/nova/+/873560 | |
| 10:21:29 | 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:51 | 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 | |
| 11:41:11 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 11:41:11 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 12:14:58 | 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:15:46 | gibi | then I have another internal call from 15:00-15:30 UTC | |
| 12:16:56 | bauzas | ack no worries | |
| 12:17:32 | kashyap | bauzas: Is it still the "operator hour" now? - https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova | |
| 12:17:49 | kashyap | s/still// | |
| 12:18:17 | bauzas | kashyap: at 15pm UTC https://ptg.opendev.org/ptg.html | |
| 12:18:27 | bauzas | 3pm whoops | |
| 12:18:50 | bauzas | ie. we will start the Nova vPTG session in ~47 mins, | |
| 12:19:05 | bauzas | and then we will have the operator hour in ~2h47mins | |
| 12:20:34 | kashyap | Yep, nod. Thx! | |
| 13:03:24 | bauzas | Nova vPTG sessions start now :) | |
| 13:14:50 | 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:15:15 | 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:19:21 | bauzas | courtesy ping list for antelope retro : gibi | |
| 13:22:37 | bauzas | artom: https://ptg.opendev.org/ptg.html | |
| 13:56:54 | bauzas | placement patch https://review.opendev.org/c/openstack/placement/+/876768 | |
| 14:27:50 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | |
| 14:29:01 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 14:32:05 | 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:35:03 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | |
| 14:46:25 | bauzas | we're taking a break until 3pm UTC and then operator hour | |
| 14:46:48 | bauzas | etherpad for operator hour is https://etherpad.opendev.org/p/march2023-ptg-operator-hour-nova | |
| 15:05:08 | auniyal__ | melwitt, ^^ unified limit topic in PTG | |
| 15:25:34 | opendevreview | Moritz Wanzenböck proposed openstack/nova master: Implement extend_volume for local devices https://review.opendev.org/c/openstack/nova/+/878763 | |
| 15:27:58 | dansmith | wangrong: hi | |
| 15:28:21 | bauzas | wangrong: I took notes on https://etherpad.opendev.org/p/generic-vdpa at the bottom of the page | |
| 15:28:49 | wangrong | hi | |
| 15:29:40 | dansmith | wangrong: have you submitted a change to gerrit before? | |
| 15:31:32 | 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:43 | 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:32:21 | 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:33:05 | 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:30 | dansmith | wangrong: I copied the template to my approved/compute-object-ids.rst file and then filled out the details | |
| 15:33:38 | dansmith | does that make sense? | |
| 15:47:15 | wangrong | dansmith: yes, make sense, I will fill that template. For gerrit maybe will not be a problem. | |
| 15:48:18 | 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 | |
| 16:25:42 | bauzas | auniyal__: ping about the Bobcat planning | |
| 17:25:17 | 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:26:03 | gibi | nova reports the instance as active/running while the snapshot is uploaded to glance | |
| 17:32:36 | 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:37 | melwitt | we know of | |
| 17:33:11 | bauzas | gibi: that's his nick :) | |
| 17:33:19 | 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:28 | bauzas | I can ask him to join the channel if he isn't | |
| 17:33:35 | bauzas | melwitt: ack, sure | |
| 17:34:01 | 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:44 | bauzas | and folks, sorry about my chairing of the vPTG, I was pretty bad at that | |
| 17:34:59 | bauzas | bad phrasing, bad timings | |
| 17:35:12 | bauzas | I hope I'll be clearer tomorrow | |
| 17:36:33 | 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:37:51 | bauzas | melwitt: btw. given your tz, don't hesitate to add your nick on the topics you want to attend | |
| 17:38:24 | 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:37 | 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:58 | melwitt | bauzas: sure, thank you | |
| 17:39:25 | 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:42 | melwitt | ack | |
| 17:40:00 | bauzas | melwitt: that said, hold on, considering the fact that Bobcat is non-SLURP | |
| 17:40:19 | melwitt | bauzas: ah right, good point. I wondered about that too | |
| 17:40:20 | bauzas | if we flip the defaults now, we'll now to forward-port that in our C release notes | |
| 17:40:40 | bauzas | because ops would miss the B relnotes if they jump straight | |
| 17:41:03 | bauzas | melwitt: I'm not opposed to flip the defaults in B | |
| 17:41:25 | bauzas | melwitt: I just wanna discuss with the team about how we ensure we don't miss anything in the C relnotes | |
| 17:42:33 | melwitt | ++ | |
| 17:43: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:55 | 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 | |