Hey Pjotr, On Mon, Jun 1, 2015 at 11:18 AM, Pjotr Prins <pjotr.publi...@thebird.nl> wrote: >> There's also unanswered questions like: How should we keep track of >> state? How do we reconfigure already deployed machines? How do we shut >> down a deployment and unprovision the resources it used? Basically, how >> many hooks does the <platform> record type need to cover everything? > > The current 'deploy' basically generates a machine from scratch - > there is some similar funtionality in Nix. I read the code and it is > pretty simplistic for now which is possible when you generate a > machine once.
Yes, the code is simplistic because I have only spent about a day or two actually writing code for it. You'll notice that the <platform> data type has many of its fields commented out. Much work to do. > What I would like to have is a state-machine that can be rerun within > an installed deploy in the vein of Puppet/Chef/cfengine but without > the complicated setup of a client/server model (the server 'model' > should simply be a git repository with branches). For persisting state between 'guix deploy' runs, I was going to write an s-expression to a file. The exact state written to such a file and how it will be used will be defined by <platform> objects. The state could then be synced among all the workstations that are doing deployments via whichever mechanism you prefer. I would like to use Git, too, but I don't 'guix deploy' to be concerned with such details. > That means that after 'deploy' we can run the state and it > checks/updates files that may have been changed. I use something like > that to run my hosts.allow configuration (for example). When I want to > add an IP address, I change the state and rerun 'deploy'. In the past > I used to run cfengine. Later I wrote cfruby/cfenjin which I still run > today for deployment and updates. For me it is time to write something > that plays well with GNU Guix. > > Are you envisaging something like that? Something that reruns state > and updates? It is a lot more complicated because you need a way to > define state, modify files, allow for transaction and roll-back. > Ideally the system should execute in parallel (for speed) and be > ordered (i.e. if two methods change the same file the order matters). > BTW cfruby lacks transactions and parallel execution, we could start > without. Sort of yes, sort of no. What you are describing sounds quite imperative. In Guix, if we were to re-deploy a configuration to a running remote system, we'd do the equivalent of what 'guix system reconfigure' does now for local GuixSD machines: an atomic update of the current system (changing the /run/current-system symlink). 'guix deploy' cannot possibly do a good job of managing non-GuixSD systems that just happen to run Guix. I think it would be better to use the existing configuration management tools for that. > The first step is to define state by creating 'classes' of machines. > One class could be deploy 'sshd with IP restriction'. That would be a > good use case. Are you proposing that we add a formal concept of "classes" in Guix or is this just to illustrate an idea? If the former, I think that pure functions that return <operating-system> objects is far more powerful than a primitive class labeling system. Hope this helps clarify some things. Thoughts? - Dave
