[ovirt-devel] Re: Why is vdsm enabled by default?

[Yuval Turgeman]

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  wrote:

>
>
> On 2/3/20 3:11 PM, Martin Perina wrote:
>
>
>
> On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David  wrote:
>
>> On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer  wrote:
>> >
>> > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg 
>> wrote:
>> >>
>> >> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David 
>> wrote:
>> >> >
>> >> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer 
>> 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 
>> 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 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Marcin Sobczyk]

On 2/3/20 3:11 PM, Martin Perina wrote:



On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David > wrote:


On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer mailto:nsof...@redhat.com>> wrote:
>
> On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg
mailto:dan...@redhat.com>> wrote:
>>
>> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David
mailto:d...@redhat.com>> wrote:
>> >
>> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer mailto:aba...@redhat.com>> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David
mailto:d...@redhat.com>> wrote:
>> >>>
>> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer
mailto: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]

[ovirt-devel] Re: Why is vdsm enabled by default?

[Martin Perina]

On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David  wrote:

> On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer  wrote:
> >
> > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg 
> wrote:
> >>
> >> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David 
> wrote:
> >> >
> >> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David 
> wrote:
> >> >>>
> >> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer 
> 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 <
> d...@redhat.com> wrote:
> >> >
> >> > If I do e.g.:
> >> >
> >> > 1. Install CentOS
> >> > 2. 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yedidyah Bar David]

On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer  wrote:
>
> On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg  wrote:
>>
>> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David  wrote:
>> >
>> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David  
>> >> wrote:
>> >>>
>> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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

>
>> >> 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  
>>  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 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yuval Turgeman]

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  wrote:

> On Thu, Jan 30, 2020 at 10:14 AM Yuval Turgeman 
> 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 
>> wrote:
>>
>>> On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:
>>>


 On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David 
 wrote:

> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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 
>> 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 -- 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yedidyah Bar David]

On Thu, Jan 30, 2020 at 10:14 AM Yuval Turgeman  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 
> wrote:
>
>> On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David 
>>> wrote:
>>>
 On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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 
> 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:
>> 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yuval Turgeman]

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

On Thu, Jan 30, 2020 at 10:01 AM Yedidyah Bar David  wrote:

> On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:
>
>>
>>
>> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David 
>> wrote:
>>
>>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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 
 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/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yedidyah Bar David]

On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer  wrote:

>
>
> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David 
> wrote:
>
>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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 
>>> 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/

[ovirt-devel] Re: Why is vdsm enabled by default?

[Amit Bawer]

On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David  wrote:

> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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.
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


>
> Thanks!
>
>
>>
>> On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David 
>> 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
>
___
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/TLFRXMMPRJQPJQJJWFEOJ3CUOUSTOI23/

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yedidyah Bar David]

On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer  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.

Thanks!


>
> On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David 
> 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
___
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/HNVENA4RTXQLF26FM4MHBBF4EKCLPBY7/

[ovirt-devel] Re: Why is vdsm enabled by default?

[Amit Bawer]

>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.
In case of manual installations by non-users, it is accustomed to run
"vdsm-tool configure --force" after step 3 and then reboot.
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.

On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David  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/
>
___
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/O7AOVUUFVYY2IWKXIRNSR33PKNR74GNU/