Better support remote deployment

Better support remote deployment

[Ricardo Wurmus]

Hi Guix,

I build software locally and deploy the result to a remote system with
“guix copy”.  This works pretty well but has a few rough edges:

1. “guix build -m manifest.scm” does not generate a profile.  It only
builds the list of packages.  To build a profile from a manifest file we
need to resort to something like this:

    guix shell -m $(PWD)/etc/container-server-manifest.scm -- sh -c 'echo $GUIX_ENVIRONMENT'

2. “guix package” cannot install an existing profile store item as the
current generation of the profile.  It can, however, install individual
package items into a profile.

3. “guix package --remove” does not support regular expressions, so
removing packages that were installed with “guix install /gnu/store/…”
cannot easily be removed.

Because of these limitations I cannot make use of a Guix profile symlink
forest on the target system.  Instead I build a profile locally (with
the “guix shell” trick above), copy it to the remote with “guix copy
--to=remote /gnu/store/…-profile”, and then link that profile to a fixed
location on the remote system.

I would like to change this workflow so that I can benefit from roll
backs without having to manually mess with symlinks.

What do you think about changing “guix package” and/or “guix copy” to
better support deployment of remote profiles?

-- 
Ricardo

Re: Better support remote deployment

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Ricardo,

On Wed, Nov 01 2023, Ricardo Wurmus wrote:

> What do you think about changing “guix package” and/or “guix copy” to
> better support deployment of remote profiles?

As someone who uses 'guix deploy' all the time. I believe remote
administration is one of our core strengths and selling points. Other
remote administration tools like Ansible or Puppet are probably no
longer needed when using GNU Guix System.

I currently have only x86_64 equipment deployed, so there is no
cross-building happening in my setup. Is that the main purpose of your
proposal?

Your effort to extend Guix's spectacular remote capabilities to other
parts of of the Guix package manager seems exceptionally valuable to
me. Thank you for working on it!

Kind regards
Felix

Re: Better support remote deployment

[Ricardo Wurmus]

Hi Felix,

> On Wed, Nov 01 2023, Ricardo Wurmus wrote:
>
>> What do you think about changing “guix package” and/or “guix copy” to
>> better support deployment of remote profiles?
>
> As someone who uses 'guix deploy' all the time. I believe remote
> administration is one of our core strengths and selling points. Other
> remote administration tools like Ansible or Puppet are probably no
> longer needed when using GNU Guix System.
>
> I currently have only x86_64 equipment deployed, so there is no
> cross-building happening in my setup. Is that the main purpose of your
> proposal?

No, both machines are x86_64.  I think “guix deploy” could benefit from
a way to not only deploy Guix System (which makes the tool primarily
useful for managing hosts, not applications) but also profiles and
containers.

-- 
Ricardo

Re: Better support remote deployment

[Maxim Cournoyer]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> I build software locally and deploy the result to a remote system with
> “guix copy”.  This works pretty well but has a few rough edges:
>
> 1. “guix build -m manifest.scm” does not generate a profile.  It only
> builds the list of packages.  To build a profile from a manifest file we
> need to resort to something like this:
>
>     guix shell -m $(PWD)/etc/container-server-manifest.scm -- sh -c 'echo $GUIX_ENVIRONMENT'
>
> 2. “guix package” cannot install an existing profile store item as the
> current generation of the profile.  It can, however, install individual
> package items into a profile.
>
> 3. “guix package --remove” does not support regular expressions, so
> removing packages that were installed with “guix install /gnu/store/…”
> cannot easily be removed.
>
> Because of these limitations I cannot make use of a Guix profile symlink
> forest on the target system.  Instead I build a profile locally (with
> the “guix shell” trick above), copy it to the remote with “guix copy
> --to=remote /gnu/store/…-profile”, and then link that profile to a fixed
> location on the remote system.
>
> I would like to change this workflow so that I can benefit from roll
> backs without having to manually mess with symlinks.
>
> What do you think about changing “guix package” and/or “guix copy” to
> better support deployment of remote profiles?

I like the use case, but perhaps it'd be best implemented via hooking
'guix home' configs with 'operating-system' ?  So you could say, for
this user, I want the following packages and services installed?

