On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer(a)redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi(a)redhat.com>
> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer(a)redhat.com> wrote:
>> From my limited experience, the usual flow for most users is
>> deploying/upgrading a host and installing vdsm from the engine UI on the
>> hypervisor machine.
> You are right, for non-hosted-engine hosts. For hosted-engine, at least
> the first host, you first install stuff on it (including vdsm), then
> deploy, and only then have an engine. If for any reason you reboot in the
> middle, you might run into unneeded problems, due to vdsm starting at boot.
>> In case of manual installations by non-users, it is accustomed to run
>> "vdsm-tool configure --force" after step 3 and then reboot.
> I didn't know that, sorry, but would not want to do that either, for
> hosted-engine. I'd rather hosted-engine deploy to do that, at the right
> point. Which it does :-)
>> Having a host on which vdsm is not running by default renders it useless
>> for ovirt, unless it is explicitly set to be down from UI under particular
> Obviously, for an active host. If it's not active, and is rebooted, not
> sure we need vdsm to start - even if it's already added/configured/etc (but
> e.g. put in maintenance). But that's not my question - I don't mind
> enabling vdsmd as part of host-deploy, so that vdsm would start if a host
> in maintenance is rebooted. I only ask why it should be enabled by the rpm
Hard to tell, this dates back to commit
d45e6827f38d36730ec468d31d905f21878c7250 and commit
c01a733ce81edc2c51ed3426f1424c93917bb106 before that, in which both did not
specify a reason.
Adding Dan. Dan - was it enabled by default in sysv? I think not. Was there
an explicit requirement/decision to enable it on the move to systemd? If
not, is it ok to keep it disabled by default and enable when needed
But the rpm post installation should also configure vdsm, at least on
fresh install , so it makes sense (at least to me) that it is okay to
enable it by default since you have all setup for a regular usage.
I do not agree.
I think most sensible sysadmin would expect a 'yum install package; yum
remove package' to leave their system mostly unchanged. Also, 'yum install
package; reboot; yum remove package'. I guess most sysadmins know that
there are %pre* and %post* and that package maintainers do all kinds of
stuff there, but do not expect, IMHO, the amount of changes that we do in
>> On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David <didi(a)redhat.com>
>>> If I do e.g.:
>>> 1. Install CentOS
>>> 2. yum install ovirt-releaseSOMETHING
>>> 3. yum install vdsm
>>> Then reboot the machine, vdsm starts, and for this, it does all kinds
>>> of things to the system (such as configure various services using vdsm-tool
>>> etc.). Are we sure we want/need this? Why would we want vdsm
>>> configured/running at all at this stage, before being added to an engine?
>>> In particular, if (especially during development) we have a bug in this
>>> configuration process, and then fix it, it might not be enough to upgrade
>>> vdsm - the tooling will then also have to fix the changes done by the buggy
>>> previous version, or require a full machine reinstall.
>>> Thanks and best regards,
>>> Devel mailing list -- devel(a)ovirt.org
>>> To unsubscribe send an email to devel-leave(a)ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> List Archives: