February 2015 - hawkular-dev - Jboss List Archives

Fwd: [wildfly-dev] Administrator Encouragement

by Heiko W.Rupp

Interesting mail on wildfly-dev > Anfang der weitergeleiteten Nachricht: > > Datum: 5. Februar 2015 10:00:21 MEZ > Von: Darran Lofthouse <darran.lofthouse(a)jboss.com> > An: "wildfly-dev(a)lists.jboss.org" <wildfly-dev(a)lists.jboss.org> > Betreff: [wildfly-dev] Administrator Encouragement > > Last week a few of us started talking about the possibility of adding a > capability to WildFly that for want of a better name I was calling > "Administrator Encouragement". > > I am not looking for this to be a design thread, that can come later but > the general principal was that subsystems could register warnings with > some kind of central service that admin tools could then retrieve later > to advise administrators that some configuration could be required to > improve their installation. Warnings would potentially have a severity > level and tooling would potentially have the option to guide the user to > the correct place to resolve the issue. > > Anyway the purpose of this thread is that I wanted to try and gather > together the kinds of warnings that we could be outputting, below is a > list of some I have thought of already but would be interested in > hearing any additional ideas. > > - SSL is not configured. > - SSL certificates are due to expire. > - Plain text password detected in the configuration. > - Some form of file based storage in use but growing beyond intended size. > - Default node name has not been changed. > - Patches available but not applied, subsequent releases available. > > Anyway these are just a few ideas and interested in hearing any more. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters

10 years, 10 months

3
3
0 / 0

REST endpoints are multiplying

by John Mazzitelli

I see all the components implementing REST APIs. How will that scale if we cluster multiple components? Are we going to ask people to install and configure a load balancer? Is there another way to make client configuration easier? Because as I see it, unless clients are told of all the different endpoints of all the different REST servers, how will they know where to go to talk REST to these components? Even if we have load balancers, they will still need to know "here's the REST URL for alerts, here's the REST URL for metrics, here's the REST URL for inventory."

10 years, 10 months

2
2
0 / 0

define: tenant

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After the demo, I was looking for ways to improve the "realm selection modal", but I keep hitting a problem with the definition of a tenant/realm. Taking Keycloak out of the context for a while, I'd like to get *our* definition of tenant to be made. After that, I can check if we can use Keycloak as part of the authorization for this scenario (KC will probably still be part of the authentication, though). One possible solution is to have "users" and "organizations", a la Github. Users can be part of zero or more organizations and organizations have one or more members. Data (git repos or resources) belongs to either an user or an organization. For this solution, here's how I see it working on different scenarios: - - standalone/hobby user: isn't a member of any organization, but have a few resources to manage. A sample curl call: - -> http://user:password@hawkular/metrics all metrics for all resources owned by the user's main account - -> http://user:password@hawkular/resource/{resourceId}/metrics all metrics for this specific resource, which should belong to the main account - - user who creates/manages one or more organizations: can either have resources on the main account (like standalone) or have resources belonging to an organization. Sample curl call: - -> http://user:password@hawkular/metrics all metrics for all resources owned by the user's main account *or* owned by organizations where this user is a member of. - -> http://user:password@hawkular/resource/{resourceId}/metrics all metrics for this specific resource, if the resource belongs to the user or to an organization where the user is a member of For this scenario, I think the UI could be built with a "context switcher". This way, the user would have access to a dashboard with resources from his main account and could switch to a dashboard with resources from an organization. The backend, though, would not have such a notion of "context". Either the user has access to the resource or not (via the main account or via an organization). Putting Keycloak back in context: for this kind of scenario, we would have only one Keycloak realm, so, all users would be in one big realm. All of the authorization would be made on our backend(s). Upon registration (via Keycloak), an user doesn't belongs to any organization. In the future, we can consume some extra LDAP data from Keycloak, to auto assign users to some organizations, if desirable. The main disadvantage of this is that we have to also care about the authorization, as we cannot rely on permission data coming from Keycloak. The main advantage is that we get a behavior that is custom tailored to our use case. Thoughts? - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v 9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+ FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9 NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI= =IfUo -----END PGP SIGNATURE-----

10 years, 10 months

3
6
0 / 0

Cassandra & Titan

by Stefan Negrea

Hello Everybody, Aurelius (the company behind Titan graph database) has been acquired by DataStax (the main Cassandra developer company). Here are two articles around the web about the acquisition and strategic direction: http://techcrunch.com/2015/02/03/datastax-plots-aurelius-graph-database-a... http://www.zdnet.com/article/datastax-snaps-up-aurelius-and-its-titan-tea... Thank you, Stefan Negrea Software Engineer

10 years, 10 months

4
5
0 / 0

logging bug

by John Mazzitelli

Well, that didn't take long. As predicted by John "Trelawney" Sanda, in only took a few days after integrating with jboss logging that we've hit a pretty nasty javac bug. Peter and I have investigated a little and found the following that look related: https://jira.codehaus.org/browse/MCOMPILER-236 https://bugs.openjdk.java.net/browse/JDK-8067747 There are several workarounds that we've discovered: 1) Always do a mvn clean before building. If you "mvn clean install" things work. If you later to "mvn install" you will fail to build. This is "less than optimal" because it requires everyone to always clean before building thus forcing the entire project code to be recompiled each and every time. 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus modules build successfully with this, Peter says this causes other things to fail to build (IIRC, alerts was one of them). 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true." I have found either of those three work around the issue. I think #3 is probably the best, unless someone knows for sure that we need that setting to be true. FWIW: You can read about the bsc plugin options here: http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-p... - perhaps there are other settings we can set to workaround the issue?

