Support charm for OpenStack operations. It's main purpose is to package common tasks into easy-to-use actions.
Typically it will be deployed into a container on an infrastructure node.
The charm requires OpenStack credentials to operate, and some actions require administrative access to cloud computes via ssh.
Spawn test instances on the given compute node(s). This requires a pre-existing test image (by default: cloudsupport-image) to be present in the cloud.
Example:
juju run-action --wait cloudsupport/0 create-test-instances nodes=compute1.maas,compute2.maas vcpus=2 vnfspecs=true physnet=physnet1Run a connectivity test against instances. The connectivity test does not require a floating ip address -- it will be run from an appropriate net namespace. The test will be run against the first port bound to the test instance. The test will ping the port and attempt a connection to tcp:22 and tcp:80 (note the cloudsupport-image should launch services listening on those).
This action supports both OVS and OVN deployments.
Example:
juju run-action --wait cloudsupport/0 test-connectivity Will delete instances on nodes. Instance names will be matched against the given pattern (by default: ^cloudsupport-test-.*). DANGER! This will wipe your instances without asking for confirmation!
Example - delete instances named 'cloudsupport-test-.*' on compute1 and compute2:
juju run-action --wait cloudsupport/0 delete-test-instances nodes=compute1.maas,compute2.maas
Get ssh cmd to connect to test instances.
If you have specified a key-name when creating the instances, you should have passwordless ssh using the printed cmds.
juju run-action --wait cloudsupport/0 get-ssh-cmd --waitOptionally you can pass an instance UUID in this case the action will get the ssh cmd only for the given instance:
juju run-action --wait cloudsupport/0 get-ssh-cmd instance="3be0c29e-0299-44bb-9b0f-f9f35cab39ee" --waitDeploy this charm with:
juju deploy cloudsupportSet up OpenStack connection params by providing yaml-formatted string with one cloud named cloud1. For safety it is strongly advised to utilize an administrative project, separate from production workload projects.
cat clouds.yaml
clouds:
cloud1:
region_name: {region_name}
auth:
auth_url: {auth_url}
username: {username}
password: {password}
user_domain_name: {user_domain_name}
project_name: {project_name}
domain_name: {domain_name}
juju config cloudsupport clouds-yaml=@clouds.yamlAlso ensure that the config param cloud-name match the name of the cloud in the clouds-yaml
i.e. (in this case you won't need this as clouds-yaml is using the default cloud name "cloud1")
juju config cloudsupport cloud-name="cloud1"The test-connectivity action needs credentials to connect to compute nodes. Those can be configured by passing in a ssh key:
juju config cloudsupport ssh-key=@~/.local/share/juju/ssh/juju_id_rsa'If a CA certificate is required to connect to the OpenStack API it can be provided thusly:
juju config cloudsupport ssl-ca='
-----BEGIN CERTIFICATE-----
<certificate body>
-----END CERTIFICATE-----
'This charm provides an nrpe check to ensure that the VMs deployed with it are not left running on the cloud for more than
stale-warn-days (this generates a warning) or more than stale-crit-days (this generates a critical alert).
To configure it, relate the charm with nrpe
juju add-relation cloudsupport nrpeand enable the check that is disabled by default
juju config cloudsupport stale-server-check=trueUse juju config to tune the stale-warn-days (default 7) and the stale-crit-days (default 14)
Specific VMs can be ignored when checking for stale servers, adding their uuid to the config param stale-ignored-uuids