Last Friday, we hosted the French event for the international Great Salt Sprint. Here is a report on what was done and discussed on this occasion.
We started off by discussing various points that were of interest to the participants :
- automatically write documentation from salt sls files (for Sphinx)
- salt-mine add security layer with restricted access (bug #5467 and #6437)
- test compatibility of salt-cloud with openstack
- module bridge bug correction : traceback on KeyError
- setting up the network in debian (equivalent of rh_ip)
- configure existing monitoring solution through salt (add machines, add checks, etc) on various backends with a common syntax
We then split up into pairs to tackle issues in small groups, with some general discussions from time to time.
6 people participated, 5 from Logilab, 1 from nbs-system. We were expecting more participants but some couldn't make it at the last minute, or though the sprint was taking place at some other time.
Unfortunately we had a major electricity black out all afternoon, some of us switched to battery and 3G tethering to carry on, but that couldn't last all afternoon. We ended up talking about design and use cases. ERDF (French electricity distribution company) ended up bringing generator trucks for the neighborhood !
Arthur & Benoit : monitoring adding machines or checks
Some unfinished draft code for supervision backends was written and pushed on github. We explored how a common "interface" could be done in salt (using a combination of states and __virtual___). The official documentation was often very useful, reading code was also always a good resource (and the code is really readable).
While we were fixing stuff because of the power black out, Benoit submitted a bug fix.
David & Alain : generate documentation from salt state & salt master
The idea is to couple the SLS description and the current state of the salt master to generate documentation about one's infrastructure using Sphinx. This was transmitted to the mailing-list.
Design was done around which information should be extracted and display and how to configure access control to the salt-master, taking a further look to external_auth and salt-api will probably be the way forward.
General discussions
We had general discussions around concepts of access control to a salt master, on how to define this access. One of the things we believe to be missing (but haven't checked thoroughly) is the ability to separate the "read-only" operations to the "read-write" operations in states and modules, if this was done (through decorators?) we could easily tell salt-api to only give access to data collection. Complex scenarios of access were discussed. Having a configuration or external_auth based on ssh public keys (similar to mercurial-server would be nice, and would provide a "limited" shell to a mercurial server.
Conclusion
The power black out didn't help us get things done, but nevertheless, some sharing was done around our uses cases around SaltStack and features that we'd want to get out of it (or from third party applications). We hope to convert all the discussions into bug reports or further discussion on the mailing-lists and (obviously) into code and pull-requests. Check out the scoreboard for an overview of how the other cities contributed.
to comment this post you need to login or create an account