10 years, 10 months

3
3
0 / 0

Re: [Hawkular-dev] logging bug

by John Sanda

Let me see if I understand. We could for the interim switch to a different logging framework like slf4j or logback that is widely used, mature, performant, etc in large part to avoid these problems mazz and others have hit. At some point in the future though, we once again revert back. Why? > On Feb 4, 2015, at 3:20 PM, Heiko W.Rupp <hrupp(a)redhat.com> wrote: > > Perhaps interim. But not for medium or long term. > >> Am 22.02.2015 um 20:08 schrieb John Sanda <jsanda(a)redhat.com>: >> >> At the risk of sounding like I have come unhinged, what about a fourth option? Use a simpler, yet performant solution like slf4j or logback. >> >>> On Feb 4, 2015, at 1:53 PM, John Mazzitelli <mazz(a)redhat.com> wrote: >>> >>> Well, that didn't take long. As predicted by John "Trelawney" Sanda, in only took a few days after integrating with jboss logging that we've hit a pretty nasty javac bug. >>> >>> Peter and I have investigated a little and found the following that look related: >>> >>> https://jira.codehaus.org/browse/MCOMPILER-236 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8067747 >>> >>> There are several workarounds that we've discovered: >>> >>> 1) Always do a mvn clean before building. If you "mvn clean install" things work. If you later to "mvn install" you will fail to build. This is "less than optimal" because it requires everyone to always clean before building thus forcing the entire project code to be recompiled each and every time. >>> >>> 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus modules build successfully with this, Peter says this causes other things to fail to build (IIRC, alerts was one of them). >>> >>> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true." >>> >>> I have found either of those three work around the issue. I think #3 is probably the best, unless someone knows for sure that we need that setting to be true. >>> >>> FWIW: You can read about the bsc plugin options here: http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-p... - perhaps there are other settings we can set to workaround the issue? >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht München HRB 153243 > Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters >

10 years, 10 months

2
1
0 / 0

Checkstyle javadoc settings

by Gary Brown

Hi Just started using the hawkular parent pom and noticed that the checkstyle config does not check the javadoc comments. Not sure if this was previously discussed and decided that it shouldn't be checked, but thought I had better check, as this is one area that can be time consuming to update code after enabling. Previously I had been using this config in Overlord: https://github.com/Governance/overlord-commons/blob/master/overlord-commo... Regards Gary

10 years, 10 months

7
14
0 / 0

httpclient vs okhhttp vs other

by Peter Palaga

Hi *, Heiko has proposed to add apache httpclient to parents dependency management. I countered that okhhttp is recently getting a lot of positive buzz. Please say loudly which http client you prefer to have in parent. Thanks, Peter

10 years, 10 months

5
5
0 / 0

Recoding of todays meeting wrt Sample setup and Jira workflow

by Heiko W.Rupp

Hey, here is the link to the recording of todays meeting. https://bluejeans.com/s/82L@/ For reference also find the Agile board columns to the JIRA git-pull-workflow and the state transitions attached. Heiko -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters

10 years, 10 months

1
0
0 / 0

Keycloak + Hawt.io

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, There was some progress last week with hawt.io 1.x and Keycloak integration, thanks to mposolda. As our target is to run on hawt.io 2.x, I think our PoC for Keycloak on rhq-metrics is now outdated. How Keycloak will work with hawt.io 2.0 is not clear yet, though. Besides, there's been a lot of progress in the Hawkular modules, so, it doesn't make sense to keep the KC server embedded on rhq-metrics. On another front, Keycloak has released 1.1.0.Final and they have plans to better support embedding and auto registration of applications on the next versions, with a special focus on seamless integration between consoles (Wildfly console with Hawt.io console, for instance). From what I'm following on their mailing list, a lot could change on this area, which is a good thing for us. That said, I'd expect this to move fast on the next days/weeks. Hence, I think it's not a good idea to keep *our* efforts on this front until that stabilizes. I'll be talking with the Keycloak team today (or later this week, depending on their schedule), as they seemed very interested in knowing our needs. For this, I'll use the information gathered on the "define: tenant" thread. As a result, I'll be closing the PR for Keycloak integration on rhq-metrics. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU0JpKAAoJECKM1e+fkPrXyOMH/2OmklrsocxNZ+t72rXfe6kE WbCLSUfc93Roa+pbMgmO4CNLf3PeWZ4HHDNy02RMdwC7lSrUidK+ad/UE4ePva18 bE+NcyeZqzCErYX6vaGcp4phAhIqzKwTEO+f26UB/H5GjX8d18XDGW2zVrRIvbpd QV3ihuXC0U7avvb3rveJj4OLst5e7diVHr863Ogxq76EJkpBQevJxAf/6hfMqQkO PGZKeiYaPZ16YZ0mHSJIK+++KjolWwcKygHVIJUZH4bhteLclUgUV2R+y9Y6s+JH Bt5J7LFuniKOaqrNCFU7p5ZZ/MzI1CATVo3nEtOriKo4kbxq0Kztv9CxHxL8zyU= =OrYk -----END PGP SIGNATURE-----

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev February 2015