Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix RemoveDeploymentTriggerDecorator order #30768

Closed

Conversation

Sgitario
Copy link
Contributor

@Sgitario Sgitario commented Feb 1, 2023

The decorator RemoveDeploymentTriggerDecorator was not configured to be triggered before ChangeDeploymentTriggerDecorator, so sometimes the image stream tag was wrong.

This change fixes the failure spotted by the test OpenshiftWithDockerAndImageTest where the image stream tag was sometimes 0.1-SNAPSHOT and other times 1.0 when it should be always 1.0.

Relates to the random failures in https://github.com/dekorateio/dekorate/actions/runs/4023231521/jobs/6913879180 and also in the jakarta-rewrite branch

@Sgitario Sgitario requested a review from gsmet February 1, 2023 07:19
@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 9167104 to 9e190ce Compare February 1, 2023 07:20
@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 1, 2023

it seems the issue is still there:

Error:  Failures: 
Error:    OpenshiftWithDockerAndImageTest.assertGeneratedResources:46 
[List check single element] (1 failure)
-- failure 1 --
expected: "openshift-with-docker-and-image:1.0"
 but was: "openshift-with-docker-and-image:0.1-SNAPSHOT"
at OpenshiftWithDockerAndImageTest.lambda$assertGeneratedResources$5(OpenshiftWithDockerAndImageTest.java:56)

@quarkus-bot

This comment has been minimized.

@@ -16,7 +15,7 @@ public void andThenVisit(DeploymentConfigSpecFluent<?> deploymentConfigSpec, Obj
}

@Override
public Class<? extends Decorator>[] after() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be removed.

The purpose of RemoveDeploymentTrigger is to remove triggers either provided by the user or by the ApplyDeploymentTrigger decorator. By removing this condition it's possible that RemoveDeploymentTrigger runs before there is anything to remove.

Copy link
Contributor

@iocanel iocanel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an issue with the implementation as commented directly on the code.
Also this is fixed as part of #30566 so we could possibly close this one.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 1, 2023

There is an issue with the implementation as commented directly on the code. Also this is fixed as part of #30566 so we could possibly close this one.

Unfortunately, this is not fixing the issue even using your changes because the ApplyDeploymentTriggerDecorator from decorator is being applied the last:

[INFO] Applying decorator 'io.quarkus.kubernetes.deployment.RemoveDeploymentTriggerDecorator' -- removes the image triggers if any
[INFO] Applying decorator 'io.quarkus.kubernetes.deployment.ChangeDeploymentTriggerDecorator' -- add the correct image
[INFO] Applying decorator 'io.dekorate.openshift.decorator.ApplyDeploymentTriggerDecorator' -- overwrite the wrong image

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 9e190ce to 16484eb Compare February 1, 2023 08:59
@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 1, 2023

@iocanel I've just updated the changes that seem to consistently apply the decorators in the correct order.
Also, I've followed your suggestion to keep using ApplyDeploymentTriggerDecorator in RemoveDeploymentTriggerDecorator. Additionally, I've updated the RemoveDeploymentTriggerDecorator decorator to only do that to the DeploymentConfig with the correct name.

@Sgitario Sgitario requested a review from iocanel February 1, 2023 09:02
@quarkus-bot

This comment has been minimized.

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 16484eb to ce2d2d6 Compare February 1, 2023 09:56
@quarkus-bot

This comment has been minimized.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 1, 2023

I'm running out of ideas here since locally my changes worked consistently ok, but not in CI.
Now, I'm doing exactly what was done by @iocanel in #30566 in spite of that locally it was not working for me, but just in case CI accepts it.

@quarkus-bot

This comment has been minimized.

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 6a34cf0 to f9c4e60 Compare February 1, 2023 11:34
@quarkus-bot

This comment has been minimized.

@Sgitario Sgitario marked this pull request as draft February 1, 2023 14:50
@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 1, 2023

Something really odd is happening with the dekorate logic that orders the decorators to be run.
In spite of the CI being green, these changes are consistently not working on my local machine. On the other hand, the changes that indeed fix the actual issue locally do not work for the CI. so, we need further investigation here. Moving to Draft.

@iocanel
Copy link
Contributor

iocanel commented Feb 1, 2023

Something really odd is happening with the dekorate logic that orders the decorators to be run. In spite of the CI being green, these changes are consistently not working on my local machine. On the other hand, the changes that indeed fix the actual issue locally do not work for the CI. so, we need further investigation here. Moving to Draft.

