Last updated on: 2023-08-29 10:06:08.

Orchestrator CLI

AGENTS

The vnfm agents command is used to manage VNFM agents on existing deployments.

Consult agents for more information.

Commands

Common agents arguments:

• -d, --deployment-id TEXT - The unique identifier for the deployment
• --node-id TEXT - The node id to filter to be used for filtering
• --node-instance-id TEXT - The node instance id to be used for filtering
• --install-method TEXT - Only show agents installed with this install_method
• -a, --all-tenants - Include resources from all tenants associated with the user. This option cannot be used simultaneously with the tenant-name argument.

The filtering flags can be passed multiple times or take comma separated values.

list

List agents configured with the Manager. When preparing to upgrade agents, if using the filtering options with vnfm agents install, use vnfm agents list first with the same filtering options to verify which agents are going to be installed.

Usage

vnfm agents list [OPTIONS]

This command supports the common agent flags and the common CLI flags.

install

After restoring a manager on a new host using a snapshot, this command installs new agents on the hosts for the new manager while also leaving the previous agents installed and running.

Caution

This should only be used in specific circumstances and should not be used to install agents for deployments using an existing manager. Instead, vnfm agents install is to be used for upgrading the agents after the corresponding Manager upgrade.

Usage

vnfm agents install [OPTIONS] [DEPLOYMENT_ID]

Install agents on the hosts of existing deployments.

DEPLOYMENT_ID - The ID of the deployment you want to install agents for.

Optional Flags

This command supports the common agent flags and the and the common CLI flags.

• --include-logs / --no-logs - Include logs in returned events [default: true]
• --stop-old-agent - If set, after installing the new agent the old agent will be stopped
• -s, --install-script TEXT - Alternative location of the install_agents.py script
• -t, --tenant-name TEXT - The name of the tenant of the relevant deployment(s). If not specified, the current tenant is used.
• --manager-ip TEXT - The private IP of the current leader (primary) Manager. This IP is used to connect to the Manager’s RabbitMQ.
• --manager_certificate TEXT - A path to a file containing the SSL certificate of the current leader Manager. The certificate is available on the Manager: /etc/cloudify/ssl/vnfm_internal_ca_cert.pem
• --wait / --no-wait - Wait for agents operations to end, and show execution logs
• --install-agent-timeout INTEGER - Agent installation timeout

validate

Validates the connection between the VNF Manager and the live VNFM Agents (installed on remote hosts).

Usage

vnfm agents validate [OPTIONS] [DEPLOYMENT_ID]

DEPLOYMENT_ID - The ID of the deployment you want to validate agents for.

Optional Flags

This command supports the common agent flags and the and the common CLI flags.

• --include-logs / --no-logs - Include logs in returned events [default: true]
• -s, --install-script TEXT - Alternative location of the install_agents.py script
• -t, --tenant-name TEXT - The name of the tenant of the relevant deployment(s). If not specified, the current tenant is used.

APPLY

Use the vnf apply command to install/update a deployment using VNF manager without having to manually go through the process of uploading a blueprint, creating a deployment, and executing a workflow. The vnfm apply command uses vnfm install or vnfm deployments update logic depending on the existence of the deployment referenced by DEPLOYMENT_ID.

It is recommended to read about vnfm install and vnfm deployments update in order to understand the vnfm apply command.

The vnfm apply designed to improve blueprints development lifecycle. For example, during blueprint development and testing, you can quickly deploy and install the updated blueprint, overriding the existing deployment with the new changes.

The vnfm apply logic:

1. Check for BLUPRINT_PATH and DEPLOYMENT_ID.
2. If BLUPRINT_PATH is missing, use the default value and infer DEPLOYMENT_ID (explained in the following Usage section).
3. Check if deployment DEPLOYMENT_ID exists.
4. Upload blueprint BLUPRINT_PATH to the manager.
5. If deployment DEPLOYMENT_ID exists, perform a deployment update with the uploaded blueprint. Else, create a new deployment with the name DEPLOYMENT_ID, and execute the install workflow.

Usage

vnfm apply [OPTIONS] include:

The vnfm apply command uses the vnfm install or vnfm deployments update depending on the existence of the deployment specified by DEPLOYMENT_ID.

If the deployment exists, the deployment will be updated with the given blueprint. Otherwise, the blueprint will be installed, and the deployment name will be DEPLOYMENT_ID. In both cases, the blueprint is uploaded to the manager.

BLUEPRINT_PATH format options include:

• blueprint yaml file.
• blueprint archive.
• URL to a blueprint archive.
• GitHub repo (organization/blueprint_repo[:tag/branch]).
• Supported archive types are zip, tar, tar.gz, and tar.bz2

DEPLOYMENT_ID is the deployment’s ID to install/update.

Default values

If BLUEPRINT_PATH is not provided, the default blueprint path is blueprint.yaml in the current working directory. If DEPLOYMENT_ID is not provided, it is inferred from the BLUEPRINT_PATH in one of the following ways:

• If BLUEPRINT_PATH is a local file path, then DEPLOYMENT_ID will be the name of the blueprint directory.
• If BLUEPRINT_PATH is an archive and –blueprint-filename/-n option is not provided, then DEPLOYMENT_ID will be the name of the blueprint directory.
• If BLUEPRINT_PATH is an archive and –blueprint-filename/-n option is provided, then DEPLOYMENT_ID will be <blueprint directory name>.<blueprint_filename>.

Optional flags

This command supports the common CLI flags.

• -p, --blueprint-path PATH - The path to the application’s blueprint file and format options include:
  • local blueprint yaml file
  • blueprint archive
  • url to a blueprint archive
  • github repo (organization/blueprint_repo[:tag/branch])
• -d, --deployment-id TEXT - The unique identifier for the deployment.
• -n, --blueprint-filename TEXT - The name of the archive’s main blueprint file. This is only relevant if uploading an archive.
• -b, --blueprint-id TEXT - The unique identifier for the blueprint.
• -i, --inputs TEXT - Inputs for the deployment (can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). You can use this argument repeatedly.
• -r, --reinstall-list TEXT - Node instances ids to be reinstalled as part of deployment update. They will be reinstalled even if the flag –skip-reinstall has been supplied.
• -w, --workflow-id TEXT - The workflow to execute [default: None]
• --skip-install - Skip install lifecycle operations.
• --skip-uninstall - Skip uninstall lifecycle operations.
• --dont-skip-reinstall - Reinstall node-instances that their properties has been modified, as part of a deployment update. Node instances that were explicitly given to the reinstall list will be reinstalled too.
• --ignore-failure - Supply the parameter ignore_failure with the value true to the uninstall workflow.
• --install-first - In deployment update, perform install workflow and then uninstall workflow. default: uninstall and then install.
• --preview - Preview the deployment update, stating what changes will be made without applying any changes.
• --dont-update-plugins - Don’t update the plugins.
• -f, --force - Force running update in case a previous update on this deployment has failed to finish successfully [This option is deprecated].
• -l, --visibility TEXT - Defines who can see the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].
• --validate - Validate the blueprint first.
• --include-logs / --no-logs - Include logs in returned events [default:True].
• --json-output - Output events in a consumable JSON format.
• --manager TEXT- Connect to a specific manager by IP or host.
• --runtime-only-evaluation - If set, all intrinsic functions will only be evaluated at runtime, and no intrinsic functions will be evaluated at parse time(such as get_input, get_property).
• --auto-correct-types - If set, before creating plan for a new deployment, an attempt will be made to cast old inputs’ values to the valid types declared in blueprint.
• --reevaluate-active-statuses - If set, before attempting to update, the statuses of previous active update operations will be reevaluated based on relevant executions’ statuses. terminated executions will be mapped to successful updates, while failed and any cancel statuses will be mapped to failed.
• --skip-plugins-validation - Determines whether to validate if the required deployment plugins exist on the manager. If validation is skipped, plugins containing source URL will be installed from source.
• -p, --parameters TEXT - Parameters for the workflow (can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times.
• --allow-custom-parameters - Allow passing custom parameters (which were not defined in the workflow’s schema in the blueprint) to the execution.
• --blueprint-labels TEXT - labels list of the form :,:.
• --deployment-labels TEXT - labels list of the form :,:.

Example using default values

In a folder called, resources with blueprint.yaml file inside:

$ vnfm apply
No blueprint path provided, using default: /home/..../resources/blueprint.yaml
Trying to find deployment resources
Uploading blueprint /home/..../resources/blueprint.yaml...
blueprint.yaml |######################################################| 100.0%
Blueprint `resources` upload started.
2021-03-31 14:07:32.306  VNFM <None> Starting 'upload_blueprint' workflow execution
2021-03-31 14:07:32.335  LOG <None> INFO: Blueprint archive uploaded. Extracting...
2021-03-31 14:07:32.368  LOG <None> INFO: Blueprint archive extracted. Parsing...
2021-03-31 14:07:33.290  LOG <None> INFO: Blueprint parsed. Updating DB with blueprint plan.
2021-03-31 14:07:33.375  VNFM <None> 'upload_blueprint' workflow execution succeeded
Blueprint uploaded. The blueprint's id is resources
Creating new deployment from blueprint resources...
Deployment created. The deployment's id is resources
Executing workflow `install` on deployment `resources` [timeout=900 seconds]
2021-03-31 14:07:36.565  VNFM <resources> Starting 'install' workflow execution
2021-03-31 14:07:36.768  VNFM <resources> [node_b_cfrr7p] Validating node instance before creation: nothing to do
2021-03-31 14:07:36.769  VNFM <resources> [node_b_cfrr7p] Precreating node instance: nothing to do
2021-03-31 14:07:36.771  VNFM <resources> [node_b_cfrr7p] Creating node instance: nothing to do
2021-03-31 14:07:36.773  VNFM <resources> [node_b_cfrr7p] Configuring node instance: nothing to do
2021-03-31 14:07:36.774  VNFM <resources> [node_b_cfrr7p] Starting node instance
2021-03-31 14:07:37.057  VNFM <resources> [node_b_cfrr7p.start] Sending task 'script_runner.tasks.run'
2021-03-31 14:07:37.638  LOG <resources> [node_b_cfrr7p.start] INFO: Downloaded install.py to /tmp/C9QFC/install.py
2021-03-31 14:07:37.638  LOG <resources> [node_b_cfrr7p.start] INFO: hi!!
2021-03-31 14:07:37.908  VNFM <resources> [node_b_cfrr7p.start] Task succeeded 'script_runner.tasks.run'
2021-03-31 14:07:37.909  VNFM <resources> [node_b_cfrr7p] Poststarting node instance: nothing to do
2021-03-31 14:07:37.911  VNFM <resources> [node_b_cfrr7p] Node instance started
2021-03-31 14:07:38.120  VNFM <resources> [node_a_vfhhzn] Validating node instance before creation: nothing to do
2021-03-31 14:07:38.123  VNFM <resources> [node_a_vfhhzn] Precreating node instance: nothing to do
2021-03-31 14:07:38.124  VNFM <resources> [node_a_vfhhzn] Creating node instance: nothing to do
2021-03-31 14:07:38.125  VNFM <resources> [node_a_vfhhzn] Configuring node instance: nothing to do
2021-03-31 14:07:38.126  VNFM <resources> [node_a_vfhhzn] Starting node instance
2021-03-31 14:07:38.432  VNFM <resources> [node_a_vfhhzn.start] Sending task 'script_runner.tasks.run'
2021-03-31 14:07:39.101  LOG <resources> [node_a_vfhhzn.start] INFO: Downloaded install.py to /tmp/E6KY5/install.py
2021-03-31 14:07:39.102  LOG <resources> [node_a_vfhhzn.start] INFO: hi!!
2021-03-31 14:07:39.480  VNFM <resources> [node_a_vfhhzn.start] Task succeeded 'script_runner.tasks.run'
2021-03-31 14:07:39.481  VNFM <resources> [node_a_vfhhzn] Poststarting node instance: nothing to do
2021-03-31 14:07:39.484  VNFM <resources> [node_a_vfhhzn] Node instance started
2021-03-31 14:07:39.661  VNFM <resources> 'install' workflow execution succeeded
Finished executing workflow install on deployment resources
* Run 'vnfm events list 57ad1536-8904-48cf-8521-70abeefa0c60' to retrieve the execution's events/logs

In the first invocation, the blueprint is uploaded and resources deployment is created and installed. Before the second invocation, node_c was added to the blueprint.

$ vnfm apply
No blueprint path provided, using default: /home/..../resources/blueprint.yaml
Trying to find deployment resources
Deployment resources found, updating deployment.
Uploading blueprint /home/..../resources/blueprint.yaml...
 blueprint.yaml |######################################################| 100.0%
Blueprint `resources-31-03-2021-17-14-09` upload started.
2021-03-31 14:14:10.328  VNFM <None> Starting 'upload_blueprint' workflow execution
2021-03-31 14:14:10.357  LOG <None> INFO: Blueprint archive uploaded. Extracting...
2021-03-31 14:14:10.387  LOG <None> INFO: Blueprint archive extracted. Parsing...
2021-03-31 14:14:11.292  LOG <None> INFO: Blueprint parsed. Updating DB with blueprint plan.
2021-03-31 14:14:11.378  VNFM <None> 'upload_blueprint' workflow execution succeeded
Blueprint uploaded. The blueprint's id is resources-31-03-2021-17-14-09
Updating deployment resources, using blueprint resources-31-03-2021-17-14-09
2021-03-31 14:14:14.223  VNFM <resources> Starting 'update' workflow execution
2021-03-31 14:14:14.542  VNFM <resources> [node_c_oh15uc] Validating node instance before creation: nothing to do
2021-03-31 14:14:14.544  VNFM <resources> [node_c_oh15uc] Precreating node instance: nothing to do
2021-03-31 14:14:14.545  VNFM <resources> [node_c_oh15uc] Creating node instance: nothing to do
2021-03-31 14:14:14.546  VNFM <resources> [node_c_oh15uc] Configuring node instance: nothing to do
2021-03-31 14:14:14.549  VNFM <resources> [node_c_oh15uc] Starting node instance
2021-03-31 14:14:14.830  VNFM <resources> [node_c_oh15uc.start] Sending task 'script_runner.tasks.run'
2021-03-31 14:14:15.371  LOG <resources> [node_c_oh15uc.start] INFO: Downloaded install.py to /tmp/5049J/install.py
2021-03-31 14:14:15.372  LOG <resources> [node_c_oh15uc.start] INFO: hi!!
2021-03-31 14:14:15.729  VNFM <resources> [node_c_oh15uc.start] Task succeeded 'script_runner.tasks.run'
2021-03-31 14:14:15.730  VNFM <resources> [node_c_oh15uc] Poststarting node instance: nothing to do
2021-03-31 14:14:15.732  VNFM <resources> [node_c_oh15uc] Node instance started
2021-03-31 14:14:16.548  VNFM <resources> 'update' workflow execution succeeded
Finished executing workflow 'update' on deployment 'resources'
Successfully updated deployment resources. Deployment update id: resources-90a04562-c24e-4088-868d-72c9d46979fc. Execution id: ef0e35e5-4b22-4cae-9608-829377312510

In the second invocation, the updated blueprint is uploaded and deployment-update is executed.

BLUEPRINTS

The vnfm blueprints command is used to manage blueprints on a VNF Manager instance.

You can use the command to upload, delete, download, validate and list blueprints and to retrieve information for a specific blueprint.

Use of spaces is not supported in file names.

Optional Flags

These commands support the common CLI flags.

Commands

upload

Usage

vnfm blueprints upload [options] BLUEPRINT_PATH

Upload a blueprint to a VNF Manager.

BLUEPRINT_PATH can be either a blueprint yaml file or blueprint archive; a url to a blueprint archive or an organization/blueprint_repo[:tag/branch] (to be retrieved from GitHub) Supported archive types are: zip, tar, tar.gz and tar.bz2

Optional Flags

• -b, --blueprint-id=BLUEPRINT_ID - The unique identifier for the blueprint
• -i, --icon-path TEXT - The path to the blueprint’s icon file (must be a valid image in PNG format); the file will be saved as icon.png in the blueprint’s resources and will overwrite any existing file with that name.
• -n, --blueprint-filename TEXT - The name of the archive’s main blueprint file. Only relevant if uploading an archive.
• -a, --async-upload - Don’t wait for the upload workflow to finish. Upload state can be checked at any time using the vnfm blueprints get or vnfm blueprints list commands.
• --labels - A labels list of the form <key>:<value>,<key>:<value>. Any comma and colon in <value> must be escaped with . The labels’ keys are saved in lowercase.
• --validate - Validate the blueprint before uploading it to the manager
• -t --tenant-name TEXT - The name of the tenant of the blueprint. If not specified, the current tenant is used.
• -l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].

