What should -Pdev do?
by Peter Palaga
Hi *,
sorry, for bringing this up so late on this list. I discussed this on
#hawkular but probably outside US office hours and I totally
underestimated the amount of emotions some of us are tied by to -Pdev.
There was a change by me recently that changed a little bit how -Pdev
behaves.
Originally, a -Pdev just produced a bundle in which the default
configuration was changed to suit the dev use case: esp. one had jdoe
loaded by invoking simply standalone.sh.
As I worked on fixing the end to end tests in Hawkular, Lucas was fixing
the REST tests in alerts. We both had the problem that the hawkular
bundle that maven has downloaded from JBoss Nexus was build without
-Pdev and as a consequence of that we could not run our integration
tests by simply taking the bundle. We had to unzip the bundle, do what
-Pdev does and only after that we could start it.
Hence, as a solution, I have prepared
https://github.com/hawkular/hawkular/pull/134
which caused that the stuff originally present only in bundles built
with -Pdev became available by default, but to use that dev stuff,
wildfly needs to be started with
standalone.sh -c standalone-itest.xml
because standalone-itest.xml is the place where the dev configuration is
activated.
With this change, there is only one way to build a hk bundle, hence
there is only one bundle to distribute and download but you can do both
dev and prod things with it. Not having jdoe/password by running the
default config is a good thing from the security PoV.
The bottom line is that -Pdev in the present master has one small issue
that I fixed in https://github.com/hawkular/hawkular/pull/148
Please comment.
Thanks,
Peter
11 years
[process] tickets and PRs
by John Sanda
Does there need to be a pull request for every ticket? Put another way, do all commits to master need to come by way of PRs? I think that there are scenarios where a manual merge makes more sense.
- John
11 years
Alert Email Config
by Jay Shaughnessy
It's not totally clear what we want to do in Hawkular to configure the
smtp server for use with the e-mail action plugin for alerts. OOB WFly
is configured for smtp server localhost:25. This generally does not
work in dev envs.
So, we deploy the e-mail action plugin, we supply the e-mail address in
Hawkular user registration, and then we just generate server log
warnings when it doesn't work. It's easily remedied with a a manual
edit. For us we can set it to the RH corp smtp server, which will work
fine as long as you run from behind the VPN, or on the corp net.
We could hardcode this into our Dist but I'm not sure if we want to
publicize that host.
Otherwise, a manual edit is required unless we provide for some sort of
build-time command line prop to be applied to Dist by the build.
Thoughts?
11 years
how to get literal $ in .xsl
by John Mazzitelli
BTW: if anyone knows how to fix this, let me know.
In the agent configuration, Thomas H. wanted to be able to configure the agent to talk over a different IP/port than localhost:8080 (specifically the one Wildfly binds to - jboss.bind.address and jboss.http.port).
In the standalone.xml config, this actually works:
<storage-adapter type="HAWKULAR"
username="jdoe"
password="password"
url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
However, when I try to get that url value to be added to the default standalone.xml via our XSL, I get an error.
So, this line here:
https://github.com/hawkular/hawkular/blob/mazz/wip/dist/src/main/resource...
I want to be:
url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
But XSL parser dies. I tried using "\$" and "$" to no avail. Anyone know how to get a literal $ to be parsed here?
11 years
Web test fixture
by Viet Nguyen
I'm pleased to announce first version of the Web Test Fixture is up and running. It's a web server (nginx) running inside Docker that can simulate a specific HTTP response code as well simple cron-like availability.
Please let me know whether this is useful for Hawkular URL monitoring and what you want to see next. For example, a. simulate slow response time, b. cycle between http status codes, etc.
Viet Nguyen
-----
Example usage:
[1] Launch a web fixture
docker run -d -p 8999:8080 hawkularqe/web-fixture
# get custom http code (replace 503 with any valid status code)
curl -I http://localhost:8999/http?return=503
--> HTTP/1.1 503 Service Temporarily Unavailable
[2] Launch a mostly-available fixture - server goes offline for 10 seconds every minute
docker run -p 8999:8080 -e "DURATION=50s" -e "CRON_EXP=* * * * *" hawkularqe/web-fixture
[1] and [2] in the example above are also running on public OS1:
1. http://209.132.179.82:50001
2. http://209.132.179.82:50002
Github:
https://github.com/Hawkular-QE/web-fixture
11 years
new agent in kettle
by John Mazzitelli
The latest agent is in kettle, along with release versions of accounts and inventory.
The new agent inserts resources into inventory and metrics along with those resources get collected and stored into metrics.
There is only a top level server and one child resource for now. But this should be good enough for UI folks to start beating on it.
I'll be feverishly trying to get a fuller EAP into inventory. I might need inventory API to have some fixes. The agent code is there, its just blowing up because I'm trying to create resource types that I've already created and inventory doesn't like that.
11 years
Re: [Hawkular-dev] Tenant Id
by Heiko W.Rupp
Hi,
as this discussion is going on and the other components need to adapt,
we need to come to
an end.
The preferred form is to have the Tenant id in the header as:
Hawkular-Tenant: acme.org
This has been agreed upon by everyone I think and been committed to
hawkular-metrics yesterday as
https://issues.jboss.org/browse/HWKMETRICS-86
Now the question is if we need a fallback in the case a client can not
supply a
header.
Following some discussion here and on irc yesterday, a queryParameter
(?tenantid=acme.org) seems to be preferred over a matrix parameter.
Last but not least is the question if we need that fallback at all.
My litmus test here is always the usage via curl.
As curl allows to pass headers via -H "Hawkular-tenant: acme.org" I can
imagine not using a fallback at all.
Hawkular itself needs to check if a tenant is provided and otherwise
reject the request with a
403 error code, providing a "missing Hawkular-Tenant" reason phrase.
While a 403 has a slightly different meaning, a 401 code is not
applicable, as for a 401 the
response must indicate a challenge to be met for successful
authentication.
If a tenant header is provided, but does not match a known tenant we
should probably
return a 404 not found - I am not sure on this one though. Perhaps a 403
with different reason
phrase is even better.
In cases where there is only one default tenant (e.g. metrics running
standalone), the
check for the provided tenant can be omitted.
For fallback / non-fallback I've created a doodle:
http://doodle.com/extrm4zreh25hhx3
Please respond until 5/20 EOD
11 years
Hawkular Public Instances Update
by Matthew Mahoney
Resending...
Hawkular Community,
We apologizes for the prolonged OS1 public Hawkular instance outage, which has been due to our need to build a new OS1 Kubernetes cluster.
Current state
- The new cluster is in place and build with Kubernetes 0.15 (was 0.9).
- Public Hawkular instances are running , but as of today only manually started (no Hawkular image build trigger).
Community: http://209.132.179.82:18080
QE: http://209.132.179.82:18085
Dev: http://209.132.179.82:18090
Next steps
- Wire Hawkular DockerHub project to trigger Jenkins job to deploy pods. This is expected to be completed early next week.
- Further improvements to the Kubernetes cluster - add additional minions.
- Abstract the Hawkular instance entry-points, as not to depend on a fixed minion IP in the URL.
Ping me with any questions / concerns.
Thanks,
11 years
WF9 requires us to change our agent subsystem extension classes
by John Mazzitelli
The quick summary of this email: the Hawkular Wildfly Monitor Agent will not be able to run on WildFly 9 in its current state. It must be refactored due to changes that were made in the WildFly 9 subsystem extension API.
Details:
After staring at this for a while, I found that our currently WildFly8 code layout of the subsystem extensions in the agent needs to change for this to run in WF9 - I don't think I used this approach in the bus or nest subsystem extensions so nothing needs to change there.
The design pattern here is to use PersistentResourceDefinition subclasses for our the subsystem resource definitions (called the Definition classes). In here you define static members for all attributes and operations as well as an INSTANCE object of the definition itself, among other things.
The problem is, that same Definition class needs to grab (and thus create) an instance of the AddStepHandler within the Definition class' constructor. And THAT AddStepHandler needs to refer back to the Definition object for the attributes. Today, it does so in the populateModel() overloaded method, which isn't a problem. However, we needed to access a parent class' data field (this.attributes) to set our attributes in that populateModel() method. Unfortunately, that parent class in WF9 has changed that this.attributes data field to final. So we can't do that anymore. Instead, it appears the only way to set the attributes now is to pass them in via the AddStepHandler class' constructor (calling the superclass's "super(Collection<?> attributes")).
But this introduces an ugly circular dependency in the Definition and AddStepHandler constructors - it bombs with an NPE.
So this means in order for us to move the agent to WF9, I would need to refactor the subsystem definition classes - I would probably have to extract out all of the attribute/operation definitions into some independent class that can be shared between the *Definition and *Add classes to avoid this constructor-circularity dependency. It probably won't be hard to do this, just a hour or two hopefully. But as it is now, it can't run on WF9.
11 years
