This repository has been archived by the owner on Feb 10, 2022. It is now read-only.
Add special case for Azure Availability Sets #355
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
❌ Hey larham! All pull request submitters and commit authors must have a Contributor License Agreement (CLA). Click here for details on the CLA process. The following github user @larham is not covered by a CLA. After the CLA process is complete, this pull request will need to be closed & reopened. DreddBot will then validate the CLA(s). |
Azure Availability Sets are miniature failure-domains, kind of like specifying that the same rack should not be used to run multiple instances of the same app. (Azure is moving to have normal Availability Zones (AZs) like other clouds, based on data-centers, with one zone per data center.) OpsMan 2.5+ decided to signal the usage of Azure Availability Sets by setting the Zone to be a constant string "Availability Sets". In other words, a Zone is required to be specified, and they overloaded the meaning of zone to be both an attribute that holds the zone name and, in this case, to hold a constant "signal" string. Sadly, this string breaks some assumptions about zone names. Any Availability Zone (or Availability Set) that is input by user configuration should already have been validated before it reaches this .erb template. Further, the string does not comply with Kubernetes Label requirements. As a workaround, we add a conditional to sense the Azure-only, artificial zone value (the string "Availability Sets"), and omit its usage as a value for the output of environmental variable 'bosh.zone'. [#168302689]
larham
force-pushed
the
availability_sets
branch
from
e82579e
to
914779f
Compare
professor
pushed a commit
that referenced
this pull request
Sep 24, 2019
Azure Availability Sets are miniature failure-domains, kind of like specifying that the same rack should not be used to run multiple instances of the same app. (Azure is moving to have normal Availability Zones (AZs) like other clouds, based on data-centers, with one zone per data center.) OpsMan 2.5+ decided to signal the usage of Azure Availability Sets by setting the Zone to be a constant string "Availability Sets". In other words, a Zone is required to be specified, and they overloaded the meaning of zone to be both an attribute that holds the zone name and, in this case, to hold a constant "signal" string. Sadly, this string breaks some assumptions about zone names. Any Availability Zone (or Availability Set) that is input by user configuration should already have been validated before it reaches this .erb template. Further, the string does not comply with Kubernetes Label requirements. As a workaround, we add a conditional to sense the Azure-only, artificial zone value (the string "Availability Sets"), and omit its usage as a value for the output of environmental variable 'bosh.zone'. [#168302689]
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add special case for Azure Availability Sets
As a workaround, we add a conditional to sense the Azure-only,
artificial zone value (the string "Availability Sets"),
and omit its usage as a value for the output of
environmental variable 'bosh.zone'.
What this PR does / why we need it:
Adapt to OpsMan 2.5+; fix breakage on Azure
How can this PR be verified?
Local test; integration pipeline under way
Is there any change in kubo-deployment?
No
Is there any change in kubo-ci?
No
Does this affect upgrade, or is there any migration required?
No
Which issue(s) this PR fixes:
https://pivotal-spike.atlassian.net/browse/PKS-349
Release note: