Mirror configuration automatic reload about cri-o HOT 6 CLOSED

I think that either solution would work. Right now Spegel will write the Containerd mirror configuration before starting, by mounting the host path. An API would work just as well but I would guess that it would be just more complicated. I have had requests to specifically support OpenShift which would also add a lot of other complexity in regards to security constraints that I have not looked at yet. I also know of vanilla Kubernetes users who are running cri-o on some or all nodes.

from cri-o.

Intersting idea! setting an inotify on the registry paths could work. Something to note: in the past, I have heard hesitation about updating registries without a drain/reboot because it hides potential misconfiguration in future pull image failures. Not opposed, just mentioning there may be cases where even if we do this, we still want to drain/reboot between updates to make sure misconfiguration is identified easier

from cri-o.

@phillebaba, thank you for getting in touch!

Just so we understand better. The ideal scenario would be when spegel drops a newly generated mirror configuration drop-in in a dot-d directory, and then CRI-O picks it up and reloads its internal state, correct? Or do you want to have an API of sorts to call?

Theoretically, we could have a directory watch and even support the current approach that containerd employs. I suppose this would be hidden behind some option to enable this feature.

from cri-o.

/kind feature

from cri-o.

I do agree that debugging may become more challenging, I have at times had issues with mirror configurations in Containerd. We can divide misconfiguration into two categories, formatting errors, and incorrect values. Formatting errors would probably be the most common. When it occurs it could be ignored, with the mirror configuration not taking effect and the original registry being used and the error logged. Incorrect values would have the same behavior as it has today, the only difference being that the changes would take effect immediately instead of waiting for a restart.

from cri-o.

@phillebaba agreed! I think the delayed failure on incorrect value is the trouble. That said, it would end up being delayed with a reboot and IfNotPresent or Never pull policies anyway, so there's only so much we can do.

All that is to say, I'm interested in helping support this case. Do you have any interest adding support in cri-o for inotify based configuration reload @phillebaba ?

from cri-o.