From ploffay at redhat.com  Mon Jul  3 03:31:16 2017
From: ploffay at redhat.com (Pavol Loffay)
Date: Mon, 3 Jul 2017 09:31:16 +0200
Subject: [Hawkular-dev] Blogs on Hawkular.org and DZone.com
Message-ID: <CAKLecW93n1=5iw2ZTSqDnPtziwr538WkMeywC4mauU3mFA82HA@mail.gmail.com>

Hello bloggers!

I have a good news! Editors from DZone[1] are watching our blog. If you
post an interesting article there is a chance that they will migrate it
onto DZone. However, It's a manual process and they are watching several
sites so they might miss some interesting articles.

We can still manually share articles on DZone and link them with
hawkular.org. It's a preferred way if you want to be sure that your article
will be shared there!

[1]: https://dzone.com/

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170703/03bd80b2/attachment.html 

From snegrea at redhat.com  Mon Jul  3 17:42:36 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 3 Jul 2017 16:42:36 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
Message-ID: <CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>

Hello Everybody,

I waited about 2 weeks to allow enough time for feedback. There was a good
amount of initial discussion on the document mostly in the form of
proposals to enhance the initial plan. There were zero negative comments
and nobody opposed the plan.

I just submitted the first PR that cleans up the front page and navigation
bar (https://github.com/hawkular/hawkular.github.io/pull/325). I would
appreciated a reviews.


Thank you,
Stefan Negrea


On Wed, Jun 21, 2017 at 5:18 PM, Stefan Negrea <snegrea at redhat.com> wrote:

> Hello Everybody,
>
> I would like to kickstart "Redux Initiative" for the Hawkular website. The
> goal is to refocus the message and information presented on the website to
> core active Hawkular projects and nothing more.
>
> I created a document that outlines the plan ("How" section), the
> modifications ("Changes" section), and a visual map of the initial cleanup
> stage ("Visual Changes" section). This document was created with feedback
> from Hawkular contributors and was triggered by a very insightful
> interaction with a manager from Open Innovation Lab.
>
> How to participate? The "How" section of the document outlines the big
> plan. First step is to reach consensus on the changes. Please, read the
> document, comment on the proposal, and participate in the discussions that
> might spark here.
>
> The document: https://docs.google.com/a/redhat.com/document/d/1XsB_
> DzMjjG7QjJw-kX41PeuU9EMNjAm9PIBVadK2z4w/edit?usp=sharing
>
>
> Thank you,
> Stefan Negrea
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170703/70cf6bd0/attachment.html 

From hrupp at redhat.com  Tue Jul  4 03:22:17 2017
From: hrupp at redhat.com (Heiko Rupp)
Date: Tue, 04 Jul 2017 09:22:17 +0200
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
Message-ID: <2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>

Hey,

On 3 Jul 2017, at 23:42, Stefan Negrea wrote:

> I waited about 2 weeks to allow enough time for feedback. There was a 
> good amount of initial discussion on the document mostly in the form 
> of proposals to enhance the initial plan. There were zero negative 
> comments and nobody opposed the plan.

I know I did not chime in on the document, so have no right
to complain now :-)

I think though that the removal of Hawkular Services is wrong.
It may indeed at the moment only exist for that one consumer,
which is ManageIQ, but not listing it is in my opinion also
confusing. Instead of removing it, we should perhaps better
educate visitors of the web site (in a graphical way?) how this
relates to the other projects.
Similar to Tracing. This is no longer Hawkular APM, so it is right
not to list Hawkular APM, but so far Tracing folks are still under the
Hawkular umbrella and the blog contains a lot of content about it.

From gbrown at redhat.com  Tue Jul  4 03:38:09 2017
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 4 Jul 2017 08:38:09 +0100
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
Message-ID: <CAKpA_JW=i4ssbOnPB9Grq8s86YPwohRvZXcAE_WM87H3DF3yjQ@mail.gmail.com>

The aim is to add a "Tracing" entry as a "stage 2", but wasn't sure whether
this meant releasing a version of the website without it first, and then
introduce it as a separate step?

A general comment - perhaps we should drop the "Hawkular" part from each
component - so then we simply have "Metrics", "Alerts" and "Tracing"?


On Tue, Jul 4, 2017 at 8:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:

> Hey,
>
> On 3 Jul 2017, at 23:42, Stefan Negrea wrote:
>
> > I waited about 2 weeks to allow enough time for feedback. There was a
> > good amount of initial discussion on the document mostly in the form
> > of proposals to enhance the initial plan. There were zero negative
> > comments and nobody opposed the plan.
>
> I know I did not chime in on the document, so have no right
> to complain now :-)
>
> I think though that the removal of Hawkular Services is wrong.
> It may indeed at the moment only exist for that one consumer,
> which is ManageIQ, but not listing it is in my opinion also
> confusing. Instead of removing it, we should perhaps better
> educate visitors of the web site (in a graphical way?) how this
> relates to the other projects.
> Similar to Tracing. This is no longer Hawkular APM, so it is right
> not to list Hawkular APM, but so far Tracing folks are still under the
> Hawkular umbrella and the blog contains a lot of content about it.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/7d94be73/attachment.html 

From jtakvori at redhat.com  Tue Jul  4 03:41:33 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Tue, 4 Jul 2017 09:41:33 +0200
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
Message-ID: <CAJo5TFkN+kK4cF2uzC1BxUsLs4W=KwAQFnw_SB9=xwYxYP9UWw@mail.gmail.com>

On Tue, Jul 4, 2017 at 9:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:


> I think though that the removal of Hawkular Services is wrong.
> It may indeed at the moment only exist for that one consumer,
> which is ManageIQ, but not listing it is in my opinion also
> confusing. Instead of removing it, we should perhaps better
> educate visitors of the web site (in a graphical way?) how this
> relates to the other projects.
>

I'm sure we have stats on what people downloads the most... is it
metrics/alerts standalone, or services? We could take it in consideration.
Having it removed from the menu really makes things clearer, I think, but
on the other hand we could find ways not to make it completely off the
radars. For instance, adding something at the top of metrics/alerts install
page: "Looking for integrated metrics + alerting? Check out Hawkular
Services".

Another thing about services disappearing: the shame is that IMO it
currently has a better-written doc than metrics (the quickstart guide is
good, the installation guide is better than metric's simple link to github).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/0305ffe2/attachment.html 

From theute at redhat.com  Tue Jul  4 03:41:55 2017
From: theute at redhat.com (Thomas Heute)
Date: Tue, 4 Jul 2017 09:41:55 +0200
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
Message-ID: <CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>

Agreed, Hawkular Services need more love, not to disappear.
It may be renamed to "Hawkular ManageIQ Provider" on the website if that
helps with clarity, but shouldn't disappear.

Also there is no quickstart anymore, it's very rough for people.

We had this:
http://www.hawkular.org/hawkular-services/docs/quickstart-guide/
Not perfect, but should be improved rather than removed IMO.

In fact, the whole overview has disappeared:
http://www.hawkular.org/overview/

Alerting has quickstarts that should be more prominent on the website:
https://github.com/hawkular/hawkular-alerts/blob/master/examples/tutorial/README.adoc

Thomas

On Tue, Jul 4, 2017 at 9:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:

> Hey,
>
> On 3 Jul 2017, at 23:42, Stefan Negrea wrote:
>
> > I waited about 2 weeks to allow enough time for feedback. There was a
> > good amount of initial discussion on the document mostly in the form
> > of proposals to enhance the initial plan. There were zero negative
> > comments and nobody opposed the plan.
>
> I know I did not chime in on the document, so have no right
> to complain now :-)
>
> I think though that the removal of Hawkular Services is wrong.
> It may indeed at the moment only exist for that one consumer,
> which is ManageIQ, but not listing it is in my opinion also
> confusing. Instead of removing it, we should perhaps better
> educate visitors of the web site (in a graphical way?) how this
> relates to the other projects.
> Similar to Tracing. This is no longer Hawkular APM, so it is right
> not to list Hawkular APM, but so far Tracing folks are still under the
> Hawkular umbrella and the blog contains a lot of content about it.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/74efbefd/attachment-0001.html 

From abonas at redhat.com  Tue Jul  4 06:14:45 2017
From: abonas at redhat.com (Alissa Bonas)
Date: Tue, 4 Jul 2017 13:14:45 +0300
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<b41a2c57-3251-d352-f974-b8a8705e634e@redhat.com>
	<CAD4MJEBkcU8vF2jPjuJ6Jxzkj4FYMAViqjicMnVKCz1DAcwccw@mail.gmail.com>
	<81444A5C-4ADC-420A-B7B6-655B82A8EC81@redhat.com>
	<7d32fdd8-ba7e-1564-8341-eafe5c26c903@redhat.com>
	<5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
Message-ID: <CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>

see this comment (the last part of it) that mentions a somewhat similar
dynamic concept

http://talk.manageiq.org/t/rethinking-providers-and-managers/2494/11

On Mon, Jun 26, 2017 at 7:05 PM, Heiko Rupp <hrupp at redhat.com> wrote:

> Now that Caina is doing a PoC I want to revisit the
> source of metadata question again.
>
> On 30 May 2017, at 23:11, Jay Shaughnessy wrote:
>
> > changes to MIQ.  As Mazz said, it's a throwback to RHQ where
> > persistence and UI was generically implemented.  The
>
> This is to quickly get a 70% version out and to be able to
> quickly add new monitored stuff. This should and will not
> prevent us from generating more dedicated UI screens later.
>
> >  * the UI config may need more presentation-only info, I'm not sure
>
> Yes
>
> >  * the UI config wouldn't necessarily need everything in the agent
> > config
> >  * it maintains our current decentralized approach to agent config
>
> This one I am no longer sure about. It was a great idea
> back in the day. I see two cases
>
> * user uses the same config for all WildFlys - why do we
> want to duplicate the metadata for all of those if
> the (RT) config is effectively the same?
> * user has modified the agent config to have
> more/less fields. In this case the current MiQ UI would
> not adapt to it and in either way just not show the
> data. And it may not even be clear when there are
> two WildFly in inventory with different configs, why they
> don't show this difference
>
> For WildFly in container it may even be less interesting
> with the current approach as here all the WildFlys will be
> built on one base image (that we supply with a baked in
> config?).
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/235db2c4/attachment.html 

From ehernand at redhat.com  Tue Jul  4 12:55:41 2017
From: ehernand at redhat.com (=?UTF-8?Q?Edgar_Hern=c3=a1ndez?=)
Date: Tue, 4 Jul 2017 11:55:41 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
Message-ID: <d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>


On 07/04/2017 02:41 AM, Thomas Heute wrote:
> Agreed, Hawkular Services need more love, not to disappear.
> It may be renamed to "Hawkular ManageIQ Provider" on the website if 
> that helps with clarity, but shouldn't disappear.
>
> Also there is no quickstart anymore, it's very rough for people.
>
>

What!? This really comes as a surprise for me. All this time my thinking 
was that "services" was the thing bundling all parts together and, 
because of the quickstarts, I believed that "services" was the preferred 
way to get Hawkular. This idea is further supported by exploring the 
DockerHub, where only images of Hawkular-services are available.

Also, right after "Inventory" got removed, "services" and "alerts" were 
somewhat redundant for me because "metrics" is included with "alerts" 
(and "services" also includes both). And, now, starting with "metrics 
0.27.0 
<https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I 
can see that metrics also includes alerts. So, the thing looks more 
redundant now. But with time I learned that "services" provides the 
operations api, used by ManageIQ. I don't know if there are other 
features provided by "services". But those extra features are not 
documented in the website and people new to Hawkular won't realize 
what's the idea behind "services".

- Edgar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/254c7978/attachment.html 

From ehernand at redhat.com  Tue Jul  4 13:04:17 2017
From: ehernand at redhat.com (Edgar Hernandez Garcia)
Date: Tue, 4 Jul 2017 12:04:17 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
Message-ID: <CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>

On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
wrote:

>
>  And, now, starting with "metrics 0.27.0
> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I can
> see that metrics also includes alerts.
>
>
I just realized that alerts is included with metrics even with previous
releases. So, both parts have been shipping the other part for a while.
Now, it's got weirder for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/c82d1458/attachment.html 

From jmartine at redhat.com  Tue Jul  4 13:24:44 2017
From: jmartine at redhat.com (Josejulio Martinez Magana)
Date: Tue, 4 Jul 2017 12:24:44 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
Message-ID: <CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>

I didn't know alerts included metrics (I knew that metrics included alerts)
If they include each other, why not call them as a whole instead as the
parts?

Is confusing for me that they are two distributions and that each that are
mutually included in each other. What's the difference?

On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <ehernand at redhat.com
> wrote:

>
>
> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
> wrote:
>
>>
>>  And, now, starting with "metrics 0.27.0
>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I
>> can see that metrics also includes alerts.
>>
>>
> I just realized that alerts is included with metrics even with previous
> releases. So, both parts have been shipping the other part for a while.
> Now, it's got weirder for me.
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/fea73eed/attachment.html 

From ehernand at redhat.com  Tue Jul  4 13:43:55 2017
From: ehernand at redhat.com (Edgar Hernandez Garcia)
Date: Tue, 4 Jul 2017 12:43:55 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
Message-ID: <CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>

Yes, its a little confusing.

May be I'm wrong in that alerts include metrics (I wrote that only trusting
my memory). If I'm wrong, it's ok to keep them as separate releases. But
the confusion remains between metrics and services, because it's not very
clear how you choose between metrics and services.


On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana <
jmartine at redhat.com> wrote:

> I didn't know alerts included metrics (I knew that metrics included alerts)
> If they include each other, why not call them as a whole instead as the
> parts?
>
> Is confusing for me that they are two distributions and that each that are
> mutually included in each other. What's the difference?
>
> On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <
> ehernand at redhat.com> wrote:
>
>>
>>
>> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
>> wrote:
>>
>>>
>>>  And, now, starting with "metrics 0.27.0
>>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I
>>> can see that metrics also includes alerts.
>>>
>>>
>> I just realized that alerts is included with metrics even with previous
>> releases. So, both parts have been shipping the other part for a while.
>> Now, it's got weirder for me.
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/42e22c02/attachment-0001.html 

From jmartine at redhat.com  Tue Jul  4 13:55:26 2017
From: jmartine at redhat.com (Josejulio Martinez Magana)
Date: Tue, 4 Jul 2017 12:55:26 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
	<CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
Message-ID: <CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>

i might be wrong, but services = metrics (with alerts) + agent + glue code
between agent and alerts(notifications) + status page

On Tue, Jul 4, 2017 at 12:43 PM, Edgar Hernandez Garcia <ehernand at redhat.com
> wrote:

> Yes, its a little confusing.
>
> May be I'm wrong in that alerts include metrics (I wrote that only
> trusting my memory). If I'm wrong, it's ok to keep them as separate
> releases. But the confusion remains between metrics and services, because
> it's not very clear how you choose between metrics and services.
>
>
> On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana <
> jmartine at redhat.com> wrote:
>
>> I didn't know alerts included metrics (I knew that metrics included
>> alerts)
>> If they include each other, why not call them as a whole instead as the
>> parts?
>>
>> Is confusing for me that they are two distributions and that each that
>> are mutually included in each other. What's the difference?
>>
>> On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <
>> ehernand at redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
>>> wrote:
>>>
>>>>
>>>>  And, now, starting with "metrics 0.27.0
>>>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I
>>>> can see that metrics also includes alerts.
>>>>
>>>>
>>> I just realized that alerts is included with metrics even with previous
>>> releases. So, both parts have been shipping the other part for a while.
>>> Now, it's got weirder for me.
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/66a255d6/attachment.html 

From cacosta at redhat.com  Tue Jul  4 14:17:38 2017
From: cacosta at redhat.com (Caina Costa)
Date: Tue, 4 Jul 2017 15:17:38 -0300
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<b41a2c57-3251-d352-f974-b8a8705e634e@redhat.com>
	<CAD4MJEBkcU8vF2jPjuJ6Jxzkj4FYMAViqjicMnVKCz1DAcwccw@mail.gmail.com>
	<81444A5C-4ADC-420A-B7B6-655B82A8EC81@redhat.com>
	<7d32fdd8-ba7e-1564-8341-eafe5c26c903@redhat.com>
	<5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
	<CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>
Message-ID: <CAJvPVZ5BRfPQpz5kJAkW-pjMtS89zadd6MFkrt9FhMBwaD4Hqw@mail.gmail.com>

Heya,

My Proof of Concept for the Dynamic/Generic UI is ready, and can be found
here: github.com/cfcosta/dynamic-entity-poc

There is some documentation on the README.md, but if you guys have any
questions, just ping and I'll add it there.

On Tue, Jul 4, 2017 at 7:14 AM, Alissa Bonas <abonas at redhat.com> wrote:

> see this comment (the last part of it) that mentions a somewhat similar
> dynamic concept
>
> http://talk.manageiq.org/t/rethinking-providers-and-managers/2494/11
>

The PoC does exactly that, we just need to define new entities/views for
them.


>
>
> On Mon, Jun 26, 2017 at 7:05 PM, Heiko Rupp <hrupp at redhat.com> wrote:
>
>> Now that Caina is doing a PoC I want to revisit the
>> source of metadata question again.
>>
>> On 30 May 2017, at 23:11, Jay Shaughnessy wrote:
>>
>> > changes to MIQ.  As Mazz said, it's a throwback to RHQ where
>> > persistence and UI was generically implemented.  The
>>
>> This is to quickly get a 70% version out and to be able to
>> quickly add new monitored stuff. This should and will not
>> prevent us from generating more dedicated UI screens later.
>>
>> >  * the UI config may need more presentation-only info, I'm not sure
>>
>> Yes
>>
>> >  * the UI config wouldn't necessarily need everything in the agent
>> > config
>> >  * it maintains our current decentralized approach to agent config
>>
>> This one I am no longer sure about. It was a great idea
>> back in the day. I see two cases
>>
>> * user uses the same config for all WildFlys - why do we
>> want to duplicate the metadata for all of those if
>> the (RT) config is effectively the same?
>> * user has modified the agent config to have
>> more/less fields. In this case the current MiQ UI would
>> not adapt to it and in either way just not show the
>> data. And it may not even be clear when there are
>> two WildFly in inventory with different configs, why they
>> don't show this difference
>>
>> For WildFly in container it may even be less interesting
>> with the current approach as here all the WildFlys will be
>> built on one base image (that we supply with a baked in
>> config?).
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170704/9f851907/attachment.html 

From hrupp at redhat.com  Tue Jul  4 15:13:01 2017
From: hrupp at redhat.com (Heiko Rupp)
Date: Tue, 04 Jul 2017 21:13:01 +0200
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <CAJvPVZ5BRfPQpz5kJAkW-pjMtS89zadd6MFkrt9FhMBwaD4Hqw@mail.gmail.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<b41a2c57-3251-d352-f974-b8a8705e634e@redhat.com>
	<CAD4MJEBkcU8vF2jPjuJ6Jxzkj4FYMAViqjicMnVKCz1DAcwccw@mail.gmail.com>
	<81444A5C-4ADC-420A-B7B6-655B82A8EC81@redhat.com>
	<7d32fdd8-ba7e-1564-8341-eafe5c26c903@redhat.com>
	<5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
	<CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>
	<CAJvPVZ5BRfPQpz5kJAkW-pjMtS89zadd6MFkrt9FhMBwaD4Hqw@mail.gmail.com>
Message-ID: <181E9645-D9E8-48D8-A459-DAFF0A5E54CE@redhat.com>

Hey,

On 4 Jul 2017, at 20:17, Caina Costa wrote:

> My Proof of Concept for the Dynamic/Generic UI is ready, and can be 
> found here: github.com/cfcosta/dynamic-entity-poc

Awesome - why don't you do a little demo via BlueJeans or
Google Hangouts or such - I think that would be great
for everyone and you could walk us through what you
did so that we can better understand how to evolve it.

   Heiko


From theute at redhat.com  Wed Jul  5 01:47:21 2017
From: theute at redhat.com (Thomas Heute)
Date: Wed, 5 Jul 2017 07:47:21 +0200
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
	<CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
	<CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>
Message-ID: <CA+aN=Mp8DDJwza5S18SfQQ0s5DjONT=jbXnzFumVaC-M8N0-Ww@mail.gmail.com>

Alerts don't include Metrics, but the opposite is true for a few releases
now (it has not always been the case).

Yes, Hawkular Services is/was the go-to place since it had everything
included (Alerting, Metrics, Inventory(RIP), EAP Agent, Command Gateway,
"glue code")...

The EAP Agent and Command Gateway are pretty much related to ManageIQ so we
could make the switch and claim it is for ManageIQ (and work in that
direction) but then we first need an easy way to consume Metrics+Alerting,
currently there is no binary for that (No Zip, No Docker) which has been
missing for a whiile, there is also no quickstart except for Alerting.

Thomas

On Tue, Jul 4, 2017 at 7:55 PM, Josejulio Martinez Magana <
jmartine at redhat.com> wrote:

> i might be wrong, but services = metrics (with alerts) + agent + glue code
> between agent and alerts(notifications) + status page
>
> On Tue, Jul 4, 2017 at 12:43 PM, Edgar Hernandez Garcia <
> ehernand at redhat.com> wrote:
>
>> Yes, its a little confusing.
>>
>> May be I'm wrong in that alerts include metrics (I wrote that only
>> trusting my memory). If I'm wrong, it's ok to keep them as separate
>> releases. But the confusion remains between metrics and services, because
>> it's not very clear how you choose between metrics and services.
>>
>>
>> On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana <
>> jmartine at redhat.com> wrote:
>>
>>> I didn't know alerts included metrics (I knew that metrics included
>>> alerts)
>>> If they include each other, why not call them as a whole instead as the
>>> parts?
>>>
>>> Is confusing for me that they are two distributions and that each that
>>> are mutually included in each other. What's the difference?
>>>
>>> On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <
>>> ehernand at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>  And, now, starting with "metrics 0.27.0
>>>>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I
>>>>> can see that metrics also includes alerts.
>>>>>
>>>>>
>>>> I just realized that alerts is included with metrics even with previous
>>>> releases. So, both parts have been shipping the other part for a while.
>>>> Now, it's got weirder for me.
>>>>
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/4f7a57b8/attachment-0001.html 

From theute at redhat.com  Wed Jul  5 01:47:55 2017
From: theute at redhat.com (Thomas Heute)
Date: Wed, 5 Jul 2017 07:47:55 +0200
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <181E9645-D9E8-48D8-A459-DAFF0A5E54CE@redhat.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<b41a2c57-3251-d352-f974-b8a8705e634e@redhat.com>
	<CAD4MJEBkcU8vF2jPjuJ6Jxzkj4FYMAViqjicMnVKCz1DAcwccw@mail.gmail.com>
	<81444A5C-4ADC-420A-B7B6-655B82A8EC81@redhat.com>
	<7d32fdd8-ba7e-1564-8341-eafe5c26c903@redhat.com>
	<5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
	<CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>
	<CAJvPVZ5BRfPQpz5kJAkW-pjMtS89zadd6MFkrt9FhMBwaD4Hqw@mail.gmail.com>
	<181E9645-D9E8-48D8-A459-DAFF0A5E54CE@redhat.com>
Message-ID: <CA+aN=MrJ-QDs-8dmJ8=_c12it-hO0LXi1kByDkeW4-bZ0m6MgA@mail.gmail.com>

+1

On Tue, Jul 4, 2017 at 9:13 PM, Heiko Rupp <hrupp at redhat.com> wrote:

> Hey,
>
> On 4 Jul 2017, at 20:17, Caina Costa wrote:
>
> > My Proof of Concept for the Dynamic/Generic UI is ready, and can be
> > found here: github.com/cfcosta/dynamic-entity-poc
>
> Awesome - why don't you do a little demo via BlueJeans or
> Google Hangouts or such - I think that would be great
> for everyone and you could walk us through what you
> did so that we can better understand how to evolve it.
>
>    Heiko
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/0247f000/attachment.html 

From abonas at redhat.com  Wed Jul  5 05:11:10 2017
From: abonas at redhat.com (Alissa Bonas)
Date: Wed, 5 Jul 2017 12:11:10 +0300
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <CA+aN=MrJ-QDs-8dmJ8=_c12it-hO0LXi1kByDkeW4-bZ0m6MgA@mail.gmail.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<b41a2c57-3251-d352-f974-b8a8705e634e@redhat.com>
	<CAD4MJEBkcU8vF2jPjuJ6Jxzkj4FYMAViqjicMnVKCz1DAcwccw@mail.gmail.com>
	<81444A5C-4ADC-420A-B7B6-655B82A8EC81@redhat.com>
	<7d32fdd8-ba7e-1564-8341-eafe5c26c903@redhat.com>
	<5366C24E-B08D-49D4-B551-41245A1D1399@redhat.com>
	<CAOJV2uDzb_9Hef6xDf50bWBp7JdE4m0WraFuLmiEhNRwmxx7Vg@mail.gmail.com>
	<CAJvPVZ5BRfPQpz5kJAkW-pjMtS89zadd6MFkrt9FhMBwaD4Hqw@mail.gmail.com>
	<181E9645-D9E8-48D8-A459-DAFF0A5E54CE@redhat.com>
	<CA+aN=MrJ-QDs-8dmJ8=_c12it-hO0LXi1kByDkeW4-bZ0m6MgA@mail.gmail.com>
Message-ID: <CAOJV2uATXDp1L=fG8xZf6w7tEB1J14qckoHFNSTONnJwgTv4Eg@mail.gmail.com>

+1

On Wed, Jul 5, 2017 at 8:47 AM, Thomas Heute <theute at redhat.com> wrote:

> +1
>
> On Tue, Jul 4, 2017 at 9:13 PM, Heiko Rupp <hrupp at redhat.com> wrote:
>
>> Hey,
>>
>> On 4 Jul 2017, at 20:17, Caina Costa wrote:
>>
>> > My Proof of Concept for the Dynamic/Generic UI is ready, and can be
>> > found here: github.com/cfcosta/dynamic-entity-poc
>>
>> Awesome - why don't you do a little demo via BlueJeans or
>> Google Hangouts or such - I think that would be great
>> for everyone and you could walk us through what you
>> did so that we can better understand how to evolve it.
>>
>>    Heiko
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/b90b1422/attachment.html 

From jshaughn at redhat.com  Wed Jul  5 10:39:50 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 5 Jul 2017 10:39:50 -0400
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CA+aN=Mp8DDJwza5S18SfQQ0s5DjONT=jbXnzFumVaC-M8N0-Ww@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
	<CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
	<CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>
	<CA+aN=Mp8DDJwza5S18SfQQ0s5DjONT=jbXnzFumVaC-M8N0-Ww@mail.gmail.com>
Message-ID: <b3a9eb87-1dc0-c11c-3c93-0d85a61c6374@redhat.com>


The two most consumable pieces of hawkular are Standalone Alerts and 
Standalone Metrics.   And these should be featured most prominently on 
the web site (imo).  Because the "Hawkular" prefix is so cumbersome to 
say, I think we should typically call these things "hAlerts" and 
"hMetrics".   I like the idea of also having the home page lead to other 
things Hawkular, such as Tracing,  MIQ Provider (much better than 
calling it Hawkular Services), HawkFX, The ruby gems, etc...   The fact 
that Metrics bundles Alerts enhances the Metrics offering but remember 
that this is primarily a metrics solution.  HAlerts should be featured 
independently as a standalone, pluggable solution for federated alerting.

As mentioned prior:

  * hServices really has only one consumer, MIQ, and should likely just
    be presented in that way.
  * hAlerts does *not* bundle metrics.
  * we should probably take a look at the docker hub and make sure it is
    coherent


On 7/5/2017 1:47 AM, Thomas Heute wrote:
> Alerts don't include Metrics, but the opposite is true for a few 
> releases now (it has not always been the case).
>
> Yes, Hawkular Services is/was the go-to place since it had everything 
> included (Alerting, Metrics, Inventory(RIP), EAP Agent, Command 
> Gateway, "glue code")...
>
> The EAP Agent and Command Gateway are pretty much related to ManageIQ 
> so we could make the switch and claim it is for ManageIQ (and work in 
> that direction) but then we first need an easy way to consume 
> Metrics+Alerting, currently there is no binary for that (No Zip, No 
> Docker) which has been missing for a whiile, there is also no 
> quickstart except for Alerting.
>
> Thomas
>
> On Tue, Jul 4, 2017 at 7:55 PM, Josejulio Martinez Magana 
> <jmartine at redhat.com <mailto:jmartine at redhat.com>> wrote:
>
>     i might be wrong, but services = metrics (with alerts) + agent +
>     glue code between agent and alerts(notifications) + status page
>
>     On Tue, Jul 4, 2017 at 12:43 PM, Edgar Hernandez Garcia
>     <ehernand at redhat.com <mailto:ehernand at redhat.com>> wrote:
>
>         Yes, its a little confusing.
>
>         May be I'm wrong in that alerts include metrics (I wrote that
>         only trusting my memory). If I'm wrong, it's ok to keep them
>         as separate releases. But the confusion remains between
>         metrics and services, because it's not very clear how you
>         choose between metrics and services.
>
>
>         On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana
>         <jmartine at redhat.com <mailto:jmartine at redhat.com>> wrote:
>
>             I didn't know alerts included metrics (I knew that metrics
>             included alerts)
>             If they include each other, why not call them as a whole
>             instead as the parts?
>
>             Is confusing for me that they are two distributions and
>             that each that are mutually included in each other. What's
>             the difference?
>
>             On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia
>             <ehernand at redhat.com <mailto:ehernand at redhat.com>> wrote:
>
>
>
>                 On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez
>                 <ehernand at redhat.com <mailto:ehernand at redhat.com>> wrote:
>
>
>                      And, now, starting with "metrics 0.27.0
>                     <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>"
>                     I can see that metrics also includes alerts.
>
>
>                 I just realized that alerts is included with metrics
>                 even with previous releases. So, both parts have been
>                 shipping the other part for a while. Now, it's got
>                 weirder for me.
>
>
>                 _______________________________________________
>                 hawkular-dev mailing list
>                 hawkular-dev at lists.jboss.org
>                 <mailto:hawkular-dev at 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 at lists.jboss.org
>             <mailto:hawkular-dev at 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 at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/59abf891/attachment-0001.html 

From jstickle at redhat.com  Wed Jul  5 16:29:18 2017
From: jstickle at redhat.com (Julie Stickler)
Date: Wed, 5 Jul 2017 16:29:18 -0400
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <b3a9eb87-1dc0-c11c-3c93-0d85a61c6374@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
	<CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
	<CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>
	<CA+aN=Mp8DDJwza5S18SfQQ0s5DjONT=jbXnzFumVaC-M8N0-Ww@mail.gmail.com>
	<b3a9eb87-1dc0-c11c-3c93-0d85a61c6374@redhat.com>
Message-ID: <CA+p6XVFstPh8guzgvnVmqCmUg3Lnj885=zKjAdowyEDtwF2Wdg@mail.gmail.com>

I meant to share this earlier (my fault for not forwarding it a week or two
ago).  One of the Red Hat Content Strategists attended OSCON back in May
and wrote up an awesome blog post (with examples) about a panel on how
documentation can help the adoption of your project.  TLDR: our web site
needs to explain Hawkular to anyone that lands on it, and guide them from
beginner content written for someone who has never heard of Hawkular to
more advanced content.

Right now?  The bare screen with a couple of buttons and a tag cloud is not
an improvement on the previous site, which at least had an overview,
getting started, and explained the features.

We need a good description of what the Hawkular project is and what it can
do for you.

If we were to write a new Getting Started or Quick Start guide for
Hawkular, where would we start?  Would we need one for each component?

***

https://mojo.redhat.com/people/nengard/blog/2017/05/11/oscon-how-documentation-can-help-in-the-adoption-of-your-project

For those not on Mojo, here's the blog post text:

*OSCON : How documentation can help in the adoption of your project*

Ben Hall from Katacoda and Ocelot Uproar gave an awesome talk at OSCON
about a topic near and dear to my heart - documentation!

Ben wanted us to know that the journey to documentation begins before you
think, it's not just the 'documentation' but it's the examples and demos on
your website. It's actually the first page of your website! Users look at
these things before they read the guides.

A big mistake we make in software is that we often give people the product
to download and then give them access to the entire manual without any
steps in between. Instead, we should approach documentation in incremental
steps to build the user's confidence.

Everyone is super busy and stressed, but they're motivated when they come
to your project site and you don't want to add additional stress and
de-motivate them with your documentation or lack thereof.

This is why almost every intro to computer science class teaches a "Hello
world" example. It has a low barrier to entry and is easy for folks to
learn. We want our documentation to get folks to a level where they are
confident in acquiring more knowledge.

Think of documentation in the following steps:

   1.

   Exploration
   2.

   Getting Started
   3.

   Onboarding/Problem Solving
   4.

   Guidance and Discovery
   5.

   Reference



*Step 1 Exploration*

Imagine that someone has just landed on your GitHub site and they're
interested in learning more. What do you have there to hook them in and
make them feel comfortable? This site is the first step of our
documentation and you want to answer the customer's question of 'why should
I care?' easily so that you can pull the user in further.

Some examples that Ben provided us with of sites that handle this well are:

   -

   Kubernetes [https://kubernetes.io/
   <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fkubernetes.io%2F>]
   site is very clear right away.
   -

   Project Calico [https://www.projectcalico.org/
   <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.projectcalico.org%2F>]
   takes one line to explain what their purpose is right at the top of the page
   -

   Kotlin [https://kotlinlang.org/
   <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fkotlinlang.org%2F>]
   is an example of how to get folks to feel confident about the product
   before downloading it.

On the other end of things, the Docker site is a less clear example. The
first line is about getting started, but if I don't know what Docker is,
why do I want to get started? The lines at the top moves so the next thing
you see is about getting certified which is way past the level your new
users are at. It takes 4 pages of scrolling before you learn what Docker
is. This is how you lose new customers. This was just one example from the
speaker, but many companies do this.

*Step 2 Getting Started*

Now that you got your potential customers to care about your project. Next,
you need to show them that your product is just what they need to solve
their problem. You have about 9 minutes here before you lose a motivated
user's interest.

A great example of hooking the user in is Stripe [https://stripe.com/
<https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fstripe.com%2F>].
They have a very clear getting started guide complete with code snippets.
They also include small discreet sections that are easy to digest and
follow.

OpenShift [https://www.openshift.org/
<https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.openshift.org%2F>]
is another great example of easy to access getting started information. The
site tells the user everything they need to know right when they need to
know it.

*Step 3: Onboarding*

The user now wants to use your product. You want to get them up and running
easily.

A good example of this is Mixpanel [https://mixpanel.com/
<https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fmixpanel.com%2F>].
They have the documentation embedded right into the portal and don't have
long lengthy documentation that you have to read. They make the process
engaging for the user.

You want to get people over the first hurdle of seeing the system in
action. Jump right into the process.

*Stage 4: Guidance and Discovery*

Now that you have the customer all set up and running, they're probably
interested in what other problems your product can solve for them. The
users already have the difficult parts done, they got started, they have
the system up and running, and now they want to know what else is possible.

Twilio [https://www.twilio.com/docs/
<https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.twilio.com%2Fdocs%2F>]
has a great example of this. You can easily pick what documentation is best
for you from their handy header. They provide you with screenshots, videos,
text content, and where to go next.

This stage is a good place to start promoting your community. Include
options to explore your community and show what people are doing with your
product.

*Stage 5: Reference*

Now your users want to be experts. Now users will look for your in-depth
documentation.

*Given these steps, who creates documentation best?*

Lego! Lego has the best documentation of all. Think about it, they don't
need to explain anything using words in their documentation, it's all
pictures. They not only help you follow the rules, but they also encourage
you to be creative. They have a website [https://ideas.lego.com/
<https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fideas.lego.com%2F>]
where they let people publish their own creations. This makes the community
feel more passionate.

JULIE STICKLER

TECHNICAL WRITER

Red Hat

<https://www.redhat.com/>

Westford ? 3S353

jstickle at redhat.com    T: 1(978)-399-0463-(812-0463)     IRC: jstickler

On Wed, Jul 5, 2017 at 10:39 AM, Jay Shaughnessy <jshaughn at redhat.com>
wrote:

>
> The two most consumable pieces of hawkular are Standalone Alerts and
> Standalone Metrics.   And these should be featured most prominently on the
> web site (imo).  Because the "Hawkular" prefix is so cumbersome to say, I
> think we should typically call these things "hAlerts" and "hMetrics".   I
> like the idea of also having the home page lead to other things Hawkular,
> such as Tracing,  MIQ Provider (much better than calling it Hawkular
> Services), HawkFX, The ruby gems, etc...   The fact that Metrics bundles
> Alerts enhances the Metrics offering but remember that this is primarily a
> metrics solution.  HAlerts should be featured independently as a
> standalone, pluggable solution for federated alerting.
>
> As mentioned prior:
>
>    - hServices really has only one consumer, MIQ, and should likely just
>    be presented in that way.
>    - hAlerts does *not* bundle metrics.
>    - we should probably take a look at the docker hub and make sure it is
>    coherent
>
>
> On 7/5/2017 1:47 AM, Thomas Heute wrote:
>
> Alerts don't include Metrics, but the opposite is true for a few releases
> now (it has not always been the case).
>
> Yes, Hawkular Services is/was the go-to place since it had everything
> included (Alerting, Metrics, Inventory(RIP), EAP Agent, Command Gateway,
> "glue code")...
>
> The EAP Agent and Command Gateway are pretty much related to ManageIQ so
> we could make the switch and claim it is for ManageIQ (and work in that
> direction) but then we first need an easy way to consume Metrics+Alerting,
> currently there is no binary for that (No Zip, No Docker) which has been
> missing for a whiile, there is also no quickstart except for Alerting.
>
> Thomas
>
> On Tue, Jul 4, 2017 at 7:55 PM, Josejulio Martinez Magana <
> jmartine at redhat.com> wrote:
>
>> i might be wrong, but services = metrics (with alerts) + agent + glue
>> code between agent and alerts(notifications) + status page
>>
>> On Tue, Jul 4, 2017 at 12:43 PM, Edgar Hernandez Garcia <
>> ehernand at redhat.com> wrote:
>>
>>> Yes, its a little confusing.
>>>
>>> May be I'm wrong in that alerts include metrics (I wrote that only
>>> trusting my memory). If I'm wrong, it's ok to keep them as separate
>>> releases. But the confusion remains between metrics and services, because
>>> it's not very clear how you choose between metrics and services.
>>>
>>>
>>> On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana <
>>> jmartine at redhat.com> wrote:
>>>
>>>> I didn't know alerts included metrics (I knew that metrics included
>>>> alerts)
>>>> If they include each other, why not call them as a whole instead as the
>>>> parts?
>>>>
>>>> Is confusing for me that they are two distributions and that each that
>>>> are mutually included in each other. What's the difference?
>>>>
>>>> On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <
>>>> ehernand at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>  And, now, starting with "metrics 0.27.0
>>>>>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>"
>>>>>> I can see that metrics also includes alerts.
>>>>>>
>>>>>>
>>>>> I just realized that alerts is included with metrics even with
>>>>> previous releases. So, both parts have been shipping the other part for a
>>>>> while. Now, it's got weirder for me.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hawkular-dev mailing list
>>>>> hawkular-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
>
> _______________________________________________
> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/d14c6a95/attachment-0001.html 

From mithomps at redhat.com  Wed Jul  5 19:17:13 2017
From: mithomps at redhat.com (mike thompson)
Date: Wed, 5 Jul 2017 16:17:13 -0700
Subject: [Hawkular-dev] Generic Hawkular-UI in MiQ
In-Reply-To: <CAJvPVZ7_FgLEmUtoWr6rinNu1ZWW0eWGeVS1J94NQ40newQkSQ@mail.gmail.com>
References: <345CDCE2-76AB-43FF-8FDB-5CE3C4601AFC@redhat.com>
	<CBF280D4-EB8A-4A42-84D9-1DAF27EFC5FF@redhat.com>
	<0E4BC096-636A-4B5D-BDF3-4EE6D55E1F7F@redhat.com>
	<CAJvPVZ7_FgLEmUtoWr6rinNu1ZWW0eWGeVS1J94NQ40newQkSQ@mail.gmail.com>
Message-ID: <705A03B5-1AD9-4740-AE88-45D3B120D379@redhat.com>

Nice Caina! I think we can work with this :)


> On May 25, 2017, at 11:30 AM, Caina Costa <cacosta at redhat.com> wrote:
> 
> So, I did some research on the codebase for possible pain points for this change. It looks completely doable, albeit that's going to be quite a bit work to get it correctly. As for backend details, I've been thinking about having a "base" entity, provably something like MiddlewareEntity, which would have the fields in common for all entities as usual, as well as a "metadata" field exposed as a JSON, and then we can work from there to get everything else working.
> 
> There are some questions that I have:
> 
> * What kind of metadata are we talking about, is it static or more of schema-less data?
> * Are we talking only about showing the data, or also editing, filtering and searching?
> * How should the backend present it to the frontend? As a normal controller or through an API?
> * In case we have more metadata in the future to be available for all entities, how should we migrate the older ones?
> * Is there a way to present JSON Schema (http://json-schema.org/ <http://json-schema.org/>) from the Agent to MiQ, or at least to have that defined before we start working on it?
> * How are "capabilities" supposed to be shown to MiQ? Let's say, a server has the support on running operations, can we assume that this will be signaled somewhere to us?
> * How much of the control on what MiQ can do should be available on miq-side and how much should be provided by the agent? Let's say, right now manageiq has the knowledge on whether a server is mutable or not, and based on that knowledge we decide if we should enable server operations or not. I don't think that's ideal, and in my mind the ideal case would be having something like that on the data:
> 
> { "capabilities": ["operations", "metrics"] }
> 
> And from that we should show the correct info/actions on the page.
> 
> As a bottom point, I like this feature very much, as it can reduce the amount of info ManageIQ has to act upon, by moving responsibilities from it to the agent.
> 
> On Thu, May 25, 2017 at 7:43 AM, Heiko W.Rupp <hrupp at redhat.com <mailto:hrupp at redhat.com>> wrote:
> On 25 May 2017, at 2:40, mike thompson wrote:
> >
> > From a MiQ UI perspective, we should be able to ?map? multiple
> > disparate structures into a canonical MiQ model that gets rendered in
> > the UI. The MiQ UI screens are just representing models so as long as
> > we just maintain consistent mappings into the canonical fields we
> > should be fine. Of course, we will probably have to add new generic
> > fields as new attributes arise, but that is expected.
> 
> I think what I forgot to mention is that in the .haml when
> you have
> 
> properties:
> - foo
> - bar
> - baz
> 
> it is also possible to compute that list via a method
> (under the hood, those lists are method calls anyway)
> 
> > This provides a more metadata style approach. It is a change of
> > direction, but we are changing things anyway with new technology
> > decisions.
> 
> The idea is to quickly get out support for new supported
> entities (e.g. Infinispan) by having the structure on the metadata.
> This also allows for the owners of the entities (Ispn-team) to
> provide the knowledge about the structure in the (agent)
> metadata without the need to also create MiQ code.
> 
> This does not prevent us from doing more specific screens
> later on for those entities. It is really meant to get initial
> support for those  in more quickly.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170705/09dad2b8/attachment.html 

From jtakvori at redhat.com  Thu Jul  6 04:01:53 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Thu, 6 Jul 2017 10:01:53 +0200
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CA+p6XVFstPh8guzgvnVmqCmUg3Lnj885=zKjAdowyEDtwF2Wdg@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CAFSJSYfeBMB3XQb-sFRjNJdU9EWVFnDePf9vUVYOpqvayZ3e8g@mail.gmail.com>
	<CAD4MJEA4prmcgRsuYnhuJFDLL1NSNLDsCLbmWUUL9FWR_OH4Hg@mail.gmail.com>
	<CAFSJSYeCqHiTpWC4E38LjCHUam7QH5Yb5ToqT5VvWmopwjP5eA@mail.gmail.com>
	<CAD4MJECBrEEi3nZJR+pGJhayVLZP3qoJ+O+OeT0nfoTYDxVnQw@mail.gmail.com>
	<CA+aN=Mp8DDJwza5S18SfQQ0s5DjONT=jbXnzFumVaC-M8N0-Ww@mail.gmail.com>
	<b3a9eb87-1dc0-c11c-3c93-0d85a61c6374@redhat.com>
	<CA+p6XVFstPh8guzgvnVmqCmUg3Lnj885=zKjAdowyEDtwF2Wdg@mail.gmail.com>
Message-ID: <CAJo5TFmfEcKZLvyDstnfR7RJY=ysBwaDa05HzmCERWJ_OGzYCg@mail.gmail.com>

Thank you Julie for these guidelines. I think the problem we have here is
that we're focused on a "strategic" decision (which is: put focus on
standalone components) without considering the loss in the documentation
organization. If we switch the focus from hServices to hMetrics/hAlerts we
should bring their documentation to at least the same level and we need an
equivalent "getting started" than this one [1] (eventually we could just
adapt it to hMetrics alone and hAlerts alone). The same applies for the
installation guide [2].

For the front page, I believe it's just the first step and we definitely
need to replace the removed content with something else. Probably the PR
should be merged in another branch so that the website is not affected
during these re-design.

[1] http://www.hawkular.org/hawkular-services/docs/quickstart-guide/
[2] http://www.hawkular.org/hawkular-services/docs/installation-guide/

On Wed, Jul 5, 2017 at 10:29 PM, Julie Stickler <jstickle at redhat.com> wrote:

> I meant to share this earlier (my fault for not forwarding it a week or
> two ago).  One of the Red Hat Content Strategists attended OSCON back in
> May and wrote up an awesome blog post (with examples) about a panel on how
> documentation can help the adoption of your project.  TLDR: our web site
> needs to explain Hawkular to anyone that lands on it, and guide them from
> beginner content written for someone who has never heard of Hawkular to
> more advanced content.
>
> Right now?  The bare screen with a couple of buttons and a tag cloud is
> not an improvement on the previous site, which at least had an overview,
> getting started, and explained the features.
>
> We need a good description of what the Hawkular project is and what it can
> do for you.
>
> If we were to write a new Getting Started or Quick Start guide for
> Hawkular, where would we start?  Would we need one for each component?
>
> ***
>
> https://mojo.redhat.com/people/nengard/blog/2017/05/
> 11/oscon-how-documentation-can-help-in-the-adoption-of-your-project
>
> For those not on Mojo, here's the blog post text:
>
> *OSCON : How documentation can help in the adoption of your project*
>
> Ben Hall from Katacoda and Ocelot Uproar gave an awesome talk at OSCON
> about a topic near and dear to my heart - documentation!
>
> Ben wanted us to know that the journey to documentation begins before you
> think, it's not just the 'documentation' but it's the examples and demos on
> your website. It's actually the first page of your website! Users look at
> these things before they read the guides.
>
> A big mistake we make in software is that we often give people the product
> to download and then give them access to the entire manual without any
> steps in between. Instead, we should approach documentation in incremental
> steps to build the user's confidence.
>
> Everyone is super busy and stressed, but they're motivated when they come
> to your project site and you don't want to add additional stress and
> de-motivate them with your documentation or lack thereof.
>
> This is why almost every intro to computer science class teaches a "Hello
> world" example. It has a low barrier to entry and is easy for folks to
> learn. We want our documentation to get folks to a level where they are
> confident in acquiring more knowledge.
>
> Think of documentation in the following steps:
>
>    1.
>
>    Exploration
>    2.
>
>    Getting Started
>    3.
>
>    Onboarding/Problem Solving
>    4.
>
>    Guidance and Discovery
>    5.
>
>    Reference
>
>
>
> *Step 1 Exploration*
>
> Imagine that someone has just landed on your GitHub site and they're
> interested in learning more. What do you have there to hook them in and
> make them feel comfortable? This site is the first step of our
> documentation and you want to answer the customer's question of 'why should
> I care?' easily so that you can pull the user in further.
>
> Some examples that Ben provided us with of sites that handle this well are:
>
>    -
>
>    Kubernetes [https://kubernetes.io/
>    <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fkubernetes.io%2F>]
>    site is very clear right away.
>    -
>
>    Project Calico [https://www.projectcalico.org/
>    <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.projectcalico.org%2F>]
>    takes one line to explain what their purpose is right at the top of the page
>    -
>
>    Kotlin [https://kotlinlang.org/
>    <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fkotlinlang.org%2F>]
>    is an example of how to get folks to feel confident about the product
>    before downloading it.
>
> On the other end of things, the Docker site is a less clear example. The
> first line is about getting started, but if I don't know what Docker is,
> why do I want to get started? The lines at the top moves so the next thing
> you see is about getting certified which is way past the level your new
> users are at. It takes 4 pages of scrolling before you learn what Docker
> is. This is how you lose new customers. This was just one example from the
> speaker, but many companies do this.
>
> *Step 2 Getting Started*
>
> Now that you got your potential customers to care about your project.
> Next, you need to show them that your product is just what they need to
> solve their problem. You have about 9 minutes here before you lose a
> motivated user's interest.
>
> A great example of hooking the user in is Stripe [https://stripe.com/
> <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fstripe.com%2F>].
> They have a very clear getting started guide complete with code snippets.
> They also include small discreet sections that are easy to digest and
> follow.
>
> OpenShift [https://www.openshift.org/
> <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.openshift.org%2F>]
> is another great example of easy to access getting started information. The
> site tells the user everything they need to know right when they need to
> know it.
>
> *Step 3: Onboarding*
>
> The user now wants to use your product. You want to get them up and
> running easily.
>
> A good example of this is Mixpanel [https://mixpanel.com/
> <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fmixpanel.com%2F>].
> They have the documentation embedded right into the portal and don't have
> long lengthy documentation that you have to read. They make the process
> engaging for the user.
>
> You want to get people over the first hurdle of seeing the system in
> action. Jump right into the process.
>
> *Stage 4: Guidance and Discovery*
>
> Now that you have the customer all set up and running, they're probably
> interested in what other problems your product can solve for them. The
> users already have the difficult parts done, they got started, they have
> the system up and running, and now they want to know what else is possible.
>
> Twilio [https://www.twilio.com/docs/
> <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fwww.twilio.com%2Fdocs%2F>]
> has a great example of this. You can easily pick what documentation is best
> for you from their handy header. They provide you with screenshots, videos,
> text content, and where to go next.
>
> This stage is a good place to start promoting your community. Include
> options to explore your community and show what people are doing with your
> product.
>
> *Stage 5: Reference*
>
> Now your users want to be experts. Now users will look for your in-depth
> documentation.
>
> *Given these steps, who creates documentation best?*
>
> Lego! Lego has the best documentation of all. Think about it, they don't
> need to explain anything using words in their documentation, it's all
> pictures. They not only help you follow the rules, but they also encourage
> you to be creative. They have a website [https://ideas.lego.com/
> <https://mojo.redhat.com/external-link.jspa?url=https%3A%2F%2Fideas.lego.com%2F>]
> where they let people publish their own creations. This makes the community
> feel more passionate.
>
> JULIE STICKLER
>
> TECHNICAL WRITER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> Westford ? 3S353
>
> jstickle at redhat.com    T: 1(978)-399-0463-(812-0463)     IRC: jstickler
>
> On Wed, Jul 5, 2017 at 10:39 AM, Jay Shaughnessy <jshaughn at redhat.com>
> wrote:
>
>>
>> The two most consumable pieces of hawkular are Standalone Alerts and
>> Standalone Metrics.   And these should be featured most prominently on the
>> web site (imo).  Because the "Hawkular" prefix is so cumbersome to say, I
>> think we should typically call these things "hAlerts" and "hMetrics".   I
>> like the idea of also having the home page lead to other things Hawkular,
>> such as Tracing,  MIQ Provider (much better than calling it Hawkular
>> Services), HawkFX, The ruby gems, etc...   The fact that Metrics bundles
>> Alerts enhances the Metrics offering but remember that this is primarily a
>> metrics solution.  HAlerts should be featured independently as a
>> standalone, pluggable solution for federated alerting.
>>
>> As mentioned prior:
>>
>>    - hServices really has only one consumer, MIQ, and should likely just
>>    be presented in that way.
>>    - hAlerts does *not* bundle metrics.
>>    - we should probably take a look at the docker hub and make sure it
>>    is coherent
>>
>>
>> On 7/5/2017 1:47 AM, Thomas Heute wrote:
>>
>> Alerts don't include Metrics, but the opposite is true for a few releases
>> now (it has not always been the case).
>>
>> Yes, Hawkular Services is/was the go-to place since it had everything
>> included (Alerting, Metrics, Inventory(RIP), EAP Agent, Command Gateway,
>> "glue code")...
>>
>> The EAP Agent and Command Gateway are pretty much related to ManageIQ so
>> we could make the switch and claim it is for ManageIQ (and work in that
>> direction) but then we first need an easy way to consume Metrics+Alerting,
>> currently there is no binary for that (No Zip, No Docker) which has been
>> missing for a whiile, there is also no quickstart except for Alerting.
>>
>> Thomas
>>
>> On Tue, Jul 4, 2017 at 7:55 PM, Josejulio Martinez Magana <
>> jmartine at redhat.com> wrote:
>>
>>> i might be wrong, but services = metrics (with alerts) + agent + glue
>>> code between agent and alerts(notifications) + status page
>>>
>>> On Tue, Jul 4, 2017 at 12:43 PM, Edgar Hernandez Garcia <
>>> ehernand at redhat.com> wrote:
>>>
>>>> Yes, its a little confusing.
>>>>
>>>> May be I'm wrong in that alerts include metrics (I wrote that only
>>>> trusting my memory). If I'm wrong, it's ok to keep them as separate
>>>> releases. But the confusion remains between metrics and services, because
>>>> it's not very clear how you choose between metrics and services.
>>>>
>>>>
>>>> On Tue, Jul 4, 2017 at 12:24 PM, Josejulio Martinez Magana <
>>>> jmartine at redhat.com> wrote:
>>>>
>>>>> I didn't know alerts included metrics (I knew that metrics included
>>>>> alerts)
>>>>> If they include each other, why not call them as a whole instead as
>>>>> the parts?
>>>>>
>>>>> Is confusing for me that they are two distributions and that each that
>>>>> are mutually included in each other. What's the difference?
>>>>>
>>>>> On Tue, Jul 4, 2017 at 12:04 PM, Edgar Hernandez Garcia <
>>>>> ehernand at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>>  And, now, starting with "metrics 0.27.0
>>>>>>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>"
>>>>>>> I can see that metrics also includes alerts.
>>>>>>>
>>>>>>>
>>>>>> I just realized that alerts is included with metrics even with
>>>>>> previous releases. So, both parts have been shipping the other part for a
>>>>>> while. Now, it's got weirder for me.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> hawkular-dev mailing list
>>>>>> hawkular-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hawkular-dev mailing list
>>>>> hawkular-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/1d9185a5/attachment-0001.html 

From snegrea at redhat.com  Thu Jul  6 14:56:37 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 6 Jul 2017 13:56:37 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
Message-ID: <CADt-fV-Y8aeunLfPXep_7mNCqh4Zwp-i12XotUQLC2vFDK8frw@mail.gmail.com>

On Tue, Jul 4, 2017 at 2:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:

> Hey,
>
> On 3 Jul 2017, at 23:42, Stefan Negrea wrote:
>
> > I waited about 2 weeks to allow enough time for feedback. There was a
> > good amount of initial discussion on the document mostly in the form
> > of proposals to enhance the initial plan. There were zero negative
> > comments and nobody opposed the plan.
>
> I know I did not chime in on the document, so have no right
> to complain now :-)
>

The document is still available for comments.


>
> I think though that the removal of Hawkular Services is wrong.
> It may indeed at the moment only exist for that one consumer,
> which is ManageIQ, but not listing it is in my opinion also
> confusing. Instead of removing it, we should perhaps better
> educate visitors of the web site (in a graphical way?) how this
> relates to the other projects.
> Similar to Tracing. This is no longer Hawkular APM, so it is right
> not to list Hawkular APM, but so far Tracing folks are still under the
> Hawkular umbrella and the blog contains a lot of content about it.
>

Hawkular Services has a very narrow use and I consider it an integration of
the basic Hawkular components into another product. The Hawkular.org
website should focus on building a community around the core components not
on the product initiatives. I have these details in the document with the
plan.



> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/86a8947c/attachment.html 

From snegrea at redhat.com  Thu Jul  6 14:59:54 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 6 Jul 2017 13:59:54 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAKpA_JW=i4ssbOnPB9Grq8s86YPwohRvZXcAE_WM87H3DF3yjQ@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CAKpA_JW=i4ssbOnPB9Grq8s86YPwohRvZXcAE_WM87H3DF3yjQ@mail.gmail.com>
Message-ID: <CADt-fV-7B_G=xaEvRmzWYnSK32j3hn9XRUO+3VLw+xqgM+xevA@mail.gmail.com>

On Tue, Jul 4, 2017 at 2:38 AM, Gary Brown <gbrown at redhat.com> wrote:

> The aim is to add a "Tracing" entry as a "stage 2", but wasn't sure
> whether this meant releasing a version of the website without it first, and
> then introduce it as a separate step?
>


Stage 1 = cleanup. Stage 2 = adding things.


>
> A general comment - perhaps we should drop the "Hawkular" part from each
> component - so then we simply have "Metrics", "Alerts" and "Tracing"?
>

Good suggestion about dropping Hawkular; I updated the PR.


>
>
> On Tue, Jul 4, 2017 at 8:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:
>
>> Hey,
>>
>> On 3 Jul 2017, at 23:42, Stefan Negrea wrote:
>>
>> > I waited about 2 weeks to allow enough time for feedback. There was a
>> > good amount of initial discussion on the document mostly in the form
>> > of proposals to enhance the initial plan. There were zero negative
>> > comments and nobody opposed the plan.
>>
>> I know I did not chime in on the document, so have no right
>> to complain now :-)
>>
>> I think though that the removal of Hawkular Services is wrong.
>> It may indeed at the moment only exist for that one consumer,
>> which is ManageIQ, but not listing it is in my opinion also
>> confusing. Instead of removing it, we should perhaps better
>> educate visitors of the web site (in a graphical way?) how this
>> relates to the other projects.
>> Similar to Tracing. This is no longer Hawkular APM, so it is right
>> not to list Hawkular APM, but so far Tracing folks are still under the
>> Hawkular umbrella and the blog contains a lot of content about it.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/fad690f7/attachment.html 

From snegrea at redhat.com  Thu Jul  6 15:17:30 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 6 Jul 2017 14:17:30 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CAJo5TFkN+kK4cF2uzC1BxUsLs4W=KwAQFnw_SB9=xwYxYP9UWw@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CAJo5TFkN+kK4cF2uzC1BxUsLs4W=KwAQFnw_SB9=xwYxYP9UWw@mail.gmail.com>
Message-ID: <CADt-fV_rVkZxRdCxp7CFMBA72TDPovWiwuVcobCuu4S79jWvPQ@mail.gmail.com>

