Posted	Nick	Remark
#openstack-nova - 2018-03-20
12:28:52	efried	kaisers1: /me US Central time :)
12:29:02	openstackgerrit	sahid proposed openstack/nova master: libvirt: handle DiskNotFound during update_available_resource https://review.openstack.org/553067
12:37:41	openstackgerrit	Merged openstack/nova master: Fix message for unexpected external event https://review.openstack.org/554380
12:40:34	jaypipes	alex_xu_: still around? not sure what you were asking about preferred_traits... I have no issue with decorating traits in flavors as being preferred. I wouldn't send them to placement, though... just allow the scheduler weighers to use them in their sorting. is that what you were thinking of?
12:50:25	openstackgerrit	sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522
12:54:51	jaypipes	efried, cdent: so based on you guys' and tetsuro's feedback on the "nested providers allocation candidates" series, I'm wondering if there's *any* reason to use non-granular request groups when nested providers are present. I spent all day reworking that series yesterday to get things working so that a non-granular request group could work against a tree of providers (but not by summing inventories across the entire tree). Instead, what I did
12:54:51	jaypipes	was say that individual providers needed within the tree needed to satisfy each quantitative resource request and then *collectively* the tree needed to satisfy the traits request. do you think that's wrong as well?
12:55:00	jaypipes	lemme push what I have.. one se.c
12:55:26	efried	jaypipes: That sounds correct to me.
12:57:03	efried	Within the request, one resource_class:amount needs to be satisfied by one provider in the tree, or one associated via aggregate with any provider in the tree. And collectively, the RPs satisfying the resource request (which may in fact *exclude* some of the RPs in the tree) must satisfy the traits.
12:57:14	efried	Not sure if that last thing is what you did.
12:58:03	efried	jaypipes: But I think that's important. I don't think we want to say traits are satisfied by a provider that's not providing any resource to the request.
12:58:41	efried	...and we do need to make sure agg-associated RPs (but only ones providing resource) are included in the traits calculation.
12:58:51	jaypipes	efried: what about when a trait is applied to the NUMA node that is the parent of a provider satisfying some part of the resource request?
12:59:08	jaypipes	efried: forget the shared stuff for right now...
13:00:32	efried	jaypipes: Hmmm, the NUMA thing... I said something yesterday, I think in a spec comment, related to this. I'll dig it up, but I think taking that into account, the answer to the above will be "that will depend on different syntax".
13:02:42	efried	jaypipes: The gist was that (what I recall from PTG discussions, early Wednesday) we want to support the NUMA subtree business (and cdent this may also play into the vmware cluster thing) via a syntax that expresses: "Get all the resources in this group from a subtree whose (sub)root is marked with trait X"
13:03:19	efried	jaypipes: So if the NUMA node is marked with trait I_AM_A_NUMA_NODE, the syntax would be like GET /a_c?resources4=...&subtree_trait4=I_AM_A_NUMA_NODE
13:03:56	openstackgerrit	Jim Rollenhagen proposed openstack/nova master: ironic: stop lying to the RT when ironic is down https://review.openstack.org/545479
13:04:48	efried	That would affect the calculation of which providers in the tree are eligible to provide resources - i.e. just the subtree rooted at a provider marked I_AM_A_NUMA_NODE - and that trait gets special treatment such that the NUMA root RP itself doesn't actually need to provide resources.
13:04:52	openstackgerrit	Ed Leafe proposed openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357
13:05:40	openstackgerrit	Jay Pipes proposed openstack/nova master: tests for alloc candidates with nested and traits https://review.openstack.org/531899
13:05:41	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: resource requests for nested providers https://review.openstack.org/554529
13:06:03	jaypipes	efried, cdent: please see above (different series, forked from the base of the old one)
13:08:12	gibi	efried, jaypipes: I agree that a single resource request need to be satisfied from a single RP but in case of traits I think the trait needs to be satisfied by the RPs on the path from the root (or subroot) to the RPs that are providing resources to that request
13:08:16	sean-k-mooney[m]	efried: thanks for your review on https://review.openstack.org/#/c/449257/59 you spotted my **{} sed hack which is fair i was just hopping i would not need to manually convert them all. ill fix it in the next respin. i answered some of your other questions inline
13:10:12	gibi	efried, jaypipes: where the path can be defined also by taking the RPs that providing resources and collecting all the ancestors for those RPs and then checking that the traits are satisfied in the set of RPs or not
13:11:36	mdbooth	Could somebody take a look at this live migration bugfix for me: https://review.openstack.org/#/c/551302/ . It's got a bunch of +1s and I hacked a CI run to ensure coverage.
13:12:02	jaypipes	gibi, efried: ok, understood. which gets back to my original question... if nested providers are present, is there really any point in *not* requiring granular request groups?
13:13:56	gibi	jaypipes, efried: do I remember correctly that a granular numbered request group means that both the resources and the traits needs to be fulfilled from a single RP?
13:14:15	efried	gibi: I don't think I agree that we should collect traits from "tree paths". That seems excessively complicated. What use case does it satisfy? (Hint: I don't think it satisfies the NUMA thing without further semantic work)
13:14:22	efried	gibi: Correct.
13:15:07	efried	jaypipes: Trying to think through whether it's always possible to express an un-numbered request group as one or more numbered groups.
13:15:26	efried	I think there's some cases you can't express - but it's actually a good thing that you can't.
13:15:40	gibi	jaypipes, efried: I've started thinking about the same
13:15:56	efried	Like getting the a trait from a provider you weren't expecting.
13:16:07	gibi	jaypipes, efried: i.e. trait is on the compute RP, resource inventory is on the PF
13:16:32	gibi	that would need two separate numbered group
13:16:41	efried	gibi: Yeah. It *should* be the case that traits on the one aren't applicable to the other. But who knows?
13:17:59	openstackgerrit	sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605
13:18:20	jaypipes	efried, gibi: yeah, that's been my dilemma :)
13:18:39	gibi	jaypipes: you successfully shared your pain :)
13:18:50	efried	jaypipes: I'm not opposed to this idea in principle - it makes a couple of things simpler, which is good.
13:18:52	jaypipes	gibi: you're welcome. ;)
13:19:04	efried	jaypipes: My concern is how we express this to operators.
13:19:19	jaypipes	efried: agree with you. I'm hunting for ideas.
13:19:30	efried	jaypipes: They need to have, what, separate flavors for nested-modeled hosts than for non?
13:19:46	efried	I mean, even a non-nested host you can express requests with granular.
13:20:02	efried	So the line could just be: start using granular for everything, period.
13:20:23	jaypipes	efried: meh, I don't think that will be common. I'm more concerned about how to document the quirks of each "solving algorithm", depending on whether they use granular or not, nested or not, sharing providers or not, etc
13:20:29	efried	But that's kind of a dick punch to the traits-in-glance thing.
13:20:58	efried	jaypipes: Don't think what will be common? Environments where some are trees and some are not?
13:21:35	jaypipes	efried: no, I mean a need for flavors that request the same resources/traits but "in different ways" (i.e. collectively met vs individually met)
13:22:19	openstackgerrit	sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605
13:22:39	kaisers1	efried: Hey, ok :)
13:23:00	efried	kaisers1: What you have looks fine to me, but you'll want to take your lead from mikal since he's engaged at this point.
13:23:27	efried	kaisers1: I'm not sure if he wants you to put the non-systemd exec into the privsep lib, or something.
13:23:34	cdent	jaypipes, efried: I think we should make the simple cases as simple to express as possible and for some deployments that ought to mean that some hardware doesn't "turn on" numa, so it just reports simple inventory.
13:23:38	kaisers1	ok, i just wanted to ask regarding the kwargs topic, did you read my reply on that?
13:23:56	efried	kaisers1: Not yet, looking...
13:24:06	cdent	I'd like to think that it is possible to do some nested things without granular but I've not thought it all the way through
13:24:15	dansmith	sean-k-mooney[m]: yep, that's what needs to happen
13:24:18	cdent	s/it is/ought to be/
13:24:20	gibi	efried, jaypipes: granularity in the flavor needs to express what resource needs to be collocated and what can be spread inside the selected host. This should not depend on the fact that the host provide nested RP tree that allows the spreading
13:24:23	kaisers1	efried: ok. It's just that either i don'r fully grasp it or it doesn't make that much sense to me
13:24:29	kaisers1	*don't
13:25:17	efried	kaisers1: Oh, I totally didn't see that response.
13:25:26	efried	I'll answer in the patch. Sorry about that.
13:25:39	kaisers1	efried: np, thanks for looking into the patch
13:25:39	efried	gibi: I tend to agree.
13:25:48	gibi	efried, jaypipes: so If I don't care about to collocate cpu and ram to the same numa then I can create the cpu request in a different group than the memory request and that will work against nested and not nested hosts
13:26:05	openstackgerrit	Surya Seetharaman proposed openstack/nova master: Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188
13:26:25	gibi	efried, jaypipes: or does it?
13:26:31	jaypipes	gibi: in a non-nested representation, there's no reason to use granular request groups. because every request is a granular request group (it cannot be satisfied by >1 provider non-sharing provider)
13:26:32	efried	gibi: Yes. (Though that still doesn't help us collocate e.g. CPU and VF on the same NUMA, cause they'll be members of different providers.)
13:26:44	openstackgerrit	Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090
13:26:57	efried	gibi: Same numbered request group == same provider. Different numbered request groups == maybe same, maybe different providers
13:27:17	gibi	efried: your last point made my above statment false
13:27:30	efried	gibi: We definitely have no way (other than unique traits) to express that two requests MUST be from separate providers.
13:27:47	gibi	efried: sorry, mixed up
13:28:03	gibi	efried: let me try again
13:28:04	efried	gibi: Always same tree-or-associated-sharing, though, if it's in one request.
13:28:37	openstackgerrit	Surya Seetharaman proposed openstack/nova master: Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188
13:29:23	gibi	efried: so we can instruct the deployer to create flavors always with granular groups if he does not care about numa affinity as two separate group can be satisfied by the same RP
13:30:05	gibi	jaypipes: I guess we don't need granular in non-nested deployments, but in a mixed deployment, the granular groups works against both type of hosts, which is good
13:30:19	efried	gibi: Even if he cares about NUMA affinity (assuming we're just talking about NUMA_CORE+MEMORY_MB - stuff in the same RP). You would then specify both resources in the same numbered group, meaning they have to come from the same provider.
13:30:42	gibi	efried: true
13:30:58	efried	(still doesn't help the NUMA_CORE+PF case)
13:31:13	efried	(we still need new syntax for that)
13:31:41	efried	(and the new syntax has to be within granular)
13:32:11	gibi	efried: NUMA_CORE + PF case needs a group that is satisfied by a subtree specified by something that identifies the root of the subtree somehow
13:32:50	gibi	efried: your I_M_A_NUMA_NODE trait based subtree specification makes sense to me
13:32:52	openstackgerrit	Surya Seetharaman proposed openstack/nova master: [WIP] Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
13:33:56	cdent	jaypipes: if you're able to go back and respond to the various comments on the reviews, in context, that would be awesome. It's sometimes hard to keep the many thread clear.
13:34:31	gibi	efried: I can even forsee that I_AM_A_NETWORKING_RP_WHICH_DEFINES_A_SUBTREE_BELONGIG_TO_THE_SAME_NEUTRON_AGENT trait :)
13:34:36	jaypipes	cdent: sure, I will. was just looking to brainstorm.
13:35:03	cdent	Yeah, sure, not complaining, definitely want the brainstorming too
13:35:04	gibi	efried: i mean I foresee a possible need of such trait based selection
13:35:18	cdent	gibi: I think you missed _PLEASE on the end of that trait
13:36:49	jaypipes	in any case, unfortunately, I now have a dentist appointment I need to get to... and then drop the dogs off at the spa and sit while my car gets serviced (will have my lappie for the last part, though, so will be online later)

Earlier   Later