Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm)

[Canek Peláez Valdés]

On Tue, Jan 29, 2013 at 1:33 PM, Stefan G. Weichinger <lists@×××××.at> wrote:
> Am 29.01.2013 20:23, schrieb Canek Peláez Valdés:
>
>> I really believe the most important thing abount systemd unit files is
>> that they are small and simple. You can also check the exit status
>> from each command in the script, or even better, you can do a test
>> after all the commands are done to check the status of the bridge and
>> see if it was created correctly.
>>
>> None of this belongs in the unit service, IMO. Otherwise, you end
>> creating ssh keys and user groups in unit files, and none of this
>> belongs there. Clear separation between the services and the init
>> system.
>>
>> But of course, as I said to Stefan, if it works it works.
>
> As I mentioned it is a first version ... just to make things work.
>
> If all the services/daemons/stuff work with systemd then I am able to
> use it as default init-system here and I don't have switch back to
> openrc to do my work (for example when I need KVM-based virtualization
> on my workstation).
>
> I agree with your argument that unitfiles should be as small and simple
> as possible, on the other hand those commands just get pulled in from
> elsewhere: the complexity is just moved out of sight, right?

I don't think so, no. It's like the Model/View/Controller design
pattern: The code does the same (sometimes it even grows in
complexity), so we are just moving stuff around, right? No, we are
clearly splitting the information we have, and how do we present it to
the user, with a set of well defined interfaces in the control module
on how to update the second using the first.

Or with a webapp; we can mix the information with the presentation,
why to split them? We are just moving it out of sight, right? No,
again, we split the information on a web page from how do we present
it to the user, so when something breaks, we know where it did.

Imagine that systemd had a bug in its ExecStart= directive. Perhaps it
works for the first 5 commands, but it fails in the 6th. Then you
would have been stuck for hours (perhaps days) trying to debug your
unit file, when it had nothing wrong, really. If instead you put all
the logic pertaining to your service in a script, or executable, or
whatever, but *clearly separated* from systemd, and you got it
working, and it doesn't work with systemd, then you *know* where the
problem is.

I really believe the proper solution is to clearly separate this
stuff. You can abuse the Type=oneshot unit files, or heck, even put
everything in a single ExecStart=( command1; command2; command3; ...;
commandN). That doesn't mean you should.

Just my 0.02 cents.

> I did quite some research to find more elegant solutions ... so far I
> wasn't successful.

I find more elegant to clearly split the commands your service uses
from the unit file.

> For now I am happy to get my itches scratched ... I am absolutely ready
> to learn and improve things. Sharing my first steps here maybe helps to
> motivate other gentoo-users to give systemd a try?

I would not bet on that ;) too much resistance. However it is
certainly getting better and better: the LWN article on The Biggest
Myths about systemd had an overwhelmingly majority of comments
positive to systemd, and just a handful of negative comments:

http://lwn.net/Articles/534210/#Comments

But that is in LWN; Gentoo is way behind, I believe.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México