Splitting out feed-comm from bus
by Peter Palaga
Hi *,
feed-comm is a component hosting the server part of the WebSockets that
both UI and Agent use for bidirectional communication. It is quite new
and it was preliminarily placed to bus git repo [1]. However, feed-comm
needs to depend on Inventory which makes up a cyclic dependency, because
Inventory already depends on Bus.
We came to a consensus with Mazz and Lukáš that the most natural
solution would be the put feed-comm into a new git repo and giving it
its own release cycle. Are there any concerns about this?
We are also in the process of finding a better home for nest, which
conceptually does not belong to bus. Moving to HK main or to a new repo
are being considered.
[1]
https://github.com/hawkular/hawkular-bus/tree/0.5.0.Final/hawkular-feed-comm
Thanks,
Peter
11 years
Maven, Continuous and Reproducible
by Peter Palaga
Hi *,
I think I found a way how to make our process more continuous, while
staying with stock Maven and Components in separate git repositories.
The core of the idea is that we actually do not need to release the
components because they are not our deliverables (yes, except for
Metrics). If we were able to declare the dependencies using git
revisions and build them on the fly, we could get rid of both SNAPSHOTS
and releases.
I have written srcdeps-maven-plugin [1] today that does exactly that:
* It collects dependencies with versions matching
{whatever}-SRC-{git-commit-hash}
* It checks out {git-commit-hash} of their sources to
~/.m2/dependency-sources
* It changes the version in the sources to
{whatever}-SRC-{git-commit-hash}
* Builds the artifacts and installs them to the local repository
* All the above happens before the dependency resolution starts
so it is fully transparent for the rest of Maven.
* The -SRC- dependencies are build only if they are not found in local
repository - so they prolong the build only when upgrading.
How to try it out:
#Make sure that you have maven 3.2.5 or newer:
mvn -version
# build the plugin
cd ~/git
git checkout https://github.com/ppalaga/srcdeps-maven-plugin.git
cd srcdeps-maven-plugin
mvn clean install
# build hawkular with the plugin
cd ../hawkular
git remote add ppalaga https://github.com/ppalaga/hawkular.git
git fetch ppalaga
git checkout -b 150819-srcdeps
mvn clean install ...
[1] https://github.com/ppalaga/srcdeps-maven-plugin
11 years
Extra back-end for our front-end
by Viliam Rockai
Hey all,
As we put more and more functionality into Hawkular, the more and more
logic is put into the front-end itself, too. From my perspective, we're
dealing with too much stuff that doesn't even belong to the front-end
anyway. I believe we should create a new back-end module, which would
connect all the existing modules with the front-end. This module may
even be maintained by the front-end team, since it'll evolve and mutate
very fast - to suit the UI needs. There are several use-cases which call
for such module. For example to create all the alert entities needed for
alerting you need to create a:
* Trigger (per alerting "entity")
* Dampening (one or more)
* Condition (one or more)
Each of those has its separate endpoint and creation of each may fail.
So basically we should (we don't do that yet, we just assume everything
went all right) even deal with transactions in the front-end right now.
>From the UI perspective, this is just a single entity "Alert
definition". Another question is - when should those objects be created?
Once you add an URL - that's pretty easy (for URLS). But, in my opinion,
for JVMs they should be created once the resource is discovered, not the
1st time the resource is accessed by UI. And the situation will be more
complicated with new resources. Being able to get some predefined sets
of metrics would be another nice feature. I.e., right now, we do 3
requests (User, maximum, committed) to get the data for the "JVM Heap
Usage" graph (and other graphs, too). Being able to process those data
on a server and send it the the front-end in one bulk would be pretty
neat.
I believe adding a new module to the back-end, which role would be to
connect the UI to the rest of Hawkular services would be beneficial for
performance, testability and robustness of the whole app.
WDYT?
Viliam
11 years
Add JDBC Driver support in Agent
by Peter Palaga
Hi *,
there is a requirement for Agent to support adding JDBC drivers
https://issues.jboss.org/browse/HAWKULAR-517
The named Jira does not name any standalone/domain/local/remote related
limitations for the functionality, hence the functionality should be
there for all modes.
As already noticed on IRC, WildFly 9's jboss-cli.sh offers the
possibility to add a module, but it works only for the local machine in
standalone mode. Remote servers or domain mode are not supported.
So clearly, for now, we can support the standalone local mode using the
same means as jboss-cli, but how should we proceed further?
Should we
(a) wait for WildFly to implement the missing functionality, or
(b) contribute to Wildfly or
(c) create a minimal Agent to install on remote servers to provide the
functionality missing in WildFly itself (as proposed by Heiko)?
Thanks,
Peter
11 years
