add plugin rst files to docs directory

for i in dmaap dnsdesig pgaas sshkeyshare
do pandoc -f markdown -t rst -o docs/foo.rst foo/README.md
done

Change-Id: Icbde9093955ba2c65c8cf4dbf17e84f198205e13
Signed-off-by: Tony Hansen <tony@att.com>
Issue-ID: CCSDK-118

6 files changed, 738 insertions, 4 deletions

diff --git a/docs/dmaap.rst b/docs/dmaap.rst
new file mode 100644
index 0000000..b49eb4f
--- /dev/null
+++ b/docs/dmaap.rst
@@ -0,0 +1,439 @@
+Cloudify DMaaP Plugin
+---------------------
+
+Cloudify plugin for creating and managing DMaaP Data Router feeds and
+subscriptions and DMaaP Message Router topics. The plugin uses the DMaaP
+Bus Controller API.
+
+Plugin Support for DMaaP Data Router
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Plugin Types for DMaaP Data Router
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Cloudify type definitions for DMaaP Data Router nodes and
+relationships are defined in ```dmaap.yaml`` <./dmaap.yaml>`__.
+
+There are four node types for DMaaP Data Router:
+
+-  ``ccsdk.nodes.Feed``: This type represents a feed that does not yet
+   exist and that should be created when the install workflow is run
+   against a blueprint that contains a node of this type.
+
++------------------------+----------+-------------+---------------------------------------------------------------------------------------------+
+| Property               | Type     | Required?   | Description                                                                                 |
++========================+==========+=============+=============================================================================================+
+| feed\_name             | string   | no          | a name that identifies the feed (plugin will generate if absent)                            |
++------------------------+----------+-------------+---------------------------------------------------------------------------------------------+
+| feed\_version          | string   | no          | version number for the feed (feed\_name + feed\_version uniquely identify the feed in DR)   |
++------------------------+----------+-------------+---------------------------------------------------------------------------------------------+
+| feed\_description      | string   | no          | human-readable description of the feed                                                      |
++------------------------+----------+-------------+---------------------------------------------------------------------------------------------+
+| aspr\_classification   | string   | no          | AT&T ASPR classification of the feed                                                        |
++------------------------+----------+-------------+---------------------------------------------------------------------------------------------+
+
+-  ``ccsdk.nodes.ExistingFeed``: This type represents a feed that
+   already exists. Nodes of this type are placed in a blueprint so that
+   other nodes in the blueprint can be set up as publishers or
+   subscribers to the feed. The table below shows the properties that a
+   node of this type may have.
+
++------------+----------+-------------+---------------------------------------------------------------+
+| Property   | Type     | Required?   | Description                                                   |
++============+==========+=============+===============================================================+
+| feed\_id   | string   | yes         | Feed identifier assigned by DMaaP when the feed was created   |
++------------+----------+-------------+---------------------------------------------------------------+
+
+-  ``ccsdk.nodes.ExternalTargetFeed``: This type represents a feed
+   created in an external DMaaP environment (i.e., an environment that
+   the plugin cannot access to make provisioning requests, such as a
+   shared corporate system). Nodes of this type are placed in a
+   blueprint so that other feed nodes of type ``ccsdk.nodes.Feed`` or
+   ``ccsdk.nodes.ExistingFeed`` can be set up to "bridge" to external
+   feeds by publishing data to the external feeds. The table below shows
+   the properties that a node of this type may have.
+
++------------+----------+-------------+----------------------------------------------------------------+
+| Property   | Type     | Required?   | Description                                                    |
++============+==========+=============+================================================================+
+| url        | string   | yes         | The publish URL of the external feed.                          |
++------------+----------+-------------+----------------------------------------------------------------+
+| username   | string   | yes         | The username to be used when delivering to the external feed   |
++------------+----------+-------------+----------------------------------------------------------------+
+| userpw     | string   | yes         | The password to be used when delivering to the external feed   |
++------------+----------+-------------+----------------------------------------------------------------+
+
+*Note: These properties are usually obtained by manually creating a feed
+in the external DMaaP DR system and then creating a publisher for that
+feed.*
+
+-  ``ccsdk.nodes.ExternalSourceFeed``: This type represents a feed
+   created in an external DMaaP environment (i.e., an environment that
+   the plugin cannot access to makes provisioning requests, such as a
+   shared corporate system). Nodes of this type are place in a blueprint
+   so that they can be set up to "bridge" to other feed nodes of type
+   ``ccsdk.nodes.Feed`` or ``ccsdk.nodes.ExistingFeed``. This type has
+   no node properties, but when a bridge is set up, the url, username,
+   and password are attached to the node as runtime\_properties, using
+   the name of the target feed node as the top-level key.
+
+There are five relationship types for DMaaP Data Router:
+
+-  ``ccsdk.relationships.publish_files``, used to indicate that the
+   relationship's source node sends is a publisher to the Data Router
+   feed represented by the relationship's target node.
+-  ``ccsdk.relationships.subscribe_to_files``, used to indicate that the
+   relationship's source node is a subscriber to the Data Router feed
+   represented by the relationship's target node.
+-  ``ccsdk.relationships.bridges_to``, used to indicate that the
+   relationship's source node (a ``ccsdk.nodes.Feed`` or
+   ``ccsdk.nodes.ExistingFeed``) should be set up to forward data
+   ("bridge") to the relationship's target feed (another
+   ``ccsdk.nodes.Feed`` or ``ccsdk.nodes.ExistingFeed``).
+-  ``ccsdk.relationships.bridges_to_external``, used to indicate that
+   the relationship's source node (a ``ccsdk.nodes.Feed`` or
+   ``ccsdk.nodes.ExistingFeed``) should be set up to forward data
+   ("bridge") to the relationship's target node (a feed in an external
+   DMaaP system, represented by a ``ccsdk.nodes.ExternalTargetFeed``
+   node).
+-  ``ccsdk.relationships.bridges_from_external_to_internal``, used to
+   indicate the the relationship's source node (a feed in an external
+   DMaaP system, represented by a ``ccsdk.nodes.ExternalSourceFeed``
+   node) should be set up to forward date ("bridge") to the
+   relationship's target node (an internal ONAP feed, represented by a
+   ``ccsdk.nodes.Feed`` or ``ccsdk.nodes.ExistingFeed`` node).
+
+The plugin code implements the lifecycle operations needed to create and
+delete feeds and to add and remove publishers and subscribers. It also
+implements the operations needed to set up bridging between feeds.
+
+Interaction with Other Plugins
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When creating a new feed or processing a reference to an existing feed,
+the plugin operates independently of other plugins.
+
+When processing a ``ccsdk.relationships.publish_files`` relationship or
+a ``ccsdk.relationships.subscribe_to_files`` relationship, this plugin
+needs to obtain data from the source node and, in the case of
+``publish_files``, provide data to the source node. Certain conventions
+are therefore needed for passing data between this plugin and the
+plugins responsible for the source nodes in these relationships. In
+Cloudify, the mechanism for sharing data among plugins is the
+``ctx.instance.runtime_properties`` dictionary associated with each
+node.
+
+A given source node may have relationships with several feeds. For
+example, an ONAP DCAE data collector might publish two different types
+of data to two different feeds. An ONAP DCAE analytics module might
+subscribe to one feed to get input for its processing and publish its
+results to a different feed. When this DMaaP plugin and the plugin for
+the source node exchange information, they need to do in a way that lets
+them distinguish among different feeds. We do this through a simple
+convention: for each source node to feed relationship, the source node
+plugin will create a property in the source node's
+``runtime_properties`` dictionary. The name of the property will be the
+same as the name of the target node of the relationship. For instance,
+if a node has a ``publishes_files`` relationship with a target node
+named ``feed00``, then the plugin that's responsible for managing the
+source node with create an entry in the source node's
+``runtime_properties`` dictionary named ``feed00``. This entry itself
+will be a dictionary.
+
+The content of this data exchange dictionary depends on whether the
+source node is a publisher (i.e., the relationship is ``publish_files``)
+or a subscriber (i.e., the relationship is ``subscribe_to_files``).
+
+For the ``publish_files`` relationship, the data exchange dictionary has
+the following properties:
+
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+| Property       | Set by               | Description                                                                                      |
++================+======================+==================================================================================================+
+| location       | source node plugin   | the DMaaP location for the publisher, used to set up routing                                     |
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+| publish\_url   | DMaaP plugin         | the URL to which the publisher makes Data Router publish requests                                |
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+| log\_url       | DMaaP plugin         | the URL from which log data for the feed can be obtained                                         |
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+| username       | DMaaP plugin         | the username (generated by the DMaaP plugin) the publisher uses to authenticate to Data Router   |
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+| password       | DMaaP plugin         | the password (generated by the DMaaP plugin) the publisher uses to authenticate to Data Router   |
++----------------+----------------------+--------------------------------------------------------------------------------------------------+
+
+For the ``subscribe_to_files`` relationship, the data exchange
+dictionary has the following properties:
+
++-----------------+----------------------+-----------------------------------------------------------------------------------------+
+| Property        | Set by               | Description                                                                             |
++=================+======================+=========================================================================================+
+| location        | source node plugin   | the DMaaP location for the subscriber, used to set up routing                           |
++-----------------+----------------------+-----------------------------------------------------------------------------------------+
+| delivery\_url   | source node plugin   | the URL to which the Data Router should deliver files                                   |
++-----------------+----------------------+-----------------------------------------------------------------------------------------+
+| username        | source node plugin   | the username Data Router uses to authenticate to the subscriber when delivering files   |
++-----------------+----------------------+-----------------------------------------------------------------------------------------+
+| password        | source node plugin   | the username Data Router uses to authenticate to the subscriber when delivering file    |
++-----------------+----------------------+-----------------------------------------------------------------------------------------+
+
+Plugin Support for DMaaP Message Router
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Plugin Types for DMaaP Message Router
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Cloudify type definitions for DMaaP Message Router nodes and
+relationships are defined in ```dmaap.yaml`` <./dmaap.yaml>`__.
+
+There are two node types for DMaaP Message Router:
+
+-  ``ccsdk.nodes.Topic``: This type represents a topic that does not yet
+   exist and that should be created when the install workflow is run
+   against a blueprint that contains a node of this type.
+
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+| Property             | Type      | Required?   | Description                                                                 |
++======================+===========+=============+=============================================================================+
+| topic\_name          | string    | no          | a name that uniquely identifies the feed (plugin will generate if absent)   |
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+| topic\_description   | string    | no          | human-readable description of the feed                                      |
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+| txenable             | boolean   | no          | flag indicating whether transactions are enabled for this topic             |
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+| replication\_case    | string    | no          | type of replication required for the topic (defaults to no replication)     |
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+| global\_mr\_url      | string    | no          | Global MR host name for replication to a global MR instance                 |
++----------------------+-----------+-------------+-----------------------------------------------------------------------------+
+
+Note: In order to set up topics, a user should be familiar with message
+router and how it is configured, and this README is not the place to
+explain the details of message router. Here are a couple of pieces of
+information that might be helpful. Currently, the allowed values for
+``replication_case`` are:
+
+-  ``REPLICATION_NONE``
+-  ``REPLICATION_EDGE_TO_CENTRAL``
+-  ``REPLICATION_EDGE_TO_CENTRAL_TO_GLOBAL``
+-  ``REPLICATION_CENTRAL_TO_EDGE``
+-  ``REPLICATION_CENTRAL_TO_GLOBAL``
+-  ``REPLICATION_GLOBAL_TO_CENTRAL``
+-  ``REPLICATION_GLOBAL_TO_CENTRAL_TO_EDGE``
+
+The ``global_mr_url`` is actually a host name, not a full URL. It points
+to a host in a global message router cluster. (A 'global' message router
+cluster is one that's not part of ONAP.)
+
+-  ``ccsdk.nodes.ExistingTopic``: This type represents a topic that
+   already exists. Nodes of this type are placed in a blueprint so that
+   other nodes in the blueprint can be set up as publishers or
+   subscribers to the topic. The table below shows the properties that a
+   node of this type may have.
+
++------------+----------+-------------+--------------------------------------------+
+| Property   | Type     | Required?   | Description                                |
++============+==========+=============+============================================+
+| fqtn       | string   | yes         | fully-qualified topic name for the topic   |
++------------+----------+-------------+--------------------------------------------+
+
+Interaction with Other Plugins
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When creating a new topic or processing a reference to an existing
+topic, the plugin operates independently of other plugins.
+
+When processing a ``ccsdk.relationships.publish_events`` relationship or
+a ``ccsdk.relationships.subscribe_to_events`` relationship, this plugin
+needs to obtain data from and provide data to the source node. Certain
+conventions are therefore needed for passing data between this plugin
+and the plugins responsible for the source nodes in these relationships.
+In Cloudify, the mechanism for sharing data among plugins is the
+``ctx.instance.runtime_properties`` dictionary associated with each
+node.
+
+A given source node may have relationships with several topics. For
+example, an ONAP DCAE analytics module might subscribe to one topic to
+get input for its processing and publish its results to a different
+topic. When this DMaaP plugin and the plugin for the source node
+exchange information, they need to do in a way that lets them
+distinguish among different feeds. We do this through a simple
+convention: for each source node to topic relationship, the source node
+plugin will create a property in the source node's
+``runtime_properties`` dictionary. The name of the property will be the
+same as the name of the target node of the relationship. For instance,
+if a node has a ``publishes_events`` relationship with a target node
+named ``topic00``, then the plugin that's responsible for managing the
+source node with create an entry in the source node's
+``runtime_properties`` dictionary named ``topic00``. This entry itself
+will be a dictionary.
+
+For both types of relationship, the data exchange dictionary has the
+following properties:
+
++----------------+----------------------+----------------------------------------------------------------------------------+
+| Property       | Set by               | Description                                                                      |
++================+======================+==================================================================================+
+| location       | source node plugin   | the DMaaP location for the publisher or subscriber, used to set up routing       |
++----------------+----------------------+----------------------------------------------------------------------------------+
+| client\_role   | source node plugin   | the AAF client role that's requesting publish or subscribe access to the topic   |
++----------------+----------------------+----------------------------------------------------------------------------------+
+| topic\_url     | DMaaP plugin         | the URL for accessing the topic to publish or receive events                     |
++----------------+----------------------+----------------------------------------------------------------------------------+
+
+Interaction with Consul configuration store
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In addition to storing the results of DMaaP Data Router and DMaaP
+Message Router provisioning operations in ``runtime_properties``, the
+DMaaP plugin also stores these results into the ONAP configuration
+store, which resides in a `Consul key-value
+store <https://www.consul.io/>`__. This allows DMaaP clients (components
+that act as publishers, subscribers, or both) to retrieve their DMaaP
+configuration information from Consul, rather than having the plugin
+that deploys the client directly configure the client using data in
+``runtime_properties``.
+
+The ``runtime_properties`` for a client must contain a property called
+``service_component_name``. If this property is not present, the plugin
+will raise a NonRecoverableError and cause the installation to fail.
+
+If ``service_component_name`` is present, then the plugin will use a
+Consul key consisting of the value of ``service_component_name``
+prepended to the fixed string ``:dmaap``. For example, if the
+``service_component_name`` is ``client123``, the plugin will use
+``client123:dmaap`` as the key for storing DMaaP information into
+Consul. Information for all of the feeds and topics for a client are
+stored under the same key.
+
+The value stored is a nested JSON object. At the top level of the object
+are properties representing each topic or feed for which the component
+is a publisher or subscriber. The name of the property is the node name
+of the target feed or topic. The value of the property is another JSON
+object that corresponds to the dictionary that the plugin created in
+``runtime_properties`` corresponding to the target feed or topic. Note
+that the information in Consul includes all of the properties for the
+feed or topic, those set by the source node plugin as well as those set
+by the DMaaP plugin.
+
+Examples:
+
+Data Router publisher, target feed ``feed00``:
+
+::
+
+    {
+      "feed00": {
+        "username": "rC9QR51I",
+        "log_url": "https://dmaap.example.com/feedlog/972",
+        "publish_url": "https://dmaap.example.com/publish/972",
+        "location": "loc00",
+        "password": "QOQeUh5KLR",
+        "publisher_id": "972.360gm"
+      }
+    }
+
+Data Router subscriber, target feed ``feed01``:
+
+::
+
+    {
+      "feed01": {
+        "username": "drdeliver",
+        "password": "1loveDataR0uter",
+        "location": "loc00",
+        "delivery_url": "https://example.com/whatever",
+        "subscriber_id": "1550"
+      }
+    }
+
+Message Router publisher to ``topic00``, subscriber to ``topic01``. Note
+how each topic appears as a top-level property in the object.
+
+::
+
+    {
+      "topic00": {
+        "topic_url": "https://dmaap.example.com:3905/events/org.onap.ccsdk.dmaap.FTL2.outboundx",
+        "client_role": "org.onap.ccsdk.member",
+        "location": "loc00",
+        "client_id": "1494621774522"
+      },
+      "topic01": {
+        "topic_url": "https://dmaap.example.com:3905/events/org.onap.ccsdk.dmaap.FTL2.inboundx",
+        "client_role": "org.onap.ccsdk.member",
+        "location": "loc00",
+        "client_id": "1494621778627"
+      }
+    }
+
+Packaging and installing
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The DMaaP plugin is meant to be used as a `Cloudify managed
+plugin <http://docs.getcloudify.org/3.4.0/plugins/using-plugins/>`__.
+Managed plugins are packaged using
+```wagon`` <https://github.com/cloudify-cosmo/wagon>`__.
+
+To package this plugin, executing the following command in the top-level
+directory of this plugin, from a Python environment in which ``wagon``
+has been installed:
+
+::
+
+    wagon create -s . -r -o /path/to/directory/for/wagon/output
+
+Once the wagon file is built, it can be uploaded to a Cloudify Manager
+host using the ``cfy plugins upload`` command described in the
+documentation above.
+
+Managed plugins can also be loaded at the time a Cloudify Manager host
+is installed, via the installation blueprint and inputs file. We expect
+that this plugin will be loaded at Cloudify Manager installation time,
+and that ``cfy plugins upload`` will be used only for delivering patches
+between releases.
+
+Configuration
+~~~~~~~~~~~~~
+
+The plugin needs to be configured with certain parameters needed to
+access the DMaaP Bus Controller. In keeping with the ONAP architecture,
+this information is stored in Consul.
+
+The plugin finds the address and port of the DMaaP Bus Controller using
+the Consul service discovery facility. The plugin expects the Bus
+Controller to be registered under the name ``dmaap_bus_controller``.
+
+Additional parameters come from the ``dmaap`` key in the Cloudify
+Manager's Consul configuration, which is stored in the Consul KV store
+under the key name 'cloudify\_manager'. The table below lists the
+properties in the configuration:
+
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+| Property       | Type     | Required?   | Default      | Description                                                                                 |
++================+==========+=============+==============+=============================================================================================+
+| ``username``   | string   | Yes         | (none)       | The username for logging into DMaaP Bus Controller                                          |
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+| ``password``   | string   | Yes         | (none)       | The password for logging into DMaaP Bus Controller                                          |
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+| ``owner``      | string   | Yes         | (none)       | The name to be used as the owner for entities created by the plugin                         |
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+| ``protocol``   | string   | No          | ``https``    | The protocol (URL scheme) used to access the DMaaP bus controller (``http`` or ``https``)   |
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+| ``path``       | string   | No          | ``webapi``   | The path to the root of the DMaaP Bus Controller API endpoint                               |
++----------------+----------+-------------+--------------+---------------------------------------------------------------------------------------------+
+
+Here is an example of a Cloudify Manager configuration object showing
+only the ``dmaap`` key:
+
+::
+
+    {
+      "dmaap": {
+        "username": "dmaap.client@ccsdkorch.onap.org",
+        "password": "guessmeifyoucan"
+        "owner": "ccsdkorc"
+      },
+
+      (other configuration here)
+
+    }
+
diff --git a/docs/dnsdesig.rst b/docs/dnsdesig.rst
new file mode 100644
index 0000000..de67aef
--- /dev/null
+++ b/docs/dnsdesig.rst
@@ -0,0 +1,103 @@
+.. raw:: html
+
+   <!--
+   ============LICENSE_START=======================================================
+   org.onap.ccsdk
+   ================================================================================
+   Copyright (c) 2017 AT&T Intellectual Property. All rights reserved.
+   ================================================================================
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+        http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+   ============LICENSE_END=========================================================
+   -->
+
+DNS/Designate Plugin
+====================
+
+Cloudify DNS/Designate plugin description # Description The
+DNS/Designate plugin extends the concepts of the Cloudify OpenStack
+plugin to include using the DNS/Designate service, to set up and tear
+down DNS "A" and "CNAME" records, as part of a Cloudify blueprint. #
+Plugin Requirements \* Python versions \* 2.7.x
+
+Note: These requirements apply to the VM where Cloudify Manager itself
+runs.
+
+Note: Cloudify Manager, itself, requires Python 2.7.x (and CentOS 7).
+
+Types
+=====
+
+ccsdk.nodes.dns.arecord
+-----------------------
+
+**Derived From:** cloudify.nodes.Root
+
+**Properties:**
+
+-  ``fqdn`` (required string) The FQDN for the set of DNS A records to
+   be managed. The DNS zone to which this FQDN belongs is assumed to be
+   the entire FQDN following the first dot. This value must not end with
+   a dot. The provided openstack credentials must allow updating records
+   in the DNS zone.
+-  ``ttl`` (optional integer default=300) The time to live, in seconds,
+   of the DNS entries.
+-  ``openstack`` (required map) The set of configuration parameters to
+   use for accessing the OpenStack DNS service: username, password,
+   tenant\_name, auth\_url, and region.
+
+**Mapped Operations:**
+
+-  ``cloudify.interfaces.lifecycle.create`` Creates or updates the type
+   "A" recordset for the specified FQDN. \*\* ``Inputs:`` \*\*\*
+   ``args`` Key-value configuration \*\*\*\* ``ip_addresses`` (required
+   sequence of string) A non-empty list of IP addresses corresponding to
+   the FQDN
+-  ``cloudify.interfaces.lifecycle.delete`` Deletes the type "A"
+   recordset, if any, for the specified FQDN.
+
+**Attributes:** This type has no runtime attributes
+
+ccsdk.nodes.dns.cnamerecord
+---------------------------
+
+**Derived From:** cloudify.nodes.Root
+
+**Properties:**
+
+-  ``fqdn`` (required string) The FQDN for the DNS CNAME record to be
+   managed. The DNS zone to which this FQDN belongs is assumed to be the
+   entire FQDN following the first dot. This value must not end with a
+   dot. The provided openstack credentials must allow updating records
+   in the DNS zone.
+-  ``ttl`` (optional integer default=300) The time to live, in seconds,
+   of the DNS entry.
+-  ``openstack`` (required map) The set of configuration parameters to
+   use for accessing the OpenStack DNS service: username, password,
+   tenant\_name, auth\_url, and region.
+
+**Mapped Operations:**
+
+-  ``cloudify.interfaces.lifecycle.create`` Creates or updates the type
+   "CNAME" recordset for the specified FQDN. \*\* ``Inputs:`` \*\*\*
+   ``args`` Key-value configuration \*\*\*\* ``cname`` (required string)
+   The FQDN that this CNAME record should point to. This value must not
+   end with at dot.
+-  ``cloudify.interfaces.lifecycle.delete`` Deletes the type "CNAME"
+   recordset, if any, for the specified FQDN.
+
+**Attributes:** This type has no runtime attributes
+
+Relationships
+=============
+
+This plugin does not define or use any relationships
diff --git a/docs/index.rst b/docs/index.rst
index 833e1aa..3597838 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,8 +1,9 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 
-TODO Add files to toctree and delete this header
-------------------------------------------------
 .. toctree::
    :maxdepth: 1
 
-
+   dmaap.rst
+   dnsdesig.rst
+   pgaas.rst
+   sshkeyshare.rst
diff --git a/docs/pgaas.rst b/docs/pgaas.rst
new file mode 100644
index 0000000..d27436f
--- /dev/null
+++ b/docs/pgaas.rst
@@ -0,0 +1,130 @@
+PGaaS Plugin
+============
+
+Cloudify PGaaS plugin description and configuraiton # Description The
+PGaaS plugin allows users to deploy PostgreSQL application databases,
+and retrieve access credentials for such databases, as part of a
+Cloudify blueprint. # Plugin Requirements \* Python versions \* 2.7.x \*
+System dependencies \* psycopg2
+
+Note: These requirements apply to the VM where Cloudify Manager itself
+runs.
+
+Note: The psycopg2 requirement is met by running "yum install
+python-psycopg2" on the Cloudify Manager VM.
+
+Note: Cloudify Manager, itself, requires Python 2.7.x (and Centos 7).
+
+Types
+=====
+
+dcae.nodes.pgaas.cluster
+------------------------
+
+**Derived From:** cloudify.nodes.Root
+
+**Properties:**
+
+-  ``writerfqdn`` (required string) The FQDN used for read-write access
+   to the cluster containing the postgres database instance. This is
+   used to identify and access a particular database instance and to
+   record information about that instance on Cloudify Manager.
+-  ``use_existing`` (optional boolean default=false) This is used to
+   reference a database instance, in one blueprint, that was deployed in
+   a different one. If it is ``true``, then the ``readerfqdn`` property
+   must not be set and this node must not have any
+   ``dcae.relationships.pgaas_cluster_uses_sshkeypair`` relationships.
+   If it is ``false``, then this node must have exactly one
+   ``dcae.relationships.pgaas_cluster_uses_sshkeypair`` relationship.
+-  ``readerfqdn`` (optional string default=value of ``writerfqdn``) The
+   FQDN used for read-only access to the cluster containing the postgres
+   database instance, if different than the FQDN used for read-write
+   access. This will be used by viewer roles.
+
+**Mapped Operations:**
+
+-  ``cloudify.interfaces.lifecycle.create`` validates and records
+   information about the cluster on the Cloudify Manager server in
+   /opt/manager/resources/pgaas/``writerfqdn``.
+-  ``cloudify.interfaces.lifecycle.delete`` deletes previously recorded
+   information from the Cloudify Manager server.
+
+Note: When ``use_existing`` is ``true``, the create operation validates
+but does not record, and delete does nothing. Delete also does nothing
+when validation has failed.
+
+**Attributes:** This type has no runtime attributes
+
+dcae.nodes.pgaas.database
+-------------------------
+
+**Derived From:** cloudify.nodes.Root
+
+**Properties:** \* ``name`` (required string) The name of the
+application database, in postgres. This name is also used to create the
+names of the roles used to access the database, and the schema made
+available to users of the database. \* ``use_existing`` (optional
+boolean default=false) This is used to reference an application
+database, in one blueprint, that was deployed in a different one. If
+true, and this node has a
+dcae.relationships.database\_runson\_pgaas\_cluster relationship, the
+dcae.nodes.pgaas.cluster node that is the target of that relationship
+must also have it's ``use_existing`` property set to true. \*
+``writerfqdn`` (optional string) This can be used as an alternative to
+specifying the cluster, for the application database, with a
+dcae.relationships.database\_runson\_pgaas\_cluster relationship to a
+dcae.nodes.pgaas.cluster node. Exactly one of the two options must be
+used. The relationship method must be used if this blueprint is
+deploying both the cluster and the application database on the cluster.
+
+**Mapped Operations:**
+
+-  ``cloudify.interfaces.lifecycle.create`` creates the application
+   database, and various roles for admin/user/viewer access to it.
+-  ``cloudify.interfaces.lifecycle.delete`` deletes the application
+   database and roles
+
+Note: When ``use_existing`` is true, create and delete do not create or
+delete the application database or associated roles. Create still sets
+runtime attributes (see below).
+
+**Attributes:**
+
+-  ``admin`` a dict containing access information for adminstrative
+   access to the application database.
+-  ``user`` a dict containing access information for user access to the
+   application database.
+-  ``viewer`` a dict containing access information for read-only access
+   to the application database.
+
+The keys in the access information dicts are as follows:
+
+-  ``database`` the name of the application database.
+-  ``host`` the appropriate FQDN for accessing the application database,
+   (writerfqdn or readerfqdn, based on the type of access).
+-  ``user`` the user role for accessing the database.
+-  ``password`` the password corresponding to the user role.
+
+Relationships
+=============
+
+dcae.relationships.pgaas\_cluster\_uses\_sshkeypair
+---------------------------------------------------
+
+**Description:** A relationship for binding a dcae.nodes.pgaas.cluster
+node to the dcae.nodes.ssh.keypair used by the cluster to initialize the
+database access password for the postgres role. The password for the
+postgres role is expected to be the hex representation of the MD5 hash
+of 'postgres' and the contents of the id\_rsa (private key) file for the
+ssh keypair. A dcae.nodes.pgaas.cluster node must have such a
+relationship if and only if it's use\_existing property is false. ##
+dcae.relationships.dcae.relationships.database\_runson\_pgaas\_cluster
+**Description:** A relationship for binding a dcae.nodes.pgaas.database
+node to the dcae.nodes.pgaas.cluster node that contains the application
+database. A dcae.nodes.pgaas.database node must have either such a
+relationship or a writerfqdn property. The writerfqdn property cannot be
+used if the cluster is created in the same blueprint as the application
+database. ## dcae.relationships.application\_uses\_pgaas\_database
+**Description:** A relationship for binding a node that needs
+application database access information to the dcae.nodes.pgaas.database
+node for that application database.
diff --git a/docs/sshkeyshare.rst b/docs/sshkeyshare.rst
new file mode 100644
index 0000000..8b5a049
--- /dev/null
+++ b/docs/sshkeyshare.rst
@@ -0,0 +1,61 @@
+.. raw:: html
+
+   <!--
+   ============LICENSE_START=======================================================
+   org.onap.ccsdk
+   ================================================================================
+   Copyright (c) 2017 AT&T Intellectual Property. All rights reserved.
+   ================================================================================
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+        http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+   ============LICENSE_END=========================================================
+   -->
+
+sshkeyshare plugin
+==================
+
+Cloudify plugin for creating ssh key pairs on the fly # Description The
+sshkeyshare Cloudify plugin creates an ssh key pair that can be used, by
+VMs or other containers spun up by a Cloudify blueprint, for
+establishing connections, among them. The blue print can, for example,
+provide the private key to one VM and the public one to another, as part
+of their initial configuration, to allow the one with the private key to
+automatically connect to the other one, to run commands. # Plugin
+Requirements \* Python versions \* 2.7.x
+
+Note: These requirements apply to the VM where Cloudify Manager itself
+runs.
+
+Note: Cloudify Manager, itself, requires Pythong 2.7.x (and CentOS 7).
+
+Types
+=====
+
+ccsdk.nodes.ssh.keypair
+-----------------------
+
+**Derived From:** cloudify.nodes.Root
+
+**Properties:** This type has no properties
+
+**Mapped Operations:** \* ``cloudify.interfaces.lifecycle.create``
+Creates a new ssh keypair using ssh-keygen
+
+**Attributes:** \* ``public`` A string containing the public key of the
+newly created keypair. \* ``base64private`` A single line base-64
+encoded representation of the content of the private key file for the
+newly created keypair.
+
+Relationships
+=============
+
+This plugin does not define or use any relationships
diff --git a/pgaas/tox.ini b/pgaas/tox.ini
index 884c079..28f1f3f 100644
--- a/pgaas/tox.ini
+++ b/pgaas/tox.ini
@@ -25,4 +25,4 @@ deps=
     requests
     coverage
     pytest-cov
-commands=pytest --junitxml xunit-results.xml --cov {envsitepackagesdir}/pgaas --cov-report=xml
+commands=pytest --junitxml xunit-results.xml --cov {envsitepackagesdir}/pgaas --cov-report xml --cov-report html