Skip to content

WFCORE-6995 Allow stability-specific resource transformations for mixed domains #6214

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

pferraro
Copy link
Contributor

@pferraro pferraro commented Oct 11, 2024

https://issues.redhat.com/browse/WFCORE-6995

Submitting as a draft while I collect feedback and add tests.

@yersan Until https://github.com/wildfly/wildfly-legacy-test publishes releases for WildFly versions, it will be impossible to create model transformation tests for COMMUNITY stability.

@pferraro pferraro requested a review from yersan October 16, 2024 09:14
@pferraro pferraro force-pushed the WFCORE-6995 branch 3 times, most recently from 7be71fb to e05436b Compare October 17, 2024 19:31
@wildfly-ci

This comment was marked as off-topic.

@wildfly-ci
Copy link

Core -> WildFly Preview Integration Build 14066 outcome was FAILURE using a merge of e05436b
Summary: Tests passed: 5009, ignored: 58; exit code 1 (Step: Build & test full (Maven)) Build time: 02:48:20

@pferraro pferraro marked this pull request as ready for review October 18, 2024 14:35
@wildfly-ci
Copy link

Core -> WildFly Preview Integration Build 14067 outcome was FAILURE using a merge of e05436b
Summary: Exit code 1 (Step: Build & test full (Maven)) Build time: 00:05:30

@wildfly-ci

This comment was marked as off-topic.

Copy link

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@wildfly-ci
Copy link

