services build has a problem
by John Mazzitelli
This recently changed and doesn't work like it did before. I can't figure out what's wrong.
The -Pdev build isn't working correctly (and neither is the non-dev build).
When you build without -Pdev, the agent should be disabled by default. But it is not, and you will get agent errors on startup.
When you build with -Pdev, the agent should be enabled and with the hawkualr.rest.user/password properties set inside standalone.xml. But they are not, and you again get agent startup errors.
This used to work a few days ago.
The .xsl that used to tweak the standalone.xml doesn't seem to be doing what it was supposed to do. Look here:
https://github.com/hawkular/hawkular-services/blob/master/feature-pack/sr...
See where it sets the system properties to control the agent enabled flag and the credentials? This isn't doing anyting that I can see because the distro doesn't have any system proeprties in standalone.xml, but this used to work. We'd get those <system-properties> elements in standalone.xml.
I can't figure out what changed. Hoping someone knows the deal and can put this back.
9 years, 8 months
Some progress on Dockerization of Hawkular-services
by Heiko W.Rupp
Hey,
I was able to make some progress with Dockerizing Hawkular-services
More technical details below
As it is relatively hard (not impossible) to do stuff like adding a user
inside a (immutable) docker container or to edit standalone.xml to
enable the agent, we need to decide how we add the (default) user
to hawkular docker container and also if/how to enable the embedded
agent.
Also as we more understand hawkular-services as one package,
we should perhaps figure out if we really need the flexibility to
modify standalone.xml on the fly with all our snippets and templates
or if we create a 'hardcoded' one that can be used for the process
going forward.
At the moment wildfly10 is our base and will be for a longer period,
so the server-supplied standalone.xml will not change anyway.
Anyway my Poc is at
https://github.com/pilhuhn/hawkular-services/tree/dockerize-all-the-things
There are 3 routes that I went (basically refining the process)
(If you want to run any you first need to
$ mkdir -p /tmp/opt/hawkular
as this is where the docker run commands expect the data for now
To get a 'working server' you need to "mvn install -Pdev first"
1) dist/ creating a Dockerfile by hand and manually running docker build
Dockerfile
and then docker-compose to run a container from this image linked to a
C* 3.5 one.
Base image is the jboss/base-jdk:8 one and the Dockerfile basically
overlays the
whole hawkular-services distribution on top
You can run this with $ docker-compose up
2) docker-dist/ here maven creates the Dockerfile on the fly and feeds
it to Docker.
This uses the fabric8.io docker plugin from Roland Huss.
Again it uses the same base image + overlay as 1). The container tag is
derived from the
maven properties.
To build and run you can go into the directory and then
$ mvn docker:build
$ mvn docker:start
3) docker-dist2/ Similar to 2) this uses the mvn docker plugin, but this
time is uses
jboss/wildfly:10.0.0.Final as the base image. Unfortunately it still
overlays the whole
wildfly from us, but we should be able to filter that out.
The good thing is though that the image is already much smaller as in 2)
To build and run the same process as 2) applies
*
The next step is now to figure out how to only apply our changes and not
to
supply the base wildfly into the conatiner. I certainly need help from
someone
with maven-fu :)
But while the current state is not optimal it shows that this is very
much doable
and we should proceed.
Heiko
9 years, 9 months
memory footprint with swarm
by John Mazzitelli
I was running the swarm agent and so while I was here, I decided to take a quick look at memory footprint. I took these numbers from the Gnome System Monitor GUI utility.
swarm agent:
Memory=188M, Resident Memory=208M
full wildfly agent:
Memory=351M, Resident Memory=378M
So swarm agent was roughly half the size of full wildfly agent.
This was not a scientific study :) I just started the agent, when I saw it finished initializing, I looked at the System Monitor and read the memory numbers.
And Jay claims if he put his mind to it, he can shrink the swarm agent further. :) But we aren't doing any more work on it at the moment.
9 years, 9 months
Updates on android Client of hawkular
by Anuj Garg
Last 10 days haven't been so handsome to me or android client.
Most of it upgraded including
->aerogear Library
->butterknife
->gsm
->support libraries
Gradle update is not possible at present as sdkmanager plugin by jake
warthon haven't been upgraded and its alternative is forcing me to build
multidex application.
So I am back to old gradle until I find a workaround.
Some part in journey gave happiness too.
With PR on hawkular android client accepted. It will work like
https://drive.google.com/open?id=0B8tYKC1-UERHNWhSeUZQdmVtS2M
Next I am planning to direct clicks on metrics to their chart presentation
Thanks
Anuj Garg
9 years, 9 months
Hawkular Client Ruby
by Lucas Ponce
Hello,
These days we have had several discussions about the hawkular client ruby.
Today there are two main uses cases (Hawkular Metrics from OpenShift and Hawkular Services for MiQ provider) and there are some complexity in the side effects of updating the clients related to the backward compatibility.
I have started to collect some notes about this
https://docs.google.com/document/d/17bAPbBJ6_2wdXAAg_XIQRMi0_RQfODyOEmdOs...
I hope it can help to gather all requeriments to have a clear picture of what could be a good decision for future implementations, studying the pros/cons.
Please, feel free to add your comments or thoughts about the topic.
Thanks,
Lucas
9 years, 9 months
Merging of own pull-requests ( please don't )
by Heiko W.Rupp
Hey,
I want to remind everyone (including myself :-) that one should not merge
ones own pull-requests (and also abstain from directly committing to master).
There are many reasons why this is good practice
- peer review finds issues
- peer review allows discussions on the concrete implementation of
a bugfix/feature request
- other findings can be addressed in the same pull-request and do
not need a subsequent one.
- It gives oneself some time to reflect what was done.
- It gives time to also add this one little file that was not git-add'ed
I totally understand that we are in some areas rather thin on developers
(Juca's work on hawkular-services and accounts come to mind) and that
there are always situations where a direct commit or self-merged PR is
needed. But it should not be the default.
I do not want us to get to a structure where only a handful of managers
have push rights to force this above mentioned peer review.
Thanks
Heiko
9 years, 9 months
Hawkular Commons 0.7.4.Final
by Juraci Paixão Kröhling
Team,
Based on the IRC discussion and on the related thread, I removed the
Embedded Cassandra from Nest and did a release of Commons (0.7.4.Final).
The integration tests for Nest are deploying the Embedded Cassandra,
while the feature pack is not shipping it. If you need help achieving
this on your module, let me know.
Next week's Hawkular Services will be based on this version of Commons,
so, it won't be shipping Cassandra anymore.
- Juca.
9 years, 9 months
Removal of embedded Cassandra
by Juraci Paixão Kröhling
Team,
As mentioned on IRC, we should not ship an embedded Cassandra with
Hawkular Services. Here are a couple of approaches we can follow to
accomplish that:
- Keep everything as is, but change the default value for
`hawkular.backend` to `remote` instead of the current `embedded_cassandra`
- Remove the embedded Cassandra entirely from Nest. This has
implications on how the integration tests are executed: we'd need to
ensure that each integration test suite starts an embedded Cassandra
before the test is executed. Or use an approach like Metrics, which
requires Cassandra to be running before the tests are started.
Which approach should be the one to follow?
- Juca.
9 years, 9 months
Fwd: [wildfly-dev] Wildfly Provisioning
by John Mazzitelli
just passing this along...
----- Forwarded Message -----
From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Tuesday, June 14, 2016 4:53:32 AM
Subject: [wildfly-dev] Wildfly Provisioning
Hi Everyone,
Recently a few of us had a meeting to discuss a new provisioning/patching system for Wildfly. I have written up the notes for this meeting which are at [1].
The document contains the full details, but the basic idea is to design a provisioning/patching/package management system for Wildfly and downstream products. This will not be based on our existing patching or feature pack code, but should take over the responsibilities of both.
Obviously this is still in the early stages, and any feedback is welcome.
Stuart
[1] https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/s...
9 years, 9 months
