<p dir="ltr">I didn't even think about it but I could have talked about how we've abused salt for our needs. Grumble...</p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, Jun 4, 2017, 5:17 PM B.S. <<a href="mailto:bs27975.2@gmail.com">bs27975.2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/03/2017 02:41 AM, Paul Nijjar via kwlug-announce wrote:<br>
><br>
> In this world of spinning up virtual machines on demand, the concept<br>
> of configuration management -- specifying a server's configuration<br>
> in some text-editable, version-controllable files and deploying them<br>
> to new machines easily -- is pretty popular. Who knew? In the past<br>
> we have had presentations on Puppet and Ansible; this month we will<br>
> get salty. Nathan Fish has been working extensively with the Salt<br>
> (aka SaltStack) configuration management system at his work, and he<br>
> has lots of lessons to share...<br>
<br>
The need for common configuration across machines has recently become<br>
itchier for me. So far I've only had time to do some wikipedia and other<br>
page reading. I see out there, at least, anisble, chef, cfengine,<br>
puppet, salt, and many others if only in passing, e.g. otter.<br>
<br>
I had made a mental note to myself to check further into Salt - nice<br>
timing for SaltStack (?) information.<br>
<br>
Any amount of info seeking quickly has one realizing this is all the<br>
thin edge of a much larger wedge. Configuration is one thing -<br>
maintenance, confirmation, inventory, monitoring, being others. Clearly<br>
my own personal infrastructure is lacking in many areas. It certainly<br>
isn't clear to me where the starting point / logical sequence of steps<br>
begins.<br>
<br>
One thing I came across in my browsing was<br>
(<a href="https://en.wikipedia.org/wiki/CFEngine" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/CFEngine</a>) "Rather than describing the<br>
steps needed to make a change, CFEngine language describes the final<br>
state in which one wants to end up. The agent then ensures that the<br>
necessary steps are taken to end up in this "policy compliant state".<br>
Thus, CFEngine can be run again and again, whatever the initial state of<br>
a system, and it will end up with a predictable result. CFEngine<br>
supports the item of statistical compliance with policy, meaning that a<br>
system can never guarantee to be exactly in an ideal or desired state,<br>
rather one approaches (converges) towards the desired state by<br>
best-effort, at a rate that is determined by the ratio of the frequency<br>
of environmental change to the rate of CFEngine execution."<br>
<br>
The idea of describing where you want to get to, not a script to take<br>
you from wherever you are to where you want to go, makes intuitive<br>
sense. How to incorporate that approach into a tool ... not so much.<br>
<br>
Looking forward to this and Bob.<br>
<br>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div>