On Fri, 3 May 2019 at 13:05, Aaron Conole <[email protected]> wrote:
> Guru Shetty <[email protected]> writes: > > > On Fri, 3 May 2019 at 11:36, Aaron Conole <[email protected]> wrote: > > > > Gurucharan Shetty <[email protected]> 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? No. It does not. Not when you run it the first time. > 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. > To stop the untracked daemons and start the new daemons, you need to run "systemctl restart openvswitch" twice. > > > > 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 <[email protected]> > > > --- > > > > 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. > The rpms in OVS repo need to maintain some kind of compatibility if the expectation is for the user of OVS to smoothly transition from RHEL rpm to fedora rpm - the goal being to retire RHEL rpm spec file. We should ideally not tangle ourselves with semantics and make the user jump hoops to get things to work. If we have the 2 rpms behave differently, then you have a nightmarish situation of having different set of instruction manuals for different set of OVS versions. > > I still don't understand why on upgrade we will always enable ovs (even > if the user didn't want it), The user wants it. So he has passed the "--with autoenable" option while building the rpm. If he did not want it, we would not have passed 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? > > That is how RHEL rpm spec file that has been used behaved so far. It will enable openvswitch service and let the user start it (either via rebooting or simply calling the "start" script or running a "force-reload-kmod" to use the new kernel module. Fedora rpm needs to maintain that compatibility if we need to make this transition. The way we have used RHEL rpm so far is to install it (which enabled openvswitch) and then see whether we need to do a "force-reload-kmod" or a "restart" depending on the kernel module used. > > > 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 > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
