| bauzas | good morning Nova | 07:05 |
|---|---|---|
| whoami-rajat | hi bauzas | 09:18 |
| whoami-rajat | wanted to reiterate about the client and OSC patches required by my feature | 09:19 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: fixup https://review.opendev.org/c/openstack/nova/+/856033 | 09:33 |
| bauzas | whoami-rajat: yup, will look | 09:37 |
| bauzas | and thanks | 09:37 |
| whoami-rajat | thank you :) | 09:38 |
| whoami-rajat | for reference novaclient https://review.opendev.org/c/openstack/python-novaclient/+/827163 | 09:38 |
| whoami-rajat | OSC: https://review.opendev.org/c/openstack/python-openstackclient/+/831014 | 09:38 |
| bauzas | whoami-rajat: could you please explain me why you remove the reimage_boot_volume from the kwargs here https://review.opendev.org/c/openstack/python-novaclient/+/827163/11/novaclient/v2/servers.py#1750 ? | 10:30 |
| bauzas | because by default, we say Yes for 2.93 https://review.opendev.org/c/openstack/nova/+/830883/32/nova/api/openstack/compute/servers.py | 10:33 |
| whoami-rajat | bauzas, yes, so the current design accepted was to add a check on the client side, i will remove the check altogether from novaclient to clear the confusion | 10:48 |
| whoami-rajat | also i just realized we changed the parameter name in current spec to "confirm-reimage", will update that as well | 10:49 |
| sean-k-mooney | whoami-rajat: i just looked at the osc patch and that is not checkign properly | 10:49 |
| bauzas | whoami-rajat: I think we have a bug with the nova patch | 10:50 |
| bauzas | whoami-rajat: well, not a bug but some behavior that's different from the spec | 10:50 |
| sean-k-mooney | the check that was ment to be added to osc was ment to check that if you use the new microversion that you also passed the new paramter if the instance was BFV | 10:50 |
| sean-k-mooney | bauzas: how so? | 10:50 |
| bauzas | whoami-rajat: if you use 2.93, you'll opt-in for reimage anyway | 10:51 |
| bauzas | you can't tell no | 10:51 |
| sean-k-mooney | bauzas: correct | 10:51 |
| sean-k-mooney | bauzas: that is intentional | 10:51 |
| whoami-rajat | sean-k-mooney, ack, will take a look at the osc patch | 10:51 |
| bauzas | sean-k-mooney: then the spec was telling other thing | 10:51 |
| bauzas | sean-k-mooney: the spec will telling you were able to opt-out | 10:51 |
| sean-k-mooney | bauzas: then the spec is wrong | 10:51 |
| bauzas | sean-k-mooney: see https://review.opendev.org/c/openstack/nova-specs/+/840155/5/specs/zed/approved/volume-backed-server-rebuild.rst#143 | 10:52 |
| bauzas | we were keeping the original behavior with 2.93 if the user was passing a parameter | 10:52 |
| bauzas | actually, no | 10:52 |
| sean-k-mooney | no that is discribibg the osc change | 10:53 |
| bauzas | the spec was saying that 'reimage is opt-in with 2.93' | 10:53 |
| sean-k-mooney | no | 10:53 |
| sean-k-mooney | that is client side only | 10:53 |
| bauzas | and here we're discussing of "no reimage is opt-out with 2.93' | 10:53 |
| sean-k-mooney | the nova api will not provde a way to opt in or out | 10:53 |
| sean-k-mooney | other then the micorverions | 10:53 |
| bauzas | oh you're right | 10:53 |
| bauzas | "on the client side" | 10:53 |
| sean-k-mooney | yes | 10:53 |
| bauzas | so | 10:54 |
| bauzas | 2.93 makes it default | 10:54 |
| bauzas | and users can say no just by a client parameter | 10:54 |
| sean-k-mooney | no | 10:54 |
| bauzas | then clarify the spec | 10:54 |
| sean-k-mooney | 2.93 makes it unconditional because we wanted rebuild to mean rebuild | 10:54 |
| bauzas | which I understand | 10:55 |
| sean-k-mooney | if you want the old behaivor you use the old microversion | 10:55 |
| bauzas | yes | 10:55 |
| sean-k-mooney | the client check was ment to prevent the request if you did not pass the parmater | 10:55 |
| bauzas | so I don't see a need for an extra param on the client | 10:55 |
| sean-k-mooney | not downgrade the microverios | 10:55 |
| bauzas | ok, then I understand | 10:55 |
| bauzas | you need to say "yes, I understand I'll reimage" | 10:55 |
| sean-k-mooney | exactly | 10:55 |
| whoami-rajat | sean-k-mooney, bauzas , as i see, the novaclient changes are not even needed i guess, just bumping the version to 2.93 should be enough right? | 10:55 |
| sean-k-mooney | whoami-rajat: yep just bumping the max version | 10:56 |
| sean-k-mooney | the rest is not needed | 10:56 |
| bauzas | whoami-rajat: correct | 10:56 |
| whoami-rajat | ack, will update | 10:56 |
| bauzas | well | 10:56 |
| bauzas | sec | 10:56 |
| bauzas | sean-k-mooney: we also need a param on the python bindings | 10:57 |
| sean-k-mooney | on the osc change you need to check when the micorversion is 2.93 or higher that --remiage is pased if its a bfv instance | 10:57 |
| bauzas | like, | 10:57 |
| sean-k-mooney | bauzas: we dont as the python bindigns are not ment to do this check | 10:57 |
| bauzas | "I want explain I know I'll reimage" with my python script | 10:57 |
| sean-k-mooney | nope | 10:57 |
| sean-k-mooney | that is not desireable | 10:57 |
| bauzas | then we need to clarify this paragraph on the spec, this is confusing | 10:57 |
| sean-k-mooney | ack we can do that | 10:58 |
| sean-k-mooney | the python bindings should have the same behavior as the api | 10:58 |
| bauzas | if we only talk about CLI, then agreed on the fact this is purely an OSC check | 10:58 |
| bauzas | sean-k-mooney: and agreed on the fact the bindings should just be passthroughs to API calls | 10:58 |
| bauzas | no smartness in therre | 10:58 |
| bauzas | thereù | 10:58 |
| bauzas | shit | 10:59 |
| bauzas | there* | 10:59 |
| sean-k-mooney | :) | 10:59 |
| bauzas | whoami-rajat: so, as said, I'd appreciate if you could write a spec follow-up for this param | 10:59 |
| bauzas | so we would agree on it | 10:59 |
| sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/831014/4/openstackclient/compute/v2/server.py#3236 | 11:00 |
| sean-k-mooney | that what i think we need to do in osc | 11:00 |
| bauzas | as a reminder, some ops are reading our specs to understand the intents | 11:00 |
| sean-k-mooney | i tought it was pretty clear | 11:00 |
| sean-k-mooney | The python-novaclient, python-openstackclient and SDK will be updated | 11:00 |
| sean-k-mooney | to support the new microversion. | 11:00 |
| sean-k-mooney | then sepera sentance | 11:01 |
| sean-k-mooney | n additional parameter ``--confirm-reimage`` will be added as a check | 11:01 |
| sean-k-mooney | (along with the microversion check) on the client side that will determine | 11:01 |
| sean-k-mooney | if the user really wants to opt into the new functionality. | 11:01 |
| sean-k-mooney | i guess we can clarify the second one | 11:01 |
| sean-k-mooney | and say openstack client | 11:01 |
| bauzas | yes, I have problems with the second one | 11:01 |
| bauzas | and yes, we should clarify the difference between the python client bindings and the shell commands | 11:01 |
| sean-k-mooney | and "really wants to opt into" -> "to confime they want to proceed" | 11:01 |
| bauzas | yes | 11:01 |
| whoami-rajat | ack will update that as well, client -> openstack client | 11:01 |
| bauzas | to opt-into means you can say no | 11:02 |
| bauzas | but here, you can't say no if you set 2.93 | 11:02 |
| sean-k-mooney | yep | 11:02 |
| bauzas | I guess I was confused by the verb | 11:02 |
| bauzas | and I guess operators can read they can turn off this even with 2.93 | 11:03 |
| sean-k-mooney | i understood the intent but also have extra context which biases my interpritation | 11:03 |
| bauzas | we just need to clarify there are no ways to refuse this contract if you specify 2.93 | 11:03 |
| bauzas | (or later) | 11:03 |
| bauzas | the check is purely a safety belt to ensure that the user knows what he's asking | 11:04 |
| bauzas | this isn't a "check" | 11:04 |
| bauzas | this is a "forced doubled signal" | 11:04 |
| opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: MV 2.93 - Add support to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | 11:13 |
| whoami-rajat | sean-k-mooney, bauzas ^ updated | 11:16 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/victoria: add regression test case for bug 1978983 https://review.opendev.org/c/openstack/nova/+/854979 | 11:22 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/victoria: For evacuation, ignore if task_state is not None https://review.opendev.org/c/openstack/nova/+/854980 | 11:22 |
| whoami-rajat | sean-k-mooney, hey, so for checking if instance is BFV, should i check the "image" field and check if it's empty ? | 11:41 |
| sean-k-mooney | whoami-rajat: i think that is likely the only way yes | 12:38 |
| sean-k-mooney | unless you were to check this from cinder somehow | 12:39 |
| sean-k-mooney | you do not have access to the bdm info at the api level | 12:39 |
| sean-k-mooney | you can check the cinder attachment/volume info but i dont know if the re is a bfv ro i am the root disk flag on the cidner side that you can use | 12:40 |
| whoami-rajat | sean-k-mooney, I don't think there's a root disk flag on the cinder side, we just have attachment info | 12:52 |
| whoami-rajat | one other thing we've is if the volume is bootable or not but again we can do a normal attach on a bootable volume and it could not be a root disk | 12:52 |
| sean-k-mooney | ya so for now checkign the server image filed is proably the best approch | 12:54 |
| opendevreview | Amit Uniyal proposed openstack/nova master: add regression test case for bug 1552777 https://review.opendev.org/c/openstack/nova/+/855900 | 13:26 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Adds check for instance resizing https://review.opendev.org/c/openstack/nova/+/855901 | 13:26 |
| *** dasm is now known as Guest2115 | 13:31 | |
| elodilles | bauzas: may i update the meetings page stable section or you are editing the page currently? | 13:39 |
| bauzas | elodilles: please do it | 13:39 |
| elodilles | ++ | 13:39 |
| elodilles | bauzas: done | 13:42 |
| *** Guest2115 is now known as dasm | 14:02 | |
| sean-k-mooney | looks like we might have a gap in our test fixtures | 14:15 |
| sean-k-mooney | https://paste.opendev.org/show/bageEC5wOh09aqjEJyGG/ | 14:16 |
| bauzas | reminder: nova meeting in 1 hour here | 15:00 |
| Uggla | oops I have just realized, I completely forget about the bug week baton. :( | 15:12 |
| Uggla | I can do it again this week. If you wish. | 15:13 |
| bauzas | Uggla: no problem at all, this is purely optional work | 15:13 |
| bauzas | Uggla: heh, fer sur | 15:13 |
| bauzas | the bug number only increased by 2. | 15:13 |
| bauzas | 9 "new" bugs | 15:13 |
| Uggla | shame on me. :) | 15:14 |
| bauzas | no shame at all | 15:14 |
| bauzas | I had the same situation when I was in Berlin :) | 15:14 |
| bauzas | gmann: around ? | 15:29 |
| bauzas | gmann: fwiw, I'll discuss https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html at the nova meeting, I'd appreciate if you could be around when we discuss to clarify any question | 15:29 |
| dansmith | bauzas: nova just needs to sign up for one of the slots, | 15:30 |
| dansmith | and plan to have operator-focused discussions during that slot | 15:30 |
| bauzas | sure, I understood it | 15:30 |
| dansmith | likely for a "pain points" sort of thing, or other things they want to bring up | 15:30 |
| dansmith | okay | 15:30 |
| bauzas | but any case of any fancy question | 15:30 |
| bauzas | I couldn't be able to answer | 15:30 |
| dansmith | I'll be around and should be able to answer questions | 15:30 |
| bauzas | what I also understood is that there is no reason to keep a competitive timeslot for the project as a different room | 15:31 |
| bauzas | like, if I was choosing Tuesday 1pm UTC, I should unbook the nova timeslot in the bexar room | 15:32 |
| bauzas | but we'll figure it out | 15:32 |
| dansmith | no, | 15:32 |
| dansmith | I think nova just needs to choose a slot and make sure our schedule lines up for that session during that slot.. I thought it was supposed to be in the nova room, not a separate one | 15:33 |
| dansmith | I guess maybe he just put them in some room in order to lodge the timeslot, but I think it should be rescheduled to our room in that slot | 15:34 |
| dansmith | yeah "projects can convert/reserve them" | 15:34 |
| bauzas | yup, I was about to unbook the nova-placement slot accordingly but reuse this timeslot with the operator-nova-friendly track or whatever this is called | 15:34 |
| dansmith | ack, but in our room | 15:35 |
| bauzas | yup, just explained this in the infra-events chan | 15:36 |
| bauzas | Bexar, this is | 15:37 |
| bauzas | no need to ask our developers to switch rooms | 15:37 |
| dansmith | right | 15:40 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Sep 6 16:00:11 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | hello everyone | 16:00 |
| elodilles | o/ | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| dansmith | o/ | 16:00 |
| bauzas | let's start while people arrive | 16:01 |
| bauzas | we have a few things to discuss | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| gibi | o/ | 16:02 |
| sean-k-mooney | o/ | 16:02 |
| bauzas | #info Three Critical bugs | 16:02 |
| bauzas | that's a bummer | 16:02 |
| bauzas | but we have a story against each | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1988311 See https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030325.html | 16:02 |
| bauzas | seems we have a way forward | 16:02 |
| bauzas | with oslo.concurrency patches | 16:03 |
| gibi | yeah there is a new oslo.concurrency release | 16:03 |
| bauzas | yup | 16:03 |
| gibi | the next step is to get the global version bump | 16:03 |
| bauzas | correct | 16:03 |
| gibi | I will abandon the nova specific patches once we have the bump merged | 16:04 |
| gibi | we have to make sure though that stable/yoga gets the new oslo version too | 16:04 |
| bauzas | yeah | 16:04 |
| sean-k-mooney | i also have patches to fix fastener and update oslo in flight | 16:04 |
| bauzas | I don't see any u-c change yet | 16:04 |
| sean-k-mooney | thos will be for A | 16:04 |
| sean-k-mooney | a this point | 16:04 |
| Uggla | o/ | 16:05 |
| bauzas | but I assume this patch will be done sooner than later | 16:05 |
| gibi | yes based on the mail thread Herve will propose the bump | 16:06 |
| gibi | https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030352.html | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | 16:06 |
| opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.94 https://review.opendev.org/c/openstack/nova/+/852088 | 16:06 |
| Uggla | oops sorry for that ^ | 16:06 |
| bauzas | gibi: would you propose a patch to nova's requirements.txt or do we automatically pull the latest ? | 16:07 |
| sean-k-mooney | https://review.opendev.org/c/openstack/requirements/+/856044 | 16:07 |
| gibi | we are not constrained in noca | 16:07 |
| gibi | nova | 16:07 |
| sean-k-mooney | i think that is the requiremtns bump | 16:07 |
| bauzas | gibi: ok, so we'll benefit from it | 16:08 |
| gibi | yep, automatically | 16:08 |
| sean-k-mooney | we shoudl once that merges yep | 16:08 |
| bauzas | https://github.com/openstack/nova/blob/master/requirements.txt#L34 | 16:08 |
| bauzas | yup, we're not constrained | 16:08 |
| bauzas | ok, let's wait for the req patch to be merged then | 16:08 |
| bauzas | for stable/yoga, seems we don't cap too | 16:09 |
| bauzas | https://github.com/openstack/nova/blob/stable/yoga/requirements.txt#L30 | 16:09 |
| sean-k-mooney | correct | 16:09 |
| gibi | coo | 16:09 |
| gibi | l | 16:09 |
| sean-k-mooney | we can either pull in the latest oslo release there or cap fasterners | 16:09 |
| bauzas | ok, we're on the good way | 16:09 |
| bauzas | moving on to the next bug then | 16:09 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1988316 Will be set to High now that the gate is skipping the test | 16:10 |
| bauzas | people agree with the proposal ? | 16:10 |
| gibi | sean-k-mooney: I would bump this https://github.com/openstack/requirements/blob/stable/yoga/upper-constraints.txt#L26 | 16:10 |
| bauzas | => High | 16:10 |
| bauzas | gibi: oh you're right about yoga's u-c | 16:10 |
| gibi | on the unshelve stuff I think we need a nova fix to return a better error message, but I'm OK to drop it from Critical to High | 16:11 |
| bauzas | yeah | 16:11 |
| gibi | it is not blocking the gate at the moment | 16:11 |
| bauzas | not saying there will be no bug to fix | 16:11 |
| sean-k-mooney | ya its a latent bug | 16:11 |
| bauzas | but this isn't longer critical as the gate is now working back | 16:12 |
| dansmith | unshelve thing meaning the to-host cell one? | 16:12 |
| sean-k-mooney | yes | 16:12 |
| bauzas | yup | 16:12 |
| bauzas | saying we have to restrict to the same cell | 16:12 |
| dansmith | yeah, that's not new just recently exposed so doesn't seem like we should be too critical in the bug status there | 16:12 |
| sean-k-mooney | im saying its latent as its the same error we would have got with unshelve to AZ we just dont have test coverage for that in tempest that was also corss cell | 16:12 |
| dansmith | right, and I'm saying being latent it's not a regression, so really shouldn't be >high :) | 16:13 |
| sean-k-mooney | +1 | 16:13 |
| bauzas | honestly, I'm in favor of saying "sorry but we don't support *yet* cross-cell unshelve to host" that's it | 16:13 |
| bauzas | so the fix could be just docs | 16:13 |
| bauzas | and a better exception handling | 16:14 |
| sean-k-mooney | yep we can do both | 16:14 |
| bauzas | anyway, set to High, there is | 16:14 |
| dansmith | well, the test needs fixing too | 16:15 |
| dansmith | it's just being skipped there right now right? | 16:15 |
| bauzas | yup | 16:15 |
| sean-k-mooney | the test is not broken | 16:15 |
| sean-k-mooney | it just should not be run in a cross cell env | 16:15 |
| bauzas | yeah, the test shouldn't be assuming we could | 16:15 |
| sean-k-mooney | no this is a job config issue | 16:15 |
| bauzas | if we would want a test, this would have to be negative | 16:15 |
| sean-k-mooney | you cant tell if its cross cell form the api | 16:16 |
| bauzas | like "I know this can't work" | 16:16 |
| sean-k-mooney | so tempest cannot detech that | 16:16 |
| sean-k-mooney | so this has to be done via job config | 16:16 |
| bauzas | ahah true | 16:16 |
| bauzas | anyway, bug report is still open, feel free to comment it out for resolution | 16:16 |
| bauzas | moving on | 16:16 |
| opendevreview | Rajat Dhasmana proposed openstack/nova-specs master: Clarify client changes in rebuild spec https://review.opendev.org/c/openstack/nova-specs/+/856164 | 16:16 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1988482 Proposed patch on the fly https://review.opendev.org/c/openstack/nova/+/855658 | 16:17 |
| bauzas | as said, reviews are welcome ^ | 16:17 |
| dansmith | sean-k-mooney: shoudn't the test be using an az? | 16:17 |
| bauzas | I exceptionally relaxed my review needs | 16:17 |
| dansmith | anyway, we can discuss elsewhere | 16:17 |
| bauzas | so I gave +2 for a patch without testing | 16:17 |
| sean-k-mooney | dansmith: i dont think so be we can follow up after ya | 16:17 |
| bauzas | tl;dr: the problem is with PrettyTable having a changed behavior | 16:18 |
| sean-k-mooney | yes so they have now fixed this by reverting the behaivor | 16:18 |
| bauzas | gibi: sean-k-mooney: wants to address this issue now ? | 16:18 |
| sean-k-mooney | i tested with the previous release broken release and new release with the revert | 16:18 |
| sean-k-mooney | i woudl prefer to merge and backprot https://review.opendev.org/c/openstack/nova/+/855658 | 16:19 |
| bauzas | so https://review.opendev.org/c/openstack/nova/+/855658 wouldn't be needed ? | 16:19 |
| bauzas | ack | 16:19 |
| sean-k-mooney | to yoga so we never need to thnk about htis again | 16:19 |
| sean-k-mooney | its not needed unless the decided to reinstate the feature or change the default | 16:19 |
| sean-k-mooney | or we can hardcode the alignmend and not worry | 16:20 |
| gibi | I agree we sean-k-mooney | 16:20 |
| bauzas | gibi: didn't know this verb | 16:20 |
| bauzas | I sean-k-mooney, you sean-k-mooney | 16:20 |
| bauzas | :) | 16:20 |
| sean-k-mooney | :) | 16:20 |
| gibi | but as an extra: in general we don't have py39 lines in the global requirements so this can hit us with different packages | 16:20 |
| gibi | bauzas: :) | 16:21 |
| gibi | I think there was a discussion in relmgmt about adding those lines | 16:21 |
| gibi | in yoga we should have been upper constrained | 16:21 |
| sean-k-mooney | it could hit distos if the distro had 3.4.0 | 16:21 |
| elodilles | (rather on requirements, but yes) | 16:21 |
| bauzas | yeah | 16:21 |
| gibi | elodilles: then there :) same folks :) | 16:22 |
| sean-k-mooney | anyway i think we can just review this normally | 16:22 |
| sean-k-mooney | not critical | 16:22 |
| gibi | agree | 16:22 |
| sean-k-mooney | it was just annoying as it was blocking some backports | 16:22 |
| sean-k-mooney | its not now | 16:22 |
| bauzas | ok, so chaning the prio to High ? | 16:23 |
| bauzas | because of the requirements patch ? | 16:23 |
| gibi | I agree that this is not critical now | 16:24 |
| bauzas | ok, punting the prio then | 16:24 |
| bauzas | sean-k-mooney: please just update the bug report with your thoughts please | 16:24 |
| sean-k-mooney | ack | 16:24 |
| sean-k-mooney | will do | 16:24 |
| bauzas | moving on, we still have lots of things to discuss | 16:24 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 9 new untriaged bugs (+2 since the last meeting) | 16:25 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (-1 since the last meeting) in Storyboard for Placement | 16:25 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:25 |
| bauzas | #info bug baton is being passed to Uggla | 16:25 |
| bauzas | that's it for bugs | 16:25 |
| Uggla | yep I will not forget that time. | 16:25 |
| bauzas | (yeah Uggla kindly offered to keep the baton for this week, thanks to him) | 16:25 |
| bauzas | Uggla: no pain here | 16:26 |
| bauzas | this is stretch goal | 16:26 |
| bauzas | anyway, moving on | 16:26 |
| bauzas | #topic Gate status | 16:26 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:26 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:26 |
| bauzas | #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly Centos 9 Stream periodic job status | 16:26 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:26 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:26 |
| bauzas | I checked all the periodic runs and all are green | 16:27 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:27 |
| bauzas | I think we discussed about the current gate bugs, we can move on | 16:27 |
| bauzas | #topic Release Planning | 16:27 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:27 |
| bauzas | #info Zed-3 was last Thursday | 16:27 |
| bauzas | hereby, I declare | 16:27 |
| bauzas | #info FeatureFreeze officially declared today | 16:27 |
| elodilles | \o/ | 16:28 |
| bauzas | #action bauzas to -2 open changes that were having an accepted spec | 16:28 |
| bauzas | #action bauzas to run the script to move specs with merged implementation to 'implemented' | 16:28 |
| bauzas | #link Zed tracking etherpad: https://etherpad.opendev.org/p/nova-zed-blueprint-status | 16:28 |
| bauzas | we still have some client changes that require reviews | 16:28 |
| bauzas | in theory, we are in client libs freeze too | 16:29 |
| bauzas | https://releases.openstack.org/zed/schedule.html#z-final-clientlib | 16:29 |
| bauzas | elodilles: what do you think of that ? | 16:29 |
| opendevreview | Merged openstack/nova master: Follow up for the PCI in placement series https://review.opendev.org/c/openstack/nova/+/855185 | 16:30 |
| elodilles | just wanted to warn that we are in freeze period | 16:30 |
| elodilles | for that as well | 16:30 |
| bauzas | shall we stop merging novaclient and OSC patches until next cycle or shall we pretend this never existed and be pragmatic ? | 16:30 |
| opendevreview | Merged openstack/nova master: Doc follow up for PCI in placement https://review.opendev.org/c/openstack/nova/+/855186 | 16:30 |
| bauzas | ok, so releasing wouldn't be acceptable | 16:30 |
| bauzas | but I guess merging patches doesn't create issues | 16:31 |
| sean-k-mooney | we can review but proably hold +w for a week | 16:31 |
| elodilles | well, if patches merges, and new release is needed, then RFE is needed | 16:31 |
| sean-k-mooney | the branches will reopen at RC1 | 16:31 |
| elodilles | so non critical things probably should be postponed to Antelope | 16:31 |
| bauzas | I don't disagree with this, I was just wondering about the difference between holding a merge, and merging without releasing | 16:32 |
| sean-k-mooney | we can alwasy do an early release of novaclient or osc in a few weeks | 16:32 |
| sean-k-mooney | bauzas: rc bug fixes is really the only issue | 16:32 |
| gibi | merging without releasing can be confusing for zed as the branch have it but the release does not | 16:32 |
| sean-k-mooney | until we have the branch | 16:32 |
| bauzas | ok, so let's agree to hold our commits | 16:33 |
| sean-k-mooney | we cant merge feature incase there is a bug fix needed | 16:33 |
| sean-k-mooney | branches will be create at rc1 | 16:33 |
| elodilles | bauzas: ++ | 16:33 |
| bauzas | #agreed Client patches are on Client libs freeze, please don't accept to merge new changes until RC1 happens | 16:33 |
| bauzas | voila | 16:33 |
| dansmith | did the rebuild bfv change merge? | 16:33 |
| dansmith | for the client I mean | 16:34 |
| bauzas | the novaclient one, not | 16:34 |
| bauzas | we were reviewing it today, hence my question | 16:34 |
| bauzas | we have novaclient support until 2.92 | 16:34 |
| dansmith | hmm, seems bad to not have that present in the client if we've got it as a server feature | 16:34 |
| bauzas | and OSC support until 2.91 IIRC | 16:34 |
| bauzas | dansmith: fwiw, we have a difference between what the server supports and what the client can negociate | 16:35 |
| sean-k-mooney | dansmith: that is why i was suggesting we do a release in a few weeks | 16:35 |
| bauzas | yoga didn't had this issue, no microversion patch was merged | 16:35 |
| bauzas | so, this is my first time :) | 16:35 |
| dansmith | okay, so you're saying we wait for rc1 then do a client release soonly so people will be able to actually use it? | 16:36 |
| sean-k-mooney | its not the first time we have not had parity between api and cli | 16:36 |
| sean-k-mooney | dansmith: yep | 16:36 |
| dansmith | okay | 16:36 |
| sean-k-mooney | dansmith: at leat that is what im suggesting | 16:36 |
| bauzas | dansmith: I'm not saying anything, I'm asking for help | 16:36 |
| bauzas | if we all agree on the discrepancy, we should also agree on the fact this isn't great | 16:37 |
| dansmith | as long as there's a short timeline to getting the client released then I guess that's okay | 16:37 |
| bauzas | that client libs freeze doesn't really help, fwiw | 16:37 |
| sean-k-mooney | it does | 16:37 |
| sean-k-mooney | normally | 16:37 |
| bauzas | ideally, we should have a one week difference I think between the server freeze and the client freeze | 16:37 |
| dansmith | bauzas: do we not? | 16:38 |
| dansmith | I guess I'm confused, seems like this is the week to get the client things finalized | 16:38 |
| bauzas | dansmith: not in the zed schedule | 16:38 |
| bauzas | hence my call for clarification | 16:38 |
| dansmith | hrm okay | 16:38 |
| dansmith | that | 16:38 |
| dansmith | is a bit of a bummer | 16:38 |
| bauzas | can't disagree | 16:39 |
| dansmith | I dunno what distros do for picking client releases, but they'd need to know that they need the one right after the zed server release to have this | 16:39 |
| dansmith | but whatever | 16:39 |
| sean-k-mooney | feedback i guess for tc/cross project ptg session | 16:39 |
| bauzas | agrred | 16:39 |
| dansmith | I think that's just for the release team | 16:39 |
| bauzas | the antelope schedule is already accepted but I guess we can debate it at the PTG | 16:39 |
| sean-k-mooney | ya perhaps | 16:40 |
| dansmith | we approve the schedule but don't really do much other than that I think | 16:40 |
| sean-k-mooney | well the schdule can be updated if we think it need changes | 16:40 |
| bauzas | just as a hint for next cycle https://releases.openstack.org/antelope/schedule.html | 16:40 |
| sean-k-mooney | its just anohter review | 16:40 |
| bauzas | anyway, moving on | 16:40 |
| bauzas | #link https://review.opendev.org/c/openstack/releases/+/855974 Nova Zed cycle highlights | 16:41 |
| bauzas | I'd appreciate if people could review my prose | 16:41 |
| bauzas | even if we didn't had a lot of blueprints, this was a productive cycle | 16:41 |
| bauzas | and I guess the marketing folks will love all the buzz words I used | 16:42 |
| bauzas | kudos to the team for the hard work you made, very well appreciated | 16:42 |
| gibi | I will re-review shortly | 16:42 |
| bauzas | gibi: YAMLs don't help with fancy formatting, unfortunatelty | 16:42 |
| bauzas | next topic then | 16:43 |
| gibi | that makes me sad | 16:43 |
| bauzas | #topic PTG planning | 16:43 |
| bauzas | thanks to gibi, | 16:43 |
| bauzas | #link https://etherpad.opendev.org/p/nova-antelope-ptg Antelope PTG etherpad | 16:43 |
| gibi | I needed it as I had a topic :) | 16:43 |
| bauzas | feel free to add your items you'd like to discuss | 16:44 |
| bauzas | the earlier be the better | 16:44 |
| bauzas | since we didn't had an agenda yet, I made a proposal : | 16:44 |
| gibi | also we should add a retro topic about prorities and more frequent deadlines | 16:44 |
| bauzas | #info bauzas has asked for 4 hours per day for Tuesday to Friday (Bexar room) | 16:44 |
| bauzas | gibi: feel free to add anything | 16:44 |
| gibi | anything? :) no you don't want that :D | 16:45 |
| bauzas | well, this is an open text file | 16:45 |
| gibi | just joking :) | 16:45 |
| bauzas | but yeah, we'll have a retro, of course | 16:45 |
| * bauzas has to add the usual topics we discuss | 16:45 | |
| bauzas | so, about the proposed schedule | 16:45 |
| bauzas | I booked 4x4 hours | 16:46 |
| bauzas | with the bexar room | 16:46 |
| bauzas | maybe we would need less | 16:46 |
| bauzas | I can unbook the room if so | 16:46 |
| bauzas | so, the plan is to not feel constrained by the schedule | 16:46 |
| bauzas | but obviously, if we keep with 4x4hours, we'll manage decent time offs :) | 16:47 |
| bauzas | #link https://ptg.opendev.org/ptg.html PTG schedule | 16:47 |
| bauzas | anyone having serious concerns with the proposed timeslots ? | 16:47 |
| bauzas | anyone wanting an asian-friendly timeslot ? | 16:47 |
| bauzas | I don't hear anything | 16:48 |
| bauzas | sold. | 16:48 |
| bauzas | last point, and I'm rushing because time flies | 16:48 |
| bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html operator friendly timeslots, which ones for Nova ? | 16:48 |
| bauzas | as you probably already read, TC proposes us to reserve some slots for operators-friendly discussions | 16:49 |
| bauzas | I'm more than happy with the idea | 16:49 |
| bauzas | so, shall we reserve one hour per day about this ? | 16:49 |
| bauzas | or just, for example, one hour on the first two days ? | 16:49 |
| gibi | do we need 4 hours total? | 16:49 |
| gibi | sorry | 16:50 |
| bauzas | or two hours back-to-back ? | 16:50 |
| bauzas | or no operator hours at all ? | 16:50 |
| bauzas | personnally, I feel this can be more than interesting | 16:50 |
| dansmith | the idea is just one of those slots for nova | 16:50 |
| bauzas | and we should have at least 2 hours at the beginning of our talks | 16:50 |
| dansmith | so you can have more slots than that, but the idea is that they're not overlapping so operators have only one place to be, if they have multiple interests | 16:50 |
| bauzas | in order to discuss about what they told us during the other days | 16:50 |
| bauzas | dansmith: yean, we could reserve other slots than the 4x4 hours we already have | 16:51 |
| bauzas | but honestly, I just hope we can find propre timeslots ? | 16:51 |
| bauzas | within the existing ones | 16:51 |
| bauzas | so, | 16:51 |
| bauzas | any proposal or should I just shoot a strawman ? | 16:52 |
| bauzas | OK, you leave me no choice | 16:52 |
| bauzas | #info bauzas to propose Tuesday 13-15UTC for operator-friendly slots | 16:53 |
| gibi | works for me :) | 16:53 |
| bauzas | #info bauzas to propose a tentative slot on Wed 16-17UTC for operators who aren't able to join on Tuesday | 16:54 |
| bauzas | that would leave 3 hours for operations-friendly talks | 16:54 |
| bauzas | this is a bit huge but I expect those discussions to be productive | 16:54 |
| bauzas | that's it for me | 16:55 |
| bauzas | next topic | 16:55 |
| bauzas | #topic Review priorities | 16:55 |
| bauzas | let's skip them, we're overtimle | 16:55 |
| bauzas | #topic Stable Branches | 16:55 |
| bauzas | elodilles: shoot | 16:55 |
| elodilles | #info stable/yoga is blocked due to py39 job is failing with prettytable 3.4.0; prettytable 3.4.1 fixes the issue so as soon as constraints are updated in requirements repository the gate will be OK | 16:55 |
| elodilles | (the same we discussed above) | 16:56 |
| bauzas | we discussed this | 16:56 |
| bauzas | cool | 16:56 |
| elodilles | #info stable/stein (and older) are blocked: grenade and other devstack based jobs fail with the same timeout issue as stable/train was previously | 16:56 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:56 |
| bauzas | the infection increases. | 16:56 |
| elodilles | these were the main points :X | 16:56 |
| bauzas | well, I'd say stable/train can be a concern to me | 16:57 |
| bauzas | for others, well, ExtendedMaintenance | 16:57 |
| bauzas | so, the ones who care should just raise a hand | 16:58 |
| bauzas | but we're approaching the top of the hour | 16:58 |
| bauzas | #topic Open discussion | 16:59 |
| bauzas | anything anyone for last min ? | 16:59 |
| bauzas | guess not | 16:59 |
| bauzas | thanks all | 16:59 |
| bauzas | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Tue Sep 6 16:59:44 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-06-16.00.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-06-16.00.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-06-16.00.log.html | 16:59 |
| elodilles | thanks bauzas o/ | 16:59 |
| elodilles | and you saved 16 seconds from the meeting :-o amazing! | 17:00 |
| gibi | and it is gone :D | 17:01 |
| bauzas | we're asked to reduce our electricity | 17:01 |
| bauzas | I just save a few kWh | 17:01 |
| elodilles | :] | 17:07 |
| gibi | fyi I added a topic generic to the PTG etherpad about catching design issues eariler in the cycle, please add your ideas there | 17:07 |
| gibi | * generic topic | 17:07 |
| opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Move specs to implemented https://review.opendev.org/c/openstack/nova-specs/+/856173 | 17:26 |
| opendevreview | Merged openstack/nova master: Add missing descriptions in HACKING.rst https://review.opendev.org/c/openstack/nova/+/853054 | 18:25 |
| opendevreview | Merged openstack/python-novaclient master: MV 2.93 - Add support to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | 18:33 |
| JayF | These two Ironic driver changes are ready for review into stable/train -- Ironically, they have +2s from two different folks https://review.opendev.org/c/openstack/nova/+/853546 https://review.opendev.org/c/openstack/nova/+/821352 | 21:59 |
| opendevreview | Takashi Natsume proposed openstack/nova master: Add a hacking rule for the setDaemon method https://review.opendev.org/c/openstack/nova/+/854653 | 22:13 |
| *** dasm is now known as dasm|off | 22:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!