Why is vdsm enabled by default?
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
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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. Thanks!
On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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. 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/...
Thanks!
On Tue, Jan 28, 2020 at 11:47 AM Yedidyah Bar David <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi
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 <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/JYB6N2PJ7YUQBL...
On Thu, Jan 30, 2020 at 10:14 AM Yuval Turgeman <yturgema@redhat.com> 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 <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/JYB6N2PJ7YUQBL...
-- Didi
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 <didi@redhat.com> wrote:
On Thu, Jan 30, 2020 at 10:14 AM Yuval Turgeman <yturgema@redhat.com> 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 <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP... >
-- Didi
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/JYB6N2PJ7YUQBL...
-- Didi
On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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.
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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi
On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com>
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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
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
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
wrote: point. Which it does :-) particular circumstances. 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, and we certainly don't want to configure it automatically, 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.
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/...
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 <didi@redhat.com>
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
wrote: 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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi
Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/QJ64H2AXP6RQ26...
On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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
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/...
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 <didi@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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi
Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/QJ64H2AXP6RQ26...
-- Didi
On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <danken@redhat.com>
On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com>
wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com> wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com>
wrote:
On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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
> > 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
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
wrote: point. Which it does :-) particular circumstances. 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/...
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 <
>> >> 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
didi@redhat.com> wrote: 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-leave@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/3YHWLO3DFU2PLP...
-- Didi
-- Didi
Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/QJ64H2AXP6RQ26...
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/Z3K5QWKSMYFDMM...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
On 2/3/20 3:11 PM, Martin Perina wrote:
On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David <didi@redhat.com <mailto:didi@redhat.com>> wrote:
On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> wrote: > > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote: >> >> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com <mailto:didi@redhat.com>> wrote: >> > >> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com <mailto:abawer@redhat.com>> wrote: >> >> >> >> >> >> >> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <didi@redhat.com <mailto:didi@redhat.com>> wrote: >> >>> >> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@redhat.com <mailto:abawer@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-supp...)
> >> >> 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/... >> > >> > >> > 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 <didi@redhat.com <mailto:didi@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 <mailto:devel@ovirt.org> >> >>>>> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/3YHWLO3DFU2PLP... >> >>> >> >>> >> >>> >> >>> -- >> >>> Didi >> > >> > >> > >> > -- >> > Didi >> _______________________________________________ >> Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> >> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/QJ64H2AXP6RQ26...
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/Z3K5QWKSMYFDMM...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
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 <msobczyk@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 <didi@redhat.com> wrote:
On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg <danken@redhat.com>
On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David <didi@redhat.com>
wrote:
On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer <abawer@redhat.com>
wrote:
On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <
didi@redhat.com> wrote:
> > On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer <abawer@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
> >> >> 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
wrote: point. Which it does :-) 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-supp...)
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/...
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 <
>>> >>> 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
didi@redhat.com> wrote: 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-leave@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/3YHWLO3DFU2PLP... > > > > -- > Didi
-- Didi
Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/QJ64H2AXP6RQ26...
-- Didi _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/Z3K5QWKSMYFDMM...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
participants (7)
-
Amit Bawer -
Dan Kenigsberg -
Marcin Sobczyk -
Martin Perina -
Nir Soffer -
Yedidyah Bar David -
Yuval Turgeman