static-pools policy: support exporting resources in resources.sh file

[marquiz]

Stemming from the comment that @klihub made in #368

CRI-RM exports CPU resource partitioning information in a file (/.cri-resmgr/resources.sh) inside every container. Currently the static-pools policy does not support this, but, just injects an empty file.

First question is that does it make sense to add support for this? From the CMK-compatibility point-of-view there is no use adding that. On the other hand, from pow of CRI-RM internal coherency it probably would make sense to add it.

The second question is what to export there as the set of currently specified variables defined do not necessarily match 1-to-1 to how the static-pools policy works. For example: There might be numerous pools, some of which are exclusive and some of which are not. Also there might be isolated CPUs but the policy does not know about that (those are expected to be taken into account at config creation time).

[klihub]

Stemming from the comment that @klihub made in #368

CRI-RM exports CPU resource partitioning information in a file (/.cri-resmgr/resources.sh) inside every container. Currently the static-pools policy does not support this, but, just injects an empty file.

First question is that does it make sense to add support for this? From the CMK-compatibility point-of-view there is no use adding that. On the other hand, from pow of CRI-RM internal coherency it probably would make sense to add it.

For any existing CMK-compatible workload it does not bring any benefit to get exposed to new data that they are not already aware of. This is somewhat a non-answer to your question.

The second question is what to export there as the set of currently specified variables defined do not necessarily match 1-to-1 to how the static-pools policy works. For example: There might be numerous pools, some of which are exclusive and some of which are not. Also there might be isolated CPUs but the policy does not know about that (those are expected to be taken into account at config creation time).

Any policy is free to expose an arbitrary set of policy-specific key-value data. The predefined set of keys simply reflects some concepts/features that are common to many of the existing policies. They are not meant to and do not restrict semantically what data can/should be exposed.

[marquiz]

The predefined set of keys simply reflects some concepts/features that are common to many of the existing policies.

OK, I wasn't sure what was the thinking behind the pre-defined keys.

For any existing CMK-compatible workload it does not bring any benefit to get exposed to new data that they are not already aware of.

True. We can extend the functionality to dynamic allocation with this – I just don't know how many users there really would be. Sounds like a low-priority backlog item to me