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
11 years
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
11 years
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
11 years
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-----
11 years
Spring cleaning
by Thomas Heute
Some of you may have noticed (sorry for the spam) but I was playing with
HAWKULAR JIRA.
Few things:
- Let's use the same terminology for the issues, this is JIRA's
terminology:
- Bug - A problem which impairs or prevents the functions of the product.
- Feature Request - A new feature of the product, which has yet to be
developed.
- Task - A task that needs to be done.
- Enhancement - An enhancement or refactoring of existing functionality
Try to think from an Hawkular *user* perspective, so that the release
notes are meaningful. Everything could be a task or enhancement, but
thinking from a user point of view, changing kettle->dist is a task not
an enhancement. Adding something that was not possible before for the
user is a "feature request" not to be considered an enhancement (even
though it is obviously an enhancement of the project).
This is my workflow:
- If a feature is broken, this is a bug (Bonus points if you can tell
which release was affected, for the moment it's easy as there was no
release)
- If a feature didn't exist, it is a feature request
- If a feature exists and does things faster/better (things changed in
the UI for better clarity) this is en enhancement
- If it's something that the end user would not really care about
(added a test, changed some build stuff), it's a task.
- tasks/sub-tasks are evil (as they all have the same kind). Instead of
https://issues.jboss.org/browse/HAWKULAR-123 let's use the
"Fix-Version(+component)" and properly fill the type. If tasks need to
be grouped, please use links.
- before closing an issue, check if the type, component, resolution,
fix-version are filled and correct. (once closed you can only
edit/change by reopening the issue and can't do bulk changes)
Thanks, if we all do that, we'll have human readable release notes.
Thomas
11 years
non-snapshot kettle dependencies
by John Mazzitelli
We need to schedule the work to get kettle dependent on non-snapshot releases.
I recently released the following that can be used in the kettle build:
hawkular-bus: 0.0.5
hawkular-nest: ls 0.0.5
hawkular-agent: 0.0.2
We need folks to release the following:
hawkular-accounts (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-alerts (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-console (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-inventory (currently kettle uses 0.0.1-SNAPSHOT)
Once those releases are done, we can edit the hawkular/pom.xml to reflect the non-snapshot versions.
11 years
Hawkular image and the docker hub registry
by Matt Wringe
There are a few images we should push out under the 'hawkular'
organization account on docker hub:
- hawkular-metrics
- hawkular-cassandra
- hawkular-heapster*
*: only until https://github.com/GoogleCloudPlatform/heapster/pull/284
is closed
If there are no objections, I will create those images soon under the
'hawkular' account.
Initially, it will probably set it up as an automated docker hub build
(since we can get it up and running very quickly). But we should really
change it so that we build the images ourselves as part of the CI build
and push the images out to docker hub. This will keep things more inline
with that the kubernetes application will be expecting and prevent us
from manually having to update the docker configurations when the
versions change.
I have no idea how our current CI works, so if someone could help me
here that we would be great. I am assuming building the docker images
there will be a simple task.
Thanks,
Matt Wringe
11 years
Properties store?
by Heiko W.Rupp
Hey,
in RHQ we had several ways to record properties of things
* traits
* resource configuration
* plugin configuration
* ...
I think we need something similar in Hawkular.
Having said that, we probably should avoid the above situation
and find out what is really needed.
I can imagine that for stuff that are in reality changing attributes of
a resource (e.g. version, #of cpus, ip address, ....) - basically stuff
that is not changing like a metric, some key-value pairs on the
resource in inventory may be the best place.
11 years
Kanban and the pull principle
by Heiko W.Rupp
Hey,
I was asked something in the lines of "what shall I work on when no one
assigns tickets to me"?
Some ideas behind Kanban are:
1) stop starting, start finishing
2) pick where you see fit
3) limit work in progress (for those who were at the f2f, remember the
coin flipping)
Now we have the columns in the workflow (see attachment).
The idea is that tickets flow from left (backlog to right, new to done).
If you see a situation like in the attachment, where there
are (many) issues in "dev coding done" = PR sent state, then
apply idea 1) to help finishing the ticket. Apply idea 2) and pick one
of
those (only one, applying idea 3) verify and merge it.
Then rinse, repeat.
For principle 2, try to honor the priorities on the tickets.
Also pick something where you feel comfortable with - you have the
freedom.
11 years
