| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-12 | |||
| 15:20:16 | dansmith | lyarwood: right now we just categorically refuse to rescue a BFV instance, and I think we should change that since BFV instances are likely pets, and likely in need of rescue | |
| 15:20:30 | dansmith | so, with your proposed changes, in addition to the ordering, also including cinder volumes, | |
| 15:20:47 | dansmith | I'm wondering what we could do to follow up your changes with a change to allow rescue of BFV instances | |
| 15:21:34 | smcginnis | I've seen cattle with BFV too. Some just prefer to keep their storage on Cinder volumes. FWIW. | |
| 15:22:00 | dansmith | smcginnis: sure I know | |
| 15:22:22 | dansmith | smcginnis: I said "likely" not "always" :) | |
| 15:23:36 | lyarwood | dansmith: Ah! The changes would actually allow BFV and non-BFV but I can see that isn't made clear in the spec. I totally missed this when copying it over from an older change this morning but I'll clean this up and make it clear now. | |
| 15:24:02 | dansmith | lyarwood: sweet | |
| 15:24:13 | dansmith | lyarwood: do you have old crusty code of up for this at all? | |
| 15:24:58 | lyarwood | dansmith: there's an old abandoned series but iirc that was missing the compute service check that I think I had somewhere locally | |
| 15:25:11 | dansmith | lyarwood: ack | |
| 15:25:43 | lyarwood | dansmith: https://review.opendev.org/#/q/status:abandoned+topic:bp/virt-rescue-stable-disk-devices | |
| 15:25:43 | dansmith | lyarwood: so you think that after these changes, if the api let them, we could rescue BFV instances no problem? | |
| 15:26:05 | lyarwood | dansmith: yes | |
| 15:26:12 | dansmith | if so, we'll need a compute capability to indicate this support, and could use that in place of the version check | |
| 15:26:57 | lyarwood | yup true, I also didn't cover microversions in the spec that I think came up in that series | |
| 15:29:24 | dansmith | lyarwood: no REST API changes, so why a microversion? | |
| 15:31:56 | lyarwood | dansmith: https://review.opendev.org/#/c/270288/18/nova/compute/api.py@2777 - mriedem raised it here as something we might have to do, I'm also not sure if that's still the case tbh. | |
| 15:32:22 | dansmith | lyarwood: oh, you even remove that in the code, I see, | |
| 15:32:46 | dansmith | well, in that case it probably does need a microversion and a rest api impact section, but in the spec I just reviewed you said "none" :) | |
| 15:34:02 | lyarwood | yeah apologies this slipped my mind when I was pushing it up for review earlier. I'll mark the spec as WIP for now while I get things back in order. | |
| 15:34:52 | dansmith | lyarwood: you said you were going to work on this this cycle right? | |
| 15:35:52 | lyarwood | dansmith: yup I should actually have time this cycle | |
| 15:36:10 | dansmith | lyarwood: cool, I | |
| 15:36:23 | dansmith | I would suggest getting this going sooner than later if you can schedule it | |
| 15:36:39 | dansmith | at least rebase the code and get it restored so that others can comment/help | |
| 15:37:01 | dansmith | even if before the spec, although I think the spec is easy to merge pretty soon if you fix up the issues | |
| 15:37:33 | lyarwood | dansmith: sure, I should be able to get something rebased pretty quickly. | |
| 15:37:36 | lyarwood | famous last words | |
| 15:41:03 | efried | jroll: randomly generated passphrase: do you think there should be a conf option for the length? If so/not, what should the default/number be? | |
| 15:49:24 | jroll | efried: probably not worth a config until/unless someone asks. 32 or 64 characters seems reasonable | |
| 15:50:19 | efried | Roger that. (Glad I asked, I was gonna go 256 :P ) | |
| 15:50:37 | jroll | 256 is also reasonable :D | |
| 15:50:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Wire up a force disconnect_volume flag https://review.opendev.org/584849 | |
| 15:51:18 | jroll | efried: I guess if nobody ever touches this, maybe 256 is a better option | |
| 15:51:47 | efried | it certainly won't be readable/typable. Like an ssh key. How big are those? | |
| 15:52:45 | jroll | $ wc ~/.ssh/id_rsa | |
| 15:52:47 | jroll | 54 61 3326 /Users/jrollenhagen/.ssh/id_rsa | |
| 15:53:43 | efried | yours is bigger than mine | |
| 15:53:53 | dansmith | mriedem: wha-chu-think main? https://review.opendev.org/#/c/636224/50/nova/compute/api.py | |
| 15:53:59 | jroll | heh | |
| 15:54:01 | dansmith | efried: whoa, wrong channel | |
| 15:54:44 | efried | that's number of chars, b64-encoded, plus header/footer | |
| 15:55:42 | jroll | right, looks like 3072 bytes | |
| 15:55:51 | mriedem | dansmith: you can't compare None values can you? | |
| 15:56:41 | dansmith | mriedem: you can | |
| 15:57:13 | dansmith | mriedem: >>> (None, 1) < (None, 2) | |
| 15:57:13 | dansmith | True | |
| 15:57:26 | mriedem | >>> datetime.datetime.today() < None | |
| 15:57:26 | mriedem | Traceback (most recent call last): | |
| 15:57:26 | mriedem | File "<stdin>", line 1, in <module> | |
| 15:57:26 | mriedem | TypeError: can't compare datetime.datetime to NoneType | |
| 15:57:37 | mriedem | i guess because of the tuples | |
| 15:57:42 | bauzas | AFAIR, you were even able to say something like None = 2 | |
| 15:57:43 | dansmith | oh you mean compare datetime to none | |
| 15:57:48 | bauzas | in py2 something | |
| 15:57:49 | mriedem | that's what these are | |
| 15:58:42 | mriedem | >>> now1 = datetime.datetime.now() | |
| 15:58:43 | mriedem | >>> now2 = datetime.datetime.now() | |
| 15:58:43 | mriedem | >>> now1 < now2 | |
| 15:58:43 | mriedem | True | |
| 15:58:43 | mriedem | >>> now1 < None | |
| 15:58:43 | mriedem | Traceback (most recent call last): | |
| 15:58:43 | mriedem | File "<stdin>", line 1, in <module> | |
| 15:58:44 | mriedem | TypeError: can't compare datetime.datetime to NoneType | |
| 15:58:55 | dansmith | yeah, ack | |
| 15:58:56 | efried | jroll: afaict those would map to original random passphrases of ~1200-2400 chars | |
| 15:59:06 | Roamer` | mriedem, you'd get the same result if you tried to compare it to "whee" or to 17 | |
| 15:59:31 | dansmith | mriedem: we have to find something better than what you have | |
| 15:59:49 | Roamer` | ah, but you're commenting on the patch in the review request, sorry, yeah | |
| 16:00:20 | mriedem | dansmith: i looked for some builtin sorting/filtering type function but didn't find anything obvious | |
| 16:01:12 | dansmith | okay I got it | |
| 16:01:51 | mriedem | sorted with a key function? | |
| 16:02:44 | mdbooth | lyarwood: https://review.opendev.org/#/c/584850/ | |
| 16:02:47 | kashyap | Is this a common convention? "os-migrateLive" | |
| 16:02:54 | dansmith | mriedem: https://pastebin.com/pHtM7iEf | |
| 16:03:09 | kashyap | (I'll ask there) | |
| 16:03:15 | mdbooth | lyarwood: I know that's abandoned, but any idea where that came from? The concept of having un-flushed data after LM switchover is disturbing. | |
| 16:03:20 | Roamer` | mriedem, dansmith, maybe something like (yeah, I know, quite unwieldy) `dtnull = datetime.datetime.utcfromtimestamp(0)` and then `(u1 or dtnull, a1 or dtnull) < (u1 or dtnull, a2 or dtnull)` | |
| 16:03:45 | dansmith | Roamer`: yep, or that | |
| 16:03:47 | Roamer` | (with the correct variable names, of course, pfheh) | |
| 16:05:00 | dansmith | mine makes anything with an updated_at win and short circuit before comparing the updated_ats which means you won't ever compare non-nones | |
| 16:05:09 | dansmith | er, Non-None to None | |
| 16:06:11 | lyarwood | mdbooth: os-brick had a number of bugs around multiple devices getting grouped under the same mpath device blocking the final flush/removal on disconnect | |
| 16:06:21 | Roamer` | dansmith, TBH, I hadn't seen yours before writing mine :) it took me a while to test it and copy it here, yours might be better and less unwieldy :) | |
| 16:06:33 | lyarwood | mdbooth: QEMU's own flush was enough to ensure everything made it to the backend before we forced anything in that case | |
| 16:07:11 | mdbooth | lyarwood: That flush was happening on the source node, after switchover? | |
| 16:07:26 | lyarwood | mdbooth: the QEMU flush? | |
| 16:07:40 | lyarwood | mdbooth: no that's before we converge iirc | |
| 16:07:44 | lyarwood | or maybe during | |
| 16:07:47 | mdbooth | lyarwood: os-brick's flush on disconnect | |
| 16:08:11 | mdbooth | So the bug was that os-brick thought it had data to flush, but it didn't really? | |
| 16:08:31 | lyarwood | mdbooth: that's after but it's just something you have to do before disconnecting mpath devices iirc, there's no data actually cached anywhere at that point | |
| 16:08:56 | mdbooth | Right. It would just be really bad if there really was data to flush at that point. | |
| 16:09:48 | lyarwood | yup | |
| 16:10:01 | dansmith | jroll: didn't you add some ironic grouping construct so that one ironic can serve independent pools of nodes to dedicated nova computes? | |
| 16:10:28 | dansmith | ah, conductor groups | |
| 16:15:11 | belmoreira | dansmith jroll how that would work? | |
| 16:15:23 | dansmith | belmoreira: did you read the spec I just sent you? :) | |
| 16:15:49 | belmoreira | :) maybe... which one? :) | |