Maven swagger plugin
by Gary Brown
Hi
The current version of the maven-swagger-plugin used by hawkular doesn't include derived types in the generated docs.
I've tried updating to 2.3.4 and it still does not work. From some basic tests with 3.0.0, it seems to produce the correct content in the json schema - but has slightly different attributes to the plugin configuration, which when updated does not seem to run the template correctly.
The other issue is some API changes when updating the com.wordnik:swagger-* dependencies in line with this maven plugin, as there have been some GAV and API changes.
Its not an urgent issue, but it looks like we will be impacted by changes when we need to upgrade, so thought I would raise the issue.
Regards
Gary
8 months, 4 weeks
[GSoC] Hawkular Android Client
by Artur Dryomov
Hi everyone,
This year I will be working on the Hawkular Android client application as
part of the Google Summer of Code 2015 program.
The application itself will use Hawkular API and AeroGear SDK. In coming
days I’ll research these areas, especially documentation, and will try to
create some sort of architecture and basic design.
Thank you all for this opportunity!
Artur.
1 year
Hawkular Metrics Openshift Containers
by Matt Wringe
I have a new subproject in Hawkular Metrics which sets up creating
components for Openshift/Fabric8
(https://github.com/hawkular/hawkular-metrics/pull/200).
There are 3 main parts
Cassandra: creates a custom seed provider to support
ReplicationControllers in Kubernetes, creates a folder/zip archive which
can be used to generate a Docker image. It may make sense to move the
Cassandra parts out to a separate project.
Hawkular Metrics: creates a folder/zip archive which can be used to
generate a Docker image
Kubernetes: pulls everything together into a single kubernetes
application. Can be used to deploy an application zip into fabric8 (via
drag and drop in the web console or via the maven plugin) or deploy all
the components into Openshift via the kubernetes.json configuration file.
The docker images are not created and deployed to a docker registry as
part of the build, it will just create a folder where you can run the
docker build from. None of the maven docker plugins I looked at seemed
to really work properly, so its still a manual process to do the build
(and push to a registry). Its something which needs to be improved.
The Cassandra service currently only supports adding new nodes to a
cluster and not removing them via the ReplicationController. This is due
to the replication factor being set to be 1 by default (which means when
a node is removed, so is the data it contained).
I believe the docker subproject of hawkular metrics is obsolete and can
be removed
(https://github.com/hawkular/hawkular-metrics/tree/master/docker), but
someone please correct me if I am wrong. It's scripts are referring to
the console which no longer exists as part of the project.
- Matt
1 year, 1 month
Tenant Id - Not Part of URL
by Stefan Negrea
Hello Everybody,
I've been working on a PR for the upcoming Hawkular Metrics release that will remove the tenant id from the end-point URLs. The tenant id will be moved to either a header parameter or a query parameter. The query parameter is in place for cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
Here is an example of the change:
Existing URL:
/{tenantId}/gauge/{metricId}/data
New URL:
/gauge/{metricId}/data
Tenant id set via:
1) header - tenantId
2) query parameter - tenantId
There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
Now, to the merits of this change. The tenant id is volatile, can change any time, and changes to it should be expected; but the rest of the URL is fixed. The second issue is that the tenant id is a security concern. So we were limited in design choices since a security concern was leaking as part of the URL.
So removing the tenant id from the URL will give us permanent & consistent addresses for resources (metrics and metric data points). And we will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id to be used on the request. If the same user later decides to use a tenant id to pass along the request, the URL of the resources would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret).
This change will give us the flexibility to adjust the security model (the meaning of tenant ids and ways to validate them) without compromising the URL structure. This will help Hawkular Metrics as it gets integrated into more and more projects and products.
Here are the links to the JIRA and the PR for this change:
https://github.com/hawkular/hawkular-metrics/pull/202
https://issues.jboss.org/browse/HWKMETRICS-68
Thank you,
Stefan Negrea
Software Engineer
1 year, 1 month
On the way to the M1 release ...
by Heiko W.Rupp
Hey,
I see those things that need (at least) to be done/fixed for the next
Wed release:
- pinger does not respond to deletions (HAWKULAR-235/-263)
- inventory does not delete metrics on resource deletion HWKINVENT-45
(if INV can not make it, can UI send the delete metrics requests ?)
- duplicate URL addition HAWKULAR-255
- alerts is not multi-tenant yet (PR is sent, but may be too disruptive
?) HWKALERTS-40
-- Add url fails across tenants for same url (HAWKULAR-277 contains a
possible solution)
-- marking alerts as resolved (needs above PR for the backend)
- working pagination
- working availability charts
- move everything on non-snapshot releases
- update / write documentation on hawkular.org
As we will most probably not have full app servers functionality,
we should disable that tab so that users are not confused by it
and re-enable and work on it after the release.
Similar for the embedded agent.
Can we please concentrate on the above (and what else is needed that is
not yet on the list) to get
the release out?
10 years, 6 months
Hawkular Metrics 0.3.4 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.3.4 of Hawkular Metrics. The release is anchored by stability improvements and Docker + Kubernetes work.
Here are the release highlights:
1) InfluxDB Compatibility Layer
- pretty printing of query results with the 'pretty' query parameter
- absolute moment operands in queries (ex: select * from test where time > 1501560s and time < 4560546h)
- various fixes which allow to integrate nicely with Grafana (declaring Hawkular Metrics as an InfluxDB 0.8 datasource)
2) RxJavaMigration
- big refactoring to use RxJava instead of Guava's ListenableFuture
- RxJava provides a much richer API for building asynchronous programs
3) Server Start-up
- the server no longer requires Cassandra to be started first
- any client requests will get back a 503 response code if the server has not fully initialized due to Cassandra being down at start up time
4) Docker and Kubernetes
- all project docker images are now available in Docker Hub! Get them here:
https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
- improved replication controller support now means that both the Hawkular-Metrics and Cassandra images can be scaled up or down
- various other smaller improvements, including better support for when containers startup
5) REST API (IMPORTANT!)
- tenantId header was renamed to Hawkular-Tenant
- tenantId header fallback was removed
- GET {id}/tags only returns the tags, not the whole definition anymore
- GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known issue)
6) UI Explorer
- was removed from the project
- discussions are underway to find a new home for the functionality and code (probably hawkular-ui-components)
- npm is no longer required to compile the project
7) Task Queue
- a generic task queue was designed and developed as part of this release
- provides functionality for scheduling and executing background tasks or jobs
- task execution is
scalable - automatically distributed among Hawkular Metrics servers
durable - Tasks are persisted
fault tolerant - Tasks are rescheduled for future execution when there is a failure
- it will serve as the foundation for
computing/storing aggregated metrics (i.e., rollups)
deleting metrics
changing data retention
- this functionality will be basis for any background task based design for the project
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.4
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327259/
Hawkular Metrics 0.3.5 and Beyond
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.3.5.
2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. The plan for 0.3.5 is to increase coverage.
3) Improved Docker and Kubernetes support - this is a long term goal for the project
4) RXJava - the initial transition from Guava was done in 0.3.4. Future releases will build upon this foundation.
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, and Heiko Rupp for their project contributions. Special mentions go to Jeeva Kandasamy and Jirka Kremser for their project help.
[1] https://issues.jboss.org/browse/HWKMETRICS-110
Thank you,
Stefan Negrea
Software Engineer
10 years, 6 months
new agent to support port offsets
by John Mazzitelli
This is for https://issues.jboss.org/browse/HAWKULAR-285 . I presume supporting port-offsets is so we can run integration tests on different ports so they don't step on other app servers running on the same machine.
I fixed this in the agent - it now gets address/port values the "official" WildFly way via socket-binding-group/socket-binding (that is, we use the same configuration mechanisms all other WildFly subsystems use). This also fixes the issue of having to have ${jboss.bind.address} and ${jboss.http.port} variables in the agent's "url" attribute. That's because the "url" attribute is no longer required.
You will notice now the agent running in kettle doesn't configure any URL in <storage-adapter>. That's because the default is to assume it is running co-located with the server components, in which case the agent will look at the <socket-binding> for "http" and use its address and port (defined in the normal WildFly location down at the bottom of standalone.xml). So you can use port offsets and it will work.
To support agents running external from the server components, there is a new attribute in the agent's <storage-adapter> called "serverOutboundSocketBindingRef". If this is set, you must have a <outbound-socket-binding> setting of the same name in your socket-binding-group. This defines where your hawkular server is. The agent will use those socket binding settings to know where to talk to Hawkular server components. For example, if your agent has this:
<storage-adapter serverOutboundSocketBindingRef="hawkular" ... />
You need to tell WildFly (and hence the agent) about that outbound binding in the socket-binding-group like this:
<socket-binding-group default-interface="public" name="standard-sockets" port-offset="${jboss.socket.binding.port-offset:0}">
...
<outbound-socket-binding name="hawkular">
<remote-destination host="your-external-hawkular-server-hostname" port="8080"/>
</outbound-socket-binding>
...
When you do this, the agent will use "http://your-external-hawkular-server-hostname:8080" as its URL to the hawkular server.
This will get into kettle when this PR is merged: https://github.com/hawkular/hawkular/pull/162
10 years, 6 months
logging categories
by John Mazzitelli
I created a JIRA [1] and PR [2] so that when we build a dev build you'll get the console to show DEBUG log messages. In production mode, it stays at INFO level. I also added additional logging categories - double check that I added your component's logger categories correctly. In addition, I removed xsl:if checks and changed to xsl:choose in the .xsl.
Merge at your earliest convenience, please :)
[1] https://issues.jboss.org/browse/HWKINVENT-55
[2] https://github.com/hawkular/hawkular/pull/149
10 years, 6 months
