[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Services and log management/monitoring
Re: Services and log management/monitoring
Sat, 4 May 2019 17:01:45 +0900
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
On 5/4/19 4:01 PM, Chris Marusich wrote:
> rendaw <address@hidden> 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.
Wow, thanks for taking the time to write this up! I believe that's a
much clearer explanation - I actually figured it out by reading the
source code extensively, but I thought this thread had been abandoned.
I've written up something similar here:
I think it would be great to have this information in the
documentation! I'd also elaborate on what actually happens in the end
("If every service just extends other services, what does the root
service do?"), how stuff actually runs (since operating systems are
processes and not data after all -> I think the answer is that the boot
service, activation service, and shepherd service all run processes but
that leads to a lot of other obvious questions: what's the difference
between the boot and activation services - or what do each do and what
makes them suitable for those tasks, what order are processes started in
each of them, how does guix deal with existing files created by
activation processes when reconfiguring the system, etc), what is a
service vs a service type, and an explanation of the folding process and
how it relates to a service type definition.
> The manual section is helpful
I strongly believe the manual section is not helpful to anyone who
doesn't already know how Guix works. The explanation of _everything_
related to services hinges on the word "extend" - and it's never
defined! It's a novel definition in this context, it's not a matter of
ambiguity. The definition of extends here is strongly tied to the
folding procedure so both of those need to be in the documentation for a
reader to gather an understanding of what's being discussed.
Reading the source code is a colossal hurdle for users, and especially
considering that this is a core service and the actual behavior is
influenced by and influences hundreds of other pieces of code (unlike
things like `(shell ...)` which get passed through to the end system
interacting with relatively few other processes). Knowing the big
picture of how Guix works as a system, how components interact under the
hood, etc. is critical because it lets you make an informed decision
when you want to create a new service, it gives you hints on how to read
arcane build errors, when the resulting system doesn't work it lets you
know where things could be going wrong, and if you want to read more
about a particular subject you know what topics/search terms/articles
could be relevant.
I hope this doesn't come off too aggressive. I view myself as a user at
this point and really want Guix to take off. I spent the greater part
of three weeks trying how to figure out how to get my new (fairly
simple) Guix system running. IMO if it takes most users (who want to do
more than install X and then run ./x) three full-time weeks, breathing
Guile, and source code diving to reach a usable point then Guix will
never be able to achieve critical mass.