Jump to: navigation, search

Difference between revisions of "Heat/htr"

m
Line 40: Line 40:
 
   template-revision: SHA1 or 1234
 
   template-revision: SHA1 or 1234
 
   tags:
 
   tags:
 +
    keywords: wordpress, mysql
 
     template-type: Application
 
     template-type: Application
 
     application-name: WordPress
 
     application-name: WordPress
Line 50: Line 51:
 
     icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
 
     icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
 
   template:
 
   template:
−
     heat_template_version: 2013-05-23
+
     <raw template data>
 +
</pre>
  
−
description: >
 
−
  Heat WordPress template to support F18, using only Heat OpenStack-native
 
−
  resource types, and without the requirement for heat-cfntools in the image.
 
−
  WordPress is web software you can use to create a beautiful website or blog.
 
−
  This template installs a single-instance WordPress deployment using a local
 
−
  MySQL database to store the data.
 
  
−
parameters:
+
*Retrieve a list of templates
 +
<pre>
 +
GET /templates?limit=100
  
−
  key_name:
+
template-revision: SHA1 or 1234
−
    type: string
+
   tags:
−
    description : Name of a KeyPair to enable SSH access to the instance
+
     keywords: wordpress, mysql
−
  instance_type:
+
     template-type: Application
−
    type: string
+
     application-name: WordPress
−
    description: Instance type for WordPress server
+
     application-version: 3.6.1
−
    default: m1.small
+
     flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
−
    constraints:
+
     flavor-weight: 3
−
      - allowed_values: [m1.small, m1.medium, m1.large]
+
     some-junk: junk
−
        description: instance_type must be one of m1.small, m1.medium or m1.large
+
     color: sadness
−
   image_id:
+
     tattoo: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
−
     type: string
+
    icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
−
     description: ID of the image to use for the WordPress server
+
   template:
−
    default: F18-x86_64-cfntools
+
     <raw template data>
−
    constraints:
 
−
      - allowed_values: [ F18-i386-cfntools, F18-x86_64-cfntools ]
 
−
        description: >
 
−
          Image ID must be either F18-i386-cfntools or F18-x86_64-cfntools
 
−
  db_name:
 
−
    type: string
 
−
     description: WordPress database name
 
−
    default: wordpress
 
−
     constraints:
 
−
      - length: { min: 1, max: 64 }
 
−
        description: db_name must be between 1 and 64 characters
 
−
      - allowed_pattern: '[a-zA-Z][a-zA-Z0-9]*'
 
−
        description: >
 
−
          db_name must begin with a letter and contain only alphanumeric
 
−
          characters
 
−
  db_username:
 
−
     type: string
 
−
    description: The WordPress database admin account username
 
−
    default: admin
 
−
    hidden: true
 
−
    constraints:
 
−
      - length: { min: 1, max: 16 }
 
−
        description: db_username must be between 1 and 64 characters
 
−
      - allowed_pattern: '[a-zA-Z][a-zA-Z0-9]*'
 
−
        description: >
 
−
          db_username must begin with a letter and contain only alphanumeric
 
−
          characters
 
−
  db_password:
 
−
    type: string
 
−
    description: The WordPress database admin account password
 
−
    default: admin
 
−
    hidden: true
 
−
    constraints:
 
−
      - length: { min: 1, max: 41 }
 
−
        description: db_username must be between 1 and 64 characters
 
−
      - allowed_pattern: '[a-zA-Z0-9]*'
 
−
        description: db_password must contain only alphanumeric characters
 
−
  db_root_password:
 
−
    type: string
 
−
    description: Root password for MySQL
 
−
     default: admin
 
−
     hidden: true
 
−
    constraints:
 
−
      - length: { min: 1, max: 41 }
 
−
        description: db_username must be between 1 and 64 characters
 
−
      - allowed_pattern: '[a-zA-Z0-9]*'
 
−
        description: db_password must contain only alphanumeric characters
 
−
 
 
−
resources:
 
−
  wordpress_instance:
 
−
     type: OS::Nova::Server
 
−
     properties:
 
−
      image: { get_param: image_id }
 
−
      flavor: { get_param: instance_type }
 
−
      key_name: { get_param: key_name }
 
−
      user_data:
 
−
        str_replace:
 
−
          template: |
 
