-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable compliance tests to use plugins for cluster provisioning #753
base: main
Are you sure you want to change the base?
Enable compliance tests to use plugins for cluster provisioning #753
Conversation
d4b2b66
to
bfd1a0f
Compare
@tonifinger Can you please post what a run would look like in the shell? (Just paste something from your terminal.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to use the test infrastructure that we already have, i.e., the scripts
- https://github.com/SovereignCloudStack/standards/blob/main/Tests/scs-compliance-check.py
- https://github.com/SovereignCloudStack/standards/blob/main/Tests/scs-test-runner.py
and the spec files
- https://github.com/SovereignCloudStack/standards/blob/main/Tests/scs-compatible-kaas.yaml (relevant for KaaS)
- https://github.com/SovereignCloudStack/standards/blob/main/Tests/scs-compatible-iaas.yaml
The spec file for KaaS already includes the CNCF conformance test. What I think we could do:
- We make a list of clusters that we need for testing purposes, and for each cluster, we say where we expect the Kubeconfig to sit,
- then your tool can use the plugin to create all these clusters and the corresponding Kubeconfig files at the specified locations,
- it could also use the plugin and this specification to remove the clusters.
- We add calls to your tool to our Zuul job BEFORE and AFTER it runs the actual tests to create and remove clusters, respectively.
This is the output to the shell using the plugin of kind and the logging lvl set to
|
Signed-off-by: Toni Finger <[email protected]>
And apply static plugin Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
a42542d
to
199fdf2
Compare
Signed-off-by: Toni Finger <[email protected]>
Please re-request review from me when you've reached the point. |
Splitting the functionality into the handling of sonobuoys and the provision of K8s clusters. Signed-off-by: Toni Finger <[email protected]>
I have reached a point where you can test the first approach by using You should be able to test this with the following command:
This PR is still in draft as I have to:
|
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Rework rebase conflicts Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Just a quick update on ongoing work:
|
In order to have one clusterspec file for each k8s version Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few remarks
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my minor remarks. Apart from that, it does look good. Now it depends on thorough testing. And of course, we should merge the CAPI plugin before we can go ahead.
Signed-off-by: Toni Finger <[email protected]>
Co-authored-by: Matthias Büchse <[email protected]> Signed-off-by: tonifinger <[email protected]>
Co-authored-by: Matthias Büchse <[email protected]> Signed-off-by: tonifinger <[email protected]>
Add plugin_config to delete process as well Add missing file `kind_cluster_config.yaml` as configuration example Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
The Test with kind plugin gives the following result: provisioning process with kind as plugin:
run tests:
Content of
Unprovision process:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is starting to look really good now. A few minor things though.
make use of Not ImplementedError Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Co-authored-by: Matthias Büchse <[email protected]> Signed-off-by: tonifinger <[email protected]>
Removed the return of the kubeconfig filepath from the `create_cluster` method as we do not use this handling. Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Remove default values to prevent parameters from being optional Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
Signed-off-by: Toni Finger <[email protected]>
This PR introduces an interface that enables the provision of kubeconfig files for the sonobuoy test framework.
Each Kubernetes provider must derive its own specific plugin from this interface class in order to provide a cluster for testing