Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-20
19:31:16 mriedem "New virt driver for rsd:"
19:31:19 sean-k-mooney we just pull the image form glance and give it to the hyperviro to use
19:31:21 dansmith efried: likely would.. libvirt can read a lot of stuff, but most of what is covered there
19:31:24 mriedem come to butthead https://github.com/openstack/rsd-virt-for-nova
19:31:31 dansmith efried: and if it wasn't just a "use this and load it" then it'd break us without nova support
19:31:53 efried anyway, I didn't want to get into all the impl details; I just wanted to understand where that bit was coming from.
19:32:03 dansmith efried: like, if it wasn't just a raw file we're copying around, libvirt would need tooling to deal with those files, even if it can read them
19:32:19 efried okay.
19:32:33 sean-k-mooney dansmith: we have a few other cases that are very similar
19:33:22 sean-k-mooney for example im thinkg of suport vif_models or gpu_models(not gpu/vgpu passthough but gpu emulation)
19:33:30 efried mriedem: I saw that, noticed they didn't have a whole lot of code in their virt driver
19:34:30 sean-k-mooney i was going to write a spec to enable virt-gpu support by extendign the enum we alredy have but do you think its woth doing somethign similar and reporting supprot vif_models or gpu_models as traits?
19:35:35 mriedem efried: i'm assuming you'll get all sorts of awesome internal pressure for that rsd driver now
19:36:16 sean-k-mooney mriedem: i have reviewd the code. its more limited then it used to be/could be
19:36:58 sean-k-mooney it currently relyi on create a 1:1 mapping between compute node and flavor
19:38:17 sean-k-mooney it previously used to to create 1 hypervior per compute node like the ironic on did so nova could act as a scudler. so while im happy to see the direver it has good way to go befoer it would be ready to move intree or be used in production
19:39:25 sean-k-mooney efried: have you looked at the rsd virt dirver at all
19:39:45 efried I glanced at what was there in github and it appeared to be empty. Beyond that, no.
19:40:20 efried Oh, I've been confusing RSD and RDT in my head. (can't imagine why)
19:40:30 efried so yeah, I've never heard of RSD, internally or otherwise.
19:40:48 sean-k-mooney efried: its ok you will :P
19:41:09 sean-k-mooney efried: https://github.com/openstack/rsd-virt-for-nova
19:41:52 efried ohh, there it is.
19:42:38 sean-k-mooney efried: ya it used to be a lot more powerful but things changed.
19:43:40 sean-k-mooney that said it still allows you to boot node with out ironic useig rsd via nova so thats kind of cool
19:46:17 sean-k-mooney but its currently missusing flavor in a way that will not scale. if you have 1000 RSD nodes it will create 1000 flavors...
19:49:12 cdent sounds like something I could use at home
19:53:00 sean-k-mooney cdent: the original plan was to create one hypervior per rsd node and 1 flavor per uniqute type of rsd node discovers whcih requried on allcoate of CUSTOM_RSD_NODE_TYPE_WHATEVER
19:53:36 sean-k-mooney so if you only had two types of rsd system you would get only 2 flavor and to customer resouce classes
19:53:45 sean-k-mooney pretty much how ironic works
19:55:49 sean-k-mooney cdent: i think helena had some issue wiht modelign things properly in plamcent so this was a temproy fix but i havent talkd to her about it since last ptg so who know why it chaged
19:56:13 cdent the world moves in mysterious ways
20:39:15 openstackgerrit melanie witt proposed openstack/nova master: Move creation of rpcapi.ComputeAPI object from __init__ https://review.openstack.org/644998
20:39:16 _pewp_ [ Gerrit Code Review ] - review.openstack.org
20:51:25 melwitt lbragstad: I re-read the channel log and I think we should just combine sessions
20:52:15 lbragstad melwitt both rbac and unified limits?
20:52:41 melwitt lbragstad: I think so. I'm going to wager we'll have enough time for both
20:53:04 lbragstad ok
20:53:09 mriedem dansmith: alright i've gone through your spec https://review.openstack.org/#/c/644625/
20:53:10 _pewp_ [ Gerrit Code Review ] - review.openstack.org
20:53:37 mriedem mostly nits, but wondering what you had in mind for the capabilities-as-traits hook for this
20:53:43 lbragstad i suppose we'll need to get some etherpads rolling then - that way we get the things nova wants to go through written down and generalized if possible
20:54:25 melwitt lbragstad: yeah, I can create etherpads with the things I was thinking, and then we can work on it. or, you can create them and I'll add. whatever you want
20:54:33 lbragstad melwitt would you want to follow up the ML thread?
20:54:49 melwitt lbragstad: sure, I'll reply
20:54:54 lbragstad thanks
21:30:07 mriedem welp, this doesn't look good http://logs.openstack.org/63/642863/1/gate/nova-tox-functional/6573680/job-output.txt.gz#_2019-03-20_15_58_21_993250
21:30:10 mriedem cdent: efried: ^
21:30:56 mriedem this is the test that uses the PlacementFixture as a context manager
21:31:07 cdent ah, that might explain why we don't register log opts
21:31:13 cdent in register_opts
21:31:32 mriedem what i can't explain is why this would just start failing all of a sudden
21:31:49 dansmith mriedem: okay, since the list of disk formats is such a restricted and static list, it doesn't seem unreasonable to just use capabilities for this, but I don't care that much
21:31:51 cdent that merged only in the last few ours
21:32:00 efried mriedem: It's because we landed https://review.openstack.org/#/c/644591/ in placement
21:32:01 _pewp_ [ Gerrit Code Review ] - review.openstack.org
21:32:02 cdent well, some times today (the register opts change)
21:32:24 efried hemna_: Not loving _pewp_ - what value is it supposed to add?
21:32:45 hemna_ arg
21:32:47 cdent mriedem: there's the revert https://review.openstack.org/#/c/645014/
21:32:48 _pewp_ [ Gerrit Code Review ] - review.openstack.org
21:32:56 cdent but I think there's likely a better fix
21:32:59 hemna_ I'll remove the github portion, I thought I already had
21:33:01 cdent (on the nova side)
21:33:54 mriedem opening a bug
21:34:31 mriedem https://bugs.launchpad.net/nova/+bug/1821092
21:34:32 openstack Launchpad bug 1821092 in OpenStack Compute (nova) "test_local_delete_removes_allocations_after_compute_restart failing since https://review.openstack.org/#/c/644591/" [Critical,Confirmed]
21:35:19 mriedem dansmith: so you were thinking like a capability boolean for each known disk_format?
21:36:05 dansmith mriedem: yeah, I mean, I know that there would be more of those than existing capabilities, but... I don't think the cost is any higher, and we just have to invent a new place to keep that list
21:36:30 klindgren sean-k-mooney, mriedem , dansmith, I assume based upon earlier discussions that you guys would be ok with a patch on live-migration to regenerate vs's copy an iso9660 config drive under the correct conditions?
21:36:51 efried cdent: You're just making a blank nova patch that depends-on the revert?
21:37:07 dansmith klindgren: meaning regenerate if we know there aren't files we'd be missing? not sure we can know that currently
21:37:35 mriedem i think we can assume there wouldn't be any personality files if inject_partition is -2
21:37:37 mriedem i.e. disabled
21:38:00 dansmith mriedem: they could be in the config drive just not injected into the root image right?
21:38:04 cdent efried: no, I was hoping someone else would make the thing that matt has seen fail depend-on the revert patch. I'm looking into fixing the nova side so we don't have to have the revert on the placement side. It's happening because of a misuse of conf, which would be good to remove
21:38:13 klindgren I mean - I *know* that on my clouds it's not there, because of the layers that are built onto of it, don't use it.
21:38:15 mriedem dansmith: oh maybe, i'd have to dig into that code
21:38:40 dansmith mriedem: pretty sure they end up in config drive if provided, and then also in the root disk if you inject, but I could be wrong
21:38:51 klindgren So I was thinking maybe a config option for scp/rsync to add regenerate?
21:38:53 efried cdent: ack.
21:38:56 dansmith mriedem: but deciding whether or not to regen based on the config of the (current) source it's coming from seems too loose a restriction
21:39:28 efried mriedem: you want me to update https://review.openstack.org/#/c/642863/ ?
21:39:44 mriedem efried: to depend on the fix for this blocker bug?
21:39:55 mriedem dansmith: i don't disagree, it would require thought,
21:40:13 mriedem so i think the answer to klindgren's question is it's going to require thought, not just a simple single change
21:40:18 klindgren I just want to avoid a patch that we can never get merged upstream
21:40:34 efried mriedem: yes. or create a new blank patch.
21:40:34 mriedem i suspect there would be MigrateData object RPC changes and such to communicate between the dest and source compute
21:40:56 dansmith mriedem: agree it's non trivial
21:41:27 mriedem klindgren: are you or your coworker buddies going to be at the ptg?
21:41:34 efried oo, cdent do tell
21:41:52 klindgren mriedem, yes we will have 2 people there
21:41:53 mriedem cdent: did someone put potato skins down the drain again?
21:41:55 klindgren I won't be there
21:42:03 cdent mriedem: twice
21:42:03 klindgren afaik
21:42:08 mriedem klindgren: at least throw something on here https://etherpad.openstack.org/p/nova-ptg-train
21:42:23 cdent efried: I'm relatively certain the same config is being used twice and it should be. need to confirm
21:42:28 mriedem and if you start coming up with design ideas and have thought through the corner cases and such, it'd be good to dump those thoughts in the ML

Earlier   Later