From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:50591) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hi6HL-0006a3-S0 for guix-patches@gnu.org; Mon, 01 Jul 2019 20:04:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hi6HF-0003fd-6C for guix-patches@gnu.org; Mon, 01 Jul 2019 20:04:09 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:37483) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hi6HC-0003f9-Kt for guix-patches@gnu.org; Mon, 01 Jul 2019 20:04:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hi6HC-0004a3-Ej for guix-patches@gnu.org; Mon, 01 Jul 2019 20:04:02 -0400 Subject: [bug#36404] [PATCH 2/5] gnu: Add machine type for deployment specifications. Resent-Message-ID: From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) References: <87o92ianbj.fsf@sdf.lonestar.org> <87imspj0ks.fsf_-_@sdf.lonestar.org> <87ef3dj0j9.fsf_-_@sdf.lonestar.org> <87a7e1j0hy.fsf_-_@sdf.lonestar.org> <87k1d4kra8.fsf@dustycloud.org> <877e93ewyj.fsf@sdf.lonestar.org> <87blyfl0jm.fsf@dustycloud.org> Date: Mon, 01 Jul 2019 20:03:15 -0400 In-Reply-To: <87blyfl0jm.fsf@dustycloud.org> (Christopher Lemmer Webber's message of "Sun, 30 Jun 2019 08:28:45 -0400") Message-ID: <87y31h9ubg.fsf@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Christopher Lemmer Webber Cc: 36404@debbugs.gnu.org --=-=-= Content-Type: text/plain Christopher Lemmer Webber 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 ) 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 :] --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl0an0MACgkQ9Qb9Fp2P 2VrPuA/+JJaQ4eqZHmOySQXfn2j/rcUphWRbVC/F3rVWbad6m3lWYl01NsOpNepi 8JOLgMbmeeWM2W6RjZjtH30etYPTwMoSGUHMI7p7lP9ImU5YMrD/ePsZc18wXM2N TClgUE6nX0R8ZMfS2iqVxxYllOkJsbR2+XiGSsofXfrHtFRwmjPJ65e4RCEmcaFC 7FQl7JCfuX/RGJdZjS2qsfHx1Fe6I03tsZdRMS9lldaY+Va7uoenK7hdav/i0NNV lwz0HwifUZrxqWHJgYDybARdMkUWuQBZlslyOg81vkbYOTD4kOtByKmO0hsI0dM8 R9IvACvn4aNDFzTjE3g7HcezjOOcDqMn/9i1tPr3Qn8DrkVoj2AdYF7uQ+pzXZkQ Lz4tgbtriEzTV/uGWpJ3lmxOoqKn2YQjuqdmc0wl0QtXNOQchFUIjVx4mWfK5EP6 cHls/yB7Rh9Iub79T/VliqSgkE2M/Q9fK8RX77aNRYoCi6aqcQ4s79eEvZXpG/Uf kJWAZqawtpd0N01d9iKtNXMAPLxJB25X4ftEkiCG/6q0/oaS0zZshJYIN8CcM62t K6CoGNCwZoS111X6yDp5qomL4XCm3jRmJHSUwamjHNhhHpIdrz+vUrdLEQjy4vxb mb0Sit8kM8dTIaOhM+f+G5/poavPUbG2Prd6os7sjxoWpzeWDgA= =c13S -----END PGP SIGNATURE----- --=-=-=--