When you upload a blueprint yaml, the CLI compresses the directory that contains the blueprint file and uploads the entire directory to the VNF Manager.

Make sure that:

• Blueprint directory contains all resources required by the blueprint, such as scripts
• Blueprint directory does NOT contain unnecessary files
• All files in the directory are readable by others (at least permission level 404)

Example

$ vnfm blueprint upload simple-blueprint.yaml

...

Uploading blueprint simple-blueprint.yaml...
 simple-blueprint.... |################################################| 100.0%
Blueprint uploaded. The blueprint's id is vnfm-nodecellar-example

...

$ vnfm blueprints upload simple-python-webserver-blueprint/blueprint.yaml --validate

...

Validating blueprint: simple-python-webserver-blueprint/blueprint.yaml
Blueprint validated successfully

...

delete

Usage

vnfm blueprints delete [OPTIONS] BLUEPRINT_ID

Delete a blueprint. It’s important to realize deleting a blueprint does not delete the deployments created from that blueprint and resources of those deployments.

Optional Flags

• --tenant-name TEXT - The name of the tenant of the relevant deployment(s). If not specified, the current tenant is used
• -f, --force - Delete the blueprint, even if there are blueprints that are currently using it. [default: True]

Example

$ vnfm blueprints delete simple-python-webserver-blueprint

...

Deleting blueprint simple-python-webserver-blueprint...
Blueprint deleted

...

package

Usage

vnfm blueprints package [OPTIONS] BLUEPRINT_PATH

Create a blueprint archive.

BLUEPRINT_PATH - The path to the blueprint yaml or to the directory in which the blueprint yaml files resides.

Optional Flags

• -o, --output-path TEXT - The local path to download to
• --validate - Validate the blueprint first

Example

$ vnfm blueprints package simple-python-webserver-blueprint/blueprint.yaml

...

Creating blueprint archive simple-python-webserver-blueprint...
Packaging complete!

...

download

Usage

vnfm blueprints download [OPTIONS] BLUEPRINT_ID

Download a blueprint from VNF Manager.

BLUEPRINT_ID - The ID of the blueprint to download.

Optional Flags

• -o, --output-path TEXT - The local path to download to
• -t --tenant-name TEXT - The name of the tenant of the blueprint. If not specified, the current tenant is used.

Example

$ vnfm blueprints download simple-python-webserver-blueprint

...

Downloading blueprint simple-python-webserver-blueprint...
 simple-python-web... |################################################| 100.0%
Blueprint downloaded as simple-python-webserver-blueprint.tar.gz

...

validate

Usage

vnfm blueprints validate [OPTIONS] BLUEPRINT_PATH

Validate a blueprint. Checks that the blueprint’s syntax is valid and that all imports are accessible.

Import validation is done only on the client side. That means that if, for some reason, the imports are accessible by the client but not on the manager, this validation will still pass.

BLUEPRINT_PATH - The path of the blueprint to validate.

Example

$ vnfm blueprints validate simple-python-webserver-blueprint/blueprint.yaml

...

Validating blueprint: simple-python-webserver-blueprint/blueprint.yaml
Blueprint validated successfully

...

create-requirements

Usage

vnfm blueprints create-requirements [OPTIONS] BLUEPRINT_PATH

Generate a pip-compliant requirements file for a specific blueprint.

BLUEPRINT_PATH - The path to the blueprint for which the file will be generated.

Optional Flags

• -o, --output-path TEXT - The local path to download to

Example

$ vnfm blueprints create-requirements nodecellar-blueprint/aws-ec2-blueprint.yaml

...

-https://github.com/F5Networks/f5-nfv-solutions/blob/master/supported/blueprints/gilan/v1.4.0/F5-VNF-Service-Layer-GiLAN.yaml.zip
-https://github.com/F5Networks/f5-nfv-solutions/blob/master/supported/plugins/f5-gilan-plugin/v02.53/f5-gilan-plugin_0.2.53.zip

...

install-plugins

Usage

vnfm blueprints install-plugins [OPTIONS] BLUEPRINT_PATH

Install the necessary plugins for a specific blueprint in the local environment.

Only supports passing the YAML of the blueprint directly.

BLUEPRINT_PATH - The path to the blueprint to install plugins for.

Example

$ vnfm blueprints install-plugins nodecellar-blueprint/aws-ec2-blueprint.yaml

...

Installing plugins...
Collecting _https://github...
.
.
.
Installing collected packages: boto, vnfm-aws-plugin
  Running setup.py install for vnfm-aws-plugin ... done
Successfully installed boto-2.38.0 vnfm-aws-plugin-1.4.3

...

list

Usage

vnfm blueprints list [OPTIONS]

List all existing blueprints.

Optional Flags

• --filter-id TEXT - Filter results according to the specified filter (based on the filter ID)
• -lr, --labels-rule TEXT - A blueprint labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Any comma and colon in <value> must be escaped with . The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, --attrs-rule TEXT - A blueprint attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [created_by]. This argument can be used multiple times
• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t --tenant-name TEXT - The name of the tenant for which to list the blueprints. If not specified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a --all-tenants - Include resources from all tenants associated with the user. This option cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search blueprints by id. The returned list will include only blueprints that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm blueprints list

...

Listing all blueprints...

Blueprints:
+------------------------------+----------------------+---------------------------+--------------------------+--------------------------+------------+----------------+------------+
|              id              |     description      |       main_file_name      |        created_at        |        updated_at        | visibility |  tenant_name   | created_by |
+------------------------------+----------------------+---------------------------+--------------------------+--------------------------+------------+----------------+------------+
| vnfm-nodecellar-example      | This Blueprint ins.. |   simple-blueprint.yaml   | 2017-04-04 05:52:32.634  | 2017-04-04 05:52:32.634  |   private  | default_tenant |   admin    |
| vnfm-hello-world-example     | This blueprint ins.. | singlehost-blueprint.yaml | 2017-04-04 06:48:53.255  | 2017-04-04 06:48:53.255  |   tenant   | default_tenant |   admin    |
+------------------------------+----------------------+---------------------------+--------------------------+--------------------------+------------+----------------+------------+

...

summary

Usage

vnfm blueprints summary <field> [optional sub-field] [OPTIONS]

Summarizes blueprints, giving a count of elements with each distinct value for the selected field. If a sub-field is selected then a count will be given for each distinct field and sub-field combination, as well as totals for each field.

For valid field/sub-field names, invoke vnfm blueprints summary

Example

$ vnfm blueprints summary --all-tenants tenant_name
Retrieving summary of blueprints on field tenant_name

Blueprint summary by tenant_name

+----------------+------------+------------+
|  tenant_name   | visibility | blueprints |
+----------------+------------+------------+
|     test1      |   tenant   |     3      |
|     test1      |   TOTAL    |     3      |
|     test2      |   tenant   |     3      |
|     test2      |   TOTAL    |     3      |
| default_tenant |   tenant   |     3      |
| default_tenant |   TOTAL    |     3      |
+----------------+------------+------------+

...

$ vnfm blueprints summary --all-tenants tenant_name visibility
Retrieving summary of blueprints on field tenant_name

Blueprint summary by tenant_name
+----------------+------------+------------+
|  tenant_name   | visibility | blueprints |
+----------------+------------+------------+
|     test1      |   tenant   |     3      |
|     test1      |   TOTAL    |     3      |
|     test2      |   tenant   |     3      |
|     test2      |   TOTAL    |     3      |
| default_tenant |   tenant   |     3      |
| default_tenant |   TOTAL    |     3      |
+----------------+------------+------------+

...

get

Usage

vnfm blueprints get [OPTIONS] BLUEPRINT_ID

Retrieve information for a specific blueprint.

BLUEPRINT_ID - The ID of the blueprint for which to retrieve information.

Optional Flags

-t --tenant-name TEXT - The name of the tenant for which to retrieve the blueprint information. If not specified, the current tenant is used.

Example

$ vnfm blueprints get vnfm-nodecellar-example

 ...

 Blueprint:
 +-----------------------------+----------------------------------------------------+-----------------------+--------------------------+--------------------------+------------+----------------+------------+--------------+
 |              id             |                    description                     |     main_file_name    |        created_at        |        updated_at        | visibility |  tenant_name   | created_by | #deployments |
 +-----------------------------+----------------------------------------------------+-----------------------+--------------------------+--------------------------+------------+----------------+------------+--------------+
 | vnfm-nodecellar-example     | This Blueprint installs the nodecellar application | simple-blueprint.yaml | 2017-04-04 05:52:32.634  | 2017-04-04 05:52:32.634  |   tenant   | default_tenant |   admin    |      1       |
 |                             |                on an existing host.                |                       |                          |                          |            |                |            |              |
 |                             |                                                    |                       |                          |                          |            |                |            |              |
 +-----------------------------+----------------------------------------------------+-----------------------+--------------------------+--------------------------+------------+----------------+------------+--------------+

 Description:
 This Blueprint installs the nodecellar application on an existing host.


 Existing deployments:

 ["vnfm-nodecellar-example"]
 ...

inputs

Usage

vnfm blueprints inputs [OPTIONS] BLUEPRINT_ID

Retrieve inputs for a specific blueprint

BLUEPRINT_ID - The path of the blueprint for which to retrieve inputs.

Optional Flags

-t --tenant-name TEXT - The name of the tenant from which to retrieve the blueprints. If not specified, the current tenant is used.

Example

$ vnfm blueprints inputs vnfm-hello-world-example

...

Retrieving inputs for blueprint vnfm-hello-world-example...

Inputs:
+------------------------+------+-------------+-------------+
|          name          | type |   default   | description |
+------------------------+------+-------------+-------------+
|     webserver_port     |  -   |     8080    |      -      |
|       agent_user       |  -   |    centos   |      -      |
|       server_ip        |  -   | 172.16.0.49 |      -      |
| agent_private_key_path |  -   |   /key.pem  |      -      |
+------------------------+------+-------------+-------------+

...

set-visibility

Usage

vnfm blueprints set-visibility [OPTIONS] BLUEPRINT_ID

Set the blueprint’s visibility.

BLUEPRINT_ID - The ID of the blueprint to update.

Mandatory flags

-l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘tenant’, ‘global’] [required].

Example

$ vnfm blueprints set-visibility vnfm-nodecellar-example -l global

...

Blueprint `vnfm-nodecellar-example` was set to global

...

set-icon

Usage

vnfm blueprints set-icon [OPTIONS] BLUEPRINT_ID

Set an icon used to describe/identify the blueprint. In case -i [ICON_PATH] is provided, point the [ICON_PATH] to a valid PNG image. If you omit this parameter, then the icon is removed from the blueprint’s resources.

BLUEPRINT_ID - The id of the blueprint to update.

Optional flags

• -i, --icon-path TEXT - The path to the blueprint’s icon file (must be a valid image in PNG format); the file will be saved as icon.png in the blueprint’s resources and will overwrite any existing file with that name.

Example

$ vnfm blueprints set-icon cloudify-nodecellar-example -i ./nodecellar.png
...

Blueprint vnfm-nodecellar-example has a new icon set.

...
$ vnfm blueprints set-icon cloudify-nodecellar-example
...

Blueprint ``cloudify-nodecellar-example`` has its icon removed.

...

set-owner

Usage

vnfm blueprints set-owner [OPTIONS] BLUEPRINT_ID

Change ownership of a blueprint.

• BLUEPRINT_ID - The id of the blueprint to update.

Optional flags

• -s, --username USERNAME - The name of the user who will be the new owner of the resource. [required]
• -t, --tenant-name TEXT - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm blueprints set-owner cloudify-nodecellar-example -s admin
...

Blueprint `vnfm-nodecellar-example` is now owned by user `admin`.

...

labels

A blueprint label is a key-value pair that can be assigned with a blueprint. There can be multiple labels assigned with each blueprint, and one can assign more than one label with the same key (yet different value) to the same blueprint.

labels list

Usage

vnf blueprints labels list [OPTIONS] BLUEPRINT_ID

List the blueprint’s labels.

BLUEPRINT_ID is the ID of the blueprint for which to list the labels.

labels add

Usage

vnf blueprints labels add [OPTIONS] LABELS_LIST BLUEPRINT_ID

Add labels to a specific blueprint.

BLUEPRINT_ID is the id of the blueprint to update LABELS_LIST: <key>:<value>,<key>:<value>. Escape any comma and colon in <value> with a (backslash).

labels delete

Usage

vnf blueprints labels delete [OPTIONS] LABEL BLUEPRINT_ID

Delete labels from a specific blueprint.

BLUEPRINT_ID is the id of the blueprint to update LABEL: A mixed list of labels and keys; for example, <key>:<value>,<key>,<key>:<value>. If <key> is provided, all labels associated with this key will be deleted from the deployment. Escape any comma and colon in <value> with a (backslash).

Blueprint filters

A filter is defined as a set of filter-rules that can be used to filter a list of blueprints, based on their labels and certain attributes. At the moment, the supported blueprint attributes to filter by include only created_by. For complete details about each filter rule, refer to filter-rules.

Blueprint filters create

Usage

vnf blueprints filters create [OPTIONS] FILTER_ID

Create a new blueprints’ filter.

FILTER-ID is the new filter’s ID.

Optional flags:

• -lr, –labels-rule TEXT A blueprint labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string or a list of strings of the form [<value1>,<value2>,…]. Any comma and colon in <value> must be escaped with . The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, –attrs-rule TEXT A blueprint attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [created_by]. This argument can be used multiple times
• -l, –visibility TEXT Defines who can see the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant]
• -t, –tenant-name TEXT The name of the tenant of the filter. If not specified, the current tenant will be used

Blueprint filters delete

Usage

vnf blueprints filters delete [OPTIONS] FILTER_ID

Delete a blueprints’ filter.

FILTER-ID is the filter’s ID.

Optional flags

-t, --tenant-name TEXT - The name of the tenant of the filter. If not specified, the current tenant is used.

Blueprint filters get

Usage

vnf blueprints filters get [OPTIONS] FILTER_ID

Get details for a single blueprints’ filter.

FILTER-ID is the filter’s ID.

Optional flags

-t, –tenant-name TEXT The name of the tenant of the filter. If not specified, the current tenant will be used

Example

$ vnf blueprints filters get new_filter
Getting info for blueprints' filter `new_filter`...
Requested blueprints' filter info:
 id:                        new_filter
 visibility:                tenant
 created_at:                2021-04-07 15:34:39.410
 updated_at:                2021-04-07 15:34:39.410
 is_system_filter:          False
 tenant_name:               default_tenant
 created_by:                admin
 resource_availability:     tenant
 private_resource:          False
 labels_filter_rules:       "os=windows"
 attrs_filter_rules:        "created_by starts-with bob"

Blueprint filters list

Usage

vnf blueprints filters list [OPTIONS]

List all blueprints’ filters.

Optional flags

