topology-updater: nrt-api Update to v1alpha2

[jlojosnegros]

As part of #1048 we need to update NRT API to v1alpha2
where new top-level attributes have been added to NRT objects.

We will use this top-level attributes to report new pod fingerprint values. see: #1049

address: #1048
see: this issue for more info about new NRT api version

[netlify]

✅ Deploy Preview for kubernetes-sigs-nfd ready!

Name	Link
🔨 Latest commit	2967f33
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-nfd/deploys/63e4d9541d589f00086df516
😎 Deploy Preview	https://deploy-preview-1053--kubernetes-sigs-nfd.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[k8s-ci-robot]

Hi @jlojosnegros. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[PiotrProkop]

@jlojosnegros Thanks for the PR! I think we need to propagate TopologyPolicies and Scope as part of new top-level attributes as part of the effort to move to v1alpha2, we can do this as part of this PR or I can create a new one to do this. The logic for that is described here:

NodeResourceTopology producers should add top-level `Attributes` in the following format
- For `Name` and `Value` of attributes, words should be `snakeCase`
- The `Name` of each attribute should be **the same of the corresponding kubelet configuration option**.
  - example: `--topology-manager-scope` becomes `topologyManagerScope`
  - example: `topologyManagerPolicy` becomes `topologyMaanagerPolicy`
- The `Value` of each attribute should be **one of the value of the corresponding kubelet configuration option, VERBATIM**.
  - example: `single-numa-node` becomes `single-numa-node`
- Should `topologyManagerOptions` be exposed:
  - they should be expanded in key-value pairs, using the `String()` representation
  - each key-value pair should be preceded by the `topologyManagerOption` prefix
  - every other provision described above applies
  - example: the `prefer-closest-numa-nodes` option becomes `topologyManagerOptionPreferClosestNumaNodes`, accepting exactly one of either `true` and `false`.

[marquiz]

Looks simple and unsurprising to me 👍

[ArangoGutierrez]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ArangoGutierrez, jlojosnegros, marquiz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [marquiz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 989d4bb7d594b6c351364ed194dcf3aa5b290970

[ffromani]

@jlojosnegros Thanks for the PR! I think we need to propagate TopologyPolicies and Scope as part of new top-level attributes as part of the effort to move to v1alpha2, we can do this as part of this PR or I can create a new one to do this. The logic for that is described here:

NodeResourceTopology producers should add top-level `Attributes` in the following format
- For `Name` and `Value` of attributes, words should be `snakeCase`
- The `Name` of each attribute should be **the same of the corresponding kubelet configuration option**.
  - example: `--topology-manager-scope` becomes `topologyManagerScope`
  - example: `topologyManagerPolicy` becomes `topologyMaanagerPolicy`
- The `Value` of each attribute should be **one of the value of the corresponding kubelet configuration option, VERBATIM**.
  - example: `single-numa-node` becomes `single-numa-node`
- Should `topologyManagerOptions` be exposed:
  - they should be expanded in key-value pairs, using the `String()` representation
  - each key-value pair should be preceded by the `topologyManagerOption` prefix
  - every other provision described above applies
  - example: the `prefer-closest-numa-nodes` option becomes `topologyManagerOptionPreferClosestNumaNodes`, accepting exactly one of either `true` and `false`.

apologies for late answer. I think the cleanest option would be to file a separate PR depending on this one and in parallel to #1049 to add the attributes reporting. Now that this is merged we don't have many other options anyway though :) I need to check if was already filed, if not I'd be happy to work on that.

[PiotrProkop]

@jlojosnegros Thanks for the PR! I think we need to propagate TopologyPolicies and Scope as part of new top-level attributes as part of the effort to move to v1alpha2, we can do this as part of this PR or I can create a new one to do this. The logic for that is described here:

NodeResourceTopology producers should add top-level `Attributes` in the following format
- For `Name` and `Value` of attributes, words should be `snakeCase`
- The `Name` of each attribute should be **the same of the corresponding kubelet configuration option**.
  - example: `--topology-manager-scope` becomes `topologyManagerScope`
  - example: `topologyManagerPolicy` becomes `topologyMaanagerPolicy`
- The `Value` of each attribute should be **one of the value of the corresponding kubelet configuration option, VERBATIM**.
  - example: `single-numa-node` becomes `single-numa-node`
- Should `topologyManagerOptions` be exposed:
  - they should be expanded in key-value pairs, using the `String()` representation
  - each key-value pair should be preceded by the `topologyManagerOption` prefix
  - every other provision described above applies
  - example: the `prefer-closest-numa-nodes` option becomes `topologyManagerOptionPreferClosestNumaNodes`, accepting exactly one of either `true` and `false`.

apologies for late answer. I think the cleanest option would be to file a separate PR depending on this one and in parallel to #1049 to add the attributes reporting. Now that this is merged we don't have many other options anyway though :) I need to check if was already filed, if not I'd be happy to work on that.

No worries. I have already started working on that :) should have PR ready to review by tomorrow.