[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.
2 days, 10 hours
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
2 days, 10 hours
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
2 days, 10 hours
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
2 days, 10 hours
New and noteworthy in hawkular-parent 25
by Peter Palaga
Hi *,
hawkular-parent 25 brings the following:
* srcdeps-maven-plugin 0.0.5
* meets the promisses falsely done for 0.0.4:
* less console output
* built without tests
* wildfly-maven-plugin 1.1.0.Alpha4
I have sent PRs to all components repos.
Thanks,
Peter
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2 days, 10 hours
Hawkular Alerts 0.6.0.Final Released!
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)
8 years, 10 months
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
8 years, 10 months
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
8 years, 10 months
