Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-20
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
13:53:53 alex_xu_ jaypipes: one more question, what is the reason you didn't want to add prefered trait in placement
13:54:25 sean-k-mooney[m] efried: damit lost the message. any TL:DR CUSTOM_SEÁNS_TRAIT would be invalid which is not much of a deal for me but some operators may want to create custom traits in there own language in teh future that said we should try to converge in a set of standard traits to cover there needs and cross the non english traits bridge when we really need too
13:56:29 efried alex_xu_: Because placement is a placer, not a weigher
13:57:10 efried alex_xu_: That's my interpretation of jaypipes' opinion, not necessarily my own
13:57:38 sean-k-mooney[m] alex_xu_: placement is fitting hard constratins, a prefereed trait is a best effort request. filtering based on a best effort request would potentially result in no valid host when there were hosts that met the required traits but no the prefered hence why jaypipes wanted to handel prefred in a weigher not in placement
13:58:13 sean-k-mooney[m] what efried said :)
13:58:50 gibi cdent: thanks, does this also means that in the old microversion we have to keep the old behavior which means not to fail the request just ignore the requested resources?
13:58:53 alex_xu_ efried: thanks for the high level explain, sean-k-mooney[m] thanks for the detail explain :)
13:59:03 efried heh
13:59:37 sean-k-mooney interesting. i have been testing out riot.im as an irc bouncer/bridge. looks like there is a 5-10 secodn delay when i use riot vs direct irc at least on posting. i get messages almost instanly on both
14:00:20 sean-k-mooney sean-k-mooney[m] is my riot.im client
14:00:21 cdent gibi: strictly speaking, yes, but it depends on the severity of the bad behavior
14:00:34 cdent I'm not generally a fan of the strict interpretation
14:02:23 gibi cdent: in this particular case the nova boot request was accepted and the requested resources was ignored. After the proposed change such a request would be rejected with an error message
14:02:27 alex_xu_ sean-k-mooney: Does that mean I require TRAIT_A, and prefer TRAIT_B, there is chance to return nothing when there is no TRAIT_B for any RP? not quite understand
14:02:59 cdent gibi: Again, using the strict interpretation, the older microversions should continue to accept
14:04:03 gibi cdent: assume for a second that we don't make it strict and allow failing in the old microversion. This would mean that there would be no difference between the old and the new microversion
14:04:34 gibi cdent: the only difference would be in the documentation
14:04:41 gibi cdent: about the meaning of the accpet
14:04:53 edleafe alex_xu_: "preferred" doesn't mean anything in placement, since it doesn't order anything
14:05:01 gibi cdent: in this case do we need the microversion bump just for the doc?
14:05:13 edleafe "required" implies a filtering, which is what placement does
14:05:54 alex_xu_ edleafe: 'preferred' order the number of traits which the RP has
14:07:15 cdent gibi: assuming that, then I wouldn't think a microverison was required for a doc change, because the behavior is the same everywhered, right? But if there is in fact a behavior change (in the API itself), that seems like a microversion, right?
14:08:11 alex_xu_ or you guys refer to the implement problem
14:09:45 edleafe alex_xu_: if I prefer a trait, I will accept an RP that doesn't have that trait if necessary. So Placement will return all RPs that satisfy the requirements. It is then up to the scheduler to sort them based on various things, and preferred traits would be one of those things
14:10:32 gibi cdent: I'm hesitant. The external behaviour will change as nova will reject a previously accepted the request. But even if nova today accept such request nova actually lies and nova does not fulfill the request properly as nova does not consider the QoS bandwidth policy on the port that is included in the request during the scheduling
14:11:21 gibi cdent: so by rejecting such request nova we clean up a lie
14:11:23 alex_xu_ edleafe: oh, the weigher will change the order again
14:11:29 cdent gibi: and you break working code
14:11:35 gibi cdent: true
14:11:59 cdent gibi: Which is what microversions are supposed to prevent, even though it means broken (in other ways) client code gets to continue existing
14:12:11 cdent I agree that it is a tricky problem and your hesitancy is warranted

Earlier   Later