Deployment maintenance guide

Consult the following topics, which provide further discussion and how-to information for performing the previous setup and deployment maintenance steps.

Update deployments

You can update/change blueprints, input values, and workflow actions for already deployed nodes.

1. Click the Deployments blade.

2. In the deployment node row for which you want to set a site, click , and then select the Update option from the list

   Or

   Click the deployment name to open the deployment page, and at the top of the window click Update deployment.

3. In the Update deployment popup window, do the following:

   

4. In that Update deployment window you can:

   • Define a new blueprint for the deployment

   • Change input values, or define new inputs for this deployment.

   • Set the following Actions to take upon this updated deployment like enabling/disabling Install/Uninstall workflows on specific node instances.

     

5. Do one of the following:

   • Click Update to commit all changes.

   • Click Preview to view all changed parameters before committing. In the Preview window slide to enable the Show only changed option, to see only changed parameters like:

     • Blueprint
     • Inputs
     • Node instance
     • Actions/Steps to be taken
     
     

6. To view this same information about past updates, do the following:

   1. Click the Deployments blade, and then click a deployment in the list to open the Deployment Details page.
   2. Scroll to or add the Deployment Executions widget on the specific deployment page.
   3. In an Execution row, click and select the Show Update Details option (this option is only available in executions associated with update workflows). The Deployment update details window appears:

   

Use the CLI to update deployments

Use the following commands to update existing deployments. For complete details, see the Orchestrator CLI.

Updating a deployment via the CLI is similar to creating a deployment, requiring that you supply an argument of the existing deployment’s ID. You must also supply either a blueprint ID or new inputs (or both) for the deployment update to use. The deployment’s blueprint and inputs will update in the data model.

1. Run the following command to update a deployment (must supply either blueprint id, or new inputs, or both):

   vnfm deployments update ID_OF_DEPLOYMENT_TO_UPDATE -b BLUEPRINT_ID -i UPDATED_INPUTS
   

2. Run the following command to get data about a deployment update:

   vnfm  deployments get-update DEPLOYMENT_UPDATE_ID
   

3. Run the following command to list deployment updates (if the deployment id parameter is supplied, then list updates for a specific deployment; otherwise, list updates for all deployments):

   vnfm  deployments history [-d DEPLOYMENT_ID]
   

Consult the Orchestrator CLI Deployments usage documentation.

User management

Displays the list of users and enables their management. This widget is only available to admin users.

The widget displays the following information regarding each of the user groups:

• Username
• Last login timestamp
• Admin - whether or not the user is sys admin on the VNF Manager (you can check and uncheck this filed to make changes)
• Active - whether or not the user is active (you can check and uncheck this field to make changes)
• # Groups - number of groups the user is a member of
• # Tenants - number of tenants the user is assigned with

The on the right of every tenant allows performing the following operations:

• Setting the user’s password
• Adding/removing the user to/from user groups
• Assigning/Unassigning the user with/from the tenant
• Deleting the user - possible only if the user does not belong to any groups, assigned to any tenants and is the creator of any resources on the manager.

Also, using Add on the top-right corner of the widget, you can create new users. Notice that if you choose to authenticate the users in front of an external user management system, you cannot create or delete the users in VNF Manager, nor can you assign them to VNF Manager user groups, in order to prevent conflicts between the two systems, which causes security problems.

Widget settings

• Refresh time interval - The time interval in which the widget’s data will be refreshed, in seconds. Default: 30 seconds.

Tenant management

Displays a list of tenants on the Manager and enables tenant management. This widget is only available to admin users. The widget displays the following information regarding each of the tenants:

• Name
• Number of user-groups assigned to the tenant
• Number of users directly assigned to the tenant (not as part of groups)

The on the right of every tenant allows performing the following operations:

• Adding/removing users to/from the tenant
• Adding/removing user-groups to/from the tenant
• Deleting the tenant - possible only if the tenant has no users. User-groups or resources associated with it.

Also, clicking Add on the top-right corner of the widget, you can create new tenants.

Widget settings

• Refresh time interval - The time interval in which the widget’s data will be refreshed, in seconds. Default: 30 seconds.

Site Management

The default Site Management page displays the Sites widget which provides a list of all sites and enables you to create, update, and delete sites. You can use Search input inside Sites widget to filter the sites list.

Each site in the list includes the following:

• Name

