Bug 1262307 - [RFE] Use a generic image upgrade mechanism
[RFE] Use a generic image upgrade mechanism
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
3.6.0
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Balakrishnan, Radhesh
Gil Klein
node
: FutureFeature
Depends On:
Blocks: 1260746
  Show dependency treegraph
 
Reported: 2015-09-11 07:43 EDT by Fabian Deutsch
Modified: 2016-02-10 15:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-15 08:49:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Node
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2015-09-11 07:43:39 EDT
Description of problem:
Currently the image based upgrade mechanism present in all of RHEV is very much tuned towards RHEV-H.
To prepare other image based update mechanism the whole mechanisms on all involved components (node, vdsm, and engine) should be updated to address a couple of things:

- Better delivery of version informations
Currently the version informations are delivered from installed filenames, which ain't very flexible

- Better detection and suggestion of upgrades
The upgrade suggestion is very naive and could be better (i.e. differentiate between the platform majors)

- Abstract way to push offline updates
Currently something like: ovirt-node-upgrade --iso=… is used, this makes much assumption about the format of the iso etc.
Something more unspecific like: ovirt-…-upgrade --image=$FN should be anticipated.
The format of the image should include some kind of hint what kidn of upgrade it is, i.e. container, tree or iso (or this could also be encoded in the filename or as arguments)

This bug should be a tracker, individual bugs to track the different changes need to be created.
Comment 1 Fabian Deutsch 2015-09-11 09:40:41 EDT
Another change is that the persistence behavior of the "new" Node implementations will be different to what we have in the classic Node.

One big assumption about the new implementations is, that the persistence will be transparent to any payload/consumer, which means that the whole persistence logic can be dropped.

Another important component involved is ovirt-host-deploy
Comment 2 Fabian Deutsch 2015-11-26 10:16:50 EST
In the end this might not be needed if we settle with the approach where a host is taking over the upgrade through some yum repo.
Comment 3 Fabian Deutsch 2015-12-15 08:49:20 EST
Closing according to comment 2 - because it looks like rpm will be used for delivery for now.

Note You need to log in before you can comment on or make changes to this bug.