Work out usage of 'resource_class' field in ESI

[tzumainn]

The resource_class field can be used to distinguish between classes of nodes. We should determine if we can use this in our ESI deployments, and see if the appropriate information is bubbled up in the various ESI CLI commands

[tzumainn]

@larsks I know we talked about resource_class being perhaps not the ideal field to use, but after looking through Ironic documentation it feels like we should use it. The intent of the field is for it to be used essentially as a baremetal flavor; it's used in things like allocations, and it feels like something we might want users to get used to looking at. In addition, the hardware currently in the MOC ESI looks like it falls into one of four categories.

My thought was that maybe it'd make sense to use the resource_class field and document the exact specs in the ESI documentation (similar to what NERC does with the flavors)? We can also update the various ESI list commands - for nodes, offers, and leases - to add both the resource_class value and perhaps the relevant properties like hard drive size and memory and cpus.

[tzumainn]

Okay, after some further consideration, I have some additional thoughts (adding @naved001 and @hakasapl to see what they think).

• I think we should definitely use the resource_class field as one method of categorization. I understand that in the long term we're going to get increasingly random sizes of hardware that don't easily fit into a specific category; however right now we have so much hardware that is homogenized that I think it'd be more of a problem if we couldn't easily say, for example, how many of the FC430s are currently being utilized. It would make sense to me to have that category of hardware be a resource_class, and then create documentation explaining what specs a particular resource_class has.
• I'll add that it is Ironic's intent that resource_class be used as a flavor-equivalent for things like allocations.
• That being said, I do think it is also useful to be able to see important attributes like arch, cpus, mem, etc. I think we can extend the custom esi list commands (for nodes, leases, offers) to include these.
• For non-homogenized hardware, I'd propose we create broad classifications such as small or medium or large and document that these pieces of hardware have specs that can fall anywhere within a given band.
• Machines with GPUs should have their own resource_class

[tzumainn]

After talking with Lars, it looks like we actually broadly agree: resource_class should be used for broad categorization, but we also want to display and allow users to query for nodes based on exact hardware properties. So what we need to do now is:

• Figure out our desired resource_class classifications, and update our manifests and existing nodes to use them
• Let OKD know, because they use metalsmith, which takes in a resource_class parameter
• Extend ESI-Leap to return resource_class and relevant node properties (taken from properties and maybe traits)

[tzumainn]

I think a decision has been made; follow up issues are:

• https://github.com/CCI-MOC/esi/issues/509
• https://github.com/CCI-MOC/esi/issues/510