Metrics protected by accounts: agent should be updated
by Thomas Segismont
Hi,
In Metrics master branch, the Hawkular component artifact is now
protected by Accounts.
This means that the current agent won't be able to send metrics, and
that we can't use the latest version of Metrics as is in Hawkular.
We need to:
- update the agent code (I haven't created any JIRA)
- update Hawkular with new Agent and Metrics srcdep in the same commit
(this is to close HAWKULAR-549)
Regards,
Thomas
10 years, 2 months
Github - Protected Branches
by Stefan Negrea
Hello Everybody,
I did a mistake force push yesterday on the master branch of Metrics and wiped a few commits. I was working on a PR and instead of force pushing the PR I did it on the master. And we did not notice that until late today. This could have partially been avoid by me working on fork. I do not like to work on a fork for the Metrics project because it is a constant churn of branching, getting new code, merging since I actively work on a project. But that by itself would not have avoided this force push at all. I knew about force push protection feature in general but never thought about activating it. Thanks to Juca for mentioning it in the channel.
As a way to avoid mistakes like this in the future, I enabled force push protection for the default branch on all Hawkular org repositories. This should have been enabled from the start.
For the future, I recommend enabling this on all new sub-projects. Also, if you have other important branches in your sub-project please enable force push protection for all of them. You can find this in Settings -> Branches -> Protected Branches - http://snag.gy/GK4ic.jpg (thanks again to Juca for the screenshot).
Thank you,
Stefan Negrea
Software Engineer
10 years, 2 months
how to avoid required sysprops
by John Mazzitelli
I saw Juca posted this in a github comment:
> That happens because the `keycloak.server.url` property is not set, so, it
> defaults to localhost:8080 . You can start the server with
> `-Dkeycloak.server.url=http://localhost:8180/auth`
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/hawkular/hawkular-btm/pull/281#issuecomment-176169067
I think this is the problem I saw yesterday with my inventory going screwy (not sure, but I was using port offset, and didn't set that sysprop).
I bring this up to ask - is there anything we can do to not require that sysprop to be set? For example, is there some startup hook we can have that sets this automatically? I don't know if it's possible, but, it is pretty clear this is going to be a common problem that people will forget to set this anytime they bind to a different address (using -b) or using a different port offset.
Is there a JIRA on this so we can try to address it in the future?
I suppose if we do have some kind of installer, one solution would be the installer would add this sysprop to the startup .conf file.
10 years, 2 months
Metrics contributors must remove the api-diff precommit hook
by Thomas Segismont
Hi,
A pull request which removes JAX-RS 1.1 support from Metrics has just
been merged. Future minor and major versions of Metrics will support
JAX-RS 2.0 only.
For Metrics contributors, it means you should remove the api-diff
precommit hook from your .git/hooks directory.
Regards,
Thomas
10 years, 2 months
Alert trigger flags
by Luba Roitman
Hi, I am trying to understand the relationship between a number of alert trigger flags. While behavior of each individual flag (autoDisable, autoEnable and autoResolve) is clear, I have some questions on how trigger behaves when some of this flags are turned on:
1. autoDisable + autoEnable: this combination seems possible and logical, the triggers gets disabled, the user tends to alerts fired by the trigger, resolves them, the trigger gets enabled2. autoDisable + autoResolve: does this combination make sense? I can imagine trigger fires an alert, goes into disabled state. Does it switch into evaluating autoresolve conditions? If user manually enables such trigger after it got disabled after firing, will it be evaluating autoresolve conditions?3. autoEnable + autoResolve: same questions as before: alert fires, trigger starts to evaluate resolve conditions, then got disabled manually. User resolves alerts, the trigger becomes enabled because of autoEnable flag, but does it evaluate resolve conditions or problem conditions?
I would appreciate your help in clarifying the questions.
Thanks, Luba
10 years, 2 months
What should be the replacement for printlns in tests?
by Peter Palaga
Hi *,
Short version: How to configure the log levels for individual
jboss.logging loggers in tests run by maven outside the container?
Long version:
I was recently assigned https://issues.jboss.org/browse/HAWKULAR-264 Add
println checks to the checkstyle. It says that "Tests shouldn't be
allowed to have printlns, we should enforce this via the checkstyle plugin."
I fully agree for tests being run on the server side - those can use
JBoss Logging in the very same manner as the server code.
However, what is the best replacement for println()s in tests that are
run outside the server?
I tried using JBoss Logging there too but I failed completely to find a
way to configure the log levels for individual loggers. Does anybody
know how to do that?
To get my work done without using printlns, I started to use
java.util.logging configured via logging.properties :
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
So what should be the replacement for printlns in tests?
Thanks,
Peter
10 years, 2 months
Eliminating Alerts -> Command Gateway dependency
by Peter Palaga
Hi Jay, Lucas and *,
I was looking into the possibility to move all message classes [1] from
Command Gateway to Commons. My primary motivation was to eliminate the
dependency of Alerts on Command Gateway. After thinking about the impact
I basically abandoned that idea.
Initially, I thought, the move can be justified by the fact that those
classes define a public API that can be hosted separately from the
implementation. However, we have not done anything like that for any
other component. I think that such a split would make the development of
the command gateway (or any other component) unnecessarily complicated.
Moreover, there is another option [2] you (Alerts guys) seem to foresee
already:
CommandEventListener can be moved to a new deployment in Hawkular.
Hawkular Alerts should not really have knowledge about Hawkular-level
decisions, like which possible Events to filter out or various special
handling that needs to be performed.
Hence I vote for moving CommandEventListener to Hawkular. Do you (Alerts
guys) already have a Jira for that?
Thanks,
Peter
[1] The message classes are generated from these schemas:
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
plus some interfaces etc. in
https://github.com/hawkular/hawkular-command-gateway/tree/master/hawkular...
[2]
https://github.com/hawkular/hawkular-alerts/blob/master/hawkular-alerts-b...
10 years, 2 months
