| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-27 | |||
| 16:25:56 | bauzas | #topic Release Planning | |
| 16:26:02 | bauzas | We past M2 and spec freeze. M3 is in 5 weeks. | |
| 16:26:10 | bauzas | We have 21 approved an open blueprints and we have 5 weeks to finish them. Please focus review effort on bps in Needs Code Review state. | |
| 16:26:29 | bauzas | that reminds me, people have to make sure their blueprint is on Needs Code Review | |
| 16:26:51 | bauzas | #link https://launchpad.net/nova/+milestone/xena-3 | |
| 16:27:35 | bauzas | the delivery status doesn't really mean anything but that can help reviewers to know which series to look at | |
| 16:27:49 | bauzas | so, if you love reviews, you know what to do | |
| 16:28:19 | bauzas | Next deadline is non-client library freeze at 16th of August | |
| 16:28:43 | bauzas | think about it for os-resource-class ;) | |
| 16:28:58 | bauzas | moving on | |
| 16:29:06 | bauzas | #topic PTG Planning | |
| 16:29:14 | bauzas | PTG timeslots booked by gibi, see #link http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023787.html | |
| 16:29:24 | bauzas | The PTG etherpad is ready to be filled with topics: #link https://etherpad.opendev.org/p/nova-yoga-ptg | |
| 16:29:37 | bauzas | If you see a need for a specific cross project section then please let gibi know | |
| 16:30:22 | bauzas | I'm pretty sure this etherpad will be filled before we have the PTG :) | |
| 16:30:47 | bauzas | #topic Stable Branches | |
| 16:30:56 | bauzas | elodilles: flood is yours | |
| 16:31:01 | bauzas | floor* | |
| 16:31:06 | bauzas | (oh man) | |
| 16:31:09 | elodilles | stable gates are not blocked | |
| 16:31:10 | elodilles | :) | |
| 16:31:18 | elodilles | at least as far as I can tell | |
| 16:31:19 | bauzas | excellent, excellent :D | |
| 16:31:46 | bauzas | tbh, this is not really time of the cycle when I look at stable changes | |
| 16:31:47 | elodilles | not so much activity around stable branches (M2, M3, vacations, etc...) | |
| 16:32:16 | bauzas | yup, most of the team efforts are focused on feature delivery as we speak, I guess | |
| 16:32:18 | elodilles | bauzas: true :) | |
| 16:32:21 | bauzas | moving on | |
| 16:32:30 | bauzas | #topic Sub/related team Highlights | |
| 16:32:36 | bauzas | Libvirt (bauzas) | |
| 16:32:45 | bauzas | bauzas: floor is your | |
| 16:32:52 | bauzas | bauzas: thanks | |
| 16:32:57 | bauzas | bauzas: nothing to report, sir. | |
| 16:33:01 | bauzas | bauzas: thanks. | |
| 16:33:05 | bauzas | moving on. | |
| 16:33:25 | bauzas | #topic Open discussion | |
| 16:33:40 | bauzas | I refreshed and nothing popped in the wikipage while we were speaking | |
| 16:34:01 | bauzas | so, nothing to say on this today, unless someone wanna raise something now | |
| 16:34:35 | stephenfin | nope | |
| 16:34:41 | bauzas | (I guess my fake dialog frightened a lof of people who disappeared) | |
| 16:34:55 | bauzas | oh wow, at least someone stayed \o/ | |
| 16:35:08 | bauzas | I'm not that bad actor | |
| 16:35:10 | sean-k-mooney | can we ever really leave | |
| 16:35:39 | bauzas | I could just pretend I'll keep the stick for the whole hour and prevent you to use this channel for the last 25 mins | |
| 16:35:41 | sean-k-mooney | i dont have anything more for today | |
| 16:35:51 | bauzas | privilege of the power, whahahah | |
| 16:36:39 | bauzas | but, heh, | |
| 16:36:42 | bauzas | #stopmeeting | |
| 16:36:53 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.log.html | |
| 16:36:53 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.txt | |
| 16:36:53 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.html | |
| 16:36:53 | opendevmeet | Meeting ended Tue Jul 27 16:36:53 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:36:53 | bauzas | #endmeeting | |
| 16:36:54 | bauzas | even | |
| 16:37:22 | sean-k-mooney | melwitt: bauzas do you want to chat about the allocation delete issue | |
| 16:37:38 | bauzas | sean-k-mooney: I guess I need to look at the original change | |
| 16:38:12 | sean-k-mooney | it didnt really contain much more motivation then we surmised already | |
| 16:38:33 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/591597 | |
| 16:39:31 | sean-k-mooney | it looks like the current intent was to put the instance in error if there was a conflict | |
| 16:39:47 | sean-k-mooney | which you would preumable fix by deleting it again | |
| 16:40:21 | sean-k-mooney | so based on that https://bugs.launchpad.net/nova/+bug/1836754 is invlid | |
| 16:40:29 | sean-k-mooney | since that is the expect behavior | |
| 16:40:55 | sean-k-mooney | and presumable tempest does not handel the fact delete can fail and it shoudl retry | |
| 16:41:39 | melwitt | no it does not. I debated whether that should be the fix, to retry on 409 during resource cleanup | |
| 16:41:52 | melwitt | but then I found the WIP change and thought it didn't seem like good UX to ever reject a delete request from a user | |
| 16:42:08 | sean-k-mooney | right | |
| 16:42:22 | melwitt | that was in fact one of the things customers within yahoo when I worked there were vehement about, delete should never fail | |
| 16:42:26 | sean-k-mooney | but if we decied its not a good ux to delete it form the user instead of https://review.opendev.org/c/openstack/nova/+/688802 | |
| 16:42:40 | sean-k-mooney | we should revert the previous patch and start callign delete again on plamcnet | |
| 16:44:06 | melwitt | I'm cool with that too. I wasn't 100% sure whether there's internal cases where we would want the chance to know about a conflict | |
| 16:44:18 | sean-k-mooney | melwitt: basiclaly i think we have 2 options. mark the bug as invilad and adapt tempset for the 409, or always call placemtn with DELETE | |
| 16:44:29 | sean-k-mooney | i dont think we need a new arguement that default to ture | |
| 16:45:04 | bauzas | I see two different things here | |
| 16:45:07 | sean-k-mooney | melwitt: do we know of any internal cases this would protect form | |
| 16:45:20 | bauzas | 1/ a delete should always work and never return an exception, for sure | |
| 16:45:39 | bauzas | 2/ a racing delete could tho leave orphaned allocations and that's fine | |
| 16:45:46 | melwitt | sean-k-mooney: they're in the WIP patch, one of them was during a soft-delete reclaim periodic. I need to look again to see the other cases where we would pass force=False | |
| 16:46:19 | sean-k-mooney | melwitt: ack | |
| 16:46:29 | melwitt | but yeah for sure when it's an end user requesting delete we should ensure that cannot fail | |
| 16:48:22 | melwitt | bauzas: only adjacent to how this discussion came about, I would love for you to be the second reviewer on the placement consumer types series, if you might have interest | |
| 16:48:43 | bauzas | melwitt: I can help | |
| 16:48:59 | melwitt | \o/ | |
| 16:49:26 | bauzas | I mostly work on the generic mdev stuff but I'm not sure I'll be able to put all the changes before I leave for 3 weeks, so I'll maybe turn into reviews next week | |
| 16:50:29 | melwitt | gibi has gone through it thoroughly already (thank you gibi!) so it's in a nice shape now | |
| 16:51:24 | sean-k-mooney | i can try and take a look too but while i dicuss the api of placment alot i never really look at the code so millage will vary | |
| 16:52:14 | bauzas | melwitt: ping me your series so I'll open a tab and make it a priority | |
| 16:53:39 | melwitt | sean-k-mooney: ++ | |
| 16:54:08 | melwitt | bauzas: it's 3 patches starting here https://review.opendev.org/c/openstack/placement/+/669170 I will remove the -W, I put up a DNM nova change to run with the new stuff and it all worked well _except_ for hitting the generation conflict seemingly guaranteed | |
| 16:55:42 | opendevreview | Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/c/openstack/nova/+/705657 | |
| 16:55:43 | opendevreview | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to top-level modules https://review.opendev.org/c/openstack/nova/+/705658 | |
| 16:55:44 | opendevreview | Stephen Finucane proposed openstack/nova master: WIP: Expand type hints for nova.block_device https://review.opendev.org/c/openstack/nova/+/742170 | |
| 16:55:44 | opendevreview | Stephen Finucane proposed openstack/nova master: trivial: Clean manager.Manager, service.Service signatures https://review.opendev.org/c/openstack/nova/+/764806 | |
| 16:57:15 | bauzas | melwitt: cool, will read tomorrow | |
| 16:57:42 | melwitt | thanks bauzas++ | |
| 16:59:26 | sean-k-mooney | melwitt: bauzas this is a summary of my view on the WIP patch https://review.opendev.org/c/openstack/nova/+/688802/2#message-70a28bde99719c723c954c947d0af17227a344e9 | |
| 17:00:00 | melwitt | thanks sean-k-mooney | |
| 17:00:13 | sean-k-mooney | melwitt: there are other reasonce lients can recive a 409 namely locked instances so we can go either way with it | |
| 17:00:28 | melwitt | I feel strongly that delete (by an end user) should never fail | |
| 17:00:46 | melwitt | internals can handle 409s if there is some reason to | |
| 17:00:47 | sean-k-mooney | right but the api contract is it must fail if the instance is locked | |