[Platform] Interoperability: extended_resource

[wvwatson]

[Acceptance Criteria] (TBD)

Interoperability test: extended_resource test

Short description of platform test:

if a survey of extended resources and fields determine that the cluster has a lower percentage of available nodes for the class that is required for a cnf pod, then the platform test is not using commoditized scheduling

• goal of this interoperability test

Test Category

• ADD Interoperability category

determining what 'resources' are allocatable for the anuket reference implementation:
https://cntt.readthedocs.io/projects/ri2/en/stable-moselle/chapters/chapter04.html#operational-runbook

https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
"Kubernetes provides a device plugin framework that you can use to advertise system hardware resources to the Kubelet.
Instead of customizing the code for Kubernetes itself, vendors can implement a device plugin that you deploy either manually or as a DaemonSet. The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adapters, and other similar computing resources that may require vendor specific initialization and setup. "

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#cluster-level-extended-resources

AKA does this violate "commoditized scheduling"?

service provider test?

only makes sense if a platform and a cnf is being evaluated

---

Implementation Tasks: TBD

Environment set up tasks:

• [ ]

Upstream tool set up tasks: (test suite + upstream tools)

• [ ]

CNF setup Tasks

• [ ]

Sample CNF tasks:

• [ ]

Code implementation tasks:

• [ ]

Documentation tasks:

• Update Test Categories md if needed
• Update Pseudo Code md if needed
• Update USAGE md if needed
• Update installation instructions if needed

QA tasks

Dev Review:

• walk through A/C
• do you get the expected result?
• if yes,
  • move to Needs Peer Review column
  • create Pull Request and follow check list
  • Assign 1 or more people for peer review
• if no, document what additional tasks will be needed

Peer review:

• walk through A/C
• do you get the expected result?
• if yes,
  • move to Reviewer Approved column
  • Approve pull request
• if no,
  • document what did not go as expected, including error messages and screenshots (if possible)
  • Add comment to pull request
  • request changes to pull request

[lixuna]

See lfn-cnti/bestpractices#309

Relevant for Anuket:

Review Anuket "4. Operational Runbook" and tests or tests ideas from the CNTI Test Catalog
See #1716