Proposal to update WildFly download distributions using channels #577
Conversation
|
@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). |
| 4. Run a script in the existing WildFly installation to update if from x.y.z to x.y.(z+1) | ||
| 5. Reload the server to run your applications on WildFly x.y.(z+ 1) | ||
|
|
||
| If there are multiple available updates for WildFly, the user must be able to decide which one they want to update to. |
There was a problem hiding this comment.
Just a note - that would be a new requirement for prospero, not something that is currently supported.
There was a problem hiding this comment.
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
|
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
force-pushed
the
wildfly_channel_in_zips
branch
from
bf87858
to
502123e
Compare
I update the proposal to address some of the questions you raise. For WildFly 33, I agree that we will not be able to address the tooling aspect of the proposal. 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. |
jmesnil
force-pushed
the
wildfly_channel_in_zips
branch
from
502123e
to
56957e7
Compare
jmesnil
force-pushed
the
wildfly_channel_in_zips
branch
from
6278630
to
32991d6
Compare
|
|
||
| WildFly must contain the tooling to let user update installations without having to download another piece of software. | ||
|
|
||
| The tooling should be made available in the `bin` directory of this installation and affects only the parent directory (`JBOSS_HOME` would have no bearing for update). |
There was a problem hiding this comment.
We should keep JBoss CLI and HAL in sync with those new capabilities.
There was a problem hiding this comment.
FYI on tooling alignment (especially HAL and JBoss CLI) I have a discussion here about a change I will be proposing against the proposals repo.
Overall based on the stability level of a new feature I am proposing different levels of support in the tooling so features can come it at a lower level maybe without tooling support and then get the tooling support added, then promote the feature to a higher stability level.
A general exception however would be where a feature is dependent on the tooling support entierely, i.e. if you can not use it without the JBoss CLI or HAL then one must support it at the outset - assuming the developers on those projects are available to assist.
| ** The user MUST specify the updates to apply. | ||
| ** As this feature is experimental, the tooling should warn the user that updating their installation is an experimental mechanism | ||
| ** these operations will be using Prospero that needs to be integrated as a JBoss module in the WildFly distributions. | ||
| * Updates must not discard any user changes to an installation (in their configuration files or JBoss modules directory) |
There was a problem hiding this comment.
Note - currently the files under modules/system are considers "system-path" and Galleon updates take precedence over user changes
There was a problem hiding this comment.
I think that's fine. We don't support users modifying system modules, so if they do they can't use this feature.
| * https://github.com/wildfly/wildfly[WildFly] | ||
| ** WildFly distributions will incorporate channel metadata used to create the distributions and tooling to update the installation to a more recent version. | ||
| * https://github.com/wildfly-extras/prospero[Prospero] | ||
| ** Prospero will be used as the library to update WildFly installations but will not surface to the user (the `installation-manager` script is the user entry point) |
There was a problem hiding this comment.
I'm not sure I understand why we need a new entry point script (installation-manager) instead of the script shipped with Prospero?
If we don't want to expose Prospero script to the users, maybe we should use the JBoss CLI/Web Console integration?
| To make it a `preview` or `community` feature, we will pay attention to the user experience. In particular, the distributions should be "self-updatable" and should not need | ||
| to rely on the external download of Prospero to be updated. Promotion to `preview` or `community` would involve the integration of Prospero library into WildFly (as a JBoss module or a separate feature pack). The user interface could also be directly the `prospero` cli tool, a streamlined CLI focused on updates, or additional commands provided within `jboss-cli` tool. | ||
|
|
||
| === Implementation Plan |
There was a problem hiding this comment.
Should the implementation plan mention the new module(s) created to include Prospero libraries?
|
|
||
| === Stability Level | ||
|
|
||
| * [x] Experimental |
There was a problem hiding this comment.
I have only had a very fast scan so sorry if I jumped over it, if this is an experimental feature - how does a user turn on this experimental feature / acknowledge that they are using an experimental feature rather than assuming it is a community feature?
|
|
||
| == Overview | ||
|
|
||
| WildFly now publishes https://repo1.maven.org/maven2/org/wildfly/channels/[channels] that is a mechanism to keep a WildFly installation up to date with the latest releases. |
|
|
||
| WildFly now publishes https://repo1.maven.org/maven2/org/wildfly/channels/[channels] that is a mechanism to keep a WildFly installation up to date with the latest releases. | ||
|
|
||
| This works out of the box if users is provisioning WildFly (using the https://github.com/wildfly/wildfly-maven-plugin[wildfly-maven-plugin] or https://github.com/wildfly-extras/prospero[Prospero]). |
There was a problem hiding this comment.
s/users is/users are/g
|
|
||
| The http://docs.wildfly.org/wildfly-proposals/build/WFLY-19130_publish_Wildfly_channel_manifest.html[Analysis Document for WFLY-19130] states that the channels publish the latest manifest with no backwards compatibility guarantee, meaning each channel will always contain components of the latest released version of WildFly. | ||
|
|
||
| There are no guarantee that the channel will not break between major releases of WildFly. |
There was a problem hiding this comment.
s/guarantee/guarantees
| Updating to a more recent version is a user decision and would require the user to give as input the version of the WildFly they want to _update to_ (e.g. `33.0.1.Final` or `34.0.0.Final`). | ||
| After the update is successful, the channel metadata would be updated to point to the current version of the installation. | ||
|
|
||
| WildFly must contain the tooling to let user update installations without having to download another piece of software. |
| ** After their confirmation, the update is applied and the installation state changes | ||
| ** After the update, the provisioned version of the installation is the more recent version that was applied | ||
|
|
||
| Since https://issues.redhat.com/browse/WFCORE-6206[WFCORE-6206], there is `installation-manager` script that is meant for internal usage. This script could be repurposed to provide these operations to the user. |
| === Test Plan for WFLY-19221 - [Preview] Incorporate channel metadata in the download zips | ||
|
|
||
| * Verify that WildFly generated distributions (from the `dist`, `ee-dist`, and `preview-dist` Maven Modules) contain the channel metadata files corresponding to their provisioning states. | ||
|
|
There was a problem hiding this comment.
We have the testsuite/galleon tests which test updating an installation using Galleon tooling. It seems like we could expand this to cover this update mechanism.
| === Non-Requirements | ||
|
|
||
| * Changing the type of distributions during an update is not supported (in other words, it is not possible to download the zip for WildFly 33.0.0.Final and update the installation to WildFly Preview) | ||
| * Trimming an existing installation coming from WildFly distributions with Galleon layers is not supported. |
There was a problem hiding this comment.
This is fine but it gets me thinking about a related scenario. Is the installation-manager.sh script present in a slimmed server? If it is, what happens when the user uses it?
There was a problem hiding this comment.
If the slimming is achieved using Galleon and recorded in the .galleon/provisioning.xml, Prospero should only update the components in the slimmed installation.
Or do you mean a scenario where the slimmed installation does not include Prospero modules?
There was a problem hiding this comment.
@spyrkob Both I suppose. TBH I don't recall what I was thinking when I asked this.
There was a problem hiding this comment.
I think currently the installation-manager.sh is always provisioned even if the installation.manager package is not present, but I'm not sure if it's possible to exclude that package, maybe @yersan can confirm.
|
|
||
| * Changing the type of distributions during an update is not supported (in other words, it is not possible to download the zip for WildFly 33.0.0.Final and update the installation to WildFly Preview) | ||
| * Trimming an existing installation coming from WildFly distributions with Galleon layers is not supported. | ||
|
|
There was a problem hiding this comment.
@spyrkob has mentioned the CLI and the console. If the decision is to not include those, they should be listed as non-requirements as the basic assumption if nothing is said should be consistency across tools.
| This feature is `experimental`. | ||
|
|
||
| To make it a `preview` or `community` feature, we will pay attention to the user experience. In particular, the distributions should be "self-updatable" and should not need | ||
| to rely on the external download of Prospero to be updated. Promotion to `preview` or `community` would involve the integration of Prospero library into WildFly (as a JBoss module or a separate feature pack). The user interface could also be directly the `prospero` cli tool, a streamlined CLI focused on updates, or additional commands provided within `jboss-cli` tool. |
There was a problem hiding this comment.
The first two sentences in this paragraph contradict the requirements.
|
|
||
| === Default Configuration | ||
|
|
||
| Updating an installation could update its default configuration (e.g. if the update is to a major version). |
jmesnil
force-pushed
the
wildfly_channel_in_zips
branch
4 times, most recently
from
50faff1
to
158156e
Compare
Signed-off-by: Jeff Mesnil <[email protected]>
Signed-off-by: Jeff Mesnil <[email protected]>
Signed-off-by: Jeff Mesnil <[email protected]>
Signed-off-by: Jeff Mesnil <[email protected]>
Signed-off-by: Jeff Mesnil <[email protected]>
Signed-off-by: Jeff Mesnil <[email protected]>
jmesnil
force-pushed
the
wildfly_channel_in_zips
branch
from
158156e
to
7772bf5
Compare
github-actions
bot
added
the
stability-level/experimental
Signed-off-by: Jeff Mesnil <[email protected]>
github-actions
bot
added
stability-level/experimental
Signed-off-by: Jeff Mesnil <[email protected]>
github-actions
bot
added
stability-level/experimental
No description provided.