-
Notifications
You must be signed in to change notification settings - Fork 471
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
base: main
Are you sure you want to change the base?
Conversation
7be71fb
to
e05436b
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
Core -> WildFly Preview Integration Build 14066 outcome was FAILURE using a merge of e05436b |
Core -> WildFly Preview Integration Build 14067 outcome was FAILURE using a merge of e05436b |
This comment was marked as off-topic.
This comment was marked as off-topic.
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
e05436b
to
c997c15
Compare
Core -> Full Integration Build 14427 outcome was UNKNOWN using a merge of c997c15 |
Core -> Full Integration Build 14126 outcome was UNKNOWN using a merge of c997c15 |
Core -> WildFly Preview Integration Build 14208 outcome was UNKNOWN using a merge of c997c15 |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
…s using SubsystemModel enumerations.
c997c15
to
aa426d5
Compare
There was a problem hiding this 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
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); | ||
} |
There was a problem hiding this comment.
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.
@Deprecated(forRemoval = true) | ||
public static TransformerRegistry create() { | ||
return new TransformerRegistry(); | ||
return create(Stability.DEFAULT); | ||
} |
There was a problem hiding this comment.
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.
ChainedTransformationDescriptionBuilderFactory factory = KernelAPIVersion.createChainedTransformationDescriptionBuilderFactory(registry); | ||
registerChainedManagementTransformers(registry, factory); | ||
registerChainedServerGroupTransformers(registry, factory); | ||
registerProfileTransformers(registry); | ||
registerSocketBindingGroupTransformers(registry); | ||
registerDeploymentTransformers(registry); | ||
registerSocketBindingGroupTransformers(registry, factory); | ||
registerDeploymentTransformers(registry, factory); |
There was a problem hiding this comment.
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?
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
Bump (to prevent github autoclose) |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
Bump (to prevent github autoclose). @bstansberry Are we still interested in this? If so, can you take a look? |
There was a problem hiding this 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); | ||
} |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
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. |
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.