[WFCORE-6560] Log installation provisioning information at boot #5724

bstansberry · 2023-10-16T01:31:58Z

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

Draft for now what we log is expected to change. This just dumps what's currently available with no particular attempt at formatting.

@yersan @spyrkob FYI

spyrkob · 2023-10-16T08:45:23Z

I also added an SPI operation to expose the latest manifest name in wildfly-extras/wildfly-installation-manager-api#18 and wildfly-extras/prospero#481

yersan · 2023-10-16T13:12:54Z

installation-manager/src/main/java/org/wildfly/core/instmgr/InstMgrService.java

+                    history = installationManager.history();
+                    CONFIG_LOGGER.provisioningHistory(history);


Maybe what we could need from the history is the latest revision instead of printing all the history.

@yersan Agreed. The real intent is to use what @spyrkob was working on. My main goal with this was to just set up the infrastructure so we could quickly tweak what we actually log once the pieces for that are ready.

@yersan I added a commit dropping that history logging. And without that verbose logging don't see any need for using the org.jboss.as.config logger.

bstansberry · 2023-10-16T17:33:49Z

@yersan Will this stuff work in embedded servers / hosts? I have a vague recollection you disabled it for embedded just to narrow the scope of your work on this.

I'm not asking for any change; I'm just refreshing my memory. :) Yesterday I thought about installing the service even on embedded and just not registering the Resource and ResourceDefinition. But then I decided I wanted to keep the scope narrow for this logging as well. Logging this for embedded is a corner case we can come back to if there is demand.

bstansberry · 2023-10-16T17:45:20Z

I also added an SPI operation to expose the latest manifest name in wildfly-extras/wildfly-installation-manager-api#18 and wildfly-extras/prospero#481

@spyrkob I didn't approve those as they are draft PRs, but they LGTM.

yersan · 2023-10-17T09:30:49Z

Will this stuff work in embedded servers / hosts? I have a vague recollection you disabled it for embedded just to narrow the scope of your work on this.

Hi @bstansberry , good point there. The tool is not available there, narrowing the scope was one reason. In general:

The focus of the integration has been always the update/revert of a remote installation via CLI, we do not use embedded server/hosts to configure a remote installation.
For any kind of local installation, you should use Prospero.
You need to restart the server to perform the installation, but we do not have such a possibility in an embedded server.

Although it could be possible to circumvent the above points and allow the use of the CLI integration, for simplicity and the first cut, we disabled the usability of the installation manager in the embedded server/host.

Thinking on the embedded, as soon as we are running in a modular environment and Prospero is installed with the server, we should be able to use the factory to create an instance to get any kind of version.

We can continue avoiding registering the management resources when using the embedded process type to continue being compliant with the above points but use Prospero to compute any version info.

bstansberry · 2023-10-17T15:05:56Z

Thanks @yersan. I think for this part I'll describe having this logging in an embedded process as a 'Nice to Have', and move to 'Future Work' if we don't get to it (which is likely.)

It's easy to tweak this to support embedded, but testing it is more work, and if we don't test it having it adds risk.

bstansberry · 2023-11-30T16:02:16Z

FYI, it turns out testing this will have to happen in full WF, as the org.wildfly.prospero:wildfly-galleon-pack depends on Jackson modules only provided by the wildfly-ee FP. So I'll submit a draft component-upgrade-needed wildfly/wildfly PR for those tests, link it here and link some custom integration test runs. I'll move it out of draft when that is done.

yersan · 2023-12-01T13:25:05Z

ok, in case it helps and if you see it useful, our testing strategy for Installation Manager in WildFly Core has been using a mocked integration. It means tests in WildFly Core for the installation manager are testing until the API method invocation. Prospero also has an extended test suite that also tests the internal invocation of their own implementation. You could just use a mocked version and return something to test the functionality. Not sure if that would cope with your requirements, but that would avoid changes in WildFly full.

bstansberry · 2023-12-01T23:47:23Z

@spyrkob To test this I'll need a release of Prospero with ProsperoInstallationManager.getInstalledVersions() implemented.

wildfly-ci · 2023-12-02T03:06:37Z

Core -> Full Integration Build 13275 outcome was UNKNOWN using a merge of 90a1a1d
Summary: Canceled (Tests passed: 7195, ignored: 89; exit code 143 (Step: Build & test full (Maven)) (new)) Build time: 04:11:30

spyrkob · 2023-12-04T16:36:13Z

@bstansberry prospero 1.2.1.Final with the updated InstallationManager has just been released

bstansberry · 2023-12-06T21:29:19Z

ok, in case it helps and if you see it useful, our testing strategy for Installation Manager in WildFly Core has been using a mocked integration. It means tests in WildFly Core for the installation manager are testing until the API method invocation. Prospero also has an extended test suite that also tests the internal invocation of their own implementation. You could just use a mocked version and return something to test the functionality. Not sure if that would cope with your requirements, but that would avoid changes in WildFly full.

