Marcin's work looks great on my (manual) tests, in addition to that we disabled ovirt-vmconsole-host-sshd.service [1] in NGN as it fails to start due to a missing host key, until it gets added to the engine, which enables the service as well.
[1] https://gerrit.ovirt.org/#/c/108173/ On Thu, Apr 2, 2020 at 4:50 PM Marcin Sobczyk <msobc...@redhat.com> wrote: > > > On 2/3/20 3:11 PM, Martin Perina wrote: > > > > On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David <d...@redhat.com> wrote: > >> On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <nsof...@redhat.com> wrote: >> > >> > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <dan...@redhat.com> >> wrote: >> >> >> >> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <d...@redhat.com> >> wrote: >> >> > >> >> > 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)? >> >> >> >> Oh dear, I have only very vague memories right now. I do believe that >> >> we have always has (the equivalent of) vdsm enable. At one point we >> >> moved that to an rpm preset per explicit request from Fedora. But my >> >> gut feeling is that there was not a very good reason to have it that >> >> way. It might have been only a case of contagiousness: old versions of >> >> ovirt-host-deploy do not have the logic to enable vdsm, so vdsm had to >> >> have it itself, so nobody bothered to fix ovirt-host-deploy for the >> >> next version, and here we are 5 years later. >> > >> > >> > It does not make sense to enable vdsm unless it was configured, >> >> Indeed >> >> > and we certainly don't >> > want to configure it automatically, >> >> We do, currently :-(( >> >> > so vdsm should not be enabled by default. >> >> :-) >> >> > >> > But someone needs to update host deploy code to enable vdsm before we >> can change >> > vdsm deployment. >> >> We always did, in otopi ovirt-host-deploy. A quick grep in the ansible >> code does not find for me this. >> >> I am glad we managed to reach a consensus, Thanks :-) >> >> Filed these now: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1797284 [RFE] enable vdsm >> services during deploy >> https://bugzilla.redhat.com/show_bug.cgi?id=1797287 [RFE] vdsm should >> be disabled by default >> >> > I vaguely remember that in the past VDSM needed to be enabled by default > due to NGN image creation. > Yuval/Sandro, is it still needed? > > If not, of course we can change VDSM packaging and host deploy flow ... > > I posted https://gerrit.ovirt.org/#/c/108098/ to disable vdsm's autostart > after installation. > Actually, due to recent issues with NGN image creation the last of the > whole topic should be tested: > > > https://gerrit.ovirt.org/#/q/topic:remove-non-socket-activation-libvirt-support+(status:open+OR+status:merged) > > > > > >> >> >> 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/QJ64H2AXP6RQ26MOKVCVIGLH43GRGTXD/ >> >> >> >> -- >> 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/Z3K5QWKSMYFDMMYOKUDRN7SMA67IPONJ/ >> > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > > >
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XA4VSQ3QN4PTLWIDDBWJLLPZLBK3EUO2/
