| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-20 | |||
| 11:46:00 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188 | |
| 12:14:02 | gibi | Kevin_Zheng: I shortly checked your test, functionally it looks OK. Do you feel that adding the request_id everywhere in the test is too much? | |
| 12:16:07 | sean-k-mooney[m] | bauzas: o/ i believe you reviewed this last cycle would you mind taking a look at the re-proposal of the nic feature based scheduling spec when you have time. https://review.openstack.org/#/c/545951/ | |
| 12:16:08 | Kevin_Zheng | gibi, sort of, but I'm not be afraid to add them, just don't know whether we have a better way to do that, in the latest patchset, I did some nodification for test test_create_server_error, but somehow the req id is different, I will dig into it latter | |
| 12:17:03 | Kevin_Zheng | gibi for those tests that tested multiple actions in one test, it seems a little bit complicated, so I wonder we have a better way to do it. | |
| 12:17:29 | sean-k-mooney[m] | bauzas: i have 1 or two nits to adress in the corresponding code but should have the series rebased and uploaded by the end of the week. im hoping we can get this all merged before milestone 1 | |
| 12:19:27 | openstackgerrit | sahid proposed openstack/nova master: only increment disk address unit for scsi devices https://review.openstack.org/538310 | |
| 12:22:08 | sean-k-mooney[m] | dansmith: just saw your comment on https://review.openstack.org/#/c/449257/59 you last comment on this topic was before i took this over from rodolfo. ill try and adress this when i do the rebase later this week. | |
| 12:22:12 | openstackgerrit | Jan Zerebecki proposed openstack/os-vif stable/ocata: Check if interface belongs to a Linux Bridge before removing https://review.openstack.org/554523 | |
| 12:23:01 | sean-k-mooney[m] | dansmith: looking at your old comment you would like us to add a spec_object field in addtion to the spec field correct? | |
| 12:23:36 | gibi | Kevin_Zheng: thanks for describing your concerns, I have to think about a bit. I will reply in the review | |
| 12:23:58 | Kevin_Zheng | gibi thanks alot | |
| 12:24:10 | openstackgerrit | Jan Zerebecki proposed openstack/os-vif stable/ocata: Check if interface belongs to a Linux Bridge before removing https://review.openstack.org/554523 | |
| 12:28:34 | efried | kaisers1: Howdy | |
| 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. | |