CFE-1134: Watch infrastructure and update AWS tags #1148

chiragkyal · 2024-09-23T10:55:15Z

The PR introduces the following changes:

The ingress controller now watches for the Infrastructure object changes. This ensures that any modifications to user-defined tags (platform.AWS.ResourceTags) trigger an update of the load balancer service.
Consider the awsLBAdditionalResourceTags annotation as a managed annotation. Any changes to user-defined tags in the Infrastructure object will be reflected in this annotation, prompting an update to the load balancer service.

Implements: CFE-1134

openshift-ci-robot · 2024-09-23T10:55:19Z

@chiragkyal: This pull request references CFE-1134 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set.

In response to this:

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 openshift-eng/jira-lifecycle-plugin repository.

chiragkyal · 2024-09-26T04:58:52Z

/retest

openshift-ci-robot · 2024-10-03T07:21:14Z

@chiragkyal: This pull request references CFE-1134 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set.

In response to this:

The PR introduces the following changes:

The ingress controller now watches for the Infrastructure object changes. This ensures that any modifications to user-defined tags (platform.AWS.ResourceTags) trigger an update of the load balancer service.

The logic for determining load balancer service updates now considers the awsLBAdditionalResourceTags annotation as a managed annotation. Any changes to user-defined tags in the Infrastructure object will be reflected in this annotation, prompting an update to the load balancer service.

Changing awsLBAdditionalResourceTags annotation won't mark the IngressController and the operator as Upgradable=False.

Implements: CFE-1134

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 openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-10-07T08:43:42Z

@chiragkyal: This pull request references CFE-1134 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set.

In response to this:

The PR introduces the following changes:

The ingress controller now watches for the Infrastructure object changes. This ensures that any modifications to user-defined tags (platform.AWS.ResourceTags) trigger an update of the load balancer service.

Consider the awsLBAdditionalResourceTags annotation as a managed annotation. Any changes to user-defined tags in the Infrastructure object will be reflected in this annotation, prompting an update to the load balancer service.

Updating awsLBAdditionalResourceTags annotation won't mark the IngressController and the operator as Upgradable=False.

Implements: CFE-1134

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 openshift-eng/jira-lifecycle-plugin repository.

chiragkyal · 2024-10-07T08:44:20Z

/assign @Miciah

candita · 2024-10-09T17:50:45Z

/assign

Miciah

