@prologic (#nsvyaxq) Makes me wonder what you’re referring to with Configuration. Is this a live flag that splits application’s code paths? Is this a plumbing piece that teaches a proxy how to reach the backend? Is this a declaration of dev/stg/prod? What’s the scope?

(#nsvyaxq) So your "configuration" becomes a list of "items" in-order, written in a simple YAML file. The tool runs this file over SSH against a set of hosts you specify on the command-line, stdin or other "discovery" mechanisms and reports the result to stdout/stderr.

(#nsvyaxq) I already have it - Vim + plain text 😜

(#nsvyaxq) So how about this... Let's have a way to run a piece of configuration, let's called it a "script" against one or more machines over SSH. That configuration is specified in a single YAML file across the set of machines. If you want to apply more than one piece of config ro more than one set of machines, you invoke the tool multiple times. The configuration is then a simple list of "items" of the form: - name: name of the item - check: a snippet of shell to determine the state of the item. - action: a snippet of shell to execute if the item's check fails.

(#nsvyaxq) and then has the ability to cobble together informative outputs in order to aid that sticky communication issue problem. eventually, the process is so complicated that you're better to just make a whole new deployment to change a single config value and, frankly, that becomes the safest, most repeatable, most understood method and easiest to assign to the owning dev team. I think it's a big reason for K8's growth: avoid the communication issues.

@eldersnake (#nsvyaxq) no no c’’mon be serious 😂

(#nsvyaxq) the one we need is the one that resolves sticky communications issues between arbitrary deployment technology choices with completely skew practices. that is to say, take beanshells for the worst example, you suddenly need: 0) declarations to point to arbitrary executables that give 0/1 responses 1) endpoint to check the live deployment status 2) endpoint to flush current configs to disk 3) audits all config changes 4) endpoints to load configs from a spot on disk or from the expected config file 5) source control history of config values and changes, like a ChainMap

(#nsvyaxq) @cvshumake Scope is basically running a bunch of "commands" and "configuring" a bunch of "files" on one or more "machines".

(#nsvyaxq) The _key_ thing here is that you use regular shell to compute the state of one or more items on a remote target. ANd then use regular shell again to correct any failed items.