| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-03 | |||
| 08:13:03 | gibi | basically this is the importnat deadlines | |
| 08:13:20 | gibi | the exact dates are #link https://releases.openstack.org/xena/schedule.html | |
| 08:13:31 | gibi | is there any question about these? | |
| 08:14:42 | suzhengwei__ | Got it. | |
| 08:15:12 | gibi | cool | |
| 08:15:47 | gibi | that was what I prepared for today. | |
| 08:15:53 | bauzas | next open office hour would be around the spec freeze | |
| 08:15:53 | gibi | Is there any topic you want to discuss? | |
| 08:16:01 | bauzas | so, I have a concern | |
| 08:16:02 | gibi | bauzas: god point | |
| 08:16:05 | gibi | good even | |
| 08:16:20 | gibi | bauzas: tell us | |
| 08:16:29 | bauzas | how can we help contributors that are not in the nova meeting for their own specs ? | |
| 08:16:41 | bauzas | how can we discuss ? | |
| 08:17:08 | gibi | bauzas: what problem do you see that we need to dicuss in a meeting? stuck reviews? | |
| 08:17:19 | bauzas | and if we want to have priorities between some reviews, how could we know which ones ? | |
| 08:18:05 | bauzas | gibi: my point is that sometimes it's nice to discuss directly in IRC when you have some spec questions | |
| 08:18:10 | gibi | sure | |
| 08:18:19 | gibi | but it does not need to be a in the form of a meeting | |
| 08:18:28 | bauzas | yup | |
| 08:18:50 | bauzas | so, I wonder how we could help the contributors that aren't around in general | |
| 08:18:53 | gibi | still if there is question now, I'm happy to hear them even during this meeting | |
| 08:19:22 | gibi | bauzas: I'm OK to do discussion primarily in the spec review | |
| 08:19:52 | gibi | and if we hit a wall there then we can try to find a common time between the spec author and the reviewers to resolve | |
| 08:19:57 | gibi | the block | |
| 08:20:01 | bauzas | yup | |
| 08:20:16 | gibi | suzhengwei, XinxinShen do you have a view on this? | |
| 08:21:22 | gibi | do you feel it is hard to discuss issues about the specs? | |
| 08:23:21 | bauzas | in general, it takes more than one week | |
| 08:23:37 | bauzas | for example, when I review a spec, I provide some comment | |
| 08:23:50 | bauzas | but then the reply could be on the next day | |
| 08:24:00 | bauzas | and then I'd only see it honestly by the end of the week | |
| 08:24:23 | suzhengwei | Is this channel often open to all? I means if i want to get help, would someone react in time? | |
| 08:24:41 | bauzas | suzhengwei: yes, in general, we do it this way | |
| 08:24:50 | suzhengwei | good | |
| 08:24:58 | bauzas | suzhengwei: for example, when I'm reviewing some gibi's spec, I'm pinging him | |
| 08:25:04 | gibi | suzhengwei: it depends on the time zone. like I tend to be here between UTC 7:00 - UTC 17:00 on workdays | |
| 08:25:08 | bauzas | telling him that I had some questions | |
| 08:25:25 | bauzas | so, sometimes we directly discuss on IRC for a spec | |
| 08:25:31 | suzhengwei | cool | |
| 08:25:35 | bauzas | but like gibi said, we're both on the same TZ | |
| 08:25:45 | bauzas | so it's simple | |
| 08:26:09 | gibi | suzhengwei: I keep my client up during the night so I will see pings next day | |
| 08:26:14 | bauzas | me too | |
| 08:28:37 | XinxinShen | cool, We should ensure that the spec author and reviewer can communicate in time. | |
| 08:28:46 | gibi | suzhengwei: if you ping us, one thing to help is not just pinging but stating your problem right away | |
| 08:29:50 | suzhengwei | yes | |
| 08:30:30 | suzhengwei | I am doing some work about instance HA, and interested in the topic "Support vm evacuation while server status is suspended, paused". | |
| 08:31:00 | suzhengwei | I wonder if some one has processed it. | |
| 08:31:27 | bauzas | I still have open specs to look at | |
| 08:31:49 | suzhengwei | If not, I would like to do it. | |
| 08:31:57 | gibi | suzhengwei: interesting ideas | |
| 08:32:34 | gibi | suzhengwei: I think we don't support these today, but if with some compromise we could | |
| 08:33:18 | gibi | we will loose the in memory state of the paused instance but we could rebuild it still on another compute host | |
| 08:33:48 | gibi | and if the source compute is dead already then the in memory state is lost anyhow | |
| 08:34:13 | suzhengwei | host failure triggers evacuation. And active instance loose the in memory state too. | |
| 08:34:32 | gibi | suzhengwei: yes, so I think it is OK to lose that for the pause instance too | |
| 08:34:41 | gibi | suzhengwei, bauzas: does suspend saves some state to the disk? | |
| 08:34:49 | bauzas | good question | |
| 08:35:07 | bauzas | I honestly don't have the answer straight out of my mind | |
| 08:35:22 | gibi | anyhow if it save something to disk and that disk is on shared storage then we might even recover that saves state on the destination host | |
| 08:35:30 | bauzas | the crucial bit to remember with instance HA is that the host is already done | |
| 08:35:32 | gibi | but as a first step I would loose that too | |
| 08:35:33 | bauzas | gone* | |
| 08:35:47 | gibi | bauzas: yepp | |
| 08:35:56 | bauzas | so, yeah, ephemeral storage can't be somehow persisted | |
| 08:36:17 | gibi | except if it is on shared storage ^^ ;) | |
| 08:36:19 | bauzas | you need to have either shared storage or volumes | |
| 08:36:23 | gibi | yepp | |
| 08:36:38 | bauzas | yeah, but in general, you need to assume a crash | |
| 08:36:52 | bauzas | so any memory that's not synced is lost | |
| 08:36:58 | gibi | bauzas: yeah, this is why first I would assume that the suspended state is lost as well | |
| 08:37:16 | gibi | to avoid an inconsistent suspended state to be loaded | |
| 08:37:18 | bauzas | if suspend stores on disk, we're ok | |
| 08:37:32 | bauzas | kashyap: around ? | |
| 08:37:40 | kashyap | bauzas: Mornin, yes | |
| 08:37:53 | kashyap | How can I be useful? :) | |
| 08:37:57 | bauzas | kashyap: we are in office hour and we have a question about suspended instances | |
| 08:38:25 | bauzas | with the libvirt driver and qemu, what happens to the memory state when suspending ? | |
| 08:38:32 | bauzas | do we suspend on disk ? | |
| 08:38:41 | bauzas | I'd be inclined to say so | |
| 08:38:52 | kashyap | bauzas: gibi: Yes: suspend usually indeed means save-the-state-to-a-file-on-disk | |
| 08:39:02 | kashyap | Your inclination is correct :) | |
| 08:39:33 | bauzas | the problem is that we can't tell whether the instance is on shared storage or not | |
| 08:39:43 | gibi | kashyap: and what do you think, moves such suspended state between compute host make sense? | |
| 08:40:25 | bauzas | gibi: keep in mind evacuate is a rebuild | |
| 08:40:26 | kashyap | gibi: You mean moving such suspended state between different compute hosts make sense? | |
| 08:40:40 | gibi | kashyap: yeaht that is my queston | |
| 08:41:05 | gibi | bauzas: in case of suspend we see the vm_state on the dest being suspended so we can look for the state file on the disk. if it is there then we know that it was on shared storage | |
| 08:41:27 | bauzas | gibi: sure but then we leak the state of the host | |
| 08:41:40 | bauzas | this isn't predictable | |
| 08:42:28 | gibi | OK, I agree this can be a can of worm | |
| 08:42:54 | gibi | suzhengwei: in case of evacuating a suspended VM, is it OK to you to loose the suspended state? | |
| 08:44:03 | kashyap | gibi: I need to think a bit more about it. (libvirt has managedSave() API that does the suspend thingie, which already Nova uses. So we have the primitives...) | |
| 08:44:06 | suzhengwei | If host down, active suspend instance both loose their memory. | |
| 08:44:53 | kashyap | gibi: suzhengwei: What is the main use-case here? The ability to start suspended instances on any compute host from a given pool? | |
| 08:44:59 | gibi | suzhengwei: if you don't want to recover the suspended state that is saved to disk, then I think your proposal is pretty simple and straight forward | |
| 08:45:08 | suzhengwei | Instance Ha, try best to recover the workload as much as possible. | |
| 08:45:17 | bauzas | interestingly, I found some nova admin docs https://docs.openstack.org/nova/latest/admin/node-down.html | |
| 08:45:38 | gibi | kashyap: we looked at it from evacuation perspective. VM is suspended to disk (on shared storage), the host dies, user evacuates VM | |