• --sort-by TEXT Key for sorting the list
• --descending Sort list in descending order [default: False]
• -t, –tenant-name TEXT The name of the tenant to list filters from. If not specified, the current tenant will be used. You cannot use this argument with arguments: [all_tenants]
• -a, –all-tenants Include resources from all tenants associated with the user. You cannot use this argument with arguments: [tenant_name].
• --search TEXT Search resources by name/id. The returned list will include only resources that contain the given search pattern
• -o, –pagination-offset INTEGER The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, –pagination-size INTEGER The max number of results to retrieve per page [default: 1000]

Blueprint filters update

Usage

vnf blueprints filters update [OPTIONS] FILTER_ID

Update an existing blueprints’ filter’s filter rules or visibility. Any flag provided as part of the update (labels’ filter-rules / attrbiutes’ filter-rules / visibility) overrides only the corresponding value. For example, if only the flag –labels-rule is provided, the labels’ filter-rules will be overridden, but the visibility and attributes’ filter-rules of the filter will stay the same.

FILTER-ID is the filter’s ID.

Optional flags

• -lr, –labels-rule TEXT A blueprint labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string or a list of strings of the form [<value1>,<value2>,…]. Escape any comma and colon in <value> with a . The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, –attrs-rule TEXT A blueprint attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [created_by]. This argument can be used multiple times.
• -l, –visibility TEXT Defines who can see the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].
• -t, –tenant-name TEXT The name of the tenant of the filter. If not specified, the current tenant will be used.

DEPLOYMENTS

The vnfm deployments command is used to manage running deployments on a VNF manager.

You can use the command to create, delete, update and list deployments and to show the outputs for a specific deployment.

Use of spaces is not supported in file names.

For more information, consult the deployment update process.

Optional Flags

These commands support the common CLI flags.

Commands

create

Usage

vnfm deployments create [OPTIONS] [DEPLOYMENT_ID]

Create a deployment on the Manager.

DEPLOYMENT_ID - The ID of the deployment to be created.

Mandatory flags

• -b, --blueprint-id TEXT - The unique identifier for the blueprint [required]

Optional Flags

• -d, --deployment-id=DEPLOYMENT_ID - A unique ID for the deployment
• -s, --site-name TEXT - Deployment’s site name
• -i, --inputs=INPUTS - Inputs for the deployment (Can be provided as wildcard-based paths (.yaml, etc..) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times.
• --skip-plugins-validation - A boolean flag that specifies whether to validate if the required deployment plugins exist on the Manager. [Default: false]
• -l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].
• --runtime-only-evaluation - If set, all intrinsic functions will only be evaluated at runtime, and no intrinsic functions will be evaluated at parse time (such as get_input, get_property).
• --labels - A labels list of the form <key>:<value>,<key>:<value>. Any comma and colon in <value> must be escaped with . The labels’ keys are saved in lowercase.

Example

$ vnfm deployments create -b simple-python-webserver-blueprint

...

Creating new deployment from blueprint simple-python-webserver-blueprint...
Deployment created. The deployment's id is simple-python-webserver-blueprint

...

update

Usage

vnfm deployments update [OPTIONS] DEPLOYMENT_ID

Update a specified deployment according to the specified blueprint.

DEPLOYMENT_ID - is the deployment’s ID to update.

Consult the Deployment maintenance guide for more information.

Mandatory flags

-b, --blueprint-id TEXT - The unique identifier of the blueprint to use for deployment update.

Optional Flags

• -i, --inputs TEXT - Inputs for the deployment (Can be provided as wildcard-based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times.
• --skip-install - Skip install lifecycle operations.
• --skip-uninstall - Skip uninstall lifecycle operations.
• --skip-reinstall - Skip automatic reinstall of node-instances whose properties are modified in the deployment update. Node instances explicitly included in the reinstall list are not skipped.
• -r, --reinstall-list TEXT - Node instances IDs to reinstall. This argument can be used multiple times.
• --ignore-failure - Pass ignore-failure option to uninstall workflow.
• --install-first - First run the install workflow and then run the uninstall workflow.
• --preview - If set, does not perform the update and returns the steps this update would make.
• --dont-update-plugins - If set, does not perform any of the plugin updates.
• -f, --force - Force an update to run, in the event that a previous update on this deployment did not complete successfully.
• --include-logs / --no-logs - Include logs in returned events [default: True]
• --json-output - Output events in a consumable JSON format
• -t, --tenant-name TEXT - The name of the tenant of the deployment. If unspecified, the current tenant is used.
• --runtime-only-evaluation - If set, all intrinsic functions will only be evaluated at runtime, and no intrinsic functions will be evaluated at parse time (such as get_input, get_property).
• --auto-correct-types - If set, before creating a plan for a new deployment, an attempt will be made to cast old inputs’ values to the valid types declared in blueprint.
• --reevaluate-active-statuses - After a failed deployment update the update metadata may get invalid. Reevaluate will correct the metadata based on the last known execution. The statuses of previous active update operations will be reevaluated based on relevant executions’ statuses. terminated executions will be mapped to successful updates, while failed and any cancel statuses will be mapped to failed.

For more information, consult the deployment update process.

Example

$ vnfm deployments update simple-python-webserver-blueprint -p simple-python-webserver-blueprint/blueprint.yaml

...

Updating deployment vnfm-nodecellar-example using blueprint vnfm-nodecellar-example/simple-blueprint.yaml
2017-03-30 10:26:12.723  VNF <vnfm-nodecellar-example> Starting 'update' workflow execution
2017-03-30 10:26:13.201  VNF <vnfm-nodecellar-example> 'update' workflow execution succeeded
Finished executing workflow 'update' on deployment 'vnfm-nodecellar-example'
Successfully updated deployment vnfm-nodecellar-example. Deployment update id: vnfm-nodecellar-example-d53a26e8-a10a-4545-956b-8bad45b90966. Execution id: dcf2dc2f-dc4f-4036-85a6-e693196e6331

...

history

Usage

vnfm deployments history [OPTIONS]

List deployment updates history.

Optional Flags

• -d, --deployment-id TEXT - The ID of the deployment for which you want to show the history of deployment updates.
• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t, --tenant-name TEXT - The name of the tenant for which you want to show the history of deployment updates. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This option cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search deployments by ID. The returned list will include only deployments that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0].
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

get-update

Usage

vnfm dep get-up [OPTIONS] DEPLOYMENT_UPDATE_ID

List deployment update details.

Optional Flags

• -t, --tenant-name TEXT - The name of the tenant for which you want to show the history of deployment updates. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.

delete

Usage

vnfm deployments delete [OPTIONS] DEPLOYMENT_ID

Delete a deployment from VNF Manager.

Deleting a deployment does not delete the resources of an application. To delete the resources, run the uninstall workflow (unless a custom uninstall workflow is provided).

DEPLOYMENT_ID - The ID of the deployment to delete

Optional Flags

• -f, --force - Delete the deployment even if there are existing live nodes for it
• -l, --with-logs - If set, then the deployment’s management workers logs are deleted as well [default: False]
• -t, --tenant-name TEXT - The name of the tenant of the deployment. If unspecified, the current tenant is used.

Example

$ vnfm deployments delete simple-python-webserver-blueprint

...

Deleting deployment simple-python-webserver-blueprint...
Deployment deleted

...

list

Usage

vnfm deployments list [OPTIONS]

List deployments.

If --blueprint-id is provided, list deployments for that blueprint. Otherwise, list deployments for all blueprints.

Optional Flags

• -b, --blueprint-id TEXT - The ID of the blueprint for which you want to list deployments.
• --filter-id TEXT - Filter results according to the specified filter (based on the filter ID)
• -lr, --labels-rule TEXT - A deployment labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Any comma and colon in must be escaped with . The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, --attrs-rule TEXT - A deployment attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [blueprint_id, created_by, site_name, schedules]. This argument can be used multiple times.
• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t, --tenant-name TEXT - The name of the tenant for which you want to list deployments. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This option cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search deployments by id. The returned list will include only deployments that contain the given search pattern.
• --search-name TEXT - Search deployments by their display name. The returned list will include only deployments that contain the given search pattern.
• --dependencies-of TEXT - List only deployments on which the given deployment ID depends.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0].
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm deployments list

...

Listing all deployments...

Deployments:
+-----------------------------+-----------------------------+--------------------------+--------------------------+------------+----------------+------------+
|              id             |         blueprint_id        |        created_at        |        updated_at        | visibility |  tenant_name   | created_by |
+-----------------------------+-----------------------------+--------------------------+--------------------------+------------+----------------+------------+
| vnfm-nodecellar-example     | vnfm-nodecellar-example     | 2017-03-30 10:14:40.556  | 2017-03-30 10:14:40.556  |   tenant   | default_tenant |   admin    |
+-----------------------------+-----------------------------+--------------------------+--------------------------+------------+----------------+------------+

...

summary

Usage

vnfm deployments summary <field> [optional sub-field] [OPTIONS]

Summarizes deployments, giving a count of elements with each distinct value for the selected field. If a sub-field is selected then a count will be given for each distinct field and sub-field combination, as well as totals for each field.

For valid field/sub-field names, invoke vnfm deployments summary.

Example

$ vnfm deployments summary blueprint_id
Retrieving summary of deployments on field blueprint_id

Deployment summary by blueprint_id
+--------------+-------------+
| blueprint_id | deployments |
+--------------+-------------+
|     sga      |      3      |
|      s       |      5      |
|      sg      |      1      |
+--------------+-------------+

...

$ vnfm deployments summary --all-tenants tenant_name blueprint_id
Retrieving summary of deployments on field tenant_name

Deployment summary by tenant_name
+----------------+--------------+-------------+
|  tenant_name   | blueprint_id | deployments |
+----------------+--------------+-------------+
|     test1      |      s       |      1      |
|     test1      |      sg      |      3      |
|     test1      |     sga      |      5      |
|     test1      |    TOTAL     |      9      |
|     test2      |     sga      |      1      |
|     test2      |      s       |      3      |
|     test2      |      sg      |      5      |
|     test2      |    TOTAL     |      9      |
| default_tenant |     sga      |      3      |
| default_tenant |      s       |      5      |
| default_tenant |      sg      |      1      |
| default_tenant |    TOTAL     |      9      |
+----------------+--------------+-------------+

...

inputs

Usage

vnfm deployments inputs [OPTIONS] DEPLOYMENT_ID

Retrieve inputs for a specific deployment.

DEPLOYMENT_ID - The ID of the deployment for which you want to list inputs.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant for which you want to list inputs. If unspecified, the current tenant is used.

Example

$ vnfm deployments inputs vnfm-nodecellar-example

...

Retrieving inputs for deployment vnfm-nodecellar-example...
 - "agent_private_key_path":
  Value: /key.pem
 - "agent_user":
  Value: centos
 - "host_ip":
  Value: 172.16.0.7

...

outputs

Usage

vnfm deployments outputs [OPTIONS] DEPLOYMENT_ID

Lists all outputs for a deployment. Not every deployment has outputs and it depends on whether or not outputs were defined in the blueprint from which the deployment was created

DEPLOYMENT_ID - The ID of the deployment for which you want to list outputs.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant for which you want to list outputs. If unspecified, the current tenant is used.

Example

$ vnfm deployments outputs vnfm-nodecellar-example

...

Retrieving outputs for deployment vnfm-nodecellar-example...
 - "endpoint":
     Description: Web application endpoint
     Value: {u'ip_address': u'172.16.0.7', u'port': 8080}

...

capabilities

Usage

vnfm deployments capabilities [OPTIONS] DEPLOYMENT_ID

Lists all capabilities for a deployment. Not every deployment has capabilities and it depends on whether or not capabilities were defined in the blueprint from which the deployment was created

DEPLOYMENT_ID - The ID of the deployment for which you want to list capabilities.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant for which you want to list capabilities. If unspecified, the current tenant is used.

Example

$ vnfm deployments capabilities vnfm-nodecellar-example

...

Retrieving capabilities for deployment vnfm-nodecellar-example...
 - "endpoint":
     Description: Web application endpoint
     Value: {u'ip_address': u'172.16.0.7', u'port': 8080}

...

set-visibility

Usage

vnfm deployments set-visibility [OPTIONS] DEPLOYMENT_ID

Set the deployment’s visibility to tenant.

DEPLOYMENT_ID - The id of the deployment to update.

Mandatory flags

-l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘tenant’, ‘global’] [required].

Example

$ vnfm deployments set-visibility vnfm-nodecellar-example -l tenant

...

Deployment `vnfm-nodecellar-example` was set to tenant

...

set-site

Usage

vnfm depployments set-site [OPTIONS] DEPLOYMENT_ID

Set the deployment’s site.

DEPLOYMENT_ID is the id of the deployment to update

Optional Flags

• -s, --site-name TEXT - Deployment’s site name
• -d, --detach-site - If set, detach the current site, making the deployment siteless [default: False]. You cannot use this argument with arguments: [site_name]

set-owner

Usage

vnfm deployments set-owner [OPTIONS] DEPLOYMENT_ID

Change ownership of a deployment.

DEPLOYMENT_ID - The id of the deployment to update.

Optional flags

• -s, --username USERNAME - The name of the user who will be the new owner of the resource. [required]
• -t, --tenant-name TEXT - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm deployments set-owner cloudify-nodecellar-example -s admin
...

Deployment `cloudify-nodecellar-example` is now owned by user `admin`.

...

labels

A deployment label is a key-value pair that can be assigned with a deployment. There can be multiple labels assigned with each deployment, and one can assign more than one label with the same key (yet different value) to the same deployment.

labels list

Usage

vnf deployments labels list [OPTIONS] DEPLOYMENT_ID

List the deployment’s labels.

DEPLOYMENT_ID is the ID of the deployment for which to list the labels.

labels add

Usage

vnf deployments labels add [OPTIONS] LABELS_LIST DEPLOYMENT_ID

Add labels to a specific deployment.

DEPLOYMENT_ID is the ID of the deployment to update.

LABELS_LIST: <key>:<value>,<key>:<value>. Escape any comma and colon in <value> with a (backslash).

labels delete

Usage

vnf deployments labels delete [OPTIONS] LABEL DEPLOYMENT_ID

Delete labels from a specific deployment.

DEPLOYMENT_ID is the ID of the deployment to update.

LABEL: A mixed list of labels and keys; for example, <key>:<value>,<key>,<key>:<value>. If <key> is provided, all labels associated with this key will be deleted from the deployment. Escape any comma and colon in <value> with a (backslash).

Schedule

A deployment schedule, a.k.a. execution schedule, allows you to set a scheduling rule for the execution of a particular workflow, such as install or uninstall, on a deployment. This allows both single-use; for example, postponed executions, and recurrent executions (for example, running each Sunday at 19:30).

schedule list

Usage

vnf deployments schedule list [OPTIONS] [DEPLOYMENT_ID]

List all deployment schedules on the manager. If DEPLOYMENT_ID is provided, list only schedules of this deployment.

Optional flags

Regular optional flags for list commands:

• --sort-by TEXT - Key for sorting the list * –descending - Sort list in descending order [default: False]
• -t --tenant-name TEXT - The name of the tenant for which to list the deployment schedules. If not specified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a --all-tenants - Include resources from all tenants associated with the user. This option cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search schedules by id. The returned list will include only schedules that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Additionally:

• -s, --since TEXT - List only schedules which have occurrences after this time. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min.
• -u, --until TEXT - List only schedules which have occurrences before this time. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min.
• --tz TEXT - The timezone to be used for scheduling; for example, EST or Asia/Jerusalem. By default, the local timezone will be used. Supports any timezone in the tz database

Valid relative time expressions are of the form +<integer> minutes|hours|days|weeks|months|years or a concatenation of these; for example, +1 year +3 months. You can also write without a space after the number, without the final s, or using the short forms min|h|d|w|mo|y.

schedule get

Usage

vnf deployments schedule get [OPTIONS] DEPLOYMENT_ID SCHEDULE_ID

Retrieve information for a specific deployment schedule.

DEPLOYMENT_ID is the ID of the deployment to which the schedule belongs. SCHEDULE_ID is the ID of the deployment schedule for which to retrieve information.