• Visibility level - Click the icon next to the name, to permit users (the sites’s creator, sys admins, or tenant managers of the current tenant) to set the visibility as a private/visible resource.

• Location - The location of the site, represented by latitude and longitude. Hovering over opens a popup with small map and marked locations.

  NOTE: Currently, zooming the map view does not work properly.

  

• Created - Site creation time

• Creator - Site creator

• Tenant - The name of the tenant the site belongs to (if the site is global, it might belong to a tenant different than the current one).

• Number of deployments assigned to the site

In the right column of the table you can edit or delete the site, if you have the correct permissions. To create new site, in the top-right corner of the widget click Create.

Create a Site

1. Click ghe Site Management balde, and then click Create.
2. Enter a name for the site. The name must be unique in the scope of the site (tenant/global).
3. Optional, to choose the visibility level click and set to visible/private accordingly.

4. Optional, in the Location text box enter the location of the site. Expected format: latitude, longitude such as 32.071072, 34.787274. To get coordinates from a database, click ; otherwise, paste coordinates into the textbox.

5. Click Create.

   

   The site is added to the list.

Update a Site

1. Click Site Management, and then click for the site you want to edit.
2. Enter a new name and/or location for the site.
3. Click Update.

Delete a Site

Deleting a site will remove the assignment of this site from all assigned deployments.

1. Click Site Management, and then click .
2. When prompted to remove the site, click Yes.

Set site for a deployment

You can set a site for already deployed nodes.

1. Click the Deployments blade.

2. In the deployment node row for which you want to set a site, click .

3. Select the Set Site option from the list, and then in the Site name text box, enter the site where this deployed node resides, and then click Update.

   

LDAP

The vnfm ldap command is used to set LDAP authentication that enables you to integrate your LDAP users and groups with F5 VNFM.

Note

You can use the CLI vnfm declaration in the F5 VNF Manager ONLY.

Optional flags

These will work on each command:

• -v, --verbose - Show verbose output. You can supply this up to three times (for example, -vvv).
• -h, --help - Show this message and exit.

Set command

Usage

vnfm LDAP set [OPTIONS]

Set F5 VNF Manager to use the LDAP authenticator.

Required flags

• -s, --ldap-server TEXT - The LDAP address against which to authenticate, for example: ldaps://ldap.domain.com.
• -u, --ldap-username TEXT- The LDAP admin username to be set on the F5 VNF Manager.
• -p, --ldap-password TEXT - The LDAP admin password to be set on the F5 VNF Manager.
• -d, --ldap-domain TEXT - The LDAP domain to be used by the server.

Optional flags

• -a, --ldap-is-active-directory - Specify whether the LDAP used for authentication is Active-Directory.
• -e, --ldap-dn-extra TEXT - Additional LDAP DN options.

Example

$ vnfm ldap set -s [LDAP SERVER ADDRESS] -u [LDAP ADMIN USERNAME] -p [LDAP ADMIN PASSWORD] -d [DOMAIN NAME]

Integrate with LDAP

VNFM provides a user management mechanism, so you can define different users with different permissions, and upon login perform authentication and authorization to control the users’ access to resources.

You define and manage the users either in F5 VNFM itself, or you can configure your Manager to integrate with an LDAP-based user-management system. You must select one of these options, as you cannot do both, and you must configure your manager accordingly upon installation or immediately afterwards, when no actions are performed on it yet.

Tip

User Management Credentials: You must have F5 VNFM administrator permissions to perform user management-related actions.

Manage users by integrating with an LDAP system

If you choose to integrate with an external user-management system, make sure your manager is configured accordingly:

1. Record the URL of the LDAP service and define sufficient credentials to an LDAP user with search permissions.
2. Configure F5 VNFM with the LDAP configuration during the installation process, in the ldap section of the config.yaml file.
3. Or, use the API to configure an LDAP connection after F5 VNFM Manager is installed, using the vnfm ldap set command, as long as the Manager is clean, meaning that no tenants, groups, users or resources exist.

Usage

vnfm ldap set [OPTIONS]

Options

• -s, --ldap-server TEXT - The LDAP server address to authenticate against [required]
• -u, --ldap-username TEXT - The LDAP admin username to be set on the F5 VNF manager [required]
• -p, --ldap-password TEXT - The LDAP admin password to be set on the F5 VNF manager [required]
• -d, --ldap-domain TEXT - The LDAP domain to be used by the server [required]
• -a, --ldap-is-active-directory - Specify whether the LDAP used for authentication is Active-Directory
• -e, --ldap-dn-extra TEXT - Extra LDAP DN options
• -h, --help - Show this message and exit

