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
9 years, 2 months
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.
9 years, 2 months
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
9 years, 2 months
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.
9 years, 2 months
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.
9 years, 2 months
UTC Timezone - Default for Services
by Stefan Negrea
Hello Everybody,
With the metrics aggregation work well under way, we have encountered the first case where timezones are important. The task queue [1] that John wrote to be used in the aggregation process is time sensitive. The tasks ran according to a schedule that is predefined; the time relationship also applies to failures, retries, and cancellation. Based on the experience we had with RHQ, not using an UTC timezone can lead to errors and loss of data (for more details visit [2])
I propose to set the default time zone for all the services to UTC. Only allow the concept of a timezone in the UI. This will avoid any problems due to automatic transitions between DST and non-DST times. For example, if the user wants to schedule something 2 weeks from now, let the UI handle the user selection. But when the user action is sent to the backend, it should be expressed in an timezone agnostic manner (eg. milliseconds since Unix Epoch).
The PR [1] sets the default timezone for the JODA library to be UTC for the classloader that contains the metrics service. With the recent discussions about creating a combined Kettle EAR or using a single classloader, that means this setting will extend to all the services in the same classloader that use JODA. And this is just the default, if a service really needs to set another timezone for a date object, it can be done by just specifying the timezone.
We tried to make the change more local in the metrics code, but the approach was error prone. Anybody could make a mistake and instantiate a date object in the current server timezone rather than UTC. This global approach drastically limits inadvertent mistakes.
Two questions for the group:
1) Does anybody see any issues with using the UTC timezone as default at the services layer?
2) Should we expand this setting to the JVM (not just JODA)?
[1] Task queue PR - https://github.com/hawkular/hawkular-metrics/pull/205
[2] Old RHQ thread - https://lists.fedorahosted.org/pipermail/rhq-devel/2014-November/003709.html
Thank you,
Stefan Negrea
Software Engineer
9 years, 2 months
maven release problem
by John Mazzitelli
OK, so I tried to do a release (of the bus/nest components). After a few hours, I hit a brick wall and can't go further. Someone tell me what's wrong.
First off, you need to fix all your javadoc warnings - because the release plugin will fail if you have any javadoc warnings. So I fixed those. I then did:
mvn clean install -Prelease
and it finished successfully. I then did:
mvn clean release:clean release:prepare
and it also finished successfully. I now have a 0.0.2 tag and the git repo looks correct. So I then did:
mvn release:perform
And it failed, like this:
[INFO] [INFO] Hawkular Nest Distribution ......................... FAILURE [ 3.184 s]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 02:46 min
[INFO] [INFO] Finished at: 2015-05-19T17:19:38-04:00
[INFO] [INFO] Final Memory: 90M/560M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.1:single (distro-assembly) on project hawkular-nest-distro: Failed to create assembly: Error creating assembly archive distribution: You must set at least one file. -> [Help 1]
I have no idea why this failed when all the other builds were successful. Even Travis finished building successfully! See: http://travis-ci.org/hawkular/hawkular-bus/builds/63241958 ... and FYI: Nexus has a snapshot repo with all of my artifacts except for that last one that failed to build. So Nexus isn't the problem.
How do you debug this? I googled that error message and nothing came up as an obvious fix.
So, after a couple hours, I still have no idea how to do a release successfully, which is odd since I've been told this was supposed to only take me a few seconds to complete :)
9 years, 2 months
[Update] Hawkular-Team Update
by hrupp＠redhat.com
To reinvite people
Sie wurden für den folgenden Termin eingeladen.
Titel: Hawkular-Team Update
This is a all-Hawkular team meeting to give updates where we are and so on.
This is *open to the public*.
Location:
on bluejeans: https://redhat.bluejeans.com/hrupp/
or alternatively teleconference Reservationless+ , passcode 204 2160 481
You can find Dial-In telephone numbers here:
https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481
RedHat internal short dial numbers are 16666 and 15555 (and probably
others, depends on your location)
Wann: Di 19. Mai 2015 3:30PM - 4PM Berlin
Wo: pc 204 2160 481
Wer
* Heiko Rupp - Organisator
* miburman(a)redhat.com
* tsegismo(a)redhat.com
* hawkular-dev(a)lists.jboss.org
* gbrown(a)redhat.com
* lkrejci(a)redhat.com
* snegrea(a)redhat.com
* jcosta(a)redhat.com
* theute(a)redhat.com
* amendonc(a)redhat.com
9 years, 2 months
relaxing checkstyle on java comment lines
by Jay Shaughnessy
I was getting really tired of checkstyle complaining about line-too-long
and trailing spaces for Java comment lines. I altered the config file
(attached) to be more flexible. But I don't have perms to create a PR
against hawkular-build-tools.
If you'd like to see this changed maybe chime in and the powers that be
will apply the change.
9 years, 2 months
Hawkular alternative to nest
by Gary Brown
Hi
I know that nest is going to be merged into hawkular, but wondering whether within hawkular the distribution can be built in two layers:
1) Bus + Accounts - i.e. the core shared "container"
2) Everything else added to (1)
This way, all of the components that will be built into (2), have the opportunity to perform local testing by building a distribution based on (1), without having the potential impact from other components not required for their component tests, and also not having to overwrite its own component in (2).
Although this is similar to the nest/hawkular approach used before, the benefit is that both of these layers would be managed in the hawkular repo and therefore should be easier to maintain.
Regards
Gary
9 years, 2 months
