Skip to content
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

[BUG] Sql Database creation not assigning elastic pool at the same time causing Azure Policy to deny the creation #1283

Open
orbus-dkreivenas opened this issue Nov 2, 2021 · 0 comments

Comments

@orbus-dkreivenas
Copy link

Describe the bug

When creating a Sql Database, the database creation fails if there is an Azure policy defined to not allow databases to be created without elastic pool.

To Reproduce

  1. Add and Assign an Azure policy to prevent database creation without elastic pool
  2. Execute the command in the snippet.

Code Snippet

database =
    await azure.SqlServers.Databases
        .Define("DatabaseName")
        .WithExistingSqlServer("ServerName")
        .WithExistingElasticPool("PoolName")
        .CreateAsync();

Expected behavior

Expectation is that the database will be created with the pool assigned.

Setup (please complete the following information):

  • Version: 1.38.0

Additional context

We discovered this with a service that creates database in Azure for customer environment provisioning. This prevents us from provisioning databases in a secure manner.

By comparing requests with PowerShell Az library, we identified that the issue is with the API version being used.

The Fluent library is using 2014-04-01 which seems to be ignoring the elastic pool name property in the create request, thus causing the policy to deny the request.

PowerShell is using the 2021-02-01-preview version, which causes the request to succeed.

Another difference is that the c# lib is sending elasticPoolName property, and PS is providing the full elasticPoolId. We tried substituting the property for the 2014-04-01 endpoint to send elasticPoolId, but the endpoint returns just a plain 400 (obvious as the elasticPoolId is not supported for 2014). We also tested this against different versions of API and it seems the pool assignment starts to work on/after 2017-03-01-preview.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant