Sql location issue

[WilliamMortlMicrosoft]

closes #809

Describe the bug
If a SQL server already exists and you want to take it over via the operator you would first create a secret with the credentials for that server then deploy a kube manifest for the server.

If the location in the manifest does not match the location of the exist server the kube resource will fail to provision (status.failedProvision=true).

If the user update the location to be correct the resource should then recover and provision.

what actually happens is an unrecoverable loop

 status:
  failedProvisioning: true
  message: successfully provisioned
  provisioned: true
  requested: "2020-03-24T19:30:58Z"
  resourceId: /subscriptions/70/....
  specHash: 8b2cd8e07d4e98404008c51b8ea629c9605ec0f9b6f73c1c7caa8df33864db60
  state: Ready

To Reproduce
Steps to reproduce the behavior:

• create sql server via operator,
• save the secret it creates
• clear local kube cluster
• change location of sql server request and redeploy it to kube cluster...should see failed state
• update sql server request to have correct location
• now works!!!!

New Expected behavior

after updating the location to be correct, the server should no longer say failedProvisioning and the operator should end reconciliation successfully

[WilliamMortlMicrosoft]

I just need to verify... I'm like 80% sure this will work

[frodopwns]

doesn't this just need failedProvisioning to be reset to false?

[WilliamMortlMicrosoft]

doesn't this just need failedProvisioning to be reset to false?

@frodopwns I dont believe so, because on here:

https://github.com/Azure/azure-service-operator/blob/master/pkg/resourcemanager/azuresql/azuresqlserver/azuresqlserver_reconcile.go#L194

provisioning is set to false (its also set to false in a slew of other false cases), thus here:

https://github.com/Azure/azure-service-operator/blob/master/pkg/resourcemanager/azuresql/azuresqlserver/azuresqlserver_reconcile.go#L106

will never trigger the true condition... I believe this is your infinite loop.

[WilliamMortlMicrosoft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[frodopwns]

doesn't this just need failedProvisioning to be reset to false?

@frodopwns I dont believe so, because on here:

https://github.com/Azure/azure-service-operator/blob/master/pkg/resourcemanager/azuresql/azuresqlserver/azuresqlserver_reconcile.go#L194

provisioning is set to false (its also set to false in a slew of other false cases), thus here:

https://github.com/Azure/azure-service-operator/blob/master/pkg/resourcemanager/azuresql/azuresqlserver/azuresqlserver_reconcile.go#L106

will never trigger the true condition... I believe this is your infinite loop.

ah yes...that is probably why I punted on it...the refactor was getting a bit long in the tooth and then this bug showed up

[WilliamMortlMicrosoft]

@frodopwns @jananivMS I'm going to test this, but its such a corner case that I was wondering if you could both look and give me some early thoughts...

[WilliamMortlMicrosoft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[frodopwns]

lgtm

[WilliamMortlMicrosoft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).