initial 100 service mgmt APIs generated by AutoRust

[ctaggart]

The code generated from AutoRust is now usable. I wanted to get feedback on the generated code and how it may be integrated here. This code is generated by running cargo run --example storage_mgmt, followed by a cargo fmt in this project.

See the example storage_account_list.rs for an example of using the generated API. Example output:

# of storage accounts 1
Some("/subscriptions/54771b03-185e-4fba-98db-4324215b1031/resourceGroups/dev/providers/Microsoft.Storage/storageAccounts/ctaggart01")

Outstanding issues

• crate names for services crate names for services #42
• config to each operation or methods in a Client generate Clients for services #50
• handling error responses error handling for generated services #47
• date format services should use time crate for dates #51
• deserialization error for virtual machine list compute service deserialization error for VirtualMachines_List #54
• azure_core::TokenCredential to get auth token move TokenCredential to azure_core #52
• azure_identity::AzureCliCredential in examples use AzureCliCredential in service examples #53

[rylev]

Overall, it's looking good. I'm really just not so sure we want this to be a separate crate. Can we talk through the pros and cons of having this as a separate crate?

[ctaggart]

Overall, it's looking good. I'm really just not so sure we want this to be a separate crate. Can we talk through the pros and cons of having this as a separate crate?

Of course! Thanks for the review. The other SDKs publish the AutoRest generated bindings in separate packages. They do keep the models and operations separate. Both group operations based on a naming convention for the operationId.

Azure SDK for Python

• models https://docs.microsoft.com/en-us/python/api/azure-mgmt-storage/azure.mgmt.storage.v2019_06_01.models?view=azure-python
• operations https://docs.microsoft.com/en-us/python/api/azure-mgmt-storage/azure.mgmt.storage.v2019_06_01.operations?view=azure-python

Azure SDK for Go

• models https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage
• operations https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage/storageapi

The Go SDK versions the generated Service APIs & SDKs separately. I think our code layout should look like Go, where the services are in a separate directory.

• https://godoc.org/github.com/Azure/azure-sdk-for-go/services
• https://godoc.org/github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01

To be like the other Azure SDKs, we should publish the generated Service API crates and keep them separate from the SDK crates.

[ctaggart]

Commit 563b786 allows you to list virtual machines, but unfortunately de-serialization is failing for me.

Camerons-MacBook-Pro:azure-sdk-for-rust cameron$ cargo run --example vm_list
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/examples/vm_list`
Error: reqwest::Error { kind: Decode, source: Error("missing field `additionalUnattendContent`", line: 1, column: 1133) }

To troubleshoot, the http response can be captured using an http proxy like mitmproxy. Then it matter of troubleshooting the serde de-serialization by reducing the json.

[ctaggart]

079dde9 added code generated for the control plane (resource manager) APIs of 70 services. A good way to review this pull request is to check out the branch. With the GitHub CLI https://cli.github.com/ installed, you can do a gh pr checkout 31. The feature names now are the tag names in the readme.md files. The default feature is the first one without preview in its name.

[rylev]

@ctaggart with the massive amount of crates in the workspace, how are clean build times affected?

[ctaggart]

The latest commit from master shows 7m 53s and the latest commit on this branch shows 14m 40s. On my laptop, not nearly that long.

[rylev]

The latest commit from master shows 7m 53s and the latest commit on this branch shows 14m 40s. On my laptop, not nearly that long.

Given the amount of code we're adding, doubling the CI time doesn't seem necessarily like a blocker, but this is something we'll want to keep an eye out for.

[ctaggart]

There are 168 service directories in https://github.com/Azure/azure-rest-api-specs/tree/master/specification. If we estimate that we are able to add 70 more mgmt crates, and may be 70 svc crates, that may be another 14 minutes or 28 minutes total on GitHub Action builds.

[ctaggart]

On my personal MacBook that is a couple of years old, a cargo build after a cargo clean takes just over 3 minutes. I ran it twice:

real 3m9.370s
user 18m37.587s
sys 1m18.459s

real 3m18.807s
user 19m41.191s
sys 1m23.599s

[ctaggart]

Basic error handling of errors and invalid responses is in place. Here is one that I just received:

Camerons-MacBook-Pro:azure-sdk-for-rust cameron$ cargo run --example vm_list
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/examples/vm_list`
Error: UnexpectedResponse { status_code: 404, body: b"{\"error\":{\"code\":\"InvalidResourceType\",\"message\":\"The resource type 'virtualMachines' could not be found in the namespace 'Microsoft.Compute' for api version '2020-06-30'. The supported api-versions are '2015-05-01-preview,2015-06-15,2016-03-30,2016-04-30-preview,2016-08-30,2017-03-30,2017-12-01,2018-04-01,2018-06-01,2018-10-01,2019-03-01,2019-07-01,2019-12-01,2020-06-01'.\"}}" }

[ctaggart]

I think it is ready to merge with error responses and error handling in place. I opened up issues for the additional work.

[rylev]

I'd like to get this into the main branch and then go from there 👍