| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 19:29:14 | efried | sean-k-mooney: Yeah, we merged it and then moved it to os.traits, but it's only for custom | |
| 19:29:53 | sean-k-mooney | i was thinking of the traits nomalisation code for the feature based nic schduling that we never finished. | |
| 19:29:56 | efried | It's probably okay to hardcode a map for this. Adding a new supported image type, that doesn't happen frequently, does it? | |
| 19:30:14 | dansmith | efried: correct | |
| 19:30:22 | sean-k-mooney | efried: not really no | |
| 19:30:35 | efried | if a new image type is added, does it require changes in nova anyway? | |
| 19:30:38 | sean-k-mooney | it happens about as often as adding a new hypervior | |
| 19:31:01 | sean-k-mooney | am not nessisarly | |
| 19:31:04 | efried | cause if not, we may want to consider making that translation generic rather than hardcoded | |
| 19:31:09 | _pewp_ | [ OpenStack Etherpad ] - etherpad.openstack.org | |
| 19:31:09 | mriedem | https://etherpad.openstack.org/p/nova-ptg-train | |
| 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 | mriedem | i suspect there would be MigrateData object RPC changes and such to communicate between the dest and source compute | |
| 21:40:34 | efried | mriedem: yes. or create a new blank patch. | |