hawkular openshift agent integration tests
by John Mazzitelli
(moving this thread to the mailing list for public consumption)
Mazz says,
> As for the Hawkular OpenShift Agent, note that there are no integration tests yet.
> I have no idea how to do that yet. I've got unit tests throughout, but not itests.
> Something we'll need to do eventually. Gotta figure out how to mock an OpenShift environment.
Matt says,
> For origin metrics we run e2e tests. So we point our test to our OpenShift instance,
> it will then deploy our metrics components (with the various different deployment options)
> and then check and see that everything deployed properly, there are no errors or restarts
> and that we can gather metrics.
>
> For the agent we might want to do something similar. I don't know how useful it would be
> to mock up an OpenShift environment when you can just have it directly use one.
>
> ... I would look to do this using the kubernetes client more directly and using a proper test framework.
Matt - I have a followup question:
Does this mean we would not be able to run itests on github commits via Travis? Not that that is a bad thing - I would not be heartbroken if I was told we will not be able to use Travis :) I'm just wondering if this means there will be no CI.
9 years, 4 months
Hawkular Alerting 1.3.0.Final has been released!
by Jay Shaughnessy
The Hawkular Alerting team is happy to announce the release of Hawkular
Alerting 1.3.0.Final.
This is a feature and fix release.
* [HWKALERTS-176] - Support conditions on missing events and data
o An *exciting* new alerting feature! This introduces
*MissingCondition*. MissingConditions let you generate alerts or
events when expected data fails to report, or when an expected
event does not happen.
* [HWKALERTS-174] - Add CORS filters
o Cross Origin Resource Sharing support allows for optional
request origin validation.
* [HWKALERTS-181] - Add clustering information on status endpoint
o The /status endpoint now reflects cluster topology!
* [HWKALERTS-175] - Improvements on webhook plugins
* [HWKALERTS-177] - Add new perf tests to study asynchronous send*() calls
Additionally, this is the first Hawkular Alerting release to deliver
Alerting features in *3* different distributions:
* The alerting engine used inside Hawkular Services and supporting the
Middleware Provider in ManageIQ.
* As a Standalone alerting engine for general use.
* And soon to be released, embedded inside Hawkular Metrics!!
For more details for this release:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versi...
Hawkular Alerting Team
Jay Shaughnessy (jshaughn(a)redhat.com)
Lucas Ponce (lponce(a)redhat.com)
9 years, 4 months
Hawkular OpenShift Agent is now available
by John Mazzitelli
(FYI: we had an "underwhelming" participation in the naming poll. What was decided upon was a more descriptive name rather than some code name anyway)
Hawkular OpenShift Agent source has been published on github.com here:
https://github.com/hawkular/hawkular-openshift-agent
For now, we'll track issues in github until we figure out what we want to do (if anything) in JIRA and where.
If interested, read the README - it provides build and run instructions.
Currently the Hawkular OpenShift Agent supports the following:
1) Watches OpenShift as pods and configmaps are added, modified, and removed
2) As things change in OpenShift, the agent adjusts what it monitors
3) All metric data is stored in Hawkular Metrics
4) Pods tell the agent what should be monitored via an annotation which names a config map. In that config map is a single YAML configuration that contains all the endpoint information the agent needs in order to monitor it and store its data. Pods can ask for multiple endpoints to be monitored, and multiple pods within the node can be monitored - but only one node is monitored. If you have multiple nodes, you need one agent per node.
5) Each endpoint data can have its data stored in its own tenant (as defined in the config map yaml)
6) The agent can monitor any endpoints you define in the global agent config file also - you don't need to have pods/config maps for this (this is useful if the agent is running outside of Open Shift or there are some things in the agent's node that you want monitored without having to look up pods/configmaps).
7) Currently, Prometheus endpoints are supported (both binary and text protocols).
There are many things we need to get done.
* Jolokia support is not yet implemented
* Secure access (encryption and authentication) to both Hawkular-Metrics and the metric endpoints
* Details on how to run the agent within Open Shift (daemon set?)
* Tag the metrics being stored (there are no tags being associated with the metrics yet)
* Determine the names of the metrics (right now its just using the names of the prometheus metrics as-is)
* etc, etc, etc
Many thanks to Matt Wringe who got this kicked off with his ideas and Open Shift integration code which was the foundation of the current codebase.
--John Mazz
9 years, 4 months
OpenShift Pet vs Cattle metaphor
by Jiri Kremser
Hello,
today, I was on L&L about storage in OpenShift and I learn interesting
thing. I always thought, that everything needs to be immutable and
stateless and all the state needs to be handled by means of NFS persistent
volumes. Luckily, there is a feature in Kubernetess (since 1.3) that allows
the PODs to be treated as pets. It's called PetSet [1] and it assigns a
unique ID (and persistent DNS record) to a POD that runs in this "mode".
Common use-case for PetSet is a set of pods with a relational DBs that uses
some kind of master-slave replication and slaves needs to know the master's
address. But it can be used for anything. We can use the hostname as the
feed id for instance.
I don't know how much this will be popular because it kind of defeats the
purpose of immutable infrastructure but it can save us some work with the
feed identity. And of course we need to support also the "normal" POD
scenario.
[1]: http://kubernetes.io/docs/user-guide/petset/
jk
9 years, 4 months
New repo for various travis scripts?
by Joel Takvorian
Hi,
I just wonder if we should create a new git repo to store the different
files that are required for integration tests on the hawkular clients
(ruby, java, now dropwizard...). For now there's just 2 required files
afaik: ".travis/wait_for_services.rb" and the docker-compose file, but
there may be more in the future.
So, rather than storing a copy of each file in each client that use that
docker-based integration tests, isn't it better to store them in a new repo
and download them from travis script?
There's also a maven install script that I picked from inventory and copied
to the java client repo, that would fit in this scripts repo as well.
Joel
9 years, 4 months
open shift agent - what to call it?
by John Mazzitelli
OK, folks, as much as I hate these "what should we name this thing?" threads, I have to do it.
We are at the point where we are going to start going full-throttle on building out an agent that can monitor things on Open Shift (and Heiko wants to be able to monitor things outside of Open Shift - I'll let him chime in on what his use cases are to get a better feel for what he's thinking)
We need a name ASAP so we can create a repository under the Hawkular github namespace and put the code up there so people can start working on it. I would like to do this sooner rather than later - say, by Thursday???
Matt was thinking "hawkulark" (Hawk-U-Lark, Hawkular-K) because "k" == kubernetes.
I was thinking "GoHawk" (rhymes with "mohawk") because it is implemented in "Go"
I wasn't keen on relying on "kubernetes" as part of the name since its really targeting Open Shift and even then doesn't have to run in Open Shift (back to the ideas Heiko has for this thing).
"GoHawk" doesn't seem to be a winner simply because what happens if we implement other hawkular feeds in Golang?
I'm assuming we'll come up with a name and agree to it collectively as a group - but I nominate Thomas H, Heiko R, and John D. as the committee to give the final approval/tie-breaking authority :) It won't be me. I suck at coming up with names.
--John Mazz
P.S. Who knows how to setup one of those online polls/surveys where you can enter your submissions and vote for other submissions?
9 years, 4 months
gohawk - need Go code to write to H-Metrics
by John Mazzitelli
I am close to having GoHawk [1] be able to take flight :) He's still a fledgling, not quite ready to leave the nest yet.. but close. I could even demo what I got if some folks are interested in learning how GoHawk is configured (YAML!!!), seeing it react to changes to an Open Shift node environment on the fly, collecting Prometheus data, and mock-storing the metrics to h-Metrics.
BUT! Right now I'm at the point where I need code that writes data to Hawkular Metrics from a Go client. Anyone have code that shows how to do this? This isn't code that QUERIES the H-Metrics for existing metric data - it is code that WRITES metrics to Hawkular Metrics. I already have a array of MetricHeader objects ([]metrics.MetricHeader) - I just need code that builds up the HTTP request and sends it (including any encryption/credential parameters/settings required?).
[1] https://github.com/jmazzitelli/gohawk
9 years, 4 months
