feat(locations): location support #1810
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
roleyfoley
requested changes
Sep 20, 2021
ml019
force-pushed
the
feat-location-based-placement
branch
from
cbd01cf
to
a5fa586
Compare
Add support for Locations on ResourceGroups as a means to determine the placement of resources. When determining placements, the resource group id is used as the Location to find the corresponding placement information, so this means the ids of all resource groups need to be known BEFORE location information is checked. As a result, when adding a component, any possible resource groups that an implementation might want to use must be defined. This means that a provider implementer cannot add additional resource groups not already defined when the component was defined. The existing placement profile approach has been left in place but if present, locations take precedence. As locations are link based, their introduction increases the chances of creating loops. Code to detect loops has thus been added when getting Occurrences.
Include more information about locations in the occurrence structure to assist debugging configuration issues. Also move the point at which component configuration for a provider is loaded so provider specific checks on the provided location values are applied.
Add a helper function to decouple what information in an occurrence gets logged in log messages from where the information is needed. The size of the occurrence structure means it does clutter logs if provided in full, and the need for the full set of data is rare. By decoupling the two, additional flexibility around what gets logged can be added without having to revisit all the places where occurrence information is included in logs.
Separate the namesapce used for locations from that used for deployment. Deployment attributes only need to be on deployable components, whereas Locations apply to the processing of all components.
ml019
force-pushed
the
feat-location-based-placement
branch
from
a5fa586
to
90ac573
Compare
|
@roleyfoley retested with |
roleyfoley
approved these changes
Sep 26, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Intent of Change
Description
Add support for Locations on ResourceGroups as a means to determine the placement of resources.
Motivation and Context
Part of ADR0007 implementation.
When determining placements, the resource group id is used as the Location to find the corresponding placement information,
so this means the ids of all resource groups need to be known BEFORE location information is checked.
As a result, when adding a component, any possible resource groups that an implementation might want to use must be
defined. This means that a provider implementer cannot add additional resource groups not already defined when the component was defined.
The existing placement profile approach has been left in place but if present, locations take precedence.
As locations are link based, their introduction increases the chances of creating loops. Code to detect loops has thus
been added when getting Occurrences.
How Has This Been Tested?
Local template generation
Related Changes
Prerequisite PRs:
Dependent PRs:
Consumer Actions: