Bug 1262307

Summary:	[RFE] Use a generic image upgrade mechanism
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Fabian Deutsch <fdeutsch>
Component:	RFEs	Assignee:	Balakrishnan, Radhesh <rbalakri>
Status:	CLOSED WONTFIX	QA Contact:	Gil Klein <gklein>
Severity:	medium	Docs Contact:
Priority:	high
Version:	3.6.0	CC:	ecohen, gklein, lsurette, rbalakri, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	node
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-15 13:49:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Node	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1260746

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.