Could you add an E2E test? (I don't know whether an E2E test can update the ResourceTags in the infrastructure config status.)

pkg/operator/controller/ingress/controller.go

Miciah · 2024-10-14T04:49:17Z

pkg/operator/controller/ingress/controller.go

@@ -134,6 +136,12 @@ func New(mgr manager.Manager, config Config) (controller.Controller, error) {
 	if err := c.Watch(source.Kind[client.Object](operatorCache, &configv1.Proxy{}, handler.EnqueueRequestsFromMapFunc(reconciler.ingressConfigToIngressController))); err != nil {
 		return nil, err
 	}
+	// Watch for changes to infrastructure config to update user defined tags
+	if err := c.Watch(source.Kind[client.Object](operatorCache, &configv1.Infrastructure{}, handler.EnqueueRequestsFromMapFunc(reconciler.ingressConfigToIngressController),
+		predicate.NewPredicateFuncs(hasName(clusterInfrastructureName)),


The other watches technically should have this predicate too, and ingressConfigToIngressController should be renamed. However, adding the predicate to the other watches and renaming the map function should be addressed in a follow-up.

pkg/operator/controller/ingress/load_balancer_service.go

Miciah · 2024-10-14T05:22:48Z

pkg/operator/controller/ingress/load_balancer_service.go

-	ignoredAnnotations := managedLoadBalancerServiceAnnotations.Union(sets.NewString(awsLBAdditionalResourceTags))
+	ignoredAnnotations := managedLoadBalancerServiceAnnotations.Clone()
+	ignoredAnnotations.Delete(awsLBAdditionalResourceTags)


Can't we just use managedLoadBalancerServiceAnnotations now?

Suggested change

ignoredAnnotations := managedLoadBalancerServiceAnnotations.Union(sets.NewString(awsLBAdditionalResourceTags))

ignoredAnnotations := managedLoadBalancerServiceAnnotations.Clone()

ignoredAnnotations.Delete(awsLBAdditionalResourceTags)

return loadBalancerServiceAnnotationsChanged(current, expected, managedLoadBalancerServiceAnnotations)

To elaborate on that question, there are two general rules at play here:

First, the status logic sets Upgradeable=False if, and only if, it observes a discrepancy between the "managed" annotations' expected values and the actual values.

Second, by the time the status logic runs, there will not be any discrepancy between the expected (desired) annotation values and the actual annotation values.

And these general rules have exceptions:

As an exception to the first rule, before this PR, awsLBAdditionalResourceTags wasn't "managed", but even so, we set Upgradeable=False if it had been modified. (This is the logic that you are modifying here.)

As an exception to the second rule, if shouldRecreateLoadBalancer indicates that changing an annotation value requires recreating the service, then the desired and actual values can differ when the status logic observes them.

So now that you are making the awsLBAdditionalResourceTags annotation a managed annotation, don't we still want to set Upgradeable=False if the annotation value doesn't match the expected value?

Thank you for the detailed explanation on how the status logic works and how it sets Upgradeable=False, as well as the exception that existed with awsLBAdditionalResourceTags before this PR. Earlier, I was under the impression that the status logic would still set Upgradeable=False even if awsLBAdditionalResourceTags was updated by the controller.

So now that you are making the awsLBAdditionalResourceTags annotation a managed annotation, don't we still want to set Upgradeable=False if the annotation value doesn't match the expected value?

Since awsLBAdditionalResourceTags will now be managed by the controller, and we still want to set Upgradeable=False if it’s updated by something other than the ingress controller, it does indeed make sense to use managedLoadBalancerServiceAnnotations directly in this logic. This way, the status logic will behave consistently for managed annotations when any discrepancy is observed.

I've removed the loadBalancerServiceTagsModified() function and used loadBalancerServiceAnnotationsChanged() directly inside loadBalancerServiceIsUpgradeable() and also added some comments for clearer understanding of the flow.

openshift-ci-robot · 2024-10-15T17:14:07Z

@chiragkyal: This pull request references CFE-1134 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set.

In response to this:

The PR introduces the following changes:

The ingress controller now watches for the Infrastructure object changes. This ensures that any modifications to user-defined tags (platform.AWS.ResourceTags) trigger an update of the load balancer service.

Consider the awsLBAdditionalResourceTags annotation as a managed annotation. Any changes to user-defined tags in the Infrastructure object will be reflected in this annotation, prompting an update to the load balancer service.

Implements: CFE-1134

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 openshift-eng/jira-lifecycle-plugin repository.

chiragkyal · 2024-10-15T18:08:31Z

Could you add an E2E test? (I don't know whether an E2E test can update the ResourceTags in the infrastructure config status.)

I need to try it to see if updating the infrastructure config status is possible through E2E. I used kubectl edit-status infrastructure cluster command to manually update the status while doing some testing. Need to check if similar thing can be done through E2E.

Having said that, do you think we should get QE sign-off for this PR?

Miciah · 2024-10-16T20:00:54Z

I need to try it to see if updating the infrastructure config status is possible through E2E. I used kubectl edit-status infrastructure cluster command to manually update the status while doing some testing. Need to check if similar thing can be done through E2E.

The tests in test/e2e/configurable_route_test.go update the ingress cluster config status; maybe that's useful as a reference or precedent for adding a similar E2E test to this PR.

What I'm wondering is whether the test can update the infrastructure config status without some other controller stomping the changes, and whether there could be other reasons specific to the infrastructures resource or resourceTags API field why an E2E test should not or cannot update it.

Having said that, do you think we should get QE sign-off for this PR?

As a general matter, we should have QE sign-off for this PR. QE might prefer to do pre-merge testing as well.

Is day2 tags support being handled by a specific group of QA engineers, or are the QA engineers for each affected component responsible for testing the feature? Cc: @lihongan.

chiragkyal · 2024-10-16T20:14:28Z

The tests in test/e2e/configurable_route_test.go update the ingress cluster config status; maybe that's useful as a reference or precedent for adding a similar E2E test to this PR.
What I'm wondering is whether the test can update the infrastructure config status without some other controller stomping the changes, and whether there could be other reasons specific to the infrastructures resource or resourceTags API field why an E2E test should not or cannot update it.

I just pushed a commit to add an E2E test. It's working fine locally, hope it should work on CI as well.

Is day2 tags support being handled by a specific group of QA engineers, or are the QA engineers for each affected component responsible for testing the feature?

The QA engineers for each affected component are testing this feature.
/cc @lihongan

chiragkyal · 2024-10-17T03:56:28Z

/retest-required

lihongan · 2024-10-18T03:22:11Z

Did pre-merge test on standalone OCP cluster and it can add new tags key/value pair and update existing tags value, but cannot delete the user added tags. see

$ oc get clusterversion
NAME      VERSION                                                AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.18.0-0.test-2024-10-18-013151-ci-ln-4jn9mbt-latest   True        False         59m     Cluster version is 4.18.0-0.test-2024-10-18-013151-ci-ln-4jn9mbt-latest

$ kubectl edit infrastructure cluster --subresource='status'

$ oc get infrastructures.config.openshift.io cluster -oyaml | yq .status.platformStatus
aws:
  region: us-east-2
  resourceTags:
    - key: Owner
      value: QE
    - key: CaseID
      value: OCP-76984
type: AWS

$ aws elb describe-tags --load-balancer-name a8a32335a6697415e9d55bafce2e6060 --output yaml
TagDescriptions:
- LoadBalancerName: a8a32335a6697415e9d55bafce2e6060
  Tags:
  - Key: kubernetes.io/service-name
    Value: openshift-ingress/router-default
  - Key: Owner
    Value: QE
  - Key: CaseID
    Value: OCP-76984
  - Key: kubernetes.io/cluster/hongli-tags-z7s5b
    Value: owned

// edit status and remove one tags pair and update one tag value
$ oc get infrastructures.config.openshift.io cluster -oyaml | yq .status.platformStatus
aws:
  region: us-east-2
  resourceTags:
    - key: Owner
      value: None
type: AWS

$ aws elb describe-tags --load-balancer-name a8a32335a6697415e9d55bafce2e6060 --output yaml
TagDescriptions:
- LoadBalancerName: a8a32335a6697415e9d55bafce2e6060
  Tags:
  - Key: kubernetes.io/service-name
    Value: openshift-ingress/router-default
  - Key: Owner
    Value: None
  - Key: CaseID
    Value: OCP-76984
  - Key: kubernetes.io/cluster/hongli-tags-z7s5b
    Value: owned

@chiragkyal please confirm if that's expected.
And will try to check HCP later.

lihongan · 2024-10-18T03:34:37Z

And the tags can be added to new created NLB custom ingresscontroler, but when updating tags in infrastructure, the NLB cannot be updated accordingly.

$ oc get infrastructures.config.openshift.io cluster -oyaml | yq .status.platformStatus
aws:
  region: us-east-2
  resourceTags:
    - key: caseid
      value: ocp-88888
type: AWS

$ aws elbv2 describe-tags --resource-arns arn:aws:elasticloadbalancing:us-east-2:******:loadbalancer/net/a84a56f6f236b4f77b0032aaa037882d/9b00573907e8e952 --output yaml
TagDescriptions:
- ResourceArn: arn:aws:elasticloadbalancing:us-east-2:******:loadbalancer/net/a84a56f6f236b4f77b0032aaa037882d/9b00573907e8e952
  Tags:
  - Key: kubernetes.io/service-name
    Value: openshift-ingress/router-nlb
  - Key: caseid
    Value: ocp-88888
  - Key: kubernetes.io/cluster/hongli-tags-z7s5b
    Value: owned

// update with new tags but NLB not changed
$ oc get infrastructures.config.openshift.io cluster -oyaml | yq .status.platformStatus
aws:
  region: us-east-2
  resourceTags:
    - key: new-key
      value: new-value
type: AWS

$ aws elbv2 describe-tags --resource-arns arn:aws:elasticloadbalancing:us-east-2:******:loadbalancer/net/a84a56f6f236b4f77b0032aaa037882d/9b00573907e8e952 --output yaml
TagDescriptions:
- ResourceArn: arn:aws:elasticloadbalancing:us-east-2:******:loadbalancer/net/a84a56f6f236b4f77b0032aaa037882d/9b00573907e8e952
  Tags:
  - Key: kubernetes.io/service-name
    Value: openshift-ingress/router-nlb
  - Key: caseid
    Value: ocp-88888
  - Key: kubernetes.io/cluster/hongli-tags-z7s5b
    Value: owned

It looks like bug with NLB? checked the NLB service and we can find the annotation of updated tags, see

$ oc -n openshift-ingress get svc router-nlb -oyaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: new-key=new-value
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "10"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "4"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "2"
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    traffic-policy.network.alpha.openshift.io/local-with-fallback: ""

lihongan · 2024-10-18T08:15:00Z

looks kubernetes/kubernetes#96939 is for NLB fix but closed

chiragkyal · 2024-10-18T08:24:08Z

@chiragkyal please confirm if that's expected.

It looks like the tags are getting merged with the existing AWS Resource tags. I think we can only control the aws-load-balancer-additional-resource-tags annotation values; the next step depends on how this annotation is getting read by its consumer.
As per https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/add-remove-tags.html, aws has remove-tags API to remove the tags, and I believe the upstream is only using add-tags API only to add the tags, so the tags are not getting removed

@Miciah is there a way we can control this behavior ?

openshift-ci · 2024-10-28T15:17:02Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Miciah

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:

~~OWNERS~~ [Miciah]

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

candita · 2024-10-28T16:13:23Z

test/e2e/operator_test.go

+	}
+
+	t.Log("Updating AWS ResourceTags in the cluster infrastructure config")
+	retryErr := retry.RetryOnConflict(retry.DefaultRetry, func() error {


Why not use updateInfrastructureConfigSpecWithRetryOnConflict here?

Because we want to update the status of the Infrastructure config, instead of spec. I've moved the status update logic to a new function updateInfrastructureConfigStatusWithRetryOnConflict for better understanding.

test/e2e/operator_test.go

candita · 2024-10-28T20:32:54Z

test/e2e/operator_test.go

@@ -1291,6 +1300,79 @@ func TestInternalLoadBalancerGlobalAccessGCP(t *testing.T) {
 	}
 }

+// TestAWSResourceTagsChanged tests the functionality of updating AWS resource tags


One of the acceptance criteria is:
"any modifications to user-defined tags (platform.AWS.ResourceTags) trigger an update of the load balancer service" - shouldn't we have a couple more tests, like deleting a user-defined tag and adding a user-defined tag?

like deleting a user-defined tag and adding a user-defined tag?

The test already covers adding a user-defined tag.

However, updating the infra status again to remove certain tag is possible, which will update the annotation as well, but the tag won't be removed from the AWS resource itself, and this is an expected behaviour for cloud-provider-aws. See #1148 (comment) for more details.

I've extended the test to cover this scenario of tag removal and annotation update in the latest changes. Hope it covers the acceptance criteria.

chiragkyal · 2024-10-29T12:16:57Z

/retest

candita · 2024-10-31T17:21:52Z

test/e2e/operator_test.go

+	// Revert to original status
+	originalInfraStatus := infraConfig.Status


Suggested change

// Revert to original status

originalInfraStatus := infraConfig.Status

// Save a copy of the original infraConfig.Status, to revert changes before exiting.

originalInfraStatus := infraConfig.Status.DeepCopy()

Thanks, addressed the suggestion.

candita · 2024-10-31T17:23:17Z

test/e2e/operator_test.go

+	// Revert to original status
+	originalInfraStatus := infraConfig.Status
+	t.Cleanup(func() {
+		updateInfrastructureConfigStatusWithRetryOnConflict(configClient, func(infra *configv1.Infrastructure) *configv1.Infrastructure {


Suggested change

updateInfrastructureConfigStatusWithRetryOnConflict(configClient, func(infra *configv1.Infrastructure) *configv1.Infrastructure {

err := updateInfrastructureConfigStatusWithRetryOnConflict(configClient, func(infra *configv1.Infrastructure) *configv1.Infrastructure {

Thanks, updated

candita · 2024-10-31T17:26:33Z

test/e2e/operator_test.go

+			infra.Status = originalInfraStatus
+			return infra
+		})
+	})


Something like this:

Suggested change

})

}

if err != nil {

t.Logf("Unable to remove changes to the infraConfig, possible corruption of test environment: %v", err)

}

)

Sure, updated.

candita · 2024-10-31T17:42:43Z

test/e2e/operator_test.go

+// assertLoadBalancerServiceAnnotationWithPollImmediate checks if the specified annotation on the
+// LoadBalancer Service of the given IngressController matches the expected value.
+func assertLoadBalancerServiceAnnotationWithPollImmediate(t *testing.T, kclient client.Client, ic *operatorv1.IngressController, annotationKey, expectedValue string) {
+	err := wait.PollImmediate(5*time.Second, 5*time.Minute, func() (bool, error) {


Sorry I didn't notice this earlier, but since I requested other changes, I'm adding this too.

We have started replacing the use of deprecated wait.PollImmediate with
wait.PollUntilContextTimeout(context.Background(), as used in https://github.com/openshift/cluster-ingress-operator/blob/master/test/e2e/operator_test.go#L3189. Please use the updated function here, and any new code that requires polled waiting.

No problem and thanks for the suggestion. I have replaced wait.PollImmediate with wait.PollUntilContextTimeout to be consistent.

candita · 2024-10-31T17:51:10Z

test/e2e/operator_test.go

+	err := wait.PollImmediate(5*time.Second, 5*time.Minute, func() (bool, error) {
+		service := &corev1.Service{}
+		if err := kclient.Get(context.Background(), controller.LoadBalancerServiceName(ic), service); err != nil {
+			t.Logf("failed to get service %s: %v", controller.LoadBalancerServiceName(ic), err)


Suggested change

t.Logf("failed to get service %s: %v", controller.LoadBalancerServiceName(ic), err)

t.Logf("failed to get service %s: %v, retrying...", controller.LoadBalancerServiceName(ic), err)

candita · 2024-10-31T17:52:19Z

test/e2e/operator_test.go

+			return false, nil
+		}
+		if actualValue, ok := service.Annotations[annotationKey]; !ok {
+			t.Logf("load balancer has no %q annotation: %v", annotationKey, service.Annotations)


Suggested change

t.Logf("load balancer has no %q annotation: %v", annotationKey, service.Annotations)

t.Logf("load balancer has no %q annotation yet: %v, retrying...", annotationKey, service.Annotations)

candita · 2024-10-31T17:57:46Z

test/e2e/operator_test.go

+			return false, nil
+		} else if actualValue != expectedValue {
+			t.Logf("expected %s, found %s", expectedValue, actualValue)
+			return false, nil


I expect that we don't want to keep trying, after we found an unexpected value. Or would we expect it change after this?

Suggested change

return false, nil

return false, fmt.Errorf("expected %s, found %s", expectedValue, actualValue)

I think we need to keep trying here because the annotation value might not get updated immediately after the infra status is updated.

candita · 2024-10-31T18:07:39Z

test/e2e/util_test.go

+// updateInfrastructureStatus updates the Infrastructure status by applying
+// the given update function to the current Infrastructure object.
+func updateInfrastructureConfigStatusWithRetryOnConflict(configClient *configclientset.Clientset, updateFunc func(*configv1.Infrastructure) *configv1.Infrastructure) error {
+	retryErr := retry.RetryOnConflict(retry.DefaultRetry, func() error {


The retry.DefaultRetry is only 10ms https://pkg.go.dev/k8s.io/client-go/util/retry#pkg-variables. Why not use wait.PollUntilContextTimeout(context.Background() and allow it to loop on conflict for a configured amount of time?

Sure, we can use wait.PollUntilContextTimeout(context.Background() here as well. I've updated the logic in the latest changes. Thanks!

- Ingress controller now monitors changes to the Infrastructure object, ensuring that modifications to user-defined AWS ResourceTags (platform.AWS.ResourceTags) trigger updates to the load balancer service. - Consider awsLBAdditionalResourceTags annotation as a managed annotation. Signed-off-by: chiragkyal <[email protected]>

openshift-ci · 2024-11-01T14:36:02Z

@chiragkyal: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-ovn-single-node	`19eced8`	link	false	`/test e2e-aws-ovn-single-node`

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

candita · 2024-11-01T17:28:18Z

/lgtm

candita · 2024-11-01T17:28:43Z

/unhold

openshift-bot · 2024-11-01T19:40:04Z

[ART PR BUILD NOTIFIER]

Distgit: ose-cluster-ingress-operator
This PR has been included in build ose-cluster-ingress-operator-container-v4.18.0-202411011908.p0.g1ee3995.assembly.stream.el9.
All builds following this will include this PR.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 23, 2024

openshift-ci bot requested review from candita and rfredette September 23, 2024 10:55

chiragkyal force-pushed the aws-tags branch from 2063ff8 to 7d38529 Compare September 25, 2024 12:39

chiragkyal force-pushed the aws-tags branch 2 times, most recently from ea36409 to f2e5cf8 Compare October 3, 2024 07:05

chiragkyal changed the title ~~CFE-1134: [WIP] Watch infrastructure and update AWS tags~~ CFE-1134: Watch infrastructure and update AWS tags Oct 3, 2024

chiragkyal force-pushed the aws-tags branch from 2ed28d6 to b5f5909 Compare October 7, 2024 08:41

openshift-ci bot assigned Miciah Oct 7, 2024

openshift-ci bot assigned candita Oct 9, 2024

Miciah reviewed Oct 14, 2024

View reviewed changes

chiragkyal force-pushed the aws-tags branch from b5f5909 to bc7d7a5 Compare October 15, 2024 17:12

chiragkyal force-pushed the aws-tags branch from bc7d7a5 to ae57009 Compare October 15, 2024 17:40

openshift-ci bot requested a review from lihongan October 16, 2024 20:14

chiragkyal requested a review from Miciah October 17, 2024 07:25

openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Oct 28, 2024

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 28, 2024

candita reviewed Oct 28, 2024

View reviewed changes

chiragkyal force-pushed the aws-tags branch from a556017 to b866ba8 Compare October 29, 2024 11:53

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Oct 29, 2024

chiragkyal requested a review from candita October 30, 2024 07:44

candita reviewed Oct 31, 2024

View reviewed changes

chiragkyal force-pushed the aws-tags branch from b866ba8 to 08fe38e Compare November 1, 2024 10:44

chiragkyal force-pushed the aws-tags branch from 08fe38e to 19eced8 Compare November 1, 2024 11:08

chiragkyal requested a review from candita November 1, 2024 14:58

openshift-ci bot added lgtm Indicates that a PR is ready to be merged. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Nov 1, 2024

openshift-merge-bot bot merged commit 1ee3995 into openshift:master Nov 1, 2024
16 of 17 checks passed

chiragkyal deleted the aws-tags branch November 3, 2024 07:07

		// Revert to original status
		originalInfraStatus := infraConfig.Status

	updateInfrastructureConfigStatusWithRetryOnConflict(configClient, func(infra configv1.Infrastructure) configv1.Infrastructure {
	err := updateInfrastructureConfigStatusWithRetryOnConflict(configClient, func(infra configv1.Infrastructure) configv1.Infrastructure {

-	})
+	}
+        if err != nil {
+             t.Logf("Unable to remove changes to the infraConfig, possible corruption of test environment: %v", err)
+        }
+	)

	t.Logf("failed to get service %s: %v", controller.LoadBalancerServiceName(ic), err)
	t.Logf("failed to get service %s: %v, retrying...", controller.LoadBalancerServiceName(ic), err)

	t.Logf("load balancer has no %q annotation: %v", annotationKey, service.Annotations)
	t.Logf("load balancer has no %q annotation yet: %v, retrying...", annotationKey, service.Annotations)

	return false, nil
	return false, fmt.Errorf("expected %s, found %s", expectedValue, actualValue)

CFE-1134: Watch infrastructure and update AWS tags #1148

CFE-1134: Watch infrastructure and update AWS tags #1148

Conversation

chiragkyal commented Sep 23, 2024 • edited Loading

openshift-ci-robot commented Sep 23, 2024 • edited by openshift-ci bot Loading

chiragkyal commented Sep 26, 2024

openshift-ci-robot commented Oct 3, 2024 • edited by openshift-ci bot Loading

openshift-ci-robot commented Oct 7, 2024 • edited by openshift-ci bot Loading

chiragkyal commented Oct 7, 2024

candita commented Oct 9, 2024

Miciah left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openshift-ci-robot commented Oct 15, 2024 • edited by openshift-ci bot Loading

chiragkyal commented Oct 15, 2024

Miciah commented Oct 16, 2024 • edited Loading

chiragkyal commented Oct 16, 2024

chiragkyal commented Oct 17, 2024

lihongan commented Oct 18, 2024

lihongan commented Oct 18, 2024 • edited Loading

lihongan commented Oct 18, 2024

chiragkyal commented Oct 18, 2024 • edited Loading

openshift-ci bot commented Oct 28, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chiragkyal commented Oct 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

candita Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

candita Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openshift-ci bot commented Nov 1, 2024

candita commented Nov 1, 2024

candita commented Nov 1, 2024

openshift-bot commented Nov 1, 2024

chiragkyal commented Sep 23, 2024 •

edited

Loading

openshift-ci-robot commented Sep 23, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Oct 3, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Oct 7, 2024 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Oct 15, 2024 •

edited by openshift-ci bot

Loading

Miciah commented Oct 16, 2024 •

edited

Loading

lihongan commented Oct 18, 2024 •

edited

Loading

chiragkyal commented Oct 18, 2024 •

edited

Loading

candita Oct 31, 2024 •

edited

Loading

candita Oct 31, 2024 •

edited

Loading