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

[ludo@gnu.org (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’.