On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David <[email protected]> wrote:
> On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <[email protected]> wrote: > > > > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <[email protected]> > wrote: > >> > >> On Thu, Jan 30, 2020 at 9:57 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)? > >> > >> 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 ... > > >> >> 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/QJ64H2AXP6RQ26MOKVCVIGLH43GRGTXD/ > > > > -- > 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/Z3K5QWKSMYFDMMYOKUDRN7SMA67IPONJ/ > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ 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/3WFQDFGYXLCLYNXOINMD3YIIO4FKPLEF/
