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
9 years, 2 months
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.
9 years, 2 months
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
9 years, 2 months
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,
9 years, 2 months
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.
9 years, 2 months
Hawkular master
by Thomas Heute
Hawkular master is working again, thanks a lot for the focus on that !
It's also starting to use non-SNAPSHOT releases:
https://github.com/hawkular/hawkular/blob/master/pom.xml
Let's continue like this:
* peer review for each Pull Request (this also means that everything
goes through a Pull Request) and keep having Hawkular master in a
working state.
* more use of non-SNAPSHOTS, who is next ? (UI one should be last)
Thanks !
Thomas
9 years, 2 months
Download hawkular-dist from Maven
by Lucas Ponce
Hi,
I was having an issue with my maven configuration when I wanted to use hawkular-dist artifact with wildfly plugin.
Finally I have found that I had to change the <classifier> param in my pom.xml.
I have this one and it works:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<configuration>
<groupId>org.hawkular</groupId>
<artifactId>hawkular-dist</artifactId>
<version>1.0.0-SNAPSHOT</version>
<!-- <classifier>distribution</classifier> -->
<skip>${skipTests}</skip>
<port>${wildfly.management.port}</port>
</configuration>
<executions>
<execution>
<id>start-wildfly</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
<configuration>
<javaOpts>
<javaOpt>-Xms64m</javaOpt>
<javaOpt>-Xmx512m</javaOpt>
<javaOpt>-Xss256k</javaOpt>
<javaOpt>-Djava.net.preferIPv4Stack=true</javaOpt>
<javaOpt>-Dsun.rmi.dgc.client.gcInterval=3600000</javaOpt>
<javaOpt>-Dsun.rmi.dgc.server.gcInterval=3600000</javaOpt>
<javaOpt>-Djboss.socket.binding.port-offset=${wildfly.port.offset}</javaOpt>
<javaOpt>-Djboss.server.data.dir=${project.build.directory}/wildfly-data</javaOpt>
<javaOpt>-Dhawkular-metrics.backend=embedded_cass</javaOpt>
<javaOpt>-Xdebug</javaOpt>
<javaOpt>-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787</javaOpt>
</javaOpts>
</configuration>
</execution>
<execution>
<id>stop-wildfly</id>
<phase>post-integration-test</phase>
<goals>
<goal>shutdown</goal>
</goals>
</execution>
</executions>
</plugin>
Hope this can save some time.
Lucas
9 years, 2 months
Hawkular integration
by Lucas Ponce
Hello,
We were discussing in the F2F (and I guess it is still an on-going topic) about the components integration in hawkular.
I want to start using accounts with the REST endpoints in alerts and I would like to know where all the components are going to live.
If I am not wrong, I remember two approaches:
- A big hawkular.ear (with all components inside).
- A modules approach.
So, at some point we need to design integration tests to validate that components work well with accounts and I guess we need to decide how to do that.
At the moment, I see that components (metrics, alerts) have integration tests, I don't have the details for metrics, but for alerts what it uses the old nest distribution to put an embedded cassandra + alerts components to run the REST endpoints.
This is useful as JUnit tests are not enough to validate the full scenarios.
Now I think we need to agree which strategy we need to follow.
Thomas Heute and others commented (if I am wrong, please correct me) that is good to have glue code and integration tests inside hawkular, so hawkular project has responsability to put pieces together and validate it is correct.
Gary Brown and others commented (please, if it is not correct, feel free to correct me) that glue code should live in the component repo, as it has more sense to put our modifications there instead to propagate the change across several repo.
I like the option b) that the glue code lives in the component, but I see the benefits of a).
is there a possibility between something in the middle ? A tradeoff between both approaches ?
So I guess we need to find an agreement, if we need to move code it should be done quickly and also we need to test things.
I don't see how to proper integrate accounts without this topic more clear.
(I don't remember there is a final decision in the mailing list, please, point me to that if I missed it).
Thanks a lot,
Lucas
9 years, 2 months
CORS filters
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
I noticed that some components are implementing a custom CORS filter.
This is a feature that is provided also by Keycloak, and
administrators can use KC to set what are the allowed origins and
methods via its UI.
If you absolutely need a custom CORS filter for a different reason,
make sure to:
1) tell Keycloak to not handle CORS on your behalf. For instance, if I
were to disable Keycloak's CORS filter for Accounts, I'd change this
line to "false":
http://git.io/vTrkl
2) validate the user input ("origin" is a value that can be faked), so
that you are not vulnerable to an HTTP splitting attack:
https://www.owasp.org/index.php/HTTP_Response_Splitting
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVXgLmAAoJECKM1e+fkPrX3lQH/3eeQ8DKNrhmy2S9B8ZBORZD
JTWQ4WC5oCD3yDfoaVRFZw2CXLYVH1exAogOpQgtMxb/2RLa4+8NsUQMYSN03dB+
4QykeC/qnpmrlvhANZ6NgquH5Qpq6neI+p0YPMESmmsrxXpkvDhwANATWJE7+hGi
xM/6TGdFSKSNckR/CcZMc+M6w2SQMLEqfvfQqbOoJKy3TUk5/8XZK1eeTf/R+pf1
Xw99TfBmlmyOxr5qsQboFYZgroURMTbyi6WeBDUb0pwi/xEFaNjFLQi+uv0m3Nn5
GuXUruw2GmGRuERn/o2z2AV+WW41FcacgU863ET6VkatHpYhyq2TqwRWJeEAUG8=
=RcuH
-----END PGP SIGNATURE-----
9 years, 2 months
