Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-01-20
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
13:42:06 sean-k-mooney im waiting for the db dumps and flavor details to confirm but thats also likely a docs bug in our downstream docs
13:42:50 sean-k-mooney we dont have the changes required for moderen ironic where it does not report cpu ram and disk inveories in our downstream docs
14:00:02 stephenfin gibi: bauzas: Think you folks could look at two large-ish outstanding doc reviews I have? They're good stuff, IMO https://review.opendev.org/c/openstack/nova/+/814562 https://review.opendev.org/c/openstack/nova/+/814563
14:03:08 bauzas stephenfin: ack, on a meeting

Earlier   Later