December 2015 - hawkular-dev - Jboss List Archives

by Jay Shaughnessy

Hawkular Alerts 0.6.0.Final has been Released! * Event Support This major new feature incorporates Events into Hawkular Alerts. Events: * Are more lightweight than Alerts * Record things of interest * Can be injected via an API call * Can be generated via a Trigger * Can have actions performed on them (for Trigger-generated Events) * Can be used as Trigger conditions For more on Events there is some general information here (more to come): http://www.hawkular.org/docs/dev/alerts.html And Lucas provides some great examples here: https://github.com/lucasponce/hawkular-examples/tree/master/events * WebHooks Action Plugin Hawkular Alerts 0.6.0.Final introduces a new Action plugin for WebHook notifications. There have been some changes to the REST endpoints as we refine the model. Of course there are fixes and minor enhancements as well. A Jira Summary for the release is here: * https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versi... The next scheduled release is 0.7.0, targeted for December 9, 2015. Hawkular Alerts Team Jay Shaughnessy (jshaughn(a)redhat.com) Lucas Ponce (lponce(a)redhat.com)

10 years, 3 months

3
5
0 / 0

CanonicalPath should go to Commons

by Peter Palaga

Hi *, esp. Lukáš, Having org.hawkular.inventory.api.model.CanonicalPath in a separate maven module inside Hawkular Commons git repo would make the life easier for both Alerts and Command Gateway. For both Alerts and Command Gateway, CanonicalPath is the only class they need from Inventory. If CanonicalPath was hosted in Commons, both Alerts and Command Gateway could stop maintaining any dependency on Inventory and the overall dependency graph [1] could thus be made simpler. Lukáš, I remember I asked about this earlier, but do not precisely remember what was your reason for the denial? [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies Thanks, Peter

10 years, 3 months

2
2
0 / 0

Moving Nest and Bus to Hawkular Commons git repository

by Peter Palaga

Hi *, this was already discussed on several calls. Although I know of no objections, I am putting it also here to give you all the last chance to protest or discuss. The plan is to move the Maven modules from Nest [1] and Bus [2] git repositories to Commons repository [3]. Details: * Nest and Bus Maven modules will be moved to Hawkular Commons git repository * Nest and Bus Maven modules will belong to groupId org.hawkular.commons * All modules of the org.hawkular.commons incl. Nest and Bus will be released together * The new and old subcomponents of Commons (such as Nest, Bus, Templates, c* driver, ...) will be allowed to depend on each other, but clearly, they may not introduce circular dependencies. * To help to keep control on which subcomponent depends on which other subcomponents, the dependency management will happen on the subcomponent level rather than in hawkular-commons-parent * Components consuming Nest, Bus or any of the other subcomponents of Hawkular Commons will have to declare just one version property version.org.hawkular.commons to manage all the the artifacts they need from commons * As noted by Stefan, only such subcomponents should be allowed to be hosted in Commons that are generic enough -i.e. that do not contain any deep and specific domain knowledge. Move of Bus and Nest to commons satisfies this. Pros: * Decrease the maintenance overhead by decreasing the number of git repositories and by decreasing the number of Hawkular components having independent release cycles - e.g. after a new release of Hawkular Parent there is two component less to upgrade, two componets less to release and n components less to upgrade that depend on Bus and Nest Cons: * Loose some amount of design cleanness - Hawkular Commons hosts Maven modules with clean logical borders that could be hosted and released independently. * Esp. the independent release cycle could be seen as an advantage when fixing bugs and CVEs Pseudo-con: * Note that the new home of Nest and Bus does not prescribe any component that consumed Commons so far to consume also Nest and Bus from now on. Dependent components can still choose the artifacts to depend on with an unchanged granularity: Who dependeded on embedded c* so far can stay with it without depending on Bus or Nest. I am going to work on this change now. [1] https://github.com/hawkular/hawkular-nest [2] https://github.com/hawkular/hawkular-bus [3] https://github.com/hawkular/hawkular-commons Thanks, Peter

10 years, 3 months

1
2
0 / 0

wildfly agent can remove resources now

by John Mazzitelli

The Hawkular WildFly Agent can now remove resources from inventory. Today, you can remove datasources and jdbc drivers and (I think) deployments (though I actually haven't tested deployments yet). I just tested the removal of a datasource from the UI and it worked (though, has anyone noticed the websocket connectivity is flaky in the UI? sometimes it works, sometimes it doesn't). The agent is getting in much better shape now. In prior releases of the agent, if anything changed in inventory (like a resource configuration property changed its value or a new resource was added, or a resource was removed) you had to restart the agent to pick up the change. Now the agent has auto-discovery scans running periodically and can discovery and update inventory on the fly. In addition, I made the inventory management more efficient - each full scan will now only tell Hawkular-Inventory about things that changed since the last time the agent sent up inventory - so if you perform a scan every 10 minutes but nothing changes, nothing will go to hawkular-inventory (before, the agent would always send everything all over again even if nothing changed). I released the agent with all these enhancements - 0.15.1.Final. Hopefully people will get a chance to beat on it and tell me what I broke :) OK, *now* I'll start my vacation. :) --John Mazz

