| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 18:59:42 | sean-k-mooney | mriedem: ya i was going to check the release notes for libvirt 1.2.17 | |
| 18:59:55 | openstack | bugzilla.redhat.com bug 1203032 in libvirt "Enhancing block/disk migration in libvirt" [Low,Closed: nextrelease] - Assigned to pboldin | |
| 18:59:55 | mriedem | the commit message referenced https://bugzilla.redhat.com/show_bug.cgi?id=1203032 | |
| 18:59:56 | _pewp_ | [ 1203032 – Enhancing block/disk migration in libvirt ] - bugzilla.redhat.com | |
| 19:00:22 | eandersson | sean-k-mooney, I see | |
| 19:00:42 | eandersson | I think this changed somehow during the upgrade which is why it's weird | |
| 19:00:48 | eandersson | I mean we went from.. Mitaka to Rocky :D | |
| 19:01:21 | eandersson | from my perspective it looks like base images are taken into account now, and weren't before. | |
| 19:01:30 | sean-k-mooney | eandersson: do you set allocation raitios in host aggreates? | |
| 19:01:42 | eandersson | nothing overcommited on these flavors | |
| 19:01:54 | eandersson | I tried adding disk_all = 1 but did nothing | |
| 19:04:05 | _pewp_ | [ OpenStack Docs: Configuration Options ] - docs.openstack.org | |
| 19:04:05 | sean-k-mooney | by disk_all do you mean https://docs.openstack.org/nova/rocky/configuration/config.html#DEFAULT.disk_allocation_ratio | |
| 19:04:18 | eandersson | sorry yea disk_allocation_ratio | |
| 19:04:38 | eandersson | we don't have it set in the aggregate for non-overprovisioned aggergates | |
| 19:05:33 | sean-k-mooney | eandersson: in ocata? i think we broke setting allocation ratios via host aggregates when we started using placment for cpu ram and disk | |
| 19:06:06 | sean-k-mooney | there is a mail from melwitt about butthis is proably not the issue. | |
| 19:06:39 | sean-k-mooney | http://lists.openstack.org/pipermail/openstack-dev/2018-January/126283.html | |
| 19:07:06 | sean-k-mooney | eandersson: in upgading form mitaka to rocky you went form that working to not | |
| 19:07:22 | eandersson | So I would expect that to break for instances that are over-commited | |
| 19:07:29 | eandersson | not for instances that are not overcommited right? | |
| 19:07:53 | sean-k-mooney | but also you nolonger need the AggregateCoreFilter,AggregateRamFilter,AggregateDiskFilter or the core/ram/disk filters | |
| 19:08:05 | eandersson | I think that would fix it for us | |
| 19:08:47 | eandersson | because placement does that now? | |
| 19:09:03 | sean-k-mooney | eandersson: yes this is handeled by placement now | |
| 19:09:21 | sean-k-mooney | or rather form ocata on | |
| 19:09:31 | _pewp_ | [ Gerrit Code Review ] - review.openstack.org | |
| 19:09:31 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Revert resize: wait for external events in compute manager https://review.openstack.org/644881 | |
| 19:09:50 | artom | _pewp_, what are you? | |
| 19:09:53 | sean-k-mooney | so you can safely disable the disk filter that is preventing the vm form working | |
| 19:10:14 | sean-k-mooney | artom: i think a bot of some kind | |
| 19:10:26 | artom | sean-k-mooney, heh, I got that part :) | |
| 19:10:31 | eandersson | Yea - I enabled debug | |
| 19:10:42 | eandersson | I gotta go, but will be back later. More meeting | |
| 19:13:24 | sean-k-mooney | artom: i think its https://github.com/hemna/sopel-tableflip | |
| 19:20:39 | melwitt | lbragstad, mriedem: well, the parts I thought were relevant to operators/users (and thus forum) are 1) are operators on board with the idea of fixing non-admin policy handling via scope types as a carrot to get operators to adopt different token scopes in their use of nova and 2) if the unified limit migration details in the spec sound OK to operators. 2) is maybe not something operators care too much about | |
| 19:23:13 | _pewp_ | [ Gerrit Code Review ] - review.openstack.org | |
| 19:23:13 | efried | dansmith: Sorry if I'm being a dolt here, but where does the request filter get required=COMPUTE_IMAGE_TYPE_FOO from originally? Is it image_meta? Is it translated from the image type somehow? This is the part I'm still missing in https://review.openstack.org/#/c/644625/ | |
| 19:23:59 | efried | You've mentioned how the compute driver adds COMPUTE_IMAGE_TYPE_FOO into its capabilities | |
| 19:24:12 | dansmith | efried: I haven't worked it all out all the plumbing yet, but we know what image they asked for and we can know what format it's in | |
| 19:25:07 | efried | Okay. So like if there's an image.type field and we can do "COMPUTE_IMAGE_TYPE_SUPPORT_%s" % image.type kind of thing? | |
| 19:25:14 | dansmith | right | |
| 19:25:24 | dansmith | it's called format I think, but yeah | |
| 19:25:38 | efried | image.type.upper().replace("things that aren't legal", "_") | |
| 19:25:52 | efried | os_traits.normalize something | |
| 19:25:56 | efried | okay, cool. Thanks. | |
| 19:26:02 | dansmith | efried: | disk_format | qcow2 | | |
| 19:26:49 | sean-k-mooney | am so dumb question before i read your sepc. could we just tag the compute nodes with traits for the image typs they support and then read the image type form glance and add the trait to the placment request | |
| 19:26:58 | dansmith | efried: https://docs.openstack.org/glance/rocky/user/formats.html | |
| 19:26:59 | _pewp_ | [ OpenStack Docs: Disk and Container Formats ] - docs.openstack.org | |
| 19:27:06 | dansmith | efried: pretty constrained list there | |
| 19:27:15 | sean-k-mooney | im thinking of suppoted image types like compute capablites | |
| 19:27:18 | efried | dansmith: cool. Standard traits to be proposed I assume. | |
| 19:27:25 | efried | sean-k-mooney: That's what he's doing, yes. | |
| 19:27:33 | dansmith | efried: yep | |
| 19:27:41 | sean-k-mooney | efried: ok makes sense | |
| 19:28:09 | dansmith | efried: first item in work item list is "add to os-traits" | |
| 19:28:13 | efried | os_traits.normalize_name is only for custom traits. prolly going to want a map. | |
| 19:28:35 | efried | ++ | |
| 19:28:56 | sean-k-mooney | efried: i was going to say we have some code in nova to normalise traits already but maybe we never merged that.. | |
| 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 | |