Core -> Full Integration Build 14427 outcome was UNKNOWN using a merge of c997c15
Summary: Canceled (Error while applying patch; cannot find commit c7edee2 in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/6214/merge branch was updated and the commit selected for the ... Build time: 00:00:34

@wildfly-ci
Copy link

Core -> Full Integration Build 14126 outcome was UNKNOWN using a merge of c997c15
Summary: Canceled (Error while applying patch; cannot find commit c7edee2 in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/6214/merge branch was updated and the commit selected for the ... Build time: 00:00:15

@wildfly-ci
Copy link

Core -> WildFly Preview Integration Build 14208 outcome was UNKNOWN using a merge of c997c15
Summary: Canceled (Error while applying patch; cannot find commit c7edee2 in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/6214/merge branch was updated and the commit selected for the ... Build time: 00:00:15

@github-actions github-actions bot removed the Stale label Dec 17, 2024
Copy link

github-actions bot commented Feb 1, 2025

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label Feb 1, 2025
Copy link
Collaborator

@yersan yersan left a comment

Choose a reason for hiding this comment

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

Just added comments, I do not have the expertise on transformers API to validate the work done here, it should be fine since the BasicResourceTestCase explicitly tests all of those transformations, but I got the impression there is still pending work to do to enable the server to use the expected stability level when it is registering the transformers, that;s still a bit unclear to me

Comment on lines +45 to +50
for (E model : EnumSet.complementOf(EnumSet.of(this.currentSubsystemModel))) {
ModelVersion version = model.getVersion();
ResourceTransformationDescriptionBuilder builder = registration.createResourceTransformationDescriptionBuilder();
this.transformation.accept(builder, version);
TransformationDescription.Tools.register(builder.build(), registration, version);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we have an example of how to use this class?

I'm not a SME in these transformers and it is too big to digest it easily, but I guess what I cannot see is how this new way to register the transformers will be able to match what we currently have. At this moment, transformers are registered as a chain, with a common builder that registers the transformation from one version to another, however here we are only registering a single version with a specific builder, so I get lost on this.

Comment on lines +293 to 296
@Deprecated(forRemoval = true)
public static TransformerRegistry create() {
return new TransformerRegistry();
return create(Stability.DEFAULT);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

What happens with the current usage of this method in our code? Shouldn't we at least force the creation of a transformer registry using a specific Stability level? Otherwise, we will continue using the wrong registry and we won't be able yet to add specific transformations to the subsystems.

Comment on lines +69 to +74
ChainedTransformationDescriptionBuilderFactory factory = KernelAPIVersion.createChainedTransformationDescriptionBuilderFactory(registry);
registerChainedManagementTransformers(registry, factory);
registerChainedServerGroupTransformers(registry, factory);
registerProfileTransformers(registry);
registerSocketBindingGroupTransformers(registry);
registerDeploymentTransformers(registry);
registerSocketBindingGroupTransformers(registry, factory);
registerDeploymentTransformers(registry, factory);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why we are only changing the Domain Transformers? Shouldn't we also change and adapt in this PR how we are registering the other transformers?

For example, at ElytronSubsystemTransformers we have:

@Override
    public void registerTransformers(SubsystemTransformerRegistration registration) {
        ChainedTransformationDescriptionBuilder chainedBuilder = TransformationDescriptionBuilder.Factory.createChainedSubystemInstance(registration.getCurrentSubsystemVersion());

What would be the equivalent code to create ChainedTransformationDescriptionBuilder using the current Stability level?

Copy link

github-actions bot commented Apr 1, 2025

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label Apr 1, 2025
@pferraro
Copy link
Contributor Author

pferraro commented Apr 2, 2025

Bump (to prevent github autoclose)

@github-actions github-actions bot removed the Stale label Apr 3, 2025
Copy link

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label May 18, 2025
@pferraro
Copy link
Contributor Author

Bump (to prevent github autoclose). @bstansberry Are we still interested in this? If so, can you take a look?

Copy link
Contributor

@bstansberry bstansberry left a comment

Choose a reason for hiding this comment

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

@pferraro I had a look and made comments. I think Yeray's earlier are the more critical ones.

Re whether we are interested in this, TBH I'm relying on you and @yersan to tell me. I think we are because in all the discussions about it we keep working on it and I think we'd stop if we decided not to do it. ;) But the details of the back-and-forth are flushed from memory, partly because I'm relying on you guys.

for (String attribute : rejectedAttributes) {
registry.addAttributeCheck(attribute, rejectChecker);
for (String rejectedAttribute : rejectedAttributes) {
this.registry.addAttributeCheck(rejectedAttribute, rejectChecker);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this method be deprecated? Just reading the diff it seems like it's unable to apply the desired 'enables' check so it's just assuming. Which is ok temporarily but perhaps should be deprecated.

It seems like the javadoc in the interface should explain the behavior re the 'enables' call for all the methods.

}
return thisBuilder();
}

@Override
public T addRejectChecks(List<RejectAttributeChecker> rejectCheckers, String... rejectedAttributes) {
for (RejectAttributeChecker rejectChecker : rejectCheckers) {
addRejectCheck(rejectChecker, rejectedAttributes);
this.addRejectCheck(rejectChecker, rejectedAttributes);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re deprecation.

public T addRenames(Map<String, String> renames) {
for (Map.Entry<String, String> rename : renames.entrySet()) {
registry.addRenamedAttribute(rename.getKey(), rename.getValue());
this.addRename(rename.getKey(), rename.getValue());
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re deprecation.

@@ -131,10 +132,6 @@ public T setValueConverter(AttributeConverter attributeConverter, String... conv
return thisBuilder();
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re deprecation.

*/
ResourceTransformationDescriptionBuilder addChildResource(ResourceDefinition definition);
@Deprecated(forRemoval = true)
Copy link
Contributor

Choose a reason for hiding this comment

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

Note to reviewers: I only see 5 uses of this in WF, all in the legacy Picketbox extensions.

*/
ResourceTransformationDescriptionBuilder addChildResource(ResourceDefinition definition, DynamicDiscardPolicy dynamicDiscardPolicy);

@Deprecated(forRemoval = true)
Copy link
Contributor

Choose a reason for hiding this comment

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

Note to reviewers: I don't see any uses of this in WF.

*/
@Deprecated(forRemoval = true)
Copy link
Contributor

Choose a reason for hiding this comment

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

Note to reviewers: I see no use in WF.

@github-actions github-actions bot removed the Stale label May 23, 2025
@yersan
Copy link
Collaborator

yersan commented May 28, 2025

@pferraro I had a look and made comments. I think Yeray's earlier are the more critical ones.

Re whether we are interested in this, TBH I'm relying on you and @yersan to tell me. I think we are because in all the discussions about it we keep working on it and I think we'd stop if we decided not to do it. ;) But the details of the back-and-forth are flushed from memory, partly because I'm relying on you guys.

This is something good to have, since it will allow us to test community-community paired stability levels in mixed domains. I don't see it as something urgent to do; I have never read issues with mixed domains on the community side, so, probably something that is not widely used. It brings up more maintenance, and the fix indeed looks complex. However, having those tests in practice is good and necessary. It will also help later to future promotions by moving a feature from community stability to a higher one.

@pferraro I don't know how complex this would end up at the end, not only on the solution but also on the future maintenance, so if you still have doubts whether this is necessary, I would be fine because I don't think this scenario is widely used in upstream.

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.

4 participants