Well, if vdsm wasn't enabled by default, we wouldn't hog the cpu if vdsm-tool configure fails
On Thu, Jan 30, 2020 at 10:25 AM Yedidyah Bar David <[email protected]> wrote: > On Thu, Jan 30, 2020 at 10:14 AM Yuval Turgeman <[email protected]> > wrote: > >> Another issue (in 4.4) as long as vdsm is not configured, >> vdsmd_init_common in ExecPre fails, and systemd keeps trying to start the >> service which is really annoying >> > > That's not really related, and is probably just a bug. %posttrans runs > 'vdsm-tool configure --force' for you. It might fail, obviously. > > You'll have exactly the same problem if you run 'vdsm-tool configure > --force' manually and then enable. The point is, that if you run it > manually, and enable manually, or both inside some script, you should, and > can, check if things are ok. Enabling automatically does not allow you to > check and decide by yourself (or inside a script). > > >> >> On Thu, Jan 30, 2020 at 10:01 AM Yedidyah Bar David <[email protected]> >> wrote: >> >>> On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <[email protected]> >>>> wrote: >>>> >>>>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <[email protected]> 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 <[email protected]> >>>>>> 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 -- [email protected] >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> 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/[email protected]/message/3YHWLO3DFU2PLPGL44DBIBG25QYGOQL7/ >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Didi >>>>> >>>> >>> >>> -- >>> Didi >>> _______________________________________________ >>> Devel mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected]/message/JYB6N2PJ7YUQBLOREQ5SHQ4YG6UF74M5/ >>> >> > > -- > Didi >
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/S6IUDJSNSGR77MBMIV6H34D5WUER7QOI/
