[WIP] Initial commit

README.md

@@ -0,0 +1,83 @@
+# 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.