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
9 years, 2 months
The components, glue and kettle
by Gary Brown
Hi
On yesterday's watercooler discussion the main topic was about how to package the individual components, with the "glue" code, within kettle.
There seems to be a general idea to move all bus integration code into Hawkular/Kettle repo. Although I agree that the kettle is the right place to bring together the components and glue, not sure whether the actual code for the glue should reside in that single repo.
My preference would be for all component related code, including that component's integration with the bus, to be located in that component repo - that way there is a clear owner of the code, and any changes to the core APIs are locally dealt across all integration points that may be supported.
Then the kettle repo can be responsible for selecting the relevant artifacts to build what it requires.
In terms of how the 'core' artifacts from each component should be enhanced with the glue - may be the simplest way would be as one person suggested - use an overlay to build upon the 'core' war artifact to add the glue artifacts (which in general will probably just be bus integration). So each component only needs to produce a single 'core' war, but also manages the integration artifacts locally.
I think I would prefer this approach over a single ear, as it still retains the individual component boundaries but enhances them with whatever they need to communicate in the kettle.
It would be even more ideal if jboss modules allowed exploded wars, so that we didn't need to use overlays, but I don't believe this is the case.
Regards
Gary
9 years, 2 months
Plans for Alerts UI
by Gary Brown
Hi
As mentioned at the F2F, one of the things I need to do with BTM is ensure that it will be capable of providing equivalent functionality that is currently in RTGov.
If Alerts are used in place of RTGov Situations, then from the UI the user would need to be able to perform various tasks when focused on a particular alert, including viewing/editing a message for resubmission to the originating service, navigate to the business transaction instance view, etc.
It would be useful if there was a way to provide plugins to the alerts UI to register actions that could be performed, or contribute additional UI tabs that can perform capabilities related to the selected alert.
Is this going to be technically possible with hawt.io/angular to add such extension points?
What is the best way to proceed - should I just create a jira for now?
Regards
Gary
9 years, 2 months
Packaging
by Thomas Heute
I would prefer if the whole WF packaging/layering would happen in
Hawkular rather than with multiple layers of packaging as it is today.
So far I have done 2 things:
1 - Basically renamed Kettle to Hawkular (+ few extras). kettle
directory is now 'dist' which should be more intuitive.
https://github.com/theute/hawkular/commit/e2b937b467e4ed8c184b51add5af7b5...
2 - Bring the nest distro build from Bus to Hawkular:
https://github.com/theute/hawkular/commit/84ed6f505a5db73ecf9264c1bc8dea3...
I understand that there could still be need for the nest (I think
Alert uses it for testing) but I find the double customization of WF
quite complex.
My next items unless I am stopped:
- Fix the docker build as I guess I broke it
- do more proper WF layering (not use 'modules/base')
- understand "hawkular-nest-wf-extension" ;)
- upgrade to WF9
- update the docs
Thomas
9 years, 2 months
Branch Kettle?
by Jay Shaughnessy
Related to the "Adding git SHA1 & Co. to manifest.mf to improve
traceability" thread...
In the interim between now and when we move to strong versioning could
we perhaps just create a "stable" branch for kettle? Note the term
"stable" as opposed to "release" or something like that. This idea was
kicked around at the F2F as a possible solution.
The stable branch would have poms updated with non-snapshot versions of
the components and so would be reproducible. It could be used for demos
without fear of snapshot regression. It could be used by QE for
test-case development and [non-release] qualification. Kettle itself
could be versioned, bumping it's version whenever a consumed component
version was updated.
Components would be required to make at least an initial release to get
things going, and then should make subsequent releases at relatively
short intervals, maybe every few weeks.
Will this work and be helpful?
9 years, 2 months
Event Store
by Gary Brown
Hi
As discussed yesterday, we need a general event store that can persist relevant events off the bus. However we didn't decide where this functionality should reside, whether in an existing component or in a new component.
Although it could be provided as a separate component, I am not sure we have any use cases where it would be used independent of the bus, so think it is probably best to include it as additional functionality within the Bus component.
Agree/disagree?
The other issues are:
- how to determine which events should be persisted, as we may want some events to trigger further processing by subscribers on the bus, but not necessarily be stored for historic analysis.
- for the event store we will need to know the type of the event being stored
So one possible solution to both these issues is, if the 'type' of the event is provided (possibly as a header value), then it will be persisted?
Then within Elasticsearch, we can use the tenant/persona as the Index (to truly segment the data) and the event type to ensure different information types are partitioned/indexed appropriately.
Thoughts?
Regards
Gary
9 years, 2 months