Example

vnfm ldap set -a -s ldap://<LDAP SERVER IP>:389 -u <LDAP ADMIN USER> -p <LDAP ADMIN USER PASSWORD> -d <DOMAIN.com>

Note

You can use the CLI vnfm declaration in the F5 VNF Manager ONLY.

How F5 VNF Manager works with the LDAP service

When integrating with an LDAP system, F5 VNFM will prevent you to manage users from the Manager, to prevent conflicts between the two systems which can cause security problems. Instead, users will log into F5 VNFM with their LDAP credentials, and the Manager will authenticate them against the LDAP service. To finish the authorization process into F5 VNFM, the users will have to belong (directly, or using nested groups) to an LDAP group connected to one or more F5 VNFM Tenants.

Connect F5 VNFM user-groups with the LDAP groups

To create this connection between the LDAP system and F5 VNFM you must create user-groups in F5 VNFM that represent your LDAP user groups. You then assign those F5 VNFM groups to tenants in F5 VNF Manager, with the desired roles. When a user logs into F5 VNFM, a request is sent to the LDAP system for authentication and identification of the groups to which the user belongs (including groups that contains groups that eventually contains the user - aka nested groups). F5 VNFM then identifies the tenants that the F5 VNFM groups (that represent the LDAP groups) can access, and allows user access according to the permissions the roles of the groups provide. For more information on creating a user group, see either the CLI command, or the Tenant Management.

In case a user belongs to multiple groups which are assigned to the same tenant with different roles, the user’s permissions in the tenant will be a sum of all the permission it receives from the different groups. For example, user-A is a member of two Groups in LDAP – “team_leaders,” and “devs.” The team_leaders group is associated in F5 VNFM with the group “all_tenants_viewers”, which is assigned to all of the manager’s tenants with the role “Viewer.” The “devs” group is associated in F5 VNFM with the group “dev_users,” which is assigned to dev_tenant with the role “User.” So, user-A is now assigned to dev_tenant twice – once as a Viewer and once as a User. Upon logging into this tenant, the permissions user-A will have will be a sum of the permissions of the two roles. After users have logged in to F5 VNFM, they are visible in the users list, but you cannot perform any management actions on their profiles.

User/LDAP relationship

Tip

LDAP passwords are not saved in VNF Manager.

Roles management with Ldap

Upon assigning a user or a user-group to a tenant, we must specify their permissions in this tenant. Do this by adding a User Role. In user creation, define whether the users are admins or not. If admins, they automatically have maximal permissions to all tenants. If not, they are marked as “default” users, meaning they exist in the system but must be explicitly assigned to specific tenants with specific roles.

When using LDAP, do not manage the users, but the user-groups, so the roles are managed through them.

When a user-group is added to a tenant, a specific tenant role must be assigned to it. By adding a user to a specific user-group, that user will inherit that user-group tenant-association along with its tenant-role (and the same for all the groups that recursively contain this group).

Add users manually

If you choose not to integrate F5 VNF Manager with LDAP systems, you must add each user individually and set a password for them. You can also create user-groups and add users to them. You can assign users and user groups to one or more tenants.

Use the Secret Store

The secrets store provides a secured variable storage (key-value pairs) for data that you do not want to expose in plain text in F5 VNFM blueprints, such as login credentials for a platform. The values of the secrets are encrypted in the database. We use the Fernet encryption of cryptography library, which is a symmetric encryption method that makes sure that the message encrypted cannot be manipulated/read without the key. When you create a secret, the key value can be a text string or it can be a file that contains the key value. The secret store lets you make sure all secrets (for example, credentials to IaaS environments) are stored separately from blueprints, and that the secrets adhere to isolation requirements between different tenants. You can include the secret key in your blueprints and not include the actual values in the blueprints.

Secrets with a hidden value

All the values of the secrets are encrypted in the database. When you create a secret you can specify if you want its value to be hidden or exposed. A secret with a hidden value means the value is only shown to the user who created it, tenant managers and sys-admins. Users can use the secret according to the user roles and the visibility of the secret. Creators and Admins are the only users that can perform any type of update to the secret.

Update a secret with a shown value

