Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-12
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 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Wire up a force disconnect_volume flag https://review.opendev.org/584849
15:50:37 jroll 256 is also reasonable :D
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 True
15:57:13 dansmith mriedem: >>> (None, 1) < (None, 2)
15:57:26 mriedem TypeError: can't compare datetime.datetime to NoneType
15:57:26 mriedem File "<stdin>", line 1, in <module>
15:57:26 mriedem Traceback (most recent call last):
15:57:26 mriedem >>> datetime.datetime.today() < None
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 File "<stdin>", line 1, in <module>
15:58:43 mriedem Traceback (most recent call last):
15:58:43 mriedem >>> now1 < None
15:58:43 mriedem True
15:58:43 mriedem >>> now1 < now2
15:58:43 mriedem >>> now2 = datetime.datetime.now()
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? :)
16:15:58 dansmith belmoreira: https://docs.openstack.org/ironic/latest/admin/conductor-groups.html
16:16:09 dansmith oops,
16:16:16 dansmith belmoreira: https://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/ironic-conductor-groups.html
16:16:52 belmoreira this is train
16:17:07 dansmith what is?
16:17:48 belmoreira sorry. This is available in Stein
16:17:52 dansmith right
16:21:18 belmoreira I forgot about it. sorry. This is great however means that we will need to scale nova-compute in the same way as the ironic-conductor
16:21:56 dansmith belmoreira: well, you probably should be doing that anyway given you're hitting nova-compute scale issues when you make ironic big :)
16:22:51 dansmith I understand the desire to make the RT loop in nova-compute more efficient, and I'm sure we can without breaking things, but it's a change to complex crufty code that only (positively) impacts the one oddball driver that uses multiple nodes,
16:23:28 dansmith so I'm less enthusiastic about that, especially when grouping nova-computes gets you a lot more gain too,
16:23:29 dansmith like better fault tolerance, mapping your existing failure domains through to ironic, etc
16:24:04 belmoreira dansmith I understand that. That's why the initial plan was the sharding. And I wasn't aware (forgot) about the conductor groups
16:24:12 belmoreira this can make it
16:24:33 dansmith cool

Earlier   Later