Imports

imports enable the author of a blueprint to reuse blueprint files, or parts of them, and to use predefined types (e.g. from the types.yaml file).

Declaration

imports:
  - ...
  - ...

Example

imports:
  - 
    http://www.getcloudify.org/spec/cloudify/4.5.5/types.yaml

  - plugin:cloudify-openstack-plugin

node_templates:
  vm:
    type: cloudify.openstack.nodes.Server
  webserver:
    type: cloudify.nodes.WebServer

In the above example, two files are imported: the default types.yaml file provided by Cloudify that contains the cloudify.nodes.WebServer node type, and the OpenStack plugin YAML, which contains the cloudify.openstack.nodes.Server node type.

A few important things to know about importing YAML files:

Importing Plugins

From Cloudify 4.3 plugin import reference is available.

The plugin import format is plugin:PLUGIN_NAME?version=VERSION&distribution=DISTRIBUTION.

The parameters are optional and are aimed to resolve cases when the managers have multiple similar plugins with the same name. The optional parameters are:

Namespace

You can import any resource and add a namespace context to all included Cloudify DSL elements, with the exception of adding namespace to Cloudify basic types.

Import command with a namespace format is namespace--RESOURCE.

When a context of a namespace is added to a resource, all possible DSL elements that can be referenced from the using blueprint’s DSL elements will get the namespace prefix (namespace--RESOURCE). For example: node_type, data_types, inputs elements will get the namespace prefix, but specific node_type properties will not be namespaced because they can not be referenced from outside the context of that node type.

Namespace value validations

A single very basic rule is enforced on namespace possible values, they can not contain the namespace delimiter ‘–’ as a part of them. So the following namespace patterns are not valid options:

Example

In a blueprint a namespace can be added to every kind of resource, like the following:

imports:
 - types--
    http://www.getcloudify.org/spec/cloudify/4.5.5/types.yaml

 - plugin--plugin:cloudify-openstack-plugin
 - blueprint--blueprint:catalog_blueprint
 - local--local_blueprint.yaml
 - file_url--file://blueprint.yaml
 - ftp--ftp://other_blueprint.yaml

Using an imported blueprint’s resources is as following:

tosca_definitions_version: cloudify_dsl_1_3

inputs:
    some_input:
        description: Some input here.

node_types:
    test_type:
        properties:
          prop1:
            default: value
tosca_definitions_version: cloudify_dsl_1_3

imports:
    - some_namespace--test_blueprint

inputs:
    some_other_input:
        description: Some other input here.

node_types:
    other_type:
        derived_from: some_namespace--test_type:
        properties:
          prop1:
            default: { get_input: some_namespace--some_input }

Importing Catalog Blueprints

A catalog blueprint package (an uploaded blueprint to the Cloudify Manager) can be referenced in other blueprints.

The blueprint import format is NAMESPACE--blueprint:BLUEPRINT_ID, while specifying a namespace is a requirement and a namespace can only be given to a blueprint import once in a blueprint context.

This will allow you to share common blueprint definitions, just a node type or even entire architectures (like a common micro-service blueprint) or any other blueprint definitions, across any blueprint and reduce blueprint definitions duplication.

Note that in order to upload a blueprint using this kind of import command that imported blueprint must be already been uploaded. You also wouldn’t be able to delete an imported catalog blueprint when it’s in use by other blueprints until you delete it’s users or force delete it.

Example

imports:
 - namespace--blueprint:my_blueprint_id
 
 node_types:
    type_from_catalog_blueprint:
        derived_from: cloudify.nodes.Compute