• Updating the secret’s value and visibility or deleting the secret is allowed according to the user roles and the visibility of the secret.
• The secret’s Creator and Admins are the only users that can update the secret’s visibility and the “is_hidden” attribute.

Update a secret with a hidden value

Only the creator of the secret and a sys-admin can see, update, or delete the secret with a hidden value (unlike a secret with an exposed value, which other users in the tenant can also update or delete).

Create a secret from the CLI

You can use the vnfm secrets command to manage VNFM secrets (key-value pairs) in the F5 VNF Manager ONLY.

$ vnfm secrets create test -s test_value …

Secret ``test`` created

…

Create a secret from the F5 VNFM Console

Secret Store Management is performed from the System Resources page in the VNFM Console.

1. Click Create in the Secret Store Management widget.

2. Insert the following values:

   • The secret key
   • The secret value (or select the secret file from your file repository)
   • The visibility level, which is the icon of the green man. Click this icon to toggle visibility settings between tenant (green man), private (red padlock), and global (blue earth).
   • If the value of the secret should be hidden

3. Click Create.

   

4. Click for viewing the secret value.

5. To change the visibility level of the secret, click in the key row.

6. To hide the secret value, select the Hidden Value checkbox.

7. For updating the secret value, click in the key row.

Manage secure communication certificates

Use the following information to securely manage communication and remote access authorization.

Customize SSL for internal communication

You can override the internal Manager certificate, and the CA certificate in the F5 VNF Manager configuration. To provide a custom internal CA certificate for the agents to use, add the ca_certificate and optionally ca_key inputs, which you must store in the /opt/cloudify/config.yaml file. To provide a custom internal certificate, use the internal_certificate and internal_key inputs. If none are provided, F5 VNFM will generate the CA and the internal certificate automatically.

Note

• If provided, the internal certificate must be generated with the appropriate subjectAltName extension to allow connections over every used Manager IP or hostname. The internal certificate must be signed by the CA certificate.
• If the ca_certificate and ca_key inputs are provided, the internal certificate will be generated and signed using the provided CA. If the ca_certificate is provided, but ca_key is NOT provided, then F5 VNFM cannot generate the internal certificate and the internal_certificate and internal_key inputs are required.
• In order to use a F5 VNF Manager cluster, the CA key must be present - either generated automatically by F5 VNFM, or passed in the ca_key input.

SSL mode for external communication

F5 VNF manager, by default, doesn’t use SSL for external communication. You can set the manager to use ssl for the external communication during bootstrap or after bootstrap.

During bootstrap, edit the manager blueprint input. In the Security Settings section, set ssl_enabled parameter to true, in order to set the manager ssl mode.

Set the rest_certificate and rest_key parameters, to use your own certificate. If missing, the manager will auto-generate the certificate.

After bootstrap, use cfy ssl command to enable or disable the ssl mode. You can also change the manager certificate by replacing the files under /home/admin/files/ssl/. The relevant files include: cloudify_external_cert.pem and cloudify_external_key.pem.

When bootstrapping with ssl mode, during the bootstrap the certificate will be copied to the local cli-profile. When using CA signed certificate, you’ll need to update it in the cli-profile (to contain the CA certificate and not the manager certificate) or to remove it (depends on the organization configuration).

In order to update the certificate in the cli-profile, run the following command: cfy profile set --rest-certificate CA_CERT_PATH

In case you renew the certificate, just update it in the manager, in the /home/admin/files/ssl directory.

Additional Security Information

• All services required by F5 VNF Manager run under the VNFM (and not root) user in the manager VM. The only exception is the parent process of Nginx, which runs as root in order to enable use of port 80. It is not recommended to change this behavior.
• A secrets store is implemented inside the F5 VNF Manager PostgreSQL database, which provides a tenant-wide variable store.
• Through usage of the secrets store, a user can ensure all secrets (such as credentials to IaaS environments, passwords, and so on) are stored securely and separately from blueprints, and adhere to isolation requirements between different tenants.
• Users need not know the actual values of a secret parameter (such as a password), since they can just point to the secrets store.
• Secrets can be added to the store using a SET function, and retrieved via GET.
• Plugins can access the secrets store, to leverage the secrets when communicating with IaaS environments.
• F5 VNF Manager instances must be secured via SSL to ensure secrets are not passed on an unencrypted communication channel.
• Using PostgreSQL ensures that secrets are replicated across all F5 VNF Manager instances within a cluster, as part of HA.

Logs menu

