resource mgmt utils first steps

[adrianchiris]

It was decided that a common util repo that will be used to host common functionality shared between resource-management projects e.g sriov-cni, sriov-device-plugin, network-resource-injector and sriov-network-operator is desirable as it will reduce code duplication and maintenance.

Currently for repositories like SRIOV CNI / SRIOV CNI Operator / Network Resources Injector and Device Plugin there is or will be a set of E2E tests that are using utils from util package. The set of packages inside allows for instance to create / delete K8s objects, read interface details. Those packages are almost similar in implementation between repositories and most probably could be implemented in one place and imported by each component. Beside tests such utils can be used in code if needed.

Some examples: https://github.com/k8snetworkplumbingwg/network-resources-injector/tree/master/test/util https://github.com/k8snetworkplumbingwg/sriov-network-operator/tree/master/test/util https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin/tree/master/pkg/utils https://github.com/k8snetworkplumbingwg/sriov-cni/tree/master/pkg/utils

next steps are:

• decide on a repo structure
• define criteria functionality that should land in this repo
• methodology for versioning of this project
• define first candidates for moving into this repo
• actually move functionality into this repo and use in the various projects

[MichalGuzieniuk]

I like the idea of this repository as a place for a common code between network plumbing repositories. I know that on the meetings we are now discussing functions that are going to be moved as a first one. Those functions are from utils packages.

But on the other hand we have E2E tests that also contains a lot of duplicated code. Currently I'm working on E2E tests for SRIOV CNI and NRI and I would like to utilize this repository to keep utils from tests in one place instead of making copy and paste. Please take those two files as an example

• https://github.com/k8snetworkplumbingwg/network-resources-injector/blob/master/test/util/pod.go
• https://github.com/k8snetworkplumbingwg/sriov-cni/pull/196/files?file-filters%5B%5D=.MD&file-filters%5B%5D=.go&file-filters%5B%5D=.mod&file-filters%5B%5D=.sh&file-filters%5B%5D=.sum&file-filters%5B%5D=.yml&file-filters%5B%5D=No+extension#diff-4f622abaf0c9f13de8ddbf77cfb90825e030471776de738c6be5e663510dcbe2

My question is about structure of this repository. I suppose that is would be good to split utils used purely in tests from utils used in production code. Will be there two or more packages inside this module?

For instance such folder structure. Is it acceptable?

- utils
      utils.go
- test
--- utils
------ pod 
            pod.go
------ configmap
            configmap.go
------ nad
            networkattachmentdefinition.go

[adrianchiris]

IMO we should definitely have a test folder. for simplicity perhaps just put all k8s object test util files under the same folder ? (especially if they will all eventually share the same package name)

e.g:

- test
--- utils
------ k8sresources
--------- pod.go
--------- configmap.go
--------- nad.go

this effort can be separate from moving non test related functionality.

PR is welcome :)