Thanks, @yersan -- that's very helpful. I've done exactly that in this PR, so there's no need for a test in full WF. I missed your comment and wrote a test in full WF anyway, but I don't want it merged anymore, as core is where such tests belong.

So, assuming the current CI runs are ok, this is ready to go.

wildfly-ci · 2023-12-11T14:59:51Z

Core -> Full Integration Build 13297 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) (new) Build time: 00:04:43

wildfly-ci · 2023-12-11T15:03:20Z

Core -> Full Integration Build 13068 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) (new) Build time: 00:08:13

wildfly-ci · 2023-12-11T15:03:24Z

Core -> WildFly Preview Integration Build 13137 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) (new) Build time: 00:08:17

wildfly-ci · 2023-12-11T16:36:39Z

Core -> Full Integration Build 13069 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) Build time: 00:06:31

wildfly-ci · 2023-12-11T16:41:30Z

Core -> WildFly Preview Integration Build 13138 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) Build time: 00:11:21

wildfly-ci · 2023-12-11T16:41:34Z

Core -> Full Integration Build 13298 outcome was FAILURE using a merge of bc06465
Summary: Exit code 1 (Step: Build & test full (Maven)) Build time: 00:11:30

spyrkob · 2023-12-12T09:35:53Z

installation-manager/src/main/java/org/wildfly/core/instmgr/logging/InstMgrLogger.java

@@ -81,6 +86,18 @@ public interface InstMgrLogger extends BasicLogger {
    @Message(id = 20, value = "No custom patches installed found for the specified manifest maven coordinates: '%s'")
    OperationFailedException noCustomPatchFound(String manifestGA);

+    @LogMessage(level = Logger.Level.INFO)
+    @Message(id = 21, value = "Installation provisioning is using the following channels: '%s'")


Nitpick, but I wonder if this should read something like "Installation provisioned using the following channel states/(versions?):". The ManifestVersions provide information about the latest used versions from each channel rather then channel information like manifest location, repositories etc.

Thanks @spyrkob -- good point. I went with "Installation was provisioned using the following channel versions:".

yersan · 2023-12-12T17:30:09Z

testsuite/manualmode/pom.xml

+                                        <!-- Validates content of traditional unzipped installation. (Works, but is irrelevant to bootable jar testing.) -->
+                                        <exclude>org.jboss.as.test.manualmode.provisioning.ProvisioningConsistencyTestCase</exclude>


This looks unrelated to these changes, isn't it? I am not against it, just trying to link the points.

@yersan Yes, it's unrelated. I have a bunch of branches in this general 'test provisioning' topic area and I got tired of switching back and forth. :)

Ok, thank you for confirming @bstansberry , I also wanted to be sure it was not unintentional

yersan

I'm just waiting for the minor pending questions and getting the feature progressing more before approving, but overall LGTM

github-actions · 2024-03-15T00:39:21Z

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

bstansberry · 2024-03-15T20:47:47Z

@yersan @spyrkob This change to WF isn't really a feature and doesn't need to be handled as such. So I changed the JIRA to Enhancement and removed the 'Feature' etc labels from this PR. So if you all are ok with approving it we can get it merged and out of the WIP queue.

Downstream it's part of a larger requirement set, but that's not relevant to how we need to handle it in WF.

spyrkob

LGTM

yersan · 2024-03-20T09:04:14Z

Thanks @bstansberry @spyrkob

bstansberry · 2024-04-17T21:03:11Z

A test I meant to add to this PR but neglected to push can be found at #5967

github-actions bot added the deps-ok Dependencies have been checked, and there are no significant changes label Oct 16, 2023

yersan reviewed Oct 16, 2023

View reviewed changes

bstansberry force-pushed the WFCORE-6560 branch from a3d67b8 to 16cdae3 Compare October 30, 2023 18:53

bstansberry force-pushed the WFCORE-6560 branch from 16cdae3 to 0e6e149 Compare November 30, 2023 15:51

bstansberry force-pushed the WFCORE-6560 branch 2 times, most recently from e0c1360 to 90a1a1d Compare December 1, 2023 22:52

bstansberry mentioned this pull request Dec 5, 2023

[WFLY-18817] Test that provisioning channel information is logged at boot wildfly/wildfly#17470

Closed

bstansberry force-pushed the WFCORE-6560 branch from 90a1a1d to 0e6e149 Compare December 5, 2023 18:22

wildfly deleted a comment from wildfly-ci Dec 5, 2023

bstansberry marked this pull request as ready for review December 5, 2023 18:46

bstansberry force-pushed the WFCORE-6560 branch from 0e6e149 to 9bc3ae5 Compare December 6, 2023 21:20

bstansberry force-pushed the WFCORE-6560 branch 3 times, most recently from cbdfbde to bc06465 Compare December 11, 2023 14:54

bstansberry added Feature This PR adds a new feature to WildFly missing-reqs This PR is missing external requirements before it can be merged labels Dec 11, 2023

spyrkob reviewed Dec 12, 2023

View reviewed changes

yersan reviewed Dec 12, 2023

View reviewed changes

bstansberry mentioned this pull request Dec 12, 2023

[WFLY-18578] Allow channel-based overriding of the org.jboss.as.produ… wildfly/wildfly#17248

Merged

bstansberry force-pushed the WFCORE-6560 branch from bc06465 to 8ea536b Compare December 19, 2023 02:41

This comment was marked as outdated.

Sign in to view

bstansberry force-pushed the WFCORE-6560 branch 2 times, most recently from 1776cf7 to 251db36 Compare January 29, 2024 19:49

This comment was marked as outdated.

Sign in to view

github-actions bot added the Stale label Mar 15, 2024

bstansberry added 24.x and removed Feature This PR adds a new feature to WildFly missing-reqs This PR is missing external requirements before it can be merged Stale labels Mar 15, 2024

[WFCORE-6560] Log installation provisioning information at boot

061b5fa

bstansberry force-pushed the WFCORE-6560 branch from 251db36 to 061b5fa Compare March 15, 2024 20:40

spyrkob approved these changes Mar 19, 2024

View reviewed changes

yersan approved these changes Mar 20, 2024

View reviewed changes

yersan added the ready-for-merge This PR is ready to be merged and fulfills all requirements label Mar 20, 2024

yersan merged commit 5c1b6e3 into wildfly:main Mar 20, 2024
12 checks passed

bstansberry deleted the WFCORE-6560 branch March 20, 2024 21:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WFCORE-6560] Log installation provisioning information at boot #5724

