Explorergt92
commented
1 month ago It's because the Azure eastus region doesn't have any CosmosDB capacity available, change "eastus" to "eastus2" in ./infra/main.bicep on line 203
Open FrancoisNoyez opened 1 month ago
Explorergt92
commented
1 month ago It's because the Azure eastus region doesn't have any CosmosDB capacity available, change "eastus" to "eastus2" in ./infra/main.bicep on line 203
FrancoisNoyez
commented
1 month ago Hi @Explorergt92 Ok, I see, thanks, I'll look into that.
Hi everyone,
I've been trying to deploy a WebApp via this project, for now with the version of the code associated to commit 16be120e of the 2024-03-16, via the console (so, using the azd tool). After successfully deploying it, I realized that the history feature does not seem to be activated.
After investigating that (logging via ssh into the server hosting the backend, via the web interface providing this service), I realized that this may be caused by the absence of the env variables related to the definition of the COSMOS db (ex: 'AZURE_COSMOSDB_ACCOUNT'). At least it does not appear in the result of the 'env' command, and when I perform the API call with the '/history/ensure' path, I get the answer "CosmosDB is not configured", which suggests that this env variable does not exist from the point of view of the app either. But this env variable is indeed defined in my local .env file associated to the azd env that I'm using for that project. So when I run the code on my computer, then everything works fine, and I do have access to the history functionality. Something that I noticed is that this .env file is not packaged together with the rest of the files / folders, when running the 'azd package' command, which explains why this info is not available for the app when the WebApp is finally launched.
That said, when someone in my company deployed the project via the "GUI wizard on Azure OpenAI studio", the resulting deployed did have the history functionality, which I interpret as the fact that, for this way of deploying, at least some of the variables which are written in the .env file (via the content of the main.bicep) at the end of the provisioning process are / can then made available to the app which hosts the WebApp. But I want to be able to define the project 'as code' as much as possible, for reproducibility of deployment purposes, so I don't want to have to use any kind of GUI in order to achieve the desired state of the project / of the solution.
So my questions are:
I've searched and searched the internet, but I have not been able to find a satisfactory answer yet. My latest lead is maybe setting variables in the 'pipeline' section of the 'azure.yml' file, but I was under the impression that the point of this is to provide env variables which are needed during the build / deployment phase only? Would that be correct for my use case, or not?
In any case, I think whatever the answer to my question is (even if it's a negative one) should be included in the documentation / README file which explains how to deploy the project using the 'azd' tool.