From 59c27f53eafcc0a9d88bc7a7fe6e60e4aaddcf14 Mon Sep 17 00:00:00 2001 From: lsviben Date: Wed, 8 Mar 2023 18:37:24 +0100 Subject: [PATCH] add more alternatives Signed-off-by: lsviben --- design/one-pager-ignore-changes.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/design/one-pager-ignore-changes.md b/design/one-pager-ignore-changes.md index 5c3c96bfeca..55675667e34 100644 --- a/design/one-pager-ignore-changes.md +++ b/design/one-pager-ignore-changes.md @@ -156,6 +156,12 @@ This will not prevent the field from appearing in the schema of the managed resources. However, we will ignore the `spec.ignoreChanges` when the feature is not enabled. +#### Alternative feature gating approach + +To avoid changing the API, we could ship the `ignoreChanges` field as an +optional annotation as a first solution. This would allow us to survey +users and see how much this feature is useful before adding it to the API. + ### Implementation alternative considered An alternative was considered where the above helper function which unsets @@ -174,6 +180,8 @@ change all the providers, it has a few drawbacks: ## Solution alternative considered +### initContainers + The idea here was to do something similar to K8s `initContainers` and add a field `initProvider` to the managed resources. The parameters under `initProvider` would be used only during creation. @@ -214,11 +222,26 @@ initialization*, which sets some of the `forProvider`fields. To avoid conflicts, the fields that are in `initProviders` would be ignored during *late initialize*. +### Case by case + +This approach would just tackle the ignored fields on a case-by-case basis, +instead of implementing a generic solution. The premise here is that not many +resources would need to use this feature. + +For instance in the [NodeGroup] example, we would add a field `initialSize`, +along with the current `desiredSize` and the updates could be handled in code. + +While this approach is valid, making changes case-by-case could lead to +bad user experience as they would need time to identify the issue and wait +for provider code change, instead of just setting a field. On the other hand, +if this issue is not that widespread, we could have an easy fix. + [AutoScalingGroup DesireCapacity]: https://doc.crds.dev/github.com/upbound/provider-aws/autoscaling.aws.upbound.io/AutoscalingGroup/v1beta1@v0.21.0#spec-forProvider-desiredCapacity [DynamoDB Tables]: https://doc.crds.dev/github.com/upbound/provider-aws/dynamodb.aws.upbound.io/Table/v1beta1@v0.24.0 [Policy]: https://doc.crds.dev/github.com/upbound/provider-aws/appautoscaling.aws.upbound.io/Policy/v1beta1@v0.24.0 [Target]: https://doc.crds.dev/github.com/upbound/provider-aws/appautoscaling.aws.upbound.io/Target/v1beta1@v0.24.0 [NodeGroup]: https://doc.crds.dev/github.com/upbound/provider-aws/eks.aws.upbound.io/NodeGroup/v1beta1@v0.24.0 +[Node Pool]: https://doc.crds.dev/github.com/upbound/provider-gcp/container.gcp.upbound.io/NodePool/v1beta1@v0.28.0 [ignore_changes]: https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#ignore_changes [crossplane-runtime]: https://github.com/crossplane/crossplane-runtime/ [crossplane-runtime/fieldpath]: https://github.com/crossplane/crossplane-runtime/tree/master/pkg/fieldpath \ No newline at end of file