|
| 1 | +--- |
| 2 | +title: '2024-04: RoleAssignments UUID Generation' |
| 3 | +--- |
| 4 | + |
| 5 | +## Context |
| 6 | + |
| 7 | +In ASO, we made several improvements to make RoleAssignment user-friendly by auto-generating their AzureName (which must be a UUID) using UUIDv5 with a seed string based on group, kind, namespace, and name. |
| 8 | +The aim for above approach was to: |
| 9 | +- include the namespace and name to ensure no two RoleAssignments in the same cluster can end up with the same UUID. |
| 10 | +- include the group and kind to ensure that different kinds of resources get different UUIDs. This isn't entirely required by Azure, but it makes sense to avoid collisions between two resources of different types even if they have the same namespace and name. |
| 11 | +- include the owner group, kind, and name to avoid collisions between resources with the same name in different clusters that actually point to different Azure resources. |
| 12 | + |
| 13 | +In scenarios where users have multiple ASO instances across different clusters, resources within the identical namespaces, and each cluster has resources with identical names pointing to distinct Azure resources, there is no native support for this configuration. To work around this limitation, users must manually assign a unique UUID to each RoleAssignment. Alternatively, setting the AzureName property to a random UUID by default can prevent the issue, but it may lead to complications if a RoleAssignment is ever deleted and then recreated (or migrated between clusters), as the old UUID would become orphaned. |
| 14 | + |
| 15 | +Issue: [RoleAssignment UUID clashes](https://github.com/Azure/azure-service-operator/issues/3637) |
| 16 | + |
| 17 | +### Option 1: Adding a new property |
| 18 | + |
| 19 | +Add a new property on RoleAssignment spec to control this behaviour. |
| 20 | + |
| 21 | +To use random uuid: |
| 22 | +```yaml |
| 23 | +uuidGeneration: random |
| 24 | +``` |
| 25 | +
|
| 26 | +To use deterministic uuid(default) |
| 27 | +```yaml |
| 28 | +uuidGeneration: stable |
| 29 | +``` |
| 30 | +
|
| 31 | +**Pro**: Backward compatible |
| 32 | +**Pro**: Ease of use |
| 33 | +
|
| 34 | +**Con**: Need to implement infrastructure to add a new property |
| 35 | +**Con**: Users will have to manage the AzureName by themselves while exporting/importing |
| 36 | +
|
| 37 | +### Option 2: Using annotations |
| 38 | +
|
| 39 | +We can use annotation below to control the name generation behaviour. |
| 40 | +In this case, If user does not specify any annotation and does not specify AzureName, ASO sets the default annotation below and follows the default behaviour of stable UUID generation. |
| 41 | +
|
| 42 | +To use random uuid: |
| 43 | +```yaml |
| 44 | +serviceoperator.azure.com/uuid-generation: random |
| 45 | +``` |
| 46 | +
|
| 47 | +To use deterministic uuid(default) |
| 48 | +```yaml |
| 49 | +serviceoperator.azure.com/uuid-generation: stable |
| 50 | +``` |
| 51 | +
|
| 52 | +**Pro**: Backward compatible |
| 53 | +**Pro**: Ease of use |
| 54 | +
|
| 55 | +**Con**: Users will have to manage the AzureName by themselves while exporting/importing |
| 56 | +**Con**: Pushes a crucial part of the resource definition into an annotation; the spec is no longer a complete definition of the resource. |
| 57 | +**Con**: Annotations are far more easily modified by other tooling, which may have unexpected flow on effects. |
| 58 | +
|
| 59 | +### Option 3: Using subscription ID as seed |
| 60 | +
|
| 61 | +Adding subscriptionId as a seed string would make the resource names distinct across subscriptions |
| 62 | +
|
| 63 | +**Pro**: User does not have to do anything |
| 64 | +
|
| 65 | +**Con**: Moving resource with same name between older to newer ASO version would require a workaround |
| 66 | +**Con**: Webhooks don't have information about subscriptionID |
| 67 | +
|
| 68 | +### Option 4: Use custom OperatorSpec property |
| 69 | +
|
| 70 | +Adding an OperatorSpec property to the RoleAssignment resource. Which would enable users to choose the generation type within operatorSpec while resource creation. |
| 71 | +
|
| 72 | +``` yaml |
| 73 | + operatorSpec: |
| 74 | + generationType: random/default |
| 75 | +``` |
| 76 | +
|
| 77 | +**Pro**: Backward compatible |
| 78 | +**Pro**: Ease of use |
| 79 | +**Pro**: Decoupled from annotations and resource spec |
| 80 | +
|
| 81 | +**Con**: Users will have to manage the AzureName by themselves while exporting/importing if they use Random generation |
| 82 | +
|
| 83 | +## Decision |
| 84 | +
|
| 85 | +Recommendation: Option 4 - Using OperatorSpec properties |
| 86 | +
|
| 87 | +We retain how the resource shape looks like and suggest using OperatorSpec property for the users running into the edge case. |
| 88 | +
|
| 89 | +## Status |
| 90 | +
|
| 91 | +Proposed. |
| 92 | +
|
| 93 | +## Consequences |
| 94 | +
|
| 95 | +TBC |
| 96 | +
|
| 97 | +## Experience Report |
| 98 | +
|
| 99 | +TBC |
| 100 | +
|
| 101 | +## References |
| 102 | +
|
| 103 | +None |
0 commit comments