REP-1293: Allocation group resource#507
Conversation
castai/resource_allocation_group.go
Outdated
| case http.StatusOK: | ||
| d.SetId(*create.JSON200.Id) | ||
| return resourceAllocationGroupRead(ctx, d, meta) | ||
| // TODO (romank): do we have a status conflict in our response from API? |
There was a problem hiding this comment.
Conflict or similar status would be useful if someone would like to move their existing allocation groups into terraform so that we don't create duplicate allocation groups.
castai/resource_allocation_group.go
Outdated
| if len(allocationGroups) > 0 { | ||
| for _, ag := range allocationGroups { | ||
| if *ag.Name == *allocationGroupName { | ||
| return diag.Errorf("allocation group already exists") |
There was a problem hiding this comment.
At the moment we do not require Unique names for Allocations Groups in the console. We should either add this check to the API as well, or remove it from here.
There was a problem hiding this comment.
I will check to see if there is an organization that already uses same name for different labeled allocation group and therefore the change would affect someone, and if not I would add this check to the API.
If we don't enforce this it would be possible to have a terraform configuration with the completely equal two entries, e.g.:
resource "cast_ai_allocation_group" "my_allocation_group" {
clusterIds = ["uuid1", "uuid2"]
namespaces = ["namespace1"]
}
resource "cast_ai_allocation_group" "my_allocation_group" {
clusterIds = ["uuid1", "uuid2"]
namespaces = ["namespace1"]
}
We could probably check the whole allocation group definition instead of just the name and would guard from most of the unintended use cases like:
-
Given that the id would be implicit it wouldn't be noticeable in the tf config that those are really two different allocation groups.
-
If migration of previously created allocation groups is not done through importing but just by copying everything in the tf files, the client would recreate all their allocation groups which I would say we should guard for.
But I would argue checking the name uniqueness would make sense from the start as I presume it would be confusing to have two allocation groups with the same name showing same or even different statistics.
tl;dr: I will first check if anyone uses non-unique allocation group names, if not I would enforce it.
…into REP-1293-support-allocation-groups # Conflicts: # castai/provider.go
…into REP-1293-support-allocation-groups # Conflicts: # castai/sdk/api.gen.go
Co-authored-by: Furkhat Kasymov Genii Uulu <vailodf@gmail.com>
…into REP-1293-support-allocation-groups
…into REP-1293-support-allocation-groups
…load scaling policy
…into REP-1293-support-allocation-groups
Example usage from the current schema: