RFC: Template Versions and Tim Resource Renaming

Martyn Taylor mtaylor at redhat.com
Tue Jan 22 15:50:37 UTC 2013


  RFC: Template Versions and Naming Consistencies

I should have probably written this as two separate emails but since 
both points are intertwined I thought it be better to discuss together.


*Background*

At the moment Tim templates are completely immutable. This means making 
a simple change to a template requires creating a completely new 
template. The original thinking here was that templates could be cloned, 
edited then saved, so would not have had large user overhead. However, 
since templates are the top level object in Tim. i.e. Template has many 
Base Images and so on. It meant that images created from differening 
templates (even if they were cloned) were not related in any way making 
it difficult to track changes in both templates and images.


/*A rather contrived example might be:*/

User Bob wants launch an instance of his image in EC2. If there is 
already an image in ec2 with my Bobs application > version 1.0 then use 
that. Otherwise he wants to build a new image based on the most recent 
template. Since the templates are not related in anyway it makes it 
difficult to do this.


*Template Versions*

Adding in the concept of Template Versions allows a user to create a 
master template. This template can be edited as many times as the user 
wants. Each time a change is made the user can snapshot it and create a 
Template Version. This is then timestamped, versioned and asscoated with 
the master template. The template version is then used to create Image 
Versions. This allows users to track changes in templates and use 
specific images of particular template versions. In the scenario above, 
we could easily check the Template Versions for the presence of 
Application V1.0 in EC2. If it exists lauch it otherwise create a new one.


*New Model and Rename*

In addition to adding Template Versions we should make the naming of 
components consistent across projects. This means renaming some of the 
existing models in Tim. See the diagrams below. The Base Image is now 
renamed to Image (the naming here is up for grabs as long as it dpoes 
not conflict with Factory). Image Version is now named to Base Image 
(since it is related to Factory::BaseImage)



Tim Resource Model


    Scenarios:

  *

    As an Application Designer I want to create Templates

  *

    As an Application Designer I want to create a new /version/ of an
    existing Template.

  *

    As an Infrastructure Consumer I want to build and deploy Images
    based on a particular Template.

  *

    As an Infrastructure Consumer I want to view which Template an Image
    was built from.

  *

    As a Infrastructure Consumer I want to guarantee equivalence
    (packages/versions) across Target and Provider Images.

  *

    As an Infrastructure Consumer I want to create a deployable that
    references a specific target image.

  *

    As an Infrastructure Consumer I want to create a deployable that
    references the target image build of a specific template version.

  *

    As an Infrastructure Consumer I want to create a deployable that
    references the most recent version of a template.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20130122/969612b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template_versions_rename_tim_model.png
Type: image/png
Size: 76315 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20130122/969612b9/attachment-0001.png>


More information about the aeolus-devel mailing list