[systemd-devel] network/openvswitch dependency loop/deadlock

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 13/02/13 03:06 did gyre and gimble:
> On Tue, 12.02.13 14:07, Thomas Graf (tgraf at redhat.com) wrote:
> 
>>
>> On 02/07/2013 04:55 PM, Ian Pilcher wrote:
>>> On 02/07/2013 06:13 AM, Colin Guthrie wrote:
>>>> Also re the initscripts tweaks and the if statement proposed in the bug,
>>>> there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that
>>>> will make "service openvswitch start" pass the --ignore-dependencies
>>>> argument if it redirects to systemctl. That's likely cleaner than the if
>>>> [ -x /usr/bin/systemctl ] check. Obviously as this is arguably not the
>>>> right fix anyway, it's perhaps a moot point.
>>>
>>> Cool.
>>>
>>> So given that it is in fact "After=... network.target" (in
>>> openvswitch.service) that is causing the problem, do you see a better
>>> solution than using SYSTEMCTL_IGNORE_DEPENDENCIES?
>>>
>>> Is there any chance that this would work?
>>>
>>>   After=syslog.target
>>>   Requires=network.target
>>>
>>> (While not breaking the use case in comment #34 of the bug.)
>>>
>>> I'm very unclear on what Requires=network.target would actually mean.
>>
>> The case of Open vSwitch is a bit special because there is a chicken
>> egg problem.
>>
>> OVS bridges and ports are configured using the ovs-vsctl utility. It
>> requires the OVS daemons to be running. So naturally we want to start
>> the openvswitch unit (if it is not running yet) before we ifup any
>> OVS type interfaces.
>>
>> We also want the openvswitch unit to be started after network on boot
>> because an OVS bridge may be using a controller on the network that
>> depends on network connectivity.
>>
>> So what we did is introduce a new ifcfg key that can be used to define
>> the interface dependencies of a bridge. Let's say ovsbr0 is configured
>> to use a controller that is behind interface em1. So before bringing
>> up ovsbr0 we want to bring up em1 and after that we want to start the
>> openvswitch unit and then configure the bridge.
>>
>> So it seems what we need is a way to tell systemd to disregard the
>> network dependency if we are starting the openvswitch unit from within
>> ifup. Something like --ignore-dependency=network.target because we
>> still want it to depend on syslog.target obviously.
>>
>> I guess we could also be providing a separate units files:
>>   openvswitch-no-network.service
>>   openvswitch.service
>>
>> What is cleaner from a systemd perspective?
> 
> Well, there still is a dep loop, that is unfixed, right?
> 
> I mean, you want your service to run as part of bringing up some
> networks, but also after the network is up. So what do you want now?
> Start it after or at the same time, that's contradicting.
> 
> a) if you want to start it only after then, you should drop those
>    callouts from ifup.
> 
> b) if you want to start it as part of the network config, then you
>    should drop any reference to network.target.
> 
> To me it appears that you aren't entirely clear which way you want it,
> and try to use --ignore-dependencies as a work-around for that... But I
> really think the first step needs to be: what it's gonna be?


Is what is really needed here some kind of netdev-generator which parses
the individual ifcfg-* files and writes out netdev at eth0.service
instances (or maybe not a single netdev at .service but several for the
different kinds of interfaces?)

That way the deps can be properly parsed and ordered in the units.
Actually due to the interplay of deps it might not be possible to use
templated units here, but just generate specific, individual units (just
like mount units).

Either way, is a generator the way to go here longer term, or is there
some other plan afoot to modernise the static network configs?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/