Fwd: RFC: Image versioning / Component Outline versioning

Jan Provazník jprovazn at redhat.com
Thu Dec 20 20:01:25 UTC 2012


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 at redhat.com>
> To:     aeolus-devel <aeolus-devel at lists.fedorahosted.org>
> CC:     mtaylor at redhat.com, Angus Thomas <athomas at redhat.com>, Jan
> Provazník <jprovazn at redhat.com>, Scott Seago <sseago at redhat.com>,
> Michael Orazi <morazi at redhat.com>, jguiditt at redhat.com,
> imcleod at redhat.com, Hugh Brock <hbrock at redhat.com>, Matthew Wagner
> <mawagner at redhat.com>
>
>
>
> 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


More information about the aeolus-devel mailing list