Add `resource_class` field to nodes

[tzumainn]

We need to

• figure out resource_class field definitions
• update the node manifests
• update the nodes currently in ESI while also notifying Derek in OKD, as he uses metalsmith which takes resource_class as a parameter
• update ESI documentation to not "hardcode" baremetal in resource_class fields

[tzumainn]

@hakasapl @naved001 Do we have a sense of how we might want to categorize our current nodes? Let me know, and I can update the node manifests and the current nodes.

[hakasapl]

@tzumainn I think we had talked about naming by significant node differences, so we would use:

• fc830 for all fc830s
• fc430 for all fc430s

Not sure what we should call the various different hardware in OCT4 though. @naved001 thoughts?

[naved001]

@hakasapl aren't the OCT4 servers some sort of Dell PowerEdge servers? So, if it's a PowerEdge R720xd we should call it that R720xd.

[joachimweyl]

@tzumainn what are the next steps for this issue?

[tzumainn]

I need a determination of how nodes should be categorized; I think resource_class will ultimately be used for pricing, so we may be blocked on https://github.com/CCI-MOC/ops-issues/issues/1271

[joachimweyl]

@larsks you had some great ideas of how to categorize the nodes, can you chime in?

[joachimweyl]

@msdisme what are your thoughts about bringing this to the Monday stratagy meeting to get feedback on what categories we would want to be billing on?

[larsks]

@joachimweyl I'm not sure that I did have a great idea here. Most of my interest in this was about the ability to filter nodes based on attributes, which is sort of orthogonal to this categorization question.

[hakasapl]

In my opinion it should be the shortened model of the machine:

fc830, fc430, r720xd, etc. Then for specifically different machines, like the ones with NVME drives, fc830-nvme etc.

Basically we only need a different resource class if the cost of running them is significantly different, which translates to a difference in performance. So I think model number works fine, then add extensions if we need to further differentiate for whatever reason

[larsks]

In my opinion it should be the shortened model of the machine:

What if we have two machines from two different vendors (dell and lenovo?) with roughly equivalent hardware -- should those really be two different resource classes? Or should resource_class more closely correlate with something like an openstack flavor -- that is, an alias for a certain amount of resources.

I don't know the answer myself.

[tzumainn]

In my opinion it should be the shortened model of the machine:

What if we have two machines from two different vendors (dell and lenovo?) with roughly equivalent hardware -- should those really be two different resource classes? Or should resource_class more closely correlate with something like an openstack flavor -- that is, an alias for a certain amount of resources.

I don't know the answer myself.

We're going to end up having both resource_class and node properties visible, so in my opinion a single resource class should correspond to a "useful" high-level categorization, like cost (with perhaps a special dump resource_class category for random pieces of hardware where cost depends on node properties). But yeah, this feels like a policy question.

[hakasapl]

@tzumainn I'm happy to make a PR for this unless you already have something working

[tzumainn]

@hakasapl oh, I don't - I was actually waiting for some sort of confirmation, but if you're confident on this you'll definitely be better than me at making sure nodes are labeled correctly!

[hakasapl]

PR submitted: https://github.com/CCI-MOC/esi-pilot/pull/57

[tzumainn]

PR merged, and nodes updated - thanks!