cluster-api-provider-azure

cluster-api-provider-azure copied to clipboard

/kind bug

[Before submitting an issue, have you checked the Troubleshooting Guide?]

What steps did you take and what happened:

1. Create an AKS cluster following the documentation https://capz.sigs.k8s.io/topics/managedcluster.html.
2. Increase the capz-controller-manager deployment log level from 0 to 5 by changing the --v flag.
3. After the cluster has been created, make a change to the cluster outside of Cluster API.
   • ex: Add tags, environment=testing to the AKS cluster from the Azure portal.
4. Make a change to the AzureManagedControlPlane configuration yaml so the changes are different from the ones made in the portal.
   • ex: Add tags. environment=development
5. Wait till Cluster API updates the cluster
6. Review the capz-controller-manager logs to see that there are no log entries showing the diff between tags.

What did you expect to happen:

When looking at capz-controller-manager logs, there should be log entries when diffs are identified between current AKS cluster state and target state.

Anything else you would like to add:

Example of expected log entries from a different Azure resource. https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/85c1951c4f1cfdec5fabb5b5a5b9a865082421f0/azure/services/agentpools/agentpools.go#L157

Environment:

• cluster-api-provider-azure version: 1.4.1
• Kubernetes version: (use kubectl version): 1.22.3
• OS (e.g. from /etc/os-release): Ubuntu 20.04.3 LTS

/area managedclusters

/help

@CecileRobertMichon: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to this:

/help

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.

/assign

@AAkindele Can you talk more about point 4?

Make a change to the AzureManagedControlPlane configuration yaml so the changes are different from the ones made in the portal. ex: Add tags. environment=development

What did you mean by Add tags. environment=development? Did you add it to the annotations or labels of AzureManagedControlPlane manifest?

@nawazkh Apologies for the lack of details. I added the tags to AzureManagedControlPlane using spec.additionalTags.

Example below with most of the fields removed for brevity.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AzureManagedControlPlane
metadata:
  name: capi-quickstart
spec:
  additionalTags:
    environment: development

@AAkindele can you clarify that this is actually a feature request for additional log information (at a higher verbosity) rather than a bug with the way capz reconciles AzureManagedControlPlane tags?

@AAkindele can you clarify that this is actually a feature request for additional log information (at a higher verbosity) rather than a bug with the way capz reconciles AzureManagedControlPlane tags?

Correct. This is a request for additional logs when a cluster is being updated. The AzureManagedControlPlane tags was just a way to trigger updates. But it could have been the cluster version, or anything else that would trigger an update to the cluster.