Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-20
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 efried gibi: I tend to agree.
13:25:39 kaisers1 efried: np, thanks for looking into the patch
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)
13:37:12 efried enjay :)
13:37:49 sean-k-mooney[m] jaypipes: doggy spa days. you really do spoil them :)
13:40:40 gibi cdent: I think there is a limit about the lenght of a trait :)
13:40:45 cdent :)
13:41:21 gibi jaypipes: good luck with your errands
13:42:40 sean-k-mooney[m] gibi i belive its set in the db scema probaly 64,128 or256 charaters
13:43:44 sean-k-mooney[m] gibi: its 255 https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/041_resource_provider_traits.py#L43
13:44:24 sean-k-mooney[m] also aprently we set the charset to latin1 so no unicode traits. is that intentional ?
13:44:32 gibi sean-k-mooney[m]: OK, then I can fit the PLEASE at the end :)
13:45:54 gibi sean-k-mooney[m]: I think that is intentional https://github.com/openstack/nova/blob/f80b4e50093002f84b43ff245a605fbe44d34711/nova/api/openstack/placement/handlers/trait.py#L74
13:47:00 alex_xu_ jaypipes: For example, I want to a FPGA device with Funciton A, the request is 'resources=RC_FPGA_DEV:1&preferred=FPGA_FUNCTION_A'. Do you mean you only request one RC_FPGA_DEV, then weigh the RPs base on the summary of RPs in the response of allocation_candidates?
13:47:02 efried kaisers1: Responded. Note that I'm not saying any of those things will necessarily ever happen in this case. It's just one of those things that's good practice.
13:47:40 sean-k-mooney[m] ah of url parsing so we dont get sql injections... we still might get requests form people with non latin based alphabets at some point but i guess we can cross that bridge when we come to it
13:48:11 efried sean-k-mooney[m]: The schema only allows A-Z and _
13:48:14 efried and 0-9
13:48:35 sean-k-mooney[m] efried: the api schema yes i see that
13:48:50 alex_xu_ oh, jaypipes has a dentist appointment
13:50:47 gibi cdent: there is a debate about a need of microversion bump in https://review.openstack.org/#/c/502306/17/specs/rocky/approved/bandwidth-resource-provider.rst@142 this might be interesting to you as well
13:51:37 sean-k-mooney[m] efried: the api schema yes i see that
13:52:03 sean-k-mooney[m] ed ::
13:52:37 gibi cdent: you can free to forward the ping to other API experts :)
13:52:48 gibi s/can/are/
13:53:32 cdent gibi: hmmm. that is an interesting one. my general rule is capture well here: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-03-19-14.00.log.html#l-178

Earlier   Later