How buildpack internal caching work in VMware Tanzu Application Service for VMs (TAS)

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

Symptoms:

An application fails to push due to a missing dependency.

In this instance, the application did not push because the application failed to pick the correct buildpack:

[STG/0] [ERR] Spring Auto Reconfiguration error: No version resolvable for '2.7.0_RELEASE' in 0.6.8, 0.7.0, 0.7.1, 0.7.2, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.8.9, 1.0.0_RELEASE, 1.1.0_RELEASE, 1.10.0_RELEASE, 1.11.0_RELEASE, 1.12.0_RELEASE, 1.2.0_RELEASE, 1.3.0_RELEASE, 1.4.0_RELEASE, 1.5.0_RELEASE, 1.6.0_RELEASE, 1.7.0_RELEASE, 1.8.0_RELEASE, 1.9.0_RELEASE, 2.0.0_RELEASE, 2.1.0_RELEASE, 2.2.0_RELEASE, 2.3.0_RELEASE, 2.4.0_RELEASE, 2.5.0_RELEASE

Environment

Cause

The application did not detect the correct buildpack because the buildpack was changed from online to offline at some point in the past. As a result, the cached metadata is out of sync.

Resolution

To resolve the issue, delete the application and re-push the application. 

Why this corrects the issue

At some point, the application was staged with an online buildpack and then was later staged with an offline buildpack. When the online buildpack is used, the metadata for the buildpack version is cached along with the application instance.

When the offline buildpack is used at a later point, the new metadata does not download but the old metadata still exists and is the authoritative source for which versions are available.

When the application is deleted, the cache is deleted. The next staging of the application uses the second-tier authority, packaged in the offline buildpack, which has a collection of versions that overlaps with the requirements of the buildpack.