Re: Ansible and GuixOps questions

["Thompson, David" <dthompson2@worcester.edu>]

Hello Robert,

On Mon, Dec 16, 2019 at 6:57 AM rchar01 <rchar01@protonmail.com> wrote:
>
> Probably many admins / DevOps are heavily using Ansible. I also use this solution to configure systems and services (on Debian and CentOS).
> I would like to transfer infrastructure to the Guix System and some questions arose:
>
> - is there any way to combine Ansible and GuixOps?

In short, no.  I'm assuming that "GuixOps" means 'guix deploy', which
is its own special tool that would take the place of Ansible if you
choose to use it.

> - is there any way to continue using Ansible to configure Guix (some in guile script and some in ansible)?

In the past I've used Chef (very similar to Ansible) to install Guix
on Ubuntu machines.  You could do the same with Ansible.  If you wish
to deploy systems running Guix System proper, I think that's possible,
too, but you'd have to do some work on your own.  You would have to
build yourself a base image of a barebones Guix system and run your
Ansible scripts from that base.  I imagine that Ansible would be
little more than a thin layer for running 'guix system reconfigure
system.scm' on a remote machine at that point.

> - would it be possible to generate a guile script (for GuixOps) from Ansible?

Sorry, I don't quite understand this.  Maybe?

> - would it be possible to change the Ansible to talk to the Guix (or GuixOps) system?

Need more clarity here as well.  Seems like a duplicate of your second
question??

> Rewriting to Guile (Guix config files):
> * Against:
> ** time consuming
> ** may require new skills
> ** only for Guix, Ansible can configure other GNU / Linux systems

If you're already using Ansible for everything, then yes it would be a
hard sell to switch to something Guix specific, but Guix tools offer
features that no mainstream tools could ever hope to offer.  As I said
earlier, though, you could make a Guix + Ansible mix work if you want.

> * What might the benefits be?

One of the big benefits is getting to use the Guix tooling and
libraries for system deployment in addition to packaging and system
configuration which many people already use.  For people who are used
to Guix, it's relatively easy to use 'guix deploy' whereas it would be
very difficult to use something else.  Another reason is that Ansible
is, frankly, not a very good tool from our point of view.  Ansible's
model is "start from a base image and mutate it into the system you
want."  If you're into reproducibility, this isn't great.  How was the
base image created?  Will running the same Ansible scripts a day from
now produce the exact same image, bit for bit?  Almost certainly not.
Ansible is already mostly redundant with 'guix system' because that
tool takes care of all the configuration management chores.  What is
*not* covered by 'guix system' is remote system management, thus 'guix
deploy' was created. It takes things further by helping you deploy the
same system configurations you use with 'guix system' to many remote
systems.  'guix deploy' is still very new and doesn't have a lot of
features, but it's built on the right foundation to avoid the big
issues with mainstream devops tools.

Hope this helps,

- Dave