| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 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 | mriedem | https://etherpad.openstack.org/p/nova-ptg-train | |
| 19:31:09 | _pewp_ | [ OpenStack Etherpad ] - etherpad.openstack.org | |
| 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? | |