From: Chris Marusich <cmmarusich@gmail.com>
To: rendaw <7e9wc56emjakcm@s.rendaw.me>
Cc: help-guix@gnu.org
Subject: Re: Services and log management/monitoring
Date: Sat, 04 May 2019 00:01:10 -0700 [thread overview]
Message-ID: <8736lu66vd.fsf@gmail.com> (raw)
In-Reply-To: <bd98e3cc-e3fa-d2e2-f584-8c6cc35d8023@s.rendaw.me> (rendaw's message of "Sat, 20 Apr 2019 00:47:27 +0900")
[-- Attachment #1: Type: text/plain, Size: 3079 bytes --]
rendaw <7e9wc56emjakcm@s.rendaw.me> writes:
> I'm fairly sure that's not what it means, but if extends isn't an
> inheritance relationship and it's not a dependency relationship I'm not
> sure what it is.
In this context, when we say that a service A extends a service B, my
understanding is that we mean that A changes (customizes) something
about B. It is definitely not inheritance. And because A changes
something about B, I don't think "A depends on B" is the best way to
think about it.
For example, the guix-service-type extends the account-service-type.
The former provides the latter with a list of user and group accounts.
In this way, the guix-service-type tells the account-service-type what
users and groups the guix service needs in order to run. When you add a
service of the guix-service-type to your operating system declaration's
list of services (it's already there by default), the
account-service-type will know what users and groups are required by the
guix-service-type, and it will create them automatically. We say the
guix-service-type "extends" the account-service-type because the former
provides the latter with a list of users/groups to create.
That is what we mean by "extension". Via this "extension" mechanism, it
is possible to make cross-cutting changes that affect many different
parts of the system, without making a bunch of changes to a bunch of
services. For example, if the tor-service-type also needs to create a
user account and group in order to do its job, it can simply extend the
activation-service-type, just like the guix-service-type did. And if
something about the way we create user accounts or groups needs to
change, we can change it for all users and groups just by modifying one
place: the account-service-type.
You might be wondering: if the account-service-type is extended by user
and group accounts, how are other services extended? The answer is that
the type of object used depends on how the services are defined. The
services participating in the extension define their own contract,
within the confines of the general "extension mechanism" that Guix
provides. Many services document how they can be extended in the
manual, but some do not, and you might have to look at the source or
existing examples to figure it out, which is not so great.
Note that if you dig into the code, you will find that the term
"extension" can also refer to a specific record type called
<service-extension>, described in the "Service Reference" section of the
manual, and defined in the gnu/services.scm file. If you want to learn
more about it, I suggest reading the manual and also the source code -
specifically the 'fold-services' procedure in gnu/services.scm, which is
where the actual extension mechanism is implemented.
The manual section is helpful, but due to some word ambiguities, it is a
little difficult to follow the first time through. Some diagrams could
help a lot in explaining the concepts. I hope this email helped a
little.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-05-04 7:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-14 18:12 Services and log management/monitoring rendaw
2019-04-17 21:20 ` Ludovic Courtès
2019-04-18 15:11 ` rendaw
2019-04-19 12:09 ` Ludovic Courtès
2019-04-19 15:47 ` rendaw
2019-05-04 7:01 ` Chris Marusich [this message]
2019-05-04 8:01 ` rendaw
2019-05-04 8:24 ` Chris Marusich
2019-05-04 8:32 ` rendaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736lu66vd.fsf@gmail.com \
--to=cmmarusich@gmail.com \
--cc=7e9wc56emjakcm@s.rendaw.me \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).