[node-devel] Versioning of oVirt Node

[Fabian Deutsch]

Am Montag, den 31.03.2014, 05:08 -0400 schrieb Barak Azulay:
> 
> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf" <dlandgra at redhat.com>
> > Sent: Monday, March 31, 2014 9:39:55 AM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > Am Sonntag, den 30.03.2014, 04:46 -0400 schrieb Barak Azulay:
> > > I assume that this new schema is handling also the frist upgrade from
> > > the old name schema.
> > 
> > Hey Barak,
> > 
> > could you explain what the first upgrade to the old schema name was for
> > you?
> 
> There are 2 scenarios that needs to be considered:
> 1 older engine with new rhevh (with new name schema)
>   * customer with rhev 3.4 tries to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

Mh.
What about picking up Alon's (IIRC) suggestion to use subdirs.
The "old" names would reside in the path where they are now.
And new isos are placed in a subdirectory, where the name of the
subdirectory is the targeted version (e.g. 3.4/ would contain Node's for
3.4)
That way we don't collide with the old scheme.
Newer isos could be brought to old Engines by doing some fancy
symlinking.

> 2 newer engine supporting older clustrers:
>   * assume you have 3.4 engine out with several ISOs located in the same dir,
>     Than there is an upgrade to 3.5 where the name schema changes (and in the same dir you have old name schema and new name schema),
>     Than you want to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

Maybe this is also solvable by using subdirs as described above.

But maybe I'm not getting you right.

- fabian

> In both cases the UI should suggest the best fit for upgrade,
> While for #2 we can add some logic to the engine to handle both cases (ugly and problematic),
> For #1 above there is very little we can do. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20140403/0952f2df/attachment.sig>