Bug 1262307 - [RFE] Use a generic image upgrade mechanism
Summary: [RFE] Use a generic image upgrade mechanism
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Balakrishnan, Radhesh
QA Contact: Gil Klein
URL:
Whiteboard: node
Depends On:
Blocks: 1260746
TreeView+ depends on / blocked
 
Reported: 2015-09-11 11:43 UTC by Fabian Deutsch
Modified: 2016-02-10 20:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-15 13:49:20 UTC
oVirt Team: Node
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Fabian Deutsch 2015-09-11 11:43:39 UTC
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 13:40:41 UTC
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 15:16:50 UTC
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 13:49:20 UTC
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.