Latest revision as of 16:10, 4 December 2013

Heat Template Repository (Heater)

Heat Template Repository (Heater) is a service for the storage, management, and versioning of "known good" templates. Its goal is to allow an organization to encode and then easily share architectural knowledge via a library of templates. Envisioned features include indexing, tagging and search, versioning, configurable back-end storage, and extended metadata composition.

Heater's primary function is as a centralized template library. It should be installable and manageable outside of any particular OpenStack enclave and have no affinity for any one installation of Heat. Many different organizations should be able to easily stand up Heater and define their own policies around publishing and storage.

Use Cases

As a client user I want to be able to query a service which contains a list of curated/supported templates in order to take advantage of my service providers expertise in various application architectures.
A user of the catalog wants to be able to search the templates by keywords.
A service maintainer would like to have a repository in which he can manage Heat templates and maintain associated keywords and metadata.
1. Associating keywords with a template allows a Service Provider to categorize templates for easy grouping and searching templates with related themes or features.
2. Similar to Nova and other Openstack projects, allowing for key/value metadata allows a Service Provider to associate contextualized keywords not covered in the base schema.
As a service provider, I want to have a centralized repository in which I can share institutional systems architecture knowledge encoded in Heat templates.
As a service provider, I should control access to this centralized repository and determine who can and cannot create new, remove or revise existing Heat templates.
As a service provider, I need to be able to tag templates with searchable, indexable keywords.
A Service Provider wants to be able to restrict a template's visibility by user role in order to support different SLAs by user role.

Authentication/Access control

Handled via Keystone as usual

API

(Spec forthcoming - just a basic overview of the possible endpoints/operations)

Submit a template and optional metadata and tags

 POST /templates

 template-type: Application
 keystone-roles:
 - admin
 - demo
 application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons: 
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql
 meta:
   some-junk: junk
   color: sadness
 template:
   <raw template data>
 
 documentation:
   abstract: 
     some abstract...
   guide:
     This blueprint includes a single server running Wordpress with Varnish.
     This blueprint's performance has not been measured.
   instructions:
     If you're new to WordPress, the
     documentation will step you through the process of logging into the
     admin panel, customizing your blog, and changing your theme.

Retrieve a list of templates

 GET /templates?limit=100

Retrieve a version of a template (Published version by default, with/without metadata)

 GET /templates/:id?meta=horizon&meta=documentation&version=b6059

View a template version history

GET /templates/:id/history
{
    current: b6059,
    b6059: {
        version: b6059,
        submitted: ... a date ...
        ref: ... resource uri to the actual version details ....,
    },
    985a4: {
        version: 985a4,
        submitted: ... a date ....
        ref: ...resource uri to the actual version details ....
    }
}

GET /templates/:id/history/:rev
{
    version: ref,
    submitted: .. a date ..
    comment: "A description of the change/difference"
    published: Not present if not published, otherwise the publish date
   
}

Publish a template version version as LKG (admin)
Reject a template version (admin)
Add metadata to an existing template version
Promote metadata to the LKG version of the template (admin)
add/remove tags from a template

Associated metadata

Users should be able to associate metadata with a template to facilitate integration with other tooling like Horizon. This metadata will be kept separate from the raw template so as to ensure that a templates usefulness isn't deluded by the requirements of any given tool. The user should always be able to retrieve a template without the associated metadata. This service should, however, allow the user to retrieve a template "package" that includes the template as well as its metadata (or sub-set thereof). Examples of some types of metadata include:

Hints for displaying template resources in a GUI (positioning, size, etc)
Associative icons
Documentation extensions
Alternative versions
Changelogs

Versioning and Publishing

Heater should support a very simple (and optional) publishing model in which designated users may review revisions of a template as well as metadata and publish it as the "official" or Last Known Good (LKG) version of the template. It is desired that this publishing model be kept very simple and avoid complex review workflow. When a template is requested, it is this published version that is returned unless a specific version is requested.

Storage Backend

The storage backend for Heater should be configurable, but support basic CRUD as well as versioning. Possible reference implementations would include Git and Swift.

Initial Implementation

Some work on a similar service has already been done at Rackspace as a POC. While the general storage, versioning, publishing, and metadata concepts are there, the current software needs to be brought up to OpenStack standards WRT api implementation, code formatting, and authentication. It also lacks configurability of the data store and tagging, however, the existing code can be brought in line with this spec with very little effort.

Heater is NOT:

a proxy to Heat
a complete CMS for templates
a template design tool
designed for one and only one consumer use case

@@ Line 1: / Line 1: @@
 = Heat Template Repository (Heater) =
-Heat Template Repository (Heater) is a service for the storage, management, and versioning of "known good" templates. Its goal is to allow an organization to encode and then easily share architectural knowledge via a library of templates.. Envisioned features include indexing, tagging and search, versioning, configurable back-end storage, and extended metadata composition.
+Heat Template Repository (Heater) is a service for the storage, management, and versioning of "known good" templates. Its goal is to allow an organization to encode and then easily share architectural knowledge via a library of templates. Envisioned features include indexing, tagging and search, versioning, configurable back-end storage, and extended metadata composition.
 Heater's primary function is as a centralized template library. It should be installable and manageable outside of any particular OpenStack enclave and have no affinity for any one installation of Heat. Many different organizations should be able to easily stand up Heater and define their own policies around publishing and storage.
@@ Line 15: / Line 15: @@
 # As a service provider, I need to be able to tag templates with searchable, indexable keywords.
 # A Service Provider wants to be able to restrict a template's visibility by user role in order to support different SLAs by user role.
 == Authentication/Access control ==
 Handled via Keystone as usual
 == API ==
@@ Line 49: / Line 51: @@
    documentation:
