JosefAssadERST

> Their RT job requires Catwalk as one of dependencies in requirements list Ah, Catwalk *client*. Got it. Still feels like your initial thought ot removing third party dependencies from...

I find the idea intriguing, but I am a bit wary. I have never implemented this myself, or had users using it, and actually I've never been a user in...

Good scope. I suspect it'll be a bit finicky to design right, because we can't predict what kind of deployment targets will be implemented. So maybe a common framework is...

It's interesting that RT currently *requires* `/live` and `/ready`, because it suggests that the current design assumes K8sish/dockerish infrastructure targets. If we implement a VMWare or even something like a...

Right, so some unstructured and unordered thoughts. * The core idea is to outsource secrets management to a system off Kubernetes, Vault being the obvious candidate. Whether the secret owners...

Here's a concrete proposal. Tell me how much of it you object to. 1. Bake Hashicorp Vault in to RT core. 2. Remove secrets management entirely from infrastructure target plugins...

That's the idea. We don't know if in ten years 99% of our jobs are served in VMWare or on docker daemons. Vault is a neutral place that my proposal...

I have no fundamental disagreements. Still, there's some really big advantages to splitting off secrets management. Can you suggest an alternative?

I am also in favor of making Vault optional, but how would that work assuming we rip secrets management our of infrastructure target plugins? Would there simply not be any...

How about: * Rip secrets management out of infr.t. plugins * Bake Hashicorp Vault _support_ into core (i.e. not shipped with RT, but if one's available, the URL and credentials...