Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
16:42:44 mriedem sean-k-mooney: i don't remember ever talking about moving port binding to conductor
16:42:50 sean-k-mooney let me see if i can get the relevent part of the spec
16:42:59 mriedem in the long ago, johnthetubaguy was working on moving port *creation* to conductor
16:43:07 efried To cdent's point, would y'all be on board with imposing a restriction in the code that MISC_SHARES_VIA_AGGREGATE and tree-ness are mutually exclusive?
16:43:15 jaypipes mriedem: and that is resource allocation, not port binding...
16:43:34 johnthetubaguy s/nodes/nods/
16:43:38 efried Freudian slip ^ :)
16:43:45 johnthetubaguy :)
16:43:47 jaypipes efried: I don't really see the need, frankly...
16:43:50 cdent efried: I think it's probably okay to not enforce it. just don't got parent or child hunting in u_p_t
16:44:00 mriedem jaypipes: port creation is resource allocation? in what way?
16:44:03 mriedem besides quota
16:44:08 efried jaypipes: It's not a *need* per se; would just allow us to kick this can down the road.
16:44:14 jaypipes efried: just don't ever search deeper than a single node level for any sharing providers
16:44:21 johnthetubaguy it was nice for case where you pick the correct IP segment for routed networks
16:44:40 johnthetubaguy where placement deals with the IP resources, that may be limited in the case of public ones
16:44:41 jaypipes mriedem: what johnthetubaguy said.
16:45:04 jaypipes mriedem: but it's not important right now.
16:45:28 jaypipes mriedem: I would be fine just mandating that sharing provider information gathering never exceeds the single level of the sharing provider.
16:45:34 sean-k-mooney mriedem: jaypipes https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/queens/approved/neutron-new-port-binding-api.rst#n139
16:45:36 efried jaypipes: Okay, but do we include the sharing provider's whole tree or not?
16:45:44 mriedem efried: i'd say no
16:46:01 cdent no
16:46:02 efried I'm worried about the future impact of spoofing a child as a root
16:46:05 mriedem efried: i personally don't think the virt driver should be managing all of this stuff
16:46:18 jaypipes sean-k-mooney: oh, that's for live migration... yeah.
16:46:24 cdent efried: just because you don't include the info, doesn't mean it isn't out there
16:46:37 mriedem i mean, we've talked about not wanting nova to orchestrate everything in the cloud, and this is a giant step (it seems to me at least) in that direction of orchestratoin
16:46:44 jaypipes cdent: the truth is out there, Scully.
16:46:54 cdent it's all lies jaypipes
16:46:54 sean-k-mooney jaypipes: ya but the intent was to do the port binding always in the conductor form that point on. both binding and creation actully
16:46:55 efried cdent: Well, that's kind of the issue, because right now, we have no way in ProviderTree of creating a root with a parent_uuid
16:47:06 mriedem sean-k-mooney: https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/queens/approved/neutron-new-port-binding-api.rst#n139 is not port creation
16:47:11 jaypipes efried: no, we should not. the "whole tree" is clearly more than "the single level of the node".
16:47:27 sean-k-mooney mriedem: right it happens after port creation
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?

Earlier   Later