10:57 a.m.
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>
wrote:
> 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
>> circumstances.
>>
>
> 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
> installation.
>
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
(host-deploy)?
But the rpm post installation should also configure vdsm, at least on
a
fresh install [1], 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.
[1]
https://github.com/oVirt/vdsm/blob/b0c338b717ff300575c1ff690d9efa256fcd21...
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
vdsm-tool.
>
> Thanks!
>
>
>>
>> On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David <didi(a)redhat.com>
>> wrote:
>>
>>> 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,
>>> --
>>> Didi
>>> _______________________________________________
>>> 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:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>>
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/3YHWLO3DFU2...
>>>
>>
>
> --
> Didi
>
--
Didi