On Tue, Jul 5, 2016 at 10:55 AM, Thomas Heute <theute(a)redhat.com> wrote:
On Tue, Jul 5, 2016 at 5:35 PM, Stefan Negrea <snegrea(a)redhat.com> wrote:
>
> On Tue, Jul 5, 2016 at 9:13 AM, Thomas Heute <theute(a)redhat.com> wrote:
>
>>
>>
>>
>> On Tue, Jul 5, 2016 at 4:05 PM, Stefan Negrea <snegrea(a)redhat.com>
>> wrote:
>>
>>> On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit :
>>>> >> 2) The Grafana plugin should be moved under Metrics because is
for
>>>> Metrics
>>>> >> > and only Metrics.
>>>> > If this is true - can we make it work with H-services as well?
>>>> >
>>>>
>>>> The Grafana plugin works with all active flavors of Metrics:
>>>> standalone,
>>>> Openshift-Metrics and Hawkular-Services.
>>>>
>>>> I'm not sure what Stefan meant.
>>>>
>>>
>>> The Grafana plugins works with Metrics deployed on all distributions
>>> however, the plugin itself can only be used with the Metrics project, there
>>> are no projects (such as Alerts, or Inventory) that will ever integrate
>>> with it. That is why I think it should be under the Metrics project and not
>>> in another place. The integration itself is very specific to just Metrics,
>>> not the entire Hawkular Services.
>>>
>>
>>
>> But then it applies to Hawkular services (the most important Hawkular
>> project) and then should really shine there as much as for Metrics.
>>
>> We really need to think of Hawkular Metrics as a core part of Hawkular
>> Services, not as a side project.
>>
>> Same for the documentation, the documentation to use metrics will need
>> to be part of Hawkular Services documentation, not just a mere pointer to
>> Hawkular metrics and let the user deal with the differences.
>>
>
>
> I am really not sure why the discussion took this turn, my comments were
> not about Services vs Metrics. To refocus on the Grafana plugin, the plugin
> is really specific to graphing actual metrics using the Metrics API only.
>
Let's not assume that people will take Hawkular Services and then combine
themselves what is available to the metrics users with Hawkular Services.
Hawkular Metrics really shines when used with Alerts and Inventory, let's
have that package easy to use and consume. And if it makes sense to add
alerts or inventory in the Grafana plugin, we should. Also if we have it
along the other clients, it's more consistent.
Thomas
To reiterate the point about the Grafana plugin. Grafana integration only
makes sense for Hawkular Metrics, because of the actual Grafana project
itself. If I have to pick where the put the documentation about the plugin
I would put it under the Metrics section because that is the only place
where it logically fits. A second option would be to leave it where you had
it on the last mindmap, under clients. To me it makes no sense to put it
under Hawkular Services, because the association between the two is done
through inference (Grafana connects to Hawkular Metrics, and Hawkular
Metrics is a service inside Hawkular Services, therefore Grafana plugin can
be used with Hawkular Services).
*tl;dr* Leaving the Grafana plugin documentation under Clients is the only
solution if the placing it under Hawkular Metrics documentation is not an
option.
>
>
>
>> Thomas
>>
>>
>>
>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev