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 <[email protected]>
To: aeolus-devel <[email protected]>
CC: [email protected], Angus Thomas <[email protected]>, Jan
Provazník <[email protected]>, Scott Seago <[email protected]>,
Michael Orazi <[email protected]>, [email protected],
[email protected], Hugh Brock <[email protected]>, Matthew Wagner
<[email protected]>
Gentlemen,
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,...)
* Packages
* Running services
Arguments for:
* 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
freedom)
* With changing just the specification, we don't have to change
references in AppForm Blueprints (Deployables) since they keep still the
same Image ID.
Arguments against:
* With changing image specification, the whole object changes (Is it
still the same object with different specification? E.g. different OS,
architecture,...?)
* 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
-- Jarda
Hi Jarda,
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.
Jan