Optional flags

• -preview INTEGER - Preview the N next dates for the workflow execution to run.
• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used

schedule create

Usage

vnf deployments schedule create [OPTIONS] DEPLOYMENT_ID WORKFLOW_ID

Schedule the execution of a workflow on a given deployment.

DEPLOYMENT_ID is the ID of the deployment for which to create the schedule. WORKFLOW_ID is the ID of the workflow the schedule will run.

Mandatory flags

• -s, --since TEXT - The earliest possible time to run. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min.

Optional flags

• -n, --schedule-name TEXT - A name for the schedule. If not provided, defaults to {deployment-id}_{workflow-id}.
• -p, --parameters TEXT - Parameters for the workflow (can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). You can use this argument repeatedly.
• --allow-custom-parameters - Allow passing custom parameters (which were not defined in the workflow’s schema in the blueprint) to the execution.
• -f, --force - Execute the workflow even if there is an ongoing execution for the given deployment.
• --dry-run - If set, no actual operations will be performed. This only prints the executed tasks, without side effects.
• --wait-after-fail INTEGER - When a task fails, wait this many seconds for already-running tasks to return [default: 600].
• -u, --until TEXT - The latest possible time to run. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min.
• --tz TEXT - The timezone to be used for scheduling, e.g. EST or Asia/Jerusalem. By default, the local timezone will be used. Supports any timezone in the tz database
• -r, --recurrence TEXT - Recurrence on the scheduled execution. e.g. 2 weeks, 30 min or 1d. You cannot use this argument with arguments: [rrule]
• -c, --count INTEGER - Maximum number of times to run the execution. If left empty, there’s no limit on repetition. You cannot use this argument with arguments: [rrule]
• --weekdays TEXT - Weekdays on which to run the execution, e.g. su,mo,tu. If left empty, runs on any weekday. You cannot use this argument with arguments: [rrule]
• --rrule TEXT - A scheduling rule in the iCalendar format, e.g. RRULE:FREQ=DAILY;INTERVAL=3, which means run every 3 days. You cannot use this argument with arguments: [count, recurrence, weekdays]
• --slip INTEGER - Maximum time window after the target time has passed, in which the scheduled execution can run [in minutes, default=0]
• --stop-on-fail - Whether to stop scheduling the execution in case it failed.
• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used

Valid relative time expressions are of the form +<integer> minutes|hours|days|weeks|months|years or a concatenation of these, for example, +1 year +3 months. These can be also written without a space after the number, without the final s, or using the short forms min|h|d|w|mo|y.

Valid recurrence expressions are of the form <integer> minutes|hours|days|weeks|months|years. These can be also written without a space after the number, without the final s, or using the short forms min|h|d|w|mo|y.

Valid weekdays expressions are any of su|mo|tu|we|th|fr|sa, or a comma-separated list of them. These may be optionally prefixed by 1 to 4 or l- (for “last”) signifying a “complex weekday”, e.g. 2mo for “the 2nd Monday of a month” or l-fr for “the last Friday of a month”. Complex weekdays can only be used in tandem with a months or years recurrence.

schedule update

Usage

vnf deployments schedule update [OPTIONS] DEPLOYMENT_ID SCHEDULE_ID

Update an existing schedule for a workflow execution.

DEPLOYMENT_ID is the ID of the deployment to which the schedule belongs. SCHEDULE_ID is the ID of the deployment schedule to update.

Optional flags

` -s, --since TEXT - The earliest possible time to run. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min. - -u, --until TEXT - The latest possible time to run. Supported formats: YYYY-MM-DD HH:MM, HH:MM, or a relative time expression such as +2 weeks or +1day+10min. - --tz TEXT - The timezone to be used for scheduling; for example, EST or Asia/Jerusalem. By default, the local timezone will be used. Supports any timezone in the tz database - -r, --recurrence TEXT - Recurrence on the scheduled execution; for example, 2 weeks, 30 min or 1d. You cannot use this argument with arguments: [rrule] - -c, --count INTEGER - Maximum number of times to run the execution. If left empty, there’s no limit on repetition. You cannot use this argument with arguments: [rrule] - --weekdays TEXT - Weekdays on which to run the execution; for example, su,mo,tu. You cannot use this argument with arguments: [rrule] - --rrule TEXT - A scheduling rule in the iCalendar format; for example, RRULE:FREQ=DAILY;INTERVAL=3, which means run every 3 days. You cannot use this argument with arguments: [count, recurrence, weekdays]. - --slip INTEGER - Maximum time window after the target time has passed, in which the scheduled execution can run [in minutes, default=0] - --stop-on-fail - Whether to stop scheduling the execution in case it failed. - -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant is used.

Valid relative time expressions are of the form +<integer> minutes|hours|days|weeks|months|years or a concatenation of these; for example, +1 year +3 months. These can be also written without a space after the number, without the final s, or using the short forms min|h|d|w|mo|y.

Valid recurrence expressions are of the form <integer> minutes|hours|days|weeks|months|years. These can be also written without a space after the number, without the final s, or using the short forms min|h|d|w|mo|y.

Valid weekdays expressions are any of su|mo|tu|we|th|fr|sa, or a comma-separated list of them. These may be optionally prefixed by 1 to 4 or l- (for “last”) signifying a “complex weekday”, e.g. 2mo for “the 2nd Monday of a month” or l-fr for “the last Friday of a month”. Complex weekdays can only be used in tandem with a months or years recurrence.

schedule delete

Usage

vnf deployments schedule delete [OPTIONS] NAME

Delete a schedule for a workflow execution.

DEPLOYMENT_ID is the ID of the deployment to which the schedule belongs. SCHEDULE_ID is the ID of the deployment schedule to delete.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used

schedule enable

Usage

vnf deployments schedule enable [OPTIONS] DEPLOYMENT_ID SCHEDULE_ID

Enable a previously-disabled schedule for a workflow execution.

DEPLOYMENT_ID is the ID of the deployment to which the schedule belongs. SCHEDULE_ID is the ID of the deployment schedule to enable.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used.

schedule disable

Usage

vnf deployments schedule disable [OPTIONS] DEPLOYMENT_ID SCHEDULE_ID

Disable a schedule for a workflow execution.

DEPLOYMENT_ID is the ID of the deployment to which the schedule belongs. SCHEDULE_ID is the ID of the deployment schedule to disable.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used

schedule summary

Usage

vnf deployments schedule summary [OPTIONS] [deployment_id|workflow_id|tenant_name|visibility]

Retrieve summary of deployment schedules; for example, a count of schedules with the same deployment ID.

TARGET_FIELD is the field on which to summarise deployment schedules.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the deployment schedule. If not specified, the current tenant will be used

Example

$ vnf deployments schedule summary deployment_id

Retrieving summary of deployment schedules on field deployment_id.

Deployment schedules summary by deployment_id:

+---------------+------------+---------------------+
| deployment_id | recurrence | execution_schedules |
+---------------+------------+---------------------+
|       a       | recurring  |          3          |
|       a       |   single   |          1          |
|       a       |   TOTAL    |          4          |
+---------------+------------+---------------------+

Modifications

A modification is a specification of changes that are scheduled for a deployment. It is a result of running a scaling workflow on a deployment.

modifications list

Usage

vnf deployments modifications list [OPTIONS] DEPLOYMENT_ID

List the deployment’s modifications.

DEPLOYMENT_ID is the ID of the deployment for which to list the modifications.

Example

$ vnf deployments modifications list openstack

Listing modifications of the deployment openstack…

Deployment modifications:

+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+
|                  id                  | workflow_id |             execution_id             |  status  |  tenant_name   |        created_at        | visibility |
+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+
| 57924e3c-f317-4604-a52b-c28abba90b64 |    scale    | f87c13d2-a6cd-4b5a-8d05-46193fe818bd | finished | default_tenant | 2021-01-22 10:18:22.101  |   tenant   |
| 05b0b0d5-9ed6-4f84-b3a9-3bd33ddc34ef |    scale    | ad9773e2-7018-49c9-8f02-93a4f8895637 | started  | default_tenant | 2021-01-22 10:25:47.087  |   tenant   |
+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+

Showing 2 of 2 deployment modifications.

modifications get

Usage

vnf deployments modifications get [OPTIONS] DEPLOYMENT_MODIFICATION_ID

Show summary of the deployment’s modification.

DEPLOYMENT_MODIFICATION_ID is the ID of the deployment modification to retrieve.

Example

``$ vnf deployments modifications get 57924e3c-f317-4604-a52b-c28abba90b64``

Retrieving deployment modification 57924e3c-f317-4604-a52b-c28abba90b64...

Deployment Modification:

+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+
|                  id                  | workflow_id |             execution_id             |  status  |  tenant_name   |        created_at        | visibility |
+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+
| 57924e3c-f317-4604-a52b-c28abba90b64 |    scale    | f87c13d2-a6cd-4b5a-8d05-46193fe818bd | finished | default_tenant | 2021-01-22 10:18:22.101  |   tenant   |
+--------------------------------------+-------------+--------------------------------------+----------+----------------+--------------------------+------------+

Modified nodes:
     - vm1

Node instances before modifications:
     - net_5vywa3 (net)
     - subnet_331f8n (subnet)
     - sec_group_evub21 (sec_group)
     - vm1_hjh3jp (vm1)

Added node instances:
     - vm1_sp6iar (vm1)

modifications rollback

Usage

vnf deployments modifications rollback [OPTIONS] DEPLOYMENT_MODIFICATION_ID

Rollback the broken (for example, stalled) deployment’s modification.

DEPLOYMENT_MODIFICATION_ID is the ID of the deployment modification to be rolled back.

Example

``$ vnf deployments modifications rollback bfcfd57e-814c-4de2-acc6-373d6e1ed232``

Rolling back a deployment modification bfcfd57e-814c-4de2-acc6-373d6e1ed232...

Deployment Modification:

+--------------------------------------+-------------+--------------------------------------+------------+----------------+--------------------------+------------+
|                  id                  | workflow_id |             execution_id             |   status   |  tenant_name   |        created_at        | visibility |
+--------------------------------------+-------------+--------------------------------------+------------+----------------+--------------------------+------------+
| bfcfd57e-814c-4de2-acc6-373d6e1ed232 |    scale    | 1ffef87b-f10a-493c-8087-d5f8055938d0 | rolledback | default_tenant | 2021-01-22 11:46:55.390  |   tenant   |
+--------------------------------------+-------------+--------------------------------------+------------+----------------+--------------------------+------------+

Modified nodes:
     - vm1

Node instances before modifications:
     - net_5vywa3 (net)
     - subnet_331f8n (subnet)
     - sec_group_evub21 (sec_group)

Node instances before rollback:
     - net_5vywa3 (net)
     - subnet_331f8n (subnet)
     - sec_group_evub21 (sec_group)
     - vm1_b0kgj5 (vm1)

Added node instances:
     - vm1_b0kgj5 (vm1)

Deployment filters

A filter is defined as a set of filter-rules that can be used to filter a list of deployments, based on their labels and certain attributes. Deployments can be filtered by the following attributes: blueprint_id, created_by, site_name, and schedules.

For complete details about each filter rule, refer to filter-rules.

Deployment filters create

Usage

vnf deployments filters create [OPTIONS] FILTER_ID

Create a new deployments’ filter.

FILTER-ID is the new filter’s ID.

Optional flags

• -lr, --labels-rule TEXT - A deployment labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string or a list of strings of the form [<value1>,<value2>,…]. Escape any comma and colon in <value> with a (backslash). The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, --attrs-rule TEXT - A deployment attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [blueprint_id, created_by, site_name, schedules]. You can us this argument multiple times.
• -l, --visibility TEXT - Defines who can see the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant]
• -t, --tenant-name TEXT - The name of the tenant of the filter. If not specified, the current tenant will be used

Deployment filters delete

Usage

vnf deployments filters delete [OPTIONS] FILTER_ID

Delete a deployments’ filter.

FILTER-ID is the filter’s ID.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the filter. If not specified, the current tenant is used.

Deployment filters get

Usage

vnf deployments filters get [OPTIONS] FILTER_ID

Get details for a single deployments’ filter.

FILTER-ID is the filter’s ID.

Optional flags

• -t, --tenant-name TEXT - The name of the tenant of the filter. If not specified, the current tenant is used.

Example

$ vnf deployments filters get new_filter
Getting info for deployments' filter `new_filter`...
Requested deployments' filter info:
   id:                        new_filter
   visibility:                tenant
   created_at:                2021-04-07 15:34:39.410
   updated_at:                2021-04-07 15:34:39.410
   is_system_filter:          False
   tenant_name:               default_tenant
   created_by:                admin
   resource_availability:     tenant
   private_resource:          False
   labels_filter_rules:       "os=windows"
   attrs_filter_rules:        "created_by starts-with bob"

Deployment filters list

Usage

vnf deployments filters list [OPTIONS]

List all deployments’ filters.

Optional flags

• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t, --tenant-name TEXT - The name of the tenant to list filters from. If not specified, the current tenant will be used. You cannot use this argument with arguments: [all_tenants]
• -a, --all-tenants - Include resources from all tenants associated with the user. You cannot use this argument with arguments: [tenant_name].
• --search TEXT - Search resources by name/id. The returned list will include only resources that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0].
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000].

Deployment filters update

Usage

vnf deployments filters update [OPTIONS] FILTER_ID

Update an existing deployments’ filter’s filter rules or visibility. Any flag provided as part of the update (labels’ filter-rulea / attributes’ filter-rulea / visibility) overrides only the corresponding value. For example, if only the flag --labels-rule is provided, the labels’ filter-rules will be overridden, but the visibility and attributes’ filter-rules of the filter will stay the same.

FILTER-ID is the filter’s ID.

Optional flags

• -lr, --labels-rule TEXT - A deployment labels’ filter rule. Labels’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> is-not <value>, <key> is null, <key> is not null. <value> can be a single string or a list of strings of the form [<value1>,<value2>,…]. Any comma and colon in <value> must be escaped with . The labels’ keys specified in the filter rules will be saved in lower case.
• -ar, --attrs-rule TEXT - A deployment attributes’ filter rule. Attributes’ filter rules must be one of: <key>=<value>, <key>!=<value>, <key> contains <value>, <key> does-not-contain <value>, <key> starts-with <value>, <key> ends-with <value>, <key> is not empty. <value> can be a single string, or a list of strings of the form [<value1>,<value2>,…]. Allowed attributes to filter by are: [blueprint_id, created_by, site_name, schedules]. This argument can be used multiple times
• -l, --visibility TEXT - Defines who can see the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant]
• -t, --tenant-name TEXT - The name of the tenant of the filter. If not specified, the current tenant is used.

EVENTS

The vnfm events command is used to view events of a specific execution.

Optional Flags

These commands support the common CLI flags.

Commands

list

Usage

vnfm events list [OPTIONS] EXECUTION_ID

Display events for an execution

• EXECUTION_ID - The unique identifier for the execution. Mandatory.

Optional Flags

• --include-logs / --no-logs - Include logs in returned events. [default: True]
• --json - Output events in a consumable JSON format.
• --tail - Tail the events of the specified execution until it ends.
• -t, --tenant-name TEXT - The name of the tenant on which the execution occurred. If unspecified, the current tenant is used.
• --from DATETIME - Output only events that occurred at this timestamp or later. Valid DATETIME format is one of the following: %Y-%m-%d, %Y-%m-%dT%H:%M:%S, %Y-%m-%d %H:%M:%S, %Y-%m-%d %H:%M:%S.%f or Unix time format (number of seconds since Epoch with microseconds as decimal fraction).
• --to DATETIME - Output only events that occurred at this timestamp or before. Valid timestamp format as for –from parameter.
• --before TEXT - Output only events that occurred in or before the time defined as such. The correct format for describing this period is NUMBER second(s)/minute(s)/hour(s)/day(s)/week(s)/month(s)/year(s) [ago], for example, 3 months, 1 week ago, 25 minutes ago. This parameter is mutually exclusive with –to.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm events list -e dcf2dc2f-dc4f-4036-85a6-e693196e6331
...

Listing events for execution id dcf2dc2f-dc4f-4036-85a6-e693196e6331 [include_logs=True]
2017-03-30 10:26:12.723  VNF <vnfm-nodecellar-example> Starting 'update' workflow execution
2017-03-30 10:26:13.201  VNF <vnfm-nodecellar-example> 'update' workflow execution succeeded

Total events: 2

...

delete

Usage

vnfm events delete [OPTIONS] EXECUTION_ID

Delete events attached to a deployment.

DEPLOYMENT_ID is the ID of the deployment events to delete

Optional Flags

• --include-logs / --no-logs - Include logs in returned events [default: True]
• -t, --tenant-name TEXT - The name of the tenant on which the execution occurred. If unspecified, the current tenant is used.
• --from DATETIME - Output only events that occurred at this timestamp or later. Valid DATETIME format is one of the following: %Y-%m-%d, %Y-%m-%dT%H:%M:%S, %Y-%m-%d %H:%M:%S, %Y-%m-%d %H:%M:%S.%f or Unix time format (number of seconds since Epoch).
• --to DATETIME - Delete only events that occurred at this timestamp or before. Valid timestamp format as for –from parameter. This parameter is mutually exclusive with –before.
• --before TEXT - Delete only events that took place in or before the time defined as such. The correct format for describing this period is NUMBER second(s)/minute(s)/hour(s)/day(s)/week(s)/month(s)/year(s) [ago], for example, 3 months, 1 week ago, 25 minutes ago. This parameter is mutually exclusive with –to.
• --store-before - Store events/logs before deleting them. The exact behaviour is then determined by the –output-path parameter: if it is not set, then all the storage is done on the manager’s side and output files are /opt/manager/logs/<TABLE_NAME>_<DEPLOYMENT_ID>_<TIMESTAMP>.log.
• --output-path FILE - Define a location on a machine running vnfm command for a file where events listed before deletion will be stored.

Example

vnfm events delete cloudify-nodecellar-example
...

Deleting events for deployment id cloudify-nodecellar-example [include_logs=True]

Deleted 344 events

...

vnfm events delete --from "2020-05-13 15:49:40" --to "2020-05-13 15:49:46" --store-before cloudify-nodecellar-example
...

Deleting events for deployment id test [include_logs=True, from_datetime=2020-05-13 15:49:40, to_datetime=2020-05-13 15:49:46]

Deleted 8 events

...

vnfm events delete --before "10 seconds" --store-before --output-path ~/deleted-test-logs.txt test
...

Deleting events for deployment id test [include_logs=True, to_datetime=2020-05-13 15:53:43.892]

Deleted 6 events

...

EXECUTIONS

The vnfm executions command is used to manage workflow executions on VNF Manager.

You can use the command to start, cancel and list executions and to retrieve information about a single execution.

You can also schedule executions to start in a specific date and time in the future (using the --schedule flag).

Optional Flags

These commands support the common CLI flags.

Commands

start

Usage

vnfm executions start [OPTIONS] WORKFLOW_ID

Execute a workflow on a given deployment

WORKFLOW_ID is the ID of the workflow to execute (for example, uninstall)

Optional Flags

• -d, --deployment-id TEXT - The deployment ID to execute the workflow on
• -p, --parameters TEXT - Parameters for the workflow execution (Can be provided as wildcard based paths (*.yaml, etc.) to YAML files, a JSON string or as “key1=value1;key2=value2”). This argument can be used multiple times.
• --allow-custom-parameters - Allow passing custom parameters (which were not defined in the workflow’s schema in the blueprint) to the execution
• -f, --force - Execute the workflow even if there is an ongoing execution for the given deployment
• --timeout INTEGER - Operation timeout in seconds (The execution itself will keep going, but the CLI will stop waiting for it to terminate) (default: 900)
• -l, --include-logs / --no-logs - Include logs in returned events
• --json - Output events in a consumable JSON format
• -t, --tenant-name TEXT - The name of the tenant on which the execution will be executed. If unspecified, the current tenant is used.
• --dry-run - Execute the workflow as a dry-run so that the execution is shown step-by-step but the workflow is not implemented and no changes are made.
• --queue - If set, executions that can`t currently run will be queued and run automatically when possible. You cannot use this argument with arguments: [force, dry_run]
• --schedule TEXT - The time (including timezone) this workflow will be executed at; expected format: YYYYMMDDHHMM+HHMM or YYYYMMDDHHMM-HHMM. i.e: 201801032230-0500 (Jan-03-18 10:30pm EST). You cannot use this argument with arguments: [queue]

Example

$ vnfm executions start install -d vnfm-nodecellar-example
...

Executing workflow install on deployment vnfm-nodecellar-example [timeout=900 seconds]
2017-03-29 11:34:11.704  VNF <vnfm-nodecellar-example> Starting 'install' workflow execution
2017-03-29 11:34:12.204  VNF <vnfm-nodecellar-example> [hos...
.
.
.
2017-03-29 11:36:47.537  VNF <vnfm-nodecellar-example> 'install' workflow execution succeeded
Finished executing workflow install on deployment vnfm-nodecellar-example
* Run 'vnfm events list -e f38ad989-d09e-4b68-b041-ac63aeacb9ae' to retrieve the execution's events/logs

...

cancel

Usage

vnfm executions cancel [OPTIONS] EXECUTION_ID

Cancel a workflow’s execution.

EXECUTION_ID - The ID of the execution to be canceled.

Optional Flags

• -f, --force - Terminate the execution abruptly, rather than request an orderly termination.
• --kill - Terminate the execution abruptly and stop currently running tasks. This stops all processes running operations and workflows for the given execution.
• -t, --tenant-name TEXT - The name of the tenant on which the execution is to be canceled. If unspecified, the current tenant is used.

Example

$ vnfm executions cancel eba71d2b-2456-4423-acb0-f8fc7324e793
...

Cancelling execution eba71d2b-2456-4423-acb0-f8fc7324e793
A cancel request for execution eba71d2b-2456-4423-acb0-f8fc7324e793 has been sent. To track the execution's status, use:
vnfm executions get eba71d2b-2456-4423-acb0-f8fc7324e793

...

list

Usage

vnfm executions list [options]

List executions.

If DEPLOYMENT_ID is provided, lists executions for that deployment. Otherwise, lists executions for all deployments.

Optional Flags

• -d, --deployment-id TEXT - The ID of the deployment for which executions are to be listed.
• --include-system-workflows - Include executions of system workflows.
• --sort-by TEXT - Key for sorting the list.
• --descending - Sort list in descending order. [default: False]
• -t, --tenant-name TEXT - The name of the tenant on which the executions occurred. If unspecified, the current tenant is used.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm executions list

...

Listing all executions...

Executions:
+--------------------------------------+-------------------------------+------------+---------------+--------------------------+-------+------------+----------------+------------+
|                  id                  |          workflow_id          |   status   | deployment_id |        created_at        | error | permission |  tenant_name   | created_by |
+--------------------------------------+-------------------------------+------------+---------------+--------------------------+-------+------------+----------------+------------+
| fa330011-1f33-4e6c-82cb-a4537e13c950 |            install            | terminated |   nodecellar  | 2017-03-28 07:47:04.733  |       |  creator   | default_tenant |   admin    |
| 261ac6f8-c75d-4e28-9c62-646925cd326c |           uninstall           | terminated |   nodecellar  | 2017-03-28 07:55:02.582  |       |  creator   | default_tenant |   admin    |
+--------------------------------------+-------------------------------+------------+---------------+--------------------------+-------+------------+----------------+------------+

...

summary

Usage

vnfm executions summary <field> [optional sub-field] [OPTIONS]

Summarizes executions, giving a count of elements with each distinct value for the selected field. If a sub-field is selected then a count will be given for each distinct field and sub-field combination, as well as totals for each field.

For valid field/sub-field names, invoke vnfm executions summary

Example

$ vnfm executions summary deployment_id

Retrieving summary of executions on field deployment_id

Execution summary by deployment_id
+---------------+------------+
| deployment_id | executions |
+---------------+------------+
|      sga1     |     2      |
|      sga3     |     2      |
|      sga2     |     2      |
|       s3      |     2      |
|       s2      |     2      |
|       s1      |     2      |
|       s5      |     2      |
|       s4      |     2      |
|      sg1      |     2      |
+---------------+------------+

...

$ vnfm executions summary workflow_id status
Retrieving summary of executions on field workflow_id

Execution summary by workflow_id
+-------------------------------+------------+------------+
|          workflow_id          |   status   | executions |
+-------------------------------+------------+------------+
|        create_snapshot        | terminated |     1      |
|        create_snapshot        |   TOTAL    |     1      |
| create_deployment_environment | terminated |     9      |
| create_deployment_environment |   TOTAL    |     9      |
|            install            | terminated |     9      |
|            install            |   TOTAL    |     9      |
|        restore_snapshot       |  started   |     1      |
|        restore_snapshot       |   TOTAL    |     1      |
+-------------------------------+------------+------------+

...

get

Usage

vnfm executions get [OPTIONS] EXECUTION_ID

Retrieve information for a specific execution.

EXECUTION_ID is the execution about which to retrieve information.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant on which the execution occurred. If unspecified, the current tenant is used.

Example

$ vnfm executions get f38ad989-d09e-4b68-b041-ac63aeacb9ae

...

Retrieving execution f38ad989-d09e-4b68-b041-ac63aeacb9ae

Execution:
+--------------------------------------+-------------------------------+-----------+------------+--------------------------+--------------+--------------------------+--------------------------+-------+------------+----------------+------------+--------------------------+---------------+
|                  id                  |          workflow_id          |   status  | is_dry_run | deployment_id            | blueprint_id |        created_at        |         ended_at         | error | visibility |  tenant_name   | created_by |        started_at        | scheduled_for |
+--------------------------------------+-------------------------------+-----------+------------+--------------------------+--------------+--------------------------+--------------------------+-------+------------+----------------+------------+--------------------------+---------------+
| f38ad989-d09e-4b68-b041-ac63aeacb9ae | install                       | completed |   False    | vnfm-nodecellar-example  | blueprint    | 2019-08-25 11:41:16.158  | 2019-08-25 11:41:18.749  |       |   tenant   | default_tenant |   admin    | 2019-08-25 11:41:16.161  |               |
+--------------------------------------+-------------------------------+-----------+------------+--------------------------+--------------+--------------------------+--------------------------+-------+------------+----------------+------------+--------------------------+---------------+

Execution Parameters:
...

resume

vnfm executions resume [OPTIONS] EXECUTION_ID

Resume the execution of a workflow in a failed or cancelled state.

EXECUTION_ID is the ID of the execution to resume. The workflow will run again, restoring the tasks graph from the storage, and retrying failed tasks when necessary. If reset-operations is passed, tasks that were started but didn’t fail will be retried as well.

Optional Flags

• --reset-operations - Reset operations in started state, so that they are run again unconditionally
• -t, --tenant-name TEXT - The name of the tenant of the execution. If not specified, the current tenant will be used

Example

$ vnfm executions resume 19280e9a-7163-4066-b4f4-a09aaed6dd0e

...

Resuming execution 19280e9a-7163-4066-b4f4-a09aaed6dd0e
A resume request for execution 19280e9a-7163-4066-b4f4-a09aaed6dd0e has been sent. To track the execution's status, use:
vnfm executions get 19280e9a-7163-4066-b4f4-a09aaed6dd0e

FILTER-RULES

A filter is defined as a set of filter-rules that can be used to filter a list of objects, based on their labels and certain attributes. Filters are currently supported for deployments and blueprints.

Filtering deployments is supported in the UI, CLI, and API. The allowed deployments’ attributes to filter by include:

• blueprint_id
• site_name
• created_by

Filtering blueprints is supported only in the CLI and API. The allowed blueprints’ attribute to filter by is created_by.

Labels operators mapping:

UI	API	CLI	Applied logic
is one of	any_of	=	The label key matches the specified key and the label value matches one of the specified values.
is not one of	not_any_of	!=	The label key matches the specified key and the label value does not match any of the specified values.
is not one of (or no such key)	is_not	is-not	No label key matches the specified key, or the label key matches the specified key and the label value does not match any of the specified values.
key is not	is_null	is null	No label key matches the specified key.
key is	is_not_null	is not null	The label key matches the specified key.

Attributes operators mapping:

UI	API	CLI	Applied logic
is one of	any_of	=	The resource attribute matches one of the specified values.
is not one of	not_any_of	!=	The resource attribute does not match any of the specified values.
contains	contains	contains	The resource attribute contains the specified value.
does not contain	not_contains	does-not-contain	The resource attribute does not contain the specified value.
starts with	starts_with	starts-with	The resource attribute starts with the specified value.
ends with	ends_with	ends-with	The resource attribute ends with the specified value.

GROUPS

The vnfm groups command is used to view information on the different groups in a deployment.

You can use the command to list all groups.

Optional Flags

These commands support the common CLI flags.

Commands

list

Usage

vnfm groups list [OPTIONS]

Lists all groups for a deployment.

DEPLOYMENT_ID is the ID of the deployment for which to list groups.

Required Flags

• -d, --deployment-id TEXT - The ID of the deployment for which to list groups.
• -t, tenant-name TEXT - The name of the tenant on which the deployment is made. If unspecified, the current tenant is used.

Example

$ vnfm groups list -d hello_world

...

Listing groups for deployment hello_world...
No groups defined for deployment hello_world

...

INSTALL

The vnfm install command is used to install an application using a VNF manager without having to manually go through the process of uploading a blueprint, creating a deployment and executing a workflow.

Usage

vnfm install [OPTIONS] [BLUEPRINT_PATH]

Install an application via the manager.

BLUEPRINT_PATH can be either a blueprint yaml file or blueprint archive; a url to a blueprint archive or an organization/blueprint_repo[:tag/branch] (to be retrieved from GitHub)

This will upload the blueprint, create a deployment and execute the install workflow.

Optional Flags

This command supports the common CLI flags.

• -b, --blueprint-id TEXT - The unique identifier for the blueprint [manager only]
• -n, --blueprint-filename TEXT - The name of the archive’s main blueprint file. This is only relevant if uploading an archive
• --validate - Validate the blueprint first
• -d, --deployment-id TEXT - The unique identifier for the deployment [manager only]
• -i, --inputs TEXT - Inputs for the deployment (Can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times
• -w, --workflow-id TEXT - The workflow to execute [default: install]
• -p, --parameters TEXT - Parameters for the workflow (Can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times
• --allow-custom-parameters - Allow passing custom parameters (which were not defined in the workflow’s schema in the blueprint) to the execution
• --timeout INTEGER - Operation timeout in seconds (The execution itself will keep going, but the CLI will stop waiting for it to terminate) [default: {0}] [manager only]
• --include-logs / --no-logs - Include logs in returned events [default: True] [manager only]
• --blueprint-labels TEXT - A labels list of the form :,:
• --deployment-labels TEXT - A labels list of the form :,:

Example

$ vnfm install -p vnfm-hello-world-example-master/ec2-blueprint.yaml

...

Uploading blueprint vnfm-hello-world-example-master/ec2-blueprint.yaml...
Blueprint uploaded. The blueprint's id is vnfm-hello-world-example-master
Creating new deployment from blueprint vnfm-hello-world-example-master...
Deployment created. The deployment's id is vnfm-hello-world-example-master
Executing workflow install on deployment vnfm-hello-world-example-master [timeout=900 seconds]
Deployment environment creation is in progress...
2016-06-28T12:19:35 VNF <vnfm-hello-world-example-master> Starting 'create_deployment_environment' workflow execution
.
.
.
2016-06-28T12:21:18 VNF <vnfm-hello-world-example-master> [vm_8573e] Configuring Agent
2016-06-28T12:21:18 VNF <vnfm-hello-world-example-master> [vm_8573e.configure] Sending task 'vnfm_agent.installer.operations.configure'
2016-06-28T12:21:18 VNF <vnfm-hello-world-example-master> [vm_8573e.configure] Task started 'vnfm_agent.installer.operations.configure'
2016-06-28T12:21:18 VNF <vnfm-hello-world-example-master> [vm_8573e.configure] Task started 'vnfm_agent.installer.operations.configure'
2016-06-28T12:21:24 VNF <vnfm-hello-world-example-master> [vm_8573e.configure] Task succeeded 'vnfm_agent.installer.operations.configure
.
.
.
2016-06-28T12:21:49 VNF <vnfm-hello-world-example-master> [http_web_server_d776e.start] Task succeeded 'script_runner.tasks.run'
2016-06-28T12:21:49 VNF <vnfm-hello-world-example-master> 'install' workflow execution succeeded
Finished executing workflow install on deployment vnfm-hello-world-example-master
* Run 'vnfm events list --include-logs --execution-id acc1a58d-108b-4a10-84c5-abbabfa5cd2f' to retrieve the execution's events/logs

...

LOGS

The vnfm logs command is used to manage log files on VNF Manager.

You can use the command to download, backup and purge VNF Manager service logs.

To use the command you must have the credentials (user and key) set in the local context and must run vnfm use -t MANAGEMENT_IP prior to running the command.

Optional Flags

These commands support the common CLI flags.

Commands

backup

Usage

vnfm logs backup [OPTIONS]

Create a backup of all logs under a single archive and save it on VNF Manager under /var/log.

Example

$ vnfm logs backup

...

Creating logs archive in manager: /tmp/vnfm-manager-logs_20170330T122201_10.239.0.208.tar.gz
Backing up manager logs to /var/log/vnfm-manager-logs_20170330T122201_10.239.0.208.tar.gz

...

download

Usage

vnfm logs download [OPTIONS]

Download an archive containing all of the VNF Manager service logs.

Optional Flags

• -o, --output-path TEXT - The local path to which to save the download.
• --all-nodes - Download logs from all nodes in a cluster. CLI cluster profile must be updated with SSH users and keys. Use Cluster Update Profile and Profile Set Cluster to update the profile.

Example

$ vnfm logs download

...

Creating logs archive in manager: /tmp/vnfm-manager-logs_20160623T070559_10.10.1.10.tar.gz
Downloading archive to: /home/nir0s/work/local-bootstrap-env
Removing archive from manager...

...

purge

Usage

vnfm logs purge [OPTIONS]

Purge all log files on VNF Manager.

Truncate all logs files under /var/log/vnfm.

This enables you to take extreme measures to clean up data from VNF Manager. For example, you can choose to run this command when the disk is full due to a bug that has caused the logs to bloat.

The -f, --force flag is mandatory as a safety measure.

Optional Flags

--backup-first - Creates a backup before purging.

Caution

Forced Prerequisites Installation

USE WITH CARE!

Log files in VNF Manager are rotated. vnfm purge is a safety measure in case disk space on VNF Manager runs out, and should only be used in extreme situations.

Example

$ vnfm logs purge -f

...

Purging manager logs...

...

MAINTENANCE-MODE

The vnfm maintenance-mode command is used to restrict REST access to the manager.

This is required, for instance, when you upgrade a manager.

Putting the manager in maintenance-mode prevents it from running any executions.

Optional Flags

These commands support the common CLI flags.

Commands

activate

Usage

vnfm maintenance-mode activate [OPTIONS]

Enter maintenance-mode on VNF Manager, rejecting further REST requests.

Optional Flags

• --wait - Wait until there are no running executions and automatically activate maintenance-mode.
• --timeout INTEGER - Operation timeout in seconds. (The execution will keep going, but the CLI will stop waiting for it to terminate.) [default: {0}]

Example

$ vnfm maintenance-mode activate

...

Entering maintenance mode...
Run 'vnfm maintenance-mode status' to check the maintenance mode's status.

...

deactivate

Usage

vnfm maintenance-mode deactivate

Deactivate maintenance-mode on the VNF Manager, to accept REST requests.

Example

$ vnfm maintenance-mode deactivate

...

Turning off maintenance mode...
Maintenance mode is off.

...

status

Usage

vnfm maintenance-mode status

Retrieve the current maintenance-mode status.

Example

$ vnfm maintenance-mode status

...

Maintenance Mode Status:
        Status:      activated
        Requested By:        admin
        Activated At:        2017-04-04T05:16:21.407Z
        Activation Requested At:     2017-04-04T05:16:21.407Z

INFO - VNF Manager is currently in maintenance mode. Most requests will be blocked.

...

NODE-INSTANCES

The vnfm node-instances command is used to view information about the different node-instances of a deployment.

You can use the command to list the node-instances of a specific deployment or of all deployments, and to retrieve information about a single node-instance.

Optional Flags

These commands support the common CLI flags.

Commands

list

Usage

vnfm node-instances list [OPTIONS]

List node-instances.

If DEPLOYMENT_ID is provided, lists node-instances for that deployment. Otherwise, lists node-instances for all deployments.

Optional Flags

• -d, --deployment-id TEXT - The unique identifier for the deployment
• -n, --node-name TEXT - The node’s name
• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t, --tenant-name TEXT - The name of the tenant from which to list node-instance. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This argument cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search node-instances by id. The returned list will include only node-instances that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm node-instances list

...

Listing all instances...

Node-instances:
+------------------------+------------------------------+-------------+-----------------+---------+------------+----------------+------------+
|           id           |        deployment_id         |   host_id   |     node_id     |  state  | visibility |  tenant_name   | created_by |
+------------------------+------------------------------+-------------+-----------------+---------+------------+----------------+------------+
|      host_gkxr6j       | vnfm-nodecellar-example      | host_gkxr6j |       host      | started |  creator   | default_tenant |   admin    |
| http_web_server_mwtpct | vnfm-hello-world-example     |  vm_qu2t7i  | http_web_server | started |  creator   | default_tenant |   admin    |
|     mongod_nps479      | vnfm-nodecellar-example      | host_gkxr6j |      mongod     | started |  creator   | default_tenant |   admin    |
|   nodecellar_gj0mj2    | vnfm-nodecellar-example      | host_gkxr6j |    nodecellar   | started |  creator   | default_tenant |   admin    |
|     nodejs_gsy2zz      | vnfm-nodecellar-example      | host_gkxr6j |      nodejs     | started |  creator   | default_tenant |   admin    |
|       vm_qu2t7i        | vnfm-hello-world-example     |  vm_qu2t7i  |        vm       | started |  creator   | default_tenant |   admin    |
+------------------------+------------------------------+-------------+-----------------+---------+------------+----------------+------------+

...

summary

Usage

vnfm node-instances summary <field> [optional sub-field] [OPTIONS]

Summarizes node-instances, giving a count of elements with each distinct value for the selected field. If a sub-field is selected then a count will be given for each distinct field and sub-field combination, as well as totals for each field.

For valid field/sub-field names, invoke vnfm node-instances summary

Example

$ vnfm node-instances summary deployment_id
Retrieving summary of node instances on field deployment_id

Node instance summary by deployment_id
+---------------+----------------+
| deployment_id | node_instances |
+---------------+----------------+
|      sga1     |       51       |
|      sga3     |       51       |
|      sga2     |       51       |
|       s3      |       2        |
|       s2      |       2        |
|       s1      |       2        |
|       s5      |       2        |
|       s4      |       2        |
|      sg1      |       35       |
+---------------+----------------+

...


$ vnfm node-instances summary deployment_id state
Retrieving summary of node instances on field deployment_id

Node instance summary by deployment_id
+---------------+---------+----------------+
| deployment_id |  state  | node_instances |
+---------------+---------+----------------+
|      sga1     | started |       51       |
|      sga1     |  TOTAL  |       51       |
|      sga3     | started |       51       |
|      sga3     |  TOTAL  |       51       |
|      sga2     | started |       51       |
|      sga2     |  TOTAL  |       51       |
|       s3      | started |       2        |
|       s3      |  TOTAL  |       2        |
|       s2      | started |       2        |
|       s2      |  TOTAL  |       2        |
|       s1      | started |       2        |
|       s1      |  TOTAL  |       2        |
|       s5      | started |       2        |
|       s5      |  TOTAL  |       2        |
|       s4      | started |       2        |
|       s4      |  TOTAL  |       2        |
|      sg1      | started |       35       |
|      sg1      |  TOTAL  |       35       |
+---------------+---------+----------------+

...

get

Usage

vnfm node-instances get [OPTIONS] NODE_INSTANCE_ID

Retrieve information for a specific node-instance.

NODE_INSTANCE_ID is the ID of the node-instance for which to retrieve information.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the node-instance. If unspecified, the current tenant is used.

Example

$ vnfm node-instances get nodecellar_gj0mj2

...

Retrieving node instance nodecellar_gj0mj2

Node-instance:
+-------------------+-----------------------------+-------------+------------+---------+------------+----------------+------------+
|         id        |        deployment_id        |   host_id   |  node_id   |  state  | visibility |  tenant_name   | created_by |
+-------------------+-----------------------------+-------------+------------+---------+------------+----------------+------------+
| nodecellar_gj0mj2 | vnfm-nodecellar-example     | host_gkxr6j | nodecellar | started |  creator   | default_tenant |   admin    |
+-------------------+-----------------------------+-------------+------------+---------+------------+----------------+------------+

Instance runtime properties:
        mongo_port: 27017
        nodejs_binaries_path: /tmp/68672f1b-b49a-4e58-ae6f-b2de63676e4f/nodejs/nodejs-binaries
        pid: 27816
        nodecellar_source_path: /tmp/68672f1b-b49a-4e58-ae6f-b2de63676e4f/nodecellar/nodecellar-source
        mongo_ip_address: localhost

...

update-runtime

Usage

vnfm node-instances update-runtime [OPTIONS] NODE_INSTANCE_ID

Update the runtime properties of a specific node-instance.

NODE_INSTANCE_ID is the id of the node-instance to update.

Mandatory flags

-p, --properties TEXT - Runtime properties for the node instance (Can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as ‘key1=value1;key2=value2’).

This argument can be used multiple times.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the node-instance. If unspecified, the current tenant is used.

Example

$ vnfm node-instances update-runtime vm_d720jr -p new_property=value -p dict_property.key=value

Successfully updated the runtime properties of "vm_d720jr"

Node-instance:
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+
|     id    | deployment_id |  host_id  | node_id |  state  | visibility |  tenant_name   | created_by |
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+
| vm_d720jr | hello_world   | vm_d720jr |    vm   | started |   tenant   | default_tenant |   admin    |
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+

Instance runtime properties:
    dict_property:   {'key': 'value'}
    new_property:    value
        ipv6_address:    None
        vnfm_agent:  {'broker_ip': ['172.16.3.112'], 'file_server_url': 'https://172.16.3.112:53333/resources', ... }
        external_name:   server_hello_world_2_vm_d720jr
        ip:              172.16.3.114
        ipv6_addresses:  []
        networks:        {'vnfm-management-network': ['172.16.3.114']}
    ...

Notice how using the dot notation dict_property.key has created a property dict_property and within it a sub-property key.

In the same way, we can access sub-properties to update them, e.g. dict_property.key = [value1, value2].

Options for providing the runtime properties

• Providing the properties to be updated directly:

  vnfm node-instances update-runtime vm_d720jr -p 'a=b; c.d.e=f'

• Through repeated usage of the –properties flag:

  vnfm node-instances update-runtime vm_d720jr -p a=b -p c.d.e=f

• In dictionary format:

  vnfm node-instances update-runtime vm_d720jr -p '{a: b, c: {d: {e: f}}}'

• Providing a path to a YAML file containing the runtime properties to be updated (must end with .yaml):

  vnfm node-instances update-runtime vm_d720jr -p my_yamls/update_runtime_props.yaml

• Where a YAML file may be formatted as follows:

a: b

c:

   d:

      e: f

• Providing a path to a directory of YAML files containing the runtime properties to be updated (must end with /):

  vnfm node-instances update-runtime vm_d720jr -p my_yamls/

Usage note:

Updating a sub-property within a runtime property does not affect other sub-properties. For example, running vnfm node-instances update-runtime vm_d720jr -p ‘{a: {b: 5}}’ on a node-instance where:

Instance runtime properties:

   a:  {b: 4, c: 3}

   ...

Will result in:

Instance runtime properties:

   a:  {b: 5, c: 3}

   ...

delete-runtime

Usage

vnfm node-instances delete-runtime [OPTIONS] NODE_INSTANCE_ID

Delete specified runtime properties of a specific node-instance

NODE_INSTANCE_ID is the id of the node-instance to update.

Mandatory flags

-p, --properties TEXT - Runtime properties for the node instance (Can be provided as wildcard based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as ‘key1=value1;key2=value2’). This argument can be used multiple times.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the node-instance. If unspecified, the current tenant is used.

Example

$ vnfm node-instances delete-runtime vm_d720jr -p 'dict_property.key' -p 'new_property'

Successfully updated the runtime properties of "vm_d720jr"

Node-instance:
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+
|     id    | deployment_id |  host_id  | node_id |  state  | visibility |  tenant_name   | created_by |
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+
| vm_d720jr | hello_world   | vm_d720jr |    vm   | started |   tenant   | default_tenant |   admin    |
+-----------+---------------+-----------+---------+---------+------------+----------------+------------+

Instance runtime properties:
    dict_property:   {}
        ipv6_address:    None
        vnfm_agent:  {'broker_ip': ['172.16.3.112'], 'file_server_url': 'https://172.16.3.112:53333/resources', ... }
        external_name:   server_hello_world_2_vm_d720jr
        ip:              172.16.3.114
        ipv6_addresses:  []
        networks:        {'vnfm-management-network': ['172.16.3.114']}
    ...

Notice how using the dot notation dict_property.key enabled you to delete the sub-property key within the property dict_property.

Options for providing the runtime properties

• Providing the properties to be deleted directly:

  vnfm node-instances delete-runtime vm_d720jr -p 'a; c.d'

• Through repeated usage of the –properties flag:

  vnfm node-instances delete-runtime vm_d720jr -p 'a' -p 'c.d'

• In dictionary format:

  vnfm node-instances delete-runtime vm_d720jr -p '{a, c: {d}}'

• Providing a path to a YAML file containing the runtime properties to be deleted (must end with .yaml):

  vnfm node-instances delete-runtime vm_d720jr -p my_yamls/update_runtime_props.yaml

• Where a YAML file may be formatted as follows:

  a:
  
  c:
  
     d:
  

Which will also delete the property a and the property d (which is within another property c).

• Providing a path to a directory of YAML files containing the runtime properties to be deleted (must end with /):

  vnfm node-instances delete-runtime vm_d720jr -p my_yamls/

Usage note:

Deleting a sub-property within a runtime property does not affect other sub-properties. For example, running vnfm node-instances delete-runtime vm_d720jr -p ‘{a: {b}}’ on a node-instance where:

Instance runtime properties:

    a:  {b: 4, c: 3}

    ...

Will result in:

a:  {c: 3}

...

NODES

The vnfm nodes command is used to view information on the different nodes of a deployment.

You can use the command to list all nodes and get information on a single node.

Optional Flags

These commands support the common CLI flags.

Commands

list

Usage

vnfm nodes list [OPTIONS]

Lists all nodes for a deployment.

If DEPLOYMENT_ID is provided, lists nodes for that deployment. Otherwise, list nodes for all deployments.

Optional Flags

• -d, --deployment-id TEXT - The unique identifier for the deployment.
• --sort-by TEXT - Key for sorting the list.
• --descending - Sort list in descending order. [default: False]
• -t, --tenant-name TEXT - The name of the tenant from which to list the nodes. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This argument cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search nodes by id. The returned list will include only nodes that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm nodes list

...

Listing all nodes...

Nodes:
+-----------------+------------------------------+------------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+
|        id       |        deployment_id         |         blueprint_id         | host_id |                     type                     | number_of_instances | planned_number_of_instances | permission |  tenant_name   | created_by |
+-----------------+------------------------------+------------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+
| http_web_server | vnfm-hello-world-example     | vnfm-hello-world-example     |    vm   |           vnfm.nodes.WebServer               |          1          |              1              |  creator   | default_tenant |   admin    |
|        vm       | vnfm-hello-world-example     | vnfm-hello-world-example     |    vm   |            vnfm.nodes.Compute                |          1          |              1              |  creator   | default_tenant |   admin    |
|      mongod     | vnfm-nodecellar-example      | vnfm-nodecellar-example      |   host  |   nodecellar.nodes.MonitoredMongoDatabase    |          1          |              1              |  creator   | default_tenant |   admin    |
|    nodecellar   | vnfm-nodecellar-example      | vnfm-nodecellar-example      |   host  | nodecellar.nodes.NodecellarApplicationModule |          1          |              1              |  creator   | default_tenant |   admin    |
|       host      | vnfm-nodecellar-example      | vnfm-nodecellar-example      |   host  |       nodecellar.nodes.MonitoredServer       |          1          |              1              |  creator   | default_tenant |   admin    |
|      nodejs     | vnfm-nodecellar-example      | vnfm-nodecellar-example      |   host  |        nodecellar.nodes.NodeJSServer         |          1          |              1              |  creator   | default_tenant |   admin    |
+-----------------+------------------------------+------------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+

...

$ vnfm nodes list -d simple_website

...

Listing nodes for deployment vnfm-hello-world-example...

Nodes:
+-----------------+------------------------------+------------------------------+---------+--------------------------+---------------------+-----------------------------+------------+----------------+------------+
|        id       |        deployment_id         |         blueprint_id         | host_id |           type           | number_of_instances | planned_number_of_instances | permission |  tenant_name   | created_by |
+-----------------+------------------------------+------------------------------+---------+--------------------------+---------------------+-----------------------------+------------+----------------+------------+
| http_web_server | vnfm-hello-world-example     | vnfm-hello-world-example     |    vm   | vnfm.nodes.WebServer     |          1          |              1              |  creator   | default_tenant |   admin    |
|        vm       | vnfm-hello-world-example     | vnfm-hello-world-example     |    vm   |  vnfm.nodes.Compute      |          1          |              1              |  creator   | default_tenant |   admin    |
+-----------------+------------------------------+------------------------------+---------+--------------------------+---------------------+-----------------------------+------------+----------------+------------+

...

summary

Usage

vnfm nodes summary <field> [optional sub-field] [OPTIONS]

Summarizes nodes, giving a count of elements with each distinct value for the selected field. If a sub-field is selected then a count will be given for each distinct field and sub-field combination, as well as totals for each field.

For valid field/sub-field names, invoke vnfm nodes summary

Example

$ vnfm nodes summary deployment_id

Retrieving summary of nodes on field deployment_id

Node summary by deployment_id
+---------------+-------+
| deployment_id | nodes |
+---------------+-------+
|      sga1     |   5   |
|      sga3     |   5   |
|      sga2     |   5   |
|       s3      |   1   |
|       s2      |   1   |
|       s1      |   1   |
|       s5      |   1   |
|       s4      |   1   |
|      sg1      |   2   |
+---------------+-------+

...

$ vnfm nodes summary --all-tenants tenant_name deployment_id
Retrieving summary of nodes on field tenant_name

Node summary by tenant_name
+----------------+---------------+-------+
|  tenant_name   | deployment_id | nodes |
+----------------+---------------+-------+
|     test1      |       s1      |   1   |
|     test1      |      sg1      |   2   |
|     test1      |      sg2      |   2   |
|     test1      |      sg3      |   2   |
|     test1      |      sga1     |   5   |
|     test1      |      sga2     |   5   |
|     test1      |      sga3     |   5   |
|     test1      |      sga4     |   5   |
|     test1      |      sga5     |   5   |
|     test1      |     TOTAL     |   32  |
|     test2      |       s1      |   1   |
|     test2      |       s2      |   1   |
|     test2      |       s3      |   1   |
|     test2      |      sg1      |   2   |
|     test2      |      sg2      |   2   |
|     test2      |      sg3      |   2   |
|     test2      |      sg4      |   2   |
|     test2      |      sg5      |   2   |
|     test2      |      sga1     |   5   |
|     test2      |     TOTAL     |   18  |
| default_tenant |       s1      |   1   |
| default_tenant |       s2      |   1   |
| default_tenant |       s3      |   1   |
| default_tenant |       s4      |   1   |
| default_tenant |       s5      |   1   |
| default_tenant |      sg1      |   2   |
| default_tenant |      sga1     |   5   |
| default_tenant |      sga2     |   5   |
| default_tenant |      sga3     |   5   |
| default_tenant |     TOTAL     |   22  |
+----------------+---------------+-------+

...

get

Usage

vnfm nodes get [OPTIONS] NODE_ID

Retrieve information for a specific node of a specific deployment.

NODE_ID is the ID of the node for which to retrieve information.

Required Flags

-d, --deployment-id TEXT - The unique identifier for the deployment. [required]

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the node. If unspecified, the current tenant is used

Example

$ vnfm nodes get -d vnfm-nodecellar-example nodecellar

...

Retrieving node nodecellar for deployment vnfm-nodecellar-example

Node:
+------------+-----------------------------+-----------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+
|     id     |        deployment_id        |         blueprint_id        | host_id |                     type                     | number_of_instances | planned_number_of_instances | permission |  tenant_name   | created_by |
+------------+-----------------------------+-----------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+
| nodecellar | vnfm-nodecellar-example     | vnfm-nodecellar-example     |   host  | nodecellar.nodes.NodecellarApplicationModule |          1          |              1              |  creator   | default_tenant |   admin    |
+------------+-----------------------------+-----------------------------+---------+----------------------------------------------+---------------------+-----------------------------+------------+----------------+------------+

Node properties:
        application_url: _https://github.com/vnfm-cosmo/nodecellar/archive/master.tar.gz
        port: 8080
        startup_script: server.js

Node instance IDs:
        nodecellar_gj0mj2


   ...

PLUGINS

The vnfm plugins command is used to manage plugins stored on a VNF manager.

You can use the command to upload, download, delete and list plugins and also to get information on a specific plugin.

A VNFM plugin is an archive created by wagon.

Each plugin has a plugin.yaml file that map node lifecycle operations to appropriate plugin functions.

Consult plugins for more information.

Optional Flags

These commands support the common CLI flags.

Commands

upload

Usage

vnfm plugins upload [OPTIONS] PLUGIN_PATH

Upload a plugin to VNF Manager.

PLUGIN_PATH is the path to the wagon archive to upload.

Wagon (using the --format flag) enables you to create archives in both tar.gz and zip formats. VNFM only supports wagon in the tar.gz format.

Required Flags

-y, --yaml-path TEXT - The path to the yaml file for the plugin

Optional Flags

• -t, --tenant-name TEXT - The name of the tenant of the plugin. If unspecified, the current tenant is used.
• -l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].
• -i, --icon-path TEXT - The path to the plugin’s icon file (must be a valid PNG image).
• --title TEXT - The plugin’s title, used e.g. in UI topology view.

Caution

All the mentioned paths (PLUGIN_PATH, --yaml-path, and --icon-path values) may be not only local filesystem paths, but also valid URLs (either http:// or https://).

Example

$ vnfm plugins upload -y plugin.yaml vnfm_aws_plugin-1.4.4-py27-none-linux_x86_64-centos-Core.wgn

...

Validating plugin vnfm_aws_plugin-1.4.4-py27-none-linux_x86_64-centos-Core.wgn...
Plugin validated successfully
Uploading plugin vnfm_aws_plugin-1.4.4-py27-none-linux_x86_64-centos-Core.wgn...
 vnfm_aws_plug... |################################################| 100.0%
Plugin uploaded. The plugin's id is e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74

...

download

Usage

vnfm plugins download [OPTIONS] PLUGIN_ID

Download a plugin from VNF Manager.

PLUGIN_ID is the ID of the plugin to download.

Optional Flags

-o, --output-path TEXT - The local path for the download. -t, --tenant-name TEXT - The name of the tenant of the plugin. If unspecified, the current tenant is used.

Example

$ vnfm plugins download e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74

...

Downloading plugin e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74...
 e90b1a09-6b56-4a9... |################################################| 100.0%
Plugin downloaded as e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74.tar.gz

...

delete

Usage

vnfm plugins delete [OPTIONS] PLUGIN_ID

Delete a plugin from VNF Manager.

PLUGIN_ID is the ID of the plugin to be deleted.

Optional Flags

• -f, --force - Delete the plugin, even if there are deployments that are currently using it.
• -t, --tenant-name TEXT - The name of the tenant of the plugin. If unspecified, the current tenant is used.

Example

$ vnfm plugins delete e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74

...

Deleting plugin e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74...
Plugin deleted

...

list

Usage

vnfm plugins list [OPTIONS]

List all available plugins on VNF Manager. You can use this command to retrieve the IDs of the plugins you want to download or delete.

Optional Flags

• --sort-by TEXT - Key for sorting the list.
• --descending - Sort list in descending order. [default: False]
• -t, --tenant-name TEXT - The name of the tenant from which to list the plugins. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This argument cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search plugins by package-name. The returned list will include only plugins that contain the given search pattern.
• --get-data - When set to True, displays the full list of connected resources (users/tenants/user-groups), for each listed resource. When set to False displays the total number of connected resources. (default:False)
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm plugins list

...

Listing all plugins...

Plugins:
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+
|                  id                  |     package_name    | package_version | distribution | supported_platform | distribution_release |       uploaded_at        | visibility |  tenant_name   | created_by |
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+
| e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74 | vnfm-aws-plugin     |      1.4.4      |    centos    |    linux_x86_64    |         core         | 2017-04-04 07:02:54.526  |   tenant   | default_tenant |   admin    |
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+

...

get

Usage

vnfm plugins get [OPTIONS] PLUGIN_ID

Retrieve information for a specific plugin.

PLUGIN_ID is the ID of the plugin for which to retrieve information.

Optional Flags

• -t, --tenant-name TEXT - The name of the tenant of the plugin. If unspecified, the current tenant is used.
• --get-data - When set to True, displays the full list of connected resources (users/tenants/user-groups), for each listed resource. When set to False displays the total number of connected resources. (default:False)

Example

$ vnfm plugins get e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74

...

Retrieving plugin e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74...

Plugin:
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+
|                  id                  |     package_name    | package_version | distribution | supported_platform | distribution_release |       uploaded_at        | visibility |  tenant_name   | created_by |
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+
| e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74 | vnfm-aws-plugin     |      1.4.4      |    centos    |    linux_x86_64    |         core         | 2017-04-04 07:02:54.526  |   tenant   | default_tenant |   admin    |
+--------------------------------------+---------------------+-----------------+--------------+--------------------+----------------------+--------------------------+------------+----------------+------------+

...

validate

Usage

vnfm plugins validate [OPTIONS] PLUGIN_PATH

Validate a plugin.

This validates that the plugin’s archive is not corrupted. A valid plugin is a wagon (_http://github.com/vnfm-cosomo/wagon) in the tar.gz format.

PLUGIN_PATH is the path to wagon archive to validate.

Example

$ vnfm plugins validate vnfm_aws_plugin-1.4.4-py27-none-linux_x86_64-centos-Core.wgn

...

Validating plugin vnfm_aws_plugin-1.4.4-py27-none-linux_x86_64-centos-Core.wgn...
Plugin validated successfully

...

set-visibility

Usage

vnfm plugins set-visibility [OPTIONS] PLUGIN_ID

Set the plugin’s visibility

PLUGIN_ID - The id of the plugin to update.

Required Flags

-l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘tenant’, ‘global’].

Example

$ vnfm plugins set-visibility e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74 -l global

...

Plugin `e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74` was set to global

...

set-owner

Usage

cfy plugins set-owner [OPTIONS] PLUGIN_ID

Change ownership of a plugin.

PLUGIN_ID - The id of the plugin to update.

Optional flags

-s, --username USERNAME - The name of the user who will be the new owner of the resource. [required]

Example

$ cfy plugins set-owner e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74 -s admin
...

Plugin `e90b1a09-6b56-4a92-b9cd-5fc4ef32ab74` is now owned by user `admin`.

...

blueprint-labels

• blueprint-labels list - cfy plugins blueprint-labels list [OPTIONS] PLUGIN_ID List blueprint labels for specific plugin.
  • PLUGIN_ID is the id of the plugin.
• blueprint-labels add - cfy plugins blueprint-labels add [OPTIONS] LABELS_LIST PLUGIN_ID Add blueprint labels for specific plugin.
  • PLUGIN_ID is the id of the plugin.
  • LABELS_LIST is a list in <label1>:<value1>,<label2>:<value2> format of labels. Any backslash, comma and colon in <value> must be escaped with .
• blueprint-labels delete - cfy plugins blueprint-labels delete [OPTIONS] LABEL PLUGIN_ID Delete blueprint labels from specific plugin.
  • PLUGIN_ID is the id of the plugin.
  • LABEL can either be a list of labels in <label1>:<value1>,<label2>:<value2> format, or just a <label1> string. In case the former is used, only specified values are going to be removed from list of plugin’s labels. If <value> is not specified, then whole <label> is deleted. Any backslash, comma and colon in <value> must be escaped with .

deployment-labels

• deployment-labels list - cfy plugins deployment-labels list [OPTIONS] PLUGIN_ID List deployment labels for specific plugin.
  • PLUGIN_ID is the id of the plugin.
• deployment-labels add - cfy plugins deployment-labels add [OPTIONS] LABELS_LIST PLUGIN_ID Add deployment labels for specific plugin.
  • PLUGIN_ID is the id of the plugin.
  • LABELS_LIST is a list in <label1>:<value1>,<label2>:<value2> format of labels. Any backslash, comma and colon in <value> must be escaped with .
• deployment-labels delete - cfy plugins deployment-labels delete [OPTIONS] LABEL PLUGIN_ID Delete deployment labels from specific plugin.
  • PLUGIN_ID is the id of the plugin.
  • LABEL can either be a list of labels in <label1>:<value1>,<label2>:<value2> format, or just a <label1> string. In case the former is used, only specified values are going to be removed from list of plugin’s labels. If <value> is not specified, then whole <label> is deleted. Any backslash, comma and colon in <value> must be escaped with .

bundle-upload

Usage

vnfm plugins bundle-upload [OPTIONS]

Upload a bundle of plugins to VNF Manager.

Optional Flags

-p, --path TEXT - Path to a plugins bundle file or URL. If unspecified, a default URL is used.

Example

$ vnfm plugins bundle-upload -p /dir/vnfm-plugins-bundle.tgz

...

update

Usage

vnfm plugins update [OPTIONS] BLUEPRINT_ID

Update the plugins of all the deployments of the blueprint.

BLUEPRINT_ID the blueprint’s ID to perform the plugins update with, mutually exclusive with --all flag.

Optional Flags

• --all-blueprints - Update the plugins used in all blueprints accessible to the current tenant or tenant selected by –tenant-name, or all tenants in case the –all-tenants flag was used.
• a, --all-tenants - Include blueprints from all tenants associated with the user. You cannot use this argument with --tenant-name.
• --except-blueprint TEXT - List of blueprint IDs to be excluded from all blueprints update (can be passed multiple times or take comma separated values).
• --plugin-name TEXT - Update only the specific plugin in all selected deployments (can be passed multiple times or take comma separated values).
• --to-latest TEXT - List of plugin names to be upgraded to the latest version (can be passed multiple times or take comma separated values).
• --all-to-latest - Update all (selected) plugins to the latest version of a plugin.
• --to-minor TEXT - List of plugin names to be upgraded to the latest minor version (can be passed multiple times or take comma separated values).
• --all-to-minor - Update all (selected) plugins to the latest minor version.
• --auto-correct-types - If set, before creating a plan for a new deployment, an attempt will be made to cast old inputs’ values to the valid types declared in blueprint.
• --reevaluate-active-statuses - After a failed plugins update the update metadata may get invalid. Reevaluate will correct the metadata based on the last known execution. The statuses of previous active update operations will be reevaluated based on relevant executions’ statuses. terminated executions will be mapped to successful updates, while failed and any cancel statuses will be mapped to failed. This flag is also passed down to the deployment update flows and has a similar effect on those.
• --manager TEXT - Connect to a specific manager by IP or host
• -q, --quiet - Show only critical logs
• --format [plain|json]
• -v, --verbose - Show verbose output. You can supply this up to three times (for example, -vvv).
• --json
• -t, --tenant-name TEXT - The name of the tenant of the plugin. If not specified, the current tenant will be used
• --include-logs / --no-logs - Include logs in returned events [default: True]
• --json-output - Output events in a consumable JSON format
• -f, --force - Use the Force option to allow an update to a deployment used as a component in another deployment. This flag applies to both direct deployment update and cascading update to components.

Example

$ vnfm plugin update openstack_blueprint

...

Updating the plugins of the deployments of the blueprint openstack_blueprint
2019-06-16 15:59:50.843  VNF <None> Starting 'update_plugin' workflow execution
2019-06-16 15:59:50.845  VNF <None> Executing deployment update for deployment openstack_blueprint_deployment...
2019-06-16 15:59:55.880  VNF <None> update_plugin workflow execution succeeded

...

get-update

Usage

vnfm plugins get-update [OPTIONS] PLUGINS_UPDATE_ID

Retrieve information for a specific plugins update.

PLUGINS_UPDATE_ID is the id of the plugins update to get information on.

Optional Flags

• -q, --quiet - Show only critical logs
• --format [plain|json]
• -v, --verbose - Show verbose output. You can supply this up to three times (i.e. -vvv)
• --json
• -t, --tenant-name TEXT - The name of the tenant of the plugins update. If not specified, the current tenant will be used

Example

$ vnfm plugin get-update 'bffee604-7133-43b0-9f5f-7a893bffd238'

...

history

Usage

vnfm plugins history [OPTIONS]

Show blueprint history by listing plugins updates.

If --blueprint-id is provided, list plugins updates for that blueprint. Otherwise, list plugins updates for all blueprints.

Optional Flags

• -b, --blueprint-id TEXT - The unique identifier for the blueprint
• --sort-by TEXT - Key for sorting the list
• --descending - Sort list in descending order [default: False]
• -t, --tenant-name TEXT - The name of the tenant to list plugins updates from. If not specified, the current tenant will be used. You cannot use this argument with arguments: [all_tenants]
• -a, --all-tenants - Include resources from all tenants associated with the user. You cannot use this argument with arguments: [tenant_name]
• --search TEXT - Search resources by name/id. The returned list will include only resources that contain the given search pattern
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]
• -q, --quiet - Show only critical logs
• --format [plain|json]
• -v, --verbose - Show verbose output. You can supply this up to three times (i.e. -vvv)
• --json

Example

$ vnfm plugins history --blueprint-id 'fdse5u0d-6281-43h0-924f-7z693bflw945'

...

SECRETS

The vnfm secrets command is used to manage VNF secrets (key-value pairs).

Optional Flags

These commands support the common CLI flags.

Commands

create

Usage

vnfm secrets create [OPTIONS] KEY

Create a new secret (key-value pair)

KEY is the new secret’s key.

Required Flags

One of these flags:

• -s, --secret-string TEXT - The string to use as the secret’s value.
• -f, --secret-file TEXT - The file with the contents of the secret.

Optional Flags

• -u, --update-if-exists - Update secret value if secret key already exists. [This option is deprecated; use vnfm secrets update command instead]. You cannot use this argument with arguments: [visibility, hidden_value]
• -l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘private’, ‘tenant’, ‘global’] [default: tenant].
• --hidden-value - The secret value is only shown to the user that created the secret, to the tenant managers, and to sys-admins. Use of the secret is allowed according to user roles and the visibility of the secret.
• -t, --tenant-name - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm secrets create test-secret -s test-value

...

Secret `test-secret` created

...

delete

Usage

vnfm secrets delete [OPTIONS] KEY

Delete a secret.

KEY is the secret’s key.

Optional Flags

-t, --tenant-name - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm secrets delete test-secret

...

Deleting secret `test-secret`...

Secret removed

...

get

Usage

vnfm secrets get [OPTIONS] KEY

Get details for a single secret.

KEY is the secret’s key.

Optional Flags

-t, --tenant-name - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm secrets get test-secret

...

Getting info for secret `test-secret`...
Requested secret info:
key:             test-secret
tenant_name:     default_tenant
created_at:      2018-05-13 16:01:37.420
updated_at:      2018-05-13 16:01:37.420
created_by:      admin
visibility:      tenant
value:           test-value
is_hidden_value: False

...

list

Usage

vnfm secrets list [OPTIONS]

List all secrets.

Optional Flags

• --sort-by TEXT - Key for sorting the list.
• --descending - Sort list in descending order. [default: False]
• -t, --tenant-name TEXT - The name of the tenant from which to list secrets. If unspecified, the current tenant is used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This argument cannot be used simultaneously with the tenant-name argument.
• --search TEXT - Search secrets by key. The returned list will include only secrets that contain the given search pattern.
• -o, --pagination-offset INTEGER - The number of resources to skip; –pagination-offset=1 skips the first resource [default: 0]
• -s, --pagination-size INTEGER - The max number of results to retrieve per page [default: 1000]

Example

$ vnfm secrets list

...

Listing all secrets...

Secrets:
+-------------+--------------------------+--------------------------+------------+----------------+------------+-----------------+
|     key     |        created_at        |        updated_at        | visibility |  tenant_name   | created_by | is_hidden_value |
+-------------+--------------------------+--------------------------+------------+----------------+------------+-----------------+
| test-secret | 2018-05-13 16:01:37.420  | 2018-05-13 16:01:37.420  |   tenant   | default_tenant |   admin    |      False      |
+-------------+--------------------------+--------------------------+------------+----------------+------------+-----------------+

Showing 1 of 1 secrets

...

export

Usage

vnfm secrets export [OPTIONS]

Export secrets from the manager to a file.

Optional Flags

• -p, --passphrase TEXT - The passphrase used to encrypt the secrets’ values, must be 8 characters long.
• --non-encrypted - Use this flag for none encrypted scerets’ values. You cannot use this argument with arguments: [passphrase]
• -l, --visibility TEXT - Filters the secrets exported according to their visibility, can be set to one of the following [‘private’, ‘tenant’, ‘global’].
• -t, --tenant-name TEXT - The name of the tenant from which to export secrets. If unspecified, the current tenant will be used. This argument cannot be used simultaneously with the all-tenants argument.
• -a, --all-tenants - Include resources from all tenants associated with the user. This argument cannot be used simultaneously with the tenant-name argument.
• --filter-by TEXT - Filters the secrets exported according to a keyword.
• -o, --output-path TEXT - The local path to download the exported secrets to. If not specified, the secrets’ file will be downloaded to <current directory>/secrets.json

import

Usage

vnfm secrets import [OPTIONS]

Import secrets from a file to the manager.

Optional Flags

• -p, --passphrase TEXT - The passphrase used to encrypt or decrypt the secrets’ values, must be 8 characters long.
• -i, --input-path TEXT - Path to secrets file to import.
• --non-encrypted - Use this flag for none encrypted secrets’ values. You cannot use this argument with arguments: passphrase
• --override-collisions - If a certain key already exists in the destination manager, its value will be updated with the new imported value.
• -m, --tenant-map TEXT - Path to a json file containing a from-to tenant names mapping.

Inputs examples

secrets input file:

[
        {
                "key": "key",
                "value": "value",
                "tenant_name": "tenant_name",
                "visibility": "tenant",
                "is_hidden_value": "False",
                "encrypted": false
        }
]
tenant mapping input file:

{
        "source_tenant1": "destination_tenant1",
        "source_tenant2": "destination_tenant2"
}

update

Usage

vnfm secrets update [OPTIONS] KEY

Update an existing secret.

KEY is the secret’s key.

Required Flags

One of these flags:

• -s, --secret-string TEXT - The string to use as the secret’s value.
• -f, --secret-file TEXT - The file with the contents of the secret.

Optional Flags

• --hidden-value / --not-hidden-value - The secret value is only shown to the user that created the secret, to the tenant managers, and to sys-admins. Use of the secret is allowed according to user roles and the visibility of the secret.
• -l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘private’, ‘tenant’, ‘global’].
• -t, --tenant-name TEXT - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ vnfm secrets update test-secret -s test-value2

