On 12/17/2012 05:32 PM, Jaromír Coufal wrote:
Re-sending one more time, since I did not find the message on
aeolus-devel mailing list after sending it.
Please, see below:
-------- Original Message --------
Subject: RFC: Image versioning / Component Outline versioning
Date: Fri, 14 Dec 2012 14:58:00 +0100
From: Jaromír Coufal <jcoufal(a)redhat.com>
To: aeolus-devel <aeolus-devel(a)lists.fedorahosted.org>
CC: mtaylor(a)redhat.com, Angus Thomas <athomas(a)redhat.com>, Jan
Provazník <jprovazn(a)redhat.com>, Scott Seago <sseago(a)redhat.com>,
Michael Orazi <morazi(a)redhat.com>, jguiditt(a)redhat.com,
imcleod(a)redhat.com, Hugh Brock <hbrock(a)redhat.com>, Matthew Wagner
In last couple of days, even on technical cabal, we had been dealing
with following issue, which is still a little bit unclear.
I would like to ask all of you for comments regarding versioning images
and their component outlines.
The question is:
* Do we want to allow user to edit Component Outline (Image XML) which
brings functionality for advanced image versioning?
* And if so, on which level?
Situation is following:
* In Component Outline you can specify
* OS (Fedora, Ubuntu, ...)
* Architecture (x86_64,...)
* Running services
* User can change image specification in the future (e.g. he can add new
packages, new services, etc.)
* User can return back to older versions
* We are adding advanced functionality for the user (giving him more
* With changing just the specification, we don't have to change
references in AppForm Blueprints (Deployables) since they keep still the
same Image ID.
* With changing image specification, the whole object changes (Is it
still the same object with different specification? E.g. different OS,
* If it is still the same object, what change makes it enough different
to become different one (changing OS? architecture? or what packages?)
* By changing image specification we can break other dependencies in
related AppForm Blueprints (Deployables), which might depend on certain
package, service, etc.
* If we allow Image versioning, do we also want use to use older
versions of the image as well?
* With more freedom becomes bigger responsibility to user and higher
potential to break things down
* We are complicating scenarios for user (If user wants change, he can
do it by cloning image and changing just what he needs)
Thank you for all of your ideas
my personal preference is to support image versioning, as a user I would
expect/appreciate this feature. I would give user full freedom and
responsibility in changing template (no restrictions for changing any
part of template), It's up to him to decide if it's better change a
template or create new one. And we should also provide him simple way to
check history of changes in a template.
Image cloning would be sufficient too if we provide simple way how to
update image ids in existing appforms. Drawback is also that a user
looses association between related (original and cloned) templates so
history of changes is not available in this solution.