-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure: create the container on the fly if it does not exist #158
Comments
Hi @DaleyKD thanks for your interest in the library. The implementation tries to clean up after itself, so currently we don’t support creating containers on the fly. I also wanted to minimize the number of API calls on the main lock acquisition path, although in this case I suppose we could wait to catch the exception before creating the container. What use case do you have that would make that desirable? As someone who is not an Azure expert, do you know if there is anything about container creation that would make it less desirable/harder to automate than automatic blob creation? |
First, I totally misread the code path and see where you're automatically creating the blob, while I thought it was the container. My apologies. The main reason is that I don't want to ask my customers to go in and manually create a container. I'd hope asking them to create the storage account would suffice. (If I DO have to ask them, it's not the end of the world.) Creating a container isn't that bad. Let me see if I can find a code snippet from my other project. Well, this is straight from MSFT and how they had us do election mutexes: https://github.com/mspnp/cloud-design-patterns/blob/master/leader-election/DistributedMutex/BlobLeaseManager.cs At the very bottom, you see that they use a I would kindly "argue" that the code should create the container if it doesn't exist, but not clean it up. Reason? In my code, we have MANY services doing leader election. We use the same container, but different blobs. |
Makes sense. Also fits with one of the goals of the library which is to "just work" without extra setup on the back-end.
Nice!
I agree. Upon consideration I think this would be good behavior to add. In fact, it is very consistent with our Is this something you'd be interested in contributing? Implementation notes:
Also, at risk of stating the obvious, in the short-term you should be able to work around this by simply creating the container yourself during process spinup or right before lock acquisition. |
Here's what I have as a workaround: var blobServiceClient = new BlobServiceClient(azureStorageConnectionString);
if (!blobServiceClient.GetBlobContainers().Any(x => x.Name.Equals(containerName)))
{
blobServiceClient.CreateBlobContainer(containerName);
}
services.AddAzureClients(builder =>
{
builder.AddClient<BlobContainerClient, BlobClientOptions>(options => new BlobContainerClient(azureStorageConnectionString, containerName));
}); |
Looking at the code, I thought it would attempt to create a new container if it came back as not found. However, an exception is thrown in my code.
Here's the error immediately kicked out:
The text was updated successfully, but these errors were encountered: