CliQr is now part of Cisco Learn More About Cisco

Upgrade to CloudCenter in Non-HA Mode

Icon

Be sure to review Upgrade Overview before starting this procedure!

 

  1.  CCM-Database Upgrade

    Upgrade CCM and Database in Non-HA Mode

    Overview

    This section provides details on upgrading your deployment to CloudCenter 4.6.x in Non-HA mode. In Non-HA mode, the database may be installed with the CCM or as a standalone server. To have PostgreSQL installed in a standalone VM, you must open Port 5432 to the CCM. See Networking Requirements > Standalone PostgreSQL (Optional) for additional context.

    Icon

    The database back up procedure for this upgrade are provided later in this section. Backup your database and applications before you begin this process (see the Backup Database section below).

    Icon

    If you are upgrading a HA CloudCenter deployment, see CCM-DB Upgrade in HA Mode for additional context.

    Prerequisites

    For each CloudCenter deployment that needs to be upgraded, verify the following prerequisites:

    • Ensure that a version file (/usr/local/osmosix/etc/version) exists in both CCMs to be upgraded.

    • Verify that the version file contains the correct version number (for example, if your current CloudCenter release version is 4.5.5, ensure that the corresponding version value is 4.5.5).

    • See the corresponding release notes for release-specific information on the CloudCenter version to which you are upgrading. For example, the CloudCenter 4.6.0 Release Notes.

    Backup Database

    Icon

    Be aware that the CCM(s) and DB(s) will be offline during the upgrade process. Schedule some down time for your enterprise before starting this process.

    Backup your database and application (the following example uses /mnt, you can change this directory as applicable).

    Backup from 4.5.x
    Icon

    Osmosix users do not have permission to use the -R option. CloudCenter uses the GetVendorList routine. To backup this routine along with the rest of the database, you must provide the -R option using your root user credentials.

    Backup from 4.6.x

    Download the Upgrade Packages

    Download the following files from software.cisco.com to the /tmp folder. See Installation Overview for additional context.

    • core_upgrade.bin

    • ccm-installer.jar
    • ccm-response.xml

    Select Your Upgrade Scenario

    Your upgrade process differs depending on your instance setup. Ascertain the following considerations before you begin the CloudCenter upgrade.

    ScenarioInstance SetupRelated Section
    1
    • Instance 1 = CCM + MySQL + PostGreSQL
    All in the Same Instance
    2
    • Instance 1 = CCM + MySQL
    • Instance 2 = PostgreSQL
    Standalone CCM with Databases on Separate Instances
    3
    • Instance 1 = CCM
    • Instance 2 = MySQL + PostgreSQL
    Standalone CCM with Databases on the Same Instance
    4
    • Instance 1 = CCM
    • Instance 2 = MySQL
    • Instance 3 = PostgreSQL
    All in Separate Instances

    Scenario 1: All in the Same Instance

     All in the Same Instance
    1. Run the following commands on the CCM instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7, ubuntu1204 (Ubuntu12.04 is not recommended for a new install)

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    2. Run the following commands from your download folder.

      Be aware that no changes are required to the ccm-response.xml file.

    Scenario 2: Standalone CCM with Databases on Separate Instances

     MySQL and PostgreSQL Databases are on Separate Instances
    1. Launch an instance for the PostgreSQL database.
    2. Run the following commands on the PostgreSQL instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7 

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    3.  Use the following command to start the database wizard and allow the CCM to access the database.

      See CCM Installation (Required) for additional context.

    4. Run the following commands on the CCM instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7, ubuntu1204 (Ubuntu12.04 is not recommended for a new install)

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    5. Edit the ccm-response.xml file to include the following values:

    6. Run the following commands from your download folder.

    Scenario 3: Standalone CCM with Databases on the Same Instance

     MySQL and PostgreSQL Databases Share the Same Instance
    1. Run the following commands on the MySQL instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7 

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    2. Use the following command to start the database wizard and allow the CCM server to access the PostgreSQL database.

      See CCM Installation (Required) for additional context.

    3. Use the Manage Access to Postgres Database option in the wizard to allow the CCM server to access the PostgreSQL database.

    4. Run the following commands on the CCM instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7, ubuntu1204 (Ubuntu12.04 is not recommended for a new install)

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    5. Edit the ccm-response.xml file to include the following values:

    6. Run the following commands from your download folder.

    7. On the MySQL instance use the database wizard to disable the MySQL database.

      See CCM Installation (Required) for additional context.

    8. Use the Disable MySQL Service option in the wizard to disable the MySQL database.

    Scenario 4: All in Separate Instances

     All in Separate Instances
    1. Run the following commands on the MySQL instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7 

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    2. Use the following command to start the database wizard and allow the CCM server to access the PostgreSQL database.

      See CCM Installation (Required) for additional context.

    3. Use the Manage Access to Postgres Database option in the wizard to allow the CCM server to access the PostgreSQL database.

    4. Run the following commands on the CCM instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7, ubuntu1204 (Ubuntu12.04 is not recommended for a new install)

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    5. Edit the ccm-response.xml file to include the following values:

    6. Run the following commands from your download folder.

    7. No changes are required on the MySQL instance.

     

    Verify Your Upgrade

    Ensure that the version file (/usr/local/osmosix/etc/version) reflects the new release.

    Reboot the CCM Server

    Reboot the CCM server.

    Configure the Properties in the CCM Wizard

    CCM Wizard Properties

    To configure the CCM wizard properties, follow this procedure.

      1. SSH into the CCM instance as a centos user.
      2. Run the following command:

    1. Invoke the CCM wizard.

      CCM Wizard Path
    2. Configure the basic properties. The wizard includes several menu groups with different properties.

      Write this down for future reference!

      Icon
      Write down the Field details in a printed version of the Your Notes section for later use.

      CCM Properties

      Field

      Description

      Mail

      • SMTP Host
      • SMTP Port
      • SMTP Auth

      SMTP server details to send mail notifications.

      Mail_User

      • Mail User
      • Password
      • From User
      • Display Name

      Mail authentication and configuration details to send mail notifications. If you retain the default settings, the mail functionality will not be configured.

      Server_info (Required)
      • Public DNS
      • DNS or IP of the CCM.
      • Used by the CCO VM to communicate with the CCM VM.
      • Monitor URL
      • Monitor VM's complete URL. For example, https://<MON or MON_LB IP address>:8443.
      • Must use HTTPS protocol.
      • Used by the CCM VM to retrieve the health status from the Monitor VM.
      • Hazelcast IP
      • Private IP address of the CCM VM.
      • Used internally by the CloudCenter platform.
      • External URL
      • Optional for non-HA CCM scenarios.

      Config_App_Logo

      No fields listed

      Used by the application profile templates.

      ESB_InfoNo fields listed

      Required only if you installed Enterprise Service Bus (ESB), an optional component that is not installed in CloudCenter appliances by default.

      Network

      • Hostname
      • Interface

      Use the defaults if you are not making any changes to these settings.

      DB
      (Effective CloudCenter 4.7.0)
      • IP or Hostname
      • Username
      • Password
      • DNS or IP of the Database
        • Local host: Default, does not include the flyway migrate configuration
        • Remote host, includes the flyway migrate configuration – see the last bullet in this row.
      • Authentication credentials (username and Password) for the database (either local or remote).
      • Optional – Flyway Migrate. Remote Host Configure the CCM to a remote database by providing the IP address of the remote database. When you provide the IP address, you see an additional screen to configure the flyway migrate process.
        • Yes: Flyway migration takes place.
        • No: Only the configuration files are updated.
        Icon

        DB configuration is required for standalone database deployments.

      ELK_Info
      (Effective CloudCenter 4.7.0)
      • ELK Host
      • Elasticearch Port
      • Logstash Port
      • Kibana Port
      • ELK Password
      • ELK Username
      • Host Identifier
      • Host Identifier List
      • Specify the IP address for the ELK/Monitor host.
      • The Elasticearch Port displays 8881 by default.
      • The Logstash Port displays 4560 by default.
      • The Kibana Port displays 8882 by default.
      • The default ELK Password is re@d0nly (zero between d and n) (change this password after the initial login – see Download Log File for additional context).
      • The default ELK Username = logreader.
      • The Host Identifier is a Unique ID for the server – be sure to prefix the unique identifier with CCM_ for example, CCM_1
      • The Host Identifier List field only applies to environments using the HA mode – provide a list of comma separated unique host identifiers for all ELK/Monitor hosts in a HA setup = for example, CCM_1,CCM_2,myCCM.

        Icon

        In an environment operating in HA mode, if you have two CCM instances with unique IDs configured as CCM_1,CCM_2 in their respective server.properties file, then this property should state CCM_1,CCM_2 in both CCM instances. Each CCM must be aware of the unique ID of the other CCM(s) when in HA mode.

    3. Exit the CCM configuration wizard.

    4. Select Yes, to restart the Tomcat service for the changes to be effective.

    You have successfully installed the CCM component! You can now proceed to the next step – Per CloudCenter Region Installation.

     

    Upgrade the CCO

    See Per CloudCenter Region Installation (Required) > CCO  for additional context.

     

     

  2.  CCO Upgrade

    Upgrade CCO

    Prerequisites

    For each CloudCenter deployment that needs to be upgraded, verify the following prerequisites:

    • Ensure that a version file (/usr/local/osmosix/etc/version) exists in both CCOs to be upgraded.

    • Verify that the version file contains the correct version number (for example, if your current CloudCenter release version is 4.6.0, ensure that the corresponding version value is 4.6.0).

    • See the corresponding release notes for release-specific information on the CloudCenter version to which you are upgrading. For example, the CloudCenter 4.6.0 Release Notes.

    • Backup your database and applications before you begin this process.
    • You should have already performed the CCM-Database Upgrade procedure.

    Backup Webapp Folder

    Backup the exploded war files to a backup folder (the following example uses /mnt, you can change this directory as applicable).

    Download the Upgrade Packages 

    • cco-installer.jar 
    • cco-response.xml 
    • core_upgrade.bin

    Select Your Upgrade Scenario

    Your upgrade process differs depending on your instance setup. Ascertain the following considerations before you begin the CCO upgrade.

    ScenarioInstance SetupRelated Section
    1
    • Instance 1 = CCO + External Script Executor (Docker Container)
    (Default) CCO and the Docker container on the same Instance
    2
    • Instance 1 = CCO
    • Instance 2 = External Script Executor (Docker Container)
    CCO and the Docker container on Separate Instances

    Scenario 1: DEFAULT – CCO and the Docker Container on the Same Instance

     CCO and the Docker Container are Co-Located (DEFAULT)

    1. Run the following commands on the CCO instance.

    2. Run the following commands from your download folder.

    Scenario 2: CCO and the Docker Container on Separate Instances

     CCO and the Docker Container are Not Co-Located
    1. Run the following commands on the CCO instance.

       Syntax

      <ostype> = centos6, centos7, rhel6, rhel7, ubuntu1204 (Ubuntu12.04 is not recommended for a new install)

      <cloudtype> = amazon, azure, azurepack, google, opsource, openstack, softlayer, vmware, vcd

    2. Run the following command from your download folder on the CCO instance.

    3. Run the following commands on the Docker Container instance.

       Syntax

      <ostype> = centos7, rhel7

      <cloudtype> = amazon, azure, azurerm, azurepack, google,  opsource, openstack , softlayer, vmware, vcd

    4. Manually edit the /user/local/osmosix/etc/container.properties file to update the Docker host location and the HTTPS port number.

    5. Reboot the CCO VM to ensure that the Docker IP is accepted by the CCO VM.

    Verify Your Upgrade

    Ensure that the version file (/usr/local/osmosix/etc/version) reflects the new release.

    Reboot the CCO

    Reboot the CCO Server

    Invoke the CCO Wizard

    In some cases, your deployment settings may need to be updated in the CCO server. Reassign the IP address information by running the wizard for both the CCO server.

    Verify the following configuration files to ensure that they reflect the right values for your deployment:

    • /usr/local/tomcat/webapps/ROOT/WEB-INF/rabbit-gateway.properties on the CCO server (verify the gatewayHost value in particular).

    • /usr/local/tomcat/webapps/ROOT/WEB-INF/gateway.properties on the CCO server (verify the rabbit.gateway.brokerHost and rabbit.gateway.cluster.addresses values in particular).

    CCO – Configure CCO Wizard Properties

      1. SSH into the CCO instance as a centos user.
      2. Run the following command:

    1. Invoke the CCO wizard.

      CCO Wizard Path
    2. Configure the Agent bundle, AMQP server, Guacamole server, and Docker server properties. The wizard includes multiple menu groups with different properties. The table below lists each property and highlights the common properties in bold text.

      Write this down for future reference!

      Icon
      Write down the Field details in a printed version of the Your Notes  section for later use.
    3. Configure the properties for the Agent bundle, AMQP server, Guacamole server, and Docker VMs:

      GroupPropertiesNotes

      AgentBundle

       

      Use the defaults.

      • If you are using the custom bundle, replace cdn.cliqr.com with the custom bundle store IP or DNS
      • If you are using the package store, replace repo.cliqrtech.com with the custom package store IP or DNS

      AMQP_Server

      • AMQP Server IP
      • AMQP Port
      • AMQP_IP or AMQP_LB_IP
      • 5671
      Network
      • Hostname
      Configure the Network details for your CCO environment. This is an optional step to configure the Private IP of the VM. You can generally configure this information if the VM does not have preset IP or hostname or if you need to override an existing IP or Hostname.

      Guacamole

       

      • Connection Broker Host
      • Connection Broker Port1
      • Connection Broker Port2
      • AMQP_IP or AMQP_LB_IP 
      • 7788
      • 7789

      Docker

      • Docker Registry URL
      • Docker CACert URL
      • Set only if custom docker registry is used
      • Set only if docker registry uses SSL with custom CA Certificates

      ELK_Info

      (Effective CloudCenter 4.7.0)

      • ELK Host
      • Elasticearch Port
      • Logstash Port
      • Host Identifier
      • Host Identifier List
      • Specify the IP address for the ELK/Monitor host.
      • The Elasticearch Port displays 8881 by default.
      • The Logstash Port displays 4560 by default.
      • The Host Identifier is a Unique ID for the server – be sure to prefix the unique identifier with CCO_ for example, CCO_Openstack_regionOne or CCO_Amazon_east.
      • The Host Identifier List field only applies to environments using the HA mode – provide a list of comma separated unique host Identifiers for all ELK/Monitor hosts in a HA setup = for example, CCO1,CCO2,myCCO.

        Icon

        In an environment operating in HA mode, if you have three CCO instances with unique IDs configured as CCO_1,CCO_2,CCO_3 in their respective server.properties file, then this property should state CCO_1,CCO_2,CCO_3 in each CCO instance. Each CCO must be aware of the unique ID of the other CCO(s) when in HA mode.

    4. Verify your changes and Exit the CCO configuration wizard.

    You have successfully configured the CCO! You can now proceed to the next step.

  3.  AMQP Upgrade

    AMQP Upgrade

    Prerequisites

    For each CloudCenter deployment that needs to be upgraded, verify the following prerequisites:

    • Ensure that a version file (/usr/local/osmosix/etc/version) exists in both AMQPs to be upgraded.

    • Verify that the version file contains the correct version number (for example, if your current CloudCenter release version is 4.6.0, ensure that the corresponding version value is 4.6.0).

    • See the corresponding release notes for release-specific information on the CloudCenter version to which you are upgrading. For example, the CloudCenter 4.6.0 Release Notes.

    • Backup your database and applications before you begin this process.
    • You should have already performed the CCM-Database Upgrade procedure.
    • You should have already performed the CCO Upgrade procedure.
    • Do not change the AMQP server's hostname, once configured.

      Icon

      Any change in the hostname may result in a VM bounce/reboot.

      If you change the AMQP server's hostname, the local AMQP database is renamed and you may need to rerun the AMQP configuration.

      Some clouds set the hostname automatically for each new instance or boot and RabbitMQ uses the a pre-set hostname to set the database name. In these cases, you must run the following commands as root to rerun the AMQP configuration:

      You will also need to run these commands again if the node is rebooted, as you may end up with a new hostname and database name.

      If a database user exists and a login is not associated, this user may not be able to log into the AMQP server.

       

       

     

    Backup Webapp Folder

    Backup the exploded war files to a backup folder (the following example uses /mnt, you can change this directory as applicable). This backup only applies to the Guacamole server, not the AMQP server.

    Download the Upgrade Packages 

    Download the following files from software.cisco.com to the /tmp folder. See Installation Overview for additional context.

    • conn_broker-response.xml
    • cco-installer.jar

      Installer and Upgrade Files

      Icon
      • Core installer files install the software binaries required for by the CloudCenter platform.
      • Core upgrade files apply the software binary or OS updates, and are required in case of an architectural change in CloudCenter components or any OS specific fixes as needed. For example, CloudCenter 4.6.1 requires the *_upgrade file if you are migrating the CCM server from the MySQL DB to the PostgreSQL DB or if the CCO server needs to have the latest Docker version.
      • The _upgrade file is not required by the AMQP or Guacamole components.

    Select Your Upgrade Scenario

    Your upgrade process differs depending on your instance setup. Ascertain the following considerations before you begin the CCO upgrade.

    ScenarioInstance SetupRelated Section
    1                  
                      • Instance 1 = AMQP + Guacamole      
    AMQP and Guacamole on the Same Instance
    2
                      • Instance 1 = AMQP
                      • Instance 2 = Guacamole
    AMQP and Guacamole on Separate Instances

     

    Scenario 1: AMQP and Guacamole on the Same Instance

     AMQP and Guacamole are Co-Located
    1. If your Guacamole server is running on the AMQP server, then issue these commands.

    2. Run the following command from your download folder.

    Scenario 2: AMQP and Guacamole on Separate Instances

     AMQP and Guacamole are not Co-Located

    Be sure to follow this procedure on each server has a separate procedure.

    1. Login to the Guacamole server and back up the webapp folder:

    2. Run the following command from your download folder in the Guacamole server.

    Verify Your Upgrade

    Ensure that the version file (/usr/local/osmosix/etc/version) reflects the new release.

    Post-Upgrade Setup

    Icon

    Any change in the hostname may result in a VM bounce/reboot.

    If you change the AMQP server's hostname, the local AMQP database is renamed and you may need to rerun the AMQP configuration.

    Some clouds set the hostname automatically for each new instance or boot and RabbitMQ uses the a pre-set hostname to set the database name. In these cases, you must run the following commands as root to rerun the AMQP configuration:

    You will also need to run these commands again if the node is rebooted, as you may end up with a new hostname and database name.

    If a database user exists and a login is not associated, this user may not be able to log into the AMQP server.

    Ensure that the required users (cliqr and cliqr_worker) are setup in your database. If you have additional users in your database, they will also be displayed when you run the rabbitmqctl command.

    If you do not see these users in your database, run the following commands as root (to recreate the users in the AMQP configuration):

    Reboot the AMQP Server

    Reboot the AMQP server.

    Start the Wizard

    Use the following command to start the guacamole wizard if you need to change settings as required by your deployment. See Per CloudCenter Region Installation (Required) > AMQP >  AMQP – Configure CCM/CCO Properties for Guacamole Server for additional context.

  4.  Health Monitor Upgrade

    Health Monitor Upgrade

    Prerequisites

    For each CloudCenter deployment that needs to be upgraded, verify the following prerequisites:

    • Ensure that a version file (/usr/local/osmosix/etc/version) exists in both Monitors to be upgraded.

    • Verify that the version file contains the correct version number (for example, if your current CloudCenter release version is 4.6.0, ensure that the corresponding version value is 4.6.0).

    • See the corresponding release notes for release-specific information on the CloudCenter version to which you are upgrading. For example, the CloudCenter 4.6.0 Release Notes.

    • Backup your database and applications before you begin this process.
    • You should have already performed the CCM-Database Upgrade procedure.
    • You should have already performed the CCO Upgrade procedure.

    Backup Database

    Backup the exploded war files to a backup folder (the following example uses /mnt, you can change this directory as applicable)

    Download the Upgrade Packages 

    Download the following files from software.cisco.com to the /tmp folder. See Installation Overview for additional context.

    • core_upgrade.bin
    • monitor-installer.jar
    • monitor-response.xml

    Upgrade

    1. Run the following commands:

      For example: ./core_upgrade.bin centos7 amazon monitor

      • <ostype> = centos6, centos7, rhel6, rhel7 (Ubuntu12.04 is not recommended for a new install)

         

      • <cloudtype> = amazon, azure, azurepack, azurerm, google, opsource, openstack, softlayer, vmware, vcd

    2. Run the following command from your download folder.

    Verify Your Upgrade

    Ensure that the version file (/usr/local/osmosix/etc/version) reflects the new release.

    Reboot the Monitor Server

    Reboot the monitor server.

    Invoke the Monitor Wizard

      1. SSH into the MONITOR instance as a centos user.
      2. Run the following command:

    1. Invoke the monitor wizard. See Health Monitor Installation (Optional) for additional context.

  5.  Docker Image Upgrade

    Docker Image Upgrade

    Overview

    A Docker image upgrade is not required with every release. If a version requires the CloudCenter-supported Docker image to be upgraded, use the procedure provided in this page. 

    When using External Services, the CloudCenter platform launches a Docker container to run the scripts. You may also need to customize this container using the applicable packages.

    The Docker image can reside in one of two places:

    • In the CCO VM (default, co-located)
    • In a Standalone Docker VM

    Versions Requiring a Docker Image Upgrade

    If you upgrade to CloudCenter 4.4.x or 4.5.x from any earlier CloudCenter version, you must upgrade the CloudCenter supported Docker image.

    CloudCenter 4.4.x and later includes the following Docker image enhancements:

    See External Service > Error Handling for additional context.

    Prerequisites

    For each CloudCenter deployment that needs to be upgraded, verify the following prerequisites:

    • Verify that the Docker version is ≤ Docker 1.11. Issue the following command on your Docker server: docker version
      You only need to upgrade your Docker image if your Docker image is not at Docker 1.11.

    • Ensure that a version file (/usr/local/osmosix/etc/version) exists in both CCOs that need to be upgraded.

    • Verify that the version file contains the correct version number (for example, if your current CloudCenter release version is 4.5.1, ensure that the corresponding version value is 4.5.1).

    • See the corresponding release notes for release-specific information on the CloudCenter version to which you are upgrading. For example, the CloudCenter 4.6.0 Release Notes.

    • Backup your database and applications before you begin this process.

    Backup Database

    Backup the exploded war files to a backup folder (the following example uses /mnt, you can change this directory as applicable).

    Download the Upgrade Packages

    • cco-installer.jar 
    • docker.tar
    • Dockerfile

    Select Your Upgrade Scenario

    Your upgrade process differs depending on your instance setup. Ascertain the following considerations before you begin the CCO upgrade.

    ScenarioInstance SetupRelated Section
    1
    • Instance 1 = CCO + Docker
    CCO and Docker on the Same Instance
    2
    • Instance 1 = CCO
    • Instance 2 = Docker
    CCO and Docker on Separate Instances

    Scenario1: CCO and Docker on the same Instance

     CCO and Docker are Co-Located
    1. Run the following commands on the CCO-Docker Instance:

    2. Run the following commands from your download folder.

    3. Run the following commands to update the Docker image file.

     

    Scenario2: CCO and Docker on Separate Instances

     CCO and Docker are not Co-Located
    1. Upgrade your CCO instance. See 2. CCO Upgrade for additional context.
    2. Run the following commands on the Docker Instance:

    3. Run the following commands from your download folder.

    4. Run the following commands to update the Docker image file.

    Verify Your Upgrade

    • Verify that the Docker version is ≤ Docker 1.11. Issue the following command on your Docker server:

    • Issue the following command and verify that the output is as follows:

     

  • No labels