| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-19 | |||
| 23:50:03 | sean-k-mooney | stderr: | |
| 23:50:05 | sean-k-mooney | Current system CPU time: 5month 4w 4h 23min 16.380000s | |
| 23:50:07 | sean-k-mooney | Current memory usage: 34.6G | |
| 23:50:17 | sean-k-mooney | Current number of tasks: 681 | |
| 23:50:17 | sean-k-mooney | kernel.pid_max: 40960 | |
| 23:50:17 | sean-k-mooney | kernel.threads-max: 1030309 | |
| 23:50:17 | sean-k-mooney | Limit of tasks: 40959 | |
| 23:50:18 | sean-k-mooney | Reducing limit by one to 40958… | |
| 23:50:18 | clarkb | Iguess a failed build is still prgress | |
| 23:50:19 | sean-k-mooney | procfs_tasks_set_limit: Permission denied | |
| 23:50:21 | sean-k-mooney | Assertion 'r >= 0 ? w == v - 1 : w == v' failed at ../src/test/test-procfs-util.c:59, function main(). Aborting. | |
| 23:50:23 | sean-k-mooney | ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― | |
| 23:50:44 | sean-k-mooney | ya not really sure why that failed to be honest | |
| 23:50:59 | sean-k-mooney | there si one failrue out of aorund 300 build tests | |
| 23:51:09 | sean-k-mooney | so its morst fine | |
| 23:51:24 | sean-k-mooney | the build logs are here https://koji.mbox.centos.org/koji/taskinfo?taskID=334490 | |
| 23:51:29 | sean-k-mooney | in case your intersted | |
| 23:52:23 | sean-k-mooney | hopefully its just a buggy test and a rebuild wil fix it but in anycase hopefuly it will get adressed soon | |
| 23:53:35 | sean-k-mooney | im pretty sure i do not have an account that can retriger that on that koji instance so ill just have to wait and see but i can link the failed build on the bugzilla bug | |
| 23:54:14 | clarkb | ya I'm not really in a hurry myself more just trying to follow along since we get semi regular question about it. Though those have died down recently. I think people just know ping is broken now | |
| 23:58:55 | sean-k-mooney | ack https://bugzilla.redhat.com/show_bug.cgi?id=2037807#c10 comment on the bug. ill check it again tomorow but at least peopel are aware of the issue | |
| #openstack-nova - 2022-01-20 | |||
| 11:53:57 | gibi | anyone with placement insights do you agree my conclusion in the bug https://storyboard.openstack.org/#!/story/2009795 ? | |
| 11:58:47 | sean-k-mooney | gibi: ill read over it now | |
| 11:59:52 | gibi | sean-k-mooney: thanks | |
| 12:01:04 | gibi | I've just added one more link to the end of the ticket supporting that it is doc bug | |
| 12:01:06 | sean-k-mooney | oh this is the resouce less traits issue | |
| 12:01:56 | sean-k-mooney | we talked about this before with regrads to neted resource providres and numa i think | |
| 12:01:57 | gibi | yes, the nested magic spec class these traits as provider traits compared to resource traits that are tight to a specific resource class | |
| 12:02:24 | gibi | yes the nested magic spec captures some of that discussion I believe | |
| 12:03:19 | sean-k-mooney | we only have one type of traits in plamcent | |
| 12:03:28 | sean-k-mooney | we dont make a distinciton in the api today | |
| 12:03:31 | gibi | yes | |
| 12:03:35 | sean-k-mooney | af far as i know | |
| 12:03:45 | gibi | the distinction is just logical not implemented | |
| 12:04:06 | sean-k-mooney | right im assserting there is not distinciton and this is a bug not a docs bug | |
| 12:04:33 | sean-k-mooney | but ill re read teh nested magic spec now | |
| 12:07:05 | sean-k-mooney | im really not sure i agree with https://docs.openstack.org/placement/latest/specs/train/implemented/2005575-nested-magic-1.html#resource-versus-provider-traits | |
| 12:07:44 | sean-k-mooney | i do not belive we can assume all custom traits on a resouceless rp are provider traits | |
| 12:15:51 | sean-k-mooney | gibi: so https://docs.openstack.org/placement/latest/specs/train/implemented/2005575-nested-magic-1.html#why-enforce-resourceless-same-subtree does not apply to https://storyboard.openstack.org/#!/story/2009795 since its not a request for a resoucless request group | |
| 12:16:24 | sean-k-mooney | the unnamed group is speical and unlike all other groups it does not require the resouce in it to come form the same RP | |
| 12:16:38 | sean-k-mooney | every named request group does | |
| 12:21:07 | gibi | sean-k-mooney: so you are on the side that an required trait in an unnamed group can come from any RP of the tree? | |
| 12:21:19 | sean-k-mooney | yes stongly so | |
| 12:21:21 | gibi | the code today only considers RPs that are providing resources to the request | |
| 12:21:59 | sean-k-mooney | we do not use root_requires today | |
| 12:22:18 | gibi | I'm reading https://docs.openstack.org/placement/latest/user/provider-tree.html | |
| 12:22:21 | gibi | it seems to be relevant too | |
| 12:22:42 | sean-k-mooney | so if we moved all the resouces form the root rp to numa nodes but did not move the capablity traits they woudl stop working | |
| 12:24:22 | gibi | either we need root_required or we need a resource on the root rp | |
| 12:24:34 | gibi | * resource on the root rp that is requested | |
| 12:24:47 | sean-k-mooney | or the unnamed group is allowed to match it | |
| 12:25:02 | sean-k-mooney | but ya we would have to mvoe to root_reqiured which is an upgrade issue | |
| 12:25:16 | sean-k-mooney | as we would have to make 2 queires and combine them | |
| 12:25:22 | sean-k-mooney | to support rooling upgrades | |
| 12:26:23 | gibi | "Traits can be requested explicitly in the GET /allocation_candidates operation with the required query parameter, but traits on resource providers never span other resource providers. If a trait is requested, one of the resource providers that appears in the allocation candidate should have the trait regardless of sharing or nested providers." | |
| 12:26:28 | gibi | https://docs.openstack.org/placement/latest/user/provider-tree.html#filtering-by-traits | |
| 12:26:45 | gibi | this shows me that the intention is the one that I see in the code | |
| 12:27:36 | sean-k-mooney | well the rp would appear in the allocagtion candiate in the provider tree summary even if it did not provide a resouce correct? | |
| 12:28:30 | gibi | "A dictionary keyed by resource provider UUID included in the allocation_requests, of dictionaries of inventory/capacity information. " | |
| 12:28:47 | gibi | so no, only the RPs that provides resources appear in the summary | |
| 12:28:54 | sean-k-mooney | the current approch impleie si can have a sharing resouceless resouce provider with traits and have them match the unnamed group | |
| 12:28:55 | gibi | the "unused" child RPs are not | |
| 12:29:17 | sean-k-mooney | which woudl be problematic since that is how we do isolated aggreates right | |
| 12:29:42 | sean-k-mooney | https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html | |
| 12:30:32 | gibi | hm, that feature adds the trait on the root RP | |
| 12:30:33 | sean-k-mooney | actully no this i swhy we have to set the trait on every host in the aggreated which is a major ux issue | |
| 12:30:49 | sean-k-mooney | yes today it does | |
| 12:30:59 | sean-k-mooney | but you shoudl be able to create 1 rp | |
| 12:31:04 | sean-k-mooney | add the trait to that | |
| 12:31:14 | sean-k-mooney | with misc_share_via aggreate | |
| 12:31:15 | gibi | OK, I think except the API doc, the rest of the doc is self consistent (even if we don't like how they work) | |
| 12:31:21 | sean-k-mooney | then add other hosts ot it | |
| 12:33:19 | sean-k-mooney | well i think we can agree on not likeign the current behavior | |
| 12:33:23 | gibi | :) | |
| 12:33:39 | sean-k-mooney | i dont think the behaivor shoudl change based on if the rp has a trait or not | |
| 12:35:09 | sean-k-mooney | what happens is you use an older micorverion | |
| 12:35:12 | gibi | I can be convinced to change the logic later / separately. I just hit this while implemented the any-trait logic and first I thought it is a code bug based on the API doc. But now with the other docs in the picture and the actual usage of this in the isolate-aggregate I think this is just a doc bug | |
| 12:35:55 | gibi | sean-k-mooney: do you have a particular microversion to check? I have test env so I can try | |
| 12:35:57 | sean-k-mooney | i think its more subtle then that | |
| 12:36:03 | sean-k-mooney | i think the doc captured the intent | |
| 12:36:15 | gibi | which doc? the API or the provider-tree doc? | |
| 12:37:01 | sean-k-mooney | api doc captures how i expected this to work the provider-tree doc captures what the code is doing | |
| 12:37:39 | sean-k-mooney | i find the current behavior hard to reasonable usefully | |
| 12:38:26 | sean-k-mooney | to me the idea that a trait in the unnamed group can match agaisnt any RP in the tree or in a sharing rp is a fundemental part fo the api regardelss of if resouces are requested form it | |
| 12:38:56 | sean-k-mooney | gibi: with out it i dont know how to reason about trait request from images | |
| 12:39:17 | sean-k-mooney | or in the flavor to some degree but images are the most restict way a user can express traits | |
| 12:39:31 | sean-k-mooney | they can only form part of the unnamed group | |
| 12:39:49 | gibi | from the nested magic spec I feel that the current implemented logic supports resource traits, qualities related to certain resource classes (happen to be on the same RP) for the provider trait case we _shoudl_ use root_quired | |
| 12:40:12 | gibi | probably the traits from the image should be translated to root_required | |
| 12:40:17 | sean-k-mooney | that the thing i really dont like the intordcution fo provdier traits | |
| 12:40:21 | gibi | but I guess we put them in the unnamed group | |
| 12:40:31 | sean-k-mooney | how can we know if a CUSTOM_trait is a resouce trait or a provider tarit | |
| 12:40:40 | sean-k-mooney | it should not be based on if there is an inventoy on the RP | |
| 12:40:40 | gibi | with the current model we don't | |
| 12:40:48 | sean-k-mooney | that inventory may not be related to the trait | |
| 12:41:12 | gibi | simply the current trait model cannot nicely describe both type of traits | |
| 12:41:41 | gibi | and it seems the impl opt to consider a trait a resource trait by default | |
| 12:41:55 | gibi | and provider triats are harder to model properl;y | |
| 12:42:01 | gibi | with the current model | |
| 12:42:03 | sean-k-mooney | i would put it more stongly right now there are only one type fo traiats and provider/resouce traits shoudl not be discussed | |