| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-24 | |||
| 16:58:13 | sean-k-mooney | ... | |
| 16:58:13 | dansmith | whoami-rajat: right? | |
| 16:58:15 | whoami-rajat | but maybe I'm the only one defending the proposal | |
| 16:58:44 | whoami-rajat | dansmith, yes, for same image it does allow the rebuild | |
| 16:58:54 | dansmith | sean-k-mooney: ^ | |
| 16:59:14 | bauzas | hah | |
| 16:59:18 | sean-k-mooney | that seams like a bug | |
| 16:59:23 | sean-k-mooney | since tha talso destorys data | |
| 16:59:34 | bauzas | (18:46:01) bauzas: rebuild on BFV wasn't destructive, right? | |
| 16:59:45 | sean-k-mooney | there is no differne form a data perspective fi you use the same image or differnt one | |
| 16:59:47 | bauzas | damn, we're about the end of time | |
| 16:59:49 | dansmith | sean-k-mooney: it doesn't on BFV but does on regular instances | |
| 17:00:13 | dansmith | sean-k-mooney: on BFV if the image is the same, it will just rebuild the ports or whatever, but no change to the disk | |
| 17:00:20 | dansmith | but will destroy the disk with the same image on a regular instance | |
| 17:00:23 | bauzas | I'll close this meeting, but I beg the people here to continue discussing this topic after | |
| 17:00:24 | sean-k-mooney | that the same as a hard reboot | |
| 17:00:37 | dansmith | sean-k-mooney: alas, it's api behavior we have had for YEARS | |
| 17:00:44 | sean-k-mooney | rebuild is not a move op | |
| 17:00:49 | dansmith | so changing it to now destroy data is a Bad Plan (tm) | |
| 17:00:51 | sean-k-mooney | and it should not really update the port either | |
| 17:00:55 | dansmith | well understood :) | |
| 17:00:59 | bauzas | thanks all, and for people interested in this bfv resize discuss, please stay around | |
| 17:01:04 | bauzas | #endmeeting | |
| 17:01:04 | opendevmeet | Meeting ended Tue May 24 17:01:04 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:04 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-24-16.00.html | |
| 17:01:04 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-24-16.00.txt | |
| 17:01:04 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-24-16.00.log.html | |
| 17:01:29 | bauzas | ok, so, lemme clarify | |
| 17:01:30 | sean-k-mooney | dansmith: it feel pretty bad to have to opt in to have it do what we document | |
| 17:01:44 | dansmith | sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3617 | |
| 17:01:47 | bauzas | 1/ resize wasn't destructive on bfv if you pass the same image | |
| 17:01:48 | sean-k-mooney | the current docs https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action= link to https://bugs.launchpad.net/nova/+bug/1482040 | |
| 17:02:03 | dansmith | sean-k-mooney: if it wasn't a question of DESTROYING data I would maybe agree with you | |
| 17:02:06 | bauzas | 2/ we agree on not providing a specific param for resize on bfv | |
| 17:02:15 | dansmith | however, for years and years you could call this api and not destroy your very precious pet root volume | |
| 17:02:25 | bauzas | 3/ given 1/ and 2/, we still need a microversion to signal the behavioural change | |
| 17:02:27 | dansmith | and just silently changing that is just asking for a very angry customer | |
| 17:02:53 | sean-k-mooney | dansmith: so what is it doing in this case | |
| 17:03:00 | bauzas | sean-k-mooneypoint is, like it or not, we can't change the behaviour without signaling it | |
| 17:03:04 | sean-k-mooney | updating the image metadata | |
| 17:03:13 | dansmith | sean-k-mooney: now or after this spec merges? | |
| 17:03:16 | sean-k-mooney | if so that can break things and shoudl be blocked | |
| 17:03:20 | sean-k-mooney | now | |
| 17:03:37 | dansmith | sean-k-mooney: now it does all the rebuild machinery it just doesn't change your root disk at all | |
| 17:03:46 | dansmith | i.e. evacuate but without the move | |
| 17:04:02 | sean-k-mooney | well rebuild just does two things | |
| 17:04:03 | dansmith | I'm not so sure it's identical to a hard reboot, but maybe | |
| 17:04:13 | dansmith | it doesn't really matter though | |
| 17:04:17 | sean-k-mooney | erases epmeral storage unless its ironic and you use an api exteion | |
| 17:04:28 | sean-k-mooney | reimage the root disk and hard rebotos | |
| 17:05:10 | sean-k-mooney | dansmith: im really debating if we should be blocking rebuidl with the same image as a bug in older releases | |
| 17:05:21 | dansmith | so I think rebuild will refresh your stored image_meta if the meta has changed on your same image right? | |
| 17:05:22 | sean-k-mooney | it seam dangous to me to allow | |
| 17:05:26 | dansmith | so you could use that to get new numa settings or something | |
| 17:05:35 | sean-k-mooney | yep | |
| 17:05:35 | opendevreview | Elod Illes proposed openstack/placement stable/wallaby: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/843174 | |
| 17:05:39 | dansmith | not the intent, but could definitely be people using it that way | |
| 17:05:52 | sean-k-mooney | i only block that if the image chagnes | |
| 17:05:56 | dansmith | not that we need to allow that in the future, BUT it means they could be using it now not expecting destruction of data | |
| 17:06:05 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3647-L3648= | |
| 17:06:22 | sean-k-mooney | dansmith: if the image chagnes we validate the host in the schduler | |
| 17:06:36 | sean-k-mooney | dansmith: i belive we have an optimisation where we do not do that if its the same image | |
| 17:06:49 | sean-k-mooney | dansmith: or at least we used too but maybe that was removed | |
| 17:07:06 | dansmith | sean-k-mooney: but we update the image_meta stored with the instance and rebuild the pci device stuff | |
| 17:07:54 | whoami-rajat | with the new proposal, if opted in, we will be performing the reimage whether it is the same image or different | |
| 17:08:11 | whoami-rajat | if not opted in, we can still perform rebuild for same image but 400 for different image | |
| 17:08:21 | sean-k-mooney | no | |
| 17:08:33 | sean-k-mooney | i really dont think that is safe. i need to read the code | |
| 17:08:36 | dansmith | sean-k-mooney: no what? | |
| 17:08:50 | sean-k-mooney | but i dont think rebuidl to same image in the current case is safe in all cases | |
| 17:09:06 | whoami-rajat | we are keeping backward compatibility with the new microversion ? | |
| 17:09:33 | sean-k-mooney | im quetioning if the curren behavior in the old microverion is a bug | |
| 17:09:57 | sean-k-mooney | whoami-rajat: i tought we blocked it always | |
| 17:10:11 | sean-k-mooney | that is not the case and now im trying to assess if it currently safe as is | |
| 17:10:19 | dansmith | oh yeah rebuild also lets you add/change metadata, server name, keys, user data, hostname, certs, etc | |
| 17:10:35 | dansmith | so people could totes be using that on pets right now and expecting no data loss | |
| 17:10:37 | sean-k-mooney | yes it does now | |
| 17:10:48 | whoami-rajat | ok, I'm not too sure about it, when i started working on it I thought it wasn't supported at all but now I'm trying to impose the new behavior without differentiating with same or different image | |
| 17:11:00 | whoami-rajat | not sure if the old behavior makes sense from a nova perspective | |
| 17:11:08 | sean-k-mooney | whoami-rajat: i tought it was not supported at all too | |
| 17:12:44 | sean-k-mooney | so the resoltion for https://bugs.launchpad.net/nova/+bug/1482040 was just to note that the image is not replaced | |
| 17:12:48 | sean-k-mooney | by linking to the bug | |
| 17:13:07 | sean-k-mooney | where as teh correct fix liekly shoudl have been to block the operatio or implemtn your spec. | |
| 17:13:23 | dansmith | https://github.com/openstack/tempest/blob/44dac69eb77d78a0de8e68e63617099249345578/tempest/api/compute/servers/test_server_actions.py#L292-L329 | |
| 17:13:34 | sean-k-mooney | dansmith: so ya we likely need to actully have a microversion... | |
| 17:13:42 | dansmith | the comment there implies that the test is doing a rebuild of a volume-backed instance, but it's not, just volume-attached | |
| 17:13:49 | dansmith | but it does say "is common" FWIW :) | |
| 17:13:53 | dansmith | sean-k-mooney: yup | |
| 17:14:32 | sean-k-mooney | i really hate that but we need to fix the api ref to docuemnt this properly | |
| 17:15:00 | sean-k-mooney | i guess i can live with new microversion always reimages and old perserves current behaivor | |
| 17:15:04 | bauzas | ok, looks like we then have a consensus | |
| 17:15:07 | dansmith | "There is a known limitation where the root disk is not replaced for volume-backed instances during a rebuild." | |
| 17:15:11 | dansmith | ^ in the api-ref | |
| 17:15:14 | sean-k-mooney | dansmith: does that work for you. | |
| 17:15:27 | bauzas | dansmith: heh, I'm glad I remind this correctly | |
| 17:15:29 | sean-k-mooney | dansmith: ya but i was expecting an error in that case | |
| 17:15:44 | bauzas | sean-k-mooney: are you okay with the direction ? | |
| 17:15:51 | bauzas | personnally, I'm all good | |
| 17:15:58 | gibi | I'm ok with a new microversion | |
| 17:15:58 | dansmith | sean-k-mooney: yes, but I think that it would probably be prudent for the _client_ to have some flag if you provide the same image to make sure you really mean it | |