From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id ECCE2138747 for ; Tue, 29 Jan 2013 19:50:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3A39C21C07C; Tue, 29 Jan 2013 19:49:08 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9FD6021C06C for ; Tue, 29 Jan 2013 19:49:06 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 10so691081ied.30 for ; Tue, 29 Jan 2013 11:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=c5h/RsxwExRjKCosH/oCBOvBj5zAlCgx6Z4+w4nfH+s=; b=n0AAN+XjHWtq1SsXr7F+aM4Ivduxu2QMYwVa5jO3cN7nuByABiBVT+VIG39GOOYUrB jy1m8gFf0MiVRKzL496lEq06oYVO9RrtZVPxDVfYXrfRYmBbXglWDv7L5tI5Psz6wzTy +vBiGbqHWj1lg7f7tZ6KILo371DVc1XiVcfpO1oHPhC9NGLb7YT6J3cuuofA9FukQ3em GIOIgWLhiS7/JtbMKiXoABdVzuAC4M5bqZLWQLy0Pj4htsyTJrDVGK6iOsvJXFDV+B04 KXlQ6n551aEzbPvbWyp8/4EF3YeC52HpMXBy7MizGwAlw8G10ADcRdjFk2mhUIeiMiN5 Xt2Q== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.187.197 with SMTP id fu5mr1554754igc.95.1359488945735; Tue, 29 Jan 2013 11:49:05 -0800 (PST) Received: by 10.64.25.111 with HTTP; Tue, 29 Jan 2013 11:49:05 -0800 (PST) In-Reply-To: <510823FF.8080007@xunil.at> References: <5106CB02.9040709@xunil.at> <5106D0B4.2040004@xunil.at> <5106E8B0.2060909@xunil.at> <5106F25A.2040203@xunil.at> <5107F9A1.2010205@xunil.at> <510823FF.8080007@xunil.at> Date: Tue, 29 Jan 2013 13:49:05 -0600 Message-ID: Subject: Re: [gentoo-user] *draft* for setting up network bridge with systemd (for qemu/kvm) From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 40936982-5d67-4112-9555-7ff4a273e050 X-Archives-Hash: 486db55bcbbd1d5e6b29fcc9d666708c On Tue, Jan 29, 2013 at 1:33 PM, Stefan G. Weichinger wrot= e: > Am 29.01.2013 20:23, schrieb Canek Pel=C3=A1ez Vald=C3=A9s: > >> 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=3D 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=3Doneshot unit files, or heck, even put everything in a single ExecStart=3D( 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. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico