you can choose which aspects (currently limited to arm (control plane), devices, configurations)
aspects will only be deleted if specified with the replace flag - for example, devices will only be deleted if replace and devices are specified
aspects will be uploaded if it is specified and in the file - if an aspect is specified but not in the file, it will not be changed (beyond the replace flag) and the user will be warned at the end.
no aspects = all aspects
certificates are the only things deleted from arm with the replace flag since they need an etag during arm upload if they exist. (and the arm template doesn't take in an etag)
the control plane will be exported as an ARM template - which will reduce time needed to set up the control plane aspect of the hub
for import and migrate - if the hub does not exist, the hub will be created
the arm template will be modified to have the correct name (and location, rg, sku if the hub exists)
during export, the connection strings (for endpoints and file upload) will be populated if needed
Tests depend on fixtures now and are more stable (as in dataplane as more retries when checking)
two hubs are created for migrate tests, one for import and export
Better error handling
if the arm deployment fails, the command stops
if a device or config fails, it will be noted but the command will continue
Limitations:
private endpoints are ignored during the import and migration process
dataplane tests can still be flakey (as in the import/migrate command's upload config or device may not get registered)
History:
IoT Hub updates
Addition of az iot hub state commands to introduce saving, uploading, and copying states between IoT Hubs. This will allow for easier migration of IoT Hubs when changing location, IoT Hub SKU, number of Event Hub partitions and more. For more information, please read the trouble shooting guide here. The commands are as follows:
az iot hub state import to save the current state of an IoT Hub to a JSON file
az iot hub state export to upload a state from a JSON file to an IoT Hub
az iot hub state migrate to copy a state of an IoT Hub to another IoT Hub
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?
Azure IoT CLI maintainers reserve the right to enforce any of the outlined expectations.
A PR is considered ready for review when all basic expectations have been met (or do not apply).
This will introduce the
az iot hub state
command group:File structure is as follows:
Improvements:
Limitations:
History:
IoT Hub updates
az iot hub state
commands to introduce saving, uploading, and copying states between IoT Hubs. This will allow for easier migration of IoT Hubs when changing location, IoT Hub SKU, number of Event Hub partitions and more. For more information, please read the trouble shooting guide here. The commands are as follows:az iot hub state import
to save the current state of an IoT Hub to a JSON fileaz iot hub state export
to upload a state from a JSON file to an IoT Hubaz iot hub state migrate
to copy a state of an IoT Hub to another IoT HubThis 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
dev
ormain
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
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..pylintrc
and.flake8
rules? Look at the CI scripts for example usage.Azure IoT CLI maintainers reserve the right to enforce any of the outlined expectations.
A PR is considered ready for review when all basic expectations have been met (or do not apply).