| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 18:24:25 | superdan | leakypipes: does that not seem like a major layering violation? maybe that has already been discussed? | |
| 18:25:31 | leakypipes | superdan: sorry, I'm not quite following you. do you mean that that code is in the wrong place? | |
| 18:27:02 | superdan | leakypipes: the resource tracker having things like "if ironic, do this other thing" | |
| 18:27:17 | superdan | we try not to even do that in compute manager, which directly consumes the compute drivers | |
| 18:27:34 | superdan | and we nak people having tried to do stuff like that in the past | |
| 18:28:26 | leakypipes | superdan: yeah, it's a temporary thing until we can be sure that the request from the user just contains a list of resources to consume as opposed to the existing situation where we need to tell if the instance is a baremetal instance or not and then do something different to track Ironic resources. | |
| 18:28:48 | leakypipes | superdan: the dilemma we have is a chicken and egg one. | |
| 18:29:23 | superdan | I'm not sure what that means, request wise, but I assume that means temporary ... for a while? | |
| 18:30:11 | mriedem | i had made a comment at one point about subclasses the resource tracker for ironic specific resource class massaging | |
| 18:30:21 | mriedem | since there were big conditionals in that patch at one point which were all just for ironic | |
| 18:30:23 | leakypipes | superdan: an OpenStack admin may have set the node.resource_class attribute for some or all of their Ironic baremetal nodes, but a) there may be records in Nova already existing that refer to the consumed resources like VCPU, MEMORY_MB and DISK_GB. We need to continue to track those "resources" like we do now but also track the new node.resource_class consumption. All of that code is basically the "auto-heal" code for Ironic installations in | |
| 18:30:24 | leakypipes | Newton and Ocatra | |
| 18:31:26 | mriedem | fwiw ironic + resource providers is broken in newton anyway i think | |
| 18:31:40 | leakypipes | superdan: yes, that code and those conditionals will not be necessary once the "flavor" for Ironic nodes no longer requests VCPU, MEMORY_MB and the like and instead just requests the custom resource class like "CUSTOM_IRON_SILVER" or whatnot. | |
| 18:31:51 | mriedem | w/o https://review.openstack.org/#/c/416762/ anyway | |
| 18:32:20 | leakypipes | mriedem: ah, yes, but that's a bit of a different thing, right? | |
| 18:32:27 | superdan | mriedem: yeah, I'd like that to be less hacky.. I'd have to think about the best way to do it though | |
| 18:32:28 | mriedem | yeah | |
| 18:32:38 | ygl | can we access the ovs controller of devstack ? | |
| 18:33:21 | ygl | is it a opendaylight controller ? | |
| 18:37:58 | superdan | jroll: is ironic making "set your node class" a requirement for people deploying ocata? | |
| 18:38:23 | superdan | meaning, is there a "you will break in pike if you haven't set this property" warning? | |
| 18:38:29 | jroll | superdan: not yet no | |
| 18:38:48 | jroll | we also support ironic without nova so we can never make it strictly mandatory | |
| 18:38:52 | superdan | jroll: so we have to tolerate not having this set until queens? | |
| 18:38:57 | jroll | or rather, doing that would be painful for people that don't care | |
| 18:39:23 | jroll | nah, we should be able to enforce it nova side in pike | |
| 18:39:32 | jroll | we can make it a pre-pike upgrade requirement | |
| 18:39:57 | superdan | jroll: okay presumably you have to note your pre-pike requirements in ocata, no? | |
| 18:40:06 | superdan | or are you just going to say in pike release notes you're broken if you don't? | |
| 18:40:19 | jroll | superdan: was planning on pike relnotes + upgrade docs | |
| 18:40:25 | superdan | okay | |
| 18:40:32 | superdan | so since we're in pike now, | |
| 18:40:33 | mriedem | in newton we said placement was going to be required in ocata, which was kind of true, but we didn't make it a hard break in the scheduler | |
| 18:40:51 | superdan | can nova not just dispense with this ironic-specific RT stuff leakypipes was talking about? | |
| 18:40:58 | jroll | I don't want to strictly enforce it at any time with log.warn() or whatever, because standalone | |
| 18:41:10 | superdan | sure, I get the standalone thing | |
| 18:41:12 | mriedem | jroll: i mean strictly enforce in nova | |
| 18:41:24 | mriedem | if you don't have node.resource_class set in nova, it's a an error | |
| 18:41:28 | superdan | mriedem: we strictly enforce placement in ocata, just not until you're fully upgraded | |
| 18:41:34 | jroll | mriedem: yes I would like to do that thing in pike | |
| 18:41:43 | jroll | superdan: so, we still need ironic-specific RT stuff, right | |
| 18:41:52 | jroll | because it auto-creates a custom resource class and such | |
| 18:41:57 | superdan | jroll: leakypipes said not once we can depend on that no/ | |
| 18:42:15 | jroll | oh there's scrollback involved | |
| 18:42:34 | superdan | I guess he's also saying something about existing legacy resources | |
| 18:42:49 | mriedem | if the nova RT isn't going to create the custom resource classes from the node.resource_class, what is? something/someone outside nova? | |
| 18:42:51 | mriedem | pre-pike? | |
| 18:43:05 | superdan | I guess it seems like we should be refactoring the interface between RT and the resources the driver returns, | |
| 18:43:17 | superdan | and make the ironic driver return the node class types if appropriate, | |
| 18:43:17 | jroll | yeah, so there's a couple parts | |
| 18:43:22 | superdan | and let the RT be generic | |
| 18:43:24 | mriedem | i was going to say, the get_available_resources() call to the driver could return the node.resource_class couldn't it? | |
| 18:43:30 | superdan | and it would then delete the legacy resources at that point, but we want that | |
| 18:43:31 | jroll | 1) something needs to put these resources in the placement engine correctly | |
| 18:43:38 | superdan | mriedem: right | |
| 18:43:42 | jroll | 2) flavors need to be able to request custom resource classes | |
| 18:44:02 | jroll | 3) I'm blanking, totally had something | |
| 18:44:30 | artom | 3) ??? | |
| 18:44:33 | artom | 4) Profit! | |
| 18:44:46 | jroll | superdan: I think leakypipes was saying we can drop it once flavors can be converted over | |
| 18:45:11 | jroll | people will need to be able to use the new and old flavors in pike | |
| 18:45:21 | jroll | so they can transition | |
| 18:45:33 | jroll | and then we can drop the cpu/memory/disk tracking in queens | |
| 18:45:34 | superdan | jroll: so "temporary" means queens at the soonest yes? | |
| 18:45:39 | jroll | I think I have that right | |
| 18:45:54 | jroll | yeah, for dropping the old stuff | |
| 18:45:54 | mriedem | leakypipes: i'll create you a bp for resource class work in pike | |
| 18:46:17 | jroll | superdan: I'm planning to like, write up a plan here before PTG sometime | |
| 18:46:27 | jroll | but our ocata release is a bit delayed so I've been dealing with that | |
| 18:46:35 | mriedem | leakypipes: oh i guess i already did https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-pike | |
| 18:47:04 | jroll | I want to spend a bunch more time here during pike and get this shit over with | |
| 18:47:11 | mriedem | jroll: i'll throw it on our etherpad | |
| 18:47:18 | jroll | mriedem: ptg? it's there :) | |
| 18:47:25 | jroll | just not fleshed out | |
| 18:47:27 | superdan | so, I still think we should be able to do this by refactoring the interface between the RT and the driver that returns resources, | |
| 18:47:39 | superdan | and make the ironic driver encapsulate this different-for-ironic behavior right? | |
| 18:47:41 | jroll | mriedem: line 88 | |
| 18:48:23 | jroll | mriedem: or what you wrote, I'll delete mine | |
| 18:48:25 | mriedem | jroll: ok jay had something too | |
| 18:48:36 | Guest54279 | Hi, anyone here has worked on pci_whitelist_entry inside nova.conf (pci passthrough) in nova ? | |
| 18:49:17 | jroll | superdan: I'm honestly not sure | |
| 18:49:44 | jroll | superdan: I guess we could say any virt driver that passes back a resource_class field back from get_available_resource gets that resource class created/written | |
| 18:49:52 | jroll | that seems sane to me | |
| 18:50:03 | jroll | idk what else is special case | |
| 18:50:10 | superdan | we kinda do that today, but in old format, | |
| 18:50:13 | jroll | write all the resources returned into the placement api | |
| 18:50:33 | superdan | I would think we should be converting the drivers to communicate in the new format anyway | |
| 18:50:47 | mriedem | Guest54279: you want moshele who isn't around right now | |
| 18:50:52 | superdan | and since we're pike now, we need to rip out the old reporting format anyway | |
| 18:51:44 | jroll | so | |
| 18:52:05 | jroll | in pike we need ironic nodes reporting both cpu/disk/ram AND a resource class | |
| 18:52:11 | jroll | in queens we want just a resource class | |
| 18:52:24 | jroll | I feel like just writing everything returned by the driver is the right thing to do | |
| 18:52:36 | jroll | and we'll just change what the driver returns each cycle | |
| 18:52:51 | superdan | jroll: right so the ironic driver would return that extra thing right now and then stop later | |
| 18:53:04 | jroll | not sure why we need all this stuff to remove allocations for cpus, etc | |
| 18:53:42 | jroll | I need to buy a whiteboard for my office already :| | |
| 18:53:54 | leakypipes | sorry guys, was on a call. | |
| 18:54:48 | jroll | superdan: I know we're hyper to get this code done, but I'd almost rather map this plan out on the ML (or at the PTG if we still don't have a plan by then) | |