4:03 p.m.
Making sure we don’t break clients is the most important aspect of this; however, there
are some other questions I want to throw out. Today we only support clients adding raw
data points. What if in the future though we add support for complex types like histograms
and allow clients to directly store them. Would clients post that data to /raw, /stats, or
something else?
Today we compute aggregated metrics at query time. We are going to add support for
pre-computed aggregate metrics that are persisted. Do we have different endpoints for
each? I haven’t thought about it too much yet, but I don’t separate endpoints is the way
to go.
With HWKMETRICS-373, we are introducing support for tag based bucketing as opposed to the
date range bucketing already have. There are some minor differences in the data structures
returned in the response, namely a map is returned instead of an array. Should we have a
different endpoints for tag based buckets vs date range buckets?
We currently have one increasingly complex method to handle queries for raw data, various
permutations of date range buckets, and eventually tag based buckets once my changes for
HWKMETRICS-373 are merged. These changes definitely will simplify things on the server
side, but do they simply or otherwise improve things for clients? I am a little concerned
that we might be letting our implementation bleed into the API a little too much. For
example, we segment our data in our schema design by metric type. Do we necessarily need
to do that everywhere in the API?
On Apr 4, 2016, at 10:21 AM, Matt Wringe <mwringe(a)redhat.com>
wrote:
----- Original Message -----
> From: "Heiko W.Rupp" <hrupp(a)redhat.com>
> To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
> Sent: Monday, April 4, 2016 4:56:15 AM
> Subject: Re: [Hawkular-dev] Hawkular Metrics - /data enpoint
>
> On 2 Apr 2016, at 0:24, Stefan Negrea wrote:
>> The plan is to deprecate existing '*/data' endpoints in the upcoming
>> release (0.15.0) and remove them in the release after that (0.16.0). That
>> gives enough time (roughly 2 months) for all existing projects to migrate
>> to the newer API. Does anybody see any problem with this timeline?
>
> Yes.
> There are users out there that use the old api in production.
> They may not even be aware that there is a new one.
>
> If they deploy the new hawkular-metrics (or someone does
> for them), their apps will break and they may not even know
> why.
+1
I think we need to make sure that we don't break the existing API for current users
who are already using it. There will most likely be a bunch of complaints if we update
this in OpenShift and then everyone's setup stops working.
> REST allows for content negotiation. So we should keep the
> old endpoint, deprecate them (and perhaps even spit regular
> warnings in the logs) and on top add the new endpoints
> that you suggested but with a new content type
> like "application/json+hawkular-v2".
If we are going to introduce a new version for the REST API, it might make sense to
release Hawkular Metrics with a new major version as well. But major versions can be
tricky depending on how the project handles them. Some projects will have the same major
versions for years, others will update the major version almost monthly (eg kernel version
versus browser version)
> In fact if we keen old and new, that new content type
> is not exactly needed if the data format exchanged does not
> change.
>
> Btw: I doubt that GET ../data and POST ../data is confusing anyone
> and in Jax-Rs you can have those on two different methods anyway.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>