Add Params for external service #46
Conversation
…uster Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
tests/utils/kudo/kudo.go
Outdated
| if err != nil { | ||
| log.Errorf("Error waiting for operator deploy to be in-progress: %s", err) | ||
| return err | ||
| if waitForDeploy { |
There was a problem hiding this comment.
The "wait for deploy complete" should also be inside the conditional block, no?
There was a problem hiding this comment.
Mmmmm, maybe. It only assures that the plan status is in 'COMPLETE', which is ok.
Maybe the parameter should be named waitForDeployInProgress, because that's what I tried to accomplish.
The problem with the "WaitForOperatorDeployInProgress" is that for an update to a ConfigMap, the "IN_PROGRESS" step is so short that the test misses it.
There was a problem hiding this comment.
The idea of waiting first for the deploy to be "in-progress" and then waiting for "completed" is to follow the deploy state machine. A parameter update will trigger a deploy, which will cause the deploy status to go from "complete" -> "in-progress" -> "complete".
So the a parameter named "waitForDeploy" waiting for "in-progress" and then "complete" makes sense, because that's what one would want from a function that updates an instances parameters: change the parameter and wait for the parameter change to be reflected fully, i.e., for the deploy plan to complete.
The problem with the "WaitForOperatorDeployInProgress" is that for an update to a ConfigMap, the "IN_PROGRESS" step is so short that the test misses it.
Is this reproducible? Where did you see it happening?
There was a problem hiding this comment.
Yes, generally I would agree with the COMPLETE->IN_PROGRESS->COMPLETE flow.
I've noticed the problem in this step:
https://github.com/mesosphere/kudo-cassandra-operator/pull/46/files#diff-013e06c2e358068fd6cff2d5724007a7R31
In this update, only an additional service is deployed, without updating the Pods of the StatefulSet. I assume that the Apply of the Service is quick enough that the window for "IN_PROGRESS" is very short and not reliable enough to wait for it
Signed-off-by: Andreas Neumann <[email protected]>
Changed wait_for_deployment to use instance generation to check if a new plan is executed Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
tests/suites/cassandra_externalservice/external_service_test.go
Outdated
Show resolved
Hide resolved
Signed-off-by: Andreas Neumann <[email protected]>
|
This is mostly complete - It's still missing the deletion of the external service if the feature is disabled, I'll wait for the Toggle Feature support in KUDO. |
# Conflicts: # operator/operator.yaml # templates/operator/operator.yaml.template # tests/suites/sanity/sanity_test.go
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
# Conflicts: # tests/suites/sanity/sanity_test.go # tests/suites/tls/tls_test.go # tests/utils/k8s/k8s.go # tests/utils/kudo/kudo.go
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
Signed-off-by: Andreas Neumann <[email protected]>
No description provided.