[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
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
1 year, 1 month
Re: [Hawkular-dev] Pushing 'hawkular-1275' branches to master (Done)
by Jay Shaughnessy
Note that the master branches now contain the Prometheus-based
components for:
hawkular-commons
hawkular-agent
hawkular-services
The hawkular-1275 branches are no longer in use. The proper Services
docker container label is now 'latest'.
On 12/15/2017 10:55 AM, Jay Shaughnessy wrote:
>
> At this point please refrain from generating PRs against the
> hawkular-1275 branches. We are in the process of migrating to
> master. The Hawkular Commons PR is generated, after it is merged we
> can merge Hawkular Agent, and then Hawkular Services. It should be
> completed no later than Monday.
>
> On 12/14/2017 9:18 AM, Jay Shaughnessy wrote:
>>
>> Note that this is for the server-side repos:
>> hawkular-commons
>> hawkular-agent
>> hawkular-services
>>
>> The provider side repos (ruby/miq) will remain in the hawkular-1328
>> branches hosted by Edgar's github account.
>>
>> On 12/13/2017 2:06 PM, Matthew Wringe wrote:
>>> Unless there is any objection, we would like to merge the
>>> hawkular-1275 branches to master and continue to work in the master
>>> branch.
>>>
>>> Once we are in the master branch we will also be moving towards a
>>> one PR per jira issue. The workflow in jira will require this and
>>> will automatically close the jira when a PR is merged.
>>>
>>> Thanks,
>>>
>>> Matt Wringe
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
8 years
Re: [Hawkular-dev] Pushing 'hawkular-1275' branches to master
by Jay Shaughnessy
At this point please refrain from generating PRs against the
hawkular-1275 branches. We are in the process of migrating to master.
The Hawkular Commons PR is generated, after it is merged we can merge
Hawkular Agent, and then Hawkular Services. It should be completed no
later than Monday.
On 12/14/2017 9:18 AM, Jay Shaughnessy wrote:
>
> Note that this is for the server-side repos:
> hawkular-commons
> hawkular-agent
> hawkular-services
>
> The provider side repos (ruby/miq) will remain in the hawkular-1328
> branches hosted by Edgar's github account.
>
> On 12/13/2017 2:06 PM, Matthew Wringe wrote:
>> Unless there is any objection, we would like to merge the
>> hawkular-1275 branches to master and continue to work in the master
>> branch.
>>
>> Once we are in the master branch we will also be moving towards a one
>> PR per jira issue. The workflow in jira will require this and will
>> automatically close the jira when a PR is merged.
>>
>> Thanks,
>>
>> Matt Wringe
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
8 years
problem with jmx exporter reading an attribute we need for availability
by John Mazzitelli
Ok, well, i hate to leave it like this but - this is so friggin' odd that I can only say "it is not my fault" :)
First - note someone changed jmx exporter code because they saw the same thing as we are - that's what this comment is about:
https://github.com/prometheus/jmx_exporter/blob/master/collector/src/main...
See: https://github.com/prometheus/jmx_exporter/issues/89
But the fix is not 100%.
If you grab these three files - you can see it yourself: https://github.com/jmazzitelli/test/tree/master/javaagent
(get Makefile and the two .java files and then run "make download-wildfly unzip-wildfly compile run")
You see i use the same API as the jmx exporter here: https://github.com/jmazzitelli/test/blob/master/javaagent/TestJavaAgent.j...
and that is what you will see:
16:31:05,290 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO [stdout] (Test Java Agent Thread) isRegistered:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) true
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getMBeanInfo:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) description: The root node of the server-level management model.
16:31:05,291 INFO [stdout] (Test Java Agent Thread) #attributes: 19
16:31:05,291 INFO [stdout] (Test Java Agent Thread) getAttribute:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) serverState=reload-required
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryMBeans:
16:31:05,291 INFO [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames(null, null):
16:31:05,291 INFO [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
16:31:05,291 INFO [stdout] (Test Java Agent Thread) =============================================================
You will see SOME JMX APIs can see the MBean, queryMBeans and queryNames canNOT (note the empty arrays []).
But notice getMBeanInfo CAN see it - I can even get the attribute value from that! (you can see it is in reload-required state)
But again, queryMBeans returns nothing.
Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.
The end result - JMX Exporter (at least sometimes) is not able to get "Server Availability" because it can't get this MBean.
For some odd reason it can get it sometimes - but it seems when it can't, it will never get it.
8 years
Tip: Hawkular running in Openshift on OS/X
by Mike Thompson
This pertains only to Hawkular services running on Mac OS/X via Openshift.
There is a small but critical detail that *must* be adjusted before running
Hawkular in Openshift on OS/X. *Not doing so will result in an
endless(almost) looping and crashing of pods *with very little information
because of the pod logs/events crash very close to startup.
The trick here is to make sure that the OS/X docker has enough memory
because the default is only 2 Gb, which is not enough to run
Hawkular/Cassandra. To adjust this setting go into docker preferences and
find the *Advanced* tab. There you can adjust the Memory and CPU. The
memory is set initially at 2Gb which is not sufficient for
Hawkular/Cassandra -- *adjust this to 8 Gb or more*.
[image: Inline image 1]
The feel free to run Hawuklar/Cassandra:
`oc new-project mm-app;oc process -f hawkular-services-ephemeral.yaml | oc
create -f -`
Hawkular Services Ephemeral Template
<https://raw.githubusercontent.com/hawkular/hawkular-services/master/opens...>
Special thanks to Matt Wringe and Matt Mahoney for their time and expertise
in diagnosing this issue.
[Jstickler, you may want to add this to documentation]
8 years
