Bug 1433434
Summary: | 3.6ngn cannot be added into 3.6 cluster in 4.1 engine | ||
---|---|---|---|
Product: | [oVirt] ovirt-host-deploy | Reporter: | Jiri Belka <jbelka> |
Component: | General | Assignee: | Yedidyah Bar David <didi> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Belka <jbelka> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | master | CC: | alkaplan, bugs, danken, didi, jbelka, lbopf, mperina, oourfali, ykaul, ylavi |
Target Milestone: | ovirt-4.1.1-1 | Keywords: | Reopened |
Target Release: | --- | Flags: | rule-engine:
ovirt-4.1+
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Known Issue | |
Doc Text: |
In Red Hat Virtualization 4.1, when the Manager deploys a host, collectd is always installed; however, host deployment will fail if you are attempting to deploy a new or reinstalled version 3.y host (in a cluster with 3.6 compatibility level), because collectd is not shipped in the 3.y repositories.
To avoid this, ensure that you install and deploy any version 3.y hosts prior to upgrading the Manager to 4.1.
Note that after the Manager upgrade, these hosts will continue to work, but you will not be able to reinstall them without first upgrading them to version 4.1.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-04-21 09:48:14 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jiri Belka
2017-03-17 16:06:56 UTC
collectd is added to package list inside host-deploy itself regardless of cluster level version which is host is able to support (based on VDSM version). IIRC we discussed this flow before adding collectd/fluentd to hosts and decided to keep it that way - that you should only install new hosts as 4.1. Yaniv? Agreed - why should we add new hosts that are old? OK, closing for now. Please reopen if needed. Yaniv - shouldn't this be clearly documented? Didi, can you add a known issue text? *** Bug 1438347 has been marked as a duplicate of this bug. *** (In reply to Yaniv Kaul from comment #4) > Agreed - why should we add new hosts that are old? There are users that control which yum repositories their hosts see via Foreman/Satellite, in order to protect themselves from unintended upgrades. I would like this bug to be fixed, so that we allow them to upgrade Engine first, see that things work, while keeping with 4.0.z upgrades/installation, add 4.2 cluster, and only finally, enable 4.2 in their production hosts. (In reply to Dan Kenigsberg from comment #9) > (In reply to Yaniv Kaul from comment #4) > > Agreed - why should we add new hosts that are old? > > There are users that control which yum repositories their hosts see via > Foreman/Satellite, in order to protect themselves from unintended upgrades. > > I would like this bug to be fixed, so that we allow them to upgrade Engine > first, see that things work, while keeping with 4.0.z upgrades/installation, > add 4.2 cluster, and only finally, enable 4.2 in their production hosts. This is a NGN bug and only affect adding new nodes. I don't understand the need to resolve this. Can you please elaborate? I got to this bug because of bug 1438347 was marked as its dup. bug 1438347 was seen on a plain el7 host, unrelated to ngn. Can we move the package to update into the host-deploy that is version and arch specific? Having engine only request an update and not list which packages to upgrade. (In reply to Yaniv Dary from comment #12) > Can we move the package to update into the host-deploy that is version and > arch specific? Having engine only request an update and not list which > packages to upgrade. It will not happen for 4.1.1-1, for which we do want the Known Issue, so please open a new bug to discuss that. It was already agreed to not do that (comment 4), but we can always change our mind. I'd personally do not do that. IMO it should be the opposite - the engine should send the list of packages, and this list should be built also based on version/arch (if needed, as well as perhaps other factors). I'd also change the host-deploy logic to be the same. Currently host-mgmt (what the Update Manager runs) works this way, while host-deploy does not (it has the list of metrics packages hard-coded in itself and without conditions). If you want host-deploy to decide on this, then the engine should provide host-deploy information it does not have currently (version, arch etc.), so this still requires a change in both of them. There has been no change/code to be tested here. Doc Text clearly states it is expected behavior. Either WONTFIX or ship a code to be tested to change original reported behavior. I'm for the first one. Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. (In reply to Jiri Belka from comment #14) > There has been no change/code to be tested here. Actually there was - I changed the bug type to Known Issue. Am I missing any extra step needed for adding a Known Issue? Some other flag? > Doc Text clearly states it > is expected behavior. Right. Current bug is only to add a Known Issue. Please verify that the "workaround" in the doc text works for you (or whatever other process you have for QE management of Known Issue bugs) and move to VERIFIED. > > Either WONTFIX or ship a code to be tested to change original reported > behavior. I'm for the first one. (In reply to Yedidyah Bar David from comment #16) > (In reply to Jiri Belka from comment #14) > > There has been no change/code to be tested here. > > Actually there was - I changed the bug type to Known Issue. > > Am I missing any extra step needed for adding a Known Issue? Some other flag? > > > Doc Text clearly states it > > is expected behavior. > > Right. Current bug is only to add a Known Issue. > > Please verify that the "workaround" in the doc text works for you (or > whatever other process you have for QE management of Known Issue bugs) and > move to VERIFIED. > > > > > Either WONTFIX or ship a code to be tested to change original reported > > behavior. I'm for the first one. |