Jack Francis

@mtougeron quick question about the stated scope in the issue description: Is the reason why this is not appropriate for BYO VNET because in those scenarios the various service endpoint...

cc @CecileRobertMichon @mboersma

@sbueringer would it make sense to include this in today's 1.3.0 beta release?

@sbueringer your summary of the expected behavior in response to this annotation is correct. This is how we're doing this in capz: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/v1.5.3/azure/services/agentpools/agentpools.go#L86-L88

@sbueringer here is the conversation that led to the addition of this annotation in capz: https://github.com/kubernetes-sigs/cluster-api-provider-azure/pull/2444#discussion_r931636784 That approach has worked well thus far for AzureManagedCluster users. The practical reasons for...

I'll take a first pass at the docs, which will clarify the expected provider behaviors. No rush on this, I had thought this was merge-ready hence the 1.3.0 beta comment....

@sbueringer @vincepri docs updated, PTAL As I was working through this, it didn't make any obvious sense to me why this change would only apply to MachinePools, so I did...

Thanks everyone for weighing in on `MachineDeployment` inclusion, that has been removed!

> > > If an autoscaler performs its changes by updating the Replicas value, the annotation in this PR wouldn't be needed. > > > > > > Good point....

This now affects all branches. It appears that there is some correlation between large ginkgo test runs and the invocation of `sigs.k8s.io/cluster-api/test/frameworkDeleteAllClustersAndWait` in capz's `dumpSpecResourcesAndCleanup` convenience func. That convenience func...