[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#36404] [PATCH 2/5] gnu: Add machine type for deployment specificati

From: Jakob L. Kreuze
Subject: [bug#36404] [PATCH 2/5] gnu: Add machine type for deployment specifications.
Date: Mon, 01 Jul 2019 20:03:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Christopher Lemmer Webber <address@hidden> writes:

> Right now it looks like you're hard-coding dispatch into the procedure
> by doing a case analysis of what type it is, but this doesn't allow us
> to extend it.
> Here I'd look at how service-type works. Check out gnu/services.scm
> and then some examples of how services are defined in say,
> gnu/services/admin.scm or something (eg rotlog-service-type). I'm not
> saying structure it in exactly this way, but that seems to be the
> right general pattern to do extensibility in the guix'y way:
>  - Have a common outer type (eg <service-type>) which actually sets up
>    the structure of this service type
>  - Then have the actual records that are specific to the service type
>    represented as the service-value.
> Section 8.16.2 "Serivce Types and Services" and 6.16.3 "Service
> Reference" for details.
> Note that I wish there was a way to generalize the ideas behind this
> pattern rather than have it be reinvented for everything that needs
> them. This is part of why David and I turned to GOOPS in the initial
> prototype implementation; it's a lot of work figuring out how to set
> up extensibility in this way, at least for me. You might want to write
> a quick GOOPS version to understand what all the parameters are that
> are needed, then convert it to the services way of doing a general
> structure that wraps a specific structure.
> I suspect you won't need as much composability as services currently
> need, so the implementation of whatever this extensibility is is
> probably not as complicated as it is for services.
> As for how to share the ssh code, maybe just having the building-block
> procedures is good enough?
> Since all we support, so far, is this kind of ssh'ing, I don't want
> this to block the patch though. It could be that we file this as a bug
> and add a TODO above the code for the moment saying "we know this
> isn't right/ideal". However, there is some risk that this could result
> in people writing out machine configurations that later break... I
> dunno.
> Thoughts?

Ah, so you mean having the configuration as part of the environment type
rather than the machine type? I think that does make more sense... If
that is what you meant, let me know and I'll send another patch
implementing the change tomorrow. It should be an easy fix.

> If you remove it, please leave a comment noting the difference between
> this and "guix system" and why you thought it was safe to remove.  If it
> turns out to not be the case, there's a breadcrumb there to figure out
> how to add it back.

Added :]

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]