Add PostgreSQL Flexible Server sample

[lazarkanelov]

Summary

• Add a new sample for Azure PostgreSQL Flexible Server with three app variants: Python SDK, .NET SDK, and a Flask notes app
• Include Terraform, Bicep, and ARM (shell scripts) deployment options with validation
• Register the new sample in run-samples.sh for CI across all deployment methods

Test plan

• Verify ARM deployment via scripts/deploy.sh and scripts/validate.sh
• Verify Terraform deployment via terraform/deploy.sh
• Verify Bicep deployment via bicep/deploy.sh
• Confirm CI picks up the new sample in all three shard categories

[paolosalvatori]

Hi @lazarkanelov, thanks for the contribution. 🙂 I have a few comments:

• If you want to create a sample that only deploys a resource, in this case an Azure Database for PostgreSQL flexible server, using Bicep or Terraform, you should include this test in localstack-pro repo. Instead, if you want to create a full sample that also deploys a companion Web App or Functions App + Azure Database for PostgreSQL flexible server, via Bicep, Terraform, and Azure CLI, you need to extend the sample to automate the deployment of the app as well, just like the other samples.
• The name and structure of the sample are wrong. If you want to provide two samples, one in Python and and one in .NET of a Web App +Azure Database for PostgreSQL flexible server, you should replace postgresql-flexible-server/python with web-app-postgresql-database/python and web-app-postgresql-database/dotnet.
• You also need to create a script that invokes the app to check whether is properly deployed and it's working as expected. This way, the GitHub Actions workflow built by @DrisDary can call this integration or validation script to test that the app deployment succeeded.
• You didn't update the main page with a link to the sample.

[paolosalvatori]

@lazarkanelov While creating an Azure Database for PostgreSQL flexible server via REST API is not wrong, the unwritten convention for this repo is to use Azure CLI for any bash script under the scripts folder. I think it would be better to change the az rest call with a call to az postgres flexible-server create

[lazarkanelov]

@paolosalvatori , thanks for the review! I've addressed your feedback:

Changes made:

• Renamed the sample from postgresql-flexible-server/python to web-app-postgresql-database/python to follow the repo's naming convention
• Added a companion Web App - the deploy script now creates an App Service Plan + Web App, configures it with the PostgreSQL connection details, and deploys a Flask notes app (with full-text search powered by PostgreSQL tsvector)
• Updated validate.sh to not only check that Azure resources exist, but also curl the deployed web app to create and list notes - verifying end-to-end that the app is working
• Updated README.md with the new sample name and link
• All 4 CI shards are passing

Regarding az rest vs az postgres flexible-server create:

It looks like az postgres flexible-server create performs a client-side SKU availability pre-check by calling the capabilities endpoint (/locations/{location}/capabilities). LocalStack's implementation of that endpoint currently returns an empty SKU list, so the CLI fails with ERROR: No available SKUs in this location. before it even attempts the actual server creation. This happens regardless of which --sku-name/--tier values are passed, or even if they're omitted (the CLI validates its defaults too).

On the other hand, az rest sends the PUT directly to the management API (the same way Terraform does) bypassing this client-side validation. The server creation itself works fine on LocalStack.

With that being said, I see a 2 paths forward:

1. Fix the capabilities endpoint in LocalStack to return valid SKU data, then switch to az postgres flexible-server create
2. Keep az rest with the explanatory comment (current approach)

Curious what do you think and what you will recommend. :)

[paolosalvatori]

@paolosalvatori , thanks for the review! I've addressed your feedback:

Changes made:

• Renamed the sample from postgresql-flexible-server/python to web-app-postgresql-database/python to follow the repo's naming convention
• Added a companion Web App - the deploy script now creates an App Service Plan + Web App, configures it with the PostgreSQL connection details, and deploys a Flask notes app (with full-text search powered by PostgreSQL tsvector)
• Updated validate.sh to not only check that Azure resources exist, but also curl the deployed web app to create and list notes - verifying end-to-end that the app is working
• Updated README.md with the new sample name and link
• All 4 CI shards are passing

Regarding az rest vs az postgres flexible-server create:

It looks like az postgres flexible-server create performs a client-side SKU availability pre-check by calling the capabilities endpoint (/locations/{location}/capabilities). LocalStack's implementation of that endpoint currently returns an empty SKU list, so the CLI fails with ERROR: No available SKUs in this location. before it even attempts the actual server creation. This happens regardless of which --sku-name/--tier values are passed, or even if they're omitted (the CLI validates its defaults too).

On the other hand, az rest sends the PUT directly to the management API (the same way Terraform does) bypassing this client-side validation. The server creation itself works fine on LocalStack.

With that being said, I see a 2 paths forward:

1. Fix the capabilities endpoint in LocalStack to return valid SKU data, then switch to az postgres flexible-server create
2. Keep az rest with the explanatory comment (current approach)

Curious what do you think and what you will recommend. :)

In case the az postgres flexible-server create calls a REST operation, that we didn't implement properly, as part of the provisioning process, we should implement it or change its implementation. If we don't do it now, the risk is that we'll forget it going forward. HINT: run az postgres flexible-server create --debug --verbose to print the exact sequence of REST calls made by the Azure CLI. This way you can understand what is the sequence of calls on the client side, the request message, the request headers, etc.

So my suggestion is deploying the app against Azure and check what the infamous call returns when run against Azure. Then, change the code of the emulator to return the same list.