On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <aba...@redhat.com> wrote:
> > > On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <d...@redhat.com> > wrote: > >> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <aba...@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/b0c338b717ff300575c1ff690d9efa256fcd2164/vdsm.spec.in#L955 > 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 <d...@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@ovirt.org >>>> To unsubscribe send an email to devel-le...@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/3YHWLO3DFU2PLPGL44DBIBG25QYGOQL7/ >>>> >>> >> >> -- >> Didi >> > -- Didi
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@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/JYB6N2PJ7YUQBLOREQ5SHQ4YG6UF74M5/
