-
Notifications
You must be signed in to change notification settings - Fork 464
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
[WFCORE-6893] Add information to product-info #6070
base: main
Are you sure you want to change the base?
Conversation
@yersan could you take a look at this? I created a hidden/private operation handler for the installation manager history that is called from both the |
Core -> WildFly Preview Integration Build 13733 outcome was FAILURE using a merge of dacd47c |
Core -> Full Integration Build 13661 outcome was FAILURE using a merge of dacd47c |
Core -> Full Integration Build 13948 outcome was FAILURE using a merge of dacd47c |
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.
@spyrkob I'm going to pick up this work and try to find an approach that does not require splitting the history handler into two versions
import static org.jboss.as.controller.descriptions.ModelDescriptionConstants.CORE_SERVICE; | ||
|
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.
Static import is out of order, they go at the beginning. I thought this was described in our IDE templates, but I have not found it. So, could you check your IDE and use the following import order:
static imports
blank line
import java.*
blank line
import javax.*
blank line
import jakarta.*
blank line
Other imports alphabetically
OperationEntry installerOpEntry = context.getRootResourceRegistration().getOperationEntry(installerAddress, "history-runtime"); | ||
context.addStep(installerOpEntry.getOperationHandler(), OperationContext.Stage.RUNTIME); |
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.
We have to find a better approach that does not require splitting the history handle into "history-runtime" and "history", both handlers do the same, in addition, the InstallationReportHandler.java host version uses history and the server version the history-handler. I'll take a closed look to find a better approach.
|
||
@Override | ||
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { | ||
try { |
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 for yuour info, even if this operation has the .setRuntimeOnly()
flag, this execute method is executed at Model stage.
Finally, it was decided to use |
@yersan should Il keep this as draft until the installation-manager 1.0.3.Final is out and update it in this PR? |
Core -> Full Integration Build 13668 outcome was FAILURE using a merge of bd81049 |
Core -> Full Integration Build 13955 outcome was FAILURE using a merge of bd81049 |
Core -> WildFly Preview Integration Build 13740 outcome was FAILURE using a merge of bd81049 |
@spyrkob Ideally yes, we can release installation-manager once we test this PR together with Prospero. Then we bump it on wildfly core and this would be rebased so we can proceed with the merge. We would need to test the operation when Prospero (or the installation manager test version) is enabled |
@spyrkob Talking about testing strategy, this is what we have so far:
Share your feedback if you see a better testing strategy, real provisioning with Prospero for testing seems more tricky since this is only WildFly Core and we do not want to be tight to one Prospero version, here we are only testing until the Prospero API invocation. |
@yersan I added tests to check that the correct information is added to the product info and installer history. I based the integration tests for standalone mode on the existing domain tests. I'm not sure if there's a better way to avoid the code duplication between the two |
Core -> Full Integration Build 13961 outcome was FAILURE using a merge of 8b38f17 |
Core -> WildFly Preview Integration Build 13746 outcome was FAILURE using a merge of 8b38f17 |
Core -> Full Integration Build 13674 outcome was FAILURE using a merge of 8b38f17 |
@spyrkob I think it could have been enough by just adding the It is good to get both covered though, but if we do it, I guess we should remove the duplication (which can be done later). We can use this directory https://github.com/wildfly/wildfly-core/tree/main/testsuite/shared/src/main/java/org/wildfly/test/installationmanager to place a base class that accepts a list of host names and inherit both test claasses from that base class, the domain one will add the hosts to the test methods. It is ok to me if this is done after this fix, I leave it up to you. If not we can create a Jira to do it later. |
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.
Looks good to me, there are two minor details, the one about test duplicity, up to you can be done later, and the minor about the date format of the timestamp.
I'm going to merge and release the one of the installation manager API, to get it later available here
List<ModelNode> result = Operations.readResult(installerInfo).asList(); | ||
for (ModelNode installerAtt : result) { | ||
if (installerAtt.has("timestamp")) { | ||
return installerAtt.get("timestamp").asString(); |
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.
We should keep the format given by the legacy tool:
wildfly-core/patching/src/main/java/org/jboss/as/patching/runner/PatchUtils.java
Line 200 in 69e4d2a
return DateFormat.getInstance().format(new Date()); |
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.
OK that probably should happen in InstMgrHistoryHandler, in the Reporter it's too late - we already have a text value
This comment was marked as outdated.
This comment was marked as outdated.
/retest |
This comment was marked as outdated.
This comment was marked as outdated.
e921710
to
ff49019
Compare
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
Issue: https://issues.redhat.com/browse/WFCORE-6893
Note: Setting as draft, because it requires wildfly-extras/wildfly-installation-manager-api#21
Related: wildfly-extras/prospero#720