[JBoss JIRA] (WFLY-12134) Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules
by Andreas Weise (Jira)
[ https://issues.redhat.com/browse/WFLY-12134?page=com.atlassian.jira.plugi... ]
Andreas Weise commented on WFLY-12134:
--------------------------------------
Integration of infinispan-clustered-counter via Module also has issues due to CounterModuleLifecycle hooking up to early (https://github.com/infinispan/infinispan/blob/master/counter/src/main/jav...). It tries to access internal caches, but infinispan subsystem did not load them yet - as not referenced. Seems some piece is missing to coordinate clustered-counter with infinispan subsystem properly.
would be great to see progress here.
however instead of using a module we found a hacky workaround for embedding infinispan-clustered-counter in an application (tested on WFLY19):
{noformat}
@Resource(name = "infinispan/container/my-container")
private EmbeddedCacheManager cacheManager;
public executeCounterStuff() {
// create counter manager from cache manager
final EmbeddedCounterManager counterManager = createCounterManager();
counterManager.defineCounter("c1",
CounterConfiguration
.builder(CounterType.UNBOUNDED_STRONG)
.build());
final StrongCounter c1 = counterManager.getStrongCounter("c1");
c1.addAndGet(...);
// stop the counter manager
counterManager.stop();
}
private EmbeddedCounterManager createCounterManager() {
// initialize CounterMetadataFileFinder and CounterModuleLifecycle SPIs
// manually on org.infinispan.factories.GlobalComponentRegistry
final GlobalComponentRegistry gcr = cacheManager.getGlobalComponentRegistry();
gcr.getComponentMetadataRepo().initialize(
Arrays.asList(new CounterMetadataFileFinder()),
CounterManager.class.getClassLoader());
new CounterModuleLifecycle().cacheManagerStarting(gcr, cacheManager.getCacheManagerConfiguration());
// create and start the counter manager
final EmbeddedCounterManager counterManager = (EmbeddedCounterManager) EmbeddedCounterManagerFactory.asCounterManager(cacheManager);
counterManager.start();
return counterManager;
}
{noformat}
Assuming the custom infinispan cache container (and its default cache) were configured in infinispan subsystem and referenced in web.xml like this
{noformat}
<resource-env-ref>
<resource-env-ref-name>infinispan/container/my-container</resource-env-ref-name>
<resource-env-ref-type>org.infinispan.manager.CacheContainer</resource-env-ref-type>
<lookup-name>java:jboss/infinispan/container/my-container</lookup-name>
</resource-env-ref>
<resource-env-ref>
<resource-env-ref-name>infinispan/cache/my-container/default</resource-env-ref-name>
<resource-env-ref-type>org.infinispan.Cache</resource-env-ref-type>
<lookup-name>java:jboss/infinispan/cache/my-container/default</lookup-name>
</resource-env-ref>
{noformat}
> Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12134
> URL: https://issues.redhat.com/browse/WFLY-12134
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 17.0.0.Beta1
> Reporter: Sergey Aganin
> Assignee: Paul Ferraro
> Priority: Major
>
> Please add the modules such that users can use the new features of Infinispan.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12356) remoting subsystem's http-connector is missing capability reference
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-12356?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-12356:
-------------------------------------
[~flavia.rainone] Are you working on this issue?
Thanks
> remoting subsystem's http-connector is missing capability reference
> -------------------------------------------------------------------
>
> Key: WFLY-12356
> URL: https://issues.redhat.com/browse/WFLY-12356
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 17.0.1.Final
> Reporter: Radoslav Husar
> Assignee: Flavia Rainone
> Priority: Major
> Labels: ux
>
> http-remoting-connector is missing capability reference to the undertow connector.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=connector-ref,value=foo)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> results in a cryptic error
> {noformat}
> 11:33:01,792 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings, service org.wildfly.ejb.remote]
> WFLYCTL0448: 5 additional services are down due to their dependencies being missing or failed
> 11:33:15,334 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.ejb.association (new available)
> service jboss.ejb.remoting.connector.client-mappings (new available)
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (no longer required)
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (new available)
> service org.wildfly.clustering.cache.registry-factory.ejb.client-mappings (new available)
> service org.wildfly.clustering.group.ejb (new available)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-316) Different behaviour of ADMIN_PASSWORD and securing management interface
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-316?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-316:
--------------------------------------------
I am questioning myself on this test. By default, the CLI allows unsecure local access. The test provides --no-local-auth to disable this local access and expects to successfully connect when no password is set. I would be ok to fix the SASL access, but shouldn't we keep it secured and just allow local access for the CLI? So fix the test to not use --no-local-auth when no password is set?
> Different behaviour of ADMIN_PASSWORD and securing management interface
> -----------------------------------------------------------------------
>
> Key: WFWIP-316
> URL: https://issues.redhat.com/browse/WFWIP-316
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> With XP image started to fail test where {{ADMIN_PASSWORD}} env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
> Seems in other images CD, 7.3.0.GA (with legacy security in place) when {{ADMIN_PASSWORD}} was empty management interface was left unsecured.
> Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12549) mp.metrics.tags does not work when specified in MP config subsystem
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-12549?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-12549:
-------------------------------------
[~jmesnil] Are you working on this issue?
Thanks,
Parul
> mp.metrics.tags does not work when specified in MP config subsystem
> -------------------------------------------------------------------
>
> Key: WFLY-12549
> URL: https://issues.redhat.com/browse/WFLY-12549
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 18.0.0.Beta1
> Reporter: Richard DiCroce
> Assignee: Jeff Mesnil
> Priority: Major
>
> Section 3.1.2 of the MP Metrics spec states:
> {quote}
> Tags can be supplied in two ways:
> ...
> At the application server level by using MicroProfile Config and setting a configuration property of the name mp.metrics.tags.
> {quote}
> This does not work in WildFly if the property is configured inline in the Microprofile Config subsystem like this:
> {code}
> <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
> <config-source name="props">
> <property name="mp.metrics.tags" value="foo=bar"/>
> </config-source>
> </subsystem>
> {code}
> Workaround: specify it under <system-properties> instead. This works as expected:
> {code}
> <system-properties>
> <property name="mp.metrics.tags" value="foo=bar"/>
> </system-properties>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-316) Different behaviour of ADMIN_PASSWORD and securing management interface
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-316?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFWIP-316:
------------------------------------
CC: [~jdenise]
> Different behaviour of ADMIN_PASSWORD and securing management interface
> -----------------------------------------------------------------------
>
> Key: WFWIP-316
> URL: https://issues.redhat.com/browse/WFWIP-316
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> With XP image started to fail test where {{ADMIN_PASSWORD}} env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
> Seems in other images CD, 7.3.0.GA (with legacy security in place) when {{ADMIN_PASSWORD}} was empty management interface was left unsecured.
> Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-316) Different behaviour of ADMIN_PASSWORD and securing management interface
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-316?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-316:
-------------------------------
Description:
With XP image started to fail test where {{ADMIN_PASSWORD}} env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
Seems in other images CD, 7.3.0.GA (with legacy security in place) when {{ADMIN_PASSWORD}} was empty management interface was left unsecured.
Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
was:
With XP image started to fail test where `ADMIN_PASSWORD` env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
Seems in other images CD, 7.3.0.GA (with legacy security in place) when `ADMIN_PASSWORD` was empty management interface was left unsecured.
Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
> Different behaviour of ADMIN_PASSWORD and securing management interface
> -----------------------------------------------------------------------
>
> Key: WFWIP-316
> URL: https://issues.redhat.com/browse/WFWIP-316
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> With XP image started to fail test where {{ADMIN_PASSWORD}} env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
> Seems in other images CD, 7.3.0.GA (with legacy security in place) when {{ADMIN_PASSWORD}} was empty management interface was left unsecured.
> Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-316) Different behaviour of ADMIN_PASSWORD and securing management interface
by Martin Choma (Jira)
Martin Choma created WFWIP-316:
----------------------------------
Summary: Different behaviour of ADMIN_PASSWORD and securing management interface
Key: WFWIP-316
URL: https://issues.redhat.com/browse/WFWIP-316
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Jeff Mesnil
With XP image started to fail test where `ADMIN_PASSWORD` env var is empty. Because test is expecting management interface to be unsecured in that case. But this does not happen and management interface is secured with SASL authentication factory. Test is using CLI so it is SASL which is used for accessing management interface.
Seems in other images CD, 7.3.0.GA (with legacy security in place) when `ADMIN_PASSWORD` was empty management interface was left unsecured.
Seems to me we should be consistent between legacy security and Elytron approach of securing OpenShift images.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-315) XP OpenShift image http management interface secured with no user by default
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-315?page=com.atlassian.jira.plugin... ]
Martin Choma closed WFWIP-315.
------------------------------
Resolution: Explained
> XP OpenShift image http management interface secured with no user by default
> ----------------------------------------------------------------------------
>
> Key: WFWIP-315
> URL: https://issues.redhat.com/browse/WFWIP-315
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: standalone-openshift.cd19.xml, standalone-openshift.xp.xml
>
>
> In one test with XP image [1] I am experiencing problem of failing rediness probe.
> {code}
> sh-4.2$ python -d /opt/eap/bin/probes/runner.py --debug -c READY --loglevel=DEBUG probe.eap.dmr.EapProbe probe.eap.dmr.HealthCheckProbe
> DEBUG:__main__:Starting probe runner with args: Namespace(check=[<Status.READY: 8>], debug=True, logfile=None, loglevel='DEBUG', probes=['probe.eap.dmr.EapProbe', 'probe.eap.dmr.HealthCheckProbe'])
> INFO:__main__:Loading probe: probe.eap.dmr.EapProbe
> DEBUG:probe.eap.dmr.EapProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
> INFO:__main__:Loading probe: probe.eap.dmr.HealthCheckProbe
> DEBUG:probe.eap.dmr.HealthCheckProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
> INFO:__main__:Probes will fail for the following states: [HARD_FAILURE, FAILURE, NOT_READY]
> INFO:__main__:Running probes
> INFO:__main__.ProbeRunner:Running the following probes: [probe.eap.dmr.EapProbe, probe.eap.dmr.HealthCheckProbe]
> INFO:__main__.ProbeRunner:Running probe: probe.eap.dmr.EapProbe
> INFO:probe.eap.dmr.EapProbe:Executing the following tests: [probe.eap.dmr.ServerStatusTest, probe.eap.dmr.BootErrorsTest, probe.eap.dmr.DeploymentTest]
> INFO:probe.eap.dmr.EapProbe:Sending probe request to http://localhost:9990/management
> DEBUG:probe.eap.dmr.EapProbe:Probe request = {
> "operation": "composite",
> "json.pretty": 1,
> "steps": [
> {
> "operation": "read-attribute",
> "name": "server-state"
> },
> {
> "operation": "read-boot-errors",
> "address": {
> "core-service": "management"
> }
> },
> {
> "operation": "read-attribute",
> "name": "status",
> "address": {
> "deployment": "*"
> }
> }
> ],
> "address": []
> }
> INFO:urllib3.connectionpool:Starting new HTTP connection (1): localhost
> DEBUG:urllib3.connectionpool:"POST /management HTTP/1.1" 403 188
> DEBUG:probe.eap.dmr.EapProbe:Probe response: <Response [403]>
> ERROR:probe.eap.dmr.EapProbe:Unexpected failure sending probe request
> Traceback (most recent call last):
> File "/s2i-output/server/bin/probes/probe/api.py", line 142, in execute
> results = self.sendRequest(request)
> File "/s2i-output/server/bin/probes/probe/dmr.py", line 97, in sendRequest
> self.failUnusableResponse(response, request, url)
> File "/s2i-output/server/bin/probes/probe/dmr.py", line 108, in failUnusableResponse
> unusable = not respDict or not respDict["outcome"] or respDict["outcome"] != "failed" or not respDict["result"]
> KeyError: 'result'
> INFO:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned statuses [FAILURE]
> DEBUG:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned messages "Error sending probe request: 'result'"
> {code}
> Note there is {{Response [403]}} which makes me think it will be related with legacy security switch with Elytron.
> When I look at CD19 standalon-openshift.xml I see by default management interface is unsecured. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is secured by legacy security ManagementRealm pointing to mgmt-users.properties
> In contrast in XP images it is secured by default by {{management-http-authentication}} which is pointing to {{mgmt-users.properties}}, which is empty by default. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is filled with that user
> {code}
> <management-interfaces>
> <http-interface http-authentication-factory="management-http-authentication" console-enabled="false">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> {code}
> I think both approaches should be consistent (no matter if legacy or Elytron). E.g. unsecured by default and secured when ADMIN_PASSWORD, ADMIN_USERNAME specified (like in case of CD19)
> [1] docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-315) XP OpenShift image http management interface secured with no user by default
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-315?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFWIP-315:
------------------------------------
Thanks to Jean-Francois it turns out it is test issue. Details here https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/....
> XP OpenShift image http management interface secured with no user by default
> ----------------------------------------------------------------------------
>
> Key: WFWIP-315
> URL: https://issues.redhat.com/browse/WFWIP-315
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: standalone-openshift.cd19.xml, standalone-openshift.xp.xml
>
>
> In one test with XP image [1] I am experiencing problem of failing rediness probe.
> {code}
> sh-4.2$ python -d /opt/eap/bin/probes/runner.py --debug -c READY --loglevel=DEBUG probe.eap.dmr.EapProbe probe.eap.dmr.HealthCheckProbe
> DEBUG:__main__:Starting probe runner with args: Namespace(check=[<Status.READY: 8>], debug=True, logfile=None, loglevel='DEBUG', probes=['probe.eap.dmr.EapProbe', 'probe.eap.dmr.HealthCheckProbe'])
> INFO:__main__:Loading probe: probe.eap.dmr.EapProbe
> DEBUG:probe.eap.dmr.EapProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
> INFO:__main__:Loading probe: probe.eap.dmr.HealthCheckProbe
> DEBUG:probe.eap.dmr.HealthCheckProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
> INFO:__main__:Probes will fail for the following states: [HARD_FAILURE, FAILURE, NOT_READY]
> INFO:__main__:Running probes
> INFO:__main__.ProbeRunner:Running the following probes: [probe.eap.dmr.EapProbe, probe.eap.dmr.HealthCheckProbe]
> INFO:__main__.ProbeRunner:Running probe: probe.eap.dmr.EapProbe
> INFO:probe.eap.dmr.EapProbe:Executing the following tests: [probe.eap.dmr.ServerStatusTest, probe.eap.dmr.BootErrorsTest, probe.eap.dmr.DeploymentTest]
> INFO:probe.eap.dmr.EapProbe:Sending probe request to http://localhost:9990/management
> DEBUG:probe.eap.dmr.EapProbe:Probe request = {
> "operation": "composite",
> "json.pretty": 1,
> "steps": [
> {
> "operation": "read-attribute",
> "name": "server-state"
> },
> {
> "operation": "read-boot-errors",
> "address": {
> "core-service": "management"
> }
> },
> {
> "operation": "read-attribute",
> "name": "status",
> "address": {
> "deployment": "*"
> }
> }
> ],
> "address": []
> }
> INFO:urllib3.connectionpool:Starting new HTTP connection (1): localhost
> DEBUG:urllib3.connectionpool:"POST /management HTTP/1.1" 403 188
> DEBUG:probe.eap.dmr.EapProbe:Probe response: <Response [403]>
> ERROR:probe.eap.dmr.EapProbe:Unexpected failure sending probe request
> Traceback (most recent call last):
> File "/s2i-output/server/bin/probes/probe/api.py", line 142, in execute
> results = self.sendRequest(request)
> File "/s2i-output/server/bin/probes/probe/dmr.py", line 97, in sendRequest
> self.failUnusableResponse(response, request, url)
> File "/s2i-output/server/bin/probes/probe/dmr.py", line 108, in failUnusableResponse
> unusable = not respDict or not respDict["outcome"] or respDict["outcome"] != "failed" or not respDict["result"]
> KeyError: 'result'
> INFO:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned statuses [FAILURE]
> DEBUG:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned messages "Error sending probe request: 'result'"
> {code}
> Note there is {{Response [403]}} which makes me think it will be related with legacy security switch with Elytron.
> When I look at CD19 standalon-openshift.xml I see by default management interface is unsecured. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is secured by legacy security ManagementRealm pointing to mgmt-users.properties
> In contrast in XP images it is secured by default by {{management-http-authentication}} which is pointing to {{mgmt-users.properties}}, which is empty by default. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is filled with that user
> {code}
> <management-interfaces>
> <http-interface http-authentication-factory="management-http-authentication" console-enabled="false">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> {code}
> I think both approaches should be consistent (no matter if legacy or Elytron). E.g. unsecured by default and secured when ADMIN_PASSWORD, ADMIN_USERNAME specified (like in case of CD19)
> [1] docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years