Logs option in the left-side menu enables you to analyse events/logs produced by your deployments. This menu contains Resource and Time Filter widgets for filtering events/logs listed in Events/Logs widget.

Resource Filter

Resource Filter widget enables you to select a specific execution for logs/events analysis. To limit the list of executions and events/logs, filter by:

• Blueprints
• Deployments
• Nodes
• Node instances

Learn more about using the Resource Filter widget.

Events/Logs Filter

Events/Logs Filter widget enables you to reduce the list of events/logs by specifying log levels, event types, keywords in messages, and time ranges.

Learn more about using the Events/Logs Filter widget.

Events and logs

Displays the logs and events of all the executions in the current tenant, according to the user’s permissions. You can configure the fields that are displayed and can choose to indicate in colors success and failure messages.

Widget settings

• Refresh time interval - The time interval in which the widget’s data will be refreshed, in seconds. Default: 2 seconds
• List of fields to show in the table You can choose which fields to present. By default, these are the fields presented:
  • Icon
  • Timestamp
  • Blueprint
  • Deployment
  • Node Id
  • Node Instance
  • Workflow
  • Operation
  • Message

You can also choose to add the field “Type,” which will present the log level in case of a log, and event type in case of an event. * Color message based on type - when marked as “on,” successful events will be colored blue, and failures in red. Default: On * Maximum message length before truncation- Allow to define the length of the messages presented in the table. Default: 200.

Note

Even if the message is being truncated in the table itself, you can see the full message upon overring.

Resource Filter

Use this widget to filter the data presented in other widgets on the page according to a specific resource. By default, the widget enables filtering by blueprint, deployment, and execution. You can also configuring the widget settings to add fields to filter by node, node instance, and more.

Widget settings

• Refresh time interval - The time interval (in seconds) to refresh the widget data. Default value: 10 seconds.
• Show blueprint filter - To expose filtering by Blueprint. Default value: On
• Show deployment filter - To expose filtering by Deployment. Default value: On
• Show execution filter - Too expose filtering by Execution. Default value: On
• Show node filter - To expose filtering by Node. Default value: Off
• Show node instance filter - To expose filtering by Node Instances. Default value: Off
• Show execution status filter - To expose filtering by Execution Status. Default value: Off
• Show site name filter - To expose filtering by Site Name. Default value: Off
• Allow multiple selection - Enables selecting multiple resources in the filter. Default value: Off

Maintenance mode

When in maintenance mode, VNF Manager activity is suspended. It rejects all requests, and does not perform any action other than to display the status of the Manager and it’s version, and to execute sub-commands of the maintenance mode.

VNF Manager has three maintenance states, activated, activating, and deactivated. To view the current maintenance state of the Manager, run vnfm maintenance-mode status. The state is also displayed when you run vnfm status (so long as the state is not deactivated).

• Activated - VNF Manager is in maintenance mode. It ignores all requests except for vnfm status, vnfm –version and sub-commands of vnfm maintenance-mode.
• Activating - An intermediate state in which the VNF Manager is not fully in maintenance mode. Only requests that trigger executions are blocked. This state enables active executions to complete and prevents new executions from being started.
• Deactivated - VNF Manager operates normally. No requests are blocked.

Usage and Flow

By default, the maintenance mode state is deactivated.

To activate maintenance mode, run vnfm maintenance-mode activate. VNF Manager either enters the activated or activating state.

To view the current status of the maintenance mode, run vnfm maintenance-mode status.

Following the activation request, if there are no active executions (running, pending, cancelling etc.), maintenance mode is activated. The output of vnfm maintenance-mode status for the activated state is as follows.

Maintenance Mode Status:
Status:      activated
Activated At: <time of activation>
Activation Requested At: <time of activation request>

If there are active executions, the Manager enters the activating state.

Maintenance Mode Status:
Status:      activating
Activation Requested At: <time of activation request>

VNF Manager currently has <number of active executions> running or pending executions. Waiting for them to finish before activating. After all executions have completed, the Manager enters the ‘activated’ state.

Note

Execution Details - If you run the maintenance mode status command in verbose mode, you can view detailed information about the current active executions.

Run vnfm maintenance-mode deactivate to deactivate maintenance mode.

Running Maintenance Mode from the VNF Manager

You can manage maintenance mode by selecting Maintenance Mode in the drop-down menu adjacent to your user name.

What’s Next?

Run workflows