inventory 0.3.0 released
by Jiri Kremser
Hi,
we've released the new Hawkular inventory version.
Also we don't use the .Final .Alpha .IdontKnow 'adjectives'/tags anymore, just plain sem-ver.
It may make sense for the major releases though.
It's the minor release, because there are new features.
What's new?
* Resources can have configs,
* configs can have a structure (validating against json schema).
* Support for dumping the whole graph into json.
* rest endpoint for getting all the children resources of given resource with given resource type
* a lot of bug fixes
Special thanks to ploffay for his contributions.
jk
9 years, 4 months
Timestamped SNAPSHOTs hard to use
by Peter Palaga
Hi *,
I tried to use $subj for the first time today, and I must say $subj did
not meet my expectations. Namely, the timestamps and buildNumbers are
generated at the instant of deployment of the given artifact, which may
lead to distinct timestampts of artifacts of the same group and same
deploy operation.
So, when I want to use the latest timestamped SNAPSHOT of Alerts in
Hawkular, there is no single timestamped version that I could use for
all Alerts artifacts that I manage using the property
${version.org.hawkular.alerts}. To use the latest timestamped version, I
actually can remove the <version.org.hawkular.alerts> property
altogether. I have to put the latest 0.4.0-SNAPSHOT literal to into all
managed alerts artifacts
(https://github.com/hawkular/hawkular/blob/master/pom.xml#L154 and
https://github.com/hawkular/hawkular/blob/master/pom.xml#L161) then run
mvn versions:lock-snapshots -Psnapshots
and voila, it resolves the versions as follows:
<dependency>
<groupId>org.hawkular.alerts</groupId>
<artifactId>hawkular-alerts-actions-email</artifactId>
<version>0.4.0-20150817.111158-17</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.hawkular.alerts</groupId>
<artifactId>hawkular-alerts-rest</artifactId>
<version>0.4.0-20150817.111150-18</version>
<type>war</type>
</dependency>
Here, you can clearly see that the timestamped versions are not the same.
This guarantees the reproducibility of the builds, but I would not call
it practical. Manual maintenance of these scattered version numbers will
be error prone and cumbersome. One can use mvn versions plugin to handle
the versions.
http://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependen...
Can anybody see a way how to make the timestamped snapshots easier to use?
Thanks,
Peter
9 years, 4 months
Keycloak Authorization Tokens
by Artur Dryomov
Hey everybody,
As you might know I’m working on the Hawkular Android Client project [1].
If you tried to run the application you might saw that we are using OAuth
to get access to Hawkular instances because basic auth is too barbaric.
For testing purposes I use the Docker container named jboss/hawkular-aio
[2] with Hawkular 1.0.0 Alpha 3.
Keycloak provides two types of auth tokens. First—a regular one, expires
after 5 minutes by default. Second—a refresh one, which is used to refresh
a regular one, expires after 30 minutes by default. The thing is, it seems
like Keycloak refreshes refresh tokens, i. e. refresh tokens can expire.
All tokens, including the refresh one of course, are refreshed in the
refresh procedure. In practice it means that if you don’t use the
application for an hour, for example, you are forced to relogin, because
you have no ability to refresh tokens. This sounds weird and personally I
would be pissed to relogin basically every time I use the application.
Am I right? Is this a proper behaviour? Can it be avoided without
reconfiguring Keycloak? Who are we in this world? These are the questions
:-)
Artur.
[1]: https://github.com/hawkular/hawkular-android-client
[2]: https://hub.docker.com/r/jboss/hawkular-aio/
9 years, 4 months
Manage cassandra-all in hawkular-parent
by Peter Palaga
Hi *,
ATM, cassandra-all is managed on three places independently, which is
hard to keep in sync:
org.apache.cassandra:cassandra-all occurences:
org.hawkular.metrics:cassandra-seed-provider:2.1.6
org.hawkular.commons:hawkular-commons-embedded-cassandra-service:2.1.6
org.hawkular.alerts:hawkular-alerts-engine:2.1.1
I'd put cassandra-all newest 2.1.* version (2.1.8) to
dependencyManagement in hawkular-parent unless somebody protests loudly.
Note, that we already manage
com.datastax.cassandra:cassandra-driver-core in parent. The driver's
release cycle is independendent from cassandra-all. The newest 2.1.*
version of the driver is 2.1.7.1 and I am going to upgrade to that one
in Parent.
Thanks,
Peter
9 years, 4 months
Please update JIRA status
by Heiko W.Rupp
Hey,
when starting to work on a JIRA in HAWKULAR or HWK*, please update
the the status in JIRA to be "on dev". You can do so by clicking on the
"Start Progress" button in Jira
This way it is easier to see what is worked on and also helps to prevent
more than one person starting the same issue.
Thanks
Heiko
9 years, 4 months
Inventory configuration definitions
by Lukas Krejci
Hi all,
There is a pending PR on inventory to add support for checking configurations
against a schema. The configs are directly mappable to JSON and the schemas
are actual JSON schemas.
Now to create a resource with configuration is a two-step process. First one
creates a resource without configuration and then adds a configuration to it.
When the PR is merged the configuration will be checked against the schema
(stored at the resource type) but that check will only happen when the config
is created (or updated), not when the resource itself is created.
Today, Heiko asked if a URL resource could be made required to have a valid
URL. Given the above, the answer is yes, but the URL resource can exist
without any URL, too, until someone assigns one to it (at which point it can
be ensured that it is a valid URL using some regex magic).
My question is, do we actually want to support Heiko's scenario (i.e. disallow
resource creation without also supplying valid config)? In my mind, one of the
reasons for bothering with Hawkular and abandoning RHQ was to ease up on the
strict rules we had there about resource hierarchies and resource creation.
Certainly, those restrictions and rules made sense, but at the same time
forced a rigid and non-modifiable workflow when working with RHQ.
IMHO, there should be an understanding of an "incomplete" resource - i.e. one
that doesn't have all the data with it that is should have - either because
that piece of data hasn't trickled down to the inventory or because the user
actually didn't decide yet what the resource will end up being. Having the
support for incomplete resources also makes the future support for changing
the resources' types easier - it could be done in steps.
Do you see strong reasons for requiring valid config at resource creation time
or do you think that current workflow is "workable" and my reasons for doing
it that way at least partially valid?
Thanks for input,
Lukas
9 years, 4 months
Each hawkular-metrics PR is now checked for performance regression
by Filip Brychta
Hello,
Please be aware that second check (first is continuous-integration/travis-ci/pr) on each hawkular-metrics PR now finally does something useful.
Following build (http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/haw-perf-stability-t...) is launched for each PR which will:
1 - build the PR
2 - build hawkular-dist using snapshot artifact from step 1
3 - deploy hawkular-dist
4 - start perf test which will
- generate as high load as the hawkular is able to server. Right now from 300 threads where each thread is using unique tenantId.
- measure average throughput (one request == POST one data point to http://${server.host}:${server.port}/hawkular/metrics/gauges/test/data and wait for response)
- check % diff with previous build
- if the % diff is < -2, it will fail the build. Right now it's still not 100% stable because of shared network, this problem should be fixed soon. Expected instability is now +/- 2 % so anything bigger than 2% should be considered as regression
5 - report status back to the PR
So please from now on pay attention to result of that check and ping me if it fails.
Consider this just as first step, there will be more next week since we have more time now (JON 3.3.3 is out).
It would be nice if anybody could create a PR which would test this (just include some tiny sleep into request processing)
Thanks,
Filip
9 years, 4 months
