diff options
Diffstat (limited to 'docs/platform/plugins')
| -rw-r--r-- | docs/platform/plugins/dmaap.rst | 439 | ||||
| -rw-r--r-- | docs/platform/plugins/dnsdesig.rst | 103 | ||||
| -rw-r--r-- | docs/platform/plugins/index.rst | 9 | ||||
| -rw-r--r-- | docs/platform/plugins/pgaas.rst | 130 | ||||
| -rw-r--r-- | docs/platform/plugins/sshkeyshare.rst | 61 |
5 files changed, 742 insertions, 0 deletions
diff --git a/docs/platform/plugins/dmaap.rst b/docs/platform/plugins/dmaap.rst new file mode 100644 index 00000000..b49eb4f8 --- /dev/null +++ b/docs/platform/plugins/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/platform/plugins/dnsdesig.rst b/docs/platform/plugins/dnsdesig.rst new file mode 100644 index 00000000..de67aef3 --- /dev/null +++ b/docs/platform/plugins/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/platform/plugins/index.rst b/docs/platform/plugins/index.rst new file mode 100644 index 00000000..35978384 --- /dev/null +++ b/docs/platform/plugins/index.rst @@ -0,0 +1,9 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. + +.. toctree:: + :maxdepth: 1 + + dmaap.rst + dnsdesig.rst + pgaas.rst + sshkeyshare.rst diff --git a/docs/platform/plugins/pgaas.rst b/docs/platform/plugins/pgaas.rst new file mode 100644 index 00000000..d27436f3 --- /dev/null +++ b/docs/platform/plugins/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/platform/plugins/sshkeyshare.rst b/docs/platform/plugins/sshkeyshare.rst new file mode 100644 index 00000000..8b5a0492 --- /dev/null +++ b/docs/platform/plugins/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 |