Description of problem: Upgrade button is unavailable(grey) in engine 3.6 when upgrade NGN-3.6 to 4.x node in engine side Version-Release number of selected component (if applicable): From: RHVH-3.6-20170217.5-RHVH-x86_64-dvd1.iso To: redhat-virtualization-host-4.1-20170208.0 How reproducible: 100% Steps to Reproduce: 1. Install RHVH 3.6 RHVH-3.6-20170217.5-RHVH-x86_64-dvd1.iso 2. Setup local repos in RHVH 3.6, then add it to engine 3.6(cluster 3.6) Run "yum update" in RHVH-3.6 can detect newer build redhat-virtualization-host-4.1-20170208.0, quit update process. 3. Login rhevm, set upgrade detect interval time as 1 hour # engine-config -s HostPackagesUpdateTimeInHours=1 # service ovirt-engine restart 4. Wait for more than 1 hour, check Upgrade button in engine 3.6 Actual results: After step4, Upgrade button in engine 3.6 is unavailable(grey) all the time Expected results: After step4, Upgrade button in engine 3.6 should be available and can upgrade NGN-3.6 to newer 4.x node from engine side Additional info:
I think it's OK - I don't expect a 3.6 engine to be able to upgrade an NGN RHVH. It can be upgraded via the RHVH itself - Ryan - can you confirm?
Correct -- it can be upgraded via RHVH itself, especially if 'yum update' can see it. In order for this to work otherwise, engine would need a backport of this topic branch: https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:NGN Recommending that users upgrade from the host is ok here.
I don't think we are going to backport this - Yaniv D. - please CLOSE-WONTFIX.
This would mean we will need to run the yum command as part of the field engineering effort without the update manager orchestration. I that acceptable to you?
(In reply to Yaniv Dary from comment #4) > This would mean we will need to run the yum command as part of the field > engineering effort without the update manager orchestration. I that > acceptable to you? Yes. I'm hoping it can be scripted via Ansible.
Yaniv D. step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3: (upgrade) el7-4.y-ngn. According to comment 3, comment 4, and comment 5, so we won't support step 2 to step 3 upgrade via engine 3.6, could you ack this, and then close this bug as WON'T fix?
(In reply to Yaniv Kaul from comment #5) > (In reply to Yaniv Dary from comment #4) > > This would mean we will need to run the yum command as part of the field > > engineering effort without the update manager orchestration. I that > > acceptable to you? > > Yes. I'm hoping it can be scripted via Ansible. Ansible is a much weaker solution than the upgrade manager. This would mean rewriting this code in Ansible. Is that what we want? (In reply to Ying Cui from comment #6) > Yaniv D. > step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3: > (upgrade) el7-4.y-ngn. > According to comment 3, comment 4, and comment 5, so we won't support step 2 > to step 3 upgrade via engine 3.6, could you ack this, and then close this > bug as WON'T fix? Ying, I'm still not sure. Let close this discussion first.
(In reply to Yaniv Dary from comment #7) > (In reply to Yaniv Kaul from comment #5) > > (In reply to Yaniv Dary from comment #4) > > > This would mean we will need to run the yum command as part of the field > > > engineering effort without the update manager orchestration. I that > > > acceptable to you? > > > > Yes. I'm hoping it can be scripted via Ansible. > > Ansible is a much weaker solution than the upgrade manager. Not for RHVH. > This would mean rewriting this code in Ansible. Is that what we want? For RHVH, yes. It's quite simple actually. > > > (In reply to Ying Cui from comment #6) > > Yaniv D. > > step1: el6-3.5-vintage -> step2: (reinstall) el7-3.6-ngn -> step 3: > > (upgrade) el7-4.y-ngn. > > According to comment 3, comment 4, and comment 5, so we won't support step 2 > > to step 3 upgrade via engine 3.6, could you ack this, and then close this > > bug as WON'T fix? > > Ying, I'm still not sure. Let close this discussion first.
Yaniv?
Handling NGN upgrades within host upgraded manager is engine 4.0 feature, in 3.6 you need to invoke yum directly to perform an upgrade. Based on above comments I'm closing this as WONTFIX, but feel free to reopen and please present other arguments why we should backport the feature.
(In reply to Yaniv Kaul from comment #9) > Yaniv? If you believe scripting this would be easier than this can remain closed.