On Sat, Oct 12, 2013 at 05:26:53PM -0400, Yaniv Bronheim wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <dan...@redhat.com>
> > To: "Antoni Segura Puimedon" <asegu...@redhat.com>
> > Cc: "arch" <a...@ovirt.org>, "VDSM Project Development" 
> > <vdsm-devel@lists.fedorahosted.org>
> > 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
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to