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