Task

Specify and run smoke tests for the Deployed service/component, the Goal is to run some tests against your service after its deployment on the Kubernetes cluster to make sure that it is working as expected, you can achieve this task manually for now but later on, you will automate this. This task involves setting up smoke tests for the service/component deployment, ensuring the reliability and stability of the deployed application.

1- Design Smoke Tests

Smoke Test Specification: Specify smoke tests to verify critical functionalities and basic usability of the deployed service/component. To accomplish this task effectively, it's essential to have access to the deployed service/component and sufficient knowledge of its functionalities and dependencies.

2- Document this smoke tests

Update Documents: Update your documents to include your smoke tests so anybody can refer to them, and later on when you automate it, it will be documented so it will save time.

3- Run Smoke Tests

Run your tests after every deployment on the integration cluster to make sure that the service is working as expected.

Example:

Specify the critical and basic functionalities that the smoke tests will cover.
Provide these smoke tests, like curl or API requests that you will fire to make sure that the service is working as expected after deployment
Provide the expected results for each test.
Provide the steps to run the smoke tests.
Provide the steps to interpret the results.
Update the documentation to include the smoke tests with the results.

4- Integration with Deployment Workflow (This step is optional for now)

Integration with Deployment Workflow: Integrate smoke testing into the deployment workflow to automate the process and ensure it runs seamlessly alongside other deployment steps. you can achieve this using argoCD rollouts for more information check this docs

Acceptance Criteria

[ ] Proper access to the environment.
[x] Smoke tests are documented and cover critical functionalities.
[x] Smoke tests are run after every deployment on the integration cluster.
[x] Smoke testing is integrated into the deployment workflow (This is an option step for now)

Note

Ensure that smoke tests provide quick feedback on the health of the deployed service/component.
Smoke tests should be designed to run efficiently without significantly impacting the deployment process.
You will have to do the smoke testing every time after a new deployment on the integration cluster.
Additional Information
Smoke Testing

@RafyMehany I have a few questions regarding the requested points above:

What is the exact environment where we are going to deploy these smoke tests? I get it is Kubernetes, but should we use local test clusters (e.g., kind, minikube), our own cluster, or the integration cluster?
To test the current version of the service in K8s I have already done something somewhat similar to smoke tests that can be found here. Is this compatible with the request in the issue?
To automate with each ArgoCD deployment the execution of the smoke tests would you suggest "packing" them into a K8s Job? From a quick look into the ArgoCD documentation this seems like our best options (at least according to the current tests).
I don't know if I missed something, but I have not seen any information regarding how to access the integration cluster, or have visibility over the state of ArgoCD applications deployed in the integration cluster. This would be very helpful to have a direct feedback regarding the status of deployments and smoke tests. Could you please provide some pointers?

Dear Mathew,

Regarding the environment, we are going to use the integration environment for all the integration work including the smoke testing and integration neighbor testing, but for sure if you want to test your own work locally and make sure that everything is working before going to the integration cluster you can use something like Kind, Minikube regarding this filehttps://github.com/glaciation-heu/IceStream/blob/main/admission_control_service/demo/demo.sh, I can see the purpose of this bash file is to install, clean, and uninstall,.. your resources, so simply it helps you to manage your resources on the cluster, This actually should be automated using ArgoCD as it will be used to install your chart on our integration cluster, regarding the smoke tests it is a different thing, to achieve smoke tests in quick words, you have to find the critical tests that make you sure that your service is up and running as expected after deployment on the integration cluster and then you have to run these tests like for example executing API requests using CURL requests, for more details you can check the task that was added on GitHub in smoke tests milestone, our first Goal is to identify these tests, document them, run them with every new deployment and automate them if it is possible from your side. to automate the smoke tests with ARgoCD, I recommend using ArgoCD rolloutshttps://argo-rollouts.readthedocs.io/en/stable/#quick-start, it is simple, allow you to run your tests, and allow rolling back in case something goes wrong the Integration cluster access was shared by Dell but we can send another email that has all the credentials to the Integration Cluster, once you have access to the cluster you can check ArgoCd applications that are up and running on the cluster.

Rafy Mehany HIRO-MicroDataCenters

From: Matthew Rossi @.> Sent: Friday, April 19, 2024 4:23 PM To: glaciation-heu/IceStream @.> Cc: Rafy Benjamin @.>; Mention @.> Subject: Re: [glaciation-heu/IceStream] [Policy Decision Point (PDP)] Component Smoke tests (Issue #156)

@RafyMehanyhttps://github.com/RafyMehany I have a few questions regarding the requested points above:

What is the exact environment where we are going to deploy these smoke tests? I get it is Kubernetes, but should we use local test clusters (e.g., kind, minikube), our own cluster, or the integration cluster?
To test the current version of the service in K8s I have already done something somewhat similar to smoke tests that can be found herehttps://github.com/glaciation-heu/IceStream/blob/main/admission_control_service/demo/demo.sh. Is this compatible with the request in the issue?
To automate with each ArgoCD deployment the execution of the smoke tests would you suggest "packing" them into a K8s Job? From a quick look into the ArgoCD documentationhttps://argo-rollouts.readthedocs.io/en/stable/analysis/job/ this seems like our best options (at least according to the current tests).
I don't know if I missed something, but I have not seen any information regarding how to access the integration cluster, or have visibility over the state of ArgoCD applications deployed in the integration cluster. This would be very helpful to have a direct feedback regarding the status of deployments and smoke tests. Could you please provide some pointers?

— Reply to this email directly, view it on GitHubhttps://github.com/glaciation-heu/IceStream/issues/156#issuecomment-2066694914, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFLD6L72ZHOKKWFX73EJGT3Y6ESF3AVCNFSM6AAAAABGJKGBTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGY4TIOJRGQ. You are receiving this because you were mentioned.Message ID: @.***>

glaciation-heu / IceStream

[Policy Decision Point (PDP)] Component Smoke tests #156