| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-20 | |||
| 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 | |
| 12:42:15 | gibi | but they exists logically | |
| 12:42:20 | gibi | just not modelled | |
| 12:42:22 | sean-k-mooney | gibi: to me the grouping in that spec was lexical | |
| 12:42:27 | sean-k-mooney | and not part of the data model | |
| 12:42:41 | sean-k-mooney | so they dont exist | |
| 12:43:04 | sean-k-mooney | they were only grouping to think about idfferent type of trait but should have no baring on impelemention | |
| 12:43:21 | gibi | we use both types from nova | |
| 12:43:24 | gibi | "types" | |
| 12:43:25 | sean-k-mooney | not without a way to catgories CUSTOM_traits | |
| 12:43:43 | gibi | we consider compute feature traits as provider traits | |
| 12:43:46 | sean-k-mooney | we do but i would not expect them to have diffeerent behaviors today | |
| 12:44:00 | sean-k-mooney | i do not | |
| 12:44:21 | gibi | today no different behavior, we carefully putting them to the root RP where we know that we will always consume resources from today | |
| 12:44:32 | gibi | so our nova model works | |
| 12:44:49 | sean-k-mooney | yes because they are beign trated as resouce_traits today | |
| 12:44:52 | sean-k-mooney | by placement | |
| 12:45:19 | gibi | yes | |
| 12:45:44 | sean-k-mooney | so i woudl reassert we are not using provider_traits or root_required today in nova | |
| 12:46:12 | gibi | nova (as the client of placement) needs to simulate the provider_trait logic, by putting provider traits on the root and alway allocation from the root | |
| 12:46:16 | sean-k-mooney | and i dont think we can until we have a way to model provider_traits and resouce_traits in a way that is indepent form the existnace of inventories | |
| 12:46:31 | sean-k-mooney | i dissagree | |
| 12:46:48 | sean-k-mooney | with out a way to model it in the data model we shoudl not try to use a half implemented feature | |
| 12:46:58 | gibi | then which resource CUSTOM_SUPPORT_MULTIATTACH is connected? | |
| 12:47:08 | gibi | today there is no such resource | |
| 12:47:15 | gibi | so it has to be a provider trait :) | |
| 12:47:36 | sean-k-mooney | no since that is not part of the api | |
| 12:47:53 | gibi | it is part of the resource model of the nova | |
| 12:48:01 | gibi | stored in placement | |
| 12:48:03 | sean-k-mooney | no since we dont need it | |
| 12:48:21 | sean-k-mooney | all our logic in nova works without the concpet of a provider trait | |
| 12:49:10 | sean-k-mooney | gibi: if we want to have resouce traits and provider traits there is a simple solution | |
| 12:49:19 | sean-k-mooney | we need to move resouce tratis into the inventory | |
| 12:49:25 | gibi | "simple" | |
| 12:49:27 | gibi | :) | |
| 12:49:48 | gibi | not even to inventory but connecting each trait to an instance of a resource class | |
| 12:49:49 | sean-k-mooney | yes if we want to have resouce traits and provider traits we need to store taits both on the resouce and proviers | |
| 12:50:22 | sean-k-mooney | i think the inventory is simpler to reason about | |
| 12:50:30 | sean-k-mooney | since it jsut works for CUSTOM_ traits | |
| 12:50:59 | sean-k-mooney | if they are applied to the inveotry then they apply to the resouce clas of that invetory | |
| 12:51:16 | sean-k-mooney | so i woudl propose inventory_traits and provider_traits as the speration instead | |
| 12:51:17 | gibi | a cpu flag trait should be connected to the VCPU or PCPU inventory but not a MEMORY_MB inventory | |
| 12:51:41 | sean-k-mooney | traits are opaque stings to placment | |
| 12:51:46 | sean-k-mooney | it does not know the releation ship | |
| 12:51:57 | sean-k-mooney | i dont think we as a client shoudl require placment too | |
| 12:52:02 | sean-k-mooney | unless we change what tratis are | |
| 12:52:18 | sean-k-mooney | and add a mapping tabel where we register every trait with the RC it applies too | |
| 12:52:32 | sean-k-mooney | and an api do that | |
| 12:52:34 | gibi | yes, but if a trait only connects to the inventory but not a resource class instance then a VCPU providing a different set of flags than a PCPU cannot be modelled by the same set of cpu flag traits | |
| 12:52:53 | sean-k-mooney | it can | |
| 12:53:00 | sean-k-mooney | since they are two different inventoies | |
| 12:53:00 | gibi | on the same root RP providing both VCPU and PCU | |
| 12:53:14 | gibi | then we are talking about "inventory" differently | |
| 12:53:23 | sean-k-mooney | correct | |
| 12:53:27 | gibi | I define inventory of an RP as a set of resource class instance | |
| 12:53:39 | gibi | you define an inventory of an RC instead :) | |
| 12:53:41 | sean-k-mooney | im say that the inventory need to change form Resouce class + count | |
| 12:53:50 | sean-k-mooney | to resouce_class + count+ traits | |
| 12:54:06 | gibi | I agree | |
| 12:54:18 | gibi | I think we are in agreement on this | |
| 12:54:30 | gibi | just using different meeting behind "inventory" | |
| 12:54:33 | sean-k-mooney | so we woudl be extending the invotry concpet with a new triats field | |