7:13 a.m.
On Fri, Mar 21, 2025 at 5:29 AM Bartosz Spyrko-Smietanko <
bspyrkos(a)redhat.com> wrote:
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.
JBoss CLI has the same issue regarding help, as its help text is static. I
think it's ok -- the static help text can just be a bit more verbose and
explain about the required stability.
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.
A quick primer:
1) 3 interfaces in the controller module org.jboss.as.contoller package --
Feature, FeatureFilter, FeatureRegistry. Particularly Feature, which
Extension, ResourceDefintion, AttributeDefinition, OperationDefinition, etc
implement, with methods in the related builders to set the stability of the
thing if it's not default. This is the mechanism to define the stability of
feature pack elements.
2) <property name="jboss.stability" value="preview"/> in a
module.xml
marks an entire module as being preview stability. This is read by Galleon
when making decisions about whether to provision the Galleon package that
represents the module. This lets us prevent unwanted bits from even being
installed.
3)
https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-feat...
-- these are feature-pack level settings. See
https://github.com/wildfly/galleon-plugins/blob/main/docs/guide/maven-plu...
for more info.
Thanks,
Bartosz
On Thu, Mar 20, 2025 at 6:41 AM Bartosz Spyrko-Smietanko via wildfly-dev <
wildfly-dev(a)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
> To unsubscribe send an email to wildfly-dev-leave(a)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
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His