Hub endpoint control plane

vilit1 commented 2 years ago

~Waiting for merge - need to have the newer SDK with the Cosmos DB feature released due to non-backwards compatible API.~

Edit: since 10/25, it seems like this is no longer the case and the api is now backwards compatible. Testing shows that it should be more or less satisfactory aside from being able to create and test routes with the cosmos db endpoint but not show/list/update/delete them. Service is dealing with that.

Edit: 11/1, we will go back to waiting on the Azure CLI core to have the new sdk so we don't have the extension fight with the core for sdk versions.

Addition of Cosmos DB Endpoint creation!

Essentially moving over endpoint and route management right now. The new command groups are:

az iot hub message-endpoint
az iot hub message-route

Sadly the sdk used still has models (endpoints's UserAssignedIdentities property does not work well with modelless)

Endpoints creation is broken up, like so:

az iot hub messaging-endpoint create cosmosdb-collection
az iot hub messaging-endpoint create eventhub
az iot hub messaging-endpoint create servicebus-topic
az iot hub messaging-endpoint create servicebus-queue
az iot hub messaging-endpoint create storage-container

This helps isolate which params are needed for which specific endpoints.

Other quality of life fixes:

Improved tests for endpoints! Now all types of endpoints are created (including service types and auth types)!
Fixed route test app-properties and system-properties to correctly try to change the format of those arguments to json before sending it to the service *
Changed how endpoint delete works (especially when specifying both the name and type)
Added connection string lookup for endpoint creation
Added test fixtures

Notes: * these will be fixed in the azure cli core commands too.

Also added a small fix in the dynamosettings, if the value is "sentinel" then it is nulled out. This value gets set if there is misconfigured pipeline variable (especially if adding new pipeline variables).

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Thank you for contributing to the IoT extension!

This checklist is used to make sure that common guidelines for a pull request are followed.

General Guidelines

Intent for Production

[ ] It is expected that pull requests made to default or core branches such as dev or main are of production grade. Corollary to this, any merged contributions to these branches may be deployed in a public release at any given time. By checking this box, you agree and commit to the expected production quality of code.

Basic expectations

[ ] If introducing new functionality or modified behavior, are they backed by unit and/or integration tests?
[ ] In the same context as above are command names and their parameter definitions accurate? Do help docs have sufficient content?
[ ] Have all the relevant unit and integration tests pass? i.e. pytest <project root> -vv. Please provide evidence in the form of a screenshot showing a succesful run of tests locally OR a link to a test pipeline that has been run against the change-set.
[ ] Have linter checks passed using the .pylintrc and .flake8 rules? Look at the CI scripts for example usage.
[ ] Have extraneous print or debug statements, commented out code-blocks or code-statements (if any) been removed from the surface area of changes?
[ ] Have you made an entry in HISTORY.rst which concisely explains your user-facing feature or change?