Proposal to update WildFly download distributions using channels

[jmesnil]

No description provided.

[jmesnil]

@bstansberry @spyrkob This proposal would encompass https://issues.redhat.com/browse/WFLY-19221 but I'd like to get the whole user story in the proposal (including the tooling aspect of it).
We would likely have to update the existing installation-manager.sh script to provide this enhancement.

[spyrkob]

Just a note - that would be a new requirement for prospero, not something that is currently supported.

[jmesnil]

as a note, it is possible to decide to which version to update by changing the manifest.maven.version in .installation/installer-channels.yaml to point to a new manifest

[spyrkob]

Currently Galleon (and consequently Prospero) will only update default configurations if there are no user changes in that configuration file. Any changes are recorded in a .new file and it's up to the user to merged those.

Is this the expected behaviour or are we going to try to merge the user changes with upcoming changes?

[jmesnil]

The existing behaviour is suitable. We would then need to drive the user to review the changes and apply them before reloading their server. wdyt?

[spyrkob]

Regarding reloading - the changes to the server have to applied while the server is down, so it's a case of starting the server again rather than reloading.

Right now prospero should display a list of such conflicts at the end of update and let the user know they might need to merge those themselves.

[bstansberry]

Thanks for this, @jmesnil. This goes well beyond WFLY-19221, which is a good thing. But it goes beyond in ways that seem unlikely to be completed by the June 26 feature freeze for WildFly 33.

So I'm not sure what we (e.g. me, you, @spyrkob) want to do re WF 33. WFLY-19221 itself establishes a kind of new contract for WF, e.g. that in our download zips there will be files in certain locations with certain content. (We somewhat already have contracts in this regard as we publish manifests that tools like wildfly-maven-plugin can use.)

If we know enough about what that contract should be, perhaps we can do something re WFLY-19221 in 33. If not, we shouldn't.

I don't think that right now we know enough, because the use case discussion here may affect things. OTOH, if there's significant value in having WFLY-19221 in 33 (e.g. to provide a base for other tooling development) it might be the case that we'd know enough a couple weeks from now, if we make that a goal of the discussion.

[jmesnil]

This goes well beyond WFLY-19221, which is a good thing. But it goes beyond in ways that seem unlikely to be completed by the June 26 feature freeze for WildFly 33.
So I'm not sure what we (e.g. me, you, @spyrkob) want to do re WF 33. WFLY-19221 itself establishes a kind of new contract for WF, e.g. that in our download zips there will be files in certain locations with certain content. (We somewhat already have contracts in this regard as we publish manifests that tools like wildfly-maven-plugin can use.)

I update the proposal to address some of the questions you raise.
The additional files are in a dotted directory, the feature itself is flagged as preview so we are not tying our hands too tightly :)

For WildFly 33, I agree that we will not be able to address the tooling aspect of the proposal.
We could limit the scope to WFLY-19221 (as a preview feature) but the full RFE will not be addressed until we have the tooling in place to effectively update WildFly.

The only advantage of having WFLY-19221 done for WildFly 33 is to be able to work incrementally and that it leaves us the full dev cycle of 34 to address the tooling aspect.

That's a weak argument so if @bstansberry or @spyrkob, you don't see another value for WFLY-19221 in itself, let's move it to WildFly 34 and do the tooling at the same time.