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

watch for changes in trusted CA configmap #113

Merged
merged 1 commit into from
Sep 18, 2019

Conversation

joelddiaz
Copy link
Contributor

in order to have the pod run with an up-to-date set of trusted CAs, watch the configmap containing the pods's CAs, and if the contents change, exit the container, so that we get restarted with the new CA content.

@openshift-ci-robot openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Sep 13, 2019
@joelddiaz
Copy link
Contributor Author

/test e2e-aws-upgrade

@joelddiaz
Copy link
Contributor Author

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 16, 2019
@joelddiaz
Copy link
Contributor Author

/test e2e-aws-upgrade

Copy link
Contributor

@dgoodwin dgoodwin left a comment

Choose a reason for hiding this comment

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

Just some docs and logging requests, otherwise looks good.


var _ reconcile.Reconciler = &ReconcileConfigMap{}

// ReconcileConfigMap reconciles a ConfigMap against the on-disk contents.
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets add a little more clarification here that this is for a very specific configmap we want to watch to determine if we should shut down. The controller is quite generically named and you need to go straight to the reconcile loop to understand why we're watching configmaps.

type ReconcileConfigMap struct {
client.Client
logger log.FieldLogger
configMapDataHash string
Copy link
Contributor

Choose a reason for hiding this comment

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

This is persistent state across reconcile loops isn't it. That is interesting, we don't have a lot of examples of that. It looks risky for concurrency, but then we're only reconciling on one single config map. Looks like it should be ok to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, persistent across reconcile calls. And as you say, since we're really only watching one single configmap (openshift-cloud-credential-operator/cco-trusted-ca), this should be safe.

cmHash := fmt.Sprintf("%x", md5.Sum([]byte(cm.Data[configMapKeyName])))

if r.configMapDataHash == "" {
r.logger.Info("Saving hash of configmap containing CA data")
Copy link
Contributor

Choose a reason for hiding this comment

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

When initializing r.logger lets add the configmap namespace/name, and the key as context fields.

Maybe "saving hash of proxy CA configmap".

r.logger.Info("Saving hash of configmap containing CA data")
r.configMapDataHash = cmHash
} else if r.configMapDataHash == cmHash {
r.logger.Debug("no change in configmap detected")
Copy link
Contributor

Choose a reason for hiding this comment

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

"no change in proxy CA configmap detected"

} else if r.configMapDataHash == cmHash {
r.logger.Debug("no change in configmap detected")
} else {
r.logger.Info("Configmap change detected, restarting pod")
Copy link
Contributor

Choose a reason for hiding this comment

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

"proxy CA configmap change detected, restarting pod"

in order to have the pod run with an up-to-date set of trusted CAs, watch the configmap containing the pods's CAs, and if the contents change, exit the container, so that we get restarted with the new CA content.
@joelddiaz
Copy link
Contributor Author

/hold release

@joelddiaz
Copy link
Contributor Author

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 18, 2019
@dgoodwin
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 18, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgoodwin, joelddiaz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 1bdab99 into openshift:master Sep 18, 2019
@wking
Copy link
Member

wking commented Nov 27, 2019

in order to have the pod run with an up-to-date set of trusted CAs, watch the configmap containing the pods's CAs, and if the contents change, exit the container, so that we get restarted with the new CA content.

Do we need this? From here:

When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet.

@joelddiaz
Copy link
Contributor Author

Do we need this?

@wking If memory serves me correctly, the way I understand this is that the configmap changes eventually make it into the container, but the database of trusted CAs wouldn't be reflected in the controller without rebuilding the trusted CA database.
If there's a better way, I'm happy to hear it.

@wking
Copy link
Member

wking commented Nov 28, 2019

...but the database of trusted CAs wouldn't be reflected in the controller...

Ah, yeah, turns out that Go caches the system store on first load and then never reloads the system pool. I'll see if I can get some motion on that upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants