Different Versions of the same Release in Runtime Config and Manifest Result in Deploy Error
search cancel

Different Versions of the same Release in Runtime Config and Manifest Result in Deploy Error

book

Article ID: 293860

calendar_today

Updated On:

Products

Operations Manager

Issue/Introduction

This KB article aims to provide clarity on what happens when a BOSH runtime-config specifies a release version which targets an instance belonging to a deployment whose manifest contains the same release but a different version.

Currently BOSH will not allow a deployment and runtime-config targeting that deployment to use the same release but different versions. It will throw an error such as the following when deploying:
  
Task 2966 | 15:57:25 | Error: Runtime manifest specifies release 'os-conf' with version as '22.1.3'. This conflicts with version '22.1.2' specified in the deployment manifest.


The error above is due to the runtime-config specifying the os-conf release version 22.1.3 but the instance its targeting belongs to a deployment manifest which specifies os-conf release version 22.1.2. To workaround this issue the following may be considered: 

Workaround 1 (preferred)
Update the runtime-config to specify the release version being utilized by the deployment manifest. There is a walkthrough of this below in the "Resolution" section.
 

Workaround 2
Specify "latest" for the release version in the deployment manifest so BOSH picks up the latest available version for that release. For example: 
name: <deployment name>
releases:
- name: os-conf
  version: latest
Specifying "latest" for a release version is not supported in runtime-configs but it is supported for deployment manifests.

It is worth mentioning there may be caveats with this approach. For example a deployment may be tested against a specific release version and updating the release version on an existing deployment may cause other complications.

Environment

Product Version: 2.10

Resolution

To elaborate on this concept, here a walkthrough using a simple "hello world" BOSH deployment and runtime-config with the os-conf release. This walkthrough considers that os-conf versions 22.1.2 and 22.1.3 are uploaded to BOSH as releases. These releases can be found here (22.1.2) and here ​​​​​​​(22.1.3).

Deployment manifest (mydeployment.yml)

name: mydeployment
stemcells:
- alias: default
  os: ubuntu-xenial
  version: 621.615
releases: 
- name: os-conf
  version: 22.1.2
update:
  canaries: 2
  max_in_flight: 1
  canary_watch_time: 5000-60000
  update_watch_time: 5000-60000
instance_groups:
- name: myvm
  azs: 
  - az1
  instances: 1
  jobs: []
  vm_type: small
  stemcell: default
  networks:
  - name: infra


Runtime-config (mydeployment-runtime-config.yml)

releases:
- name: os-conf
  version: 22.1.3

addons:
  - name: os-configuration
    include:
      instance_groups:
      - myvm
    jobs:
    - name: pre-start-script
      release: os-conf
      properties:
        script: |-
          #!/bin/bash

          set -ex

          touch /var/vcap/sys/log/myfile


Step 1
Deploy the manifest for the BOSH deployment:

bosh -d mydeployment deploy mydeployment.yml


This will create the mydeployment BOSH deployment. We can then request the manifest and view the os-conf release version:

$ bosh -d mydeployment manifest | grep os-conf -A1
- name: os-conf
  version: 22.1.2



Step 2

In scenarios where you need to retrieve a specific runtime-config

bosh runtime-config --name <runtime-config-name> > runtime-config.yml


Update the runtime-config:

bosh update-runtime-config --name=my-deployment-os-conf mydeployment-runtime-config.yml


This will create a BOSH runtime-config which targets instances with the instance-group name "myvm"


Step 3
Redeploy the BOSH deployment mydeployment:

bosh -d mydeployment manifest > mydeployment-manifest.yml
bosh -d mydeployment deploy mydeployment-manifest.yml


This will yield the error:
 

Task 2977 | 16:35:08 | Error: Runtime manifest specifies release 'os-conf' with version as '22.1.3'. This conflicts with version '22.1.2' specified in the deployment manifest.


Step 4
Update the runtime config so that it uses os-conf release 22.1.2:

Runtime-config (mydeployment-runtime-config.yml)

releases:
- name: os-conf
  version: 22.1.2

addons:
  - name: os-configuration
    include:
      instance_groups:
      - myvm
    jobs:
    - name: pre-start-script
      release: os-conf
      properties:
        script: |-
          #!/bin/bash

          set -ex

          touch /var/vcap/sys/log/myfile


Once those edits are made, save and push the changes to BOSH:

$ bosh update-runtime-config --name=my-deployment-os-conf mydeployment-runtime-config.yml

  releases:
  - name: os-conf
-   version: 22.1.3
+   version: 22.1.2


Step 5
The redeploy the BOSH deployment mydeployment should succeed without the error now since the runtime-config and the deployment manifest reference the same os-conf release version.



Conclusion
If a runtime-config specifies a release version that targets an instance belonging to a deployment manifest that specifies the same release but a different version then there will be a conflict and deploys will result in error. The recommended solution is to use the same release version in the runtime-config that the manifest references.

Consider a tile like VMware GemFire for Tanzu Application Service. This tile packages the os-conf release within it and may result in these errors if a runtime-config uses a different os-conf version and that runtime-config targets VMware GemFire for Tanzu Application Service VMs. To find out the versions of a release a tile is using, refer to the release notes or unzip the .pivotal file and review the releases directory. For example, if an environment is upgrading the VMware GemFire for Tanzu Application Service tile from v1.14.7 to 1.14.9 and os-conf targets those VMS then the runtime-config may need to be updated before the upgrade to avoid deployment errors.

#Find the os-conf leveraged from tile version 1.14.7

$ mv p-cloudcache-1.14.7-build.4.pivotal p-cloudcache-1.14.7-build.4.zip
$ unzip p-cloudcache-1.14.7-build.4.zip

$ cat metadata/metadata.yml | grep os-conf -A1
      - name: os-conf
        version: "22.1.2+stemcell.621.401"


#Find the os-conf leveraged from tile version 1.14.9

$ mv p-cloudcache-1.14.9-build.5.pivotal p-cloudcache-1.14.9-build.5.zip
$ unzip p-cloudcache-1.14.9-build.5.zip

$ cat metadata/metadata.yml | grep os-conf -A1
      - name: os-conf
        version: "22.1.3+stemcell.621.543"


Here we can see:

  • VMware GemFire for Tanzu Application Service tile version 1.14.7 contains os-conf release version "22.1.2+stemcell.621.401".
  • VMware GemFire for Tanzu Application Service tile version 1.14.9 contains os-conf release version "22.1.3+stemcell.621.543".


If an environment is leveraging os-conf release version 22.1.2+stemcell.621.401 targeting the VMs for VMware GemFire for Tanzu Application Service tile version 1.14.7 then the runtime-config for these VMs would need to be updated to point to os-conf release version 22.1.3+stemcell.621.543 prior to the upgrade of the tile to version 1.14.9 to avoid the os-conf version conflict error during deployments.

Powered by Wolken Software