On Sat, Oct 12, 2013 at 05:26:53PM -0400, Yaniv Bronheim wrote:
>
>
> ----- Original Message -----
> > From: "Dan Kenigsberg" <[email protected]>
> > To: "Antoni Segura Puimedon" <[email protected]>
> > Cc: "arch" <[email protected]>, "VDSM Project Development"
> > <[email protected]>
> > Sent: Thursday, October 10, 2013 11:51:30 PM
> > Subject: Re: [vdsm] Recent changes in vdsmd startup
> >
> > On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote:
> > > Is this what happened with the network functional testing? After these
> > > last changes, before the yum install of the new vdsm and the yum erase
> > > of the old I had to add the vdsm-tool libvirt reconfigure and start.
> > > Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6
> > > somehow it didn't happen).
> >
> > IMO what you've experienced is the intended change that Yaniv has
> > reported in this thread. Fresh installation of vdsm now requires
> > more-than-just `service vdsmd start`.
> >
> > I'm trying to understand our action on the unattended upgrade path.
>
> Interesting point. Thanks for raising that up, raising such issues was part
> of this mail goals
> You are right that after an upgrade we will need to restart libvirt service
> manually to start working with new configuration,
> But, AFAIK we don't force vdsmd restart after upgrading.
Actually, we have to restart (you cannot expect the old process to keep
on running porperly after its data/code files have changed underneath)
and we do, by virtue of
/sbin/service vdsmd condrestart
in the %post script.
> If the user updated the package and still wants the new configuration,
> manual vdsmd restart will be required anyway. So the print to restart also
> related service is just enough.
I'm afraid we're ain't so lucky...
Dan.
_______________________________________________
vdsm-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
