Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
16:53:15 mriedem dansmith: are the CI failures in https://review.openstack.org/#/c/543580/ all unrelated?
16:53:16 sean-k-mooney the os-vif object depency was there to not have yet another unversioned dictionary of stings going back and fort, it could be done without that chage however
16:53:25 mriedem dansmith: all the grenade jobs failed there?
16:53:28 efried cdent: Acknowledging that the virt driver at least needs to be able to *see* (if not control) the sharing providers, but isn't allowed to talk to placement, I'm still asserting it's a requirement, not a bonus.
16:54:13 mriedem i think seeing that they are there is OK
16:54:27 mriedem like, if i have a compute node tree and see that it's getting it's disk_gb from a shared provider, that's good
16:54:34 mriedem that's something the RT doesn't know about today, and is a problem
16:54:35 cdent efried: it's a requirement for the interface which u_p_t wants to provide to be able to do that. That it is being done within the confines of the ProviderTree object is a matter of convenience (and a reasonably good choice).
16:54:54 efried ptaytah ptahtah, cool.
16:55:34 efried mriedem: For those other two comments, do you want me to call out hypervisor_hostname and ironic explicitly?
16:55:44 cdent efried: you can understand why "something that is not in this tree" feel like it doesn't fit in the definition of ProviderTree (strictly from a naming standpoint)?
16:55:46 mriedem efried: no, just verifying my understanding
16:55:50 efried mriedem: And for the sharing tree issue, do you still want some ascii art?
16:55:58 dansmith mriedem: I had only looked at the first one and it's been a while so figured a recheck, let me look at the others
16:56:09 efried cdent: Yeah. But I ain't proposing a patch to rename it to ProviderCopse
16:56:23 mriedem dansmith: http://logs.openstack.org/80/543580/1/check/neutron-grenade/f675ec2/logs/screen-n-api.txt.gz?level=TRACE#_Feb_12_22_21_47_795180
16:56:24 mriedem that's real
16:56:43 cdent ooooh. nice name! Then we can have free roaming agents doing copicing.
16:57:03 dansmith ah yup
16:57:05 mriedem efried: well the prose is confusing
16:57:13 efried mriedem: I'm gonna reprose it.
16:57:32 efried Guess I'll do that and see if you think it's enough.
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 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

Earlier   Later