Would that work for your use case?

-- 
Thanks,
Maxim

Re: Better support remote deployment

[Ricardo Wurmus]

Hi Maxim,

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Guix,
>>
>> I build software locally and deploy the result to a remote system with
>> “guix copy”.  This works pretty well but has a few rough edges:
>>
>> 1. “guix build -m manifest.scm” does not generate a profile.  It only
>> builds the list of packages.  To build a profile from a manifest file we
>> need to resort to something like this:
>>
>>     guix shell -m $(PWD)/etc/container-server-manifest.scm -- sh -c 'echo $GUIX_ENVIRONMENT'
>>
>> 2. “guix package” cannot install an existing profile store item as the
>> current generation of the profile.  It can, however, install individual
>> package items into a profile.
>>
>> 3. “guix package --remove” does not support regular expressions, so
>> removing packages that were installed with “guix install /gnu/store/…”
>> cannot easily be removed.
>>
>> Because of these limitations I cannot make use of a Guix profile symlink
>> forest on the target system.  Instead I build a profile locally (with
>> the “guix shell” trick above), copy it to the remote with “guix copy
>> --to=remote /gnu/store/…-profile”, and then link that profile to a fixed
>> location on the remote system.
>>
>> I would like to change this workflow so that I can benefit from roll
>> backs without having to manually mess with symlinks.
>>
>> What do you think about changing “guix package” and/or “guix copy” to
>> better support deployment of remote profiles?
>
> I like the use case, but perhaps it'd be best implemented via hooking
> 'guix home' configs with 'operating-system' ?  So you could say, for
> this user, I want the following packages and services installed?
>
> Would that work for your use case?

No, because on the remote I don’t have Guix System.

It would still be useful, but not for this use case.

-- 
Ricardo

Re: Better support remote deployment

[Maxim Cournoyer]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Maxim,
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Hi Guix,
>>>
>>> I build software locally and deploy the result to a remote system with
>>> “guix copy”.  This works pretty well but has a few rough edges:
>>>
>>> 1. “guix build -m manifest.scm” does not generate a profile.  It only
>>> builds the list of packages.  To build a profile from a manifest file we
>>> need to resort to something like this:
>>>
>>>     guix shell -m $(PWD)/etc/container-server-manifest.scm -- sh -c 'echo $GUIX_ENVIRONMENT'
>>>
>>> 2. “guix package” cannot install an existing profile store item as the
>>> current generation of the profile.  It can, however, install individual
>>> package items into a profile.
>>>
>>> 3. “guix package --remove” does not support regular expressions, so
>>> removing packages that were installed with “guix install /gnu/store/…”
>>> cannot easily be removed.
>>>
>>> Because of these limitations I cannot make use of a Guix profile symlink
>>> forest on the target system.  Instead I build a profile locally (with
>>> the “guix shell” trick above), copy it to the remote with “guix copy
>>> --to=remote /gnu/store/…-profile”, and then link that profile to a fixed
>>> location on the remote system.
>>>
>>> I would like to change this workflow so that I can benefit from roll
>>> backs without having to manually mess with symlinks.
>>>
>>> What do you think about changing “guix package” and/or “guix copy” to
>>> better support deployment of remote profiles?
>>
>> I like the use case, but perhaps it'd be best implemented via hooking
>> 'guix home' configs with 'operating-system' ?  So you could say, for
>> this user, I want the following packages and services installed?
>>
>> Would that work for your use case?
>
> No, because on the remote I don’t have Guix System.
>
> It would still be useful, but not for this use case.

I see.  Then your suggestion to extend 'guix package' to be able to
install a profile from a store profile sounds useful, or perhaps a new
'guix deploy-profile' (or a better name / sub-command?) that would
automate the copy and installation in one step.

-- 
Thanks,
Maxim

Re: Better support remote deployment

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

On Tue, Nov 07 2023, Maxim Cournoyer wrote:

> Then your suggestion to extend 'guix package' to be able to
> install a profile from a store profile sounds useful, or perhaps a new
> 'guix deploy-profile' (or a better name / sub-command?) that would
> automate the copy and installation in one step.

