[bug#36872,2/2] remote: Remove '--system' argument.

* gnu/services.scm (activation-script): Return a <program-file> rather
than a <scheme-file>.
* gnu/deploy.scm (guix-deploy): Remove handling for '--system'.
(show-help): Remove documentation for '--system'.
(%default-options): Remove default setting for 'system'.
---
 gnu/services.scm        | 56 ++++++++++++++++++++---------------------
 guix/scripts/deploy.scm |  8 ++----
 2 files changed, 30 insertions(+), 34 deletions(-)

I'm still wondering whether asking the remote machine what its
architecture is won't turn out to be fragile in some way, though I'm not
sure how to articulate how that would be yet.  It seems like a weird
side effect to apply before doing the build.  (What if we want to build
derivations when we don't actually have a machine up and running yet?
Etc, etc.)

But you and Dave seem to think it's the right thing to do, so I'm going
to assume that you both know what to do better than I do at this point.

At any rate, the patch looks fine; once it's rebased on top of master
I'm ok with pushing it if there are no objections.

Jakob L. Kreuze writes:

> * gnu/services.scm (activation-script): Return a <program-file> rather
> than a <scheme-file>.
> * gnu/deploy.scm (guix-deploy): Remove handling for '--system'.
> (show-help): Remove documentation for '--system'.
> (%default-options): Remove default setting for 'system'.
> ---
>  gnu/services.scm        | 56 ++++++++++++++++++++---------------------
>  guix/scripts/deploy.scm |  8 ++----
>  2 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/gnu/services.scm b/gnu/services.scm
> index 7de78105ff..6ee05d4580 100644
> --- a/gnu/services.scm
> +++ b/gnu/services.scm
> @@ -430,34 +430,34 @@ ACTIVATION-SCRIPT-TYPE."
>  (define (activation-script gexps)
>    "Return the system's activation script, which evaluates GEXPS."
>    (define actions
> -    (map (cut scheme-file "activate-service" <>) gexps))
> -
> -  (scheme-file "activate"
> -               (with-imported-modules (source-module-closure
> -                                       '((gnu build activation)
> -                                         (guix build utils)))
> -                 #~(begin
> -                     (use-modules (gnu build activation)
> -                                  (guix build utils))
> -
> -                     ;; Make sure the user accounting database exists.  If it
> -                     ;; does not exist, 'setutxent' does not create it and
> -                     ;; thus there is no accounting at all.
> -                     (close-port (open-file "/var/run/utmpx" "a0"))
> -
> -                     ;; Same for 'wtmp', which is populated by mingetty et
> -                     ;; al.
> -                     (mkdir-p "/var/log")
> -                     (close-port (open-file "/var/log/wtmp" "a0"))
> -
> -                     ;; Set up /run/current-system.  Among other things this
> -                     ;; sets up locales, which the activation snippets
> -                     ;; executed below may expect.
> -                     (activate-current-system)
> -
> -                     ;; Run the services' activation snippets.
> -                     ;; TODO: Use 'load-compiled'.
> -                     (for-each primitive-load '#$actions)))))
> +    (map (cut program-file "activate-service.scm" <>) gexps))
> +
> +  (program-file "activate.scm"
> +                (with-imported-modules (source-module-closure
> +                                        '((gnu build activation)
> +                                          (guix build utils)))
> +                  #~(begin
> +                      (use-modules (gnu build activation)
> +                                   (guix build utils))
> +
> +                      ;; Make sure the user accounting database exists.  If it
> +                      ;; does not exist, 'setutxent' does not create it and
> +                      ;; thus there is no accounting at all.
> +                      (close-port (open-file "/var/run/utmpx" "a0"))
> +
> +                      ;; Same for 'wtmp', which is populated by mingetty et
> +                      ;; al.
> +                      (mkdir-p "/var/log")
> +                      (close-port (open-file "/var/log/wtmp" "a0"))
> +
> +                      ;; Set up /run/current-system.  Among other things this
> +                      ;; sets up locales, which the activation snippets
> +                      ;; executed below may expect.
> +                      (activate-current-system)
> +
> +                      ;; Run the services' activation snippets.
> +                      ;; TODO: Use 'load-compiled'.
> +                      (for-each primitive-load '#$actions)))))
>  
>  (define (gexps->activation-gexp gexps)
>    "Return a gexp that runs the activation script containing GEXPS."
> diff --git a/guix/scripts/deploy.scm b/guix/scripts/deploy.scm
> index 8eeb9ae7a1..bc1d93a93a 100644
> --- a/guix/scripts/deploy.scm
> +++ b/guix/scripts/deploy.scm
> @@ -44,8 +44,6 @@
>  (define (show-help)
>    (display (G_ "Usage: guix deploy [OPTION] FILE...
>  Perform the deployment specified by FILE.\n"))
> -  (display (G_ "
> -  -s, --system=SYSTEM    attempt to build for SYSTEM--e.g., \"i686-linux\""))
>    (show-build-options-help)
>    (newline)
>    (display (G_ "
> @@ -67,8 +65,7 @@ Perform the deployment specified by FILE.\n"))
>           %standard-build-options))
>  
>  (define %default-options
> -  `((system . ,(%current-system))
> -    (substitutes? . #t)
> +  `((substitutes? . #t)
>      (build-hook? . #t)
>      (graft? . #t)
>      (debug . 0)
> @@ -91,8 +88,7 @@ Perform the deployment specified by FILE.\n"))
>        (for-each (lambda (machine)
>                    (info (G_ "deploying to ~a...~%")
>                          (machine-display-name machine))
> -                  (parameterize ((%current-system (assq-ref opts 'system))
> -                                 (%graft? (assq-ref opts 'graft?)))
> +                  (parameterize ((%graft? (assq-ref opts 'graft?)))
>                      (guard (c ((message-condition? c)
>                                 (report-error (G_ "failed to deploy ~a: '~a'~%")
>                                               (machine-display-name machine)

Hey Chris!

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> I'm still wondering whether asking the remote machine what its
> architecture is won't turn out to be fragile in some way, though I'm not
> sure how to articulate how that would be yet.  It seems like a weird
> side effect to apply before doing the build.  (What if we want to build
> derivations when we don't actually have a machine up and running yet?
> Etc, etc.)

I agree that it isn't the purest solution, but my thinking is that
'remote-eval' is meant to be effectful anyway. As for the situation
where we build derivations for a machine that isn't running yet: I think
we can cross that bridge when we get to it -- 'guix deploy' doesn't have
the feature at the moment.

Regards,
Jakob

Jakob L. Kreuze writes:

> Hey Chris!
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> I'm still wondering whether asking the remote machine what its
>> architecture is won't turn out to be fragile in some way, though I'm not
>> sure how to articulate how that would be yet.  It seems like a weird
>> side effect to apply before doing the build.  (What if we want to build
>> derivations when we don't actually have a machine up and running yet?
>> Etc, etc.)
>
> I agree that it isn't the purest solution, but my thinking is that
> 'remote-eval' is meant to be effectful anyway. As for the situation
> where we build derivations for a machine that isn't running yet: I think
> we can cross that bridge when we get to it -- 'guix deploy' doesn't have
> the feature at the moment.
>
> Regards,
> Jakob

I thought about it more between yesterday and today, and it continues to
seem strange to me that we're doing "probing" here.  We don't probe to
guess where Guix is currently installed or etc to specify disks.  I
guess that's not the same thing, but...

Here's the concern: imagine that we want to be able to up-front do
something like "guix system build" before we even start spinning up
servers.  Does this block that direction?

Dave, your input appreciated on this one.

I'm not sure I want to block the patch series with my hand wringing, but
I do want to make sure we give it appropriate consideration.

 - Chris

Hi,

On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber
<cwebber@dustycloud.org> wrote:
>
> I thought about it more between yesterday and today, and it continues to
> seem strange to me that we're doing "probing" here.  We don't probe to
> guess where Guix is currently installed or etc to specify disks.  I
> guess that's not the same thing, but...
>
> Here's the concern: imagine that we want to be able to up-front do
> something like "guix system build" before we even start spinning up
> servers.  Does this block that direction?

This is a good point.  We want to make sure that the config file
*completely* describes the operating systems that need to be built,
therefore having to talk to a remote machine is no bueno.  The reason
I didn't want the user to have to explicitly specify the remote
system's architecture is for usability.  I wanted 'guix deploy' to
just DTRT like guix already does when you run `guix system
reconfigure` or `guix build` locally where %current-system defaults to
what the local machine is running.  However, I think that providing
this information would only be a small inconvenience for the current
managed host environment type. This wouldn't be an issue at all for an
AWS environment type, for example, because the user would have to
specify which instance type they want and with that you know what the
value of %current-system should be when generating the OS derivation.
I imagine this would be the case for any cloud environment.

I think I've said this before (not sure if IRL or in an email) that we
should make it the responsibility of the environment type to determine
what the remote machine's system is.  I still think that should be the
case, but we should change the managed host type so that the user
specifies that information as a new record field rather than making
'guix deploy' probe for it.

Does this make sense?

- Dave

Hi Chris and Dave,

"Thompson, David" <dthompson2@worcester.edu> writes:

> Hi,
>
> On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber
> <cwebber@dustycloud.org> wrote:
>>
>> I thought about it more between yesterday and today, and it continues to
>> seem strange to me that we're doing "probing" here.  We don't probe to
>> guess where Guix is currently installed or etc to specify disks.  I
>> guess that's not the same thing, but...
>>
>> Here's the concern: imagine that we want to be able to up-front do
>> something like "guix system build" before we even start spinning up
>> servers.  Does this block that direction?
>
> This is a good point.  We want to make sure that the config file
> *completely* describes the operating systems that need to be built,
> therefore having to talk to a remote machine is no bueno.  The reason
> I didn't want the user to have to explicitly specify the remote
> system's architecture is for usability.  I wanted 'guix deploy' to
> just DTRT like guix already does when you run `guix system
> reconfigure` or `guix build` locally where %current-system defaults to
> what the local machine is running.  However, I think that providing
> this information would only be a small inconvenience for the current
> managed host environment type. This wouldn't be an issue at all for an
> AWS environment type, for example, because the user would have to
> specify which instance type they want and with that you know what the
> value of %current-system should be when generating the OS derivation.
> I imagine this would be the case for any cloud environment.
>
> I think I've said this before (not sure if IRL or in an email) that we
> should make it the responsibility of the environment type to determine
> what the remote machine's system is.  I still think that should be the
> case, but we should change the managed host type so that the user
> specifies that information as a new record field rather than making
> 'guix deploy' probe for it.
>
> Does this make sense?

Right. My gut feels a bit conflicted since 'remote-eval' is already
talking to the remote, but the points about building ahead of time and
having the configuration file completely specify the deployment are
strong -- perhaps the better thing to do is to add a 'system' keyword to
'remote-eval'. I'll redo this patch as a 'system' field for the
'managed-host-environment-type' configuration.

Regards,
Jakob