Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-13
18:39:49 owalsh lyarwood: correct, just restart services
18:40:11 lyarwood owalsh: cool thanks
18:40:24 dansmith death match round 2, dublin
18:53:36 mriedem fork in the kidneys, check
19:55:15 openstackgerrit Merged openstack/nova master: Replace Chinese quotes to English quotes https://review.openstack.org/543349
19:56:31 dansmith efried: jaypipes: seen the question on this? https://review.openstack.org/#/c/540111/3
19:56:45 dansmith I was about to reply, but then realized I was misunderstanding his concern and I think it's probably valid
19:57:06 dansmith hoping that there's some detail of how you see that working that wouldn't actually break it
19:57:46 efried dansmith: It's been on my list to look at, but was rapidly getting buried. Thanks for bringing it back to the top. Looking....
19:58:58 mriedem been wondering the same type of thing with traits,
19:59:12 mriedem the ironic driver will blow away any traits that aren't on the ironic node
19:59:16 mriedem rather than try to merge the
19:59:18 mriedem *them
19:59:27 dansmith well, there needs to be some amount of that I think,
19:59:36 dansmith although we can't blow them all away in this case I think
19:59:49 dansmith was hoping there was some "only blows away at the given level" detail or something
20:00:09 efried mriedem: I remember that being discussed at length (for ironic traits), and the conclusion in that case was that the ironic inspector was the Source Of Truth, so it was kosher to blow away anything that crept in from elsewhere.
20:00:26 mriedem idk, it seems quite limiting
20:00:41 dansmith efried: it is for sure until the compute service starts needing to do some too, like for capabilities
20:00:52 mriedem if we have an external system to model resources that other services outside of nova can interact with, it seems wrong to completely trample them
20:00:53 dansmith in that case compute might be able to do its own merging,
20:01:05 dansmith but for this inventory thing, nic bandwidth is probably a good example
20:01:06 mriedem dansmith: yeah that's what i had to do in my poc patch for the capabilities thing
20:01:10 dansmith yeah
20:01:29 efried So I agree that we don't want to make it a rule that virt blows away children it doesn't recognize.
20:01:32 dansmith so maybe for this we could get the inventory from the vif modeling somehow?
20:01:44 mriedem trying to balance the stance we've had in the past against things like metrics providers in-tree saying that's all best served outside of nova,
20:01:54 efried But the design (and imple) is flexible enough that we don't need to make that rule at this level.
20:02:00 efried s/impl/implementation/
20:02:03 mriedem and now we appear to have something that's outside of nova for external services, but we're saying we'll overwrite what they do
20:02:05 efried vay
20:02:25 efried (Sorry, that was /me frustrated at own inability to spell, twice)
20:02:37 efried Okay, I get the concern.
20:02:50 dansmith efried: so you're saying I can have a child of compute node and the update_tree() won't blow those away, just inveentory for the level I'm updating, yeah?
20:02:58 openstackgerrit Merged openstack/nova master: Invalid query parameter could lead to HTTP 500 https://review.openstack.org/539164
20:03:32 efried dansmith: We'll make placement look *exactly* like whatever comes out the other side of update_provider_tree.
20:03:41 efried But I still think that's okay.
20:04:03 dansmith efried: not if that means we blow away stuff we didn't return.. so now I'm confused
20:04:10 efried Because 1) virt gets to be the (primary) source of truth for the provider tree rooted at the compute node.
20:04:33 efried And 2) virt kinda needs to know whether there's some other entity "out there" that's allowed to mess with some level of its tree.
20:04:49 dansmith well, that's what I'm saying,
20:04:51 efried If it knows that, then it can preserve those pieces of the tree unchanged.
20:04:53 dansmith if we go that route,
20:05:07 efried Because it receives them as part of the tree it gets on input.
20:05:15 dansmith then we need to have the virt drvier capable of collecting external things we support, like bandwidth on a nic
20:05:20 efried nononono
20:05:22 dansmith oh,
20:05:31 efried It doesn't need to be able to collect them, cause we already gave it to... yeah.
20:05:32 dansmith you're saying ProviderTree already has the child things,
20:05:37 efried yes, exactly.
20:05:43 dansmith that's the confusion though:
20:05:45 efried It has the whole picture as Placement knows about it right now.
20:05:58 efried ...at least the picture that's rooted at the compute host RP.
20:06:20 dansmith does ProviderTree.update(<not including things that were in the child>) blow those away? or are you saying the virt driver needs to look and include those things in its update?
20:07:24 efried ProviderTree.update_[thingy](rp_uuid) for thingy in (inventory, traits, aggregates) will replace thingy for just the RP indicated by rp_uuid.
20:07:50 efried E.g. if you replace inventory via that method, but not traits, then traits stay whatever they were before.
20:08:02 efried Also, those update_* methods don't muck with children.
20:08:06 dansmith yeah but that's not the question
20:08:12 dansmith okay, _that_ is the quesation
20:08:19 dansmith whether update() touches the children
20:08:22 dansmith um
20:08:26 dansmith "affects the children"
20:08:28 efried To muck with hierarchy, you have to ProviderTree.remove(), .new_root(), .new_child()...
20:08:33 efried There is no update().
20:08:39 dansmith I know, I'm saving letters
20:08:45 dansmith I think that's his question
20:08:54 dansmith so I had assumed it would only affect the level you're on, and was replying,
20:09:04 dansmith but then re-read the bit of your text he's taking exception to and wasn't sure
20:09:10 dansmith so I think you just need to tighten that up a smidge
20:09:42 efried Okay. That's a true statement ("...only affects the level you're on"). *except* that if you .remove(rp), you also remove all of rp's descendants. That's what the sentence is saying.
20:09:48 dansmith sure
20:09:50 dansmith and,
20:10:15 dansmith I was going to say that if the compute node thinks it needs to remove its provider, then it _should_ affect the external thing that still thinks it is reporting resources for that provider
20:10:23 dansmith i.e. compute is authoritative for the existence of itself
20:10:29 efried right.
20:11:07 efried It'll be a possibly-not-enforced-but-highly-recommended rule that these entities that share control of a tree never share control of a single RP within that tree.
20:11:22 efried that way lies madness.
20:11:29 dansmith not sure how you would enforce tat, but agree, that should be the assumption
20:11:33 dansmith *that
20:11:35 mriedem stephenfin: still around?
20:12:19 efried Okay, I'll post an edit. Thanks for the discussion dansmith, mriedem
20:21:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup the manage-volumes admin doc https://review.openstack.org/544066
20:25:13 jaypipes efried, dansmith, mriedem: just finished reading back... yes, agree that the spec could use some clarity/language around the update_provider_tree() method implementations not calling ProviderTree.remove() for nodes in the tree that it doesn't manage.
20:25:24 dansmith aye
20:25:30 efried Roger wilco.
20:26:19 jaypipes efried: I still don't understand this from tetsuro though: "Note that at least libvirt driver today removes CUSTOM_RCs which users set manually via placement API for a compute host when the periodic updating task happens."
20:26:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup the manage-volumes admin doc https://review.openstack.org/544066
20:26:58 efried jaypipes: I think he's saying libvirt removes *inventory* in custom RCs it didn't create itself.
20:27:13 efried I don't think we're talking about removing the actual resource classes from placement.
20:27:26 jaypipes efried: is he just saying that if an operator manually calls POST /resource_providers/{cn_uuid}/inventories and adds a CUSTOM_XXX resource class, that it will be removed by the libvirt virt driver's get_inventory() method?
20:27:33 efried I think so, yes.
20:27:44 jaypipes efried: gotcha. ok. and yes, that is definitely by design...
20:27:47 efried yup.
20:28:23 mriedem that is eventually due to this check? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L831
20:28:31 jaypipes efried: since clearly the virt driver owns the resources on the compute node. but it's worth saying that update_provider_tree() implementations will *not* remove a *node* from the tree of providers if it doesn't know about the node.
20:28:37 jaypipes mriedem: yea
20:28:57 jaypipes mriedem: oh, no...
20:29:26 efried That's just an optimization that'll short-circuit if nothing has changed.
20:29:29 jaypipes mriedem: that check is seeing if what we got from get_inventory() is the same as what is cached in the reportclient's provider tree.
20:29:36 jaypipes what efried said.

Earlier   Later