This repository has been archived by the owner on Mar 4, 2024. It is now read-only.
Fix cross-model relations #16
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
With cross-model relations (CMR), the "unit name" visible on the offering side of the relation is a UUID which doesn't match with the unit's own view of its unit name. Thus, the unit cannot find the responses to its cert requests, as they are keyed by the UUID rather than the unit name. By explicitly publishing the unit name over the relation, it ensures that the provider and requirer will use the same key. We use the unit name rather than a UUID or nonce to ensure that non-CMR deployments are not broken upon upgrade. Fixes #14
|
Is it possible with CMRs to be related to two units with the same name? e.g. kubernetes-worker/0 on two different models. If so, should we be concerned about it? This otherwise LGTM. |
|
@Cynerva It is possible, which is part of why the remote unit name ends up being replaced by a UUID, which is what was causing the problem in the first place. However, because the relation data is scoped by the relation, the only units that will see the data will be the ones of the application involved in the relation, so the unit name is only need to tell which unit within the application should get which data, rather than which unit of which application, if that makes sense. |
|
Got it. Thanks. |
tf-gerrit-replicator
pushed a commit
to tungstenfabric/tf-charms
that referenced
this pull request
Jun 29, 2021
With cross-model relations (CMR), the "unit name" visible on the offering side of the relation is a UUID which doesn't match with the unit's own view of its unit name. Thus, the unit cannot find the responses to its cert requests, as they are keyed by the UUID rather than the unit name. By explicitly publishing the unit name over the relation, it ensures that the provider and requirer will use the same key. We use the unit name rather than a UUID or nonce to ensure that non-CMR deployments are not broken upon upgrade. juju-solutions/interface-tls-certificates#16 Change-Id: I3df63b92fc25423d930b5bf1c263eb62125a0a3f
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.
With cross-model relations (CMR), the "unit name" visible on the offering side of the relation is a UUID which doesn't match with the unit's own view of its unit name. Thus, the unit cannot find the responses to its cert requests, as they are keyed by the UUID rather than the unit name. By explicitly publishing the unit name over the relation, it ensures that the provider and requirer will use the same key.
We use the unit name rather than a UUID or nonce to ensure that non-CMR deployments are not broken upon upgrade.
Fixes #14 and lp:1813605