Skip to content

Instantly share code, notes, and snippets.

@benmoss
Forked from gab-satchi/summary.md
Last active August 28, 2019 18:17
Show Gist options
  • Save benmoss/0816eafaac751ef7c33b904f3d289185 to your computer and use it in GitHub Desktop.
Save benmoss/0816eafaac751ef7c33b904f3d289185 to your computer and use it in GitHub Desktop.
PKS Windows stemcell upgarde investigation

Problem

PKS 1.5's Windows support defines the minimum required Windows stemcell as version 2019.7, however if you provide a greater version (eg 2019.8), cluster creation will fail. Full details of this bug are detailed in this Tracker story. The root of the problem was that the PKS service adapter had 2019.7 hardcoded and therefore always would try to deploy that stemcell when deploying Windows clusters.

On-demand service broker (ODB) does not allow using latest for stemcell version, so we had to find a way to send the currently uploaded Windows stemcell version from OpsManager to the broker. The Linux stemcell version was always passed using the tile metadata.

Current solution

PKS tile metadata has been updated to include the Windows stemcell versions found in Plans 11, 12 and 13. Since Windows can be "enabled" by enabling any one of those three plans, we have to look at all of them to see if Windows has been enabled. We now either include the uploaded Windows stemcell version or a "0" for each of the 3 plans. For example, if only Plan 12 is enabled, the tile will send 0:2019.8:0 to the service adapter as the Windows stemcell version.

The service adapter has been updated to parse these stemcell versions and detect if a valid (nonzero) Windows stemcell version was included.

Assumptions

  • None of the uploaded stemcells will have a : in the version. This solution uses a colon as a separator when splitting the single string with all versions.
  • There will never be a Windows-enabled plan deployed without a Windows stemcell also being associated with it. The getWindowsEnabled function tells us if Windows has been enabled for a plan, and if we get into that condition we assume we will find a valid Windows stemcell version. If somehow we have a bug where Windows is enabled but a stemcell version hasn't been sent to the service adapter, a stemcell version of 0:0:0 would be in the resulting manifest and probably lead to a deployment error.

Additional notes

We would have liked to just simply include/exclude the Windows stemcell from the list of stemcells given to the broker based on whether or not the Windows feature is enabled. We couldn't figure out a way to get OpsMan metadata to support this though. In part the problem is the one noted above, that the Windows feature is spread across all three plans, and in part the problem is an inability to conditionally append to arrays with the limited templating tools available in OpsMan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment