Titan 0.5.4 with Cassandra 3.3
by Peter Palaga
Hi *,
Short version: I want to release our own fixed Titan 0.5.4-jboss-1 that
works with Cassandra 3.3
Long version:
Titan is a graph database used by Hawkular Inventory. ATM, we use Titan
0.5.4 with Cassandra 2.x.
As I already noted elsewhere, Titan 0.5.4 requires Guava 15 that is
incompatible with Guava 18 required by the newest c* 3.x Driver. The
conflict seems to be solved in the titan05 branch [1] in the
thinkaurelius repo. I asked both their release engineer directly and on
their mailing list [2] if they could release Titan 0.5.5, but got no
reply so far. It does not look like we can hope for a release from them
soon.
Therefore, I propose the following:
* I'll fork Titan code from their 0.5.4 tag
* I'll apply the changes necessary for Titan 0.5.4 to work with
Cassandra 3.3
* I'll change the groupId from com.thinkaurelius.titan to org.hawkular.titan
* I'll release the result as Titan 0.5.4-jboss-1
This should be just a temporary solution till Inventory is migrated to
Titan 1.0 API that should work with the newest Cassandra.
Are there any concerns about this proposal?
[1] https://github.com/thinkaurelius/titan/tree/titan05
[2]
https://groups.google.com/forum/#!searchin/aureliusgraphs/0.5.5/aureliusg...
Thanks,
Peter
9 years, 12 months
Hawkular Metrics - /data enpoint
by Stefan Negrea
Hello Everybody,
I submitted today a PR for a long standing JIRA:
https://issues.jboss.org/browse/HWKMETRICS-24 ; here is a related one:
https://issues.jboss.org/browse/HWKMETRICS-57 , and the PR:
https://github.com/hawkular/hawkular-metrics/pull/473
The JIRAs recommend splitting '*/data' endpoint in two separate endpoints,
'/raw' and '/stats'. There are two issues with the current '*/data'. First,
the code was really hard to maintain because it was serving two purposes.
Depending on the input parameters, the endpoint would serve raw ingested
data in some cases and bucketed results in some other cases. The PR still
has the old code (since it got just deprecated in this release) and it's
not pretty. The second problem was the actual API interface. There was no
simple way to know exactly what you get back from the endpoint because
sometimes it would return simple data points and sometimes bucketed data.
This was based on the query parameters specified in the request. And to
make things worse, some parameters could not be mixed, for example, the
user could not limit or order bucketed results; but the documentation had
to include all under the same endpoint.
The plan is to deprecate existing '*/data' endpoints in the upcoming
release (0.15.0) and remove them in the release after that (0.16.0). That
gives enough time (roughly 2 months) for all existing projects to migrate
to the newer API. Does anybody see any problem with this timeline?
I expect the transition to be simpler because most of the consumers were
using '*/data' with the intent to get bucketed results, which is now
'*/stats'. So it is just a simple change in most cases.
Are there any projects negatively affected by this change in the long-term?
Does the change make sense? Is the API interface for retrieving data easier
to understand after the change?
Thank you,
Stefan Negrea
Software Engineer
10 years
A better mechanism to import events from Hawkular to MiQ?
by Jay Shaughnessy
Jkremser, and anyone,
So I've now got some code working that can move Hawkular events (events
stored via H Alerts) into MiQ as MiQ Events. As a note, not every
Hawkular event will be a MiQ event because MiQ requires that supported
event types are predefined. This mail is more about the mechanism used
to move the events...
I've started with a primitive mechanism, it's a looping REST Get with an
advancing time window, using the H Alerts rest api via the
hawkular-ruby-client. This has a variety of potential issues, for example:
* Any Hawkular events generated when MiQ isn't running will likely be
missed.
* If the timestamps reported on the events are behind the MiQ polling
window they will be missed. (late arrival, possibly a hawkular
server time a bit behind MiQ server time).
* Potentially excessive polling if the number of events is not large.
Certainly some of these issues could be softened with a little more
provider-side smarts, like querying more into the past and protecting
against duplicate event storage, etc. But I'm wondering what thoughts
people may have on a better mechanism. I know other providers in MiQ
use a variety of techniques to import data, from polling, to blocking
HTTP requests, to queue listeners. I should mention that the general
approach of an MiQ provider is to provide an "Event Catcher", which runs
in a handler process for each provider instance. The catcher is
basically told by MiQ to go get events and then queues them for MiQ
consumption. Let me know what you think. Also, if anyone would like
to see a short demo of what I have right now I'd be happy to run a short
meeting.
10 years
Termin gestrichen: Hawkular-Team Update - Di 5. Apr. 2016 3:30PM - 4PM (hrupp@redhat.com)
by hrupp＠redhat.com
Dieser Termin wurde gestrichen und aus Ihrem Kalender entfernt.
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 5. Apr. 2016 3:30PM - 4PM Berlin
Wo: pc 204 2160 481
Kalender: hrupp(a)redhat.com
Wer
* Heiko Rupp - Organisator
* Mike Thompson
* Gabriel Cardoso
* gbrown(a)redhat.com
* Jiri Kremser
* Thomas Segismont
* miburman(a)redhat.com
* theute(a)redhat.com
* Simeon Pinder
* Peter Palaga
* lkrejci(a)redhat.com
* snegrea(a)redhat.com
* John Mazzitelli
* hawkular-dev(a)lists.jboss.org
* jcosta(a)redhat.com
* John Sanda
* amendonc(a)redhat.com
* Jay Shaughnessy
* Lucas Ponce
* mwringe(a)redhat.com
Einladung von Google Kalender: https://www.google.com/calendar/
Sie erhalten diese E-Mail unter hawkular-dev(a)lists.jboss.org, da Sie ein
Gast bei diesem Termin sind.
Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem
Termin zu erhalten. Sie können auch unter https://www.google.com/calendar/
ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen für
Ihren gesamten Kalender steuern.
Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger Ihre Antwort
auf die Einladung ändern. Weitere Informationen finden Sie unter
https://support.google.com/calendar/answer/37135#forwarding
10 years
[Metrics] How to react on low disk?
by Heiko W.Rupp
Hey,
<captain_obvious>
so for Hawkular-metrics (and Hawkular) we store the data in a Cassandra
database that puts files on a disk,
which can get full earlier than expected (and usually on week-ends). And
when the disk is full, Metrics does not like it.
</captain_obvious>
What can we do in this case?
I could imagine that on the C* nodes we run a script that uses df to
figure out the available space and tries
to run some compaction if space gets tight.
Of course that does not solve the issue per se, but should give some air
to breathe.
Right now I fear we are not able to reduce the ttl of a metric/tenant on
the fly and have metrics do the right thing - at least if I understood
yak correctly.
That script should possibly also send an email to an admin.
In case that we run Hawkular-full, we can determine the disk space and
feed that into Hawkular for Alerts to pick it up and then have the
machinery trigger the compaction and send the email.
10 years