...

Secret `test-secret` updated.

...

set-visibility

Usage

vnfm secrets set-visibility [OPTIONS] KEY

Set the secret’s visibility.

KEY - The secret’s key.

Required Flags

-l, --visibility TEXT - Defines who can access the resource, can be set to one of [‘tenant’, ‘global’] [required].

Example

$ vnfm secrets set-visibility test-secret -l global

...

Secret `test-secret` was set to global

...

set-owner

Usage

cfy secrets set-owner [OPTIONS] KEY

Change ownership of a secret.

KEY - The key of the secret to update.

Optional flags-

• -s, --username USERNAME - The name of the user who will be the new owner of the resource. [required]
• -t, --tenant-name TEXT - The name of the tenant of the secret. If not specified, the current tenant will be used.

Example

$ cfy secrets set-owner test-secret -s admin
...

Secret `test-secret` is now owned by user `admin`.

...

STATUS

The vnfm status command is used to display the status of a running VNF Manager.

To use the command you must vnfm profiles use -t MANAGEMENT_IP first.

Usage

vnfm status

Show a list of the services running on the manager, whether it is in maintenance-mode, and its REST protocol. In cluster mode, PostgreSQL and RabbitMQ don’t run on the manager, so it verifies their connection.

Optional Flags

This command supports the common CLI flags.

