add sku option for sqldatabase

[guyomog78]

SUMMARY

Change the non functional edition option to a functional sku option.

Partial Fixes #153 Unable to specify a SKU
Fixes #126

ISSUE TYPE

• Feature Pull Request
• Bugfix Pull Request

COMPONENT NAME

azure_rm_sqldatabase.py
azure_rm_sqldatabase_info.py

ADDITIONAL INFORMATION

The Sku option use the Python Sku class from azure.mgmt.sql.models to be able to push valide values.
The documentation is updated with the new SKU call option
The internal test to detect change is updated (replace edition by sku)

The sku entrie is then identical as the azure_rm_sqldatabase_info report

example call before change

  - name: Create (or update) SQL Database with SKU
    azure_rm_sqldatabase:
      resource_group: myResourceGroup
      server_name: sqlcrudtest-5961
      name: testdb
      location: eastus
      edition: standard

example call after change

  - name: Create (or update) SQL Database with SKU
    azure_rm_sqldatabase:
      resource_group: myResourceGroup
      server_name: sqlcrudtest-5961
      name: testdb
      location: eastus
      sku:
        name: S0

or with more options
example call after change

  - name: Create (or update) SQL Database with SKU
    azure_rm_sqldatabase:
      resource_group: myResourceGroup
      server_name: sqlcrudtest-5961
      name: testdb
      location: eastus
      sku:
        name: S0
        tier: Standard
        capacity: 50

Attention All option under sku should be coherent with the name value else an error is reported

[Fred-sun]

@guyomog78 Can you help tests/integration/the targets/azure_rm_sqlserver/tasks/main yml increase test cases? Thank you very much!

[guyomog78]

@Fred-sun Like make a test with the S0 mode and ensure that realy is a S0 mode, then change to P1 mode ensure that is well a P1?? someting like that?

[Fred-sun]

@Fred-sun Like make a test with the S0 mode and ensure that realy is a S0 mode, then change to P1 mode ensure that is well a P1?? someting like that?

yes! Thanks!

[guyomog78]

OK, did you have an ETA in mind?

[guyomog78]

@Fred-sun, it was a little bit more difficulte as expected, but necessary to correct the sqldatabasinfo too to report the good SKU like documentation say.
when database information collected, sku name is equal to Standard for Service_objective_name S0,S1,S2.. Premium for Service_objective_name P1, P2 ,P3 ...
So, to use the expected information in sku.name (ex: S0, P2, DW100c , GP_FsV2_12...) I have used the current_service_objective_name retruned by the request.

To see current information: Get-AzSqlServerServiceObjective -Location eastus

[Fred-sun]

@guyomog78 Such parameter changes may cause the edition parameter previously configured by the user to be unavailable. Can the following two methods be used to avoid this problem?

First: Add Fail prompt. After this version, the edition parameter is changed to sku, and sku aliase is changed to sku.

Second: Keep the edition parameter, but set the default value and "mutually_exclusive=['edition', 'sku']", for example, when edition: Standard, the default sku.name=S1, and edition: premium, the default sku.name=P1.

[guyomog78]

@Fred-sun t it is a while that the edition parameter is not functionnal, but I understand your point of view.

I will try to keep for this time the edition parameters

[guyomog78]

@Fred-sun It's Done!!
I have also used autopep8 and pylint in vscode and applied "format document"

On test file, I have injected Edition value Premium and it's good. I have tested with standard too ;-)

et Voilà!

PS: Feel free to update the version where edition will be full removed

[guyomog78]

@Fred-sun Thanks a lot for review.
Now I'm aware about that the import part for script should be after documentation. It was modified by the "format document" under vscode. Now, I know that I need to revert this part for the next time if appens :-)