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

[Flavio Leitner]

On Fri, 5 Feb 2016 02:20:06 -0500
Mark Mielke <mark.mielke at gmail.com> wrote:

> 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.

OK, now I see what you're saying.

[...]
> > 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.

Correct.  Now that I see the real issue I can look more into it. 


> 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.

Yes, the idea is to enforce the ifcfgs on every boot to make sure it
is in a known and update state. 

Thanks,
-- 
fbl