Separate node and partition configuration

[sjpb]

Replaces openhpc_slurm_partitions with openhpc_nodegroups and openhpc_partitions, to make complex partition configurations correct. Previously it would have been possible to to defined nodes twice, with different parameters, and only the first occurance would have been used.

As part of these changes this:

• Adds nodegroup.node_params to allow specifying additional Node-level parameters
• Adds nodegroup.features to allow specifying additional Node features
• Removes openhpc_slurm_partitions.cluster_name
• Removes openhpc_slurm_partitions.extra_nodes

[sjpb]

In the slurm appliance, it needs the default openhpc config and the tf-templated one to be something like:

openhpc_nodegroups:
  - name: compute
openhpc_partitions:
  - name: compute

but, maybe, the latter should actually be in common env as openhpc_partitions: "{{ openhpc_nodegroups }}" to give a partition per nodegroup by default, with no further config.

[jovial]

Does it resolve the issues with autoconfiguration?

This is definitely workable and seems better than describing properties of nodes on the partition (which could be configured inconsistently when nodes were members of multiple partitions.

Should openhpc_nodegroups actually be called openhpc_nodesets

+1 for consistency

Do we want to extend this with an alternative way of overriding the "top-level" parameters, to make all this breaking change visible in one PR (or, we just fixup release notes after - that's probably better).`

Could you give an example? Just trying to figure out exactly what you mean here.

Do we want to add a validate task which checks no nodegroups overlap hosts? Shouldn't be too hard, I think.

Always good to fail early

[sjpb]

Actually @jovial if we're using Features/NodeSets internally we can't let people do openhpc_nodegroups[*].params.Features b/c that'll break our templating so I will have to add an openhpc_nodegroups[*].features which is additive to the nodegroup features.

edit: now done

[jovial]

Changes look sensible to me. Would be interested to hear feedback from people setting per node params and if it works for them.

[sjpb]

@priteau do you want to look at this for Will's comment:

Would be interested to hear feedback from people setting per node params and if it works for them.

[sjpb]

This was reverted in ed717da to permit #186 to be merged "first".