azure: use capz 1.0 release branch for in-tree azure tests

[jackfrancis]

Sorry for the thrashing today. This prior PR pinned in-tree cloud-provider-azure tests to the release-1.1 branch of capz:

#25193

Initial test signal after change suggests that these tests are still not happy against capz @ release-1.1:

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/107981/pull-kubernetes-e2e-capz-conformance/1491515486653911040

The original reason for all of these changes was a breakage in the capz commit @ v1.0.1. For example:

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/107981/pull-kubernetes-e2e-capz-conformance/1491294976963776512

The root cause of the above failures is well-known (it's due to a cert-manager regression in versions of cluster-api prior to v1.0.4). Because (1) we have a prior history of success running these in-tree cloud-provider azure tests against a capz v1.0 version and (2) because the release-1.0 branch of capz has the required, new version of cluster-api built into its CI and cluster definitions (see kubernetes-sigs/cluster-api-provider-azure#2038), lets pin these test-infra jobs to the release-1.0 branch instead of release-1.1.

[jsturtevant]

Changing the name here will lose the history but other wise will be fine

[jsturtevant]

/lgtm

[andyzhangx]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, jackfrancis, jsturtevant

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• config/jobs/kubernetes/sig-cloud-provider/azure/OWNERS [andyzhangx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

@jackfrancis: Updated the job-config configmap in namespace default at cluster test-infra-trusted using the following files:

• key release-1.20.yaml using file config/jobs/kubernetes/sig-cloud-provider/azure/release-1.20.yaml
• key release-1.21.yaml using file config/jobs/kubernetes/sig-cloud-provider/azure/release-1.21.yaml
• key release-1.22.yaml using file config/jobs/kubernetes/sig-cloud-provider/azure/release-1.22.yaml
• key release-1.23.yaml using file config/jobs/kubernetes/sig-cloud-provider/azure/release-1.23.yaml
• key release-master.yaml using file config/jobs/kubernetes/sig-cloud-provider/azure/release-master.yaml

In response to this:

Sorry for the thrashing today. This prior PR pinned in-tree cloud-provider-azure tests to the release-1.1 branch of capz:

#25193

Initial test signal after change suggests that these tests are still not happy against capz @ release-1.1:

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/107981/pull-kubernetes-e2e-capz-conformance/1491515486653911040

The original reason for all of these changes was a breakage in the capz commit @ v1.0.1. For example:

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/107981/pull-kubernetes-e2e-capz-conformance/1491294976963776512

The root cause of the above failures is well-known (it's due to a cert-manager regression in versions of cluster-api prior to v1.0.4). Because (1) we have a prior history of success running these in-tree cloud-provider azure tests against a capz v1.0 version and (2) because the release-1.0 branch of capz has the required, new version of cluster-api built into its CI and cluster definitions (see kubernetes-sigs/cluster-api-provider-azure#2038), lets pin these test-infra jobs to the release-1.0 branch instead of release-1.1.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.