[WFCORE-6560] Log installation provisioning information at boot #5724

bstansberry commented Oct 16, 2023

spyrkob commented Oct 16, 2023

yersan Oct 16, 2023

bstansberry Oct 16, 2023

bstansberry Oct 16, 2023

bstansberry commented Oct 16, 2023

bstansberry commented Oct 16, 2023

yersan commented Oct 17, 2023 •

edited

Loading

bstansberry commented Oct 17, 2023

bstansberry commented Nov 30, 2023

yersan commented Dec 1, 2023 •

edited

Loading

bstansberry commented Dec 1, 2023

wildfly-ci commented Dec 2, 2023

spyrkob commented Dec 4, 2023

bstansberry commented Dec 6, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

spyrkob Dec 12, 2023

bstansberry Dec 19, 2023

yersan Dec 12, 2023

bstansberry Dec 12, 2023 •

edited

Loading

yersan Dec 13, 2023

yersan left a comment

This comment was marked as outdated.

This comment was marked as outdated.

github-actions bot commented Mar 15, 2024

bstansberry commented Mar 15, 2024

spyrkob left a comment

yersan commented Mar 20, 2024

bstansberry commented Apr 17, 2024

		history = installationManager.history();
		CONFIG_LOGGER.provisioningHistory(history);

		<!-- Validates content of traditional unzipped installation. (Works, but is irrelevant to bootable jar testing.) -->
		<exclude>org.jboss.as.test.manualmode.provisioning.ProvisioningConsistencyTestCase</exclude>

[WFCORE-6560] Log installation provisioning information at boot #5724

[WFCORE-6560] Log installation provisioning information at boot #5724

Conversation

bstansberry commented Oct 16, 2023

spyrkob commented Oct 16, 2023

yersan Oct 16, 2023

Choose a reason for hiding this comment

bstansberry Oct 16, 2023

Choose a reason for hiding this comment

bstansberry Oct 16, 2023

Choose a reason for hiding this comment

bstansberry commented Oct 16, 2023

bstansberry commented Oct 16, 2023

yersan commented Oct 17, 2023 • edited Loading

bstansberry commented Oct 17, 2023

bstansberry commented Nov 30, 2023

yersan commented Dec 1, 2023 • edited Loading

bstansberry commented Dec 1, 2023

wildfly-ci commented Dec 2, 2023

spyrkob commented Dec 4, 2023

bstansberry commented Dec 6, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

wildfly-ci commented Dec 11, 2023

spyrkob Dec 12, 2023

Choose a reason for hiding this comment

bstansberry Dec 19, 2023

Choose a reason for hiding this comment

yersan Dec 12, 2023

Choose a reason for hiding this comment

bstansberry Dec 12, 2023 • edited Loading

Choose a reason for hiding this comment

yersan Dec 13, 2023

Choose a reason for hiding this comment

yersan left a comment

Choose a reason for hiding this comment

This comment was marked as outdated.

This comment was marked as outdated.

github-actions bot commented Mar 15, 2024

bstansberry commented Mar 15, 2024

spyrkob left a comment

Choose a reason for hiding this comment

yersan commented Mar 20, 2024

bstansberry commented Apr 17, 2024

yersan commented Oct 17, 2023 •

edited

Loading

yersan commented Dec 1, 2023 •

edited

Loading

bstansberry Dec 12, 2023 •

edited

Loading