| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-03 | |||
| 18:18:45 | mriedem | *should be debug | |
| 18:18:48 | eandersson | I can throw up a quick commit on gerrit | |
| 18:18:52 | mriedem | ack | |
| 18:18:58 | mriedem | just don't get any on me | |
| 18:20:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create volume attachment during boot from volume in compute https://review.openstack.org/541420 | |
| 18:20:02 | mriedem | melwitt: this time with 10x more bdmturducken ^ call in the next 20 minutes and we'll double your bdms | |
| 18:20:31 | melwitt | and the peasants rejoiced | |
| 18:21:02 | Tahvok | melwitt: mriedem thanks a lot for helping with the issue! And didn't know what was going on... | |
| 18:21:16 | Tahvok | We've had it for a few months now... | |
| 18:21:21 | mriedem | i can't say that's it, but it sounds right | |
| 18:21:34 | mriedem | yeah it was a regression in ocata i believe | |
| 18:21:51 | melwitt | np, I'd been chasing that bug for a long time to get the fix out | |
| 18:49:58 | mriedem | so uh, i don't think this is ever going to be true https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3196 | |
| 18:50:06 | mriedem | is it possible to reboot a rescued instance? | |
| 18:50:09 | mriedem | the api doesn't allow it | |
| 18:50:39 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py#L69-L72 | |
| 18:51:15 | mriedem | is there some other place in nova where we internally reboot an instance when it's rescued? | |
| 18:52:49 | melwitt | I know not | |
| 18:53:13 | mriedem | git blame history here i go | |
| 18:54:01 | mriedem | https://github.com/openstack/nova/commit/39ffe806cdfe97721fee5e48c8591c4c3b52766b | |
| 18:54:22 | openstackgerrit | Merged openstack/nova master: support multiple member_of qparams https://review.openstack.org/561315 | |
| 18:54:25 | mriedem | https://github.com/openstack/nova/blob/39ffe806cdfe97721fee5e48c8591c4c3b52766b/nova/compute/api.py#L1702 | |
| 18:54:32 | mriedem | wtf, you couldn't reboot a rescue vm | |
| 18:55:57 | melwitt | what? that patch is about the vm_state, just making sure it stays "rescued" after the reboot. right? | |
| 18:56:01 | mriedem | https://review.openstack.org/#/q/topic:bug/1170237+(status:open+OR+status:merged) | |
| 18:56:18 | mriedem | yeah, but if you look at the reboot api code in that same hash, we don't allow rebooting a rescued vm | |
| 18:56:28 | melwitt | oh :\ | |
| 18:56:35 | mriedem | i mean, we don't allow rebooting an instance with vm_state=RESCUE | |
| 18:56:37 | mriedem | https://review.openstack.org/#/q/topic:bug/1170237+(status:open+OR+status:merged) | |
| 18:56:49 | mriedem | looks like some rax/xen thing | |
| 18:56:54 | mriedem | that likely never made the api change upstream | |
| 18:56:57 | mriedem | gd rax | |
| 18:57:25 | melwitt | guh, weird. so we have patches that say "now you can reboot a rescued instance" but you can't because the API kicks you out | |
| 18:57:38 | mriedem | the rax api code probably lets you | |
| 18:57:41 | melwitt | right | |
| 18:57:51 | mriedem | where was that one guy that still works at rax? | |
| 18:58:01 | mriedem | the guy always in korea.. | |
| 18:58:08 | melwitt | tbh, I don't know whether we're suppose to be able to reboot rescued instances. I'm not that familiar with the "rescue" function | |
| 18:58:18 | mriedem | neither am i, | |
| 18:58:23 | mriedem | but i can read code :) | |
| 18:58:25 | mriedem | that's how i found this | |
| 18:58:52 | melwitt | well, yeah. I mean whether or not it makes sense. I would guess from the lack of user complaints that it's not usual to try to reboot one | |
| 18:59:06 | mriedem | mikal: johnthetubaguy: when you're around, maybe you can sort this out - did rax have a proprietary change to allow rebooting rescued instances? https://review.openstack.org/#/q/topic:bug/1170237+(status:open+OR+status:merged) | |
| 18:59:24 | mriedem | because the upstream api doesn't allow that | |
| 18:59:36 | mriedem | see https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py#L69-L72 | |
| 19:09:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix being able to hard reboot a pausing instance https://review.openstack.org/566143 | |
| 19:26:58 | openstackgerrit | Oliver Walsh proposed openstack/nova master: Fix handling of connect issues in _ensure_resource_provider https://review.openstack.org/566148 | |
| 19:28:08 | mriedem | owalsh: i already have a patch up for that | |
| 19:28:13 | mriedem | beat you by a few hours | |
| 19:28:27 | mriedem | https://review.openstack.org/#/c/566096/ | |
| 19:29:18 | owalsh | mriedem: snap | |
| 19:32:27 | owalsh | mriedem: worse on pike, it cache None | |
| 19:32:42 | mriedem | yeah it was a backport regression | |
| 19:33:58 | melwitt | oh, so _that's_ where the None RP comes from. geesh | |
| 19:34:22 | melwitt | I remember we reverted a thing while we were trying to get backports done for the stable releases | |
| 19:34:48 | mriedem | yeah that was ocata | |
| 19:35:00 | mriedem | i suspect the fleetify devstack stuff in pike+ was hiding it for us | |
| 19:35:01 | mriedem | somehow | |
| 19:35:28 | mriedem | although even in ocata devstack i thought we started the compute last | |
| 19:44:00 | mriedem | dansmith: what do you think a safe batch size is for this heal allocations CLI? at first i default to CONF.api.max_limit but that's 1000 which seems way too big https://review.openstack.org/#/c/565886/5/nova/cmd/manage.py@1776 - map_instances defaults to 50 | |
| 19:44:05 | mriedem | so was thinking about using 50 | |
| 19:44:21 | dansmith | yeah 1000 is too much | |
| 19:44:24 | dansmith | 50 is probably good | |
| 19:44:25 | mriedem | online_data_migrations also does 50 | |
| 19:44:32 | dansmith | yup | |
| 19:44:54 | melwitt | did we do an audit of other uses of safe_connect where None can be returned? | |
| 19:45:11 | mriedem | melwitt: jaypipes has been working on untangling that | |
| 19:45:18 | melwitt | k, cool | |
| 19:59:36 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix wrong arguments for 'detach_volume' https://review.openstack.org/566152 | |
| 20:06:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886 | |
| 20:11:38 | mriedem | owalsh: if you want to do the backport to queens and pike for https://review.openstack.org/#/c/566096/ that would speed things along so i can +2 the backports | |
| 20:11:52 | mriedem | owalsh: beware: the provider tree stuff in rocky will likely mean merge conflicts for the backports | |
| 20:16:59 | arvindn05 | dansmith: looks like there was agreement on the rebuild instance with traits thread. Can you send out an update on ML on the final approach? | |
| 20:17:03 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153 | |
| 20:17:43 | dansmith | arvindn05: I started it a bit ago but got distracted.. if there is agreement you're not blocked right? | |
| 20:23:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create volume attachment during boot from volume in compute https://review.openstack.org/541420 | |
| 20:24:17 | arvindn05 | dansmith: i am blocked at this point because my approved patch https://review.openstack.org/#/c/560596/ is also holding based on the decision on the rebuild issue | |
| 20:25:15 | arvindn05 | my next patches would be update the spec with decision on rebuild and propose the code patch for the same | |
| 20:25:24 | dansmith | arvindn05: you mean you're blocked because your patches don't do what mriedem wants yeah? | |
| 20:25:48 | dansmith | arvindn05: if you'd do what we said in the meeting this morning, then he'd remove his -W and everything would move along, AFAICT | |
| 20:26:53 | arvindn05 | dansmith: yup. but i was unfortunately not in the meeting and not entirely sure what approach was decided | |
| 20:27:12 | dansmith | if only there was a log... | |
| 20:27:34 | arvindn05 | dansmith: is it fair to summarize it as we want to go check the allocations route | |
| 20:27:50 | arvindn05 | (8:25:17 AM) efried: arvindn05: That was the impression I got. But yeah, let's see what dansmith has to say. | |
| 20:27:59 | dansmith | arvindn05: yes | |
| 20:28:39 | arvindn05 | dansmith: great. Thanks for confirming....i will start with the spec and the code patch. glad the deadlock was resolved :) | |
| 20:28:44 | efried | ++ | |
| 20:30:02 | mriedem | arvindn05: fyi http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-05-03-14.00.log.html#l-161 | |
| 20:31:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix being able to hard reboot a pausing instance https://review.openstack.org/566143 | |
| 20:31:57 | owalsh | mriedem: sure | |
| 20:32:20 | mriedem | thanks, hopefully it's not too bad, the patch is pretty isolated | |
| 20:32:40 | arvindn05 | mriedem: thanks got that from gibi as well :) last statement was <dansmith> I shall commentificate upon the threadage and reviewage so wanted to confirm :) | |
| 20:34:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup placement policy generator docs https://review.openstack.org/565225 | |
| 20:41:26 | arvindn05 | dansmith: one other clarification, we want to validate the allocations vs traits always correct? Even when we are rebuilding with the same image and no traits have changed | |
| 20:48:55 | melwitt | I would think so -- while the image hasn't changed, the underlying resource provider traits could have | |
| 20:50:12 | mriedem | arvindn05: that gets tricky depending on where you do the validation, | |
| 20:50:31 | mriedem | if the image doesn't change, i'm not sure if you get to the point in conductor where we'd be calling the scheduler | |
| 20:50:47 | mriedem | i realze you're not calling the scheduler to do the validation, but i assumed it would be in the same block | |
| 20:51:03 | arvindn05 | mriedem: i am thinking it would be in the conductor | |
| 20:51:32 | arvindn05 | conductor already has the placement client and all its dependencies need to make the validation | |