Use of jira trackers
by Heiko W.Rupp
Someone asked:
> I thought HAWKULAR project's metrics component means Hawkular-UI
> metrics component. Why is there a metrics component under
> Hawkular-JIRA? We have "HWKMETRICS" which should be used instead.
> Confusing.
HAWKULAR is the over all jira project for Hawkular.
Stuff that is needed for the overall project is recorded there.
For the individual subcomponents of Hawkular, we have
a jira-component and sometimes also a separate HWK*
tracker. Projects can use that to track their individual issues
or also breakdown of tasks that were originally recorded
in HAWKULAR as a "top level" item.
Users that download Hawkular and find an issue will file
it in HAWKULAR and not chase the individual HWK* jira -
most often because they do not know about it.
Also release notes for Hakular are created from HAWKULAR
jira (only)
UI-specific work is recorded in the UI component of HAWKULAR
--
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, 2 months
hawkular bower build failure
by John Mazzitelli
Red Alert! Hawkular fails to build (at least for me):
...
[ERROR] bower es5-dom-shim#* invalid-meta es5-dom-shim is missing "main" entry in bower.json
[ERROR] bower es5-dom-shim#* invalid-meta es5-dom-shim is missing "ignore" entry in bower.json
[INFO] bower es5-dom-shim#* resolved git://github.com/termi/ES5-DOM-SHIM.git#e25207e9ed
[INFO]
[INFO] Please note that,
[INFO] hawtio-oauth#2.0.38 depends on keycloak#~1.1.0 which resolved to keycloak#1.1.0
[INFO] hawkular-console depends on keycloak#1.3.1 which resolved to keycloak#1.3.1
[INFO] Resort to using keycloak#1.3.1 which resolved to keycloak#1.3.1
[INFO] Code incompatibilities may occur.
[INFO]
[ERROR] bower angular resolution Unsuitable resolution declared for angular: ~1.4.9
[ERROR] bower ECONFLICT Unable to find suitable version for angular
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Hawkular ........................................... SUCCESS [ 18.163 s]
[INFO] Hawkular: Admin console ............................ FAILURE [03:52 min]
[INFO] Hawkular: WildFly Agent Download WAR ............... SKIPPED
[INFO] Hawkular: Pinger ................................... SKIPPED
[INFO] Hawkular: Availability Creator ..................... SKIPPED
[INFO] Hawkular: API parent pom ........................... SKIPPED
[INFO] Hawkular: RX extensions layer ...................... SKIPPED
[INFO] Hawkular: REST API Web Application ................. SKIPPED
[INFO] Hawkular Feature Pack .............................. SKIPPED
[INFO] Hawkular: Distribution ............................. SKIPPED
[INFO] Hawkular: End-To-End integration tests ............. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 04:11 min
[INFO] Finished at: 2016-02-05T10:22:53-05:00
[INFO] Final Memory: 44M/468M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.26:bower (bower install) on project hawkular-console: Failed to run task: 'bower install' failed. (error code 1) -> [Help 1]
10 years, 2 months
Downsizing the Nest deployments
by Peter Palaga
Hi *,
there is a couple of jars our war deployments could load from WF modules
that are available either on a stock WF/EAP installation (apache
commons.*, guava 18, ...) or that are our own (c* driver, guava 16).
Technically, it would mean to mark those dependencies as provided and
declare them as dependencies in jboss-deployment-structure.xml.
The motivation is twofold:
(1) Make clear that (if applicable) it is the container teams who is
responsible for sustaining and productization of the jars.
(2) Make the wars smaller - faster to build, faster to release/upload,
faster to download, faster to deploy.
Can anybody see a reason why we should not follow this strategy?
Thanks,
Peter
10 years, 2 months
RfD: Installer
by Heiko W.Rupp
Hey,
while the All In One zip works well for demoing, using Hawkular in a
more serious scenario requires a lot of options and settings
* External C*: $CASSANDRA_NODES and -Dhawkular.backend=remote
* Binding to non-localhost: -b a.b.c.d and
-Dkeycloak.server.url=http://a.b.c.d:8080/auth
* Adding jdoe to a dist build:
-Dkeycloak.import=./standalone/configuration/hawkular-realm-for-dev.json
* Using an external RDBMS for keycloack users: "before the server first
boots, the `KeycloakDS` on `standalone.xml` should be changed to point
to an external database." (this applies when using the embedded KC and
not a separate standalone one)
* If not using jdoe above: setting user/password for the internal agent
after a user was created
* Dorking around with standalone.xml to chose up a mail server
* Setting other java opts
all the above involve a huge amount of manual steps and configuration
changes.
I think it is thus time to introduce some sort of installer or config
script that is able to make the changes. I think there is meanwhile even
a cli mode that can apply the changes (to standalone.xml) on a
non-running server. Some options could be set in env variables or
directly applied to the standalone.xml.
If we still need to supply env-variables we may potentially also create
a start script from the installer, which sets the variabls and then
calls standalone.sh
10 years, 2 months
LOTE Persistant Data
by Matthew Mahoney
Summary
LOTE data is now persistent in between Hawkular restarts.
Details
LOTE is configured with Hawkular and Cassandra running in separate Pods. This means that when a new Hawkular image is build, and then deployed, only Hawkular will be restarted and Cassandra will remain running with it's existing data.
** New user accounts will not persist between Hawkular restarts.
How do I Clean Up The Data (aka: restart Cassandra)?
If Cassandra restart is needed, for the time being please email myself and Viet.
Maintenance Page
There is a maintenance page that will be rendered when LOTE is down, instead of the a 503 error.
Thanks,
Matt
10 years, 2 months
Hawkular Metrics 0.12.0 - Release
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.12.0 of Hawkular Metrics. This release is anchored by Hawkular integration enhancements, under-the-cover refactoring and changes in code structure, and removal of the deprecated JAX-RS 1.1 implementation.
Here is a list of major changes in this release:
1) Hawkular Authentication
* When deployed part of Hawkular distribution, Hawkular Metrics uses Hawkular Accounts for authentication and authorization
* Due to multi-tenant data segregation, Hawkular Accounts does both authentication and authorization since there are no specific permissions within Hawkular Metrics
* For more details: HWKMETRICS-69, HWKMETRICS-344
2) Performance Improvements
* Removed obsolete code for tracking tenants; this increased for cases where data was written under a tenant that did not exist before (HWKMETRICS-341)
* Removed the virtual clock handler (used to accelerate internal metrics clock) since it is no longer used (HWKMETRICS-340)
3) JAX-RS 1.1 Implementation - Removed
* The already deprecated JAX-RS 1.1 implementation of Hawkular Metrics has now been removed from the source tree and the modules consolidated
* Going forward only JAX-RS 2.0 implementation of the REST API is available
4) Wildfly 10 - Deploying & Running
* Deploying and running the project on Wildfly 10 is now fully supported
* IMPORTANT: Support for Wildfly 9 is now dropped
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.12.0
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12329375
Hawkular Metrics Clients
* Ruby: https://github.com/hawkular/hawkular-client-ruby
* Python: https://github.com/hawkular/hawkular-client-python
* Go: https://github.com/hawkular/hawkular-client-go
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, and Heiko Rupp for their project contributions.
Thank you,
Stefan Negrea
Software Engineer
10 years, 2 months
Fwd: [wildfly-dev] Is the BOM for 10.0.0.Final available already?
by John Mazzitelli
----- Forwarded Message -----
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, February 1, 2016 1:48:16 PM
Subject: Re: [wildfly-dev] Is the BOM for 10.0.0.Final available already?
WildFly BOMs for 10.0.0.Final are released.
easiest way to use it is to have this in your pom
<dependencyManagement>
<dependencies>
<dependency> <groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee7</artifactId>
<scope>import</scope>
<type>pom</type>
<version>10.0.0.Final</version> </dependency>
</dependencies>
</dependencyManagement>
make sure that this is part of your <dependencyManagement> and not just <dependencies>
10 years, 2 months