−
            #!/bin/bash -v
 
−
 
 
−
            yum -y install mysql mysql-server httpd wordpress
 
−
            systemctl enable mysqld.service
 
−
            systemctl enable httpd.service
 
−
            systemctl start mysqld.service
 
−
            systemctl start httpd.service
 
−
 
 
−
            firewall-cmd --add-service=http
 
−
            firewall-cmd --permanent --add-service=http
 
−
 
 
−
            # Setup MySQL root password and create a user
 
−
            mysqladmin -u root password db_rootpassword
 
−
            cat << EOF | mysql -u root --password=db_rootpassword
 
−
            CREATE DATABASE db_name;
 
−
            GRANT ALL PRIVILEGES ON db_name.* TO "db_user"@"localhost"
 
−
            IDENTIFIED BY "db_password";
 
−
            FLUSH PRIVILEGES;
 
−
            EXIT
 
−
            EOF
 
−
 
 
−
            sed -i "/Deny from All/d" /etc/httpd/conf.d/wordpress.conf
 
−
            sed -i "s/Require local/Require all granted/" /etc/httpd/conf.d/wordpress.conf
 
−
            sed -i s/database_name_here/db_name/ /etc/wordpress/wp-config.php
 
−
            sed -i s/username_here/db_user/ /etc/wordpress/wp-config.php
 
−
            sed -i s/password_here/db_password/ /etc/wordpress/wp-config.php
 
−
 
 
−
            systemctl restart httpd.service
 
−
          params:
 
−
            db_rootpassword: { get_param: db_root_password }
 
−
            db_name: { get_param: db_name }
 
−
            db_user: { get_param: db_username }
 
−
            db_password: { get_param: db_password }
 
−
 
 
−
outputs:
 
−
   WebsiteURL:
 
−
     description: URL for Wordpress wiki
 
−
    value:
 
−
      str_replace:
 
−
        template: http://host/wordpress
 
−
        params:
 
−
          host: { get_attr: [wordpress_instance, first_address] }
 
 
</pre>
 
</pre>
−
 
  
 
* Retrieve a version of a template (Published version by default, with/without metadata)
 
* Retrieve a version of a template (Published version by default, with/without metadata)
Line 182: Line 79:
 
GET /templates/:id?meta=horizon&meta=documentation&version=b6059
 
GET /templates/:id?meta=horizon&meta=documentation&version=b6059
 
</pre>
 
</pre>
 +
 +
 
* View a template version history
 
* View a template version history
 
<pre>
 
<pre>
−
GET /teplates/:id/history
+
GET /templates/:id/history
 
{
 
{
 
     current: b6059,
 
     current: b6059,
Line 199: Line 98:
 
}
 
}
 
</pre>
 
</pre>
 +
 +
 
<pre>
 
<pre>
 
GET /templates/:id/history/:rev
 
GET /templates/:id/history/:rev

Revision as of 21:45, 3 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

  1. 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.
  2. As a service maintainer I would like to have a repository in which I can manage Heat templates and maintain associated metadata or tags.
  3. As a service provider, I want to have a centralized repository in which I can share institutional systems architecture knowledge encoded in Heat templates.
  4. 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.
  5. As a service provider, I need to be able to tag templates with searchable, indexable keywords.


Example Response

 template-revision: SHA1 or 1234
 
 tags:
   template-type: Application
   application-name: WordPress
   application-version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   flavor-weight: 3
   some-junk: junk
   color: sadness
   tattoo: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png


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-revision: SHA1 or 1234
  tags:
    keywords: wordpress, mysql
    template-type: Application
    application-name: WordPress
    application-version: 3.6.1
    flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
    flavor-weight: 3
    some-junk: junk
    color: sadness
    tattoo: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
    icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
  template:
    <raw template data>


  • Retrieve a list of templates
GET /templates?limit=100

template-revision: SHA1 or 1234
  tags:
    keywords: wordpress, mysql
    template-type: Application
    application-name: WordPress
    application-version: 3.6.1
    flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
    flavor-weight: 3
    some-junk: junk
    color: sadness
    tattoo: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
    icon-20x20: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
  template:
    <raw template data>
  • 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
Retrieved from "https://wiki.openstack.org/w/index.php?title=Heat/htr&oldid=37129"