On Tue, Jul 4, 2017 at 2:41 AM, Joel Takvorian <jtakvori at redhat.com> wrote:

>
> On Tue, Jul 4, 2017 at 9:22 AM, Heiko Rupp <hrupp at redhat.com> wrote:
>
>
>> I think though that the removal of Hawkular Services is wrong.
>> It may indeed at the moment only exist for that one consumer,
>> which is ManageIQ, but not listing it is in my opinion also
>> confusing. Instead of removing it, we should perhaps better
>> educate visitors of the web site (in a graphical way?) how this
>> relates to the other projects.
>>
>
> I'm sure we have stats on what people downloads the most... is it
> metrics/alerts standalone, or services? We could take it in consideration.
> Having it removed from the menu really makes things clearer, I think, but
> on the other hand we could find ways not to make it completely off the
> radars. For instance, adding something at the top of metrics/alerts install
> page: "Looking for integrated metrics + alerting? Check out Hawkular
> Services".
>
> Another thing about services disappearing: the shame is that IMO it
> currently has a better-written doc than metrics (the quickstart guide is
> good, the installation guide is better than metric's simple link to github).
>
>

I agree that we should not lose the content from Hawkular Services. How
about renaming Hawkular Clients to Integrations and feature at the top of
the page the MiQ and OpenShift integrations? As far as updating the Metrics
and Alerting content, that is going to come after the cleanup.




>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/be0b9bc8/attachment.html 

From snegrea at redhat.com  Thu Jul  6 15:34:27 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 6 Jul 2017 14:34:27 -0500
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
Message-ID: <CADt-fV_h91h2o5j+51Prn4jfrGfoQLUobiyBr55S5JdtsGoNwg@mail.gmail.com>

Thank you,
Stefan Negrea


On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
wrote:

>
> On 07/04/2017 02:41 AM, Thomas Heute wrote:
>
> Agreed, Hawkular Services need more love, not to disappear.
> It may be renamed to "Hawkular ManageIQ Provider" on the website if that
> helps with clarity, but shouldn't disappear.
>
> Also there is no quickstart anymore, it's very rough for people.
>
>
>
> What!? This really comes as a surprise for me. All this time my thinking
> was that "services" was the thing bundling all parts together and, because
> of the quickstarts, I believed that "services" was the preferred way to get
> Hawkular. This idea is further supported by exploring the DockerHub, where
> only images of Hawkular-services are available.
>
> Also, right after "Inventory" got removed, "services" and "alerts" were
> somewhat redundant for me because "metrics" is included with "alerts" (and
> "services" also includes both). And, now, starting with "metrics 0.27.0
> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I can
> see that metrics also includes alerts. So, the thing looks more redundant
> now. But with time I learned that "services" provides the operations api,
> used by ManageIQ. I don't know if there are other features provided by
> "services". But those extra features are not documented in the website and
> people new to Hawkular won't realize what's the idea behind "services".
>
> - Edgar.
>

Hawkular Metrics started bundling Alerting in October of last year and
there are no plans to not bundle it.

We need to make a differentiation between the components (Alerting,
Metrics, Trancing) and their integration into other projects. Hawkular
Services is a specific integration for ManageIQ. We need to adjust the
content around the core components to be able to build a community around
the core components. The integrations are just delivery methods for these
components. The integration of Hawkular Metrics and Alerting (there is a
special bundle for that just like Hawkular Services) in OpenShift Origin
has been used a lot more people than Hawkular Services ever was. Yet it is
nowhere featured or discussed. We need to refocus the front page on the
core components. Hawkular Services or Hawkular Metrics & Alerting OpenShift
Origin (or other future integrations) should be mentioned but in another
section.


>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/3fb48d3e/attachment-0001.html 

From jsanda at redhat.com  Thu Jul  6 19:51:48 2017
From: jsanda at redhat.com (John Sanda)
Date: Thu, 6 Jul 2017 19:51:48 -0400
Subject: [Hawkular-dev] hawkular.org - Redux Initiative
In-Reply-To: <CADt-fV_h91h2o5j+51Prn4jfrGfoQLUobiyBr55S5JdtsGoNwg@mail.gmail.com>
References: <CADt-fV8V8wER87v8_PVEEo0c67USmr+zFVZGaLbhJi_dDHpFbA@mail.gmail.com>
	<CADt-fV81w+9FMvfMW7e2DREacimDKwtPF_ieGsMZ3YEPuD2V6A@mail.gmail.com>
	<2A025908-6659-4FAA-8736-EB718765F7E5@redhat.com>
	<CA+aN=MqWTZJ1ZFpHb1rQT8xo5OsCzv9rFp4OV6r7m0ecgqEx2w@mail.gmail.com>
	<d955b087-ee8d-e95b-9f8b-f37957468f60@redhat.com>
	<CADt-fV_h91h2o5j+51Prn4jfrGfoQLUobiyBr55S5JdtsGoNwg@mail.gmail.com>
Message-ID: <CAH-hyAccJs952xGboo8Vx4--M0P=Hn0DgX97rZJ8rdZDEPhk6Q@mail.gmail.com>

On Thu, Jul 6, 2017 at 3:34 PM, Stefan Negrea <snegrea at redhat.com> wrote:

>
>
> Thank you,
> Stefan Negrea
>
>
> On Tue, Jul 4, 2017 at 11:55 AM, Edgar Hern?ndez <ehernand at redhat.com>
> wrote:
>
>>
>> On 07/04/2017 02:41 AM, Thomas Heute wrote:
>>
>> Agreed, Hawkular Services need more love, not to disappear.
>> It may be renamed to "Hawkular ManageIQ Provider" on the website if that
>> helps with clarity, but shouldn't disappear.
>>
>> Also there is no quickstart anymore, it's very rough for people.
>>
>>
>>
>> What!? This really comes as a surprise for me. All this time my thinking
>> was that "services" was the thing bundling all parts together and, because
>> of the quickstarts, I believed that "services" was the preferred way to get
>> Hawkular. This idea is further supported by exploring the DockerHub, where
>> only images of Hawkular-services are available.
>>
>> Also, right after "Inventory" got removed, "services" and "alerts" were
>> somewhat redundant for me because "metrics" is included with "alerts" (and
>> "services" also includes both). And, now, starting with "metrics 0.27.0
>> <https://github.com/hawkular/hawkular-metrics/releases/tag/0.27.0>" I
>> can see that metrics also includes alerts. So, the thing looks more
>> redundant now. But with time I learned that "services" provides the
>> operations api, used by ManageIQ. I don't know if there are other features
>> provided by "services". But those extra features are not documented in the
>> website and people new to Hawkular won't realize what's the idea behind
>> "services".
>>
>> - Edgar.
>>
>
> Hawkular Metrics started bundling Alerting in October of last year and
> there are no plans to not bundle it.
>

?I don't want to side track the discussion too much, but if we are going to
target kubernetes/openshift as the base platform, then maybe it does make
sense to consider changing the deployment. We should probably have separate
containers for metrics and for alerts.?



>
> We need to make a differentiation between the components (Alerting,
> Metrics, Trancing) and their integration into other projects. Hawkular
> Services is a specific integration for ManageIQ. We need to adjust the
> content around the core components to be able to build a community around
> the core components. The integrations are just delivery methods for these
> components. The integration of Hawkular Metrics and Alerting (there is a
> special bundle for that just like Hawkular Services) in OpenShift Origin
> has been used a lot more people than Hawkular Services ever was. Yet it is
> nowhere featured or discussed. We need to refocus the front page on the
> core components. Hawkular Services or Hawkular Metrics & Alerting OpenShift
> Origin (or other future integrations) should be mentioned but in another
> section.
>
>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170706/bf6275b4/attachment.html 

From theute at redhat.com  Fri Jul  7 05:13:10 2017
From: theute at redhat.com (Thomas Heute)
Date: Fri, 07 Jul 2017 09:13:10 +0000
Subject: [Hawkular-dev] New Hawkular Blog Post: OpenTracing JAX-RS
	Instrumentation
Message-ID: <595f50a664ed0_447c3332c42516@mini-queue-04.resque.ife.mail>

New Hawkular blog post from noreply at hawkular.org (Pavol Loffay): http://ift.tt/2tYLEaM

In the previous demo we have demonstrated how to instrument a Spring Boot app using OpenTracing, a vendor-neutral standard for distributed tracing. In this article we are going to instrument a Java API for RESTful Web Services (JAX-RS), and show you how to trace the business layer and add custom data to the trace.

Demo application

Creating a JAX-RS app from scratch can be a time consuming task, therefore in this case we are going to use Wildfly Swarm?s app generator. Select JAX-RS and CDI dependencies and hit generate button.

Figure 1: Wildfly Swarm generator.

The generated application contains one REST endpoint which returns hello world string. This endpoint is accessible on http://localhost:8080/hello. In the next step we are going to add instrumentation and simple business logic.

Instrumentation

Adding OpenTracing instrumentation to JAX-RS is very simple, just include the following dependency in the classpath and the tracing feature will be automatically registered.

&lt;dependency&gt;
    &lt;groupId&gt;io.opentracing.contrib&lt;/groupId&gt;
    &lt;artifactId&gt;opentracing-jaxrs2&lt;/artifactId&gt;
&lt;/dependency&gt;

OpenTracing is just an API, therefore it is required to register a specific tracer instance. In this demo we are going to use Jaeger tracing system. The tracer should be created and initialized only once per process, hence ServletContextListener is the ideal place for this task:

@WebListener
public class TracingContextListener implements ServletContextListener {

  @Inject
  private io.opentracing.Tracer tracer;

  @Override
  public void contextInitialized(ServletContextEvent sce) {
    GlobalTracer.register(tracer);
  }

  @Override
  public void contextDestroyed(ServletContextEvent sce) {}

  @Produces
  @Singleton
  public static io.opentracing.Tracer jaegerTracer() {
    return new Configuration(&quot;wildfly-swarm&quot;, new Configuration.SamplerConfiguration(
        ProbabilisticSampler.TYPE, 1),
        new Configuration.ReporterConfiguration())
        .getTracer();
  }
}

Tracer initialization code requires to specify app name, which is in this case wildfly-swarm and sampler configuration.

Note that we are suing Java?s Context and Dependency Injection (CDI) to share a tracer instance in our app. If we forget to register a specific tracer instance, then the tracing feature would use NoopTracer. Now we can verify tracing by starting Jaeger server using the following command: docker run --rm -it --network=host jaegertracing/all-in-one and accessing the endpoint at http://localhost:8080/hello. Our trace with one span should be present in the UI at http://localhost:16686.

Instrumenting business logic

JAX-RS instrumentation provides nice visibility into your app, however, it is often necessary to add custom data to the trace to see what is happening in the service or database layer.

The following code snippet shows how the service layer can create and add data to the trace:

public class BackendService {

  @Inject
  private io.opentracing.Tracer tracer;

  public String action() throws InterruptedException {
    int random = new Random().nextInt(200);

    try (ActiveSpan span = tracer.buildSpan(&quot;action&quot;).startActive()) {
      anotherAction();
      Thread.sleep(random);
    }

    return String.valueOf(random);
  }

  private void anotherAction() {
    tracer.activeSpan().setTag(&quot;anotherAction&quot;, &quot;data&quot;);
  }

Note that it?s not necessary to manually pass a span instance around. The method anotherAction accesses the current active span from the tracer.

With the additional instrumentation shown above, an invocation of the REST endpoint would result in a trace consisting of two spans, one representing the inbound server request, and the other the business logic. The span representing server processing is automatically considered as the parent for span created in business layer. If we created span in anotherAction then its parent would be span created in action method.

Figure 1: Jaeger showing reported spans.

Video

Conclusion

We have demonstrated that instrumenting a JAX-RS app is just a matter of adding a dependency and registering a tracer instance. If we would like to use a different OpenTracing implementation, Zipkin for instance, it would just require changing tracer producer code. No changes to the application or business logic! In the next demo we will wire this app with Spring Boot created in previous demo and deploy them on Kubernetes.

Links

OpenTracing: http://opentracing.io

Github repository with demo: http://ift.tt/2s6QrTB

OpenTracing JAX-RS instrumentation: http://ift.tt/2uxvWQO

Jaeger: http://ift.tt/2eOSqHE

from Hawkular Blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170707/97e89857/attachment.html 

From hrupp at redhat.com  Mon Jul 10 07:47:43 2017
From: hrupp at redhat.com (Heiko Rupp)
Date: Mon, 10 Jul 2017 13:47:43 +0200
Subject: [Hawkular-dev] OWASP ZAP for security testing
Message-ID: <DA577B9E-1039-4A4B-8033-565670F7674E@redhat.com>

I was last week in a session about "Security during the build", where 
the presenter
talked about enforcing checks for security issues during the build phase 
(preferably
nightly CI run)
One of the interesting tools is 
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
which is a web client that can run attacks against web applications to 
try things like
* sql injection
* cross site forgery
* just parameter fuzzing
and much more.
While this is a bit hard to set up with pure REST-APIs (if they don't 
follow HATEOAS),
it seems worth doing anyway to make sure that the obvious things don't 
hit.
And before someone mentions that this does not apply to us because we 
use Cassandra
and not a SQL data store: it is possible to generate profiles and e.g. 
switch off the sql injection attack vector.

From cacosta at redhat.com  Mon Jul 17 09:59:06 2017
From: cacosta at redhat.com (Caina Costa)
Date: Mon, 17 Jul 2017 10:59:06 -0300
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
Message-ID: <CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>

On Mon, Jul 17, 2017 at 9:39 AM, Alissa Bonas <abonas at redhat.com> wrote:

> 1. a diagram that shows an example of architecture components and data
> format of entities (json/code/configuration) will help to understand the
> proposal.
>



This is an example of an Entity hierarchy, it shows what kind of entities
we can create, as well as other patterns that we can use. The farther the
key is from Entity, the more specialized it is, which means that the
.applicable? method on those are a lot more picky on what kind of data it
matches to. Views follow the same hierarchy and the engine matches the same
way, and the first defined view is used, so let's say:

If we have a WildflyDomainControllerServer to render, first it will try to
find WildFlyDomainControllerServerView, then WildFlyDomainServerView, then
WildFlyServerView, then WildFlyServerBaseView, then ServerView. That means
that adding new entities are not going to break the views being used.

Also, WildFlyServerBase is an abstract entity, in the sense that it only
provides implementation, and is not to be matched. This can be achieved by
setting .applicable? to return false. Entities are just normal ruby
objects, there is nothing special about them, they just need to answer to
the .applicable? method and receive 1 argument in its initializer.
?

> What I mean is - which component should define/work with which format for
> the example entities? what should be defined on hawkular side, what is
> fetched and defined in ruby gem, what parts are defined and how they are
> processed in miq ui, what parts in miq server + how does that work (or not
> :)) with persisting objects in miq, etc. Can/should 2 completely different
> entities (such as middleware server and a deployment) use your proposal,
> given that they might have some similar common fields? (for example,
> "name", "status")
>

Entities define the "canonical truth" of the responses from the server, and
views define how to represent them as JSON. They don't tackle how we're
going to present data, and not how to fetch them.

To persist data on MiQ: this PoC does not take any action on persisting
stuff, it only cares about representation. To do that, we just need a new
JSON field on every middleware table, to save the response from the server,
and then we can use it. Something like this:

entity = Entity.constantize(MiddlewareServer.first.data)
render json: View.for(entity)


>
> 2. I noticed that the discussion moved to jbmc list although it originated
> in hawkular-dev. the tech discussion is definitely more suitable in
> hawkular-dev as a continue to the original thread on the topic.
>
>
>
> On Mon, Jul 17, 2017 at 3:27 PM, Caina Costa <cacosta at redhat.com> wrote:
>
>> Yes, that's exactly what it does, with some caveats: we have a hierarchy
>> of server types, as in, we first have to implement a generic server type
>> that implements the default attributes to all the servers. From there, we
>> can subclass for more specific server types, and the view/entity runtime
>> takes care of match the hawkular data with the defined entities. So let's
>> say we have a hierarchy like that:
>>
>> MiddlewareServer > WildFlyServer > WildFly11Server
>>
>> For this example, let's say that MiddlewareServer includes only the
>> summary, WildFlyServer includes metrics, and WildFly11Server includes power
>> operations.
>>
>> When matching the data with Entity.constantize(data), we match first the
>> more specialized server, so WildFly11Server, and then WildFlyServer, then
>> the more generic MiddlewareServer. This is automatic on the runtime, and if
>> we add new server types, it will try to match in the reverse of the order
>> provided, first the most specific, then going forward for less specific
>> entities.
>>
>> So, in summary:
>>
>> It does enable us to add new server types with no code change on the
>> ManageIQ side, by providing more generic interfaces that we can match upon,
>> which means that while we might not have all information by default, we
>> will have a representation that makes sense. It also enables us to expand
>> new server types easily with small changes.
>>
>>
>>
>> On Mon, Jul 17, 2017 at 8:31 AM, Thomas Heute <theute at redhat.com> wrote:
>>
>>> I just watched the recording, it was not clear to me the benefits it
>>> brings (or if it's just internal).
>>>
>>> I was hoping to see how one can add a new server type with no code
>>> change on the ManageIQ side, maybe I misinterpreted the current work.
>>>
>>> Can you explain ?
>>>
>>> Thomas
>>>
>>> On Thu, Jul 13, 2017 at 6:13 PM, Caina Costa <cacosta at redhat.com> wrote:
>>>
>>>> Hello guys,
>>>>
>>>> Thanks you all for joining the presentation, lots of great questions!
>>>> For those of you that could not join, here's the recording:
>>>>
>>>> https://bluejeans.com/s/hnR7@/
>>>>
>>>> And the slides are attached.
>>>>
>>>> As always, if you have any questions, please do not hesitate to get in
>>>> touch. I'm available on IRC and e-mail.
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170717/f7559669/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.png
Type: image/png
Size: 6324 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170717/f7559669/attachment.png 

From hrupp at redhat.com  Tue Jul 18 08:42:10 2017
From: hrupp at redhat.com (Heiko Rupp)
Date: Tue, 18 Jul 2017 14:42:10 +0200
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
	<CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
Message-ID: <BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>

On 17 Jul 2017, at 15:59, Caina Costa wrote:

> If we have a WildflyDomainControllerServer to render, first it will 
> try to find WildFlyDomainControllerServerView, then

I (still) consider that a problem, even if better than what we have now.
I can't tell e.g. the Infinispan folks "Listen you know your stuff 
better than we do, so please start writing Ruby code and create a 
pull-request against the hawkular-provider gem"

My goal really is to externalise that as much as possible (in to the 
hawkular-server or agent side), so that it is
possible for other groups to write the description in e.g. JSON for 
their UI and the relation between Entities.

Having that in Hawkular/Agent also allows us to introduce new supported 
stuff outside the release cycles of ManageIQ and their downstream 
CloudForms.
I am not even sure if e.g. introducing support for Infinispan could be 
part of a z-Stream release, which is supposed to be bugfixes only.
So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release 
after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular 
side, we can update the Middleware Manager / agent and the support would 
show automagically.
Of course we may at some point in time create more specific UIs for some 
task, but the 80% case should work without modification of MiQ code.

We need to generate the views dynamically, by fetching the (meta) data 
and the schema and generating the view from that. That means we don't 
need to change anything on ui-classic to add new entity types.
Those *EntityView Ruby objects need to be created from data retrieved 
from the Hawkular side and not by checking in new code into the 
hawkular-provider gem when supporting new Entities.

The metadata should probably stored inside MiQ for faster access, but 
that is a 2ndary concern.


From jtakvori at redhat.com  Wed Jul 19 11:36:30 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Wed, 19 Jul 2017 17:36:30 +0200
Subject: [Hawkular-dev] Calculated metrics: sharing ideas
Message-ID: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>

Hi,

I just want to share some ideas about the eventuality of having a language
to perform some arithmetic / aggregations on metrics, before it goes out of
my head...

Here's an example of what I would personally love to see in Hawkular:

----------------------------------------------
*Example:*
*sum(stats(rate((id(my_metric), tags(a=foo AND b=bar),
regexp(something_.+)), 5m), 10m))*
|
|=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for id,
0-n for tags and regexp)
|==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten them in
a single set
|===> rate(set_of_raw_metrics, rate_period) computes the rate for each of
them and return a set of metrics (map n=>n)
|====> stats(set_of_raw_metrics, bucket_size) bucketize the raw metrics,
returning the same number of bucketized metrics (map n=>n)
|=====> sum(set_of_stats_metrics) sums every buckets, returning a single
bucketized metric (fold n=>1)


*Other:*
Functions like "sum" that take stats_metrics could have overloaded shortcut
"sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.
In other words above example could be rewritten:
*sum(rate((id(my_metric), tags(a=foo AND b=bar), regexp(something_.+)),
5m), 10m)*

Note: we can do aggregations like "sum" on raw data if necessary, it just
means we have to interpolate.

*Scalar operations:*
*sum((id(a_metric_in_milliseconds), 1000*id(a_metric_in_seconds)), 10m)*
----------------------------------------------

Of course many other functions could come growing the library.

Now I suppose the big question, if we want to do such thing, is "are we
going to invent our own language?" I don't know if there are standards for
this, and if they are good.

The Prometheus query language cannot be transposed because a label is not a
tag and it makes no sense for us to write something like
"my_metric{tag=foo}", it's either "my_metric" or "tag=foo".

The same language could be used both for read-time on-the-fly aggregations
and write-time / cron-based rollups.

WDYT?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170719/fc0a7be5/attachment-0001.html 

From cacosta at redhat.com  Wed Jul 19 11:43:05 2017
From: cacosta at redhat.com (Caina Costa)
Date: Wed, 19 Jul 2017 12:43:05 -0300
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
	<CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
	<BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
Message-ID: <CAJvPVZ4PA0hkBHRz18v7Bu+eZi8-OS_=k0WM5BmJL_kmjs2WjA@mail.gmail.com>

On Tue, Jul 18, 2017 at 9:42 AM, Heiko Rupp <hrupp at redhat.com> wrote:

> On 17 Jul 2017, at 15:59, Caina Costa wrote:
>
> > If we have a WildflyDomainControllerServer to render, first it will
> > try to find WildFlyDomainControllerServerView, then
>
> I (still) consider that a problem, even if better than what we have now.
> I can't tell e.g. the Infinispan folks "Listen you know your stuff
> better than we do, so please start writing Ruby code and create a
> pull-request against the hawkular-provider gem"
>

I've sent this just to you, instead of the group, so this is my other email:

I'm currently developing an extension to this system that allows exactly
that, to provide a JSON/YAML structure to dinamically generate views from
that. It is just a factory layer to generate views, but it will enable us
to do both options, either defining on the repository itself, for more
complex schemas, and importing from the server/a plain file for everything
else.

Something like that:

render json: View.from_schema(schema_from_server).new(entity)

I'm still defining the format correctly, but what I'm using right now looks
something like this:

summary:
  - name: id
  - name: name
  - name: active
    alias: is_active
foo:
  name: foo

Which, as  json would be something like that:

{"summary":[{"name":"id"},{"name":"name"},{"name":"active"
,"alias":"is_active"}],"foo":{"name":"foo"}}


>
> My goal really is to externalise that as much as possible (in to the
> hawkular-server or agent side), so that it is
> possible for other groups to write the description in e.g. JSON for
> their UI and the relation between Entities.
>
> Having that in Hawkular/Agent also allows us to introduce new supported
> stuff outside the release cycles of ManageIQ and their downstream
> CloudForms.
> I am not even sure if e.g. introducing support for Infinispan could be
> part of a z-Stream release, which is supposed to be bugfixes only.
> So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release
> after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular
> side, we can update the Middleware Manager / agent and the support would
> show automagically.
> Of course we may at some point in time create more specific UIs for some
> task, but the 80% case should work without modification of MiQ code.
>
> We need to generate the views dynamically, by fetching the (meta) data
> and the schema and generating the view from that. That means we don't
> need to change anything on ui-classic to add new entity types.
> Those *EntityView Ruby objects need to be created from data retrieved
> from the Hawkular side and not by checking in new code into the
> hawkular-provider gem when supporting new Entities.
>
> The metadata should probably stored inside MiQ for faster access, but
> that is a 2ndary concern.
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170719/7e569e54/attachment.html 

From cacosta at redhat.com  Wed Jul 19 11:59:03 2017
From: cacosta at redhat.com (Caina Costa)
Date: Wed, 19 Jul 2017 12:59:03 -0300
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
	<CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
	<BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
Message-ID: <CAJvPVZ6+qVRdBzfxBqCDdVKg7+8pmkU4Pk1b2hO1UgL8eXspvQ@mail.gmail.com>

So, an update:

I implemented support of json and yaml schemas to generate views
dynamically. A schema looks like this:

{
        "summary": [
                {"name": "id"},
                {"name": "active", "alias": "is_active"},
                {"name": "full_name", "alias": "name"}
        ],
        "foo": {"name": "foo"}
}

Which is functionally equivalent (it actually generates a view dynamically
with the same ruby code) to this:

pane :summary do
  field :id
  field :active, :is_active
  field :full_name, :mario
end

field :foo

And this is how it could be used to generate the views from data:

render json: View.from_json(unparsed_json).new(entity)
render json: View.from_yaml(unparsed_yaml).new(entity)
render json: View.from_hash(data_as_hash).new(entity)

Since those methods generate classes, they can be used to inherit new
views, or even doing something like this:

class EAPServerView < View.from_json(:code_to_get_from_hawkular)
end

Also, another important thing is that methods defined inside a view are
used for the rendering, so attribute transformation can done in the view,
instead of the entity if necessary, like this:

entity = OpenStruct.new(foo: :bar)
class MyView < View
  field :foo

  def foo
    :baz
  end
end

Then rendering it would return something like { "foo": "baz" }.

The changes are available on the same repo as always:
github.com/cfcosta/dynamic-entity-poc , and you can find examples on how
this work on view_spec.rb, and examples of schemas on
spec/fixtures/view_import.*


On Tue, Jul 18, 2017 at 9:42 AM, Heiko Rupp <hrupp at redhat.com> wrote:

> On 17 Jul 2017, at 15:59, Caina Costa wrote:
>
> > If we have a WildflyDomainControllerServer to render, first it will
> > try to find WildFlyDomainControllerServerView, then
>
> I (still) consider that a problem, even if better than what we have now.
> I can't tell e.g. the Infinispan folks "Listen you know your stuff
> better than we do, so please start writing Ruby code and create a
> pull-request against the hawkular-provider gem"
>
> My goal really is to externalise that as much as possible (in to the
> hawkular-server or agent side), so that it is
> possible for other groups to write the description in e.g. JSON for
> their UI and the relation between Entities.
>
> Having that in Hawkular/Agent also allows us to introduce new supported
> stuff outside the release cycles of ManageIQ and their downstream
> CloudForms.
> I am not even sure if e.g. introducing support for Infinispan could be
> part of a z-Stream release, which is supposed to be bugfixes only.
> So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release
> after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular
> side, we can update the Middleware Manager / agent and the support would
> show automagically.
> Of course we may at some point in time create more specific UIs for some
> task, but the 80% case should work without modification of MiQ code.
>
> We need to generate the views dynamically, by fetching the (meta) data
> and the schema and generating the view from that. That means we don't
> need to change anything on ui-classic to add new entity types.
> Those *EntityView Ruby objects need to be created from data retrieved
> from the Hawkular side and not by checking in new code into the
> hawkular-provider gem when supporting new Entities.
>
> The metadata should probably stored inside MiQ for faster access, but
> that is a 2ndary concern.
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170719/4c870d08/attachment.html 

From mazz at redhat.com  Wed Jul 19 13:51:57 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 19 Jul 2017 13:51:57 -0400 (EDT)
Subject: [Hawkular-dev] Calculated metrics: sharing ideas
In-Reply-To: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
References: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
Message-ID: <1361294295.56100813.1500486717332.JavaMail.zimbra@redhat.com>

Take a look at the query language of Prometheus:

https://prometheus.io/docs/querying/basics/

----- Original Message -----
> Hi,
> 
> I just want to share some ideas about the eventuality of having a language to
> perform some arithmetic / aggregations on metrics, before it goes out of my
> head...
> 
> Here's an example of what I would personally love to see in Hawkular:
> 
> ----------------------------------------------
> Example:
> sum(stats(rate((id(my_metric), tags(a=foo AND b=bar), regexp(something_.+)),
> 5m), 10m))
> | 
> |=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for id,
> |0-n for tags and regexp)
> |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten them in a
> |single set
> |===> rate(set_of_raw_metrics, rate_period) computes the rate for each of
> |them and return a set of metrics (map n=>n)
> |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw metrics,
> |returning the same number of bucketized metrics (map n=>n)
> |=====> sum(set_of_stats_metrics) sums every buckets, returning a single
> |bucketized metric (fold n=>1)
> 
> 
> Other:
> Functions like "sum" that take stats_metrics could have overloaded shortcut
> "sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.
> In other words above example could be rewritten:
> sum(rate((id(my_metric), tags(a=foo AND b=bar), regexp(something_.+)), 5m),
> 10m)
> 
> Note: we can do aggregations like "sum" on raw data if necessary, it just
> means we have to interpolate.
> 
> Scalar operations:
> sum((id(a_metric_in_milliseconds), 1000* id(a_metric_in_seconds)), 10m)
> ----------------------------------------------
> 
> Of course many other functions could come growing the library.
> 
> Now I suppose the big question, if we want to do such thing, is "are we going
> to invent our own language?" I don't know if there are standards for this,
> and if they are good.
> 
> The Prometheus query language cannot be transposed because a label is not a
> tag and it makes no sense for us to write something like
> "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".
> 
> The same language could be used both for read-time on-the-fly aggregations
> and write-time / cron-based rollups.
> 
> WDYT?
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From miburman at redhat.com  Thu Jul 20 02:51:31 2017
From: miburman at redhat.com (Michael Burman)
Date: Thu, 20 Jul 2017 09:51:31 +0300
Subject: [Hawkular-dev] Calculated metrics: sharing ideas
In-Reply-To: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
References: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
Message-ID: <1c46c626-f6fb-4271-d9da-9215719cb0a7@redhat.com>