-  abstract: |
+    abstract:
-    [WordPress](http://wordpress.org/about/) installed with
+      some abstract...
-    [Apache](http://httpd.apache.org/),
+     guide:
-    [vsftpd](https://security.appspot.com/vsftpd.html#about), [
+      This blueprint includes a single server running Wordpress with Varnish.
-    Varnish](https://www.varnish-cache.org/about), and
+      This blueprint's performance has not been measured.
-    [MySQL 5.5](http://www.mysql.com/about/).
+    instructions:
+      If you're new to WordPress, the
-    This deployment is intended for simple test cases and low
+      documentation will step you through the process of logging into the
-    traffic scenarios.  It is not for high traffic events and
+      admin panel, customizing your blog, and changing your theme.
-     is not easily scalable.
-  guide: |
-    This blueprint includes a single server running Wordpress with Varnish.
-    This blueprint's performance has not been measured.
-  instructions: |
-    #### Getting Started
-    If you're new to WordPress, the
-    [First Steps With WordPress](http://codex.wordpress.org/First_Steps_With_WordPress)
-    documentation will step you through the process of logging into the
-    admin panel, customizing your blog, and changing your theme.
-    The [WordPress Lessons](http://codex.wordpress.org/WordPress_Lessons)
-    cover a wide range of topics for users and designers.
-    #### Accessing Your Deployment
-    If you provided a domain name that is associated with your Rackspace
-    Cloud account and chose to create DNS records, you should be able to
-    navigate to the provided domain name in your browser. If DNS has not
-    been configured yet, please refer to this
-    [documentation](http://www.rackspace.com/knowledge_center/article/how-do-i-modify-my-hosts-file)
-    on how to setup your hosts file to allow your browser to access your
-    deployment via domain name. Please note: some applications like
-    WordPress, Drupal, and Magento may not work properly unless accessed via
-    domain name.
-    #### Logging in via SSH
-    The private key provided in the passwords section can be used to login
-    as root via SSH.  We have an article on how to use these keys with
-    [Mac OS X and Linux](http://www.rackspace.com/knowledge_center/article/logging-in-with-a-ssh-private-key-on-linuxmac)
-    as well as [Windows using PuTTY](http://www.rackspace.com/knowledge_center/article/logging-in-with-a-ssh-private-key-on-windows).
-    #### Details of Your Setup
-    This deployment was stood up using
-    [chef-solo](http://docs.opscode.com/chef_solo.html). Once the deployment
-    is up, chef will not run again, so it is safe to modify configurations.
-    A system user of 'wp_user' or the username you provided as a part of
-    your deployment has been created with the same password as your
-    WordPress user.  This user can be used to SCP, SFTP, or FTP content over
-    to your site.  We recommend using SCP or any encrypted protocol.  Clear
-    text protocols such as FTP could inadvertently expose your user
-    credentials.
-    WordPress itself was installed using [WP-CLI](http://wp-cli.org/).
-    WordPress is installed in /var/www/vhosts/YOUR DOMAIN/ and served by
-    [Apache](http://httpd.apache.org/).  The web site configuration is in
-    /etc/apache2/sites-enabled.  The configuration file will be named using
-    the domain name used as a part of this deployment (for example,
-    domain.com.conf).
-    In order to significantly improve performance, Apache has been moved to
-    run on port 8080, and [Varnish](https://www.varnish-cache.org/) is
-    listening on port 80.  Varnish will cache content served by WordPress,
-    store it in memory, and then serve it from memory if any subsequent
-    requests are made for the same content.  A special configuration file
-    build for WordPress is in place.  The configuration can be found in
-    /etc/varnish/include/.
-    [Lsyncd](https://code.google.com/p/lsyncd/) has been in installed to sync
-    static content across the front end servers.  All new content will be
-    published to the master node and then synced across with lsync to the
-    other web nodes.  When uploading content while migrating a site, you'll
-    only need to upload the content to the master node.  The configuration
-    for lsync can be found in /etc/lsyncd.
-    [vsftpd](https://security.appspot.com/vsftpd.html) has been installed to
-    allow you FTP access to the content of your site.  As mentioned earlier,
-    you can use the WordPress username and password provided as the
-    credentials for FTP.
-    [MySQL](http://www.mysql.com/) is the database backend used in this
-    deployment.  The MySQL root password is included in the password section
-    of this deployment.  If you do lose the password, it is also available
-    in /root/.my.cnf.  MySQL backups are performed locally by
-    [Holland](http://wiki.hollandbackup.org/).  The backups will be stored
-    in /var/lib/mysqlbackup.
-    #### Updating WordPress
-    If you'd like to update WordPress to the newest version, you can
-    leverage the
-    [One-click Update](http://codex.wordpress.org/Updating_WordPress#One-click_Update)
-    now available through the web interface.  This is the simplest, most pain
-    free way to upgrade your installation.  Keeping your installation up to
-    date is important for maintaining site security.
-    #### Migrating an Existing Site
-    If you'd like to move your existing site to this deployment, there are
-    plugins available such as
-    [duplicator](http://wordpress.org/plugins/duplicator/) or
-    [WP Migrate DB](http://wordpress.org/plugins/wp-migrate-db/) that can
-    help ease the migration process.  This will give you a copy of the
-    database that you can import into this deployment.  There are a number
-    of other tools to help with this process.  Static content that is stored
-    on the filesystem will need to be moved manually.
-    #### Plugins
-    There are over 23,000 plugins that have been created by an engaged
-    developer community.  The
-    [plugin directory](http://wordpress.org/extend/plugins/) provides an
-    easy way to discover popular plugins that other users have found to be
-    helpful. [Managing Plugins](https://codex.wordpress.org/Managing_Plugins)
-    is important and you should be aware that some plugins decrease your
-    site's performance so use them sparingly.
-    #### Scaling out
-    This single server deployment is not well suited to be scaled out.  We
-    recommend leveraging a multi server option and using the WordPress
-    migration tools to move your content if you need to grow your Cloud
-    footprint.
@@ Line 215: / Line 107: @@
 * Promote metadata to the LKG version of the template (admin)
 * add/remove tags from a template
 == Associated metadata ==
@@ Line 223: / Line 116: @@
 * Alternative versions
 * Changelogs
 == Versioning and Publishing ==
 Heater should support a very simple (and optional) publishing model in which designated users may review revisions of a template as well as metadata and publish it as the "official" or Last Known Good (LKG) version of the template. It is desired that this publishing model be kept very simple and avoid complex review workflow. When a template is requested, it is this published version that is returned unless a specific version is requested.
 == Storage Backend ==
 The storage backend for Heater should be configurable, but support basic CRUD as well as versioning. Possible reference implementations would include Git and Swift.
 == Initial Implementation ==
 Some work on a similar service has already been done at Rackspace as a POC. While the general storage, versioning, publishing, and metadata concepts are there, the current software needs to be brought up to OpenStack standards WRT api implementation, code formatting, and authentication. It also lacks configurability of the data store and tagging, however, the existing code can be brought in line with this spec with very little effort.
 == Heater is NOT: ==

Difference between revisions of "Heat/htr"