Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
16:47:52 mriedem sean-k-mooney: that spec has no reliance on johnthetubaguy's work to move port creation to the super-conductor
16:47:56 mriedem as far as i remember anyway
16:48:07 mriedem it's for live migration, where we already have the port created on a live vm
16:48:15 cdent efried: all we want to do is represent a provider, in tree. you're saying that if a provider has a parent we can't _not_ include the parent in the provider tree?
16:48:22 mriedem john's thing was for picking the correct host for routed networks
16:48:36 efried cdent: No, I'm saying if we do include it, we have to lie about its parentage.
16:48:48 cdent no we don't. we just don't have it
16:48:51 sean-k-mooney mriedem: that spec was written with live migration but for bandwitdh based sceduling we needed to move port/creation to the conductor too so we can read the bandwith request form the neutron port before hitting placement
16:49:03 efried I suppose that's one way of looking at it.
16:49:07 mriedem sean-k-mooney: sure, the bw based scheduling spec is a whole other clusterfuck
16:49:15 mriedem sean-k-mooney: the live migration one for port binding is pretty clear
16:49:19 cdent The ProviderTree is a representation of what we care about, now. It is not the whole truth?
16:49:46 sean-k-mooney mriedem: maybe we did not explictly say it in either i guess i was jsut under the impressions we had discussed makeing that change for all code paths
16:49:46 cdent I would hope that it is just whatever is useful.
16:50:07 mriedem sean-k-mooney: the bw based scheduling spec has at least like 3 major dependencies
16:50:20 mriedem and at this rate will get done in maybe the next openstack A release
16:50:20 efried cdent: But please let's not make the argument that we shouldn't include the non-owned descendants of the compute host.
16:51:08 mriedem sean-k-mooney: the dep tree within just nova is already in LP https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider
16:51:14 efried cdent: We have literally no way of knowing which ones those would be.
16:51:18 mriedem that doesn't include changes needed in neutron
16:51:39 sean-k-mooney mriedem: well we could strip it donw a little but ya i know its currently state it need many things like nova neutron negociation via os-vif object which is very nice but strictly required
16:51:56 mriedem you mean but *not* strictly required?
16:52:03 sean-k-mooney sorry yes
16:52:30 cdent efried: my feeling is that the core meaning of "ProviderTree" is "this compute node and its children". That it includes auxilliary things like shared providers is bonus.
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

Earlier   Later