Thanks.
When I wrote 'GuixOps', I meant tools that could replace Ansible.
I am aware of 'guix deploy'. Is Guix currently providing other
tools that could help?
"
- would it be possible to generate a guile script (for GuixOps)
from Ansible?
- would it be possible to change the Ansible to talk to the Guix
(or GuixOps) system?
"
I meant the ability to generate a script for the Guix system
configuration and / or guix deploy from existing Ansible
configurations.
Do you think that creating an intermediate program that converts
Ansible configuration to Guix will be problematic?
A few words of explanation.
I would like to transfer my current infrastructure (configurations
in Ansible) to Guix and I was wondering about the possibilities.
Thanks for all the answers.
Regards,
Robert.
‐‐‐ Original Message ‐‐‐
On Thursday, December 19, 2019 10:13 PM, Thompson, David
wrote:
> Hello Robert,
>
> On Mon, Dec 16, 2019 at 6:57 AM rchar01 rcha...@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
