Hub State Import, Export, Migrate Refactor

[vilit1]

This will introduce the az iot hub state command group:

• az iot hub state export
• az iot hub state import
• az iot hub state migrate

File structure is as follows:

{
  "arm": full_arm_template,
  "configurations": {
       "admConfigurations": {
           "config_id": { config_properties }
       },
       "edgeDeployments": {
           "config_id": { config_properties }
       }
   }
  "devices": {
      "device_id": {
         "identity": { identity_properties (and properties shared with twin) },
         "twin" : { twin_properties },
         "modules" : {
            "module_id" : {
                "identity": { identity_properties },
                "twin": { twin_properties }
            }
         }
      }
   }
}

Improvements:

1. 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)
2. 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
3. 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
4. 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)

---

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] 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?

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).

[vilit1]

Test run: https://dev.azure.com/azureiotdevxp/aziotcli/_build/results?buildId=6717&view=results

[vilit1]

tests passing again

[vilit1]

https://dev.azure.com/azureiotdevxp/aziotcli/_build/results?buildId=7301&view=results - tests passing