We have a lot of sub-commands already. Could 'guix deploy' instead be
fed something other than a 'machine' record?

How about a 'remote-user-profile'?

Kind regards
Felix

Re: Better support remote deployment

[Maxim Cournoyer]

Hello,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi,
>
> On Tue, Nov 07 2023, Maxim Cournoyer wrote:
>
>> Then your suggestion to extend 'guix package' to be able to
>> install a profile from a store profile sounds useful, or perhaps a new
>> 'guix deploy-profile' (or a better name / sub-command?) that would
>> automate the copy and installation in one step.
>
> We have a lot of sub-commands already. Could 'guix deploy' instead be
> fed something other than a 'machine' record?

Perhaps too much of an overload of that command; not sure.

> How about a 'remote-user-profile'?

'guix package' is already the command we use to create profiles; maybe
it could accept a '--remote' argument to operate on a remote machine?
Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package
-m manifest.scm' can already accomplish? :-)

-- 
Thanks,
Maxim

Re: Better support remote deployment

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Wed, Nov 08, 2023 at 09:36:46AM -0500, Maxim Cournoyer wrote:
> Hello,
> 
> Felix Lechner <felix.lechner@lease-up.com> writes:
> 
> > Hi,
> >
> > On Tue, Nov 07 2023, Maxim Cournoyer wrote:
> >
> >> Then your suggestion to extend 'guix package' to be able to
> >> install a profile from a store profile sounds useful, or perhaps a new
> >> 'guix deploy-profile' (or a better name / sub-command?) that would
> >> automate the copy and installation in one step.
> >
> > We have a lot of sub-commands already. Could 'guix deploy' instead be
> > fed something other than a 'machine' record?
> 
> Perhaps too much of an overload of that command; not sure.
> 
> > How about a 'remote-user-profile'?
> 
> 'guix package' is already the command we use to create profiles; maybe
> it could accept a '--remote' argument to operate on a remote machine?
> Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package
> -m manifest.scm' can already accomplish? :-)

Currently there's no ssh connection caching, so using GUIX_DAEMON_SOCKET
can be quite slow, I normally allow 5-10 minutes for a profile. That
works best when you can't use guix copy to send derivations over.

The profile effectively already exists, it doesn't need to be computed
on each machine.  It does seem more like deploy: take this profile, send
it to that machine, and activate it there.  `guix deploy` already takes
a file, the file could have a profile (or home config?) and a location
for the profile. And a user.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Better support remote deployment

[Maxim Cournoyer]

Hi,

Efraim Flashner <efraim@flashner.co.il> writes:

[...]

>> 'guix package' is already the command we use to create profiles; maybe
>> it could accept a '--remote' argument to operate on a remote machine?
>> Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package
>> -m manifest.scm' can already accomplish? :-)
>
> Currently there's no ssh connection caching, so using GUIX_DAEMON_SOCKET
> can be quite slow, I normally allow 5-10 minutes for a profile. That
> works best when you can't use guix copy to send derivations over.
>
> The profile effectively already exists, it doesn't need to be computed
> on each machine.  It does seem more like deploy: take this profile, send
> it to that machine, and activate it there.  `guix deploy` already takes
> a file, the file could have a profile (or home config?) and a location
> for the profile. And a user.

That's some idea I suggested earlier (add integration form 'guix home'
configs to an operating system definition).  That has merit on its own,
but wouldn't solve Ricardo's use case, which is to deploy a profile on a
*foreign* distribution (not Guix System).

-- 
Thanks,
Maxim

Re: Better support remote deployment

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Felix Lechner <felix.lechner@lease-up.com> writes:

[...]

>> How about a 'remote-user-profile'?
>
> 'guix package' is already the command we use to create profiles; maybe
> it could accept a '--remote' argument to operate on a remote machine?
> Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package
> -m manifest.scm' can already accomplish? :-)

Doing that confuses ‘guix package’ because it’d try to perform the
effectful part (switching symlinks) locally, even though everything was
built on another machine.  (It’s also slow due to RPC round trips, as
Efraim wrote.)

But yeah, I think we could do something along these lines by isolating
the effectful bits and evaluating them remotely when needed, like we did
to achieve code sharing between ‘guix deploy’ and ‘guix system
reconfigure’.

