Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
16:40:58 mriedem we want any kind of 'claim' happening before we hit a compute, which is where port binding happens
16:41:03 sean-k-mooney mriedem: ya. that was one of the open questions should nova claim the bandwith or tell neutron to do it as part of port bining which we want to move to condutor
16:41:17 efried mriedem: Sure: we're polling the SSP to get available capacity for inventory reporting. If that changes (disk is added, disk goes offline, cluster node tanks, whatever), we want to modify the SSP's inventory accordingly. In this example, whichever virt gets there first, wins.
16:41:17 mriedem port binding was never moving to conductor
16:41:20 mriedem port creation was moving to conductor
16:41:30 sean-k-mooney mriedem: it was as part of the multi port binding spec
16:41:37 jaypipes sean-k-mooney: port binding != resource allocation. I'd rather have the conductor do the resource allocation steps than the nova-compute during port-binding
16:42:21 mriedem jaypipes: agree, otherwise we have a late claim on the wrong host and we fail
16:42:27 sean-k-mooney jaypipes: today yes port-binding happens on compute but intent is for it to move to conductor before we call the compute node
16:42:34 jaypipes mriedem: and we're back to square one again.
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.

Earlier   Later