[JBoss JIRA] (WFLY-12507) Create a test feature-pack for use in testing common layer combinations
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12507:
---------------------------------------
Summary: Create a test feature-pack for use in testing common layer combinations
Key: WFLY-12507
URL: https://issues.jboss.org/browse/WFLY-12507
Project: WildFly
Issue Type: Task
Components: Build System, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 18.0.0.Final
In our OpenShift images we intend to provide a number Galleon layers tailored toward handling common use cases. WFLY-12394 is about testing those use cases in the main WF testsuite. To help make that testing more robust, add a testsuite/test-feature-pack module that produces layers analogous to what will be in the images, and test those in testsuite/layers. And then the WFLY-12394 work can use those too, as opposed to using hand coded equivalents in each testsuite module.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFWIP-167:
------------------------------------
[~jmesnil] do you agree with marking "standalone.xml via ConfigMap" as unsupported for EAP 7.3 ?
> EAP Operator handling ConfigMap internally
> ------------------------------------------
>
> Key: WFWIP-167
> URL: https://issues.jboss.org/browse/WFWIP-167
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap.
> Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users.
> Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me.
> However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator.
> What do you think? Have you considered this approach?
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12506) Document purpose of each clustering module.
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12506:
-----------------------------------
Summary: Document purpose of each clustering module.
Key: WFLY-12506
URL: https://issues.jboss.org/browse/WFLY-12506
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 18.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
There are currently a large number of clustering modules within the wildfly code base. I've had to field a number of questions about the purpose and intended usage of each one, which is an indication that their function and context is not adequately documented.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12505) Ban transitive dependencies for clustering modules
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12505:
-----------------------------------
Summary: Ban transitive dependencies for clustering modules
Key: WFLY-12505
URL: https://issues.jboss.org/browse/WFLY-12505
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 18.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The purpose here is to help identify unnecessary modules dependencies in the corresponding module.xml files, as there should be a 1:1 relationship between pom dependencies and module dependencies, with the exception of dynamically loaded dependencies - most of which should be optional.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12304) Upgrade Apache Artemis from 2.9.0 to 2.10.0
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12304?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12304:
---------------------------------------
[~clebert.suconic] Im taking a look at this one. I dont rule out adding a handler. I'll keep the Jira posted. Thanks for the reproducer, [~ehugonnet]!
> Upgrade Apache Artemis from 2.9.0 to 2.10.0
> -------------------------------------------
>
> Key: WFLY-12304
> URL: https://issues.jboss.org/browse/WFLY-12304
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Reporter: Martin Stefanko
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Labels: blocker-WF18, downstream_dependency
>
> Upgrade Apache Artemis from 2.9.0.Final to 2.10.0.Final.
> Due to HA issue with Apache Artemis 2.10.0 this may not be the final version upgrade
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months