Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
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 mriedem cdent: jaypipes: edleafe: agree? ^
17:02:03 efried or even...
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 dansmith mriedem: well, maybe, but I thought we had to do something
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: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: Read Neutron port 'binding_profile' during boot https://review.openstack.org/507481
17:41:57 openstackgerrit sean mooney proposed openstack/nova master: Format NIC features using os-traits definitions https://review.openstack.org/466051
17:42:05 mriedem default_availability_zone and default_schedule_zone
17:42:38 jroll efried: as far as the one vs many trees for ironic... _update_available_resource is called once per ironic node, not once per nova-compute host. (and thus the same for get_inventory and such). in old-nova terms, it's called once per compute_node record, of which many may exist per compute service. does that make sense?
17:42:46 mordred mriedem: at root is that currently nodepool gets a list of azs and the balances across them by default - which has led to unexpected behavior before (citycloud had an az specifically for a type of flavor and were confused why were launching nodes there)
17:42:56 jroll efried: I'll do a full review of the spec and drop some comments there, if that works better for you
17:43:32 mordred mriedem: but on clouds with more than one az where they're all the same, if we DON'T balance across them we wind up with usage only in the default zone

Earlier   Later