Skip to content

feat: workflow Integration with API (dependent annotations, context) #1257

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

Merged
merged 36 commits into from
Jun 9, 2022

Conversation

csviri
Copy link
Collaborator

@csviri csviri commented Jun 1, 2022

No description provided.

@csviri csviri self-assigned this Jun 1, 2022
@csviri csviri changed the title Feat: workflow Integration with API (dependent annotations, context) feat: workflow Integration with API (dependent annotations, context) Jun 1, 2022
@metacosm metacosm self-requested a review June 1, 2022 18:11
@csviri csviri force-pushed the annotation-workflow branch from e8a1c2f to 828dc09 Compare June 2, 2022 12:07
@csviri csviri force-pushed the annotation-workflow branch from 828dc09 to e1c617f Compare June 2, 2022 12:13
@csviri csviri marked this pull request as ready for review June 3, 2022 07:06
@csviri csviri marked this pull request as draft June 3, 2022 14:53
@csviri csviri marked this pull request as ready for review June 6, 2022 14:34
@csviri csviri linked an issue Jun 6, 2022 that may be closed by this pull request
@csviri csviri linked an issue Jun 6, 2022 that may be closed by this pull request
2 tasks
@@ -55,7 +55,8 @@ void resetShouldResetAllState() {
shouldBePossibleToOverrideConfigOnce();

ConfigurationServiceProvider.reset();
assertEquals(ConfigurationServiceProvider.DEFAULT, ConfigurationServiceProvider.getDefault());
assertNotEquals(ConfigurationServiceProvider.getDefault(),
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is wrong. After calling reset, we should get the default ConfigurationService.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will comment this in the code, what I wanted to achieve is that reseting it does provide a new instance of the new config, see the explanation below.

@@ -55,7 +55,8 @@ void resetShouldResetAllState() {
shouldBePossibleToOverrideConfigOnce();

ConfigurationServiceProvider.reset();
assertEquals(ConfigurationServiceProvider.DEFAULT, ConfigurationServiceProvider.getDefault());
assertNotEquals(ConfigurationServiceProvider.getDefault(),
ConfigurationServiceProvider.createDefault());
Copy link
Collaborator

Choose a reason for hiding this comment

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

Also, createDefault shouldn't be accessible from outside of the ConfigurationServiceProvider class, imo.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

A set it package private so it is testable.

private static ConfigurationService instance;
private static ConfigurationService defaultConfigurationService = DEFAULT;
private static ConfigurationService defaultConfigurationService = createDefault();
Copy link
Collaborator

Choose a reason for hiding this comment

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

What's the point of that change? See also comments on the associated test class…

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, this solves an issue with the integration tests, basically since it is singleton, it needs to be reseted after the integration tests. But if the DEFAULT is not created again (with this method in reset) , the configurations are for dependents stay in there and causes trouble. This is just for tests.

see: https://github.com/java-operator-sdk/java-operator-sdk/blob/0b7dc97de05df069e2db87384a9d1f67b3e79724/operator-framework-junit5/src/main/java/io/javaoperatorsdk/operator/junit/AbstractOperatorExtension.java#L165-L165

Copy link
Collaborator

Choose a reason for hiding this comment

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

🤔 I guess the current reset implementation is indeed wrong…

*/
@SuppressWarnings("rawtypes")
public class ManagedDependentResourceContext {
public interface ManagedDependentResourceContext {
Copy link
Collaborator

Choose a reason for hiding this comment

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

What's the point of extracting an interface here when there's only one implementation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I extracted it for the same reason, since this is a user facing interface, so the setters should not be accessible. Thus is denotes the intention as much as possible.

+ dependsOn.stream().map(d -> d.dependentResource.toString())
.collect(Collectors.joining(", ", "->[", "]"))
+ '}';
return "DependentResourceNode{" +
Copy link
Collaborator

Choose a reason for hiding this comment

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

This version of toString isn't really useful…

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Why, basically a reverted this, since you can see easily the parents and the whole structure just by looking on workflow definition. So was debugging this, and searching for issues during the development on lot's of occasions, and this was always sufficient to find the problem.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jun 9, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 23 Code Smells

63.0% 63.0% Coverage
0.5% 0.5% Duplication

@csviri csviri merged commit b439c1c into next Jun 9, 2022
@csviri csviri deleted the annotation-workflow branch June 9, 2022 13:14
@metacosm metacosm mentioned this pull request Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DependentResource and Workflow Design Details Questions Define workflows with dependent resource annotations
2 participants