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
11 months, 3 weeks
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
11 months, 3 weeks
Generic Hawkular-UI in MiQ
by Heiko W.Rupp
Hey,
the current way we implement the Hawkular-part of the MiQ ui is static,
where we write .haml files that show what properties and relations to
show.
Basically for each resource type one such page exists.
Adding a new kind of server like e.g. Apache Tomcat would need to add
a ton new .haml files.
In RHQ we had a pretty generic UI that was driven off of the metadata
inside the plugin descriptor. If a resource type had <operation>
elements,
then the UI showed the operations tab. Similar for the list of metrics
or the Events tab etc. Also for the resource configuration, the tab and
the
list of configuration properties was driven off of the plugin
descriptor.
See also [1].
The idea is now to apply the same mechanics to the ManageIQ UI so that
the resource type definitions coming from the agent can drive the UI.
We most probably need to extend the current config [2] to show
- what is shown by default
- how relations are to be shown
- which properties should be grouped together
The agent would store those in the resource type, which MiQ
can pull and build the UI from those definitions.
There is currently a rough spot: how to deal with one / more "competing"
WildFly RTs?
In RHQ we had the one canonical definition of a
resource type. Now each agent could send a different one. While
technically we can
work with that, it may be confusing if 2 WF-standalone look different.
It will not happen
often though - especially in container-land, where the config is "backed
into the image".
I wonder if we should change this way of inventory a bit to be similar
to RHQ (but more
simple):
- RT definition is done on the server
- agent asks for the RT definition on 1st start
- MiQ also gets the RT definition from the server.
With Inventory.v3 this may mean that some startup code needs to populate
RTs
and probably periodically refresh them.
Thoughts?
[1]
https://github.com/pilhuhn/misc_writing/blob/master/HowToWriteAnRhqPlugin...
[2]
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent...
8 years, 4 months
Openshift/k8s templates, tagged images vs IfNotPresent
by Pavol Loffay
Hi,
we are providing OpenShift and k8s templates for Jaeger project
https://github.com/jaegertracing.
What is the "standard" in the industry when providing *public* templates?
Should we use tagged versions of images or depend on IfNotPresent strategy
(pull image when not present)?
I would say that public templates should use tagged versions because it's
always tested against a specific version and therefore guaranteed that it
works as expected. This also seems to be the case templates provided by
fabric8 team. Another thing is that templates not using tagged versions
might get quickly outdated.
IfNotPresent may lead to weird states when a template is not compatible
with pulled image. Plus it does not allow to simply update deployment when
using tagged templates.
I'm just interested in what people think and use.
Regards,
--
PAVOL LOFFAY
Red Hat Česká republika <https://www.redhat.com/>
Purkyňova 111 TPB-B 612 45 Brno
M: +421948286055
<https://red.ht/sig>
8 years, 5 months
https://hub.docker.com/r/hawkular/*
by Jiri Kremser
Hi,
the Dockerhub is the image registry that is enabled by default for
dockerd. IMO, we can't support only our internal RH registries and ignore
the dockerhub. This is what we deliver to the community. Less and less
people are downloading zip files and installing stuff these days (or even
using package managers). If I want to try tool/product/project X (where X
can be prometheus, ) First thing that comes to my mind is to google for the
docker image and some short code (like `docker run -e foo=bar org/image`)
that I can copy&paste to the terminal and have everything set up correctly.
We have nothing like that today and that was 1 of the reasons, why I
started the hawkinit cli/tui tool.
Currently we have dozens of images there that are obsolete or that were
used for 1 particular use-case/demo. For instance the hawkular-metrics
https://hub.docker.com/r/hawkular/hawkular-metrics/tags/ has the latest
change before 2 years and contains bunch of images that have snapshot in
the tag. If I am a newcomer trying to play with hawkular-metrics, I would
run away quickly.
The very first image is the https://hub.docker.com/r/hawkular/hawkular/
which should be the "Hawkular", right? Last change is 1 year old and again,
for the newcomers it's hard to explain the fact that it's the old version
containing the old components, but it has the rich UI, while the new ones
have no UI, but new components.
Could you guys look and reply to this email if you want to preserve certain
image?
Currently these are 'maintained' and quite ok (I didn't go through all of
them):
* hawkular-services
* hawkular-openshift-agent
* wildfly-hawkular-javaagent
* wildfly-hawkular-agent-domain
* wildfly-hawkular-agent
* hawkular-website
* hawkular-grafana-datasource
* hawkular-openshift-agent-example-jolokia-wildfly (despite the name, (name
!= description))
... the rest seems to be abbandoned or was created for some demo and it's a
question if those images should be under the hawkular org, or if we
shouldn't move them to something like hawkular-labs or hawkular-examples,
or similar. I don't know.
One note to the naming: we have quite a lot of different agents without any
description or metadata in the image itself, what should I use and when? I
know that, mazz knows that and probably couple of other guys know that, but
people out there would have no idea.
Perhaps it would be good to have also some thoughts from people that are
relatively new in the team or work a lot with the d. images. Like Caina,
Paul, Josejulio.
wdyt, guys?
jk
8 years, 5 months
Application Performance Metrics within minishift
by Abdel Hegazi
Hi,
I am trying to find a way to visualize APM within each container running
which is something I am not able to do with Prometheus (I am running
Openshift Origin/ minishift)
With some help from google, I found this blog post from openshift guys
https://blog.openshift.com/performance-metrics-apm-spring-boot-microservi...
which (theoretically) is exactly what I am looking for but it looks like
nothing it really working as the documentation says as I am always hit by
this error message which I already posted at the comment section but no one
replied
ERROR: Neither $JAVA_MAIN_CLASS nor $JAVA_APP_JAR is set and 0 found in
/deployments (1 expected)
As I see the ENTRYPOINT is missing, so regardless the the value of the
$JAVA_OPTIONS env variable it doesn't look like it feels it.
So, with some more search I found this blog post by you which seemed great,
http://www.hawkular.org/blog/2017/03/25/collecting-application-metrics-op...
but the thing even starting $minishift --metrics but I am still not able to
receive any metrics as it always says metrics isn't enabled within the
cluster.
I tried to run some of the example mentioned wildfly, java, python ..etc
something is still missing, I am not able to find-out what should I do as
to get some metrics I am assuming all of these base images in all your
examples will have hawkular agent .jar injected within them so that they
should be able to export metrics to wherever endpoint, what I would like to
have either to visualize these metrics at grafana (which I assume via
prometheus) or at hawkular server interface.
Is there any working documentation which is actually updated and tested?
Thanks,
--
Abdel
8 years, 5 months
