Re: 01/01: hydra: services: Fix Cuirass configuration.

Re: 01/01: hydra: services: Fix Cuirass configuration.

[Ludovic Courtès]

Howdy Clément,

clement@lassieur.org (ClXment Lassieur) skribis:

> commit 641b9750c30cd8275765aaa6457aea961224f928
> Author: Clément Lassieur <clement@lassieur.org>
> Date:   Fri Jul 20 20:10:28 2018 +0200
>
>     hydra: services: Fix Cuirass configuration.
>     
>     * hydra/modules/sysadmin/services.scm (guix-input): Take a NAME argument.
>     (cuirass-specs): Use the correct input names.  Rename '#:proc-arguments' to
>     '#:proc-args'.  Add specifications for the "staging" and "core-updates"
>     branches.  Add missing '#:load-path-inputs' and '#:package-path-inputs'
>     fields.
> ---
>  hydra/modules/sysadmin/services.scm | 35 ++++++++++++++++++++++++++---------

Thanks a lot for fixing it!  Cuirass is back up and running now on
berlin.

One question: could we have a single “guix” input corresponding to
https://git…/guix.git for the master branch?  I suppose that should work
in theory?

Anyway the database migration went smoothly and the new schema looks
much better.  Thank you!

Ludo’.

Re: 01/01: hydra: services: Fix Cuirass configuration.

[Clément Lassieur]

Heya :-)

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

> Thanks a lot for fixing it!  Cuirass is back up and running now on
> berlin.

Yay!

One note though: Cuirass reads the config once, and only adds the
specifications whose name isn't already in the database.  So it would
have worked if you had used '() as a specification list, because the
database was in a consistent state (thanks to the upgrade).

The four specifications I added are totally useless, except for their
names, and the fact that they describe the database.  What I mean is
that if you change them it won't have any effect.  But if you change
their name, Cuirass will think they are new and try to add them to the
database.

This behaviour is terrible, because it means the configuration is non
deterministic.  It would be great to add a mechanism that detects
specification changes, and updates the database accordingly.  But I'm
not sure it's feasible.  Another solution would be to edit the database
through a web interface, à la hydra :-), but that would require a lot of
work.

> One question: could we have a single “guix” input corresponding to
> https://git…/guix.git for the master branch?  I suppose that should work
> in theory?

The inputs can all be named "guix", if that's what you mean.  Actually,
they can all be named the way you want, except the 'guix-modular' ones
that can only be named "guix" or "guix-modular"[1].  I think we should
add an ad-hoc 'key' field to avoid that restriction.  That 'key' field
would be the key used by the evaluator to access the 'guix-checkout'.

As for allowing the same input to be used by several specifications
(that is, a N - N relationship between the Inputs and the Specifications
tables), it is possible, but it would require deep changes: each input
would need to have a associated stamp in the database, and when the
input changes, the evaluation of all its specs would need to be
triggered.  It would be more efficient though, because it would reduce
the number of 'git pull'.

I chose to implement a N - 1 relationship between Inputs and
Specifications because that's how Hydra does, it requires less code
changes, and in most cases several specifications won't use the exact
same inputs.  But we can definitely improve it if you think it's worth
it!

> Anyway the database migration went smoothly and the new schema looks
> much better.  Thank you!

HTH!
Clément

[1]: https://git.savannah.gnu.org/cgit/guix.git/tree/build-aux/hydra/guix-modular.scm#n66

Re: 01/01: hydra: services: Fix Cuirass configuration.

[Ludovic Courtès]

Hey!

Clément Lassieur <clement@lassieur.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Thanks a lot for fixing it!  Cuirass is back up and running now on
>> berlin.
>
> Yay!
>
> One note though: Cuirass reads the config once, and only adds the
> specifications whose name isn't already in the database.  So it would
> have worked if you had used '() as a specification list, because the
> database was in a consistent state (thanks to the upgrade).
>
> The four specifications I added are totally useless, except for their
> names, and the fact that they describe the database.  What I mean is
> that if you change them it won't have any effect.  But if you change
> their name, Cuirass will think they are new and try to add them to the
> database.

Yeah I know, terrible.

> This behaviour is terrible, because it means the configuration is non
> deterministic.  It would be great to add a mechanism that detects
> specification changes, and updates the database accordingly.  But I'm
> not sure it's feasible.  Another solution would be to edit the database
> through a web interface, à la hydra :-), but that would require a lot of
> work.

In practice I have to admit that I add, remove, or modify specs through
the sqlite3 command line, and that’s okayish (did you know that SQL was
initially designed to be *the* user interface to the database? :-)).

Another approach would be to have part of our database available in Git
instead of in an actual database.  So Cuirass would pull its specs from
a Git repo and that’s it.  That’s less work than writing an HTTP
interface, and that’s more flexible/convenient.

>> One question: could we have a single “guix” input corresponding to
>> https://git…/guix.git for the master branch?  I suppose that should work
>> in theory?
>
> The inputs can all be named "guix", if that's what you mean.  Actually,
> they can all be named the way you want, except the 'guix-modular' ones
> that can only be named "guix" or "guix-modular"[1].  I think we should
> add an ad-hoc 'key' field to avoid that restriction.  That 'key' field
> would be the key used by the evaluator to access the 'guix-checkout'.
>
> As for allowing the same input to be used by several specifications
> (that is, a N - N relationship between the Inputs and the Specifications
> tables), it is possible, but it would require deep changes: each input
> would need to have a associated stamp in the database, and when the
> input changes, the evaluation of all its specs would need to be
> triggered.  It would be more efficient though, because it would reduce
> the number of 'git pull'.
>
> I chose to implement a N - 1 relationship between Inputs and
> Specifications because that's how Hydra does, it requires less code
> changes, and in most cases several specifications won't use the exact
> same inputs.  But we can definitely improve it if you think it's worth
> it!

OK.  Well that’s good enough for now!

Thanks for explaining!

Ludo’.