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
10 years, 10 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 :)
10 years, 10 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
10 years, 10 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.
10 years, 10 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
10 years, 10 months
The components, glue and kettle
by Gary Brown
Hi
On yesterday's watercooler discussion the main topic was about how to package the individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle repo. Although I agree that the kettle is the right place to bring together the components and glue, not sure whether the actual code for the glue should reside in that single repo.
My preference would be for all component related code, including that component's integration with the bus, to be located in that component repo - that way there is a clear owner of the code, and any changes to the core APIs are locally dealt across all integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build what it requires.
In terms of how the 'core' artifacts from each component should be enhanced with the glue - may be the simplest way would be as one person suggested - use an overlay to build upon the 'core' war artifact to add the glue artifacts (which in general will probably just be bus integration). So each component only needs to produce a single 'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the individual component boundaries but enhances them with whatever they need to communicate in the kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't need to use overlays, but I don't believe this is the case.
Regards
Gary
10 years, 10 months
Plans for Alerts UI
by Gary Brown
Hi
As mentioned at the F2F, one of the things I need to do with BTM is ensure that it will be capable of providing equivalent functionality that is currently in RTGov.
If Alerts are used in place of RTGov Situations, then from the UI the user would need to be able to perform various tasks when focused on a particular alert, including viewing/editing a message for resubmission to the originating service, navigate to the business transaction instance view, etc.
It would be useful if there was a way to provide plugins to the alerts UI to register actions that could be performed, or contribute additional UI tabs that can perform capabilities related to the selected alert.
Is this going to be technically possible with hawt.io/angular to add such extension points?
What is the best way to proceed - should I just create a jira for now?
Regards
Gary
10 years, 10 months
