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

[Flavio Leitner]

On Sun, 28 Feb 2016 19:36:12 -0500
Mark Mielke <mark.mielke at gmail.com> wrote:

> On Fri, Feb 5, 2016 at 7:48 AM, Flavio Leitner <fbl at redhat.com> wrote:
> 
> > On Fri, 5 Feb 2016 02:20:06 -0500
> > Mark Mielke <mark.mielke at gmail.com> wrote:  
> > > 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.
> >  
> 
> Hi Flavio:
> 
> I tried with OVS 2.5.0 now that it is out, as it contains one the patches
> that makes this issue less severe. The current behaviour is acceptable in
> my use case,

Glad to know that.

> but could still be a problem in somebody else's use case. In
> particular, I think if the bond were to be re-configured, it may fail to
> properly take as a result of this remaining problem? Is this something you
> are still looking at? If you have a patch, I would be happy to try it?

Yes, it's on my queue yet.

We also have issues to configure DPDK datapath with the current systemd
services that we would require to configure and then restart the service
which doesn't sound user friendly.

It is not possible to do hot upgrade AFAIK, so that would need to be
resolved with systemd services at some point too.

NetworkManager might support OVS in the near future so we wouldn't need
to use the old 'network' sysv script to start and configure OVS interfaces.
That might change things too.

If someone didn't get on that first, I will appreciate if you can evaluate
any fixes I can come up.

-- 
fbl