Example

$ vnfm status

...

Retrieving manager services status... [ip=10.239.2.241]

Services:
+--------------------------------+--------+
|            service             | status |
+--------------------------------+--------+
| VNFM Console                   | Active |
| PostgreSQL                     | Active |
| AMQP-Postgres                  | Active |
| Manager Rest-Service           | Active |
| RabbitMQ                       | Active |
| Webserver                      | Active |
| VNFM Composer                  | Active |
| Management Worker              | Active |
+--------------------------------+--------+

...

In Cluster Mode

Retrieved manager services status... [ip=10.239.2.162]

Services:
+--------------------------------+--------+
|            service             | status |
+--------------------------------+--------+
| VNFM Console                   | Active |
| Manager Rest-Service           | Active |
| PostgreSQL                     | Active |
| AMQP-Postgres                  | Active |
| File Sync Service              | Active |
| RabbitMQ                       | Active |
| Webserver                      | Active |
| VNFM Composer                  | Active |
| Management Worker              | Active |
+--------------------------------+--------+

...

TOKENS

The vnfm tokens command is used to receive a REST token from the VNF Manager.

Commands

get

Usage

vnfm tokens get [OPTIONS]

Returns a valid REST token from the VNF Manager.

Optional Flags

This command supports the common CLI flags.