Hi,

I'd personally would want to see another type of functional language, 
such that would look like the one when you do Streams / RxJava. I guess 
it's closer to the one in MongoDB/RethinkDB/InfluxDB 2.0/Riemann, than 
the one in Prometheus/Graphite (PromQL is mostly evolution of Graphite's 
query language).

And it could allow us to provide features such as streaming metrics, 
since we could transform those queries directly to reactive queries (we 
should take advantage of the fact that we process the metrics by 
reacting to them in the backend).

    - Micke


On 07/19/2017 06:36 PM, Joel Takvorian wrote:
> Hi,
>
> I just want to share some ideas about the eventuality of having a 
> language to perform some arithmetic / aggregations on metrics, before 
> it goes out of my head...
>
> Here's an example of what I would personally love to see in Hawkular:
>
> ----------------------------------------------
> *Example:*
> /sum(stats(rate((id(my_metric), tags(a=foo AND b=bar), 
> regexp(something_.+)), 5m), 10m))/
> |
> |=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for 
> id, 0-n for tags and regexp)
> |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten 
> them in a single set
> |===> rate(set_of_raw_metrics, rate_period) computes the rate for each 
> of them and return a set of metrics (map n=>n)
> |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw 
> metrics, returning the same number of bucketized metrics (map n=>n)
> |=====> sum(set_of_stats_metrics) sums every buckets, returning a 
> single bucketized metric (fold n=>1)
>
>
> *Other:*
> Functions like "sum" that take stats_metrics could have overloaded 
> shortcut "sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.
> In other words above example could be rewritten:
> /sum(rate((id(my_metric), tags(a=foo AND b=bar), 
> regexp(something_.+)), 5m), 10m)/
>
> Note: we can do aggregations like "sum" on raw data if necessary, it 
> just means we have to interpolate.
>
> *Scalar operations:*
> /sum((id(a_metric_in_milliseconds), *1000**id(a_metric_in_seconds)), 10m)/
> ----------------------------------------------
>
> Of course many other functions could come growing the library.
>
> Now I suppose the big question, if we want to do such thing, is "are 
> we going to invent our own language?" I don't know if there are 
> standards for this, and if they are good.
>
> The Prometheus query language cannot be transposed because a label is 
> not a tag and it makes no sense for us to write something like 
> "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".
>
> The same language could be used both for read-time on-the-fly 
> aggregations and write-time / cron-based rollups.
>
> WDYT?
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jtakvori at redhat.com  Thu Jul 20 07:58:02 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Thu, 20 Jul 2017 13:58:02 +0200
Subject: [Hawkular-dev] Calculated metrics: sharing ideas
In-Reply-To: <1c46c626-f6fb-4271-d9da-9215719cb0a7@redhat.com>
References: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
	<1c46c626-f6fb-4271-d9da-9215719cb0a7@redhat.com>
Message-ID: <CAJo5TF=Hq+JXia9f6PZBVqHzHf75kkD7RkrDjQGURew+cFsU9Q@mail.gmail.com>

