Description
Before I commit more time to fully fleshing out a plan, just wanted to check if this is something that would be considered if I contributed a PR.
The goal: Allow most if not all config to be read dynamic from Consul service labels. Consul is a service mesh and while the most common scenario is where one container surfaces one service, there are very few limitations and services can be registered just fine pointing to an arbitrary address & port. For example Traefik allows dynamic configuration or the reverse proxy via these labels. The largest benefit would be in allowing the adjusting of the config, such as tweaking an interval, without restarting the container. Labels only apply after a container restart whereas service labels are fully dynamic and applied in seconds.
The largest challenge would be coupling the separate service entry to the container in which to execute actions. I believe more freedom would be better & necessary, i.e. essentially allowing any enabled service to request actions for any running container or image. For flexibility I would avoid requiring specifying the target container name since in orchestration environs they are often autogenerated and non-deterministic uuid's. Instead I would look to referring to targets by the ofelia defined id. For example, the only semi-static label based config might be enabling ofelia & defining an executor id that crons attached to services can target.
Reading from & authenticating to Consul is fairly trivial with pre-existing libraries. A small bit of caching would be required however to handle connection loss and for the smoothest operation the auth token would be read from env in the simplest form or a file, where the file would be re-read on a signal to facilitate token rotation without needing a restart.