| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-20 | |||
| 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 | |
| 12:54:53 | gibi | we would extend the inventory of an RC concpet :D | |
| 12:55:22 | gibi | anyhow we agree here and we are pretty far from my original problem | |
| 12:55:35 | sean-k-mooney | well an invtory is a top level object in placment | |
| 12:55:37 | sean-k-mooney | https://github.com/openstack/placement/blob/master/placement/objects/inventory.py | |
| 12:55:52 | sean-k-mooney | so im saying we shoudl add a traits filed that is a list of traits | |
| 12:55:56 | gibi | I will not change the current behavior of the trait filtering logic when I implement any-traits | |
| 12:56:11 | sean-k-mooney | ack | |
| 12:56:19 | sean-k-mooney | i still think its a bug as currently defined | |
| 12:56:34 | sean-k-mooney | but we can change it fi we add inventory level traits | |
| 12:56:39 | gibi | yeah | |
| 12:57:03 | gibi | I think it is not a bug based on the original intent (the magic spec) it might be a bug from the current intent we have | |
| 12:57:51 | sean-k-mooney | i dont think the magic spec ful filles its intended uscases but it may be the intent of the autours | |
| 12:58:03 | gibi | still as there is a disconnect between the API doc and the behavior I would change the doc to avoid a loss of a day of others like me reading only the aPI doc | |
| 12:58:37 | sean-k-mooney | we likely shoudl adress teh api doc issue yes to make it aling with how it work | |
| 12:58:56 | sean-k-mooney | but i also think we shoudl avoid using any of the feature intoduced in the magic spec | |
| 12:59:14 | sean-k-mooney | until we reconsider the data model | |
| 12:59:28 | gibi | you mean we should not use root_required from nova? | |
| 12:59:34 | sean-k-mooney | correct | |
| 12:59:38 | gibi | I'm fine with that limit | |
| 12:59:48 | gibi | we already use same_subtree tough | |
| 12:59:56 | sean-k-mooney | well | |
| 12:59:57 | gibi | which was also defined by the magic spec | |
| 13:00:16 | sean-k-mooney | rather then limit i shoudl say be very very carful of depening on this if we want to change it going forward | |
| 13:00:31 | sean-k-mooney | im not sure the curent magic spec is compatblie with how i tought about numa in placment | |
| 13:00:42 | gibi | that is a good question | |
| 13:01:10 | gibi | the numa spec could be an input to rething the placement model | |
| 13:01:14 | sean-k-mooney | right now i dont think we are useing resouceless rps correct | |
| 13:01:23 | sean-k-mooney | i think that is the point we have to be careful | |
| 13:01:34 | sean-k-mooney | root_required is proably ok | |
| 13:02:06 | sean-k-mooney | untill we have resourceless rps the distinction does not matter | |
| 13:02:27 | sean-k-mooney | so that is the bit i would avoid for now | |
| 13:02:34 | gibi | I agree | |
| 13:02:40 | gibi | resourceless rp feels like an edge case | |
| 13:03:32 | sean-k-mooney | do we have any features that require it currently that are in flight | |
| 13:03:43 | sean-k-mooney | i do not think so but just wondering | |
| 13:04:26 | sean-k-mooney | nic affinity/anti affintiy i think was on eof the usecase form the spec but we dont have that today | |
| 13:04:43 | sean-k-mooney | and my draft pci in placment spec did not use it | |
| 13:04:56 | gibi | I dont know about any use case that needs it now | |
| 13:05:02 | sean-k-mooney | i was only going to model providres of PF ro VF but not the nic | |
| 13:05:08 | sean-k-mooney | ok | |
| 13:05:42 | sean-k-mooney | so we can likely update the api doc without "breaking" exisitng usecases | |
| 13:05:49 | gibi | yeah | |
| 13:06:20 | sean-k-mooney | i think i need to breing up the ponit that we shoudl be spending more time workin on plamcnet internally | |
| 13:06:24 | sean-k-mooney | again | |
| 13:07:19 | gibi | yeah | |
| 13:07:49 | gibi | I feel the pain touching placement internals now as I lost most of the context and honestly the core placement devs are not with us any more | |
| 13:08:42 | sean-k-mooney | placement is decptive. it mostly just works and is well tested, but there are sharp edges in places where we dont use a feature yet | |
| 13:08:54 | sean-k-mooney | the bits we use work great | |
| 13:09:14 | gibi | ... and the sql in the implementation is way more complex than what I can easily grok | |
| 13:17:45 | opendevreview | Imran Hussain proposed openstack/nova master: [nova/libvirt] Support for checking and enabling SMM when needed https://review.opendev.org/c/openstack/nova/+/825496 | |
| 13:28:15 | opendevreview | Balazs Gibizer proposed openstack/placement master: Clarify trait filtering in the API doc https://review.opendev.org/c/openstack/placement/+/825501 | |
| 13:28:27 | gibi | sean-k-mooney: ^^ this is the API doc update | |
| 13:32:11 | gibi | and thanks for talking it through with me | |
| 13:38:17 | sean-k-mooney | ack no worries | |
| 13:38:38 | sean-k-mooney | i did not expect the behavior in the story so its good to know to not get bitten by it | |
| 13:39:55 | sean-k-mooney | i have an downstream ironic edgecase that might be related to this by the way although i think they just forgot to zero out cpu ram and disk requests in the flavor | |
| 13:40:25 | sean-k-mooney | they do not have a resouce class associated with the ironic node | |
| 13:40:40 | sean-k-mooney | so they likely have no inventoies on teh RP | |
| 13:41:06 | sean-k-mooney | they are seing the request to palcment elimiate teh placment rps for the ironic nodes | |