10 years, 4 months

1
0
0 / 0

agent auto-scan, inventory update

by John Mazzitelli

I think I finally got the agent working much better than before. In the past: 1) the agent would scan for inventory and once it got that inventory, that was it. It could never detect any new resources unless you restarted it 2) the agent would never detect changes to resource configuration properties even for resources it found on the original scan I think I fixed both now. The agent will scan periodically for new resources and add them to hawkular-inventory when it finds them. It will also detect if existing resources changed their resource configuration, if so, it will send those changed resources to hawkular-inventory. I also fixed it where it will no longer send the ENTIRE inventory EVERY scan. The agent will only send resources to inventory that are new or changed to the agent. All of this is in master. I wanted to release the agent with this new stuff, but I need h-inventory to do a release first (agent and command-gateway have srcdep dependencies on it).

10 years, 4 months

1
1
0 / 0

versioning schema

by Jiri Kremser

Hello, I'd like to ask about the policy we want to use for the versioning schema. I've raised a PR [1] that will check the project version and fails the build if it's wrong. This should catch the releases with malformed versions. It's aligned with the JBoss project versioning [2], however, it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good point in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can be also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when releasing, we add the Final/Alpha, etc. Looking into wildfly repo, they use the former method. Is this what we want? I personally consider the latter method more natural and we use it in the inventory, despite the fact the hawkular/hawkular uses the x.y.z.AlphaN-SNAPSHOT. jk [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 [2]: https://developer.jboss.org/wiki/JBossProjectVersioning

10 years, 4 months

6
6
0 / 0

Root cause analysis

by Heiko W.Rupp

Hi, came along that tweet: https://twitter.com/tobiasfrech/status/678858126414716928 Suppose this happens and we did record that the update was end of week 48 we could in an alert not only say "value X too high" [1] but also deduct that this is most likely due to the update. [1] Currently this depends on having an alert trigger correctly defined to alert if the value goes above the max of week 45..48. We may want to have alerts figure this out automatically via the data analysis from Pavol.

10 years, 4 months

1
0
0 / 0

hawkular-alerts/master synced with Wildfly10

by Lucas Ponce

Hello, We have sync-ed hawkular-alerts master branch and now it is based on Wildfly10. This branch uses for itests the distribution defined in accounts via feature packs and travis is ok with it. https://travis-ci.org/hawkular/hawkular-alerts/builds/97694344 Lucas

10 years, 4 months

1
0
0 / 0

is it time for a bom? or for version definitions in parent pom?

by John Mazzitelli

I just released the wildfly agent (0.13.7.Final) and I just realized I may not have moved things up to the latest releases of its dependencies. It would be really nice now if we had something (even if its just versions in the parent pom) that defines the latest releases that components should be using because right now, how many of our pom.xml files have things like this: <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkular.accounts> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bus> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular.cmdgw> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkular.commons> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawkular.inventory> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawkular.metrics> It would be nice if we aren't required to set these (but we could override them, right? if we want to try out a different version than what the parent pom defines). This would make releasing easier. We just comment out all the <version...> entries in all our pom.xml files (if they are there at all), thus falling back to what the parent-pom has defined. Or maybe we build a bom?? I dunno - all I know is, there is going to come a time when something breaks because "uh-oh, this component built on version x.y.z of metrics, but THIS component built on version a.b.c of metrics".

10 years, 4 months

6
15
0 / 0

autoVersionSubmodules = true

by Juraci Paixão Kröhling

Team, Is anyone against setting the property autoVersionSubmodules to true in the parent? This property instructs maven to set the same version of "parent" (your parent, not Hawkular parent) to all sub modules, so, during release, there's only one question about "what's the version to be released?" and "what's the next development version", no matter how many sub modules you have. It seems that some of us already have it either on the pom.xml for the project (Inventory), while others use the property via CLI (-DautoVersionSubmodules=true). So, if nobody is against it, I'll send a PR by Friday to our parent setting this to true. - Juca.

10 years, 4 months

3
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev December 2015