Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-20
09:13:52 Kevin_Zheng fanzhang yw
09:33:44 jianghuaw_ bauzas, good morning:-)
09:34:00 bauzas just catching up emails this morning
09:34:02 jianghuaw_ hope you enjoyed the time in the magic kingdom
09:34:25 bauzas well, my daughters did at least :)
09:34:59 jianghuaw_ good enough:-)
09:53:06 openstackgerrit Chris Dent proposed openstack/nova master: Provide framework for setting placement error codes https://review.openstack.org/546177
10:02:46 gibi morning nova
10:29:20 openstackgerrit Silvan Kaiser proposed openstack/nova master: Exec systemd-run with privileges in Quobyte driver https://review.openstack.org/554195
10:41:00 openstackgerrit Pranab proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
10:41:50 gibi melwitt: I left a comment and a question in https://etherpad.openstack.org/p/nova-runways-rocky with '[gibi]' prefix. But overall I'm OK with the proposal.
10:42:30 gibi melwitt: I think we have to start doing it to gather real experience and then we can improve the process iteratively
11:03:12 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090
11:05:50 Kevin_Zheng gibi, Hi, I might need some suggestion on https://review.openstack.org/#/c/553288/ about tests
11:37:08 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090
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

Earlier   Later