Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

3 Deployment and Administration Notes

Important things to know before deploying SUSE Cloud Application Platform.

3.1 README First

README first!

Before you start deploying SUSE Cloud Application Platform, review the following documents:

Read the Release Notes: Release Notes SUSE Cloud Application Platform

Read Chapter 3, Deployment and Administration Notes

3.2 Important Changes

Warning: Deprecation of cflinuxfs2 and sle12 Stacks

As of SUSE Cloud Foundry 2.18.0, since our cf-deployment version is 9.5 , the cflinuxfs2 stack is no longer supported, as was advised in SUSE Cloud Foundry 2.17.1 or Cloud Application Platform 1.4.1. The cflinuxfs2 buildpack is no longer shipped, but if you are upgrading from an earlier version, cflinuxfs2 will not be removed. However, for migration purposes, we encourage all admins to move to cflinuxfs3 or sle15 as newer buildpacks will not work with the deprecated cflinuxfs2. If you still want to use the older stack, you will need to build an older version of a buildpack to continue for the application to work, but you will be unsupported. (If you are running on sle12, we will be retiring that stack in a future version so start planning your migration to sle15. The procedure is described below.)

  • Migrate applications to the new stack using one of the methods listed. Note that both methods will cause application downtime. Downtime can be avoided by following a Blue-Green Deployment strategy. See https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html for details.

    Note that stack association support is available as of cf CLI v6.39.0.

    • Option 1 - Migrating applications using the Stack Auditor plugin.

      Stack Auditor rebuilds the application onto the new stack without a change in the application source code. If you want to move to a new stack with updated code, please follow Option 2 below. For additional information about the Stack Auditor plugin, see https://docs.cloudfoundry.org/adminguide/stack-auditor.html.

      1. Install the Stack Auditor plugin for the cf CLI. For instructions, see https://docs.cloudfoundry.org/adminguide/stack-auditor.html#install.

      2. Identify the stack applications are using. The audit lists all applications in orgs you have access to. To list all applications in your Cloud Application Platform deployment, ensure you are logged in as a user with access to all orgs.

        tux > cf audit-stack

        For each application requiring migration, perform the steps below.

      3. If necessary, switch to the org and space the application is deployed to.

        tux > cf target ORG SPACE
      4. Change the stack to sle15.

        tux > cf change-stack APP_NAME sle15
      5. Identify all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf buildpacks
      6. Remove all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf delete-buildpack BUILDPACK -s sle12
        tux > cf delete-buildpack BUILDPACK -s cflinuxfs2
      7. Remove the sle12 and cflinuxfs2 stacks.

        tux > cf delete-stack sle12
        tux > cf delete-stack cflinuxfs2
    • Option 2 - Migrating applications using the cf CLI.

      Perform the following for all orgs and spaces in your Cloud Application Platform deployment. Ensure you are logged in as a user with access to all orgs.

      1. Target an org and space.

        tux > cf target ORG SPACE
      2. Identify the stack an applications in the org and space is using.

        tux > cf app APP_NAME
      3. Re-push the app with the sle15 stack using one of the following methods.

      4. Identify all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf buildpacks
      5. Remove all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf delete-buildpack BUILDPACK -s sle12
        tux > cf delete-buildpack BUILDPACK -s cflinuxfs2
      6. Remove the sle12 and cflinuxfs2 stacks using the CF API. See https://apidocs.cloudfoundry.org/7.11.0/#stacks for details.

        List all stacks then find the GUID of the sle12 cflinuxfs2 stacks.

        tux > cf curl /v2/stacks

        Delete the sle12 and cflinuxfs2 stacks.

        tux > cf curl -X DELETE /v2/stacks/SLE12_STACK_GUID
        tux > cf curl -X DELETE /v2/stacks/CFLINUXFS2_STACK_GUID
Warning: Doppler Port Change

As of SUSE Cloud Application Platform 1.4, Doppler has been changed to use port 443 to allow for SSL communication and passthrough to Ingress controller. Firewall rules should be updated accordingly.

3.3 Usage of Helm Chart Fields in Cloud Application Platform

There are slight differences in the way Cloud Application Platform uses some Helm chart fields than what is defined in https://v2.helm.sh/docs/developing_charts. Take note of the following fields:

APP VERSION (appVersion in Chart.yaml)

In Cloud Application Platform, the APP VERSION field indicates the Cloud Application Platform release that a Helm chart belongs to. This is in contrast to indicating the version of the application as defined in https://v2.helm.sh/docs/developing_charts/#the-appversion-field. For example, in the suse/uaa Helm chart, an APP VERSION of 1.4 is in reference to Cloud Application Platform release 1.4 and does not indicate uaa is version 1.4.

CHART VERSION (version in Chart.yaml)

In Cloud Application Platform, the CHART VERSION field indicates the Helm chart version, the same as defined in https://v2.helm.sh/docs/developing_charts/#charts-and-versioning. For Cloud Application Platform Helm charts, the chart version is also the release number of the coresponding component. For example, in the suse/uaa Helm chart, a CHART VERSION of 2.16.4 also indicates uaa is release 2.16.4.

3.4 Helm Values in scf-config-values.yaml

Take note of the following Helm values when defining your scf-config-values.yaml file.


For SUSE® CaaS Platform and other Kubernetes deployments where the nodes are based on SUSE Linux Enterprise, the btrfs file system driver must be used. By default, btrfs is selected as the default.

For Microsoft AKS, Amazon EKS, Google GKE, and other Kubernetes deployments where the nodes are based on other operating systems, the overlay-xfs file system driver must be used.

3.5 Status of Pods during Deployment

Some Pods Show as Not Running

Some uaa and scf pods perform only deployment tasks, and it is normal for them to show as unready and Completed after they have completed their tasks, as these examples show:

tux > kubectl get pods --namespace uaa
secret-generation-1-z4nlz   0/1       Completed

tux > kubectl get pods --namespace scf
secret-generation-1-m6k2h       0/1       Completed
post-deployment-setup-1-hnpln   0/1       Completed
Some Pods Terminate and Restart during Deployment

When monitoring the status of a deployment, pods can be observed transitioning from a Running state to a Terminating state, then returning to a Running again.

If a RESTARTS count of 0 is maintained during this process, this is normal behavior and not due to failing pods. It is not necessary to stop the deployment. During deployment, pods will modify annotations on itself via the StatefulSet pod spec. In order to get the correct annotations on the running pod, it is stopped and restarted. Under normal circumstances, this behavior should only result in a pod restarting once.

3.6 Namespaces

Length of release names

Release names (for example, when you run helm install --name) have a maximum length of 36 characters.

Always install to a fresh namespace

If you are not creating a fresh SUSE Cloud Application Platform installation, but have deleted a previous deployment and are starting over, you must create new namespaces. Do not re-use your old namespaces. The helm delete command does not remove generated secrets from the scf and uaa namespaces as it is not aware of them. These leftover secrets may cause deployment failures. See Section 31.4, “Deleting and Rebuilding a Deployment” for more information.

3.7 DNS Management

The following tables list the minimum DNS requirements to run SUSE Cloud Application Platform, using example.com as the example domain. Your DNS management is platform-dependent, for example Microsoft AKS assigns IP addresses to your services, which you will map to A records. Amazon EKS assigns host names, which you will use to create CNAMEs. SUSE CaaS Platform provides the flexibility to manage your name services in nearly any way you wish. The chapters for each platform in this guide provide the relevant DNS instructions.

Warning: Supported Domains

When selecting a domain, SUSE Cloud Application Platform expects DOMAIN to be either a subdomain or a root domain. Setting DOMAIN to a top-level domain, such suse, is not supported.


A SUSE Cloud Application Platform cluster exposes these four services:

Kubernetes service descriptionsKubernetes service names
User Account and Authentication (uaa)uaa-uaa-public
Cloud Foundry (CF) TCP routing servicetcp-router-tcp-router-public
CF application SSH accessdiego-ssh-ssh-proxy-public
CF routerrouter-gorouter-public

uaa-uaa-public is in the uaa namespace, and the rest are in the scf namespace.

3.8 Releases and Associated Versions

The supported upgrade method is to install all upgrades, in order. Skipping releases is not supported. This table matches the Helm chart versions to each release as well as other version related information.

CAP ReleaseSCF and UAA Helm Chart VersionStratos Helm Chart VersionStratos Metrics Helm Chart VersionMinimum Kubernetes Version RequiredCF API ImplementedKnown Compatible CF CLI VersionCF CLI URL
1.5.2 (current release)   6.34.0https://github.com/cloudfoundry/cli/releases/tag/v6.34.0