# What it should become?

Utility service like puppetlabs puppet, but a bit simplified. It will consist of 2 parts - server and agent. Each agent
will be able to fetch only configs thaat intened only for it's use. On server-side there will be jsons that describing
separate hosts, host-groups and services and all of these files will be under control of some vcs like hg or git.

## When it will be ready to see and touch?

There is no due or deadline it will de ready to test or use. All depends on speed of researching abilities of lua and
other go modules. And spare time ofcorse. It is some sort of pet-project. If there is any use of this project it will
be great!

## Short story - why this project began?

The thing is that puppetlabs puppet become fat-ass monster that is relatively hard to maintain. Its development process
move relatively in fast pace newer versions are sometimes incompatible with older ones it is hotably hard to keep heap
of already working manifests, templates and configs up to date with newer versions of puppet.

Version 2.7 of puppet was relatively easy to maintain but awful to install on newer systems. Matz's Ruby Interpreter is
unable to deliver acceptable level of performance hogging cpu fast. So i have to run JRuby which using JVM which is
famous for its memory wasting. It is faster than MRI, but compiling newer JVM on older linuxes is real pain in the ass.

In ruby eco-system exist Ruby-On-Rails framework that is all-in-one solution for web apps in ruby ecosystem. But
puppetlabs puppet does not use it. So it is relatively hard to force puppet server work in proper scalable and stable
fashion. If you want to package puppet server, you have to build ruby itself, and vendor tons of modules of specific
versions and also put there puppel-server itself.

It is clear that with each new version of puppet its appetites grew in exploding manner and as of today it is became fat
beast.

So to speak, it was version 2.7 with it's own bust, that relavely well working, but it is more than 10 years old and
long ago obsoleted bu puppetlabs. It was designed to run on later versions of ruby-1.8. With some minor quirks it is
possible to make it work on ruby-1.9. But to make it work on more recent versions of ruby puppet-2.7 should be heavily
reworked. And generally puppet suffres fron performance issues because it was written entirely on ruby.

Speaking of puppet agent it is resource hog too.

Some time ago i've got an idea to puppet me home servers but in a more pleasurable manner. And I looked at what is on
"market" exist on this toppic. It was same players: puppet, chef, ansible, salstack, cfengine.

And all of these solutions have thei own weak spots. And one of the most painful is portability. For example ansible
itself claims tha it is agentless. But in reality it uses naked python on client-side, they blew somewhat-compatible
client-code on python3 stdin and it executes it. Agent is ephemeral but in order to run commands it requires real
python3 interpreter installation, so they just lie about agentlessity of puppet to sell it to sylly ones.

Nevertheless, in my opinion puppet is most suitable solution because it not only able to setup services but also
designed to support cosistent configuration and on configuration change it restores changes back. And well puppeted
servers can preserve its servers configuration. Agents regulary run and poll puppet server for configs state and compare
it with local state situation. All configs transformed to their original state and revices restarted to maintain
original configuration.

Thats why i've com to idea of making my own service same in spirit as puppet, but less complex. Its goal will be to
distribute config changes and maintain state of puppeted machines.

puppet in a nutshell, but on a diet.

## What is working mechanics?

The request made fron client to server and payload of request describes some facts abou itself like what os it running,
what its hostname, networking interfaces, addresses, package manager etc - all general info that can be required for
configuration. As respose server sends long json that describes what configs with which data should be placed on
filesystem and which services should be restarted.

## What about dashboard-а?

I am not able to make very beutiful dashboards. The idea is to cheat and make simple to use API to give the idea of
state of servers and supply some additional metrics and data. This api and be joined with monitoring system (like zabbix,
icnga, etc) to make nice dashboards and perform alerts and notifications. It is more convinient way of representing
status data in my opinion.

## Why lua was taken as scripting language?

There is more than one implementation of lua language on go. Including github.com/yuin/gopher-lua which seems to be
interesting. It gives ability to make own modules in go. At least it is possible to make own implementation of json
and http(s) modules that can be useful in lua templaing. Also it is possible to make lua module that can put variables
from go namespace to lua's.

## So, how progress on this puppet-thing implementation?

All progress in this repo.

Right now it all about r'n'd of current libraries and crutch all of this to make workint pieces of code for lua
templating engine.