@mboersma - isn't this a duplicate of #2670 ?

@dtzar they're related but not the same: Azure/azure-sdk-for-go and Azure/go-autorest. CAPZ's direct usage of go-autorest can probably be addressed as a separate task, similarly to kubernetes-sigs/cloud-provider-azure#2983.

@mboersma are you interested in working on this or should we mark it as help wanted?

/milestone v1.8

/assign

I'm psyched to work on it but since it's also intertwined with our async framework it will be more work than just replacing our to.StringPtr()-type calls.

Should we maybe start with the to.*Ptr type calls since we'll have to do that regardless of SDK track 2 vs. ASO stuff? that can be its own PR. Then we can evaluate moving async services separately.

@mboersma should this be attached to #3409 parent?

@mboersma should this be attached to #3409 parent?

Yes, good call. Although really it will probably require all of ASO to be implemented as well before go-autorest is literally not used.

/milestone release-1.11

@mboersma: The provided milestone is not valid for this repository. Milestones in this repository: [next, v1.11]

Use /milestone clear to clear the milestone.

/milestone v1.11

See also #4208 which removes a lot of the code in question.

@mboersma can we complete the rest of this work for 1.13 and if so, what is remaining?

@dtzar there are still a few vestigial uses of this library in tests and in some auth code, and in the latter case there isn't an obvious replacement for CAPZ's use of things like auth.Environment.

I don't think there's particular urgency to this, however: the uses are confined and the code in question isn't going to break. I'm hopeful to make some progress on this for v1.13, but there may be higher priorities.

/unassign

I won't be able to address this, at last for a couple weeks. If anyone else wants to pick it up, that would be 💯.

/assign