GNU bug report logs - #43155
[PATCH] hydra//build-machines: Update childhurd-net-options for secret-service.

Previous Next

Full log

Message #17 received at 43155 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43155 <at> debbugs.gnu.org
Subject: Re: [bug#43155] [PATCH] hydra//build-machines: Update
 childhurd-net-options for secret-service.
Date: Thu, 03 Sep 2020 12:19:49 +0200

Ludovic Courtès writes:

Hi,

> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>> Ludovic Courtès writes:
>> Yes, we can add something like
>>
>>       (secret-root (format #f "/etc/childhurd/~a" id))
>>
>> to the
>>
>>     (service hurd-vm-service-type
>>         (hurd-vm-configuration
>>           ...
>
> Sounds good.
>
>> (i'm a bit curious, though, why we would want to differentiate between
>> childhurds, they can be all identical?)
>
> Well, dunno if it really matters for our specific use case, but it seems
> “cleaner” to me to give each childhurd its identity.  OTOH, these are
> VMs and they run on the same physical machine, so…

Right...

>>> (I realize that the current code will silently keep going if we forget
>>> to put the secret files in place; IOW, the service config doesn’t show
>>> the files we intended to push as secrets.  Oh well, we’ll see that
>>> later.)
>>
>> Yes, I guess that's a feature -- "you" can start it once, then do
>> something like
>>
>>     mkdir -p /etc/childhurd/etc
>>     scp -r childhurd:/etc/guix /etc/childhurd/etc
>>     scp -r childhurd:/etc/ssh /etc/childhurd/etc
>
> Right, that can be convenient.  OTOH, from the perspective of having
> declarative OS configs, it’s not great because this aspect of the config
> are left out.  But maybe that’s an issue we can have if/when we
> generalize ‘secret-service-type’.

Ah, I see -- it could lead to "silent" failure/differences if
/etc/childhurd somehow disappears -- isn't re-created upon new install.
It makes sense to at least be less than silent, "fail early" is always
good.

>>>> (I guess we then also need to add a cuirass jobs for the Hurd?)
>>>
>>> Yes, or maybe just change ‘systems’ in the Cuirass specs for
>>> ‘guix-master’, but then it’ll try to build everything for GNU/Hurd,
>>> which doesn’t sound like a great idea for now.
>>
>> I agree, not much sense in that yet.
>>
>>> Perhaps we can simply add a separate jobset pulling from ‘master’ but
>>> building only for i586-gnu and only the “core” package set?
>>
>> Hmm, why can't I find the definition of "core"?.  Anyway, It would be a
>> great first step to build (everything needef for) "hello", after that we
>> want to have/try "guile-3.0" and possibly "guix".
>
> Sure.  The “core” subset is defined in (gnu ci).

As discussed on IRC that could get an update.  Would you like to do
that, seems like an easy edit but I'm a bit unsure about the choices and
consequences there?

I think once the offloading works we'll want to try building guix; and
it could be nice if as many dependencies that "just happen to build" are
actually available.  It's waay to early to try to build everything but
we may want something in between.  Or add "guix" to core-packages,
maybe?  Just wondering out loud here...

Janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.