That said, I wonder if this would really be more convenient than SSH’ing
into the target machine and running the commands right there.  Perhaps
I’m missing something about the use case?

Ludo’.

Re: Better support remote deployment

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

On Thu, Nov 16 2023, Ludovic Courtès wrote:

> I wonder if this would really be more convenient than SSH’ing
> into the target machine and running the commands right there.

Just from using 'guix deploy' I'll note that 'guix pull' is an expensive
operation, especially when running a custom version---but it would be
more appropriate for the affected parties to speak up here.

Kind regards
Felix

Re: Better support remote deployment

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

On 2023-11-16 16:23:00 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> 
> > Felix Lechner <felix.lechner@lease-up.com> writes:
> 
> [...]
> 
> >> How about a 'remote-user-profile'?
> >
> > 'guix package' is already the command we use to create profiles; maybe
> > it could accept a '--remote' argument to operate on a remote machine?
> > Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package
> > -m manifest.scm' can already accomplish? :-)
> 
> Doing that confuses ‘guix package’ because it’d try to perform the
> effectful part (switching symlinks) locally, even though everything was
> built on another machine.  (It’s also slow due to RPC round trips, as
> Efraim wrote.)
> 
> But yeah, I think we could do something along these lines by isolating
> the effectful bits and evaluating them remotely when needed, like we did
> to achieve code sharing between ‘guix deploy’ and ‘guix system
> reconfigure’.
> 
> That said, I wonder if this would really be more convenient than SSH’ing
> into the target machine and running the commands right there.  Perhaps
> I’m missing something about the use case?

I was following the debate, but maybe I have missed something, so I will put
forward my use case as well.  I have two properties I would like to have from a
"remote deploy" mechanism, and they are not satisfied by SSH-ing to the machine
and running the commands there.

1. No need for `guix pull'.  I run (a little) custom Guix, so running `guix
pull' is somewhat expensive.  I do not want to do it just to deploy something
(be it a system, or home, or profile).

2. No need to copy over the definitions.  My configurations are part of a git
repository, which I would like to keep local to just my development machine.  So
rsync-ing it over to the remote machine in order to run command there is
something I would like to avoid.

If, however, I can build a profile locally, `guix copy' it over, and *then* SSH
into the machine and somehow activate the profile (be it home or regular
profile), that would work for me.  Is that currently possible?

> 
> Ludo’.
>

Thanks,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Better support remote deployment

[Maxim Cournoyer]

Hi,

Tomas Volf <~@wolfsden.cz> writes:

[...]

> I was following the debate, but maybe I have missed something, so I will put
> forward my use case as well.  I have two properties I would like to have from a
> "remote deploy" mechanism, and they are not satisfied by SSH-ing to the machine
> and running the commands there.
>
> 1. No need for `guix pull'.  I run (a little) custom Guix, so running `guix
> pull' is somewhat expensive.  I do not want to do it just to deploy something
> (be it a system, or home, or profile).
>
> 2. No need to copy over the definitions.  My configurations are part of a git
> repository, which I would like to keep local to just my development machine.  So
> rsync-ing it over to the remote machine in order to run command there is
> something I would like to avoid.
>
> If, however, I can build a profile locally, `guix copy' it over, and *then* SSH
> into the machine and somehow activate the profile (be it home or regular
> profile), that would work for me.  Is that currently possible?

That's possible if the remote machine runs Guix System and you use 'guix
deploy'.  Otherwise, if the remote machine is a foreign distribution,
you'd have to manually copy things with 'guix copy', like Ricardo has
been doing and wanting to improve here.

-- 
Thanks,
Maxim

Re: Better support remote deployment

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> That said, I wonder if this would really be more convenient than SSH’ing
> into the target machine and running the commands right there.  Perhaps
> I’m missing something about the use case?

The use case is to have a development host where packages are built and
then pushed / installed on a remote that lacks the prerequisites to
build the packages (e.g. checkout of development source repositories).

I feel it would be a good fit for “guix deploy”, which has a similar set
of assumptions but for deploying Guix System rather than mere package
profiles.

-- 
Ricardo