UNINSTALL

The vnfm uninstall command is used to uninstall an application using VNF Manager, without having to manually go through the process of executing a workflow, deleting a deployment and deleting a blueprint.

Usage

vnfm uninstall [OPTIONS] DEPLOYMENT_ID

Uninstall an application via VNF Manager.

This command executes the uninstall workflow, deletes the deployment and the blueprint (if there is only one deployment for that blueprint).

DEPLOYMENT_ID is the ID of the deployment to uninstall.

Optional Flags

This command supports the common CLI flags.

• -w, --workflow-id TEXT - The workflow to execute [default: uninstall]
• -p, --parameters TEXT - Parameters for the workflow (Can be provided as wildcard-based paths (*.yaml, /my_inputs/, etc.) to YAML files, a JSON string or as key1=value1;key2=value2). This argument can be used multiple times.
• --allow-custom-parameters - Allow passing custom parameters (that were not defined in the workflow’s schema in the blueprint) to the execution.
• --timeout INTEGER - Operation timeout in seconds. (The execution continues, but the CLI stops waiting for it to terminate) [default: {0}] [manager only]
• --include-logs / --no-logs - Include logs in returned events. [default: True]
• -t, --tenant-name TEXT - The name of the tenant of the deployment. If unspecified, the current tenant is used.

Example

$ vnfm uninstall vnfm-hello-world-example

...

Executing workflow uninstall on deployment vnfm-hello-world-example [timeout=900 seconds]
2017-04-04 09:55:44.071  VNF <vnfm-hello-world-example> Starting 'uninstall' workflow execution
2017-04-04 09:55:44.927  VNF <vnfm-he...
.
.
.
2017-04-04 09:56:01.680  VNF <vnfm-hello-world-example> 'uninstall' workflow execution succeeded
Finished executing workflow uninstall on deployment vnfm-hello-world-example
* Run 'vnfm events list -e 97a0c9af-9927-4189-8b36-5b3fba05347b' to retrieve the execution's events/logs
Deleting deployment vnfm-hello-world-example...
Deployment deleted
Deleting blueprint vnfm-hello-world-example...
Blueprint deleted

...

WORKFLOWS

The vnfm workflows command is used to view information about the different workflows of a deployment.

You can use the command to list the workflows of a specific deployment and to retrieve information about a single workflow.

Optional Flags

These commands support the common CLI flags.

Commands

list

Usage

vnfm workflows list [OPTIONS]

Lists all workflows on the VNF Manager for a specific deployment.

DEPLOYMENT_ID The ID of the deployment for which you want to list the workflows.

Required Flags

-d, --deployment-id TEXT - The unique identifier for the deployment.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the deployment. If unspecified, the current tenant is used.

Example

$ vnfm workflows list -d vnfm-nodecellar-example

...

Listing workflows for deployment vnfm-nodecellar-example...

Workflows:
+-----------------------------+-----------------------------+--------------------+------------+
|         blueprint_id        |        deployment_id        |        name        | created_at |
+-----------------------------+-----------------------------+--------------------+------------+
| vnfm-nodecellar-example     | vnfm-nodecellar-example     | execute_operation  |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     |        heal        |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     |      install       |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     | install_new_agents |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     |       scale        |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     |     uninstall      |            |
| vnfm-nodecellar-example     | vnfm-nodecellar-example     |       update       |            |
+-----------------------------+-----------------------------+--------------------+------------+

...

get

Usage

vnfm workflows get [OPTIONS] WORKFLOW_ID

Retrieves information for a specific workflow of a specific deployment.

WORKFLOW_ID The ID of the workflow for which you want to get information.

Required Flags

-d, --deployment-id TEXT - The ID of the deployment to which the workflow belongs.

Optional Flags

-t, --tenant-name TEXT - The name of the tenant of the deployment. If unspecified, the current tenant is used.

Example

$ vnfm workflows get execute_operation -d vnfm-nodecellar-example

...

Retrieving workflow execute_operation for deployment vnfm-nodecellar-example

Workflows:
+-----------------------------+-----------------------------+-------------------+------------+
|         blueprint_id        |        deployment_id        |        name       | created_at |
+-----------------------------+-----------------------------+-------------------+------------+
| vnfm-nodecellar-example     | vnfm-nodecellar-example     | execute_operation |            |
+-----------------------------+-----------------------------+-------------------+------------+

Workflow Parameters:
    Mandatory Parameters:
        operation
    Optional Parameters:
        operation_kwargs:    {}
        node_ids:    []
        node_instance_ids:   []
        run_by_dependency_order:     False
        allow_kwargs_override:       None
        type_names:  []

...

What’s Next?

• VNFM CLI Server
• REST API