The only one I've used a lot among those you mention is mongodb query
language. And honestly I don't like it very much, I find it quite
counter-intuitive to use. It's all JSON, everything must be named and
bracketed, I was quickly lost in a opened-closed-nested curly-braces hell.
For instance, querying for age > 40 is "{age:{$gt:40}}". It's probably easy
to implement as a query language, but it can become a nightmare for users.
In db world I see it as a big step backward from SQL, which is much more
"natural". (I just found that blog post that explains it better than me:
http://www.vertabelo.com/blog/notes-from-the-lab/sql-vs-mongo-query )

On Thu, Jul 20, 2017 at 8:51 AM, Michael Burman <miburman at redhat.com> wrote:

> Hi,
>
> I'd personally would want to see another type of functional language,
> such that would look like the one when you do Streams / RxJava. I guess
> it's closer to the one in MongoDB/RethinkDB/InfluxDB 2.0/Riemann, than
> the one in Prometheus/Graphite (PromQL is mostly evolution of Graphite's
> query language).
>
> And it could allow us to provide features such as streaming metrics,
> since we could transform those queries directly to reactive queries (we
> should take advantage of the fact that we process the metrics by
> reacting to them in the backend).
>
>     - Micke
>
>
> On 07/19/2017 06:36 PM, Joel Takvorian wrote:
> > Hi,
> >
> > I just want to share some ideas about the eventuality of having a
> > language to perform some arithmetic / aggregations on metrics, before
> > it goes out of my head...
> >
> > Here's an example of what I would personally love to see in Hawkular:
> >
> > ----------------------------------------------
> > *Example:*
> > /sum(stats(rate((id(my_metric), tags(a=foo AND b=bar),
> > regexp(something_.+)), 5m), 10m))/
> > |
> > |=> "id", "tags" and "regexp" all return a set of raw metrics (0-1 for
> > id, 0-n for tags and regexp)
> > |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten
> > them in a single set
> > |===> rate(set_of_raw_metrics, rate_period) computes the rate for each
> > of them and return a set of metrics (map n=>n)
> > |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw
> > metrics, returning the same number of bucketized metrics (map n=>n)
> > |=====> sum(set_of_stats_metrics) sums every buckets, returning a
> > single bucketized metric (fold n=>1)
> >
> >
> > *Other:*
> > Functions like "sum" that take stats_metrics could have overloaded
> > shortcut "sum(set_of_raw_metrics, bucket_size)" to perform the bucketing.
> > In other words above example could be rewritten:
> > /sum(rate((id(my_metric), tags(a=foo AND b=bar),
> > regexp(something_.+)), 5m), 10m)/
> >
> > Note: we can do aggregations like "sum" on raw data if necessary, it
> > just means we have to interpolate.
> >
> > *Scalar operations:*
> > /sum((id(a_metric_in_milliseconds), *1000**id(a_metric_in_seconds)),
> 10m)/
> > ----------------------------------------------
> >
> > Of course many other functions could come growing the library.
> >
> > Now I suppose the big question, if we want to do such thing, is "are
> > we going to invent our own language?" I don't know if there are
> > standards for this, and if they are good.
> >
> > The Prometheus query language cannot be transposed because a label is
> > not a tag and it makes no sense for us to write something like
> > "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".
> >
> > The same language could be used both for read-time on-the-fly
> > aggregations and write-time / cron-based rollups.
> >
> > WDYT?
> >
> >
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/ec2d543c/attachment.html 

From jshaughn at redhat.com  Thu Jul 20 08:35:51 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 20 Jul 2017 08:35:51 -0400
Subject: [Hawkular-dev] Calculated metrics: sharing ideas
In-Reply-To: <CAJo5TF=Hq+JXia9f6PZBVqHzHf75kkD7RkrDjQGURew+cFsU9Q@mail.gmail.com>
References: <CAJo5TF=iFCgA83kDXqZ4M+u7K6y9kB8pSJzn76xFV_OtDSLd7g@mail.gmail.com>
	<1c46c626-f6fb-4271-d9da-9215719cb0a7@redhat.com>
	<CAJo5TF=Hq+JXia9f6PZBVqHzHf75kkD7RkrDjQGURew+cFsU9Q@mail.gmail.com>
Message-ID: <c7de9f00-0bc9-bef6-7c1f-6c68ccc37cc8@redhat.com>


Perhaps you could get some ideas from the expression language we put 
together for the current metrics alerter.  It exists today but we could 
certainly change the alerter to use a new query language, if/when it 
exists.  I'd guess a lot of people don't realize you can even 
query/alert on hMetrics using these expressions.  For example, you could 
do something like this to test if the 90th percentile is greater than 
twice the median for a metric set defined by a tagQuery, either 
combining the metrics or testing them each individually.

   ( q(qNow,%90) > ( 2 * q(qNow,median) ) )


http://www.hawkular.org/hawkular-metrics/docs/user-guide/#_query_based_alerting

On 7/20/2017 7:58 AM, Joel Takvorian wrote:
> The only one I've used a lot among those you mention is mongodb query 
> language. And honestly I don't like it very much, I find it quite 
> counter-intuitive to use. It's all JSON, everything must be named and 
> bracketed, I was quickly lost in a opened-closed-nested curly-braces 
> hell. For instance, querying for age > 40 is "{age:{$gt:40}}". It's 
> probably easy to implement as a query language, but it can become a 
> nightmare for users. In db world I see it as a big step backward from 
> SQL, which is much more "natural". (I just found that blog post that 
> explains it better than me: 
> http://www.vertabelo.com/blog/notes-from-the-lab/sql-vs-mongo-query )
>
> On Thu, Jul 20, 2017 at 8:51 AM, Michael Burman <miburman at redhat.com 
> <mailto:miburman at redhat.com>> wrote:
>
>     Hi,
>
>     I'd personally would want to see another type of functional language,
>     such that would look like the one when you do Streams / RxJava. I
>     guess
>     it's closer to the one in MongoDB/RethinkDB/InfluxDB 2.0/Riemann, than
>     the one in Prometheus/Graphite (PromQL is mostly evolution of
>     Graphite's
>     query language).
>
>     And it could allow us to provide features such as streaming metrics,
>     since we could transform those queries directly to reactive
>     queries (we
>     should take advantage of the fact that we process the metrics by
>     reacting to them in the backend).
>
>         - Micke
>
>
>     On 07/19/2017 06:36 PM, Joel Takvorian wrote:
>     > Hi,
>     >
>     > I just want to share some ideas about the eventuality of having a
>     > language to perform some arithmetic / aggregations on metrics,
>     before
>     > it goes out of my head...
>     >
>     > Here's an example of what I would personally love to see in
>     Hawkular:
>     >
>     > ----------------------------------------------
>     > *Example:*
>     > /sum(stats(rate((id(my_metric), tags(a=foo AND b=bar),
>     > regexp(something_.+)), 5m), 10m))/
>     > |
>     > |=> "id", "tags" and "regexp" all return a set of raw metrics
>     (0-1 for
>     > id, 0-n for tags and regexp)
>     > |==> "(a,b,c)" takes n parameters, all sets of metrics, and flatten
>     > them in a single set
>     > |===> rate(set_of_raw_metrics, rate_period) computes the rate
>     for each
>     > of them and return a set of metrics (map n=>n)
>     > |====> stats(set_of_raw_metrics, bucket_size) bucketize the raw
>     > metrics, returning the same number of bucketized metrics (map n=>n)
>     > |=====> sum(set_of_stats_metrics) sums every buckets, returning a
>     > single bucketized metric (fold n=>1)
>     >
>     >
>     > *Other:*
>     > Functions like "sum" that take stats_metrics could have overloaded
>     > shortcut "sum(set_of_raw_metrics, bucket_size)" to perform the
>     bucketing.
>     > In other words above example could be rewritten:
>     > /sum(rate((id(my_metric), tags(a=foo AND b=bar),
>     > regexp(something_.+)), 5m), 10m)/
>     >
>     > Note: we can do aggregations like "sum" on raw data if necessary, it
>     > just means we have to interpolate.
>     >
>     > *Scalar operations:*
>     > /sum((id(a_metric_in_milliseconds),
>     *1000**id(a_metric_in_seconds)), 10m)/
>     > ----------------------------------------------
>     >
>     > Of course many other functions could come growing the library.
>     >
>     > Now I suppose the big question, if we want to do such thing, is "are
>     > we going to invent our own language?" I don't know if there are
>     > standards for this, and if they are good.
>     >
>     > The Prometheus query language cannot be transposed because a
>     label is
>     > not a tag and it makes no sense for us to write something like
>     > "my_metric{tag=foo}", it's either "my_metric" or "tag=foo".
>     >
>     > The same language could be used both for read-time on-the-fly
>     > aggregations and write-time / cron-based rollups.
>     >
>     > WDYT?
>     >
>     >
>     >
>     > _______________________________________________
>     > hawkular-dev mailing list
>     > hawkular-dev at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org <mailto:hawkular-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/36350c09/attachment.html 

From jtakvori at redhat.com  Thu Jul 20 09:15:16 2017
From: jtakvori at redhat.com (jtakvori at redhat.com)
Date: Thu, 20 Jul 2017 13:15:16 +0000
Subject: [Hawkular-dev] Invitation: Hawkular UI demos: alerts and metrics -
 ven. 21 juil. 2017 16:00 - 16:30 (CEST) (hawkular-dev@lists.jboss.org)
Message-ID: <001a114b3c2622fd520554bf8afa@google.com>

Vous avez ?t? invit? ? l'?v?nement suivant.

Titre : Hawkular UI demos: alerts and metrics
https://bluejeans.com/u/jtakvori/
Presentations of the two (small) UIs recently developed: one for metrics,  
the other for alerts.
Date?: ven. 21 juil. 2017 16:00 ? 16:30 Paris
Agenda?: hawkular-dev at lists.jboss.org
Participants?:
     * jtakvori at redhat.com- organisateur
     * hawkular-dev at lists.jboss.org

D?tails de l'?v?nement :  
https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr

Invitation de Google?Agenda?: https://www.google.com/calendar/

Vous recevez ce message ? l'adresse hawkular-dev at lists.jboss.org, car vous  
participez ? cet ?v?nement.

Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant.  
Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse  
https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de  
notification pour l'int?gralit? de votre agenda.

En transf?rant cette invitation, vous risquez d'autoriser tous les  
destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus,  
consultez la page suivante?:  
https://support.google.com/calendar/answer/37135#forwarding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/28a009ba/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1226 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/28a009ba/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1256 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/28a009ba/attachment-0003.bin 

From jtakvori at redhat.com  Thu Jul 20 10:45:22 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Thu, 20 Jul 2017 16:45:22 +0200
Subject: [Hawkular-dev]  Grafana datasource release: 1.0.9
Message-ID: <CAJo5TF=b23qLUqndOeTOjhGNoppy89++XZ5Vf-Z_0+SWDKQUwQ@mail.gmail.com>

Hawkular grafana datasource 1.0.9 has been released today:
https://github.com/hawkular/hawkular-grafana-datasource/releases/tag/v1.0.9


   - Implement stats on charts (feat. #79
   <https://github.com/hawkular/hawkular-grafana-datasource/issues/79>)
   - OpenShift template: added readiness and liveness probes (PR #76
   <https://github.com/hawkular/hawkular-grafana-datasource/pull/76>, big
   thanks to @ctron <https://github.com/ctron>)
   - Fixed display issue in OpenShift (PR #75
   <https://github.com/hawkular/hawkular-grafana-datasource/pull/75>, big
   thanks to @ctron <https://github.com/ctron>)
   - Updated openshift-memory-example to work with tags QL (PR #74
   <https://github.com/hawkular/hawkular-grafana-datasource/pull/74>)
   - Resolve variables in annotations (PR #71
   <https://github.com/hawkular/hawkular-grafana-datasource/pull/71>)
   - Updated Dockerfile to use Grafana 4.1.2 (PR #70
   <https://github.com/hawkular/hawkular-grafana-datasource/pull/70>)


The new docker image has been pushed to dockerhub, and grafana plugin
repository will soon be updated.


A screenshot with stats metrics:

[image: Inline image 1]

By the way, a blog post is on its way:
https://github.com/hawkular/hawkular.github.io/pull/330
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/32c64691/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2017-07-20-grafana-stats-none.png
Type: image/png
Size: 111446 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/32c64691/attachment-0001.png 

From cacosta at redhat.com  Thu Jul 20 16:29:00 2017
From: cacosta at redhat.com (Caina Costa)
Date: Thu, 20 Jul 2017 17:29:00 -0300
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <CAJvPVZ6+qVRdBzfxBqCDdVKg7+8pmkU4Pk1b2hO1UgL8eXspvQ@mail.gmail.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
	<CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
	<BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
	<CAJvPVZ6+qVRdBzfxBqCDdVKg7+8pmkU4Pk1b2hO1UgL8eXspvQ@mail.gmail.com>
Message-ID: <CAJvPVZ5Csdj=XZ9jHncE2C8k_cSjMZVe3Zb25m0Mj92ros2Z3Q@mail.gmail.com>

Hello Guys,

This is another update to the proof of concept, and today we are doing big
improvements to cover other parts of the representation that we did not
cover yet: fetching data from Hawkular, and turning that into
entities/views.

First, let's look at fetching data from Hawkular's Inventory:

# Create Client
client = Hawkular::Client.new(
  entrypoint: 'http://localhost:8080',
  credentials: { username: 'jdoe', password: 'password' },
  options: { tenant: 'hawkular' }
)

# Get all feeds available on the server
feeds = client.inventory.list_feeds

# Get all resources
feeds.map do |feed|
 # We get the resources for the feed
 resources = client.inventory.list_resources_for_feed(feed, true)
 # Then we make them presentable
 HawkularResourceCollection.new(resources).prepare
end
The first new thing here is HawkularResourceCollection, which does the
following:

Gets the raw representation of the properties defined by Hawkular
This is necessary because we want to use everything the server gives us,
not only what the gem decides to expose.
Creates the entities by mapping the data (we will cover that soon).
Merge other resource properties for the servers.
This last step is a little more complicated: there are two kinds of
resources that we get from the inventory: servers (like WildFly Servers)
and what I call resources: java runtime, operating systems, and so on. We
need some properties on the server that are exposed from the runtime/os,
like immutability controls, so we merge those to all the servers on the
feed.

To map the data to the entities, we use EntityMapper, a class that does
exactly this mapping. Besides that, it does name transformation for
properties, feed extracting, unescaping of paths, and returning a hash.
When we need to persist anything, this is the data that we generate for the
field, so persisting and fetching data from the db can looks like this:

# Getting data from the db, raw_hash being our json field to save the
response
server = MiddlewareServer.last
entity = Entity.constantize(server.raw_hash)

# And persisting an entity to the db
server.update(raw_hash: entity.data)
The generated hash is then fed to Entity.constantize, which returns the
entities we will use to render.

So, we have the data, and we have the entities. I have a standalone setup
running, generated by hawkinit, and the response contains the following:

A WildFly Server
The Java Runtime
The Operating System
Which will use the following entities/views to render (refer to old
emails/README.md for more on this):


?

Well, that's it. If you download the code at the github repo, you can see
this in action, by just running the server and visiting ./ It will list
everything hawkular found running, in pretty pretty json using the defined
views.

On Wed, Jul 19, 2017 at 12:59 PM, Caina Costa <cacosta at redhat.com> wrote:

> So, an update:
>
> I implemented support of json and yaml schemas to generate views
> dynamically. A schema looks like this:
>
> {
>         "summary": [
>                 {"name": "id"},
>                 {"name": "active", "alias": "is_active"},
>                 {"name": "full_name", "alias": "name"}
>         ],
>         "foo": {"name": "foo"}
> }
>
> Which is functionally equivalent (it actually generates a view dynamically
> with the same ruby code) to this:
>
> pane :summary do
>   field :id
>   field :active, :is_active
>   field :full_name, :mario
> end
>
> field :foo
>
> And this is how it could be used to generate the views from data:
>
> render json: View.from_json(unparsed_json).new(entity)
> render json: View.from_yaml(unparsed_yaml).new(entity)
> render json: View.from_hash(data_as_hash).new(entity)
>
> Since those methods generate classes, they can be used to inherit new
> views, or even doing something like this:
>
> class EAPServerView < View.from_json(:code_to_get_from_hawkular)
> end
>
> Also, another important thing is that methods defined inside a view are
> used for the rendering, so attribute transformation can done in the view,
> instead of the entity if necessary, like this:
>
> entity = OpenStruct.new(foo: :bar)
> class MyView < View
>   field :foo
>
>   def foo
>     :baz
>   end
> end
>
> Then rendering it would return something like { "foo": "baz" }.
>
> The changes are available on the same repo as always: github.com/cfcosta/
> dynamic-entity-poc , and you can find examples on how this work on
> view_spec.rb, and examples of schemas on spec/fixtures/view_import.*
>
>
> On Tue, Jul 18, 2017 at 9:42 AM, Heiko Rupp <hrupp at redhat.com> wrote:
>
>> On 17 Jul 2017, at 15:59, Caina Costa wrote:
>>
>> > If we have a WildflyDomainControllerServer to render, first it will
>> > try to find WildFlyDomainControllerServerView, then
>>
>> I (still) consider that a problem, even if better than what we have now.
>> I can't tell e.g. the Infinispan folks "Listen you know your stuff
>> better than we do, so please start writing Ruby code and create a
>> pull-request against the hawkular-provider gem"
>>
>> My goal really is to externalise that as much as possible (in to the
>> hawkular-server or agent side), so that it is
>> possible for other groups to write the description in e.g. JSON for
>> their UI and the relation between Entities.
>>
>> Having that in Hawkular/Agent also allows us to introduce new supported
>> stuff outside the release cycles of ManageIQ and their downstream
>> CloudForms.
>> I am not even sure if e.g. introducing support for Infinispan could be
>> part of a z-Stream release, which is supposed to be bugfixes only.
>> So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release
>> after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular
>> side, we can update the Middleware Manager / agent and the support would
>> show automagically.
>> Of course we may at some point in time create more specific UIs for some
>> task, but the 80% case should work without modification of MiQ code.
>>
>> We need to generate the views dynamically, by fetching the (meta) data
>> and the schema and generating the view from that. That means we don't
>> need to change anything on ui-classic to add new entity types.
>> Those *EntityView Ruby objects need to be created from data retrieved
>> from the Hawkular side and not by checking in new code into the
>> hawkular-provider gem when supporting new Entities.
>>
>> The metadata should probably stored inside MiQ for faster access, but
>> that is a 2ndary concern.
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/4b3ee38e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Entity.png
Type: image/png
Size: 3824 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170720/4b3ee38e/attachment.png 

From theute at redhat.com  Fri Jul 21 02:25:51 2017
From: theute at redhat.com (Thomas Heute)
Date: Fri, 21 Jul 2017 08:25:51 +0200
Subject: [Hawkular-dev] Grafana datasource release: 1.0.9
In-Reply-To: <CAJo5TF=b23qLUqndOeTOjhGNoppy89++XZ5Vf-Z_0+SWDKQUwQ@mail.gmail.com>
References: <CAJo5TF=b23qLUqndOeTOjhGNoppy89++XZ5Vf-Z_0+SWDKQUwQ@mail.gmail.com>
Message-ID: <CA+aN=Mq6Hy+XScXGYcOKyNNXMAFZ0pvTE8S1tfHAZcu-L1mp9g@mail.gmail.com>

Very nice !

On Thu, Jul 20, 2017 at 4:45 PM, Joel Takvorian <jtakvori at redhat.com> wrote:

> Hawkular grafana datasource 1.0.9 has been released today:
> https://github.com/hawkular/hawkular-grafana-
> datasource/releases/tag/v1.0.9
>
>
>    - Implement stats on charts (feat. #79
>    <https://github.com/hawkular/hawkular-grafana-datasource/issues/79>)
>    - OpenShift template: added readiness and liveness probes (PR #76
>    <https://github.com/hawkular/hawkular-grafana-datasource/pull/76>, big
>    thanks to @ctron <https://github.com/ctron>)
>    - Fixed display issue in OpenShift (PR #75
>    <https://github.com/hawkular/hawkular-grafana-datasource/pull/75>, big
>    thanks to @ctron <https://github.com/ctron>)
>    - Updated openshift-memory-example to work with tags QL (PR #74
>    <https://github.com/hawkular/hawkular-grafana-datasource/pull/74>)
>    - Resolve variables in annotations (PR #71
>    <https://github.com/hawkular/hawkular-grafana-datasource/pull/71>)
>    - Updated Dockerfile to use Grafana 4.1.2 (PR #70
>    <https://github.com/hawkular/hawkular-grafana-datasource/pull/70>)
>
>
> The new docker image has been pushed to dockerhub, and grafana plugin
> repository will soon be updated.
>
>
> A screenshot with stats metrics:
>
> [image: Inline image 1]
>
> By the way, a blog post is on its way: https://github.com/
> hawkular/hawkular.github.io/pull/330
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170721/4471bcbb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2017-07-20-grafana-stats-none.png
Type: image/png
Size: 111446 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170721/4471bcbb/attachment-0001.png 

From abonas at redhat.com  Fri Jul 21 08:41:15 2017
From: abonas at redhat.com (Alissa Bonas)
Date: Fri, 21 Jul 2017 15:41:15 +0300
Subject: [Hawkular-dev] Invitation: Hawkular UI demos: alerts and
 metrics - ven. 21 juil. 2017 16:00 - 16:30 (CEST)
 (hawkular-dev@lists.jboss.org)
In-Reply-To: <001a114b3c2622fd520554bf8afa@google.com>
References: <001a114b3c2622fd520554bf8afa@google.com>
Message-ID: <CAOJV2uDktajPDy01LvVqkQe-a=d-R-_91=YKg=Zbkb5N7f7k4Q@mail.gmail.com>

Please record it

On Jul 20, 2017 16:51, <jtakvori at redhat.com> wrote:

> plus d'infos ?
> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
> Hawkular UI demos: alerts and metrics
> https://bluejeans.com/u/jtakvori/
> <https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2Fu%2Fjtakvori%2F&sa=D&usd=2&usg=AFQjCNGDKiK9mvzs0DY6NR4cMic1Hqqytw>
> Presentations of the two (small) UIs recently developed: one for metrics,
> the other for alerts.
> *Date*
> ven. 21 juil. 2017 16:00 ? 16:30 Paris
>
> *Agenda*
> hawkular-dev at lists.jboss.org
>
> *Participants*
> ?
> jtakvori at redhat.com- organisateur
> ?
> hawkular-dev at lists.jboss.org
>
> Allez-vous participer ?   *Oui
> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=1&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
> - Peut-?tre
> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=3&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
> - Non
> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=2&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>*
>     plus d'options ?
> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>
> Invitation de Google Agenda <https://www.google.com/calendar/>
>
> Vous recevez ce message ? l'adresse hawkular-dev at lists.jboss.org, car
> vous participez ? cet ?v?nement.
>
> Refusez cet ?v?nement pour ne plus recevoir de notifications le
> concernant. Vous avez ?galement la possibilit? de cr?er un compte Google ?
> l'adresse https://www.google.com/calendar/ et de d?finir vous-m?me les
> param?tres de notification pour l'int?gralit? de votre agenda.
>
> En transf?rant cette invitation, vous risquez d'autoriser tous les
> destinataires ? modifier votre r?ponse ? l'invitation. En savoir plus
> <https://support.google.com/calendar/answer/37135#forwarding>.
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170721/3eda57cc/attachment.html 

From theute at redhat.com  Fri Jul 21 10:36:34 2017
From: theute at redhat.com (Thomas Heute)
Date: Fri, 21 Jul 2017 14:36:34 +0000
Subject: [Hawkular-dev] New Hawkular Blog Post: Protecting Jaeger UI with a
 sidecar security proxy
Message-ID: <59721172786a4_583b5333384891c@mini-queue-01.resque.ife.mail>

New Hawkular blog post from noreply at hawkular.org (Juraci Paix?o Kr?hling): http://ift.tt/2uhE5Lj

In a production deployment of Jaeger, it may be advantageous to restrict access to Jaeger?s Query service, which includes the UI. For instance, you might have internal security requirements to allow only certain groups to access trace data, or you might have deployed Jaeger into a public cloud. In a true microservices way, one possible approach is to add a sidecar to the Jaeger Query service, acting as a security proxy. Incoming requests hit our sidecar instead of reaching Jaeger?s Query service directly and the sidecar would be responsible for enforcing the authentication and authorization constraints.

Incoming HTTP requests arrive at the route ?, which uses the internal service ? to resolve and communicate with the security proxy ?. Once the request is validated and all security constraints are satisfied, the request reaches Jaeger ?.

For demonstration purposes we?ll make use of Keycloak as our security solution, but the idea can be adapted to work with any security proxy. This demo should also work without changes with Red Hat SSO. For this exercise, we?ll need:

A Keycloak (or Red Hat SSO) server instance running. We?ll call its location ${REDHAT_SSO_URL}

An OpenShift cluster, where we?ll run Jaeger backend components. It might be as easy as oc cluster up

A local clone of the Jaeger OpenShift Production template

Note that we are not trying to secure the communication between the components, like from the Agent to the Collector. For this scenario, there are other techniques that can be used, such as mutual authentication via certificates, employing istio or other similar tools.

Preparing Keycloak

For this demo, we?ll run Keycloak via Docker directly on the host machine. This is to stress that Keycloak does not need to be running on the same OpenShift cluster as our Jaeger backend.

The following command should start an appropriate Keycloak server locally. If you already have your own Keycloak or Red Hat SSO server, skip this step.

docker run --rm --name keycloak-server -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=password -p 8080:8080 jboss/keycloak

Once the Keycloak server is up and running, let?s create a realm for Jaeger:

Login into Keycloak (http://&lt;YOUR_IP&gt;:8080/auth/admin/master/console) with admin as username and password as password

In the top left corner, mouse over the Select realm box and click Add realm. Name it jaeger and click Create

On Clients, click Create and set proxy-jaeger as the name and save it

Set the Access Type to confidential and * as Valid Redirect URIs and save it. You might want to fine tune this in a production environment, otherwise you might be open to an attack known as &quot;Unvalidated Redirects and Forwards&quot;.

Open the Installation tab and select Keycloak OIDC JSON and copy the JSON that is shown. It should look like this, but the auth-server-url and secret will have different values.

{
  &quot;realm&quot;: &quot;jaeger&quot;,
  &quot;auth-server-url&quot;: &quot;http://ift.tt/2tmR0IR&quot;,
  &quot;ssl-required&quot;: &quot;external&quot;,
  &quot;resource&quot;: &quot;proxy-jaeger&quot;,
  &quot;credentials&quot;: {
    &quot;secret&quot;: &quot;7f201319-1dfd-43cc-9838-057dac439046&quot;
  }
}

And finally, let?s create a role and a user, so that we can log into Jaeger?s Query service:

Under the Configure left-side menu, open the Roles page and click Add role

As role name, set user and click Save

Under the Manage left-side menu, open the Users page and click Add user

Fill out the form as you wish and set Email verified to ON and click on Save

Open the Credentials tab for this user and set a password (temporary or not).

Open the Role mappings tab for this user, select the role user from the Available Roles list and click Add selected

Preparing OpenShift

For this demo, we assume you have an OpenShift cluster running already. If you don?t, then you might want to check out tools like minishift. If you are running a recent version of Fedora, CentOS or Red Hat Enterprise Linux you might want to install the package origin-clients and run oc cluster up --version=latest. This should get you a basic OpenShift cluster running locally.

To make it easier for our demonstration, we?ll add cluster-admin rights to our developer user and we?ll create the Jaeger namespace:

oc login -u system:admin
oc new-project jaeger
oc adm policy add-cluster-role-to-user cluster-admin developer -n jaeger
oc login -u developer

Preparing the Jaeger OpenShift template

We?ll use the Jaeger OpenShift Production template as the starting point: either clone the entire repository, or just get a local version of the template.

The first step is to add the sidecar container to the query-deployment object. Under the containers list, after we specify the jaeger-query, let?s add the sidecar:

        - image: jboss/keycloak-proxy
          name: ${JAEGER_SERVICE_NAME}-query-security-proxy
          volumeMounts:
          - mountPath: /opt/jboss/conf
            name: security-proxy-configuration-volume
          ports:
          - containerPort: 8080
            protocol: TCP
          readinessProbe:
            httpGet:
              path: &quot;/&quot;
              port: 8080

Note that container specifies a volumeMount named security-proxy-configuration-volume: we?ll use it to store the proxy?s configuration file. You should add the volume under the spec/template/spec node for query-deployment, sibling to the dnsPolicy property (it?s probably right under the previous code snippet):

        volumes:
          - configMap:
              name: ${JAEGER_SERVICE_NAME}-configuration
              items:
                - key: proxy
                  path: proxy.json
            name: security-proxy-configuration-volume

Now, we need to specify the ConfigMap, with the proxy?s configuration entry. To do that, we add a new top-level item to the template. As a suggestion, we recommend keeping it close to where it?s consumed. For instance, right before the query-deployment:

- apiVersion: v1
  kind: ConfigMap
  metadata:
    name: ${JAEGER_SERVICE_NAME}-configuration
    labels:
      app: jaeger
      jaeger-infra: security-proxy-configuration
  data:
    proxy: |
      {
          &quot;target-url&quot;: &quot;http://localhost:16686&quot;,
          &quot;bind-address&quot;: &quot;0.0.0.0&quot;,
          &quot;http-port&quot;: &quot;8080&quot;,
          &quot;applications&quot;: [
              {
                  &quot;base-path&quot;: &quot;/&quot;,
                  &quot;adapter-config&quot;: {
                    &quot;realm&quot;: &quot;jaeger&quot;,
                    &quot;auth-server-url&quot;: &quot;${REDHAT_SSO_URL}&quot;,
                    &quot;ssl-required&quot;: &quot;external&quot;,
                    &quot;resource&quot;: &quot;proxy-jaeger&quot;,
                    &quot;credentials&quot;: {
                      &quot;secret&quot;: &quot;THE-SECRET-FROM-INSTALLATION-FILE&quot;
                    }
                  }
            ,
            &quot;constraints&quot;: [
                      {
                          &quot;pattern&quot;: &quot;/*&quot;,
                          &quot;roles-allowed&quot;: [
                              &quot;user&quot;
                          ]
                      }
                  ]
              }
          ]
      }

Note that we are only allowing users with the role user to log into our Jaeger UI. In a real world scenario, you might want to adjust this to fit your setup. For instance, your user data might come from LDAP, and you only want to allow users from specific LDAP groups to access the Jaeger UI.

The secret within the credentials should match the secret we got from Keycloak at the beginning of this exercise. Our most curious readers will note that we mentioned the template parameter REDHAT_SSO_URL under the property auth-server-url. Either change that to your Keycloak server, or let?s specify a template parameter, allowing us to set this at deployment time. Under the parameters section of the template, add the following property:

- description: The URL to the Red Hat SSO / Keycloak server
  displayName: Red Hat SSO URL
  name: REDHAT_SSO_URL
  required: true
  value: http://THE-URL-FROM-THE-INSTALLATION-FILE:8080/auth

This value should be a location that is reacheable by both your browser and by the sidecar, like your host?s LAN IP (192.x, 10.x). Localhost/127.x is not going to work.

As a final step, we need to change the service to direct requests to the port 8080 (proxy) instead of 16686. This is done by changing the property targetPort on the service named query-service, setting it to 8080:

- apiVersion: v1
  kind: Service
  metadata:
    name: ${JAEGER_SERVICE_NAME}-query
    labels:
      app: jaeger
      jaeger-infra: query-service
  spec:
    ports:
    - name: jaeger-query
      port: 80
      protocol: TCP
      targetPort: 8080
    selector:
      jaeger-infra: query-pod
    type: LoadBalancer

As a reference, here?s the complete template file that can be used for this blog post.

Deploying

Now that we have everything ready, let?s deploy Jaeger into our OpenShift cluster. Run the following command from the same directory you stored the YAML file from the previous steps, referenced here by the name jaeger-production-template.yml:

oc process -f jaeger-production-template.yml | oc create -n jaeger -f -

During the first couple of minutes, it?s OK if the pods jaeger-query and jaeger-collector fail, as Cassandra will still be booting. Eventually, the service should be up and running, as shown in the following image.

Once it is ready to serve requests, click on URL for the route (http://ift.tt/2uIOgZQ). You should be presented with a login screen, served by the Keycloak server. Login with the credentials you set on the previous steps, and you should reach the regular Jaeger UI.

Conclusion

In this exercise, we?ve seen how to add a security proxy to our Jaeger Query pod as a sidecar. All incoming requests go through this sidecar and all features available in Keycloak can be used transparently, such as 2-Factor authentication, service accounts, single sign-on, brute force attack protection, LDAP support and much more.

from Hawkular Blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170721/306531d6/attachment-0001.html 

From jtakvori at redhat.com  Fri Jul 21 10:57:49 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Fri, 21 Jul 2017 16:57:49 +0200
Subject: [Hawkular-dev] Invitation: Hawkular UI demos: alerts and
 metrics - ven. 21 juil. 2017 16:00 - 16:30 (CEST)
 (hawkular-dev@lists.jboss.org)
In-Reply-To: <CAOJV2uDktajPDy01LvVqkQe-a=d-R-_91=YKg=Zbkb5N7f7k4Q@mail.gmail.com>
References: <001a114b3c2622fd520554bf8afa@google.com>
	<CAOJV2uDktajPDy01LvVqkQe-a=d-R-_91=YKg=Zbkb5N7f7k4Q@mail.gmail.com>
Message-ID: <CAJo5TF=NxVmTK96wUBz50ahyGcrjvtPvCrRcVHNjzEqtiUtrOw@mail.gmail.com>

Recording link: https://bluejeans.com/s/7hiCO/

By the way I started to open enhancement tickets here based on comments
https://github.com/hawkular/hawkular-ui/issues

Feel free to add more

2017-07-21 14:41 GMT+02:00 Alissa Bonas <abonas at redhat.com>:

> Please record it
>
> On Jul 20, 2017 16:51, <jtakvori at redhat.com> wrote:
>
>> plus d'infos ?
>> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>> Hawkular UI demos: alerts and metrics
>> https://bluejeans.com/u/jtakvori/
>> <https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2Fu%2Fjtakvori%2F&sa=D&usd=2&usg=AFQjCNGDKiK9mvzs0DY6NR4cMic1Hqqytw>
>> Presentations of the two (small) UIs recently developed: one for metrics,
>> the other for alerts.
>> *Date*
>> ven. 21 juil. 2017 16:00 ? 16:30 Paris
>>
>> *Agenda*
>> hawkular-dev at lists.jboss.org
>>
>> *Participants*
>> ?
>> jtakvori at redhat.com- organisateur
>> ?
>> hawkular-dev at lists.jboss.org
>>
>> Allez-vous participer ?   *Oui
>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=1&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>> - Peut-?tre
>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=3&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>> - Non
>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=2&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>*
>>     plus d'options ?
>> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>>
>> Invitation de Google Agenda <https://www.google.com/calendar/>
>>
>> Vous recevez ce message ? l'adresse hawkular-dev at lists.jboss.org, car
>> vous participez ? cet ?v?nement.
>>
>> Refusez cet ?v?nement pour ne plus recevoir de notifications le
>> concernant. Vous avez ?galement la possibilit? de cr?er un compte Google ?
>> l'adresse https://www.google.com/calendar/ et de d?finir vous-m?me les
>> param?tres de notification pour l'int?gralit? de votre agenda.
>>
>> En transf?rant cette invitation, vous risquez d'autoriser tous les
>> destinataires ? modifier votre r?ponse ? l'invitation. En savoir plus
>> <https://support.google.com/calendar/answer/37135#forwarding>.
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170721/b40cc850/attachment.html 

From theute at redhat.com  Mon Jul 24 07:20:42 2017
From: theute at redhat.com (Thomas Heute)
Date: Mon, 24 Jul 2017 11:20:42 +0000
Subject: [Hawkular-dev] New Hawkular Blog Post: Grafana: new query interface
Message-ID: <5975d80aa2835_2f79a9d31480987@mini-queue-07.resque.ife.mail>

New Hawkular blog post from noreply at hawkular.org (Joel Takvorian): http://ift.tt/2uPct0T

There have been improvements lately in the Hawkular Grafana datasource that are worth mentioning.

The way to query metrics by tags has changed since plugin v1.0.8. It now takes advantage of the Hawkular Metrics' tags query language, that was introduced server-side in Metrics 0.24.0 and enhanced in 0.25.0. To sum it up, Metrics integrates a parser that allows queries such as: tag1 = 'awesome!' AND tag2 NOT IN ['foo', 'bar'].

The datasource in now able to fetch bucketized metrics stats, instead of raw metrics. It consists in aggregating datapoints in slices of time (buckets) and providing, for each slice, some statistics like min, max, average and more. The exact content of a bucket is described in Metrics REST API. Hawkular has always been able to provide metric stats server-side, but being able to use them in the Grafana plugin is new, introduced in v1.0.9.

The new query interface

Tags query language

The first change is that you don?t have to choose between query by tag and query by metric id anymore, you can do both at the same time. Querying by tag will refine the available list of metric names (much like a filter) and can result in multiple metrics from a single query. By selecting a metric name, you restrict the query to only display that one. This filtering is really nice when there?s tons of metrics available, like in the case of hundreds of OpenShift pods being monitored with the same tenant.

The simple key/value pairs interface is now replaced with a more elaborated query builder, following the pattern: 'tag-key' 'operator' 'tag-value(s)' ['AND/OR' etc.]

The following images show a walk-through:

Selecting the tag key

Selecting the tag operator

Selecting the tag value

The text fields include dynamic suggestions, you can use Grafana template variables within tag values, or enter free text. Once you?ve set up a tag query expression, the relevant metrics immediately show up on the chart and the list of available metrics in the dropdown list in updated.

Filtered metrics

This query builder lets you build almost any tag query that the Hawkular server understands. There are however some corner cases. For now this builder doesn?t allow you to prioritize expressions with parentheses. For instance, you cannot build c1 = 'foo' OR (b1 != 'B' AND a1 = 'abcd'). As a workaround you can turn off the query builder and directly type in your query expression.

Toggle editor mode

It will be sent as is to the Hawkular Metrics server. This will also be useful to fill the gap if the language evolves server-side and this plugin isn?t updated immediately.

Stats query

The other important feature is the ability to run stats queries against Hawkular Metrics, instead of raw queries. There are several reasons to do this:

it reduces the network load, and client-side processing load, especially when raw data would contain tons of datapoints

it enables some aggregation methods

it also allows higher-level analysis with stats such as percentiles

To enable it, just clear the raw checkbox.

Toggle stats mode

When you clear the raw checkbox, you can configure Multiple series aggregation to None, Sum or Average and can configure Stat type as avg, min, max, median, sum and different percentiles. You can display several different Stat types within the same query.

Stats without aggregation: each two metrics show avg, min and max

Same query with series aggregation: the two metrics are averaged into one, which shows avg, min and max

If the query returns multiple series, use Multiple series aggregation to define if and how to aggregate them. None will show them individually on the chart. But consider for instance the case of an OpenShift pod with many replicas, and you?re tracking their memory usage. It may be more relevant here to aggregate all of them, both sum and average are meaningful here.

The Stat type option refers to an aggregation at a different level: not between multiple metrics, but within a single metric, all raw datapoints are aggregated within time buckets.

Conclusion

These two improvements aim a common goal, that is facilitating querying over large amounts of data. This is becoming crucial especially in the context of microservices and applications running on container platforms, as the number of metrics explodes. Proper metrics tagging is the corner stone to make sense of this data.

from Hawkular Blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170724/b4feec05/attachment.html 

From hrupp at redhat.com  Fri Jul 28 04:03:21 2017
From: hrupp at redhat.com (hrupp at redhat.com)
Date: Fri, 28 Jul 2017 08:03:21 +0000
Subject: [Hawkular-dev] Einladung: Android Client Progress - Fr 4. Aug. 2017
 4PM - 4:50PM (MESZ) (hawkular-dev@lists.jboss.org)
Message-ID: <94eb2c0d23be5e080005555c1d01@google.com>

Sie wurden f?r den folgenden Termin eingeladen.

Titel: Android Client Progress
Pallavi is demoing her work so far on the Android Client as part of her  
Google Summer of Code work.
Wann: Fr 4. Aug. 2017 4PM ? 4:50PM Berlin
Wo: BlueJeans: https://redhat.bluejeans.com/2042160481
Kalender: hawkular-dev at lists.jboss.org
Wer
     * hrupp at redhat.com - Organisator
     * Pallavi Gupta
     * anujgargcse at gmail.com
     * hawkular-dev at lists.jboss.org
     * lponce at redhat.com - Optional
     * jshaughn at redhat.com - Optional

Termininformationen:  
https://www.google.com/calendar/event?action=VIEW&eid=NTRzNDd0b2M2cGJoMGltMWh2MmI5ZG1vZmQgaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTYjaHJ1cHBAcmVkaGF0LmNvbWQ1OTU0NmZmNzFiODk1OWI3NzhlZGM3YmJlOTk4MWEyY2VhYjQ4MTA&ctz=Europe/Berlin&hl=de

Einladung von Google Kalender: https://www.google.com/calendar/

Sie erhalten diese E-Mail unter hawkular-dev at lists.jboss.org, da Sie ein  
Gast bei diesem Termin sind.

Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem  
Termin zu erhalten. Sie k?nnen auch unter https://www.google.com/calendar/  
ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen f?r  
Ihren gesamten Kalender steuern.

Wenn Sie diese Einladung weiterleiten, kann jeder Empf?nger Ihre Antwort  
auf die Einladung ?ndern. Weitere Informationen finden Sie unter  
https://support.google.com/calendar/answer/37135#forwarding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170728/aa50b71b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1792 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170728/aa50b71b/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1830 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170728/aa50b71b/attachment-0003.bin 

From mazz at redhat.com  Thu Jul 27 19:17:34 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 27 Jul 2017 19:17:34 -0400 (EDT)
Subject: [Hawkular-dev] some of the new hAlerts UI
In-Reply-To: <58026403.61318469.1501196712321.JavaMail.zimbra@redhat.com>
Message-ID: <382687604.61319479.1501197454128.JavaMail.zimbra@redhat.com>

Just wanted to give a quick update of the new hAlerts 2.0 UI that is under construction. I know folks are hearing about hAlerts but haven't seen it. Below is what Lucas, Jay, and myself have been working on the past two weeks or so. Still a work in progress, but this is what we've got so far. 

The first is the dashboard that shows you an overview of what alerts are in the system - some graphs, timelines, and counters - all using Patternfly styles. 

The second is the alerts list that utilizes the Patternfly Compound Expansion List . You can filter on date, severity (critical, high, etc), status (open, acked, resolved); it shows you details about alerts including lifecycle info (who acknowledged and resolved them), users' notes about the alerts, what conditions caused the alerts to fire, etc. etc. You can ack, resolve, and delete alerts. 




Other parts of the UI not shown here are the triggers and actions pages (let's you define triggers and actions). But the snapshots below are the more colorful and pretty pages - I'm all about sharing eye candy :) 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170727/e015060d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dash.png
Type: image/png
Size: 65415 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170727/e015060d/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: list.png
Type: image/png
Size: 116125 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170727/e015060d/attachment-0003.png 

From theute at redhat.com  Fri Jul 28 05:11:21 2017
From: theute at redhat.com (Thomas Heute)
Date: Fri, 28 Jul 2017 09:11:21 +0000
Subject: [Hawkular-dev] New Hawkular Blog Post: OpenTracing EJB
	instrumentation
Message-ID: <597affb99c47_264ea173189272f@mini-queue-02.resque.ife.mail>

New Hawkular blog post from noreply at hawkular.org (Juraci Paix?o Kr?hling): http://ift.tt/2u3KYMP

OpenTracing features more and more framework integrations, allowing for transparent instrumentation of applications with minimal effort. This blog post will show how to use the EJB instrumentation to automatically trace EJB invocations.

For this demo, we?ll generate a project using the Wildfly Swarm project generator, which allows us to have a seed project with the appropriate OpenTracing support in place. The concrete OpenTracing solution we will use is provided by the Jaeger project, which is also provided as a Wildfly Swarm Fraction.

With that, we?ll create a simple JAX-RS endpoint with an EJB facet, invoking a set of EJB services in different ways to demonstrate all the features of this integration.

Our application has one endpoint called /order, responsible for receiving requests to place orders in our system. When we call this endpoint, we also call some other EJB services, like

AccountService to send a notification that an order has been placed

OrderService to effectively place the order

InventoryService to change our inventory

InventoryNotificationService, to notify other backend systems.

As we are only interested in the tracing parts, we?ll not implement the business code itself, only the scaffolding.

Our demo project is heavily based on the opentracing-ejb-example from the repository opentracing-contrib/java-ejb. We have also prepared an archive with the final outcome of this demo, which you can use as reference.

The seed project

To generate the seed project, open the Wildfly Swarm generator and create a project with the &quot;Group ID&quot; io.opentracing.contrib.ejb and &quot;Artifact ID&quot; demo-example. Add the dependencies EJB, CDI, JAX-RS, OpenTracing, and Jaeger.

Make sure to select all listed dependencies and confirm that they are shown in the &quot;Selected dependencies&quot; section, otherwise, you might not have all the required fractions for this demo.

Click on Generate Project and you?ll get a ZIP file with the seed project. Uncompress it and add the following dependency to the pom.xml, within the dependencies node and after the WildFly Swarm Fractions dependencies:

    &lt;dependency&gt;
      &lt;groupId&gt;io.opentracing.contrib&lt;/groupId&gt;
      &lt;artifactId&gt;opentracing-ejb&lt;/artifactId&gt;
      &lt;version&gt;0.0.2&lt;/version&gt;
    &lt;/dependency&gt;

It?s now a good time to perform a sanity build, to make sure everything is in place. The first build might take a few minutes:

$ mvn wildfly-swarm:run
...
...
2017-07-26 12:02:19,154 INFO  [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm is Ready

If it looks good, stop the server with Ctrl+C and let?s start coding our application!

The application

Let?s start by defining a JAX-RS endpoint that also acts as a stateless EJB. This is a common trick to get JAX-RS endpoints to be managed as EJBs, so that they can be invoked via JMX or get monitoring features. Or, in our case, to get traced via EJB interceptors.

This endpoint is where we get our HTTP requests from and where our transaction starts, from the tracing perspective. Once we receive an HTTP request, we call the AccountService#sendNotification method and then the OrderService#processOrderPlacement.

Note that we annotate the class with @Interceptors(OpenTracingInterceptor.class), which means that all methods on this class are to be traced.

src/main/java/io/opentracing/contrib/ejb/demoexample/Endpoint.java:

package io.opentracing.contrib.ejb.demoexample;

import io.opentracing.contrib.ejb.OpenTracingInterceptor;

import javax.ejb.Stateless;
import javax.inject.Inject;
import javax.interceptor.Interceptors;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import java.util.logging.Logger;

/**
 * This is a regular JAX-RS endpoint with EJB capabilities. We use the EJB capability to specify an interceptor,
 * so that every method on this class is wrapped on its own span. If the OpenTracing JAX-RS integration is being used,
 * it would be a good idea to not have the interceptor at this level, to avoid having too much &quot;noise&quot;.
 *
 * @author Juraci Paix?o Kr?hling
 */
@Path(&quot;/order&quot;)
@Stateless
@Interceptors(OpenTracingInterceptor.class)
public class Endpoint {
    private static final Logger log = Logger.getLogger(Endpoint.class.getName());

    @Inject
    AccountService accountService;

    @Inject
    OrderService orderService;

    @POST
    @Path(&quot;/&quot;)
    public String placeOrder() {
        log.info(&quot;Request received to place an order&quot;);
        accountService.sendNotification();
        orderService.processOrderPlacement();
        return &quot;Order placed&quot;;
    }

}

Our AccountService is a simple stateless EJB, responsible for sending a notification about the new order to the owner of the account. Here, we could call another service, or send an email, SMS or any other form of message.

As this is a regular EJB, we are able to automatically join the span context from the JAX-RS endpoint, making this call a child span of the main transaction. This is all transparent to you as developer.

Note again that we annotate the bean with @Interceptors(OpenTracingInterceptor.class). As our interceptor is just like any other EJB interceptor, you could use a ejb-jar.xml to automatically use this inteceptor on all available beans. Whether or not to trace all beans is a per-deployment decision, so, no ejb-jar.xml is provided by the integration.

src/main/java/io/opentracing/contrib/ejb/demoexample/AccountService.java:

package io.opentracing.contrib.ejb.demoexample;

import io.opentracing.contrib.ejb.OpenTracingInterceptor;

import javax.ejb.Stateless;
import javax.interceptor.Interceptors;
import java.util.logging.Logger;

/**
 * This is a simple synchronous EJB, without any knowledge about span context or other OpenTracing semantics. All it
 * does is specify an interceptor and it's shown as the child of a parent span.
 *
 * @author Juraci Paix?o Kr?hling
 */
@Stateless
@Interceptors(OpenTracingInterceptor.class)
public class AccountService {
    private static final Logger log = Logger.getLogger(AccountService.class.getName());

    public void sendNotification() {
        log.info(&quot;Notifying the account owner about a new order&quot;);
    }
}

Our OrderService is responsible for actually placing the order: it?s where the business knowledge resides. We?ll later look into details at the InventoryService, but for now, we need to know that this service requires a SpanContext to be explicitly passed. We can get this context from the EJBContext, stored under a context data entry that can be retrieved with the constant io.opentracing.contrib.ejb.OpenTracingInterceptor.SPAN_CONTEXT.

src/main/java/io/opentracing/contrib/ejb/demoexample/OrderService.java:

package io.opentracing.contrib.ejb.demoexample;

import io.opentracing.SpanContext;
import io.opentracing.contrib.ejb.OpenTracingInterceptor;

import javax.annotation.Resource;
import javax.ejb.EJBContext;
import javax.ejb.Stateless;
import javax.inject.Inject;
import javax.interceptor.Interceptors;
import java.util.logging.Logger;

import static io.opentracing.contrib.ejb.OpenTracingInterceptor.SPAN_CONTEXT;

/**
 * This is a regular synchronous stateless EJB. It demonstrates how to get the span context for the span it's wrapped
 * on. This can be used to pass down the call chain, create child spans or add baggage items.
 *
 * @author Juraci Paix?o Kr?hling
 */
@Stateless
@Interceptors(OpenTracingInterceptor.class)
public class OrderService {
    private static final Logger log = Logger.getLogger(OrderService.class.getName());

    @Resource
    EJBContext ctx;

    @Inject
    InventoryService inventoryService;

    public void processOrderPlacement() {
        log.info(&quot;Placing order&quot;);
        Object ctxParentSpan = ctx.getContextData().get(SPAN_CONTEXT);
        if (ctxParentSpan instanceof SpanContext) {
            inventoryService.changeInventory((SpanContext) ctxParentSpan);
            return;
        }

        inventoryService.changeInventory(null);
    }
}

Our InventoryService is responsible for interfacing with backend systems dealing with inventory control. We don?t want to block the parent transaction while interacting with those systems, so, we make this an asynchronous EJB. When dealing with asynchronous objects, it?s a good idea to be explicit about the span context, as there are potential concurrency issues when sharing a context between a synchronous and an asynchronous bean.

The OpenTracing EJB integration is able to intercept the method call and detect if there is a span context among the parameters, which is the case of the changeInventory(SpanContext) method. In this situation, the following happens behind the scenes:

The caller makes a method call, passing the SpanContext

The interceptor is activated, creating a new child span using the SpanContext as the parent

The interceptor replaces the original SpanContext with this new child span on the method call

The intercepted method is finally invoked, wrapped by the new child span.

Note that the SpanContext passed by the OrderService is not the same as the one received by InventoryService. While this might cause some confusion, we believe this is the right semantic for this use case, as it allows for a complete tracing picture, without any explicit tracing code, apart from passing the context around.

src/main/java/io/opentracing/contrib/ejb/demoexample/InventoryService.java

package io.opentracing.contrib.ejb.demoexample;

import io.opentracing.SpanContext;
import io.opentracing.contrib.ejb.OpenTracingInterceptor;

import javax.ejb.Asynchronous;
import javax.ejb.Stateless;
import javax.inject.Inject;
import javax.interceptor.Interceptors;
import java.util.logging.Logger;

/**
 * This is an asynchronous stateless EJB with spans created automatically by the interceptor. Note that the span context
 * that this method sees is &lt;b&gt;not&lt;/b&gt; the same as the span context sent by the caller: the interceptor wraps this
 * method call on its own span, and replaces the span context by the context of this new span. This is done so that this
 * span context can be passed along to the next service &quot;as is&quot;.
 *
 * @author Juraci Paix?o Kr?hling
 */
@Asynchronous
@Stateless
@Interceptors({OpenTracingInterceptor.class})
public class InventoryService {
    private static final Logger log = Logger.getLogger(InventoryService.class.getName());

    @Inject
    InventoryNotificationService inventoryNotificationService;

    public void changeInventory(SpanContext context) {
        log.info(&quot;Changing the inventory&quot;);
        inventoryNotificationService.sendNotification(context);
    }
}

And finally, our last service, InventoryNotificationService: in this case, we notify another set of backend systems that a new order has been placed. Again, this is an asynchronous EJB and works like the one above, but additionally, we wanted to manually create a &quot;business span&quot;, called sendNotification. This method could send several notifications, wrapping each one into a span of its own. As we manually started it, we manually finish it as well.

src/main/java/io/opentracing/contrib/ejb/demoexample/InventoryNotificationService.java

package io.opentracing.contrib.ejb.demoexample;

import io.opentracing.Span;
import io.opentracing.SpanContext;
import io.opentracing.util.GlobalTracer;

import javax.ejb.Asynchronous;
import javax.ejb.Stateless;
import java.util.logging.Logger;

/**
 * This is the final call in the chain. This is an asynchronous stateless EJB, which obtains the span context
 * via a method parameter. This bean is not intercepted in any way by us, so, the span context received is exactly
 * the same as what was sent by the caller.
 *
 * @author Juraci Paix?o Kr?hling
 */
@Stateless
@Asynchronous
public class InventoryNotificationService {
    private static final Logger log = Logger.getLogger(InventoryNotificationService.class.getName());

    public void sendNotification(SpanContext context) {
        Span span = GlobalTracer.get().buildSpan(&quot;sendNotification&quot;).asChildOf(context).startManual();
        log.info(&quot;Sending an inventory change notification&quot;);
        span.finish();
    }

}

Now, let?s do a final sanity check and see if everything is in the right place: mvn wildfly-swarm:run . As before, the final message should be WildFly Swarm is Ready. Hit Ctrl+C and let?s setup our tracing backend.

The tracing backend

Instrumenting our code is one part of the story. The other part is to plug in an actual OpenTracing implementation that is capable of capturing the spans and submitting them to a backend service. For our demo, we?ll use Jaeger. If you don?t have a Jaeger server running yet, one can be started via Docker as follows:

docker run \
    --rm \
    -p5775:5775/udp \
    -p6831:6831/udp \
    -p6832:6832/udp \
    -p5778:5778 \
    -p16686:16686 \
    -p14268:14268 \
    --name jaeger \
    jaegertracing/all-in-one:latest

Tying everything together

Now that we have our code ready and a tracing backend, let?s start Wildfly Swarm passing a service name, which is the only property required by the Jaeger client. By default, Jaeger?s Java tracer will attempt to send traces via UDP to a Jaeger Agent located on the local machine. If you are using a different architecture, refer to the Jaeger?s documentation on how to use environment variables to configure the client, or refer to the Jaeger?s fraction for Wildfly Swarm.

For our demo, we?ll use a property that is recognized by the Jaeger?s Wildfly Swarm Fraction. The other two properties are telling Jaeger that every request should be sampled.

mvn wildfly-swarm:run -Dswarm.jaeger.service-name=order-processing -Dswarm.jaeger.sampler-type=const -Dswarm.jaeger.sampler-parameter=1

Watch the logs for an entry containing com.uber.jaeger.Configuration: if everything is correctly set, it should show the complete configuration of the Jaeger client, like this:

2017-07-26 12:03:09,139 INFO  [com.uber.jaeger.Configuration] (ServerService Thread Pool -- 6) Initialized tracer=Tracer(version=Java-0.20.0, serviceName=order-processing, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket at 7270de22, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), maxQueueSize=100, closeEnqueueTimeout=1000), sampler=ConstSampler(decision=true, tags={sampler.type=const, sampler.param=true}), ipv4=-1062731153, tags={hostname=carambola, jaeger.version=Java-0.20.0, ip=192.168.2.111}, zipkinSharedRpcSpan=false)

Once the message WildFly Swarm is Ready is seen, we can start making requests to our endpoint:

$ curl -X POST localhost:8080/order
Order placed

And this can be seen on the server?s log:

2017-07-26 12:03:19,302 INFO  [io.opentracing.contrib.ejb.demoexample.Endpoint] (default task-2) Request received to place an order
2017-07-26 12:03:19,304 INFO  [io.opentracing.contrib.ejb.demoexample.AccountService] (default task-2) Notifying the account owner about a new order
2017-07-26 12:03:19,307 INFO  [io.opentracing.contrib.ejb.demoexample.OrderService] (default task-2) Placing order
2017-07-26 12:03:19,314 INFO  [io.opentracing.contrib.ejb.demoexample.InventoryService] (EJB default - 1) Changing the inventory
2017-07-26 12:03:19,322 INFO  [io.opentracing.contrib.ejb.demoexample.InventoryNotificationService] (EJB default - 2) Sending an inventory change notification

At this point, the complete trace with its 6 spans can be seen on Jaeger?s UI, located at http://localhost:16686/search , if you are using the Docker command we listed before.

Conclusion

EJBs are a very important part of Java EE and we expect the OpenTracing EJB framework integration to complement the other Java EE related integrations, like the Servlet and JAX-RS. In this blog post, we?ve shown how tracing EJBs can be accomplished by transparently tracing synchronous stateless EJBs, intercepting span contexts in asynchronous EJBs and by exposing the span context via EJB contexts, as well as manually starting spans to include specific business logic into the trace.

from Hawkular Blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170728/afee88b0/attachment-0001.html 

From lponce at redhat.com  Mon Jul 31 04:24:42 2017
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 31 Jul 2017 10:24:42 +0200
Subject: [Hawkular-dev] Invitation: Hawkular UI demos: alerts and
 metrics - ven. 21 juil. 2017 16:00 - 16:30 (CEST)
 (hawkular-dev@lists.jboss.org)
In-Reply-To: <CAJo5TF=NxVmTK96wUBz50ahyGcrjvtPvCrRcVHNjzEqtiUtrOw@mail.gmail.com>
References: <001a114b3c2622fd520554bf8afa@google.com>
	<CAOJV2uDktajPDy01LvVqkQe-a=d-R-_91=YKg=Zbkb5N7f7k4Q@mail.gmail.com>
	<CAJo5TF=NxVmTK96wUBz50ahyGcrjvtPvCrRcVHNjzEqtiUtrOw@mail.gmail.com>
Message-ID: <CAGUuq3V2U3udMULE8LQ61oXzmQgsWDmN=dyyTesY_JuNAybuiQ@mail.gmail.com>

Thanks for the video.



2017-07-21 16:57 GMT+02:00 Joel Takvorian <jtakvori at redhat.com>:

> Recording link: https://bluejeans.com/s/7hiCO/
>
> By the way I started to open enhancement tickets here based on comments
> https://github.com/hawkular/hawkular-ui/issues
>
> Feel free to add more
>
> 2017-07-21 14:41 GMT+02:00 Alissa Bonas <abonas at redhat.com>:
>
>> Please record it
>>
>> On Jul 20, 2017 16:51, <jtakvori at redhat.com> wrote:
>>
>>> plus d'infos ?
>>> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>>> Hawkular UI demos: alerts and metrics
>>> https://bluejeans.com/u/jtakvori/
>>> <https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2Fu%2Fjtakvori%2F&sa=D&usd=2&usg=AFQjCNGDKiK9mvzs0DY6NR4cMic1Hqqytw>
>>> Presentations of the two (small) UIs recently developed: one for
>>> metrics, the other for alerts.
>>> *Date*
>>> ven. 21 juil. 2017 16:00 ? 16:30 Paris
>>>
>>> *Agenda*
>>> hawkular-dev at lists.jboss.org
>>>
>>> *Participants*
>>> ?
>>> jtakvori at redhat.com- organisateur
>>> ?
>>> hawkular-dev at lists.jboss.org
>>>
>>> Allez-vous participer ?   *Oui
>>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=1&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>>> - Peut-?tre
>>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=3&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>>> - Non
>>> <https://www.google.com/calendar/event?action=RESPOND&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&rst=2&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>*
>>>     plus d'options ?
>>> <https://www.google.com/calendar/event?action=VIEW&eid=cjlsazV2bTRoOWVmbXJoZjE3bmtrNThuMG8gaGF3a3VsYXItZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MTkjanRha3ZvcmlAcmVkaGF0LmNvbTUwNjQ2Yjg2ZDE4YTk2ZmZjMjg0ZmM4M2I3Y2ZlZTM2OWYwZmYxZTQ&ctz=Europe/Paris&hl=fr>
>>>
>>> Invitation de Google Agenda <https://www.google.com/calendar/>
>>>
>>> Vous recevez ce message ? l'adresse hawkular-dev at lists.jboss.org, car
>>> vous participez ? cet ?v?nement.
>>>
>>> Refusez cet ?v?nement pour ne plus recevoir de notifications le
>>> concernant. Vous avez ?galement la possibilit? de cr?er un compte Google ?
>>> l'adresse https://www.google.com/calendar/ et de d?finir vous-m?me les
>>> param?tres de notification pour l'int?gralit? de votre agenda.
>>>
>>> En transf?rant cette invitation, vous risquez d'autoriser tous les
>>> destinataires ? modifier votre r?ponse ? l'invitation. En savoir plus
>>> <https://support.google.com/calendar/answer/37135#forwarding>.
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170731/09b23a43/attachment.html 

From hrupp at redhat.com  Mon Jul 31 12:08:38 2017
From: hrupp at redhat.com (Heiko Rupp)
Date: Mon, 31 Jul 2017 18:08:38 +0200
Subject: [Hawkular-dev] Dynamic UI PoC Presentation
In-Reply-To: <CAJvPVZ5Csdj=XZ9jHncE2C8k_cSjMZVe3Zb25m0Mj92ros2Z3Q@mail.gmail.com>
References: <CAJvPVZ5Aa_yf-PyW0oBoU-qV9eam-uE_CMvn8LRSZKBo0aTsvA@mail.gmail.com>
	<CA+aN=MrFop_o+8VHcB7-=DKPc=Ynzh-F6zvz+j9OhZpACCvhag@mail.gmail.com>
	<CAJvPVZ78ppkVPtv7GLiTuxPW7H4J2bZgfFTqX-OVwO7QFzu1bA@mail.gmail.com>
	<CAOJV2uD9RBMZ7JGtJm6AT=tWsE7TXrrhbUFH7vz1JPaiaH8RCA@mail.gmail.com>
	<CAJvPVZ7VVPC-ZCX1vpiaPJsWasDAp+qPiYA+dQgnc-tHMpagSw@mail.gmail.com>
	<BF365008-F4EA-43D6-A098-B077E75830C2@redhat.com>
	<CAJvPVZ6+qVRdBzfxBqCDdVKg7+8pmkU4Pk1b2hO1UgL8eXspvQ@mail.gmail.com>
	<CAJvPVZ5Csdj=XZ9jHncE2C8k_cSjMZVe3Zb25m0Mj92ros2Z3Q@mail.gmail.com>
Message-ID: <5206C9B4-3646-4A74-8D8A-901057910DCB@redhat.com>

Hey Caina,


On 20 Jul 2017, at 22:29, Caina Costa wrote:

> This is another update to the proof of concept, and today we are doing 
> big improvements to cover other parts of the representation that we 
> did not cover yet: fetching data from Hawkular, and turning that into 
> entities/views.

It's great that you are making progress. There are still some
missing pieces for me, but perhaps just because I didn't
try the code.
Before I go on, let me put a diagram in:


In Blue are pieces that should not need any modification if
a new type of Server is added. In the picture I have three servers
Type A and Type B, which have their configuration for the
resources they represent and report and send metrics about.
They would now also get additional data (meta data) about
the layout of those resources on the MiQ UI (Def A and B).
So if I modify Def A, the way the UI is layouted in Layout A
should change.

There are now some extra definitions, that I want to briefly
explain:
In the current setup of the agent and inventory, each server of
a given type (Type B) sends its own Inventory report and would
also send its own version of the Definition, hence Def B and Def B'.

What we could do it to now use Def* from the agent, but create
(Hawkular-)server side definitions SDef* for that purpose that
would then direct the layouting as Def A and so would do.
But that is a bit of a 2ndary concern at the moment.

I think what would be good if you could implement your current
status end-to-end with a new type of server (something Fusy)
including the definition file on Hawkular side and an actual rendered
UI so that we can continue from there.

Thanks
    Heiko


-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_ui.png
Type: image/png
Size: 81759 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170731/988d69a0/attachment-0001.png