Are you sure that tests on CI are passing? I am seeing them as skipped.
Eitherway here are some thoughts on how we could deal with it:

  • Simplify the original decorator in dekorate. The decorator seems to be quite complex due to a long fixed issue in sundrio, so we could possibly try to simplify it.
  • Fix the ordering algorithm in dekorate. The issue here is that our comparator is not transitive which is most likely what is causing our ordering issues.
  • Register a configurator that sets the right image so that no matter what decorator is run last it will use ther correct value.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 2, 2023

Something really odd is happening with the dekorate logic that orders the decorators to be run. In spite of the CI being green, these changes are consistently not working on my local machine. On the other hand, the changes that indeed fix the actual issue locally do not work for the CI. so, we need further investigation here. Moving to Draft.

Are you sure that tests on CI are passing? I am seeing them as skipped. Eitherway here are some thoughts on how we could deal with it:

  • Simplify the original decorator in dekorate. The decorator seems to be quite complex due to a long fixed issue in sundrio, so we could possibly try to simplify it.
  • Fix the ordering algorithm in dekorate. The issue here is that our comparator is not transitive which is most likely what is causing our ordering issues.
  • Register a configurator that sets the right image so that no matter what decorator is run last it will use ther correct value.

+100 It makes totally sense to fix this from the root.
I will try to use a custom configurator to do this.

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 7eaffce to 15daf5a Compare February 2, 2023 08:35
@Sgitario Sgitario marked this pull request as ready for review February 2, 2023 08:36
@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 2, 2023

I've just updated the pull request by providing a custom configurator, so we can fix this issue from the root. I reported a couple of issues in Dekorate, but not blockers.

@quarkus-bot

This comment has been minimized.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 2, 2023

It seems that dekorateio/dekorate#1147 is indeed a blocker because for some reason, it expects a build service factory (??) in Kind projects.
So, I don't know how we cannot overwrite the default container image at the moment. @iocanel can you help here please?

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 2, 2023

I'm going to confirm that this pull request #30591 introduced this issue and if so, I will revert those changes.

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 15daf5a to 46768d5 Compare February 2, 2023 11:56
@quarkus-bot

This comment has been minimized.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 2, 2023

I've just confirmed that this issue has nothing to do with #30591.
I guess this issue has been always there, and for some reason, now it's more frequent. The only fix I foresee is to fix the logic of the decorator execution at Dekorate side.

@Sgitario Sgitario force-pushed the fix_order_remove_depl_trigger branch from 46768d5 to e820786 Compare February 2, 2023 12:55
@quarkus-bot
Copy link

quarkus-bot bot commented Feb 2, 2023

Failing Jobs - Building e820786

Status Name Step Failures Logs Raw logs
JVM Tests - JDK 11 Build Failures Logs Raw logs
✔️ JVM Tests - JDK 17
JVM Tests - JDK 18 Build Failures Logs Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: integration-tests/kubernetes/quarkus-standard-way 

📦 integration-tests/kubernetes/quarkus-standard-way

io.quarkus.it.kubernetes.OpenshiftWithDockerAndImageTest.assertGeneratedResources line 46 - More details - Source on GitHub

org.assertj.core.error.AssertJMultipleFailuresError: 

[List check single element] (1 failure)

⚙️ JVM Tests - JDK 18 #

- Failing: integration-tests/kubernetes/quarkus-standard-way 

📦 integration-tests/kubernetes/quarkus-standard-way

io.quarkus.it.kubernetes.OpenshiftWithDockerAndImageTest.assertGeneratedResources line 46 - More details - Source on GitHub

org.assertj.core.error.AssertJMultipleFailuresError: 

[List check single element] (1 failure)

@iocanel
Copy link
Contributor

iocanel commented Feb 2, 2023

I've just confirmed that this issue has nothing to do with #30591. I guess this issue has been always there, and for some reason, now it's more frequent. The only fix I foresee is to fix the logic of the decorator execution at Dekorate side.

I think that issue was always there but only manifests itself under certain decorator combinations.
I agree that the best course of action, is to deal with the issue in the dekorate side. I'll be able to work on that later today.

@Sgitario
Copy link
Contributor Author

Sgitario commented Feb 3, 2023

Closing as this will be addressed in Dekorate.

@Sgitario Sgitario closed this Feb 3, 2023
@quarkus-bot quarkus-bot bot added the triage/invalid This doesn't seem right label Feb 3, 2023
gsmet added a commit to gsmet/quarkus that referenced this pull request Feb 3, 2023
Related to quarkusio#30768
I don't know why but it's failing systematically in the jakarta-rewrite
branch and I don't want it to be in the way of the migration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubernetes triage/invalid This doesn't seem right
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants