.. 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: ``__`` 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.