Skip to content
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

Test clean for resubmission pipeline #1292

Draft
wants to merge 31 commits into
base: master
Choose a base branch
from

Conversation

maximenoel8
Copy link
Contributor

@maximenoel8 maximenoel8 commented Aug 9, 2024

What does this PR ?

This PR gives the possibility to automatically handle the tools resubmission in the context of a release testing using BV.
In this PR there are two parts :

New cleanup pipeline ( for now 4.3 NUE and PRV )

What does this pipeline

Create a pipeline able to clean the server artifacts created during a BV run.
This pipeline will also redeploy the current clients using the new terracumber functionalities to modify a main.tf file.

What does NOT this pipeline

Adding or removing clients from the current deployment.
Redeploying monitoring and proxy.

New python scripts

main.py

Organize the modules and arguments.

suse_manager_api.py

Call the API ( from controller ) to clean the server artifacts.

suse_manager_ssh.py

Unfortunately, we require a ssh connection to server to remove the know hosts because the clients are fresh deployment.
Could be manage directly in groovy step if we don't want to add this python script.

Testing

Currently tested for debugging BV 4.3 NUE and PRV
Pipeline url : https://ci.suse.de/view/Manager/view/Manager-4.3/job/manager-4.3-qe-build-validation-NUE-cleaning/

What is missing ?

  • Unit tests for the python script
  • Improve the generic pipeline to seamlessly handle all the BV pipelines. We will still require two descriptions to point either on PRV or NUE.
  • Improvement to also redeploy monitoring and proxy, will be possible once all the BV hostnames are aligned to the testsuite names.

Issues

Related to:

return output

except Exception as e:
return f"Exception: {str(e)}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double checking: do we want the following behavior ?

If we catch all Exceptions here, the script won't fail when one happens and I think stages such as

 stage('Delete ssh know hosts') {
       sh(script: "${api_program} --url ${params.manager_hostname} --mode delete_known_hosts")
 }

will still be green, as we do not check the return of this function in main.

The same holds true for the check on stderr.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed that's an issue I already had and need to improve.

logger.info(f"File {local_path} copied to {remote_path} on server {url}")
return "File copy successful"

except Exception as e:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same observation on Exception catching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants