Support reloading all configmaps and secrets without injecting annotations

[intrand]

Reloader seems like a really neat project. I can see using this for a number of use-cases, and have mentioned it to some friends as something for them to take a look at, as well.

So far my experience with Reloader has been excellent. It's very fast, small and simple to understand. I like it!

Unfortunately, to use it at work, we really need it to support reloading of deployments/statefulsets/daemonsets ("deployment") upon configmap/secret ("config") change without needing to inject an annotation to every single deployment. It's just not reasonable for us to manage that at this time. We could build some custom thing that adds the annotation to everything, but it seems like a lot of work compared to the application supporting our use-case more directly.

In addition, and especially because of our environment, I share the same concerns as #110 - it'd be amazing if Reloader could do a single update of deployments when some might rely on multiple configs.

I realize I'm asking for a lot here, but I'm interested in the project and the response.

Thanks for your hard work! It's been a pleasure using your software so far :)

[rasheedamir]

Unfortunately, to use it at work, we really need it to support reloading of deployments/statefulsets/daemonsets ("deployment") upon configmap/secret ("config") change without needing to inject an annotation to every single deployment. It's just not reasonable for us to manage that at this time. We could build some custom thing that adds the annotation to everything, but it seems like a lot of work compared to the application supporting our use-case more directly.

will it be OK/acceptable if you need to create a CR (custom resource) for everything you would like Reloader to restart?

In addition, and especially because of our environment, I share the same concerns as #110 - it'd be amazing if Reloader could do a single update of deployments when some might rely on multiple configs.

Yeah we have a plan to add support for it;

[intrand]

Unfortunately, to use it at work, we really need it to support reloading of deployments/statefulsets/daemonsets ("deployment") upon configmap/secret ("config") change without needing to inject an annotation to every single deployment. It's just not reasonable for us to manage that at this time. We could build some custom thing that adds the annotation to everything, but it seems like a lot of work compared to the application supporting our use-case more directly.

will it be OK/acceptable if you need to create a CR (custom resource) for everything you would like Reloader to restart?

I see that as about the same amount of work as adding a kustomization.yaml to each app. It's not the end of the world to do so, but it becomes unwieldy to do that for hundreds of apps written by different teams with different levels of k8s understanding, with only a small handful of apps not needing to be reloaded. The number needing Reloader support might dwindle over time, but I think that's a long way out for us.

I was hoping for something like a global-"auto" with the ability to place an annotation with a value like "false" on the things you want to exclude from Reloader, such as a specific deployment/statefulset/daemonset or even an entire namespace.

Sadly, what I'm requesting is kind of an anti-pattern to what's supported by Reloader right now.

In the meantime we've had multiple discussions and have moved forward with kustomizating apps, at least in the short term, because we'd like to offer the functionality Reloader provides to internal customers.

In addition, and especially because of our environment, I share the same concerns as #110 - it'd be amazing if Reloader could do a single update of deployments when some might rely on multiple configs.

Yeah we have a plan to add support for it;

Awesome! That'd especially be useful for us because some of our stuff mounts quite a few configmaps.

Thanks for getting back to me on this!

[Yann-J]

Hey there, just chiming in as we came across a use case where we would like to apply Reloader's functionality, but we do not have access to the definitions/annotations of the apps' Deployment (because they are auto-generated by a third-party tool - in our case Camel-k).

Is it possible at all today to instruct Reloader to watch all pods in a namespace for instance?

[faizanahmad055]

@Yann-J At the moment, the functionality doesn't exist. But you are welcome to contribute via a PR :) .

[ctrought]

@Yann-J I realize this request was from a long time ago, but sharing here in case anyone else is interested.

what we do is use mutation policies via Gatekeeper to inject annotations/labels as required, so for someone wanting everything to have the annotation they could inject the annotation on whichever objects they want.

https://open-policy-agent.github.io/gatekeeper/website/docs/mutation/

apiVersion: mutations.gatekeeper.sh/v1
kind: AssignMetadata
metadata:
  name: reloader-annotation
spec:
  location: metadata.annotations."reloader.stakater.com/auto"
  match:
    kinds:
    - apiGroups:
      - "apps"
      kinds:
      - Deployment
      - StatefulSet
      - Daemonsets
    namespaceSelector: #optional namespace selector if you want to scope down, otherwise it will do everything
      matchExpressions:
      - key: reloader.io/enabled
        operator: In
        values:
        - auto
    scope: Namespaced
  parameters:
    assign:
      value: "true"