Write tests (whether unit or e2e) targeting servicesStateFromSummary (or any other function responsible for this conversion) which covers some scenarios when converting ClusterSummary status to ServiceSet status.
Especially implement the following flow via mocking unit tests:
- Create ServiceSet with A.
- ClusterSummary shows A is deployed.
- Validate A is deployed in ServiceSet.
- ClusterSummary shows A is Failed now (probably need to mock) with failure message.
- Validate A in ServiceSet also shows failed with failure message.
- ClusterSummary shows A is Pending now with the same failure message from failure previously.
- Validate A in ServiceSet is also pending with the failure message.
- ClusterSummary shows A has conflict now.
- Validate A in ServiceSet shows conflict.
- ClusterSummary now shows A is deployed again.
- Validate ServiceSet also shows A as deployed.
The following flow in e2e tests is also important IMO:
Changing status of a service:
- Create MCS on mothership cluster (can be a CD as well but MCS on mothership is cheap and quick) with service A.
- Verify ServiceSet eventually shows A is deployed.
- Induce forced failure in A. E.g with following:
- template: ingress-nginx-4-13-0
name: nginx
namespace: nginx
helmOptions:
timeout: 1s
values: |
ingress-nginx:
global:
image:
registry: this.does.not.exist.com
- template: postgres-operator-1-15-1
- Verify the ClusterSummary shows error.
- Verify the ServiceSet also shows error with the same failure message as reported in the ClusterSummary.
- Now remove the invalid config from MCS for A so it can become deployed again.
- Verify ServiceSet eventually shows A is deployed again.
Status of service with conflict:
- Create MCS1 on mothership cluster with priority 100 with service A1.
- Create MCS2 on mothership cluster with priority 200 with service A2.
(Here A1 and A2 refer to the same service A but A2 just means a newer version of A than A1)
- Verify that ClusterSummary for MCS2 shows A deployed.
- Verify that the ServiceSet for MCS2 also reflects that A is deployed.
- Verify that ClusterSummary for MCS1 shows conflict with failure message (because MCS1 is lower priority).
- Verify that the conflict status along with any failure message and other relevant info is reflected in the ServiceSet for MCS1.
Write tests (whether unit or e2e) targeting servicesStateFromSummary (or any other function responsible for this conversion) which covers some scenarios when converting ClusterSummary status to ServiceSet status.
Especially implement the following flow via mocking unit tests:
The following flow in e2e tests is also important IMO:
Changing status of a service:
Status of service with conflict:
(Here A1 and A2 refer to the same service A but A2 just means a newer version of A than A1)