+++ /dev/null
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS =
-SPHINXBUILD = sphinx-build
-PAPER =
-BUILDDIR = _build
-
-# User-friendly check for sphinx-build
-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
-$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
-endif
-
-# Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
-
-help:
- @echo "Please use \`make <target>' where <target> is one of"
- @echo " html to make standalone HTML files"
- @echo " dirhtml to make HTML files named index.html in directories"
- @echo " singlehtml to make a single large HTML file"
- @echo " pickle to make pickle files"
- @echo " json to make JSON files"
- @echo " htmlhelp to make HTML files and a HTML help project"
- @echo " qthelp to make HTML files and a qthelp project"
- @echo " devhelp to make HTML files and a Devhelp project"
- @echo " epub to make an epub"
- @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
- @echo " latexpdf to make LaTeX files and run them through pdflatex"
- @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
- @echo " text to make text files"
- @echo " man to make manual pages"
- @echo " texinfo to make Texinfo files"
- @echo " info to make Texinfo files and run them through makeinfo"
- @echo " gettext to make PO message catalogs"
- @echo " changes to make an overview of all changed/added/deprecated items"
- @echo " xml to make Docutils-native XML files"
- @echo " pseudoxml to make pseudoxml-XML files for display purposes"
- @echo " linkcheck to check all external links for integrity"
- @echo " doctest to run all doctests embedded in the documentation (if enabled)"
-
-clean:
- rm -rf $(BUILDDIR)/*
-
-html:
- $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
- $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
- $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
- @echo
- @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-pickle:
- $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
- @echo
- @echo "Build finished; now you can process the pickle files."
-
-json:
- $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
- @echo
- @echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
- $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
- @echo
- @echo "Build finished; now you can run HTML Help Workshop with the" \
- ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
- $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
- @echo
- @echo "Build finished; now you can run "qcollectiongenerator" with the" \
- ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
- @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/cloudify-openstack-plugin.qhcp"
- @echo "To view the help file:"
- @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/cloudify-openstack-plugin.qhc"
-
-devhelp:
- $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
- @echo
- @echo "Build finished."
- @echo "To view the help file:"
- @echo "# mkdir -p $$HOME/.local/share/devhelp/cloudify-openstack-plugin"
- @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/cloudify-cli"
- @echo "# devhelp"
-
-epub:
- $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
- @echo
- @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-latex:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo
- @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
- @echo "Run \`make' in that directory to run these through (pdf)latex" \
- "(use \`make latexpdf' here to do that automatically)."
-
-latexpdf:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through pdflatex..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-latexpdfja:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through platex and dvipdfmx..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
- $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
- @echo
- @echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
- $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
- @echo
- @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo
- @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
- @echo "Run \`make' in that directory to run these through makeinfo" \
- "(use \`make info' here to do that automatically)."
-
-info:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo "Running Texinfo files through makeinfo..."
- make -C $(BUILDDIR)/texinfo info
- @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-gettext:
- $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
- @echo
- @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-changes:
- $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
- @echo
- @echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
- $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
- @echo
- @echo "Link check complete; look for any errors in the above output " \
- "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
- $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
- @echo "Testing of doctests in the sources finished, look at the " \
- "results in $(BUILDDIR)/doctest/output.txt."
-
-xml:
- $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
- @echo
- @echo "Build finished. The XML files are in $(BUILDDIR)/xml."
-
-pseudoxml:
- $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
- @echo
- @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
+++ /dev/null
-
-
-Changelog
-=========
-
-.. include:: ../CHANGELOG.txt
-
+++ /dev/null
-# -*- coding: utf-8 -*-
-#
-# cloudify-openstack-plugin documentation build configuration file, created by
-# sphinx-quickstart on Tue Nov 8 14:02:23 2016.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys
-import os
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = [
- 'sphinx.ext.autodoc',
- 'sphinx.ext.intersphinx',
- 'sphinx.ext.todo',
- 'sphinx.ext.viewcode',
- 'sphinxify',
-]
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = u'cloudify-openstack-plugin'
-copyright = u'2016-17 GigaSpaces Technologies Ltd.'
-author = u'GigaSpaces Technologies Ltd.'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = u'2.0'
-# The full version, including alpha/beta/rc tags.
-release = u'2.0'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
-language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This patterns also effect to html_static_path and html_extra_path
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = True
-
-
-# -- Options for HTML output ----------------------------------------------
-
-# The theme to use for HTML and HTML Help pages. See the documentation for
-# a list of builtin themes.
-# html_theme = 'sphinx-rtd-theme'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = []
-
-# The name for this set of Sphinx documents.
-# "<project> v<release> documentation" by default.
-#html_title = u'cloudify-openstack-plugin v1.0a1'
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (relative to this directory) to use as a favicon of
-# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#html_extra_path = []
-
-# If not None, a 'Last updated on:' timestamp is inserted at every page
-# bottom, using the given strftime format.
-# The empty string is equivalent to '%b %d, %Y'.
-#html_last_updated_fmt = None
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
-# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr', 'zh'
-#html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# 'ja' uses this config value.
-# 'zh' user can custom change `jieba` dictionary path.
-#html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'cloudify-openstack-plugindoc'
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-
-# Latex figure (float) alignment
-#'figure_align': 'htbp',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-# author, documentclass [howto, manual, or own class]).
-latex_documents = [
- (master_doc, 'cloudify-openstack-plugin.tex', u'cloudify-openstack-plugin Documentation',
- u'GigaSpaces Technologies Ltd.', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
- (master_doc, 'cloudify-openstack-plugin', u'cloudify-openstack-plugin Documentation',
- [author], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-# dir menu entry, description, category)
-texinfo_documents = [
- (master_doc, 'cloudify-openstack-plugin', u'cloudify-openstack-plugin Documentation',
- author, 'cloudify-openstack-plugin', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
-
-
-# Example configuration for intersphinx: refer to the Python standard library.
-intersphinx_mapping = {'https://docs.python.org/2/': None}
-
-
-# SCVersioning
-scv_show_banner = True
-scv_banner_greatest_tag = True
+++ /dev/null
-.. _config:
-
-Openstack Configuration
-=======================
-
-The Openstack plugin requires credentials and endpoint setup information in order to authenticate and interact with Openstack.
-
-This information will be gathered by the plugin from the following sources,
-each source possibly partially or completely overriding values gathered from previous ones:
-
-1. environment variables for each of the configuration parameters.
-2. JSON file at ``~/openstack_config.json`` or at a path specified by the value of an environment variable named ``OPENSTACK_CONFIG_PATH``
-3. values specified in the ``openstack_config`` property for the node whose operation is currently getting executed (in the case of relationship operations, the ``openstack_config`` property of either the **source** or **target** nodes will be used if available, with the **source**'s one taking precedence).
-
-The structure of the JSON file in section (2), as well as of the ``openstack_config`` property in section (3), is as follows:
-
-.. highlight:: json
-
-::
-
- {
- "username": "",
- "password": "",
- "tenant_name": "",
- "auth_url": "",
- "region": "",
- "nova_url": "",
- "neutron_url": "",
- "custom_configuration": ""
- }
-
-* ``username`` username for authentication with Openstack Keystone service.
-* ``password`` password for authentication with Openstack Keystone service.
-* ``tenant_name`` name of the tenant to be used.
-* ``auth_url`` URL of the Openstack Keystone service.
-
- .. attention:: New in 2.0
-
- ``auth_url`` must include the full keystone auth URL, including the version number.
-
-* ``region`` Openstack region to be used. This may be optional when there's but a single region.
-* ``nova_url`` (**DEPRECATED** - instead, use ``custom_configuration`` to pass ``endpoint_override`` directly to the Nova client) explicit URL for the Openstack Nova service. This may be used to override the URL for the Nova service that is listed in the Keystone service.
-* ``neutron_url`` (**DEPRECATED** - instead, use ``custom_configuration`` to pass ``endpoint_url`` directly to the Neutron client) explicit URL for the Openstack Neutron service. This may be used to override the URL for the Neutron service that is listed in the Keystone service.
-* ``custom_configuration`` a dictionary which allows overriding or directly passing custom configuration parameter to each of the Openstack clients, by using any of the relevant keys: ``keystone_client``, ``nova_client``, ``neutron_client`` or ``cinder_client``.
- * Parameters passed directly to Openstack clients using the ``custom_configuration`` mechanism will override other definitions (e.g. any of the common Openstack configuration parameters listed above, such as ``username`` and ``tenant_name``)
- * The following is an example for the usage of the ``custom_configuration`` section in a blueprint:
-
-.. highlight:: yaml
-
-::
-
- custom_configuration:
- nova_client:
- endpoint_override: nova-endpoint-url
- nova_specific_key_1: value_1
- nova_specific_key_2: value_2
- neutron_client:
- endpoint_url: neutron-endpoint-url
- keystone_client:
- ..
- cinder_client:
- ..
-
-
-The environment variables mentioned in (1) are the standard Openstack environment variables equivalent to the ones in the JSON file or ``openstack_config`` property. In their respective order, they are:
-
-* ``OS_USERNAME``
-* ``OS_PASSWORD``
-* ``OS_TENANT_NAME``
-* ``OS_AUTH_URL``
-* ``OS_REGION_NAME``
-* ``NOVACLIENT_BYPASS_URL``
-* ``OS_URL``
-
-**Note**: ``custom_configuration`` doesn't have an equivalent standard Openstack environment variable.
-
-
- The Openstack manager blueprint stores the Openstack configuration used for the bootstrap process in a JSON file as described in (2) at
- ``~/openstack-config.json``.
- Therefore, if they've been used for bootstrap,
- the Openstack configuration for applications isn't required as the plugin will default to these same settings.
-
+++ /dev/null
-
-.. highlight:: yaml
-
-Examples
-========
-
-Example I
----------
-
-This example will show how to use most of the types in this plugin,
-as well as how to make the relationships between them.
-
-We'll see how to create a server with a security group set on it and a floating_ip associated to it,
-on a subnet in a network.
-
-
-The following is an excerpt from the blueprint's `blueprint`.`nodes` section::
-
- my_floating_ip:
- type: cloudify.openstack.nodes.FloatingIP
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- floating_network_name: Ext-Net
-
-
- my_network:
- type: cloudify.openstack.nodes.Network
- properties:
- resource_id: my_network_openstack_name
-
-
- my_subnet:
- type: cloudify.openstack.nodes.Subnet
- properties:
- resource_id: my_subnet_openstack_name
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- cidr: 1.2.3.0/24
- ip_version: 4
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- cidr: 1.2.3.0/24
- ip_version: 4
- relationships:
- - target: my_network
- type: cloudify.relationships.contained_in
-
-
- my_security_group:
- type: cloudify.openstack.nodes.SecurityGroup
- properties:
- resource_id: my_security_group_openstack_name
- rules:
- - remote_ip_prefix: 0.0.0.0/0
- port: 8080
-
-
- my_server:
- type: cloudify.openstack.nodes.Server
- properties:
- resource_id: my_server_openstack_name
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- relationships:
- - target: my_network
- type: cloudify.relationships.connected_to
- - target: my_subnet
- type: cloudify.relationships.depends_on
- - target: my_floating_ip
- type: cloudify.openstack.server_connected_to_floating_ip
- - target: my_security_group
- type: cloudify.openstack.server_connected_to_security_group
-
-
-1. Creates a floating IP, whose node name is ``my_floating_ip``, and whose floating_network_name is ``Ext-Net`` (This value represents the name of the external network).
-2. Creates a network, whose node name is ``my_network``, and whose name on Openstack is ``my_network_openstack_name``.
-3. Creates a subnet, whose node name is ``my_subnet``, and whose name on Openstack is ``my_subnet_openstack_name``. The subnet's address range is defined to be 1.2.3.0 - 1.2.3.255 using the ``cidr`` parameter, and the subnet's IP version is set to version 4. The subnet will be set on the ``my_network_openstack_name`` network because of the relationship to the ``my_network`` node.
-4. Creates a security_group, whose node name is ``my_security_group``, and whose name on Openstack is ``my_security_group_openstack_Name``. The security group is set with a single rule, which allows all traffic (since we use the address range ``0.0.0.0/0``) to port ``8080`` (default direction is *ingress*).
-5. Creates a server, whose node name is ``my_server``, and whose name on openstack is ``my_server_openstack_name``. The server is set with an image and flavor IDs. The server is set with multiple relationships:
-
- - A relationship to the ``my_network`` node: Through this relationship,
- the server will be automatically placed on the ``my_network_openstack_name`` network.
- - A relationship to the ``my_subnet`` node:
- This relationship is strictly for ensuring the order of creation is correct,
- as the server requires the ``my_subnet_openstack_name`` subnet to exist before it can be created on it.
- - A relationship to the ``my_floating_ip`` node:
- This designated relationship type will take care of associating the server with the floating IP represented by the ``my_floating_ip`` node.
- - A relationship with the ``my_security_group`` node:
- This relationship will take care of setting the server up with the security group represented by the ``my_security_group`` node.
-
-
-Example II
-----------
-
-This example will show how to use the ``router`` and ``port`` types, as well as some of the relationships that were missing from Example I.
-
-We'll see how to create a server connected to a port, where the port is set on a subnet in a network, and has a security group set on it. Finally, we'll see how this subnet connects to a router and from there to the external network.
-
-
-The following is an excerpt from the blueprint's ``blueprint``.``node_templates`` section::
-
- my_network:
- type: cloudify.openstack.nodes.Network
- properties:
- resource_id: my_network_openstack_name
-
-
- my_security_group:
- type: cloudify.openstack.nodes.SecurityGroup
- properties:
- resource_id: my_security_group_openstack_name
- rules:
- - remote_ip_prefix: 0.0.0.0/0
- port: 8080
-
-
- my_subnet:
- type: cloudify.openstack.nodes.Subnet
- properties:
- resource_id: my_subnet_openstack_name
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- cidr: 1.2.3.0/24
- ip_version: 4
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- cidr: 1.2.3.0/24
- ip_version: 4
- relationships:
- - target: my_network
- type: cloudify.relationships.contained_in
- - target: my_router
- type: cloudify.openstack.subnet_connected_to_router
-
-
- my_port:
- type: cloudify.openstack.nodes.Port
- properties:
- resource_id: my_port_openstack_name
- relationships:
- - target: my_network
- type: cloudify.relationships.contained_in
- - target: my_subnet
- type: cloudify.relationships.depends_on
- - target: my_security_group
- type: cloudify.openstack.port_connected_to_security_group
-
-
- my_router:
- type: cloudify.openstack.nodes.Router
- properties:
- resource_id: my_router_openstack_Name
-
-
- my_server:
- type: cloudify.openstack.nodes.Server
- properties:
- cloudify_agent:
- user: ubuntu
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- relationships:
- - target: my_port
- type: cloudify.openstack.server_connected_to_port
-
-
-1. Creates a network. See Example I for more information.
-
-2. Creates a security group. See Example I for more information.
-
-3. Creates a subnet. This is again similar to what we've done in Example I. The difference here is that the subnet has an extra relationship set towards a router.
-
-4. Creates a port, whose node name is ``my_port``, and whose name on Openstack is ``my_port_openstack_name``. The port is set with multiple relationships:
-
- - A relationship to the ``my_network`` node: Through this relationship, the port will be automatically placed on the ``my_network_openstack_name`` network.
- - A relationship to the ``my_subnet`` node: This relationship is strictly for ensuring the order of creation is correct, as the port requires the ``my_subnet_openstack_name`` subnet to exist before it can be created on it.
- - A relationship to the ``my_security_group`` node: This designated relationship type will take care of setting the ``my_security_group_openstack_name`` security group on the port.
-
-5. Creates a router, whose node name is ``my_router``, and whose name on Openstack is ``my_router_openstack_name``. The router will automatically have an interface in the external network.
-
-6. Creates a server, whose node name is ``my_server``, and whose name on Openstack is **the node's ID** (since no ``name`` parameter was supplied under the ``server`` property). The server is set with an image and flavor IDs. It also overrides the ``cloudify_agent`` property of its parent type to set the username that will be used to connect to the server for installing the Cloudify agent on it. Finally, it is set with a relationship to the ``my_port`` node: This designated relationship type will take care of connecting the server to ``my_port_openstack_name``.
-
-
-Example III
------------
-
-This example will show how to use the ``volume`` type, as well as ``volume_attached_to_server`` relationship.
-
-The following is an excerpt from the blueprint's ``blueprint``.``node_templates`` section::
-
- my_server:
- type: cloudify.openstack.nodes.Server
- properties:
- cloudify_agent:
- user: ubuntu
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
-
- my_volume:
- type: cloudify.openstack.nodes.Volume
- properties:
- resource_id: my_openstack_volume_name
- device_name: /dev/vdb
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- size: 1
- relationships:
- - target: my_server
- type: cloudify.openstack.volume_attached_to_server
-
-
-1. Creates a server, with name ``my_server``, and with name on Openstack **the node's ID** (since no ``name`` parameter was supplied under the ``server`` property). The server is set with an image and flavor IDs.
-2. Creates a volume. It is set with a relationship to the ``my_server`` node: This designated relationship type will take care of attaching the volume to Openstack server node.
-
-
-
-Example IV
-----------
-
-This example will show how to use a Windows server with a Cloudify agent on it.
-
-
-The following is an excerpt from the blueprint's ``blueprint``.``node_templates`` section::
-
- my_keypair:
- type: cloudify.openstack.nodes.KeyPair
- properties:
- private_key_path: /tmp/windows-test.pem
-
- my_server:
- type: cloudify.openstack.nodes.WindowsServer
- relationships:
- - type: cloudify.openstack.server_connected_to_keypair
- target: keypair
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- server:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- name: my-server
- userdata: |
- #ps1_sysnative
- winrm quickconfig -q
- winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
- winrm set winrm/config '@{MaxTimeoutms="1800000"}'
- winrm set winrm/config/service '@{AllowUnencrypted="true"}'
- winrm set winrm/config/service/auth '@{Basic="true"}'
- &netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow
- &netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow
-
- msiexec /i https://www.python.org/ftp/python/2.7.6/python-2.7.6.msi TARGETDIR=C:\Python27 ALLUSERS=1 /qn
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- server:
- image: 8672f4c6-e33d-46f5-b6d8-ebbeba12fa02
- flavor: 101
- name: my-server
- userdata: |
- #ps1_sysnative
- winrm quickconfig -q
- winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
- winrm set winrm/config '@{MaxTimeoutms="1800000"}'
- winrm set winrm/config/service '@{AllowUnencrypted="true"}'
- winrm set winrm/config/service/auth '@{Basic="true"}'
- &netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow
- &netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow
-
- msiexec /i https://www.python.org/ftp/python/2.7.6/python-2.7.6.msi TARGETDIR=C:\Python27 ALLUSERS=1 /qn
- cloudify.interfaces.worker_installer:
- install:
- inputs:
- cloudify_agent:
- user: Admin
- password: { get_attribute: [SELF, password] }
-
-
-1. Creates a keypair. the private key will be saved under ``/tmp/windows-test.pem``.
-2. Creates a Windows server:
-
- * It is set with a relationship to the ``my_keypair`` node, which will make the server use the it as a public key for authentication, and also use this public key to encrypt its password before posting it to the Openstack metadata service.
- * The worker-installer interface operations are given values for the user and password for the ``cloudify_agent`` input - the password uses the [get_attribute]({{< relref "blueprints/spec-intrinsic-functions.md#get-attribute" >}}) feature to retrieve the decrypted password from the Server's runtime properties (Note that in this example, only the ``install`` operation was given with this input, but all of the worker installer operations as well as the plugin installer operations should be given with it).
- * We define custom userdata which configures WinRM and installs Python on the machine (Windows Server 2012 in this example) once it's up. This is required for the Cloudify agent to be installed on the machine.
-
-
+++ /dev/null
-.. cloudify-cli documentation master file, created by
- sphinx-quickstart on Thu Jun 12 15:30:03 2014.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Cloudify Openstack Plugin
-=========================
-
-The OpenStack plugin allows users to use an OpenStack based cloud infrastructure for deploying services and applications.
-For more information about OpenStack, please refer to: https://www.openstack.org/.
-
-
-Contents:
-
-.. toctree::
- :maxdepth: 2
-
- configuration
- types
- nova-net
- examples
- misc
- changelog
-
-
-Plugin Requirements
--------------------
-
-* Python versions:
-
- * 2.7.x
-* If the plugin is installed from source,
- then the following system dependencies are required:
-
- * ``gcc``
- * ``gcc-c++``
- * ``python-devel``
-
-
-Compatibility
--------------
-
-* *Mitaka* official support
-* *Liberty* official support
-* *Kilo* official support
-* *Juno*, *Icehouse* previously supported, not currently tested.
-
-.. attention:: New in 2.0
-
- The full Keystone URL in :ref:`config` is now required in the ``openstack_config`` ``auth_url`` property: eg ``http://192.0.2.200:5000/v2.0`` or ``http://192.0.2.200:5000/v3``.
-
-The Openstack plugin uses various Openstack clients packages. The versions used in Openstack Plugin are as follows:
-
-* `keystoneauth1 <https://github.com/openstack/keystoneauth>`_ - 2.12.1
-* `Keystone client <https://github.com/openstack/python-keystoneclient>`_ - 3.5.0
-* `Nova client <https://github.com/openstack/python-novaclient>`_ - 7.0.0
-* `Neutron client <https://github.com/openstack/python-neutronclient>`_ - 6.0.0
-* `Cinder client <https://github.com/openstack/python-cinderclient>`_ - 1.9.0
-* `Glance client <https://github.com/openstack/python-glanceclient>`_ - 2.5.0
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-
+++ /dev/null
-
-.. highlight:: yaml
-
-Tips
-====
-
-* It is highly recommended to **ensure that Openstack names are unique** (for a given type): While Openstack allows for same name objects, having identical names for objects of the same type might lead to ambiguities and errors.
-
-* To set up DNS servers for Openstack servers (whether it's the Cloudify Manager or application VMs), one may use the Openstack ``dns_nameservers`` parameter for the [Subnet type](#cloudifyopenstacknodessubnet) - that is, pass the parameter directly to Neutron by using the ``args`` input of the operations in Subnet node, e.g.::
-
- my_subnet_node:
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- dns_nameservers: [1.2.3.4]
- cloudify.interfaces.validation:
- creation:
- inputs:
- args:
- dns_nameservers: [1.2.3.4]
-
- This will set up ``1.2.3.4`` as the DNS server for all servers on this subnet.
-
-* Public keys, unlike the rest of the Openstack resources, are user-based rather than tenant-based. When errors indicate a missing keypair, make sure you're using the correct user rather than tenant.
-
-* ICMP rules show up on Horizon (Openstack GUI) as ones defined using ``type`` and ``code`` fields, rather than a port range. However, in the actual Neutron (and Nova, in case of Nova-net security groups) service, these fields are represented using the standard port range fields (i.e., ``type`` and ``code`` correspond to ``port_range_min`` and ``port_range_max`` (respectively) on Neutron security groups, and to ``from_port`` and ``to_port`` (respectively) on Nova-net security groups).
-
- ** For example, to set a security group rule which allows **ping** from anywhere, the following setting may be declared in the blueprint:
- * ``protocol``: ``icmp``
- * ``port_range_min``: ``0`` (type)
- * ``port_range_max``: ``0`` (code)
- * ``remote_ip_prefix``: ``0.0.0.0/0``
-
-* To use Openstack Neutron's ML2 extensions, use the ``args`` input for the Network's ``create`` operation. For example, the `provider network <http://developer.openstack.org/api-ref-networking-v2-ext.html#createProviderNetwork>`_ may be set in the following way::
-
- my_network:
- type: cloudify.openstack.nodes.Network
- ...
- interfaces:
- cloudify.interfaces.lifecycle:
- create:
- inputs:
- args:
- # Note that for this parameter to work, OpenStack must be configured to use Neutron's ML2 extensions
- provider:network_type: vxlan
-
-* Ordering NICs in the Openstack plugin can be done in the 1.4 version of the Openstack plugin by simply stating the relationships to the various networks (or ports) in the desired order, e.g.::
-
- node_templates:
- server:
- type: cloudify.openstack.nodes.Server
- relationships:
- - target: network1
- type: cloudify.relationships.connected_to
- - target: network2
- type: cloudify.relationships.connected_to
-
- network1:
- type: cloudify.openstack.nodes.Network
- properties:
- resource_id: network1
-
- network2:
- type: cloudify.openstack.nodes.Network
- properties:
- resource_id: network2
-
- In the example above, network1 will be connected to a NIC preceding the one network2 will - however these wont be eth0/eth1, but rather eth1/eth2 - because by default, the management network will be prepended to the networks list (i.e. it'll be assigned to eth0).
- To avoid this prepending, one should explicitly declare a relationship to the management network, where the network's represented in the blueprint by an existing resource (using the "use_external_resource" property).
- This will cause the management network adhere the NICs ordering as the rest of them.
- Example::
-
- node_templates:
- server:
- type: cloudify.openstack.nodes.Server
- properties:
- management_network_name: network2
- relationships:
- - target: network1
- type: cloudify.relationships.connected_to
- - target: network2
- type: cloudify.relationships.connected_to
- - target: network3
- type: cloudify.relationships.connected_to
-
- network1:
- type: cloudify.openstack.nodes.Network
- properties:
- resource_id: network1
-
- network2:
- type: cloudify.openstack.nodes.Network
- properties:
- use_external_resource: true
- resource_id: network2
-
- network3:
- type: cloudify.openstack.nodes.Network
- properties:
- use_external_resource: true
- resource_id: network3
-
- In this example, "network2" represents the management network, yet it'll be connected to eth1, while "network1" will take eth0, and "network3" (which also happened to already exist) will get connected to eth2.
-
- The server's property "management_network_name: network2" is not mandatory for this to work - this was just to make the example clear - yet the management network can also be inferred from the provider context (which is what happens when this property isn't explicitly set). Were the provider context to have "network2" set as the management network, this example would've worked just the same with this property omitted.
-
-Misc
-====
-
-* The plugin's operations are each **transactional**
- (and therefore also retryable on failures),
- yet not **idempotent**.
- Attempting to execute the same operation twice is likely to fail.
-
-* Over this documentation, it's been mentioned multiple times that some configuration-saving information may be available in the Provider Context.
- The Openstack manager blueprint and Openstack provider both create this relevant information,
- and therefore if either was used for bootstrapping, the Provider Context will be available for the Openstack plugin to use.
-
-The exact details of the structure of the Openstack Provider Context are not documented since this feature is going through deprecation and will be replaced with a more advanced one.
+++ /dev/null
-
-Nova-net Support
-================
-
-The Openstack plugin includes support for Nova-net mode -
-i.e. an Openstack installation which does not have the Networking API
-(Neutron service).
-
-In such an environment, there is but a single preconfigured private network,
-which all servers make use of automatically.
-There are no subnets, networks, routers or ports.
-Since these resource types don't exist,
-the plugin's equivalent types aren't valid to use in such an environment.
-
-There are, however, some resource types whose API is available via both the Nova and Neutron services - These had originally been on the Nova service,
-and later were moved and got extended implementation in the Neutron one,
-but were also kept in the Nova service for backward compatibility.
-
-For these resource types, the Openstack plugin defines two separate types - one in the plugin's standard types namespace (``cloudify.openstack.nodes.XXX``),
-which uses the newer and extended API via the Neutron service;
-and Another in a special namespace (``cloudify.openstack.nova_net.nodes.XXX``),
-which uses the older API via the Nova service.
-This is why you may notice two separate types defined for [Floating](#cloudifyopenstacknodesfloatingip) [IP](#cloudifyopenstacknovanetnodesfloatingip),
-as well as for [Security](#cloudifyopenstacknodessecuritygroup) [Group](#cloudifyopenstacknovanetnodessecuritygroup).
-
-
-To summarize, ensure that when working in a Nova-net Openstack environment,
-Neutron types aren't used - these include all types whose resources' APIs are natively available only via the Network API,
-as well as the types which are in the ``cloudify.openstack.nova_net.Nodes`` namespace.
-
-On the opposite side, when using an Openstack environment which supports Neutron,
-it's recommended to use the Neutron-versions of the relevant types
-(i.e. avoid any types defined under the
-``cloudify.openstack.nova_net.Nodes`` namespace),
-as they offer more advanced capabilities.
-However, it's important to mention that this is not required,
-and using the Nova-versions of some types in a Neutron-enabled environment is possible and will work as well.
-
-
-Nova-net Node Types
--------------------
-
-
-.. cfy:node:: cloudify.openstack.nova_net.nodes.FloatingIP
-
-
-.. cfy:node:: cloudify.openstack.nova_net.nodes.SecurityGroup
-
+++ /dev/null
-git+https://github.com/cloudify-cosmo/sphinxify.git
+++ /dev/null
-
-.. highlight:: yaml
-
-Types
-^^^^^
-
-Node Types
-==========
-
-.. cfy:node:: cloudify.openstack.nodes.Server
-
- An OpenStack server.
-
-
-.. cfy:node:: cloudify.openstack.nodes.WindowsServer
-
- This type has the same properties and operations-mapping as the type above (as it derives from it), yet it overrides some of the agent and plugin installations operations-mapping derived from the built-in cloudify.nodes.Compute type. Use this type when working with a Windows server.
-
- Additionally, the default value for the use_password property is overridden for this type, and is set to true. When using an image with a preset password, it should be modified to false.
-
-
-.. cfy:node:: cloudify.openstack.nodes.KeyPair
-
-
-.. cfy:node:: cloudify.openstack.nodes.Image
-
-
-.. cfy:node:: cloudify.openstack.nodes.SecurityGroup
-
-
-.. cfy:node:: cloudify.openstack.nodes.Router
-
-
-.. cfy:node:: cloudify.openstack.nodes.Port
-
-
-.. cfy:node:: cloudify.openstack.nodes.Network
-
-
-.. cfy:node:: cloudify.openstack.nodes.Subnet
-
-
-.. cfy:node:: cloudify.openstack.nodes.FloatingIP
-
-
-.. cfy:node:: cloudify.openstack.nodes.Volume
-
-
-.. cfy:node:: cloudify.openstack.nodes.Project
-
-
-Types' Common Behaviors
-=======================
-
-Validations
------------
-
-All types offer the same base functionality for the ``cloudify.interfaces.validation.creation`` interface operation:
-
- * If it's a new resource (``use_external_resource`` is set to ``false``), the basic validation is to verify there's enough quota to allocate a new resource of the given type.
-
- * When [using an existing resource](#using-existing-resources), the validation ensures the resource indeed exists.
-
-
-Runtime Properties
-------------------
-
-Node instances of any of the types defined in this plugin get set with the following runtime properties during the ``cloudify.interfaces.lifecycle.create`` operation:
-
- * ``external_id`` the Openstack ID of the resource
- * ``external_type`` the Openstack type of the resource
- * ``external_name`` the Openstack name of the resource
-
-The only exceptions are the two *floating-ip* types - Since floating-ip objects on Openstack don't have a name, the ``external_name`` runtime property is replaced with the ``floating_ip_address`` one, which holds the object's actual IP address.
-
-
-Default Resource Naming Convention
-----------------------------------
-
-When creating a new resource (i.e. ``use_external_resource`` is set to ``false``), its name on Openstack will be the value of its ``resource_id`` property. However, if this value is not provided, the name will default to the following schema:
-
-``<openstack-resource-type>_<deployment-id>_<node-instance-id>``
-
-For example, if a server node is defined as so::
-
- node_templates:
- myserver:
- type: cloudify.openstack.nodes.Server
- ...
-
-Yet without setting the ``resource_id`` property, then the server's name on Openstack will be ``server_my-deployment_myserver_XXXXX`` (where the XXXXX is the autogenerated part of the node instance's ID).
-
-
-
-Using Existing Resources
-------------------------
-
-It is possible to use existing resources on Openstack - whether these have been created by a different Cloudify deployment or not via Cloudify at all.
-
-All Cloudify Openstack types have a property named ``use_external_resource``, whose default value is ``false``. When set to ``true``, the plugin will apply different semantics for each of the operations executed on the relevant node's instances. Specifically, in the case of the ``cloudify.interfaces.lifecycle.create`` operation, rather than creating a new resource on Openstack of the given type, the plugin will behave as follows:
-
-1. Try to find an existing resource on Openstack whose name (or IP, in the case of one of the **floating-ip** types) is the value specified for the ``resource_id`` property. If more than one is found, an error is raised.
-
-2. If no resource was found, the plugin will use the value of the ``resource_id`` property to look for the resource by ID instead. If a resource still isn't found, an error is raised.
-
-3. If a single resource was found, the plugin will use that resource, and set the node instance with the appropriate runtime properties according to the resource's data.
-
-
-The semantics of other operations are affected as well:
-
-* The ``cloudify.interfaces.lifecycle.start`` operation, where applicable, will only validate that the resource is indeed started, raising an error if it isn't.
-
-* The ``cloudify.interfaces.lifecycle.stop`` operation, where applicable, won't have any effect.
-
-* The ``cloudify.interfaces.lifecycle.delete`` operation will not actually delete the resource from Openstack (but will clear the runtime properties from the node instance).
-
-* The ``cloudify.interfaces.validation.creation`` operation will verify that a resource with the given name or ID indeed exists, or otherwise print a list of all available resources of the given type.
-
-* The ``cloudify.interfaces.relationship_lifecycle.establish`` operation will behave as normal if the related node is not set with ``use_external_resource`` as ``true``; However if both nodes have this property set to ``true``, the operation will only attempt to verify that they're indeed "connected" on Openstack as well ("connected" in this case also refers to a security-group imposed on a server, floating-ip associated with a server, etc.).
-
-
-Notes
------
-
-* As mentioned in the [Relationships section](#relationships), some relationships take effect in non-relationship operations. When ``use_external_resource`` is set to ``true``, the existence of such connections is validated as well.
-
-* Using an existing resource only makes sense for single-instance nodes.
-
-
-
-
-Relationships
-=============
-
- Not all relationships have built-in types
- (i.e., some types may simply get connected using standard Cloudify relationships such as ``cloudify.relationships.connected_to``).
-
- Some relationships take effect in non-relationship operations,
- e.g. a subnet which is connected to a network actually gets connected on subnet's creation
- (in the ``cloudify.interfaces.lifecycle.create`` operation)
- and not in a ``cloudify.interfaces.relationship_lifecycle.establish`` operation - this occurs whenever the connection information is required on resource creation.
-
-
-.. cfy:rel:: cloudify.openstack.server_connected_to_port
-
- A relationship for connecting a server to a port. The server will use this relationship to automatically connect to the port upon server creation.
-
-
-.. cfy:rel:: cloudify.openstack.port_connected_to_security_group
-
- A relationship for a port to a security group.
-
-
-.. cfy:rel:: cloudify.openstack.server_connected_to_keypair
-
-
-.. cfy:rel:: cloudify.openstack.port_connected_to_subnet
-
- A relationship for connecting a port to a subnet. This is useful when a network has multiple subnets, and a port should belong to a specific subnet on that network. The port will then receive some IP from that given subnet.
-
- Note that when using this relationship in combination with the port type's property `fixed_ip`, the IP given should be on the CIDR of the subnet connected to the port.
-
- *Note*: This relationship has no operations associated with it; The port will use this relationship to automatically connect to the subnet upon port creation.
-
-
-.. cfy:rel:: cloudify.openstack.server_connected_to_security_group
-
- A relationship for setting a security group on a server.
-
-
-.. cfy:rel:: cloudify.openstack.subnet_connected_to_router
-
- A relationship for connecting a subnet to a router.
-
-
-.. cfy:rel:: cloudify.openstack.port_connected_to_floating_ip
-
- A relationship for associating a floating ip with a port. If that port is later connected to a server, the server will be accessible via the floating IP.
-
-
-.. cfy:rel:: cloudify.openstack.server_connected_to_floating_ip
-
- A relationship for associating a floating ip with a server.
-
-
-.. cfy:rel:: cloudify.openstack.volume_attached_to_server
-
- A relationship for attaching a volume to a server.
Code Review / so.git / commitdiff