Avoid defining node templates of generic types (such as cloudify.nodes.Root, cloudify.nodes.SoftwareComponent etc). This is OK for short “dirty” demo’s — but when working with clients, usually node templates will belong to types that offer some functionality.
Strive to include as much functionality as possible, at the type level.
Use keywords such as SELF, SOURCE and TARGET when using intrinsic functions such as get_property and get_attribute.
Before beginning, make sure you master the topic of custom relationships. These can help solve many design problems, and are often overlooked because they seem to be complex at first glance.
Types which are meant to be reusable across multiple blueprints (such as VNF’s), should not bind operations to the script plugin, as the script plugin does not (currently) allow using scripting libraries — script files must be included with the blueprint. Use proper plugins instead.
Functionality that is meant to be reusable, should be encapsulated within a plugin.
Whenever possible, define a type (string, integer, boolean, custom data types) for the property/input/operation input.
Use custom data types when complex types are needed, and be as specific/restrictive as possible.
Never assign defaults (for inputs, properties or operation inputs) which are installation-specific and are likely to vary between installations (for example: OpenStack image ID’s or flavour ID’s).
If there is a theoretical possibility of an operation to raise a RecoverableError, then the operation MUST be idempotent.
To ensure proper functioning during scaling:
A lifecycle operation must never assume that it is called exactly once within the lifetime of the deployment.
Never use a node instance ID for application purposes (for example: never use a node instance ID of a Compute node, as the server’s host name). In particular: Node instance ID’s must never be used as keys to any data-store outside of Cloudify itself. The reason is that node instance ID’s are only unique:
Within a given deployment (which means: two different deployments may have node instances with the same ID’s)
Within a given point in time (which means: node instance ID’s may be assigned to different resources within a deployment, throughout the deployment’s lifetime. For example: running “install”, then running “uninstall” and then “install” again, will result in exactly the same node instance ID’s).