0.3.0.Final of Hawkular Alerts
by Jay Shaughnessy
We're happy to announce 0.3.0.Final of Hawkular Alerts. A bunch of
good stuff this time around, here are the relevant Jiras and a few
highlight blurbs:
** Enhancement
* [HWKALERTS-17] - Refactor to eliminate EE dependencies of EJB3
Now packaged as a WAR as opposed to an EAR, for easier consumption
in another EAR.
* [HWKALERTS-50] - Integrate with Hawkular Metrics
A value-add External Alerter deployment (WAR) that adds more
alerting power when integrated with Hawkular Metrics. Thanks to John
Sanda for his help.
* [HWKALERTS-52] - Hooks for external alerts
A mechanism for integrating External Alerters into Hawkular
Alerts. Allows external clients to leverage the Hawkular Alerts Trigger
and Action infrastructure.
* [HWKALERTS-57] - Improve the way actions plugins access
information related to an alert
Now Actions and Notifiers have full access (via JSON) to the Alert
details.
* [HWKALERTS-59] - Review if 204 return code can be changed to an
empty list
API CHANGE! Get Alerts now returns and empty list as opposed to 204
when the criteria results in in no alerts.
* [HWKALERTS-60] - Review end point for alert resolution
New REST endpoints for Ack or Resolve of a single alert.
* [HWKALERTS-62] - Allow any data to store contextual information
Optionally Store a Map of context data with any datum sent into
alerts for evaluation. Then use that context info in your actions.
* [HWKALERTS-65] - Adapt email plugin to support multiple
conditions and multiple states
Big enhancements in e-mail notifier for rich messages at different
life-cycle points.
* [HWKALERTS-67] - Update gson dependencies with jackson
Remove use of GSON, now depends on fasterxml provided by Wildfly.
** Feature Request
* [HWKALERTS-64] - Enable trigger on alert resolution
- Now can AutoEnable an [Auto]Disabled Trigger when its alerts are
resolved.
- Now automatically returns an AutoResolve Trigger to firing mode
when its alerts are manually resolved.
Please contact us with any questions, comments or contributions!
Jay Shaughnessy (jshaughn(a)redhat.com)
Lucas Ponce (lponce(a)redhat.com)
9 years, 5 months
Re: [Hawkular-dev] inventory API: can I get a feed ID from a resource ID?
by John Mazzitelli
I'm not sure how the UI knows the feed ID to use. I'll defer to the UI guys how they do it. I wonder how they get the feed ID to use with the resource ID?
The agent is easy - I know my feed ID :) For the UI, I'm not sure how they know what the agent's feed ID is when talking about my agent's resources (versus the pinger's resources, let's say - or another agent).
----- Original Message -----
> The REST URLs always resembled what is now formalized in the "canonical path"
> of the entities.
>
> If you accessed resource with ID "a", you never did that just by using that
> "a". You had to mention the tenantID (deduced from the auth info), the
> environmentID (part of the URL) and feedID (if the resource lived under a
> feed). That is precisely what the canonical path contains, too.
>
> So from the user of the REST interface nothing really changed apart from the
> fact that 0.2.0.Alpha1 supports resource hierarchy (which is expressed as a
> URL path, too).
>
> On Monday, July 20, 2015 09:16:23 John Mazzitelli wrote:
> > This is important to know from a UI perspective. Right now, I store the
> > resource ID under the tenant ID.
> >
> > The UI (IIRC) only has the resource ID. From what you just said Lukas, that
> > doesn't seem like its unique enough.
> >
> > This might be an issue with the UI.
> >
> > ----- Original Message -----
> >
> > > In Inventory 0.2.0.Alpha1 which I am about to release today if no
> > > breakage
> > > was
> > > discovered during my absence:
> > >
> > > If you have the resource java object, which I think you have in agent,
> > > you
> > > simply do:
> > >
> > > resourceObject.getPath().ids().getFeedId();
> > >
> > > Long version:
> > >
> > > All inventory entities now store a "canonical path" which is a path going
> > > down
> > > from tenant do the entity in question following the "contains"
> > > relationships.
> > >
> > > The above call will take the resource object's path analyze it using the
> > > "ids()" call and will return the feed id, if the resource is contained
> > > within a feed or null, if the resource lives directly under an
> > > environment.
> > >
> > > Also if you just store the resource ID, remember that that is only
> > > "locally
> > > unique" within your feed, so to reliably get the correct resource, you
> > > only
> > > can search for it within the feed:
> > >
> > > inventory.tenants().getAll("asdf").environments().get("asf").feeds("myfeed
> > > ") .resources().get("resource-id");
> > >
> > > If you also store the canonical path of the resource, you could do:
> > >
> > > inventory.inspect(CanonicalPath.fromString("resource-path"),
> > > Resources.Single.class);
> > >
> > > which would return to you the same access object as the above call.
> > >
> > > So when you create your resource, you supply locally unique id, and can
> > > use
> > > the access object returned from the create method to get the newly
> > > created
> > > resource which will contain its full canonical path and all the other
> > > details.
> > >
> > > On Friday, July 17, 2015 15:11:42 John Mazzitelli wrote:
> > > > To the inventory folks: is there an API that gives me a feed ID if all
> > > > I
> > > > know is a resource ID? If there is no API, can I get one? :)
> > > >
> > > > We'll need a way to determine what feed is responsible for managing
> > > > what
> > > > parts of the inventory. So, given that clients like the UI will only
> > > > know
> > > > about things like resource ID, that's all they will be able to give the
> > > > kettle - but the server-side components will need to take that resource
> > > > ID
> > > > and get its associated feed ID so it can pass messages to the feed that
> > > > is
> > > > managing that resource. _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
9 years, 5 months
inventory API: can I get a feed ID from a resource ID?
by John Mazzitelli
To the inventory folks: is there an API that gives me a feed ID if all I know is a resource ID? If there is no API, can I get one? :)
We'll need a way to determine what feed is responsible for managing what parts of the inventory. So, given that clients like the UI will only know about things like resource ID, that's all they will be able to give the kettle - but the server-side components will need to take that resource ID and get its associated feed ID so it can pass messages to the feed that is managing that resource.
9 years, 5 months
Integration branch for Inventory 0.2.0.Alpha1
by Lukas Krejci
Hi all,
I plan to release inventory 0.2.0.Alpha1 soonish because it would be good for
it to take some soak time in Hawkular prior to the next milestone. The main
reason being the move to Titan and Cassandra as inventory's backend.
The other big(gish) feature is the support for resource hierarchy (at last!) a
move to using canonical paths to entities on many places, etc.
In another words, there will be breakage.
I've opened the integration branch in my own fork of Hawkular:
https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
I already made it pass the integration tests. There will need to be changes
for Pinger and agent (and possibly for the UI, too) which I am seeking for
help with.
I've started working on the agent updates for that branch (which triggered
quite a lot of changes on the inventory side to make the transition (and
future changes) smoother) but nothing is committed yet for that.
Cheers,
Lukas
9 years, 5 months
Fwd: Writing good pull requests (Fwd: [wildfly-dev] How to contribute pull requests to WildFly)
by Peter Palaga
Things to consider. Forwarded from thecore -- P
-------- Forwarded Message --------
Subject: Writing good pull requests (Fwd: [wildfly-dev] How to
contribute pull requests to WildFly)
Date: Thu, 16 Jul 2015 16:30:26 -0500
From: David M. Lloyd <david.lloyd(a)redhat.com>
To: The Core <thecore(a)redhat.com>
I recently sent this to wildfly-dev. I think however that these
guidelines are probably applicable to many, if not all, of our git-based
OSS projects, so if any of you are interested in this topic, here you go.
-------- Forwarded Message --------
Subject: [wildfly-dev] How to contribute pull requests to WildFly
Date: Thu, 16 Jul 2015 16:08:08 -0500
From: David M. Lloyd <david.lloyd(a)redhat.com>
To: WildFly Dev <wildfly-dev(a)lists.jboss.org>
Since migrating to git, and a review-oriented contribution structure,
we've seen a massive improvement in the quality and quantity of
community contribution in both WildFly itself and its affiliated
projects. However, while we have lots of documents about how to get the
WildFly code, hack on it, use git to make a branch, submit a pull
request, etc., one thing rarely (if ever) talked about is any kind of
standards as to how to actually build and structure your pull requests,
so I'm going to establish that right now.
I have a few reasons for doing this. First, the reviewers are stretched
thin - very thin. This has several bad effects, including (but not
limited to):
* Pull requests sitting in the queue for extended periods of time
* Giant pull requests getting less review than small pull requests
* Pull requests receiving highly variable quality-of-review
Secondly, we see problematic pull requests in a wide variety of shapes
and sizes, from the single-unreviewable-mega-commit PR to the
thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as
well as some stealthier cases like the build-is-broken-between-commits PR.
Thirdly, the project has reached a size and scope where we really need
to have more eyes on every change - as many as possible in fact.
To that effect, and borrowing some concepts heavily from the Linux
Kernel project's documentation [1], I offer this. You're welcome.
(For background on how to get started with contribution, the hacking
guide [2] is still the best place to start; after any initial
discussion, I'll probably throw this up alongside that.)
WildFly Contribution and Pull Request Standards
-----------------------------------------------
While a complete git tutorial is far, far out of scope of this guide,
there are a few important rules and guidelines to adhere to when
creating a pull request for WildFly or one of its constituent or related
sub-projects.
1) Describe the pull request adequately.
The description *should* include a JIRA number directly from the project
in question, whose corresponding JIRA issue will in turn have been
linked to the pull request you are just now creating. The description
*should* also include a decent, human-readable summary of what is
changing. Proper spelling and grammar is a plus!
2) Make sure it builds and tests pass *first*.
It is highly annoying to reviewers when they find they've spent a great
deal of time reviewing some code only to discover that it doesn't even
compile. In particular, it's common for a patch to trip CheckStyle if
it hadn't been previously compile-tested at the least.
While it is tempting to rely on the automated CI/GitHub integration to
do our build and test for us (and I'm guilty of having done this too),
it generally just causes trouble, so please don't do it!
3) Separate your changes - but not *too* much.
This comes directly from [1], and I agree with it 100%:
"Separate each _logical change_ into a separate patch.
"For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
or more patches. If your changes include an API update, and a new
driver which uses that new API, separate those into two patches.
"On the other hand, if you make a single change to numerous files,
group those changes into a single patch. Thus a single logical change
is contained within a single patch.
"The point to remember is that each patch should make an easily understood
change that can be verified by reviewers. Each patch should be justifiable
on its own merits.
"If one patch depends on another patch in order for a change to be
complete, that is OK. Simply note "this patch depends on patch X"
in your patch description.
"When dividing your change into a series of patches, take special care to
ensure that [WildFly] builds and runs properly after each patch in the
series. Developers using "git bisect" to track down a problem can end up
splitting your patch series at any point; they will not thank you if you
introduce bugs in the middle.
"If you cannot condense your patch set into a smaller set of patches,
then only post say 15 or so at a time and wait for review and integration."
I also want to emphasize how important it is to separate *functional*
and *non-functional* changes. The latter category includes reformatting
(which generally should *not* be done without a strong justification).
4) Avoid massive and/or "stream of consciousness" branches
We all know that development can sometimes be an iterative process, and
we learn as we go. Nonetheless, we do not need or want a complete
record of all the highs and lows in the history of every change (for
example, an "add foobar" commit followed later by a "remove foobar"
commit in the same PR) - particularly for large changes or in large
projects (like WildFly proper). It is good practice for such change
authors to go back and rearrange and/or restructure the commits of a
pull request such that they incrementally introduce the change in a
logical manner, as one single conceptual change per PR.
If a PR consists of dozens or hundreds of nontrivial commits, you will
want to strongly consider dividing it up into multiple PRs, as PRs of
this size simply cannot be effectively reviewed. They will either be
merged without adequate review, or outright ignored or closed. Which
one is worse, I leave to your imagination.
5) Pay attention and respond to review comments
While in general it is my experience that WildFly contributors are good
about this, I'm going to quote this passage from [1] regardless:
"Your patch will almost certainly get comments from reviewers on ways in
which the patch can be improved. You must respond to those comments;
ignoring reviewers is a good way to get ignored in return. [...]
"Be sure to tell the reviewers what changes you are making and to thank them
for their time. Code review is a tiring and time-consuming process, and
reviewers sometimes get grumpy. Even in that case, though, respond
politely and address the problems they have pointed out."
In addition, when something needs to be changed, the proper manner to do
so is generally to modify the original commit, not to add more commits
to the chain to fix issues as they're reported. See (4).
6) Don't get discouraged
It may come to pass that you have to iterate on your pull request many
times before it is considered acceptable. Don't be discouraged by this
- instead, consider that to be a sign that the reviewers care highly
about the quality of the code base. At the same time though, consider
that it is frustrating for reviewers to have to say the same things over
and over again, so please do take care to provide as high-quality
submissions as possible, and see (5)!
7) You can review code too!
You don't have to be an official reviewer in order to review a pull
request. If you see a pull request dealing with an area you are
familiar with, feel free to examine it and comment as needed. In
addition, *all* pull requests need to be reviewed for basic
(non-machine-verifiable) correctness, including noticing bad code, NPE
risks, and anti-patterns as well as "boring stuff" like spelling and
grammar and documentation.
8) On major refactorings
When doing major and/or long-term refactors, while rare, it is possible
that the above constraints become impractical, especially with regard to
grouping changes. In this case, you can use a work branch on a (GitHub)
fork of WildFly, applying the above rules in micro-scale to just that
branch. In this case you could possibly ask a reviewer to also review
some or all of the pull requests to that branch. Merge commits would
then be used to periodically synchronize with upstream.
In this way, when the long-term branch is ready to "come home" to the
main branch, the reviewers may have a good idea that the (potentially
quite numerous) changes in the work branch have been reviewed already.
[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
[2] https://developer.jboss.org/wiki/HackingOnWildFly
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
9 years, 5 months
New or noteworthy in hawkular-parent 18
by Peter Palaga
Hi *,
New or noteworthy in hawkular-parent 18 [1]:
* WF BoM upgraded to 9.0.0.Final
* WF Plugin configured to use our WF version
* Added gatling-maven-plugin
* Added Jackson Core
* Removed JBoss Logging, EJB and Servlet APIs from Parent dep
management because they are managed in WF BoM. Note that WF BoM
manages these as provided thus making them non-transitive and as a
consequence of that, they need to be added explicitly on some places.
I have sent PRs with an upgrade to parent 18 to all consuming repos.
Note that in HK main, I sent it to dev/inventory-0.2.0.Alpha1 branch.
Best,
Peter
[1] https://github.com/hawkular/hawkular-parent-pom/commits/18
9 years, 5 months
tomorrow
by John Mazzitelli
Tomorrow morning I would like to talk about something Heiko prototyped, which I then took and built out. It is related to server-feed communications and is also going to relate to pushing realtime information to the UI as well. Now that this stuff is in a place that is demoable (its hacked up, but it shows what I want it to show), I figure let everyone know what's going on, and what it is Heiko has been dreaming up (see how I subtly threw him under the bus there? :) Seriously, its a pretty cool idea and I have something working that I can show. If anyone is interested, I'll do this maybe during or after the status call. I realize its last minute, but I wanted to bring it up now before the end of week because I don't know if we want this infrastructure to go in the release next week or not.
9 years, 5 months
resteasy jackson or fasterxml jackson?
by John Mazzitelli
This is more for Lucas P, but wanted to put it out to the wider audience.
I'm playing with JSON stuff, and now that we are not using gson, we have to decide what jackson version we are going to use, because i just saw some oddities on stuff I'm building because of the two different impls that are available.
Are we going to use the restasy jackson2 or the fasterxml jackson artifacts? I think we need to consolidate on one (I mean, after all, we just got rid of gson - so we are trying to consolidate on one JSON impl). And they are technically two different impls because they are in two totally different Java packages and so look like two different impls. This can bite us if we aren't careful.
I'm using fasterxml right now. I don't know if i'm going down the exact same path that I did with gson (that is, using something no one else is). But my problem is I believe the resteasy modules are NOT in WildFly Core, so that's why I'm just pulling in the fasterxml artifacts directly rather than depending on the resteasy module.
9 years, 5 months
[GSoC] Hawkular Android Client: Weekly Report #7
by Artur Dryomov
Hi everyone,
This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.
This morning Heiko had merged two pull requests. The first one is important
and is related to the API update, hopefully you can use the latest Hawkular
version with the application at this point—well, at least the 1.0.0 Alpha 2
[1]. The second one is more minor, but helpful—you can now filter alerts by
time periods, just like the web UI [2].
I wanted to discuss future plans—mostly because the application itself is
working and all basic features are available. Most of all I would like to
receive some feedback regarding the direction of the future development.
And I totally understand that Hawkular itself is evolving and there are
more changes to come.
Major.
- Accounts. I need to investigate if it is possible at all, but multiple
accounts handling would be nice. If it is not, at least logging out should
be supported. There is some work done about that, but the discussion
suddenly calmed down [3].
- Navigation. I am not entirely sure that the current navigation handles
everything properly. For example, at the moment all alerts are shown when
browsing alerts. There should be some categorization based on resources,
but at moment there are no proper API calls supporting it. The only thing
we have is filtering via trigger IDs. Web UI solution is mostly a hack from
my perspective [4].
- Applications. This is a big one. I need to try to configure it and
play with the API to understand how it works and how can I adapt the
application to handle it.
Minor.
- Chart. Distinguish availability and threshold ones. Not sure if it is
possible in a flexible way, because Inventory at this point doesn’t show a
type in the Metric model.
- Chart. Make it more like the web one. I’m kind of limited by the used
chart library, plus it is tricky to handle large sets of data, especially
for months and years. Trying to dig through the TypeScript source code to
understand how the web UI works.
- Lists. Maybe add pull-to-refresh support. Purely cosmetic and utility
change, not sure if it will be useful actually.
Most likely I should restructure these points into GitHub issues and work
on them, but I wanted to receive some feedback if it is possible. What do
you want to see in the application? What do you think should be primary
goals at this point?
Thanks and have a nice week!
Artur.
[1]: https://github.com/hawkular/hawkular-android-client/pull/28
[2]: https://github.com/hawkular/hawkular-android-client/pull/29
[3]: https://github.com/hawkular/hawkular-android-client/pull/26
[4]:
https://github.com/hawkular/hawkular/blob/b61fc571bfff88a08621b088c79f3a2...
9 years, 5 months
