[arch-projects] [netcfg] [PATCH 3/3] systemd: Replace netcfg.service with a generator in order to get proper dependencies

[Thomas Bächler]

Am 29.10.2012 21:31, schrieb Jouke Witteveen:
> On Thu, Oct 25, 2012 at 11:53 PM, Thomas Bächler <thomas at archlinux.org> wrote:
>> Until now, netcfg might fail to start because it is started too early (this actually
>> happened to me quite regularly). To fix this, we need to make systemd aware of the
>> dependencies of a profile.
>>
>> This commit adds a systemd generator that creates profiles with the names
>>    netcfg-profile-$PROFILE.service
>> on boot. The ugly part: You cannot permanently enable such a profile, as it is
>> generated during boot. To enable it, put it in NETWORKS=() - it will always be
>> loaded, unless netcfg-profiles.target is masked. The old netcfg.service has
>> been removed. This scheme does not support NETWORKS=(last) anymore, since we
>> cannot determine which units were manually started or stopped before.
>>
>> If you add a new profile, you need to reload the systemd configuration so the
>> service file shows up. We should encourage people to use systemctl to start
>> and stop their profiles instead of netcfg.
>>
>> While this scheme is less intuitive than netcfg at profilename.service, it
>> is the only way to provide proper dependencies during boot.
>>
>> A note on backgrounding: All netcfg profiles are now started in parallel,
>> so backgrounding is unnecessary. However, due to the correct dependencies
>> in the units, everything should work fine.
>>
>> Due to a bug in systemd's dependency resolution with devices, this patch
>> requires systemd v195 to work.
> 
> This patch (and all the related ones) might be the end of netcfg.
> There are a few reasons for which I don't like to merge them.

I strongly disagree! In fact, they will keep netcfg alive.

> This will make it very difficult to maintain dual initscripts and
> systemd compatibility. For instance, in the NETWORKS array, it is
> possible to specify simple dependency relations between profiles. The
> new approach introduces a new, systemd-specific DEPENDS array for
> this.

They're not "simple depencies", they're orderings of profiles. I agree
that the systemd-only DEPENDS option confusing considering initscripts
don't have it, but it is the right direction to go.

> At the same time, systemd is basically a topological sorting
> mechanism, ie a dependency resolver. We inherently duplicate stuff
> here.

We don't duplicate anything. We use systemd to do the work for us. We
allow systemd to properly resolve conflicts and dependencies.

> The proposed setup is quite complex.

It is not! When you look at it, it only translates the information from
our profiles to systemd units.

> I feel it is likely possible to
> do netcfg's job in a systemd empowered way and I also feel that the
> proposed way is not the proper way of doing that. Therefore I suggest
> to start a new project for profile based network management as we have
> done with netcfg, but tailored to systemd. Let's call it netctl.

First of all, starting a new project is a bad idea. We can have proper
support NOW and improve that over time. Rewriting is a bad idea,
transitioning is the right way. If you start something new, it'll take
months before it is in a working state and more months until it matches
netcfg's functionality. We can't live without a working networking
solution for that long.

In the end, whatever you do, you'll end up using a generator like I did,
because systemd cannot hold the networking information we need.

> My goal for netctl would be to learn from netcfg experiences. No more
> 'menu' or 'last' on places where profile names are supposed to be put,
> no more connection types without interfaces, no more incomprehensible
> execution trails (there can be a lot of recursion, especially in calls
> to the ethernet connection code).

These are all things we can change in netcfg now, instead of starting a
new project.

> I would also like to use systemd's
> power as much as possible.

Me too.

> This might mean to hope for Lennarts
> cooperation in at least two places:
> 1) write a proper ifplugd service (possibly ifplugd needs to be altered),

He won't work on ifplugd, he considers it obsolete.

> 2) support variables from EnvironmentFile in the BindsTo/After part of
> a unit (so that we can put our interfaces there).

Won't happen. Environment file is considered an ugly hack.

> There will be (at least) two types of service files: one for simple
> wired/wireless connections with a fixed interface, one for connections
> that generate an interface (for example: bond connections). The latter
> will be the difficult kind. In any case, I would like the profile
> files to be of the kind systemd accepts as environment files, but very
> similar (in some cases even compatible) to those of netcfg.

Environment files are not the way to go. They are considered a hack and
we won't get support for them anywhere but in Exec*=.

> In short, netctl should be a purified netcfg, depending on systemd.[1]
> We might loose a few features of netcfg, but we would gain a lot of
> simplicity and ease of use (for those used to systemd).

I agree we should improve and restructure netcfg's code - but the only
way this will happen is by having a generator like the one I started.

> As for the problem addressed by the presented patch: we could put
> After=udev-settle.service
> in the services.

Never. udev-settle is the worst idea and I don't use any service that
needs it - and I will not support adding it anywhere.

> A user can then prevent the case that netcfg is
> started before there interfaces appear by enabling the udev-settle
> service.
> 
> Any comments on this wild plan?

As I said: Make a transition from old to new, in small steps and catch
bugs on the way. Rewriting is not the answer.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20121029/ae38c4de/attachment-0001.asc>