# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 24
# self = https://watcher.sour.is/conv/nsvyaxq
what would your ideal configuration management tool look like? What features would it have? How would it be different from every other tool out there 🤔
what would your ideal configuration management tool look like? What features would it have? How would it be different from every other tool out there 🤔
I already have it - Vim + plain text 😜
I already have it - Vim + plain text 😜
the one we need is the one that resolves sticky communications issues between arbitrary deployment technology choices with completely skew practices. \nthat 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
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.
So how about this... Let's have a way to run a piece of configuration, let's ca
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.
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:\n\n- name: name of the item\n- check: a snippet of shell to determine the state of the item.\n- action: a snippet of shell to execute if the item's check fails.
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.
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:\n\n- name: name of the item\n- check: a snippet of shell to determine the state of the item.\n- action: a snippet of shell to execute if the item's check fails.
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.
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.
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.
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.
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.
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.
@prologic 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?
@cvshumake Scope is basically running a bunch of "commands" and "configuring" a bunch of "files" on one or more "machines".
@cvshumake Scope is basically running a bunch of "commands" and "configuring" a bunch of "files" on one or more "machines".
@cvshumake Scope is basically running a bunch of "commands" and "configuring" a bunch of "files" on one or more "machines".