[ovs-discuss] systemd ovs-vswitchd starts too early

[Mark Mielke]

On Thu, Feb 4, 2016 at 7:49 AM, Flavio Leitner <fbl at redhat.com> wrote:
> On Wed, 3 Feb 2016 22:01:46 -0500 Mark Mielke <mark.mielke at gmail.com> wrote:
>> > We need to split the issues:  One is that enabling
>> > openvswitch.service causes it to run too soon.  I think the
>> > proposed patch should resolve that (check journalctl -xe).

>> The proposed patch doesn't seem to change anything. I checked
>> /var/log/messages and journalctl -xe. It has zero impact on the order
>> of the boot up. openvswitch-nonetwork.service still starts too soon,
>> before the physical interfaces have been probed and recognized. In
>> both cases, systemd has determined that openvswitch-nonetwork.service
>> is a dependency, and it starts it as soon as syslog.target is reached
>> (which is the constraint that openvswitch-nonetwork.service defines).
>> Adding "After=network.service" to openvswitch.service does not affect
>> when openvswitch-nonetwork.service starts as "After=network.target" is
>> already more constraining than "After=network.service"...
>
> It seems you're mixing the issues.
>
> openvswitch-nonetwork.service should not start by itself because it
> should not be enabled.  It is considered internal to OVS initialization.

I think you are misunderstanding me. I am describing not my own
thought process, but how systemd is actually implementing the systemd
service files that are used to define openvswitch-nonetwork.service
and openvswitch.service.

You stated that you believed openvswitch.service should be a no-op. It
is not. Even with your patch, it is not. By having openvswitch.service
be enabled, it is causing openvswitch-nonetwork.service to be started
as soon as systemd can schedule it, which is After=syslog.target, and
in parallel to network.service, which is what causes it to run too
early.

When it is disabled, everything works fine, because network.service
starts openvswitch-nonetwork.service on demand, after the physical
network interfaces have been probed and registered.

It is openvswitch.service which is the problem that is causing
openvswitch-nonetwork.service to start too early.

> Now there are two ways to start that service.  The important one is when
> 'network.service' is _running_ and processing ifcfg files. That is a
> loop processing ifcfgs one by one and when it finds the first ifcfg for
> an OVS port, it will start openvswitch-nonetwork.service because it
> needs the service at that point.  We didn't start earlier and we can't
> start after.

Correct. This is the "right" place for it to start, because the
physical network interfaces have been probed and registered. They
"exist" at this point, so it is safe to start
openvswitch-nonetwork.service as soon as a TYPE=OVS* interface is
specified. Because these ifcfg- files also specify their dependencies,
and because the dependencies are started first, everything works fine
this way. But it only works fine if openvswitch.service is *disabled*.

> So, it can't be after network.target and can't be after network.service.

Right.

> However, if you have interfaces added from previous boot remaining in
> the OVS DB, OVS will keep them when you start OVS daemons. So, you will
> see them on the OVS _before_ they are actually available in the system
> or brought up by network.service.

This doesn't happen unless openvswitch.service is enabled. So, while I
agree with your statement, I don't agree with your conclusion.

> The OVS initialization just fires up OVS daemons.  It doesn't configure
> any ports or bridges because historically on Fedora that is what the
> network.service does, for each ifcfg- file available.
>
> Regarding to the second issue that we need to clean stale bonding ports
> from the DB to start from scratch I can provide a patch, but let's see
> about the first issue to avoid confusions and misunderstandings.

To be clear, as I think you might be second-guessing my statements
with a presumption that I don't get it...

Problem #1, that openvswitch-nonetwork.service starts too early if
openvswitch.service is on, actually causes a real problem, with
evidence in the logs.

Problem #2, only happens for me if openvswitch-nonetwork.service
starts too early. If I turn openvswitch.service off *with or without*
your proposed alteration to After= to include network.service, then I
don't experience Problem #2.

So, from my perspective...

Problem #1 is a bug in how openvswitch.service is defined. There is a
misunderstanding here around how systemd operates, and there is no
correct patch on the table at the moment. The only fix here is to
disable openvswitch.service.

Problem #2 is mostly a work-around for Problem #1 in my case. However,
I can see how in *other* cases than mine, it could be a valuable
solution. For example, let us say that the physical interfaces for the
OVSBond changed. In this case, ifup-ovs should correctly reset the
bond to have the new configuration.


-- 
Mark Mielke <mark.mielke at gmail.com>