Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
16:57:48 mriedem efried: if we say that the provider tree just going to see the sharing provider and not if it's a root or none of its children (if it can even have children, but i don't see why it couldn't), then it's probably important
16:58:30 efried I didn't quiite parse that, but I think I get what you're saying.
16:58:40 cdent bbl
17:01:03 efried Will future ironic model each ironic node as a separate tree in its own right? Or will they always be children/subtrees of the compute host?
17:01:05 mriedem https://awwapp.com/b/u8ghqr9rr/
17:01:12 mriedem efried: can you see ^?
17:01:34 efried mriedem: yes
17:01:47 mriedem efried: in that diagram i'm asserting that the provider tree that the virt driver sees is in blue
17:01:50 efried mriedem: And yes, that's the idea.
17:01:51 efried Yup.
17:02:03 efried or even...
17:02:03 mriedem cdent: jaypipes: edleafe: agree? ^
17:02:34 sean-k-mooney efried: i would assume future ironic might model each chassie as a resouce provierd of inventoies of custome_baremetal_node object but i done no about a RP per bermtal node
17:03:11 mriedem efried: there is no resource provider for the compute host, just the nodes
17:03:12 dansmith mriedem: oh, I bet this is because we don't have grenade mappings for queens yet,
17:03:13 mriedem so they'd be separate
17:03:20 dansmith mriedem: so we're actually upgrading from pike to rocky here
17:03:35 efried mriedem: Okay. We don't have a way to handle that yet FYI.
17:03:37 dansmith sdague: can you remind me what I need to do for that?
17:03:55 mriedem dansmith: i see a stable/queens branch for grenade now,
17:04:06 mriedem so maybe it was just done after that CI run and your recheck will be happy
17:04:07 dansmith mriedem: yeah, but logs show we have pike computes in there
17:04:16 sean-k-mooney efried: each ironic node bing its own provider tree?
17:04:20 efried mriedem: But once we do, it'll be a true statement that the ProviderTree can have multiple full actual trees.
17:04:20 dansmith mriedem: well, maybe, but I thought we had to do something
17:04:26 efried sean-k-mooney: Yeah
17:04:40 sean-k-mooney efried: that should just be a simple virt driver change no?
17:04:44 efried no
17:04:51 dansmith mriedem: zuul backlog is 1249 items long, so it hasn't even started running yet :/
17:05:12 efried sean-k-mooney: rt will have no way to map the ironic node back to the compute host for purposes of scheduling.
17:05:42 sean-k-mooney efried: you could use an aggregate for that
17:05:43 efried s/rt/conductor/ I guess
17:05:56 efried sean-k-mooney: Could. But like I say, we don't have that yet.
17:06:10 efried And that would be an interesting case for aggregated provider trees that aren't sharing providers.
17:07:04 efried TBH, I don't know how ironic plans to model in u_p_t. mgoddard around?
17:07:24 jroll efried: we haven't made any, that I know of
17:07:40 sean-k-mooney efried: ironic may also want to use either nested resouce providers or aggregates to model node to chassis relationships for blade systems too
17:08:06 jroll s/at all/on this topic/
17:08:46 jroll jaypipes may also have some thoughts on it, though
17:10:34 sean-k-mooney efried: i genally thing of aggregate just as arbitry groupings of RPs and shareing RPs as a special subset of that. in genneral i think aggregates are usfull for far mor thing that are not sharing related the sharing related uscases
17:11:10 efried sean-k-mooney: I agree that there are plenty of non-sharing use cases for aggregates.
17:11:30 efried sean-k-mooney: But as currently conceived (per recent refinement) we don't pull in non-sharing aggregated providers at all.
17:11:36 mordred mriedem: is it possible to query nova as an end-user to find out what the default AZ is?
17:12:08 jroll efried: so, in an ideal world, we just... don't care about mapping an ironic node to a compute host for scheduling purposes. because, any compute host can talk to ironic to do the build
17:12:54 mriedem mordred: as in https://developer.openstack.org/api-ref/compute/#get-availability-zone-information doesn't tell you which is the default in config?
17:13:27 efried jroll: Coolcool. But n-cond still needs to schedule a deploy to *some* n-cpu somewhere.
17:14:07 efried jroll: So if the ironic nodes are independent providers (independent of their compute host) how does it know where?
17:14:24 jroll efried: agree, and I'm not sure we want to special case it. but if we did: host = random(get_ironic_compute_hosts())
17:14:34 mriedem mordred: doesn't look like it http://paste.openstack.org/show/677614/
17:15:06 jroll efried: I realize now I don't know how that works with placement. in the old world, both the host and node are in the compute_nodes record
17:15:07 mriedem mordred: well, i guess if there is only 1 'available' zone then you know what the default is :)
17:15:10 efried jroll: Oh, so all ironic nodes under an n-cond can be managed by any n-cpu under that same n-cond?
17:15:37 jroll efried: in theory, yes, we don't do that in reality today
17:16:15 jroll efried: but we do currently shuffle them between ironic n-cpu hosts that are up, as the hosts go up and down
17:18:52 efried jroll: But don't ops also always deploy specific ironic nodes?
17:19:23 jroll efried: as in "nova boot this-specific-machine"?
17:19:29 efried Yeah; maybe I'm misremembering that.
17:19:34 jroll nope, not at all
17:19:36 efried k
17:19:41 jroll some do - and they use things like scheduler hints
17:20:01 efried Rightright, that's what I was thinking - that it's a requirement to be able to do so.
17:20:03 jroll other installations are just another cloud, with the hypervisors missing
17:20:32 jroll efried: the "requirement" part of that depends who you ask :)
17:20:40 jroll I'm not sure it works upstream today
17:20:45 efried So yeah, I have absolutely no idea how we're planning to model ironic in Placement-land. But I suspect there will have to be some additional affordance outside of what we're doing in u_p_t.
17:21:27 efried Because right now, if you tried to model each ironic node as its own root/tree, it wouldn't work.
17:21:47 efried (by "right now" I mean "with NRP and u_p_t implemented as specced")
17:22:42 jroll yeah, I'm not up to speed on the nested things
17:23:20 jroll I suspect jay has ideas here, dunno
17:27:30 openstackgerrit Eric Fried proposed openstack/nova-specs master: Update Provider Tree https://review.openstack.org/540111
17:27:36 efried mriedem: See how that grabs ya ^
17:27:47 efried jaypipes, edleafe, cdent ^
17:32:50 edleafe efried: stop grabbing me!
17:32:59 efried mriedem: Updated that diagram a little bit too https://awwapp.com/b/u8ghqr9rr/
17:33:09 efried edleafe: Dangit, there goes my career 40 years from now.
17:34:11 mriedem efried: then i think you definitely need a diagram in the spec to give an example
17:34:14 jroll efried: I see nodename everywhere in this spec, that signals to me that one tree per ironic node is expected
17:34:20 mriedem of what's in vs what's out when the driver gets the provider tree object
17:34:55 efried jroll: That's probably just a lack of precision on my part more than anything.
17:35:14 efried jroll: I still don't understand the difference between nodename, hypervisor_hostname, and host.name.
17:35:54 efried jroll: But I wrote the code first, and 'nodename' was the var that made sense to pass around in there, so that's probably how it ended up in the spec.
17:36:02 jroll efried: nodename ~= hypervisor_hostname, I'm not sure what host.name refers to
17:36:46 efried nodename == hypervisor_hostname, except for ironic where they're never equal; but hypervisor_hostname == host.name always ??? Or something ???
17:37:28 jroll in the ironic world, nodename == hypervisor_hostname, for sure. compute_node.host is the different one (and the one that actually looks like a hostname)
17:37:37 efried jroll: When you say ~= is that "regular expression match" à la Perl, or "not equal" à la other things?
17:37:47 efried oh, okay.
17:38:19 efried So that makes zero sense to me, that ironic node name should be the same as the hypervisor host's name. So the latter is actually a total misnomer.
17:38:22 jroll efried: equal, but I'm not 100% sure on weird drivers, so I'm going with approximately equal :)
17:38:28 efried gotcha
17:39:24 jroll sure, it's a poorly named thing. originally it was for things like xen, where compute.host (how you reach n-cpu) might be separate from the actual hypervisor (how you reach xenapi)
17:39:40 jroll s/hypervisor/hypervisor_hostname/
17:40:31 mordred mriedem: :) ... and yah - the lack of info about default in config in the az list is, I think, the thing
17:41:04 mordred mriedem: came up in some discussions around nodepool and azs - thanks for confirming
17:41:21 mriedem mordred: from what i remember, there are actually >1 nova config options related to a 'default' az
17:41:49 mordred mriedem: awesome. and of course there are :)
17:41:55 openstackgerrit sean mooney proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257
17:41:56 openstackgerrit sean mooney proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777
17:41:57 openstackgerrit sean mooney proposed openstack/nova master: Format NIC features using os-traits definitions https://review.openstack.org/466051
17:41:57 openstackgerrit sean mooney proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/507481
17:42:05 mriedem default_availability_zone and default_schedule_zone

Earlier   Later