Closed carlkyrillos closed 5 days ago
Hi @carlkyrillos I verified PR. Done very good, working as described in verification steps. Minor comments in code - up to you.
But I have Comments for design. Can you please look.
Please correct me if I didn't understand something or was wrong. I added question to Design Task Thank you
@carlkyrillos , seems I was wrong when said that Labels and annotations become useless in Secrets that received "watched-by" label/. Metadata still will be used in logics, just changes in it will not cause Pod(s) restarting. But still maybe need think more about this + Regression.
ok ...looked once more. It seems good. PR is very good. Code is clear. Validation notes are clear , precise, detailed, and easy for usage. Thanks.
/lgtm
Issue Link
JIRA: THREESCALE-11396
What
This PR improves on the existing secret watched-by logic in a few ways:
secret.apicast.apps.3scale.net/{secret-UID: 'true'
, where the value was set totrue
regardless of whether the secret had thewatched-by
label. Now the value is set tofalse
if the Secret doesn't have thewatched-by
label andtrue
if the secret does have thewatched-by
label.apimanager.apps.3scale.net/{secret-name}: '{secret-resourceVersion}'
whenever a secret was referenced in the APIcast CR. Now the apicast pod is only annotated if the referenced secret also has thewatched-by
label on it..data
, i.e. changes to the watched secrets labels, annotations, etc. won't trigger a rollout even if though the secret's resourceVersion changed. This is accomplished through a new secret calledhashed-secret-data
that stores a hash of each watched secret's data using SHA256 encryption. Whenever the operator detects that a watched secret's resourceVersion has changed, it first takes a hash of the secret's current.data
and if that matches the secret's entry in thehashed-secret-data
secret, then the operator will ignore the change and prevent a rollout. If the.data
has changed, the operator will update the apicast pod's annotations with the watched secret's latest resourceVersion which will trigger a rollout.Verification Steps
cat << EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: apicast-config-secret namespace: $NAMESPACE type: Opaque stringData: config.json: | { "services": [ { "proxy": { "policy_chain": [ { "name": "apicast.policy.upstream", "configuration": { "rules": [{ "regex": "/", "url": "http://echo-api.3scale.net" }] } } ] } } ] } EOF
Create an APIcast CR that references the
custom-env-1
Secret:Run the operator:
Wait for APIcast to be ready:
Verify that the APIcast labels reference the two secrets' UIDs but the label values are
false
:The labels should look like this:
Verify that the apicast pod annotations don't contain references to the secrets since neither of the secrets have the
watched-by
label:Verify that the
hashed-secret-data
secret exists but is empty:Add the
watched-by
label to the configuration secret:Verify that the APIcast labels were updated and that one of secret labels has a value of
true
:The labels should now look like this:
Once the new pod is ready, verify that it has an annotation referencing the config secret:
There should be an annotation that looks like this:
Verify that the
hashed-secret-data
secret has an entry for the config secret:Edit the data in the config secret and verify a new pod is created:
Once the pods have stabilized, add a label to the config secret and verify that no new pods are created even though the resourceVersion has changed: