[ovs-dev] [PATCH 2/2] fedora: Handle upgrades from rhel package.

[Aaron Conole]

Guru Shetty <guru at ovn.org> writes:

> On Fri, 3 May 2019 at 11:36, Aaron Conole <aconole at redhat.com> wrote:
>
>  Gurucharan Shetty <guru at ovn.org> writes:
>
>  > Currently we have rhel/openvswitch.spec.in that provides
>  > sysv scripts. The fedora package provides systemd scripts.
>  > If one upgrades openvswitch package from sysv to systemd,
>  > you will end up in a situation where old OVS daemons are
>  > running, but systemd does not know about it.  One "restart"
>  > is needed for systemd to see the old daemons. Another "restart"
>  > or "force-reload-kmod" is needed to actually use the new
>  > daemons.
>
>  Is this true?  I thought the restart would actually run the restart
>  action and that would spawn new instances of the daemons.  It seems like
>  a strange behavior.
>
> systemd openvswitch scripts when installed, hasn't been started yet in its history. So they do not know that
> any daemon has been started. So a "stop" will not stop old daemons.

The restart does, though - right?  IIRC, the ExecStop= will be called
and terminate the old daemons first.  I just want to make sure that it's
documented if process will be terminated (via the ExecStop= action) so
that any audit log can be explained.  As it is written, the behavior
isn't clear whether the untracked daemons are stopped.

>  > This commit, just takes care of the first restart. The "real"
>  > restart/force-reload-kmod will still have to be done outside
>  > the package installation.
>  >
>  > Signed-off-by: Gurucharan Shetty <guru at ovn.org>
>  > ---
>
>  I'm still not clear on the reasoning to only do the 'restart' on
>  upgrade from the sysv style.  If we're going through the trouble to
>  auto-enable it seems confusing that the service gets enabled but not
>  started, but only sometimes.  Maybe it's best that if this autoenable
>  flag is set, the daemons are also spawned.
>
> The "restart" being done here is only to make systemd aware of old daemons. The old rhel rpm did not
> restart/force-reload-kmod old daemons either. 
> So this just brings fedora rpm to parity with rhel rpm. There is pre-built infrastructure that handle restart vs
> force-reload-kmod for rhel based openvswitch rpms. If we respawn daemons, it will cause them to get
> confused.

I think the idea is to bring RHEL to match Fedora, though.  Not the
other way around.  Fedora is upstream for RHEL.

I still don't understand why on upgrade we will always enable ovs (even
if the user didn't want it), but not also always start it.  After all, a
system reboot will cause it to start.  Does it make sense to skip the
reboot step and just allow ovs to start?

>  >  rhel/openvswitch-fedora.spec.in | 14 ++++++++++++++
>  >  1 file changed, 14 insertions(+)
>  >
>  > diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
>  > index e8165f9..d41d11c 100644
>  > --- a/rhel/openvswitch-fedora.spec.in
>  > +++ b/rhel/openvswitch-fedora.spec.in
>  > @@ -364,6 +364,12 @@ getent passwd openvswitch >/dev/null || \
>  >      usermod -a -G hugetlbfs openvswitch
>  >  %endif
>  >  %endif
>  > +
>  > +%if %{with autoenable}
>  > +    if [ -x "/etc/init.d/openvswitch" ]; then
>  > +        touch %{_tmppath}/ovs-upgrade-from-sysv
>  > +    fi
>  > +%endif
>  >  exit 0
>  >  
>  >  %post
>  > @@ -397,6 +403,14 @@ fi
>  >  %if %{with autoenable}
>  >      systemctl daemon-reload
>  >      systemctl enable openvswitch
>  > +    # Handle upgrades to this package from the OVS repo's rhel packages.
>  > +    # One "restart" is needed for newer systemd files to see the old running
>  > +    # daemons. Another "restart" (outside the package postinst script) is
>  > +    # needed to actually run new daemons.
>  > +    if [ -e "%{_tmppath}/ovs-upgrade-from-sysv" ]; then
>  > +        systemctl restart openvswitch
>  > +        rm "%{_tmppath}/ovs-upgrade-from-sysv"
>  > +    fi
>  >  %endif
>  >  
>  >  %post selinux-policy