Skip to content
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.

Figure out how best to handle resources that must be named default in Azure #324

Closed
Porges opened this issue Nov 12, 2020 · 1 comment
Closed

Comments

@Porges
Copy link
Member

Porges commented Nov 12, 2020

There are a number of these, good examples in the Storage APIs: https://docs.microsoft.com/en-us/azure/templates/microsoft.storage/2019-04-01/storageaccounts/blobservices/containers/immutabilitypolicies

I think we can deduce which resources must be named default from the Swagger specs. The question is then how best to handle these:

  • We can remove the AzureName setting from the CRD and force it to be default.
  • We could consider putting these resources “inside” the parent resource; logically a lot of these are part of the parent resource but must be “deployed” separately for historical reasons. It might make these resources easier to use from a CRD point-of-view as you don’t need to think up a Kubernetes-name for the resource, &c.
Porges added a commit that referenced this issue Nov 12, 2020
…320)

* Add create/delete tests for the `StorageAccountsBlobService` and `StorageAccountsBlobServicesContainer` resource types. 
* Attempt to make deployment more robust, if we deploy a second time and the deployment already exists. This could happen due to faults or spurious failures in patching resources.
  * TODO: We need to check the existing deployment against spec and delete/recreate it if it is different?
*  Handle authentication configuration errors as early as possible; the `autorest` library does not check this and will give back an authorizer that does not work.
* Added temporary fix for #319.
* Fix bad log message in one of the matchers.
* Only save recording for a test when it is successful. This makes it easier to develop when trying to fix a test.

## Outstanding items

We need to think about how to handle resources like `StorageAccountsBlobService` better. It _must_ be named `"default"` to work but this is not enforced at the moment.

One idea is that we could merge this into the `StorageAccount` resource type so that it can be configured there, and the controller takes care of creating it separately.

Another issue is that the name is not going to be unique in Kubernetes. For resources with an owner we might need to scope the name under the owner name, but I’m not sure that this is possible; the object is created in Kubernetes before we can touch the name. The user can set AzureName to "default" and Name to something else but this is not obvious.

I opened an issue for this here: #324
@Porges
Copy link
Member Author

Porges commented Dec 2, 2020

This is further fixed by #329. There might still be some outstanding cases as we need to recognize regular expressions that end in a fixed portion! 😬

@Porges Porges closed this as completed Dec 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant