Jump to: navigation, search

Difference between revisions of "Heat/htr"

m
Line 37: Line 37:
 
<pre>
 
<pre>
 
POST /templates
 
POST /templates
−
{
+
 
−
     template: { ... raw template here ...},
+
  template-revision: SHA1 or 1234
−
     meta: {
+
  tags:
−
         documentation: "A compelling, accurate and enlightening explanation",
+
     template-type: Application
−
         horizon: {
+
    application-name: WordPress
−
                layout: { ... very complex layout format understood only by horizon ... },
+
    application-version: 3.6.1
−
                catagory: "Cool stuff",
+
    flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
−
                icons: {
+
    flavor-weight: 3
−
                    small: ... some remote reference or embedded binary data ...
+
    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
−
     tags: ["foo", "bar", "baz"]
+
  template:
−
}
+
    heat_template_version: 2013-05-23
 +
 
 +
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:
 +
 
 +
  key_name:
 +
    type: string
 +
    description : Name of a KeyPair to enable SSH access to the instance
 +
  instance_type:
 +
    type: string
 +
    description: Instance type for WordPress server
 +
    default: m1.small
 +
    constraints:
 +
      - allowed_values: [m1.small, m1.medium, m1.large]
 +
        description: instance_type must be one of m1.small, m1.medium or m1.large
 +
  image_id:
 +
    type: string
 +
    description: ID of the image to use for the WordPress server
 +
    default: F18-x86_64-cfntools
 +
    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)
 
<pre>
 
<pre>

Revision as of 21:29, 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:
    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:
    heat_template_version: 2013-05-23

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:

  key_name:
    type: string
    description : Name of a KeyPair to enable SSH access to the instance
  instance_type:
    type: string
    description: Instance type for WordPress server
    default: m1.small
    constraints:
      - allowed_values: [m1.small, m1.medium, m1.large]
        description: instance_type must be one of m1.small, m1.medium or m1.large
  image_id:
    type: string
    description: ID of the image to use for the WordPress server
    default: F18-x86_64-cfntools
    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] }


  • 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 /teplates/: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=37127"