5:28 a.m.
Hi Brian,
On 20 Mar 2025, at 15:44, Brian Stansberry
<bstansbe(a)redhat.com> wrote:
Re the stability level, I'd like to explore the idea of using the server itself as
the control point for what features are allowed by tools.
1) The WildFly Galleon Plug has stability notions that can be used when provisioning, to
restrict the installation to functionality with a desired stability. Is this surfaced in
Prospero?
Yes when provisioning the server the user can use `--stability-level` attribute to define
the provisioned server’s stability level.
At the very beginning, Prospero of course comes before the installation, so there does
need to be some initial control of stability that's not coming from the installation.
2) This feature is about updating an existing installation. That installation was
provisioned with a particular minimum stability. Can this information be preserved in a
way that allows Prospero to use it?
Yes, the stability level is a part of the Galleon provisioning definition, it's stored
in the .galleon/provisioning.xml. Prospero has an access to that information.
I started down this line of thinking because there shouldn't be any need to start the
JBoss CLI or HAL with a particular stability level in order to control the capabilities
they expose to users. They connect to a server and can see its stability and can tailor
their behavior accordingly. For example if a CLI command or command arg is at preview
stability, don't offer it if the server is at community or default.
I guess that would be possible - the argument or operation would still be available to the
user when composing the command, but at execution time the user would get an unsupported
operation error. I’m wondering if that’d lead to some confusion for the users though if
those operations and attributes were available in the help and autocomplete but would not
work when executed on the server.
In general I wanted to explore the option to include the notion of stability levels in the
Prospero Galleon packs, so that we can provision the installer distribution at either
level, but I need to understand more about how those levels are implemented in WildFly and
Galleon to do that.
Thanks,
Bartosz
On Thu, Mar 20, 2025 at 6:41 AM Bartosz Spyrko-Smietanko via wildfly-dev
<wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> wrote:
> Hi,
>
> I filed an RFE to add support for updating to a specific manifest version to Prospero
- https://github.com/wildfly-extras/prospero/issues/754
>
> The changes are mostly to the Prospero tool, but, to keep feature parity, some
changes will need to be made to the JBoss CLI commands and Web Console as well.
>
> Since Prospero does not support stability levels, those changes need to be handled as
default level (AFAIU).
>
> Thanks,
> Bartosz
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
<mailto:wildfly-dev-leave@lists.jboss.org>
> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
> List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His