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
9 years, 10 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
9 years, 10 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
9 years, 10 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
9 years, 10 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>
9 years, 10 months
