Repository navigation
Adapting the Manager Blueprints for Your Setup
If you haven't already, first download and run your your Openstack RC file.
The Cloudify example blueprints can get you set up with your own Cloudify Manager in minutes.
However, you might have an existing cloud account with certain limits.
Here, we discuss minor adjustments that can get you up and running with Cloudify. Let's get started.
Download the cloudify-manager-blueprints repository to a folder on your computer:
git clone https://github.com/cloudify-cosmo/cloudify-manager-blueprints.git
cp -R cloudify-manager-blueprints my-openstack-manager
cd my-openstack-manager
You'll find example blueprints for Openstack, Cloudstack, and SoftLayer, as well as simple example.
In this example, I'll use Openstack.
cd openstack
Notice, there is an "inputs.json.template" and an "openstack.yaml".
Modifying these two files, you can bootstrap your own Cloudify Manager.
Inputs are static variables that you can specify when you upload the blueprint.
Copy "inputs.json.template" file and to a new "inputs.json" and fill it out with your own details.
{
"keystone_username": "USERNAME@CLOUD",
"keystone_password": "PASSWORD",
"keystone_tenant_name": "TENANT@YOURCOMPANY",
"keystone_url": "https://region-a.keystone.url.com:35357/v2.0/",
"region": "region-b",
"manager_public_key_name": "my-manager-kp",
...
"use_existing_manager_keypair": false,
...
"manager_private_key_path": "~/.ssh/cloudify-manager-kp.pem",
Notice the last three inputs. We'll return to this file in a moment.
Open the file "openstack.yaml" in a text editor. Notice the "inputs".
inputs:
use_existing_manager_keypair:
type: boolean
default: false
manager_public_key_name:
type: string
manager_private_key_path:
default: ~/.ssh/cloudify-manager-kp.pem
type: string
These inputs expose to the blueprint those inputs in the inputs.json file we just edited.
The blueprint accesses these by using a { get_input: input_name } tag:
node_templates:
management_keypair:
type: cloudify.openstack.nodes.KeyPair
properties:
use_external_resource: { get_input: use_existing_manager_keypair }
resource_id: { get_input: manager_public_key_name }
private_key_path: { get_input: manager_private_key_path }
openstack_config: { get_property: [openstack_configuration, openstack_config] }
notice the property "use_existing_resource". it points to "use_existing_manager_keypair". Whatever value that variable holds, will be passed to "use_existing_resource". obviously.
in this case, the value of that variable is a boolean: false. this means that during the execution a new keypair will be generated, however, if you set that variable to true, Cloudify will try to use an exiting keypair in Openstack:
node_templates:
management_keypair:
type: cloudify.openstack.nodes.KeyPair
properties:
use_external_resource: true
resource_id: { get_input: manager_public_key_name } # see what you have: $ nova keypair-list
The rest of the blueprint follows the same rules. I'm going to rewrite the blueprint to use existing everything, except for a VM and manager.
For each node template, I added "use_external_resource" and a variable assigned the value "true".
router:
type: cloudify.openstack.nodes.Router
properties:
use_external_resource: { get_input: use_existing_subnet }
Then I used a variable to assign a name.
resource_id: cloudify-router
router:
external_gateway_info:
network_name: { get_input: external_network_name }
openstack_config: { get_property: [openstack_configuration, openstack_config] }
Go to my git repository to see the complete blueprint file.
Now, validate the blueprint to make sure that there are no syntactical errors:
(cloudify)me@machine:~/cloudify-manager-blueprints$ cfy blueprints validate -p hphpc/openstack.yaml
Validating hphpc/openstack.yaml
Blueprint validated successfully
If you get an error, it will probably be a large blob. Look toward the end for the error message:
get_input function references an unknown input 'my_undeclared_input'