Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-10
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)
18:54:57 jroll and code according to that plan
18:55:00 superdan jroll: yeah
18:55:13 superdan jroll: I just haven't had time to look at this stuff until now and so I'm asking questions based on that
18:55:35 jroll superdan: right, I haven't had enough time either, tbh
18:56:24 jroll I kinda have it in my head, need to write it down and have people tell me where I'm wrong
18:56:33 jroll but I need to get ocata out the door first >.>
18:56:36 superdan I can do the latter part
18:56:45 jroll I'm sure you can
18:57:14 mriedem so maybe we do wed morning all resource providers/placement stuff at the ptg?
18:57:20 mriedem 10-noon is nova/cinder on thursday
18:57:28 mriedem jroll: or would you rather do wed afternoon?
18:57:33 mriedem maybe you don't care
18:57:44 jroll mriedem: yeah I think afternoon would be better
18:57:47 mriedem ok
18:57:54 mriedem let you guys get your ironic-specific stuff started on wed morning
18:57:59 jroll yeah
18:58:11 jroll I know at least a couple people wanted to float over for placement stuff
18:59:15 leakypipes superdan: what you're talking about there (fix the stuff in the virt driver's get_available_resource()) call is EXACTLY what I had originally proposed and that approach was shot down as too invasive of the virt layer :)
18:59:19 mriedem scottda: so for whatever reason, at 3am last night, i was thinking maybe we should just change the default catalog_info for nova/cinder to be v3 in pike
18:59:22 leakypipes superdan: lemme get a link ... one sec.
18:59:34 superdan leakypipes: well, this is too invasive to the RT layer, IMHO :D
18:59:37 mriedem scottda: anyone with older config would be using cinder v2, new nova installs would be cinder v3 by default
18:59:58 mriedem scottda: that would make us test nova + cinder v3 by default in the gate in pike
19:00:09 leakypipes superdan: see here for an original proposed solution to this: https://review.openstack.org/#/c/334038/
19:00:22 superdan leakypipes: we might also haveanother method for just RP stuff, and just stop calling the old one at some point
19:00:25 leakypipes back in the good ole days of Mitaka :)
19:00:28 superdan to avoid mixing the two
19:00:39 leakypipes superdan: ya, totes agreed.
19:00:53 superdan leakypipes: where is the giant nak from zeus on that patch?
19:00:59 leakypipes superdan: I think we have to live with some more cruft int he RT for a time (until Queens at earliest).
19:01:09 mriedem ha yeah it's all +1s in there
19:02:07 jroll the get_inventory() method landed but not the implementations for the drivers, wat
19:02:12 superdan leakypipes: cruft being the reporting of both things? or what/
19:02:40 mriedem leakypipes: no that was also abandoned https://review.openstack.org/#/c/334035/
19:02:49 mriedem i don't know why it takes you to git.o.o
19:02:54 jroll mriedem: oh, weird
19:02:56 jroll thanks

Earlier   Later