From hrupp at redhat.com  Sun Mar  1 09:26:46 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Sun, 1 Mar 2015 15:26:46 +0100
Subject: [Hawkular-dev] Fwd: [wildfly-dev] Heads up on JBoss Logger 3.2 :
	more changed than what it looks like
References: <CAFm4XO2wnBqZywOkgDjhM=p-UDn6nintBpGS73PU+yPO_fSfgA@mail.gmail.com>
Message-ID: <2EC1A815-43F2-4BE0-A7A1-E17075F5BA67@redhat.com>

FYI from wildfly-dev, as we seem to "still" be using 3.1.x stream of jboss.logging.

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Sanne Grinovero <sanne at hibernate.org>
> Datum: 27. Februar 2015 21:08:00 MEZ
> An: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> Betreff: [wildfly-dev] Heads up on JBoss Logger 3.2 : more changed than what it looks like
> 
> Hi all,
> today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
> in an Hibernate project, and got some integration test failures.
> 
> The surprising aspect is that everything seemed fine at compile level:
> just switch the version in the pom, and without needing any further
> changes it compiles fine and runs all unit tests successfully.. but
> fails when using the freshly built libraries in WildFly 8.2.
> 
> It's not a regression of jboss-logging, but one of its improvements
> require a bit of attention.
> 
> This is what happened to us:
> we have some log statements which look like this in source code (after
> simplifying):
> 
>    int i = ...
>    log.debugf( "Number: %d", i );
> 
> This does of course compile fine in both old an new versions of JBoss
> Logger. And it all works as expected in unit tests.
> But when deploying the modified version of this Hibernate library in
> WildFly 8.2, you'd get some of these:
> - java.lang.NoSuchMethodError:
> org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
> 
> When using the older version of JBoss Logger (at compile time), the
> above line of code is compiled as an invocation to:
> 
>    void debugf(String format, Object param1);
> 
> (which is a method present in both versions)
> 
> When using the new version of JBoss Logger (at compile time), the same
> line of code is interpreted as the (better) invocation to:
> 
>    void debugf(String format, int arg);
> 
> So that's what the library is going to invoke at runtime - and that
> method doesn't exist in WildFly 8.2.
> 
> Be aware of this when upgrading as it might look like a trivial
> version bump but it makes it quite hard to guarantee backwards
> compatibility with older versions of the logger.
> 
> Personally since I want to upgrade the logger but don't want to drop
> compatibility with existing WildFly releases, I'm trying to figure how
> to reliably validate that no logging statement is going to invoke one
> of the new ones.. for now.
> 
> I guess this also means that users won't actually benefit from the
> better performance of the new logging methods until we recompile all
> of its client libraries using the new version ;-)
> Auto-boxing is evil..
> 
> Sanne
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From gbrown at redhat.com  Mon Mar  2 04:26:16 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 2 Mar 2015 04:26:16 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
Message-ID: <2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>

Hi Lucas

Thanks again for the info - a couple more points related to potential use for 'situations' in RTGov:

1) RTGov maintains a list of 'situations' that have occurred, which can be used to access other information about the business transaction, historic analysis, etc. Wondering whether maintaining a historic view of notifications that have occurred is something you have thought about?

Possibly this could be another plugin - may be not explicitly defined as an action, but implicitly just records any notifications sent.

2) From the description in the doc, it gives an example of an email notifier with an email address - so in this context the email address is statically defined. Is it also possible for the component raising the 'action'/'notification' to provide the email address?

3) Would you expect any component generating notifications to use a 'client api' or is direct publishing of the NotificationMessage a valid use case?


Regards
Gary

----- Original Message -----
> Hi Gary,
> 
> answers in line:
> 
> ----- Original Message -----
> > From: "Gary Brown" <gbrown at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Friday, February 27, 2015 4:58:49 PM
> > Subject: [Hawkular-dev] Notification messages
> > 
> > Hi
> > 
> > Started looking at Hawkular alerts with an eye on RTGov eventually using
> > the
> > notification mechanism to represent what we currently store/display as
> > 'situations'. Had a couple of questions:
> > 
> > 1) The notification message currently has a notifierId - so does this mean
> > an
> > alert trigger will only have a single notifer? Or could a single alert
> > (notification message) potentially be sent to multiple notifiers (e.g.
> > twitter, email, etc.) - and if so require a notifierId list?
> > 
> 
> No, a trigger definition can be linked with a list of "notifiers" (this term
> will be called "action" in our next api review).
> 
> Also this actions can be shared, i.e. an action can be "email to admins and
> CTO" and this action has an ID that can be re-used in several triggers
> definitions.
> 
> 
> > 2) Only other field is currently a description, which is fine for targets
> > such as email, twitter etc, but in RTGov 'situations' are also used to hold
> > other information that can be used to understand the source of the problem,
> > and tie it back to the originating business transaction. Will it be
> > possible
> > to add such fields to the notification message, even though they may not be
> > relevant for the email/sms/twitter type notifiers?
> > 
> 
> Yes, sure, the UI of the MVP was very simple due time constrainst we couldn't
> add a rich functionality on that component.
> 
> The idea is the following:
> 
> - We will have plugable ActionsPlugins that are responsible of the perform
> (i.e. an action plugin for emailing, other for mobile, other smp, etc).
> - So this ActionPlugin is registered at deployment type, and it specifies
> which info can a plugin get, so in the UI you will see that depending of the
> plugin selected you will be able to select some properties or others.
> 
> - Also, not business requeriments, but technical requeriment, we want the
> alerts engine and the action plugins work decoupled, so, i.e. the alerts
> engine can be reused for a paas cloud provider to use the engine but add
> their own notifications mechanism.
> 
> Some notes of this architecture can be reviewed here:
> 
> https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
> 
> 
> Cheers,
> Lucas
> 
> > Regards
> > Gary
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> 

From hrupp at redhat.com  Mon Mar  2 05:27:31 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 2 Mar 2015 11:27:31 +0100
Subject: [Hawkular-dev] @Null / @NotNull
Message-ID: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>

Hey,

as we were having a discussion this morning on #hawkular-dev about null

I think we should start (on top of writing more JavaDoc) using
annotations to mark methods and method parameters that
allow being null / not null and if they may return null or not.

This is especially important on API classes(*1), that may be 
consumed by 3rd parties that may or may not have insight
into source of the implementation (on top of that, such annotations
are an enhancement of the API contract).

I know we have been talking about that in the past without
no real result. Luckily since then JSR 308 has been
marked as final and thus a standard exists, that includes such
annotations (+ a checking framework, + tooling to retroactively add
such annotations to existing source).

See http://types.cs.washington.edu/checker-framework/
and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts

http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10 <- annotations
http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc

Another option are the org.jetbrains versions of the annotations, which are around for a while.

If we only care about documentation, but not compile time and/or static analysis, we can also
use the ones from BeanValidation, which live under the javax package spaces (iirc). *2

Here is a more complete list of frameworks
http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use




*1) Java and REST
*2) BV may be a good idea for more complex input like in alert definition





From lponce at redhat.com  Mon Mar  2 05:30:57 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 2 Mar 2015 05:30:57 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
Message-ID: <1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>

Hi Gary,

Thx for your questions, some answers in-line:

> 
> Hi Lucas
> 
> Thanks again for the info - a couple more points related to potential use for
> 'situations' in RTGov:
> 
> 1) RTGov maintains a list of 'situations' that have occurred, which can be
> used to access other information about the business transaction, historic
> analysis, etc. Wondering whether maintaining a historic view of
> notifications that have occurred is something you have thought about?
> 

Yes, the concept of record will be handled via the "Alert" entity, as a result of an alert a set of notifications messages will be sent.

Additionally the plugin itself can also store/save their notifications (i.e. audit purposes), but I guess that specific task should be part of the ActionPlugin logic.

> Possibly this could be another plugin - may be not explicitly defined as an
> action, but implicitly just records any notifications sent.
> 

Right, the idea is to have a plugable architecture that allow to add these kind of features without impacting into the main alerts engine.

> 2) From the description in the doc, it gives an example of an email notifier
> with an email address - so in this context the email address is statically
> defined. Is it also possible for the component raising the
> 'action'/'notification' to provide the email address?
> 

Yes, it is.

The idea is that the ActionPlugin at registration time, should provide which properties need for an action.
These properties can be to set up a list of destionation emails, or even to have a default one, or other combination.
Plugin will be responsible to implement the notification itself.

The engine, will trigger the alert, and when an alert happen, it will signal their actions attached.

These actions are de-couple and the engine doesn't have any detail of what is behind, the bus component will get the info of the notifiers/actions id and it will send the notification/action messages through the bus, where the plugins are listening and they will perform the actions once they receive the messages.

> 3) Would you expect any component generating notifications to use a 'client
> api' or is direct publishing of the NotificationMessage a valid use case?
> 
> 

Not sure if I get the "client api" use case, if you can add an example I can check if the current architecture supports that use case.

At the moment, the idea is that the plugin should listen from the bus, but you can create an alternative notifications implementation without having that dependency from the bus (i.e. some thirdparty likes metrics and alerts components and they want to hard integrate them into other code, so they won't use the bus but the API defined for the notifications can be overrided it with additional/alternative implementations).

Lucas


> 
> ----- Original Message -----
> > Hi Gary,
> > 
> > answers in line:
> > 
> > ----- Original Message -----
> > > From: "Gary Brown" <gbrown at redhat.com>
> > > To: hawkular-dev at lists.jboss.org
> > > Sent: Friday, February 27, 2015 4:58:49 PM
> > > Subject: [Hawkular-dev] Notification messages
> > > 
> > > Hi
> > > 
> > > Started looking at Hawkular alerts with an eye on RTGov eventually using
> > > the
> > > notification mechanism to represent what we currently store/display as
> > > 'situations'. Had a couple of questions:
> > > 
> > > 1) The notification message currently has a notifierId - so does this
> > > mean
> > > an
> > > alert trigger will only have a single notifer? Or could a single alert
> > > (notification message) potentially be sent to multiple notifiers (e.g.
> > > twitter, email, etc.) - and if so require a notifierId list?
> > > 
> > 
> > No, a trigger definition can be linked with a list of "notifiers" (this
> > term
> > will be called "action" in our next api review).
> > 
> > Also this actions can be shared, i.e. an action can be "email to admins and
> > CTO" and this action has an ID that can be re-used in several triggers
> > definitions.
> > 
> > 
> > > 2) Only other field is currently a description, which is fine for targets
> > > such as email, twitter etc, but in RTGov 'situations' are also used to
> > > hold
> > > other information that can be used to understand the source of the
> > > problem,
> > > and tie it back to the originating business transaction. Will it be
> > > possible
> > > to add such fields to the notification message, even though they may not
> > > be
> > > relevant for the email/sms/twitter type notifiers?
> > > 
> > 
> > Yes, sure, the UI of the MVP was very simple due time constrainst we
> > couldn't
> > add a rich functionality on that component.
> > 
> > The idea is the following:
> > 
> > - We will have plugable ActionsPlugins that are responsible of the perform
> > (i.e. an action plugin for emailing, other for mobile, other smp, etc).
> > - So this ActionPlugin is registered at deployment type, and it specifies
> > which info can a plugin get, so in the UI you will see that depending of
> > the
> > plugin selected you will be able to select some properties or others.
> > 
> > - Also, not business requeriments, but technical requeriment, we want the
> > alerts engine and the action plugins work decoupled, so, i.e. the alerts
> > engine can be reused for a paas cloud provider to use the engine but add
> > their own notifications mechanism.
> > 
> > Some notes of this architecture can be reviewed here:
> > 
> > https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
> > 
> > 
> > Cheers,
> > Lucas
> > 
> > > Regards
> > > Gary
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > 
> 

From gbrown at redhat.com  Mon Mar  2 05:38:57 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 2 Mar 2015 05:38:57 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
Message-ID: <816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>

Hi

----- Original Message -----
> > 3) Would you expect any component generating notifications to use a 'client
> > api' or is direct publishing of the NotificationMessage a valid use case?
> > 
> > 
> 
> Not sure if I get the "client api" use case, if you can add an example I can
> check if the current architecture supports that use case.
> 
> At the moment, the idea is that the plugin should listen from the bus, but
> you can create an alternative notifications implementation without having
> that dependency from the bus (i.e. some thirdparty likes metrics and alerts
> components and they want to hard integrate them into other code, so they
> won't use the bus but the API defined for the notifications can be overrided
> it with additional/alternative implementations).
> 

The question was more about how the alerts/notification messages are raised - so instead of the alert engine, it may be rtgov policies identifying a 'situation' an needing to create an 'alert'. In this case, would rtgov use some form of client API to report the alert, or simply create the alert and publish it on the bus?

Regards
Gary

From lponce at redhat.com  Mon Mar  2 05:54:00 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 2 Mar 2015 05:54:00 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
	<816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>
Message-ID: <1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>


> 
> ----- Original Message -----
> > > 3) Would you expect any component generating notifications to use a
> > > 'client
> > > api' or is direct publishing of the NotificationMessage a valid use case?
> > > 
> > > 
> > 
> > Not sure if I get the "client api" use case, if you can add an example I
> > can
> > check if the current architecture supports that use case.
> > 
> > At the moment, the idea is that the plugin should listen from the bus, but
> > you can create an alternative notifications implementation without having
> > that dependency from the bus (i.e. some thirdparty likes metrics and alerts
> > components and they want to hard integrate them into other code, so they
> > won't use the bus but the API defined for the notifications can be
> > overrided
> > it with additional/alternative implementations).
> > 
> 
> The question was more about how the alerts/notification messages are raised -
> so instead of the alert engine, it may be rtgov policies identifying a
> 'situation' an needing to create an 'alert'. In this case, would rtgov use
> some form of client API to report the alert, or simply create the alert and
> publish it on the bus?
> 

In our present design the hawkular-alerts-engine should be responsible to generate the Alerts from Events/Data.

The alerts engine is also responsible to manage the persistence layer of alerts and rules definitions.

If I am understanding your scenario, it is like if we can "decouple" the alerts engine, because we have a third party element that can raise alerts (i.e. RTGov policies) and it can be interesting to create an Alert that can have attached a list of actions/notifications.

It sounds not clear for me (at a first thought) I guess you can accomplish same feature just letting RTGov to generate a simple data and attaching a definition from the alerts engine, that sounds more natural.

But anyway it is interesting to understand this use case to see what is the best way to implement it.

Thx,
Lucas

> Regards
> Gary
> 

From gbrown at redhat.com  Mon Mar  2 06:06:55 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 2 Mar 2015 06:06:55 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
	<816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>
	<1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>
Message-ID: <1918450370.20274167.1425294415435.JavaMail.zimbra@redhat.com>

Hi

Maybe your suggestion is the way to go - RTGov still generates 'situations' which are made available to the alerts engine to determine if a notification should be raised. So looks like there are two possibilities:

(a) RTGov somehow creates alerts directly, so alerts engine, RTGov, other components, etc could independently raise alerts that are then used to create notifications.

or

(b) RTGov and other components create their own event to represent a 'situation of interest', and the alerts engine interprets these to determine if an alert should be create resulting in notifications.


I'm open to either approach, although (b) has the benefit of allowing the source component (e.g. RTGov) to simple raises the 'situations' while not worrying about issues such as dampening, which can be defined with the alerts engine.

Regards
Gary

----- Original Message -----
> 
> > 
> > ----- Original Message -----
> > > > 3) Would you expect any component generating notifications to use a
> > > > 'client
> > > > api' or is direct publishing of the NotificationMessage a valid use
> > > > case?
> > > > 
> > > > 
> > > 
> > > Not sure if I get the "client api" use case, if you can add an example I
> > > can
> > > check if the current architecture supports that use case.
> > > 
> > > At the moment, the idea is that the plugin should listen from the bus,
> > > but
> > > you can create an alternative notifications implementation without having
> > > that dependency from the bus (i.e. some thirdparty likes metrics and
> > > alerts
> > > components and they want to hard integrate them into other code, so they
> > > won't use the bus but the API defined for the notifications can be
> > > overrided
> > > it with additional/alternative implementations).
> > > 
> > 
> > The question was more about how the alerts/notification messages are raised
> > -
> > so instead of the alert engine, it may be rtgov policies identifying a
> > 'situation' an needing to create an 'alert'. In this case, would rtgov use
> > some form of client API to report the alert, or simply create the alert and
> > publish it on the bus?
> > 
> 
> In our present design the hawkular-alerts-engine should be responsible to
> generate the Alerts from Events/Data.
> 
> The alerts engine is also responsible to manage the persistence layer of
> alerts and rules definitions.
> 
> If I am understanding your scenario, it is like if we can "decouple" the
> alerts engine, because we have a third party element that can raise alerts
> (i.e. RTGov policies) and it can be interesting to create an Alert that can
> have attached a list of actions/notifications.
> 
> It sounds not clear for me (at a first thought) I guess you can accomplish
> same feature just letting RTGov to generate a simple data and attaching a
> definition from the alerts engine, that sounds more natural.
> 
> But anyway it is interesting to understand this use case to see what is the
> best way to implement it.
> 
> Thx,
> Lucas
> 
> > Regards
> > Gary
> > 
> 

From lponce at redhat.com  Mon Mar  2 06:13:14 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 2 Mar 2015 06:13:14 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1918450370.20274167.1425294415435.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
	<816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>
	<1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>
	<1918450370.20274167.1425294415435.JavaMail.zimbra@redhat.com>
Message-ID: <1166809026.20855651.1425294794485.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Lucas Ponce" <lponce at redhat.com>
> Cc: hawkular-dev at lists.jboss.org
> Sent: Monday, March 2, 2015 12:06:55 PM
> Subject: Re: [Hawkular-dev] Notification messages
> 
> Hi
> 
> Maybe your suggestion is the way to go - RTGov still generates 'situations'
> which are made available to the alerts engine to determine if a notification
> should be raised. So looks like there are two possibilities:
> 
> (a) RTGov somehow creates alerts directly, so alerts engine, RTGov, other
> components, etc could independently raise alerts that are then used to
> create notifications.
> 
> or
> 
> (b) RTGov and other components create their own event to represent a
> 'situation of interest', and the alerts engine interprets these to determine
> if an alert should be create resulting in notifications.
> 
> 
> I'm open to either approach, although (b) has the benefit of allowing the
> source component (e.g. RTGov) to simple raises the 'situations' while not
> worrying about issues such as dampening, which can be defined with the
> alerts engine.
>

Exactly, 'situations' are data that can be used to create a trigger definition, that can be attached with a notification list.

This data can be really simple, for example, it can be just a String with a value, and a condition can be just to detect if you have a new situation into the alerts engine.
 
> Regards
> Gary
> 
> ----- Original Message -----
> > 
> > > 
> > > ----- Original Message -----
> > > > > 3) Would you expect any component generating notifications to use a
> > > > > 'client
> > > > > api' or is direct publishing of the NotificationMessage a valid use
> > > > > case?
> > > > > 
> > > > > 
> > > > 
> > > > Not sure if I get the "client api" use case, if you can add an example
> > > > I
> > > > can
> > > > check if the current architecture supports that use case.
> > > > 
> > > > At the moment, the idea is that the plugin should listen from the bus,
> > > > but
> > > > you can create an alternative notifications implementation without
> > > > having
> > > > that dependency from the bus (i.e. some thirdparty likes metrics and
> > > > alerts
> > > > components and they want to hard integrate them into other code, so
> > > > they
> > > > won't use the bus but the API defined for the notifications can be
> > > > overrided
> > > > it with additional/alternative implementations).
> > > > 
> > > 
> > > The question was more about how the alerts/notification messages are
> > > raised
> > > -
> > > so instead of the alert engine, it may be rtgov policies identifying a
> > > 'situation' an needing to create an 'alert'. In this case, would rtgov
> > > use
> > > some form of client API to report the alert, or simply create the alert
> > > and
> > > publish it on the bus?
> > > 
> > 
> > In our present design the hawkular-alerts-engine should be responsible to
> > generate the Alerts from Events/Data.
> > 
> > The alerts engine is also responsible to manage the persistence layer of
> > alerts and rules definitions.
> > 
> > If I am understanding your scenario, it is like if we can "decouple" the
> > alerts engine, because we have a third party element that can raise alerts
> > (i.e. RTGov policies) and it can be interesting to create an Alert that can
> > have attached a list of actions/notifications.
> > 
> > It sounds not clear for me (at a first thought) I guess you can accomplish
> > same feature just letting RTGov to generate a simple data and attaching a
> > definition from the alerts engine, that sounds more natural.
> > 
> > But anyway it is interesting to understand this use case to see what is the
> > best way to implement it.
> > 
> > Thx,
> > Lucas
> > 
> > > Regards
> > > Gary
> > > 
> > 
> 

From jsanda at redhat.com  Mon Mar  2 07:54:28 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 2 Mar 2015 07:54:28 -0500
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
Message-ID: <28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>

How about using the Optional class introduced in Java instead of null? Not only does it provide documentation like the annotations do, but Optional also provides a rich API that the annotations do not. If you are not familiar with Optional, this article[1] is a good overview.

[1] http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html <http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html>
> On Mar 2, 2015, at 5:27 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Hey,
> 
> as we were having a discussion this morning on #hawkular-dev about null
> 
> I think we should start (on top of writing more JavaDoc) using
> annotations to mark methods and method parameters that
> allow being null / not null and if they may return null or not.
> 
> This is especially important on API classes(*1), that may be 
> consumed by 3rd parties that may or may not have insight
> into source of the implementation (on top of that, such annotations
> are an enhancement of the API contract).
> 
> I know we have been talking about that in the past without
> no real result. Luckily since then JSR 308 has been
> marked as final and thus a standard exists, that includes such
> annotations (+ a checking framework, + tooling to retroactively add
> such annotations to existing source).
> 
> See http://types.cs.washington.edu/checker-framework/
> and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts
> 
> http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10 <- annotations
> http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc
> 
> Another option are the org.jetbrains versions of the annotations, which are around for a while.
> 
> If we only care about documentation, but not compile time and/or static analysis, we can also
> use the ones from BeanValidation, which live under the javax package spaces (iirc). *2
> 
> Here is a more complete list of frameworks
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
> 
> 
> 
> 
> *1) Java and REST
> *2) BV may be a good idea for more complex input like in alert definition
> 
> 
> 
> 
> _______________________________________________
> 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/20150302/0d23fcbf/attachment.html 

From miburman at redhat.com  Mon Mar  2 08:42:01 2015
From: miburman at redhat.com (Michael Burman)
Date: Mon, 2 Mar 2015 08:42:01 -0500 (EST)
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>
Message-ID: <1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>

Hi,

This is actually very good read about Optional benefits (with lambdas especially): http://vanillajava.blogspot.fi/2015/01/java-8-optional-is-not-just-for.html

Then again, I hope we don't start to use Optional when something really isn't optional. That kills readability.

  -  Micke

----- Original Message -----
From: "John Sanda" <jsanda at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Monday, 2 March, 2015 2:54:28 PM
Subject: Re: [Hawkular-dev] @Null / @NotNull

How about using the Optional class introduced in Java instead of null? Not only does it provide documentation like the annotations do, but Optional also provides a rich API that the annotations do not. If you are not familiar with Optional, this article[1] is a good overview. 

[1] http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html 




On Mar 2, 2015, at 5:27 AM, Heiko W.Rupp < hrupp at redhat.com > wrote: 

Hey, 

as we were having a discussion this morning on #hawkular-dev about null 

I think we should start (on top of writing more JavaDoc) using 
annotations to mark methods and method parameters that 
allow being null / not null and if they may return null or not. 

This is especially important on API classes(*1), that may be 
consumed by 3rd parties that may or may not have insight 
into source of the implementation (on top of that, such annotations 
are an enhancement of the API contract). 

I know we have been talking about that in the past without 
no real result. Luckily since then JSR 308 has been 
marked as final and thus a standard exists, that includes such 
annotations (+ a checking framework, + tooling to retroactively add 
such annotations to existing source). 

See http://types.cs.washington.edu/checker-framework/ 
and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts 

http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10 <- annotations 
http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc 

Another option are the org.jetbrains versions of the annotations, which are around for a while. 

If we only care about documentation, but not compile time and/or static analysis, we can also 
use the ones from BeanValidation, which live under the javax package spaces (iirc). *2 

Here is a more complete list of frameworks 
http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use 




*1) Java and REST 
*2) BV may be a good idea for more complex input like in alert definition 




_______________________________________________ 
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

From miburman at redhat.com  Mon Mar  2 08:45:33 2015
From: miburman at redhat.com (Michael Burman)
Date: Mon, 2 Mar 2015 08:45:33 -0500 (EST)
Subject: [Hawkular-dev] maven -P or -D for things like docgen
In-Reply-To: <1489677318.30529842.1425303799184.JavaMail.zimbra@redhat.com>
Message-ID: <488927396.30532998.1425303933428.JavaMail.zimbra@redhat.com>

Hi,

>From #hawkular and PR 158. Originally I replaced a -Ddocgen with -Pdocgen as I thought it was originally a mistake. To me generating documentation was just another goal of the project, different target environment. However, originally one used to set up with -D a parameter that would then also generate the documentation.

I guess the same process should be shared among all our different targets & projects, so which one is preferred?

   - Micke

From tsegismo at redhat.com  Mon Mar  2 08:48:11 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 02 Mar 2015 14:48:11 +0100
Subject: [Hawkular-dev] maven -P or -D for things like docgen
In-Reply-To: <488927396.30532998.1425303933428.JavaMail.zimbra@redhat.com>
References: <488927396.30532998.1425303933428.JavaMail.zimbra@redhat.com>
Message-ID: <54F46A1B.9040402@redhat.com>

+1 for direct activation with -P

Le 02/03/2015 14:45, Michael Burman a ?crit :
> Hi,
>
>>From #hawkular and PR 158. Originally I replaced a -Ddocgen with -Pdocgen as I thought it was originally a mistake. To me generating documentation was just another goal of the project, different target environment. However, originally one used to set up with -D a parameter that would then also generate the documentation.
>
> I guess the same process should be shared among all our different targets & projects, so which one is preferred?
>
>     - Micke
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lponce at redhat.com  Mon Mar  2 08:51:09 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 2 Mar 2015 08:51:09 -0500 (EST)
Subject: [Hawkular-dev] maven -P or -D for things like docgen
In-Reply-To: <54F46A1B.9040402@redhat.com>
References: <488927396.30532998.1425303933428.JavaMail.zimbra@redhat.com>
	<54F46A1B.9040402@redhat.com>
Message-ID: <1342996042.20930381.1425304269373.JavaMail.zimbra@redhat.com>

Hawkular alerts has a "docgen" profile activated with -P, so I think "-P" is most standard way.

+1 in -P in order to maintain the same mechanism.


----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, March 2, 2015 2:48:11 PM
> Subject: Re: [Hawkular-dev] maven -P or -D for things like docgen
> 
> +1 for direct activation with -P
> 
> Le 02/03/2015 14:45, Michael Burman a ?crit :
> > Hi,
> >
> >>From #hawkular and PR 158. Originally I replaced a -Ddocgen with -Pdocgen
> >>as I thought it was originally a mistake. To me generating documentation
> >>was just another goal of the project, different target environment.
> >>However, originally one used to set up with -D a parameter that would then
> >>also generate the documentation.
> >
> > I guess the same process should be shared among all our different targets &
> > projects, so which one is preferred?
> >
> >     - Micke
> > _______________________________________________
> > 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
> 


From tsegismo at redhat.com  Mon Mar  2 08:59:03 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 02 Mar 2015 14:59:03 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>
	<1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>
Message-ID: <54F46CA7.7090502@redhat.com>

To clarify, the conversation started talking about validation of a 
required constructor parameter. So Optional does not apply here.

Also, on how to use Optional in general, this is interesting:
http://blog.joda.org/2014/11/optional-in-java-se-8.html
|
-> "My only fear is that Optional will be overused. Please focus on 
using it as a return type (from methods that perform some useful piece 
of functionality)."

As for using annotations for null/notnull, the IDE I use infers it most 
of the time, so I personally don't feel the need of using it.

Le 02/03/2015 14:42, Michael Burman a ?crit :
> Hi,
>
> This is actually very good read about Optional benefits (with lambdas especially): http://vanillajava.blogspot.fi/2015/01/java-8-optional-is-not-just-for.html
>
> Then again, I hope we don't start to use Optional when something really isn't optional. That kills readability.
>
>    -  Micke
>
> ----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, 2 March, 2015 2:54:28 PM
> Subject: Re: [Hawkular-dev] @Null / @NotNull
>
> How about using the Optional class introduced in Java instead of null? Not only does it provide documentation like the annotations do, but Optional also provides a rich API that the annotations do not. If you are not familiar with Optional, this article[1] is a good overview.
>
> [1] http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html
>
>
>
>
> On Mar 2, 2015, at 5:27 AM, Heiko W.Rupp < hrupp at redhat.com > wrote:
>
> Hey,
>
> as we were having a discussion this morning on #hawkular-dev about null
>
> I think we should start (on top of writing more JavaDoc) using
> annotations to mark methods and method parameters that
> allow being null / not null and if they may return null or not.
>
> This is especially important on API classes(*1), that may be
> consumed by 3rd parties that may or may not have insight
> into source of the implementation (on top of that, such annotations
> are an enhancement of the API contract).
>
> I know we have been talking about that in the past without
> no real result. Luckily since then JSR 308 has been
> marked as final and thus a standard exists, that includes such
> annotations (+ a checking framework, + tooling to retroactively add
> such annotations to existing source).
>
> See http://types.cs.washington.edu/checker-framework/
> and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts
>
> http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10 <- annotations
> http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc
>
> Another option are the org.jetbrains versions of the annotations, which are around for a while.
>
> If we only care about documentation, but not compile time and/or static analysis, we can also
> use the ones from BeanValidation, which live under the javax package spaces (iirc). *2
>
> Here is a more complete list of frameworks
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
>
>
>
>
> *1) Java and REST
> *2) BV may be a good idea for more complex input like in alert definition
>
>
>
>
> _______________________________________________
> 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
>


From hrupp at redhat.com  Mon Mar  2 09:56:07 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 2 Mar 2015 15:56:07 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <54F46CA7.7090502@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>
	<1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>
	<54F46CA7.7090502@redhat.com>
Message-ID: <E1A9EA29-4413-4583-8C90-6B4EA3F47008@redhat.com>


> Am 02.03.2015 um 14:59 schrieb Thomas Segismont <tsegismo at redhat.com>:
> As for using annotations for null/notnull, the IDE I use infers it most 
> of the time, so I personally don't feel the need of using it.

I think not every IDE can do it, so adding the annotations are a benefit
for all users.
The annotations from FindBugs and JSR-308 can allow for static code analysis,
which may be helpful in error prevention as well.


From tsegismo at redhat.com  Mon Mar  2 10:41:10 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 02 Mar 2015 16:41:10 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <E1A9EA29-4413-4583-8C90-6B4EA3F47008@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>	<1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>	<54F46CA7.7090502@redhat.com>
	<E1A9EA29-4413-4583-8C90-6B4EA3F47008@redhat.com>
Message-ID: <54F48496.60403@redhat.com>

Le 02/03/2015 15:56, Heiko W.Rupp a ?crit :
> The annotations from FindBugs and JSR-308 can allow for static code analysis,
> which may be helpful in error prevention as well.

Good point

From jshaughn at redhat.com  Mon Mar  2 15:40:29 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 02 Mar 2015 15:40:29 -0500
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1166809026.20855651.1425294794485.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>	<1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>	<816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>	<1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>	<1918450370.20274167.1425294415435.JavaMail.zimbra@redhat.com>
	<1166809026.20855651.1425294794485.JavaMail.zimbra@redhat.com>
Message-ID: <54F4CABD.5010502@redhat.com>



On 3/2/2015 6:13 AM, Lucas Ponce wrote:
>
> ----- Original Message -----
>> From: "Gary Brown" <gbrown at redhat.com>
>> To: "Lucas Ponce" <lponce at redhat.com>
>> Cc: hawkular-dev at lists.jboss.org
>> Sent: Monday, March 2, 2015 12:06:55 PM
>> Subject: Re: [Hawkular-dev] Notification messages
>>
>> Hi
>>
>> Maybe your suggestion is the way to go - RTGov still generates 'situations'
>> which are made available to the alerts engine to determine if a notification
>> should be raised. So looks like there are two possibilities:
>>
>> (a) RTGov somehow creates alerts directly, so alerts engine, RTGov, other
>> components, etc could independently raise alerts that are then used to
>> create notifications.
>>
>> or
>>
>> (b) RTGov and other components create their own event to represent a
>> 'situation of interest', and the alerts engine interprets these to determine
>> if an alert should be create resulting in notifications.
>>
>>
>> I'm open to either approach, although (b) has the benefit of allowing the
>> source component (e.g. RTGov) to simple raises the 'situations' while not
>> worrying about issues such as dampening, which can be defined with the
>> alerts engine.
>>
> Exactly, 'situations' are data that can be used to create a trigger definition, that can be attached with a notification list.
>
> This data can be really simple, for example, it can be just a String with a value, and a condition can be just to detect if you have a new situation into the alerts engine.
>   

We definitely want to be able to incorporate external alerts into the 
engine.  I think perhaps we will want to support both approaches above, 
but if it  were just one then I think (b) would be the preference, 
because as you said, it opens up dampening, safety logic and anything 
else that comes into play at the condition-matching phase.

I'm not sure there is anything today preventing RTGov or anyone from 
using a registered Action, or registering their own Action, and then 
using the bus infrastructure to send it a message.  As long as the 
message had the correct payload it should just work.

But it should also be fairly easy to hook into the Alerting as a whole.  
I think you could create a Trigger looking for a StringCondition 
operator, send in a Situation in some String format, and have it fire an 
alert for each.  We could maybe do a little better by creating a more 
robust Data element for external systems to hook into.  Something that 
perhaps could extend StringData and also provide a secondary String 
(maybe json), as data that just gets passed along to the notifiers/actions.

Moreover, we have yet to talk about incorporating Alerts themselves into 
Triggers, such that we start to allow for higher-level Alerting that 
correlates Alerts.  This may lead to a true AlertCondition.  It may be a 
built-in Action that generates an AlertCondition for the alert generated 
by the trigger. Or something like that.



Actions are tied to the triggers and when the trigger fires an Alert we 
explicitly send a message to the relevant actions' topics on the bus.


How to handle external alert generation is a great topic.
This is a good topic.  I think it could be useful to have external 
Alert-generators just feed fully-fledged Alerts into the system


From jshaughn at redhat.com  Mon Mar  2 17:06:03 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 02 Mar 2015 17:06:03 -0500
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <54F48496.60403@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>	<1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>	<54F46CA7.7090502@redhat.com>	<E1A9EA29-4413-4583-8C90-6B4EA3F47008@redhat.com>
	<54F48496.60403@redhat.com>
Message-ID: <54F4DECB.8080309@redhat.com>


Regardless of which parameter annotations we use it's been a pain point 
with Eclipse formatting.  I played around a little in one of our Alerts 
Rest handlers and I think the best I've seen is to enable these options 
in the formatter, under the New Lines tab:

x Insert New Line after annotations on parameters
x Insert New Line after type annotations

The unfortunate thing is that at least with my version of Eclipse, it 
works well only if you manually put the first parameter on a new line.  
With the changes you'll get this from Eclipse:

     @GET
     @Path("/trigger/{triggerId}")
     @Produces(APPLICATION_JSON)
     @ApiOperation(value = "Find all threshold conditions",
             responseClass = 
"Collection<org.hawkular.alerts.api.model.condition.StringCondition>",
             notes = "Pagination is not yet implemented")
     public void findAllThresholdConditionsByTrigger(
             @Suspended
             final AsyncResponse response,
             @ApiParam(value = "Trigger id to get threshold conditions", 
required = true)
             @PathParam("triggerId")
             final String triggerId) {
         try {
             Collection<Condition> conditionsList = 
definitions.getTriggerConditions(triggerId, null);
             Collection<ThresholdCondition> thresholdConditions = new 
ArrayList<ThresholdCondition>();
             for (Condition cond : conditionsList) {
                 if (cond instanceof ThresholdCondition) {
thresholdConditions.add((ThresholdCondition) cond);
                 }
             }
             if (thresholdConditions.isEmpty()) {
                 log.debugf("GET - findAllThresholdConditions - Empty");
response.resume(Response.status(Response.Status.NO_CONTENT).type(APPLICATION_JSON_TYPE).build());
             } else {
                 log.debugf("GET - findAllThresholdConditions - %s 
compare conditions. ", thresholdConditions.size());
response.resume(Response.status(Response.Status.OK)
.entity(thresholdConditions).type(APPLICATION_JSON_TYPE).build());
             }
         } catch (Exception e) {
             log.debugf(e.getMessage(), e);
             Map<String, String> errors = new HashMap<String, String>();
             errors.put("errorMsg", "Internal Error: " + e.getMessage());
response.resume(Response.status(Response.Status.INTERNAL_SERVER_ERROR)
.entity(errors).type(APPLICATION_JSON_TYPE).build());
         }
     }

Basically the convention being that if you have annotations in the 
params, each  goes on it's own line.  I actually don't care what options 
we use but this is one formatting area where I still keep seeing 
disparity between the IDEs.



On 3/2/2015 10:41 AM, Thomas Segismont wrote:
> Le 02/03/2015 15:56, Heiko W.Rupp a ?crit :
>> The annotations from FindBugs and JSR-308 can allow for static code analysis,
>> which may be helpful in error prevention as well.
> Good point
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From hrupp at redhat.com  Tue Mar  3 02:28:45 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 3 Mar 2015 08:28:45 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <54F4DECB.8080309@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
	<28031859-CC3F-444B-9CDE-A3B13A278DC7@redhat.com>
	<1787990386.30528386.1425303721291.JavaMail.zimbra@redhat.com>
	<54F46CA7.7090502@redhat.com>
	<E1A9EA29-4413-4583-8C90-6B4EA3F47008@redhat.com>
	<54F48496.60403@redhat.com> <54F4DECB.8080309@redhat.com>
Message-ID: <EBDF9DA8-E189-44B1-BB55-0CC55C17B644@redhat.com>

Your example shows one more thing that bugs me since Greg established it:

> Am 02.03.2015 um 23:06 schrieb Jay Shaughnessy <jshaughn at redhat.com>:
> 
>     @GET
>     @Path("/trigger/{triggerId}")
>     @Produces(APPLICATION_JSON)
>     @ApiOperation(value = "Find all threshold conditions",
>             responseClass = 
> "Collection<org.hawkular.alerts.api.model.condition.StringCondition>",
>             notes = "Pagination is not yet implemented")
>     public void findAllThresholdConditionsByTrigger(
>             @Suspended
>             final AsyncResponse response,
>             @ApiParam(value = "Trigger id to get threshold conditions", 
> required = true)
>             @PathParam("triggerId")
>             final String triggerId) {
>         try {
>             Collection<Condition> conditionsList = 
> definitions.getTriggerConditions(triggerId, null);
>             Collection<ThresholdCondition> thresholdConditions = new 
> ArrayList<ThresholdCondition>();
>             for (Condition cond : conditionsList) {

It is virtually unclear when the real method body starts, because there
is no visual guide to it. Yes, my IDE can show the folds, but it should also be
clear when looking at the code on e.g. GitHub (which also can't infer @Null)
I'd like us to use

    public signature_of_method(...
       ...
    {   // in same row as the 'p' from public
       // real method body goes here 





From hrupp at redhat.com  Tue Mar  3 02:32:46 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 3 Mar 2015 08:32:46 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
Message-ID: <D9A4E99A-2D20-4997-8895-BB1DC10DCAE3@redhat.com>

Hello,

I have set up a Doodle to determine how we proceed.

http://doodle.com/we2yweic43i4nz3g

Please fill it in.

  Heiko


> Am 02.03.2015 um 11:27 schrieb Heiko W.Rupp <hrupp at redhat.com>:
> 
> Hey,
> 
> as we were having a discussion this morning on #hawkular-dev about null
> 
> I think we should start (on top of writing more JavaDoc) using
> annotations to mark methods and method parameters that
> allow being null / not null and if they may return null or not.
> 
> This is especially important on API classes(*1), that may be 
> consumed by 3rd parties that may or may not have insight
> into source of the implementation (on top of that, such annotations
> are an enhancement of the API contract).
> 
> I know we have been talking about that in the past without
> no real result. Luckily since then JSR 308 has been
> marked as final and thus a standard exists, that includes such
> annotations (+ a checking framework, + tooling to retroactively add
> such annotations to existing source).
> 
> See http://types.cs.washington.edu/checker-framework/
> and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts
> 
> http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10 <- annotations
> http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc
> 
> Another option are the org.jetbrains versions of the annotations, which are around for a while.
> 
> If we only care about documentation, but not compile time and/or static analysis, we can also
> use the ones from BeanValidation, which live under the javax package spaces (iirc). *2
> 
> Here is a more complete list of frameworks
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
> 
> 
> 
> 
> *1) Java and REST
> *2) BV may be a good idea for more complex input like in alert definition
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From gbrown at redhat.com  Tue Mar  3 03:11:36 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 3 Mar 2015 03:11:36 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <54F4CABD.5010502@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
	<2141878912.20257560.1425288376365.JavaMail.zimbra@redhat.com>
	<1669338395.20806784.1425292257260.JavaMail.zimbra@redhat.com>
	<816652226.20270214.1425292737052.JavaMail.zimbra@redhat.com>
	<1758553568.20838455.1425293640020.JavaMail.zimbra@redhat.com>
	<1918450370.20274167.1425294415435.JavaMail.zimbra@redhat.com>
	<1166809026.20855651.1425294794485.JavaMail.zimbra@redhat.com>
	<54F4CABD.5010502@redhat.com>
Message-ID: <684177864.20962838.1425370296700.JavaMail.zimbra@redhat.com>

Is there any plans to support an arbitrary Java type as an alert? If not, then what about a MapData type?

Regards
Gary
 
----- Original Message -----
> 
> 
> On 3/2/2015 6:13 AM, Lucas Ponce wrote:
> >
> > ----- Original Message -----
> >> From: "Gary Brown" <gbrown at redhat.com>
> >> To: "Lucas Ponce" <lponce at redhat.com>
> >> Cc: hawkular-dev at lists.jboss.org
> >> Sent: Monday, March 2, 2015 12:06:55 PM
> >> Subject: Re: [Hawkular-dev] Notification messages
> >>
> >> Hi
> >>
> >> Maybe your suggestion is the way to go - RTGov still generates
> >> 'situations'
> >> which are made available to the alerts engine to determine if a
> >> notification
> >> should be raised. So looks like there are two possibilities:
> >>
> >> (a) RTGov somehow creates alerts directly, so alerts engine, RTGov, other
> >> components, etc could independently raise alerts that are then used to
> >> create notifications.
> >>
> >> or
> >>
> >> (b) RTGov and other components create their own event to represent a
> >> 'situation of interest', and the alerts engine interprets these to
> >> determine
> >> if an alert should be create resulting in notifications.
> >>
> >>
> >> I'm open to either approach, although (b) has the benefit of allowing the
> >> source component (e.g. RTGov) to simple raises the 'situations' while not
> >> worrying about issues such as dampening, which can be defined with the
> >> alerts engine.
> >>
> > Exactly, 'situations' are data that can be used to create a trigger
> > definition, that can be attached with a notification list.
> >
> > This data can be really simple, for example, it can be just a String with a
> > value, and a condition can be just to detect if you have a new situation
> > into the alerts engine.
> >   
> 
> We definitely want to be able to incorporate external alerts into the
> engine.  I think perhaps we will want to support both approaches above,
> but if it  were just one then I think (b) would be the preference,
> because as you said, it opens up dampening, safety logic and anything
> else that comes into play at the condition-matching phase.
> 
> I'm not sure there is anything today preventing RTGov or anyone from
> using a registered Action, or registering their own Action, and then
> using the bus infrastructure to send it a message.  As long as the
> message had the correct payload it should just work.
> 
> But it should also be fairly easy to hook into the Alerting as a whole.
> I think you could create a Trigger looking for a StringCondition
> operator, send in a Situation in some String format, and have it fire an
> alert for each.  We could maybe do a little better by creating a more
> robust Data element for external systems to hook into.  Something that
> perhaps could extend StringData and also provide a secondary String
> (maybe json), as data that just gets passed along to the notifiers/actions.
> 
> Moreover, we have yet to talk about incorporating Alerts themselves into
> Triggers, such that we start to allow for higher-level Alerting that
> correlates Alerts.  This may lead to a true AlertCondition.  It may be a
> built-in Action that generates an AlertCondition for the alert generated
> by the trigger. Or something like that.
> 
> 
> 
> Actions are tied to the triggers and when the trigger fires an Alert we
> explicitly send a message to the relevant actions' topics on the bus.
> 
> 
> How to handle external alert generation is a great topic.
> This is a good topic.  I think it could be useful to have external
> Alert-generators just feed fully-fledged Alerts into the system
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Wed Mar  4 02:53:21 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Mar 2015 08:53:21 +0100
Subject: [Hawkular-dev] C* at Apple
Message-ID: <228589BF-7465-4178-9E43-EFCA7268DEE0@redhat.com>

https://www.youtube.com/watch?v=Bc4ql9TDzyg&index=48&list=PLqcm6qE9lgKJkxYZUOIykswDndrOItnn2

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From hrupp at redhat.com  Wed Mar  4 08:12:59 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Mar 2015 14:12:59 +0100
Subject: [Hawkular-dev] SE Radio episode on Continuous Devliery
Message-ID: <18CC6EF9-4644-4A65-9F64-DDD7CF95E6B6@redhat.com>

Hey,

this is another excellent episode of Software Engineering Radio - this time on 
Continuous Delivery.

http://www.se-radio.net/2015/02/episode-221-jez-humble-on-continuous-delivery/

Something to consider for your commute to work.

  Heiko



From crobson at redhat.com  Wed Mar  4 08:45:12 2015
From: crobson at redhat.com (Catherine Robson)
Date: Wed, 04 Mar 2015 08:45:12 -0500
Subject: [Hawkular-dev] Forecasting of bad things
In-Reply-To: <3147548.ZtEKCTtQJN@localhost.localdomain>
References: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>
	<54EE3D65.40704@redhat.com>
	<3147548.ZtEKCTtQJN@localhost.localdomain>
Message-ID: <54F70C68.3020301@redhat.com>

Heiko - thanks for sharing.  I know we have talked about this several 
times.  I'll see if Gabriel and Liz can include some examples of future 
metric projection in the work they are doing so we don't lose sight of it.

- Catherine

> Lukas Krejci <mailto:lkrejci at redhat.com>
> February 25, 2015 at 5:15 PM
> These guys have a very interesting modelled-after-brain thing for just 
> these
> types of things...
>
> Anomaly detection, autonomous temporal sequence learning, you name it ;)
>
> https://github.com/numenta/htm.java
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> Matt Wringe <mailto:mwringe at redhat.com>
> February 25, 2015 at 4:23 PM
> Does it only have to be about forecasting/projecting 'bad' things :)
>
> With more historical data, it could get more interesting than a just 
> an estimated straight line.
>
> Say if it was able to know that you have a large increase in power at 
> a particular time of day (eg a 30 minute commute on the train at 17:30 
> where you stream video). The forecasted chart in this case could have 
> a dip in battery reserves at about this time.
>
> But maybe you don't always stream video during your commute. So in 
> this case it could give you an estimated range instead of a particular 
> time.
>
> Although, bringing in historical data analysis and estimated ranges 
> tend to make things more complicated and the charts more confusing.
>
>
> On 25/02/15 03:04 PM, Heiko W. Rupp wrote:
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> Heiko W. Rupp <mailto:hwr at pilhuhn.de>
> February 25, 2015 at 3:04 PM
> Something I was talking about for a while ...
>
> I saw this today in Android 5 - they give you (when the device is 
> running on battery) not only a
> chart about past battery consumption (dark green), but also about 
> estimated future depletion (grey-green)
> and on top of the chart the current state (40%) + an estimate that the 
> battery will last ~4 more days at the
> same usage level.
>
>
>
> -- 
> Heiko Rupp hwr at pilhuhn.de <mailto:hwr at pilhuhn.de>
> Blog: http://pilhuhn.blogspot.com   @pilhuhn
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Catherine Robson
User Experience Design
Red Hat JBoss Middleware
c: 978-944-3825

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150304/71e43f90/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1210 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150304/71e43f90/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150304/71e43f90/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1259 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150304/71e43f90/attachment-0005.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 41714 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150304/71e43f90/attachment-0001.png 

From theute at redhat.com  Wed Mar  4 09:21:58 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 04 Mar 2015 15:21:58 +0100
Subject: [Hawkular-dev] Availability vs uptime for URL "ping"
Message-ID: <54F71506.3050201@redhat.com>


In the most simplistic form of monitoring we're looking at pinging 
website and report up/down and response time from the initiator of the 
HTTP HEAD/GET

We've discussed a bit about availability vs uptime.

First question:	Do we need to distinguish ? Is it important for someone 
who wants to know if his website is accessible to really separate the 2 
concepts. (Details vs simplicity)

Second question: If we separate the 2, how do we do distinguish ? A 
suggestion:
   * HTTP Code 2xx and 3xx -> URL is up and available
   * HTTP Code 4xx -> The server may reject the request (it may not like 
bots, user entered a wrong url (should be checked upfront), or resource 
has been deleted)... Server is up, availability is unknown
   * HTTP Code 5xx -> URL is up but not available
   * Timeout -> URL is down and not available
Couldn't resolve host 'www.fffffffffefwefdwdf.com' -> Domain name is 
deleted: URL is down and not available

4xx is likely the most debatable, it's a client issue and likely needs 
either code fix or user intervention... (And we can't unfortunately 
expect servers to fully respect the codes)

Thoughts ?

Thomas

From hrupp at redhat.com  Wed Mar  4 09:26:31 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Mar 2015 15:26:31 +0100
Subject: [Hawkular-dev] Forecasting of bad things
In-Reply-To: <54EE3D65.40704@redhat.com>
References: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>
	<54EE3D65.40704@redhat.com>
Message-ID: <E2294969-A851-40D7-BE41-B7416B5EE67F@redhat.com>


> Am 25.02.2015 um 22:23 schrieb Matt Wringe <mwringe at redhat.com>:
> 
> With more historical data, it could get more interesting than a just an estimated straight line. 

Absolutely. I did just send this screenshot to show that this is not a crazy idea but in fact already in production in consumer devices.

> 
> Although, bringing in historical data analysis and estimated ranges tend to make things more complicated and the charts more confusing.

We will need to use more complex historical data. 
E.g. implement Holt-Winters forecasting.

  Heiko



From mithomps at redhat.com  Wed Mar  4 12:15:25 2015
From: mithomps at redhat.com (mike thompson)
Date: Wed, 4 Mar 2015 09:15:25 -0800
Subject: [Hawkular-dev] Forecasting of bad things
In-Reply-To: <E2294969-A851-40D7-BE41-B7416B5EE67F@redhat.com>
References: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>
	<54EE3D65.40704@redhat.com>
	<E2294969-A851-40D7-BE41-B7416B5EE67F@redhat.com>
Message-ID: <40782A98-4118-40B5-813B-CD64C7DB6B8B@redhat.com>

Along this same vein of predictive anomaly detection, here are two videos (one from Netflix and one from Twitter) from the SF Metrics Meetup:

http://blog.librato.com/posts/sf-metrics-meetup-anomaly-detection <http://blog.librato.com/posts/sf-metrics-meetup-anomaly-detection>



> On 4 Mar 2015, at 06:26, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> 
>> Am 25.02.2015 um 22:23 schrieb Matt Wringe <mwringe at redhat.com>:
>> 
>> With more historical data, it could get more interesting than a just an estimated straight line. 
> 
> Absolutely. I did just send this screenshot to show that this is not a crazy idea but in fact already in production in consumer devices.
> 
>> 
>> Although, bringing in historical data analysis and estimated ranges tend to make things more complicated and the charts more confusing.
> 
> We will need to use more complex historical data. 
> E.g. implement Holt-Winters forecasting.
> 
>  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/20150304/0eeec9cf/attachment.html 

From lkrejci at redhat.com  Thu Mar  5 07:40:02 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 05 Mar 2015 13:40:02 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
Message-ID: <11325390.tKcYtSOpoj@localhost.localdomain>

I'm late to the game but I am very MUCH in favor of introducing these into the 
codebase.

For me the annotations bring in the clear intention of the writer that is 
otherwise potentially complex to deduce from the code itself.

IDEs can try to infer the intention of the writer only to an extent and give 
up with methods of certain complexity.

Also, if one annotates methods as returning @Nonnull, the IDE (Idea in my 
case) can be sure of it and will flag any possibility of a null return for me. 
If the annotation is NOT there, all the IDE can assume is that the method 
returns a nullable value.

@Nonnull on parameters is even more useful, because the IDE will flag any 
potentially unsafe method invocation with a possibly null value. If the 
annotation is NOT present, all the IDE can infer is to offer a nullity check 
on method params in the method body - which is exactly not what the writer 
wanted to do ;)

Again, this seems useless in trivial examples, but I've benefited from using 
these annotations many times in any non-trivial code.

On Monday, March 02, 2015 11:27:31 Heiko W.Rupp wrote:
> Hey,
> 
> as we were having a discussion this morning on #hawkular-dev about null
> 
> I think we should start (on top of writing more JavaDoc) using
> annotations to mark methods and method parameters that
> allow being null / not null and if they may return null or not.
> 
> This is especially important on API classes(*1), that may be
> consumed by 3rd parties that may or may not have insight
> into source of the implementation (on top of that, such annotations
> are an enhancement of the API contract).
> 
> I know we have been talking about that in the past without
> no real result. Luckily since then JSR 308 has been
> marked as final and thus a standard exists, that includes such
> annotations (+ a checking framework, + tooling to retroactively add
> such annotations to existing source).
> 
> See http://types.cs.washington.edu/checker-framework/
> and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts
> 
> http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10
> <- annotations
> http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc
> 
> Another option are the org.jetbrains versions of the annotations, which are
> around for a while.
> 
> If we only care about documentation, but not compile time and/or static
> analysis, we can also use the ones from BeanValidation, which live under
> the javax package spaces (iirc). *2
> 
> Here is a more complete list of frameworks
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-sho
> uld-i-use
> 
> 
> 
> 
> *1) Java and REST
> *2) BV may be a good idea for more complex input like in alert definition
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Thu Mar  5 07:49:29 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 5 Mar 2015 13:49:29 +0100
Subject: [Hawkular-dev] @Null / @NotNull
In-Reply-To: <11325390.tKcYtSOpoj@localhost.localdomain>
References: <158A7EC5-183B-4BEF-B656-5B7D6C64CECB@redhat.com>
	<11325390.tKcYtSOpoj@localhost.localdomain>
Message-ID: <B91028A5-4EE0-473E-BD4E-49B30CE1DE8B@redhat.com>


> Am 05.03.2015 um 13:40 schrieb Lukas Krejci <lkrejci at redhat.com>:
> For me the annotations bring in the clear intention of the writer that is 
> otherwise potentially complex to deduce from the code itself.
> 
> IDEs can try to infer the intention of the writer only to an extent and give 
> up with methods of certain complexity.

The annotations not only help convey the intention of the writer.

Folks that just browse the GitHub repo or that we send pointers to api methods
on GitHub also do not have the benefit of IDEs inferring the values.

But then it was hard to write, so it should be hard to understand. :-)))



From tsegismo at redhat.com  Thu Mar  5 12:32:34 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 05 Mar 2015 18:32:34 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
Message-ID: <54F89332.3080506@redhat.com>

Hi,

There's a growing portion of application code in the metrics REST API 
which returns errors (with whichever HTTP status) in the following form:

====
{"errorMsg": "blah"}
====

Whether this format is nice or suitable is not the purpose of this 
message. I just want to draw your attention to the fact that being 
consistent regarding error reporting is important.

In this regard, I've added a new ExceptionMapper for 
org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only 
application errors conform to the format above, but also errors coming 
from payload parsing.

Regards,
Thomas

[1] 
http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#builtinException

From mazz at redhat.com  Thu Mar  5 13:57:10 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 5 Mar 2015 13:57:10 -0500 (EST)
Subject: [Hawkular-dev] infinispan + cassandra
In-Reply-To: <413068512.23703640.1425581797998.JavaMail.zimbra@redhat.com>
Message-ID: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>

I'm looking at Infinispan and how it can be configured in Wildfly (there was talk about us needing a clustered cache in the kettle, so this is what started me looking at this).

Since we already have C* in use by metrics, and there is talk that inventory is going to use C* under the covers, I was wondering what people thought about utlizing C* as the persistent backend for infinispan:

http://infinispan.org/docs/cachestores/cassandra/

This provides persistence across a clustered infinispan cache.

Is this something we'd be interested in or would want to use?

From jshaughn at redhat.com  Thu Mar  5 14:03:26 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 05 Mar 2015 14:03:26 -0500
Subject: [Hawkular-dev] infinispan + cassandra
In-Reply-To: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>
References: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>
Message-ID: <54F8A87E.3080302@redhat.com>


My guess is that we are going to want a cluster-wide cache at some 
point, as we scale.  Whether it needs to be persisted, I don't know.  
But I think it could be useful to make it available and see how it may work.

On 3/5/2015 1:57 PM, John Mazzitelli wrote:
> I'm looking at Infinispan and how it can be configured in Wildfly (there was talk about us needing a clustered cache in the kettle, so this is what started me looking at this).
>
> Since we already have C* in use by metrics, and there is talk that inventory is going to use C* under the covers, I was wondering what people thought about utlizing C* as the persistent backend for infinispan:
>
> http://infinispan.org/docs/cachestores/cassandra/
>
> This provides persistence across a clustered infinispan cache.
>
> Is this something we'd be interested in or would want to use?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From jsanda at redhat.com  Thu Mar  5 15:17:33 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 5 Mar 2015 15:17:33 -0500
Subject: [Hawkular-dev] infinispan + cassandra
In-Reply-To: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>
References: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>
Message-ID: <99B192D1-E232-4A30-9B1E-5ACBABCB01B9@redhat.com>

That cache store is out of date and probably would not want to use it with more recent versions (> 1.2) of Cassandra. We would want a cache store based on CQL. With that said, I still think it is a good idea to look into Infinispan. And if we are going to consider Infinispan, then we should also be thinking about Spark, particularly in terms of  Cassandra integration.

> On Mar 5, 2015, at 1:57 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I'm looking at Infinispan and how it can be configured in Wildfly (there was talk about us needing a clustered cache in the kettle, so this is what started me looking at this).
> 
> Since we already have C* in use by metrics, and there is talk that inventory is going to use C* under the covers, I was wondering what people thought about utlizing C* as the persistent backend for infinispan:
> 
> http://infinispan.org/docs/cachestores/cassandra/
> 
> This provides persistence across a clustered infinispan cache.
> 
> Is this something we'd be interested in or would want to use?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From theute at redhat.com  Fri Mar  6 01:54:07 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 06 Mar 2015 07:54:07 +0100
Subject: [Hawkular-dev] infinispan + cassandra
In-Reply-To: <54F8A87E.3080302@redhat.com>
References: <2026192286.23703709.1425581830352.JavaMail.zimbra@redhat.com>
	<54F8A87E.3080302@redhat.com>
Message-ID: <54F94F0F.3060304@redhat.com>

I don't see why this would have to be persisted for that use case, but 
C* cache store is not production ready.

Thomas


On 03/05/2015 08:03 PM, Jay Shaughnessy wrote:
> My guess is that we are going to want a cluster-wide cache at some
> point, as we scale.  Whether it needs to be persisted, I don't know.
> But I think it could be useful to make it available and see how it may work.
>
> On 3/5/2015 1:57 PM, John Mazzitelli wrote:
>> I'm looking at Infinispan and how it can be configured in Wildfly (there was talk about us needing a clustered cache in the kettle, so this is what started me looking at this).
>>
>> Since we already have C* in use by metrics, and there is talk that inventory is going to use C* under the covers, I was wondering what people thought about utlizing C* as the persistent backend for infinispan:
>>
>> http://infinispan.org/docs/cachestores/cassandra/
>>
>> This provides persistence across a clustered infinispan cache.
>>
>> Is this something we'd be interested in or would want to use?
>> _______________________________________________
>> 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


From hrupp at redhat.com  Fri Mar  6 04:25:25 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Mar 2015 10:25:25 +0100
Subject: [Hawkular-dev] Availability vs uptime for URL "ping"
In-Reply-To: <54F71506.3050201@redhat.com>
References: <54F71506.3050201@redhat.com>
Message-ID: <03DF2899-42C5-4A5F-8524-CF107404197E@redhat.com>

[ I will send a follow up email for "computed resource state" ]

> We've discussed a bit about availability vs uptime.
> 
> First question:	Do we need to distinguish ? Is it important for someone 
> who wants to know if his website is accessible to really separate the 2 
> concepts. (Details vs simplicity)

Isn't uptime a function of availability over time?
And even this is not always correct if you take a machine that has been powered up and is up for 4 weeks, then its uptime is 4 weeks. If someone in the middle of the 4 weeks pulls the power cord on the network switch, then it may not be available (for business) for a while, but it is still up.
But if we take this edge case away (because when connectivity is up again, we can find out with the uptime(1) command that it indeed was up all the time). The two match nicely.

> 
> Second question: If we separate the 2, how do we do distinguish ? A 
> suggestion:
>   * HTTP Code 2xx and 3xx -> URL is up and available

+1

>   * HTTP Code 4xx -> The server may reject the request (it may not like 
> bots, user entered a wrong url (should be checked upfront), or resource 
> has been deleted)... Server is up, availability is unknown
>   * HTTP Code 5xx -> URL is up but not available
>   * Timeout -> URL is down and not available
> Couldn't resolve host 'www.fffffffffefwefdwdf.com' -> Domain name is 
> deleted: URL is down and not available

Here we might need to even have special handling if this happens when the url is first entered,
and ask the user in case of error if this entered url was "wrong" on purpose (Test-Driven-Ops)
or not.

> 
> 4xx is likely the most debatable, it's a client issue and likely needs 
> either code fix or user intervention... (And we can't unfortunately 
> expect servers to fully respect the codes)

Usually for a client user that wants to shop at acme.com, it does not matter if the server returns a 500 or a
404 - Shop not found.

In a more general case one can argue that it is the business of a feed to determine the values for availability.




From hrupp at redhat.com  Fri Mar  6 04:30:07 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Mar 2015 10:30:07 +0100
Subject: [Hawkular-dev] Computed resource state
Message-ID: <4438D5C6-242F-4E43-B266-2F47474725FB@redhat.com>


But in fact (and we were discussing that already) if the above url "ping" would be done from two different sites (e.g. US and EU) and one would return 200 and the other a timeout, then the real availability would be UP, as it is reachable (*1). Here a single feed (pinger in one location) is no longer able to determine the availability alone.

Also it may not be enough to determine availability by status code alone, as a 200 after 2 minutes is for the end customer equivalent to down.


And then we found out in RHQ that just having availability states of "UP" and "DOWN" are not enough, as individual resources may be down on purpose, the feed may just not report anything. Or when you look at a group of resources (or composite resource) like an application consisting of multiple services, the total availability of my shop may be up, but degraded (e.g. slow response time). Or it may be up and fast, but one of the 3 servers in the cluster is down .

This is why I am proposing a) to have a more differentiated set of "resource state"s and b) to have this state being a function of several input parameters. 

About a) this is a list of possible resource states, where UP and DOWN correspond to the classical binary availability terms.

UP: Resource is available and working normally
DEGRADED: Resource is available but not at full performance
DOWN: Resource is at fault and not working normally
MAINTENANCE: There is a scheduled maintenance period, availability may be UP or DOWN
MISSING: The resource was recorded in inventory, but does not exist in reality (e.g. was deleted on file system)
ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin (e.g. a network interface on a 8 port card where only 1 cable is connected)
UNKNOWN: Resource state can not be determined

Aggregated state

A state of ?MIXED? can be added for groups or applications (e.g 3 servers in a cluster, one server is down, 2 are up).
For groups, the aggregated state could be computed as follows, but see below
All UP: Group is UP
All DOWN: Group is DOWN
Otherwise: Group is MIXED


Wrt b) computation of state

For the example of the url ping, the resource state could be computed as 

function(list< code, time >) {
  result = down;
  for (< code, time > ) {
      if (code == 200 )  {
         if (time < threshold ) {
            return UP;
         }
     }
  }
  return DOWN
}

This is already sort of what alerting is doing partially right now, and we could use this in a rectified way

[input values]----> [  resource state processor ]  ---(+) 

and then at the (+) point we expose the resource state to e.g. the UI and other services,
where one of the services is the alert engine 

(+)----> [  alert engine  ] ---->  [ notification handlers ]

That decides upon the computed states if alerting needs to be done and in what way.


*1) Of course we still need to flag the timeout, as the timeout may have an impact on customers being able to reach the shop.



From vrockai at redhat.com  Fri Mar  6 04:37:39 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Fri, 06 Mar 2015 10:37:39 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F89332.3080506@redhat.com>
References: <54F89332.3080506@redhat.com>
Message-ID: <1425634659.22395.1.camel@vrockai-laptop>

Hello, 

Thanks for opening this issue again. I think we should follow a standard
here. Let me just copy-paste from my last email (Thread "REST ideas"):

Another REST issue we should agree on: The standard for error responses.
I've found, that there are several standards we can follow (or create
our own):
http://stackoverflow.com/a/14538774/3252949

In my opinion it's fine to stick with the JSON API:
http://jsonapi.org/format/#errors

or stick with even simpler google style guide:
https://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml?showone=error#error


Viliam

On Thu, 2015-03-05 at 18:32 +0100, Thomas Segismont wrote:
> Hi,
> 
> There's a growing portion of application code in the metrics REST API 
> which returns errors (with whichever HTTP status) in the following form:
> 
> ====
> {"errorMsg": "blah"}
> ====
> 
> Whether this format is nice or suitable is not the purpose of this 
> message. I just want to draw your attention to the fact that being 
> consistent regarding error reporting is important.
> 
> In this regard, I've added a new ExceptionMapper for 
> org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only 
> application errors conform to the format above, but also errors coming 
> from payload parsing.
> 
> Regards,
> Thomas
> 
> [1] 
> http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#builtinException
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From tsegismo at redhat.com  Fri Mar  6 04:48:28 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Mar 2015 10:48:28 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <1425634659.22395.1.camel@vrockai-laptop>
References: <54F89332.3080506@redhat.com>
	<1425634659.22395.1.camel@vrockai-laptop>
Message-ID: <54F977EC.8080609@redhat.com>

I'm fine with something simple to begin with.

Really, the purpose of my email was to recall we're running on top of a 
container+framework and that application errors are not the only ones.

Le 06/03/2015 10:37, Viliam Rockai a ?crit :
> Hello,
>
> Thanks for opening this issue again. I think we should follow a standard
> here. Let me just copy-paste from my last email (Thread "REST ideas"):
>
> Another REST issue we should agree on: The standard for error responses.
> I've found, that there are several standards we can follow (or create
> our own):
> http://stackoverflow.com/a/14538774/3252949
>
> In my opinion it's fine to stick with the JSON API:
> http://jsonapi.org/format/#errors
>
> or stick with even simpler google style guide:
> https://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml?showone=error#error
>
>
> Viliam
>
> On Thu, 2015-03-05 at 18:32 +0100, Thomas Segismont wrote:
>> Hi,
>>
>> There's a growing portion of application code in the metrics REST API
>> which returns errors (with whichever HTTP status) in the following form:
>>
>> ====
>> {"errorMsg": "blah"}
>> ====
>>
>> Whether this format is nice or suitable is not the purpose of this
>> message. I just want to draw your attention to the fact that being
>> consistent regarding error reporting is important.
>>
>> In this regard, I've added a new ExceptionMapper for
>> org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only
>> application errors conform to the format above, but also errors coming
>> from payload parsing.
>>
>> Regards,
>> Thomas
>>
>> [1]
>> http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#builtinException
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From hrupp at redhat.com  Fri Mar  6 04:57:33 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Mar 2015 10:57:33 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F89332.3080506@redhat.com>
References: <54F89332.3080506@redhat.com>
Message-ID: <94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>

We should all over the place

a) specifc exceptions for some of the more common cases
like StuffNotFoundException(message)

b) add Exception mappers that deal with mapping that exception content to some sensible output depending on requested media type.

We have done that in RHQ, which could for the start be copied 1:1.
See

https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/rest/CustomExceptionMapper.java
and
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/rest/ParameterMissingException.java
and
https://github.com/rhq-project/rhq/blob/master/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/rest/StuffNotFoundException.java




> Am 05.03.2015 um 18:32 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> Hi,
> 
> There's a growing portion of application code in the metrics REST API 
> which returns errors (with whichever HTTP status) in the following form:
> 
> ====
> {"errorMsg": "blah"}
> ====
> 
> Whether this format is nice or suitable is not the purpose of this 
> message. I just want to draw your attention to the fact that being 
> consistent regarding error reporting is important.
> 
> In this regard, I've added a new ExceptionMapper for 
> org.jboss.resteasy.spi.ReaderException[2] instances. So now, not only 
> application errors conform to the format above, but also errors coming 
> from payload parsing.
> 
> Regards,
> Thomas
> 
> [1] 
> http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#builtinException
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters



From jpkroehling at redhat.com  Fri Mar  6 05:07:55 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 06 Mar 2015 11:07:55 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
References: <54F89332.3080506@redhat.com>
	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
Message-ID: <54F97C7B.20303@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2015 10:57 AM, Heiko W.Rupp wrote:
> We should all over the place
> 
> a) specifc exceptions for some of the more common cases like
> StuffNotFoundException(message)
> 
> b) add Exception mappers that deal with mapping that exception
> content to some sensible output depending on requested media type.

I think we should be a bit careful with blindly throwing exceptions
and mapping them to responses. Exceptions are more expensive than just
checking for an object's existence and, for a public service (SaaS),
this could be abused.

For scenarios where things were really expected to be there but
aren't, exceptions are fine. For scenarios where the user asked for
something that didn't exist, input checking and promptly returning a
404 makes more sense, IMO.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU+Xx6AAoJECKM1e+fkPrXcjsH/2oX5F8HIcz9a29km8hSGBY2
/iPdHDmOA/WkdB/75T29oTdaVqKQkDonqHOsVC/GkBGNedJcWhnrdkN+08KZvseH
nED3e9EcKjY833jK1/1r4muPHNmDxGkE91AtsOGdQDo95ckDtqSH2qnJQns9GHZ5
qYohcKWFMZpD42upcYRaOyQTJBrN79WSwnoiijeTmb+OE4UoGIpRM/L2QS3lPcCq
4SMW2NuXJW06cm5OJTnfoc590JOf7fRkQakzA+W22GxE4INdkL95fQGS+Zoxp0cv
8ITUM4Ek1eyBc+LXMh0xB4P5mLGbiuoyD9l6oxC9w7vDOp8e2UGTRASdNiKwxSc=
=YcB3
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Fri Mar  6 05:17:34 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Mar 2015 11:17:34 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F97C7B.20303@redhat.com>
References: <54F89332.3080506@redhat.com>	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
	<54F97C7B.20303@redhat.com>
Message-ID: <54F97EBE.7060504@redhat.com>

Le 06/03/2015 11:07, Juraci Paix?o Kr?hling a ?crit :
> I think we should be a bit careful with blindly throwing exceptions
> and mapping them to responses. Exceptions are more expensive than just
> checking for an object's existence and, for a public service (SaaS),
> this could be abused.
>
> For scenarios where things were really expected to be there but
> aren't, exceptions are fine. For scenarios where the user asked for
> something that didn't exist, input checking and promptly returning a
> 404 makes more sense, IMO.

+1

From lponce at redhat.com  Fri Mar  6 05:55:29 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 6 Mar 2015 05:55:29 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F97EBE.7060504@redhat.com>
References: <54F89332.3080506@redhat.com>
	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
	<54F97C7B.20303@redhat.com> <54F97EBE.7060504@redhat.com>
Message-ID: <597118559.24123623.1425639329935.JavaMail.zimbra@redhat.com>



> 
> Le 06/03/2015 11:07, Juraci Paix?o Kr?hling a ?crit :
> > I think we should be a bit careful with blindly throwing exceptions
> > and mapping them to responses. Exceptions are more expensive than just
> > checking for an object's existence and, for a public service (SaaS),
> > this could be abused.
> >
> > For scenarios where things were really expected to be there but
> > aren't, exceptions are fine. For scenarios where the user asked for
> > something that didn't exist, input checking and promptly returning a
> > 404 makes more sense, IMO.
> 
> +1

+1


From hrupp at redhat.com  Fri Mar  6 06:11:19 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Mar 2015 12:11:19 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F97C7B.20303@redhat.com>
References: <54F89332.3080506@redhat.com>
	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
	<54F97C7B.20303@redhat.com>
Message-ID: <FE345795-9E36-4F44-BBBC-CF60EB6F6750@redhat.com>


> Am 06.03.2015 um 11:07 schrieb Juraci Paix?o Kr?hling <jpkroehling at redhat.com>:
> For scenarios where things were really expected to be there but
> aren't, exceptions are fine. For scenarios where the user asked for
> something that didn't exist, input checking and promptly returning a
> 404 makes more sense, IMO.

I fear that this will lead to pretty unreadable code with many blocks of 

return Response.Builder.notFound(new StringEntity("this is my message %s",bla)).type("application/json").build()

While we do (only) application/json right now, this will get more complex with more (custom) media types.



From jpkroehling at redhat.com  Fri Mar  6 06:30:15 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 06 Mar 2015 12:30:15 +0100
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <FE345795-9E36-4F44-BBBC-CF60EB6F6750@redhat.com>
References: <54F89332.3080506@redhat.com>	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>	<54F97C7B.20303@redhat.com>
	<FE345795-9E36-4F44-BBBC-CF60EB6F6750@redhat.com>
Message-ID: <54F98FC7.8090307@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2015 12:11 PM, Heiko W.Rupp wrote:
> 
>> Am 06.03.2015 um 11:07 schrieb Juraci Paix?o Kr?hling
>> <jpkroehling at redhat.com>: For scenarios where things were really
>> expected to be there but aren't, exceptions are fine. For
>> scenarios where the user asked for something that didn't exist,
>> input checking and promptly returning a 404 makes more sense,
>> IMO.
> 
> I fear that this will lead to pretty unreadable code with many
> blocks of
> 
> return Response.Builder.notFound(new StringEntity("this is my
> message %s",bla)).type("application/json").build()
> 
> While we do (only) application/json right now, this will get more
> complex with more (custom) media types.

How about then making beans for representing the responses and letting
the JAX-RS convert it to the appropriate media type? The disadvantage
is that each "response" structure requires a class. The advantage is
that it's well documented what is the response's structure.

class ErrorResponseBean {
  String message;
}

ResponseBean bean = new ErrorResponseBean("this is my message %s",bla);
Response.notFound().entity(bean).build();

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU+Y/HAAoJECKM1e+fkPrXKLUH/2RYlwMACfK42JODX4w3BAc4
Lj1c4ObCkgHvLtP11/m8nA+HZwegFVqqJQZSYji3q9WYfLPBsQeRJv9Yciii5VnE
UaqxGwPRyxx6nVluPK4gBX8qirKFZh05kM6vRAotjYtnK8+BnxnEb38UmYVuhFL6
HIglliwtVqIK9CWmUn7atPCK7d6o0k3/xC1Kh0435dv85evC0kVr8w7eORC1iWjF
EBoHOvdYHl+rrvsOJyIXZERxhVhx4JD/gydsvKD5IBc4Q38fI0yXVtQdutsaufpW
CEwI2SrSZjZ9T2J9oVRUT8KgD/9GPNwTjGCmVu1e4tAq/yR57pj0OoY7gpjf640=
=+Q8p
-----END PGP SIGNATURE-----

From miburman at redhat.com  Fri Mar  6 06:56:25 2015
From: miburman at redhat.com (Michael Burman)
Date: Fri, 6 Mar 2015 06:56:25 -0500 (EST)
Subject: [Hawkular-dev] [metrics] Consistent error replies from REST API
In-Reply-To: <54F98FC7.8090307@redhat.com>
References: <54F89332.3080506@redhat.com>
	<94CDD07D-F852-4981-BF21-A56E61B07B61@redhat.com>
	<54F97C7B.20303@redhat.com>
	<FE345795-9E36-4F44-BBBC-CF60EB6F6750@redhat.com>
	<54F98FC7.8090307@redhat.com>
Message-ID: <7376203.34615437.1425642985275.JavaMail.zimbra@redhat.com>

Hi,

This is what's done in the websocket branch currently:

    @Override
    public void onFailure(Throwable t) {
        Error errors = new Error(errorMsg + ": " + Throwables.getRootCause(t).getMessage());
        response.resume(Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(errors).type(
            MediaType.APPLICATION_JSON_TYPE).build());
    }

public class Error {
    private String errorMsg;

..

Currently with forced JSON.

  - Micke

----- Original Message -----
From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Friday, March 6, 2015 1:30:15 PM
Subject: Re: [Hawkular-dev] [metrics] Consistent error replies from REST API

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2015 12:11 PM, Heiko W.Rupp wrote:
> 
>> Am 06.03.2015 um 11:07 schrieb Juraci Paix?o Kr?hling
>> <jpkroehling at redhat.com>: For scenarios where things were really
>> expected to be there but aren't, exceptions are fine. For
>> scenarios where the user asked for something that didn't exist,
>> input checking and promptly returning a 404 makes more sense,
>> IMO.
> 
> I fear that this will lead to pretty unreadable code with many
> blocks of
> 
> return Response.Builder.notFound(new StringEntity("this is my
> message %s",bla)).type("application/json").build()
> 
> While we do (only) application/json right now, this will get more
> complex with more (custom) media types.

How about then making beans for representing the responses and letting
the JAX-RS convert it to the appropriate media type? The disadvantage
is that each "response" structure requires a class. The advantage is
that it's well documented what is the response's structure.

class ErrorResponseBean {
  String message;
}

ResponseBean bean = new ErrorResponseBean("this is my message %s",bla);
Response.notFound().entity(bean).build();

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU+Y/HAAoJECKM1e+fkPrXKLUH/2RYlwMACfK42JODX4w3BAc4
Lj1c4ObCkgHvLtP11/m8nA+HZwegFVqqJQZSYji3q9WYfLPBsQeRJv9Yciii5VnE
UaqxGwPRyxx6nVluPK4gBX8qirKFZh05kM6vRAotjYtnK8+BnxnEb38UmYVuhFL6
HIglliwtVqIK9CWmUn7atPCK7d6o0k3/xC1Kh0435dv85evC0kVr8w7eORC1iWjF
EBoHOvdYHl+rrvsOJyIXZERxhVhx4JD/gydsvKD5IBc4Q38fI0yXVtQdutsaufpW
CEwI2SrSZjZ9T2J9oVRUT8KgD/9GPNwTjGCmVu1e4tAq/yR57pj0OoY7gpjf640=
=+Q8p
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev


From silverblack11 at gmail.com  Fri Mar  6 13:02:03 2015
From: silverblack11 at gmail.com (Samat Gayazov)
Date: Fri, 6 Mar 2015 21:02:03 +0300
Subject: [Hawkular-dev] GSOC2015 - Hawkular - Android client
Message-ID: <CAFEAaAAD1rWQes1v4Fi5FejJcZEhYYBGyf8-U+i+Aoy5UGNrOw@mail.gmail.com>

Hello!
My name is Samat Gayazov, and I?m interested in contributing towards the
project Hawkular - Android client. I am a student of Software Engineering
at HSE Moscow, I have strong background in Java, C++, Python, and C#.
Previously I developed some apps for mobile Windows platform and for
Android. I know a lot about Android?s Material Design, and here is my apps:
https://play.google.com/store/apps/developer?id=dieserSamat
http://apps.microsoft.com/windows/app/travelassist/83f6db61-b655-4986-be5f-7150f282ed75
<http://www.google.com/url?q=http%3A%2F%2Fapps.microsoft.com%2Fwindows%2Fapp%2Ftravelassist%2F83f6db61-b655-4986-be5f-7150f282ed75&sa=D&sntz=1&usg=AFQjCNFH5MM8AcgmxFwhEwXstf4VPBjnjQ>

I have also finished course of iOS Swift Programming and course about
building UIs, which, I think, will help me to develop better mobile apps.
So, I?m really looking forward to participating in Google Summer of Code
and contributing to Hawkular - Android client.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150306/07512d8f/attachment.html 

From mwringe at redhat.com  Mon Mar  9 09:50:43 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Mon, 09 Mar 2015 09:50:43 -0400
Subject: [Hawkular-dev] Clustering and Scalability
Message-ID: <54FDA533.2030707@redhat.com>

Hey,

I am trying to figure out how clustering and scalability works in 
Hawkular/Hawkular metrics. Do we have any documentation on this?

Thanks,

Matt Wringe






From mazz at redhat.com  Mon Mar  9 10:37:46 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 9 Mar 2015 10:37:46 -0400 (EDT)
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <54FDA533.2030707@redhat.com>
References: <54FDA533.2030707@redhat.com>
Message-ID: <1321579907.25689889.1425911866783.JavaMail.zimbra@redhat.com>

> I am trying to figure out how clustering and scalability works in
> Hawkular/Hawkular metrics. Do we have any documentation on this?

I've been asking the same question every now and then for a few weeks now. The answer I've been consistently getting is "it will scale when we get the customer to cluster the hawkular servers by putting one if his own load balancers in front" :)


From tsegismo at redhat.com  Mon Mar  9 10:48:53 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 09 Mar 2015 15:48:53 +0100
Subject: [Hawkular-dev] [metrics] Influx gap analysis
Message-ID: <54FDB2D5.6030900@redhat.com>

Hi everyone,

We've been talking about Influx support in Metrics recently so I've 
started a gap analysis document:

https://docs.google.com/document/d/1xZRt7MjvZJ7J8jKFNrR8bYebcObihfd1YIljvkzmem4/edit

It doesn't say how we could implement missing features but rather lists 
them (well, the most important).

Feel free to comment.

Regards,
Thomas

From ike.braun at googlemail.com  Mon Mar  9 10:50:54 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Mon, 9 Mar 2015 15:50:54 +0100
Subject: [Hawkular-dev] [metrics] Influx gap analysis
In-Reply-To: <54FDB2D5.6030900@redhat.com>
References: <54FDB2D5.6030900@redhat.com>
Message-ID: <D2D76440-8302-4C64-852F-06D7967B491B@googlemail.com>

The biggest gap is probably the query language. 

Btw, there was post on the influx list recently, that it now supports windows as well.

> On 09 Mar 2015, at 15:48, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi everyone,
> 
> We've been talking about Influx support in Metrics recently so I've 
> started a gap analysis document:
> 
> https://docs.google.com/document/d/1xZRt7MjvZJ7J8jKFNrR8bYebcObihfd1YIljvkzmem4/edit
> 
> It doesn't say how we could implement missing features but rather lists 
> them (well, the most important).
> 
> Feel free to comment.
> 
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From tsegismo at redhat.com  Mon Mar  9 10:53:25 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 09 Mar 2015 15:53:25 +0100
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <54FDA533.2030707@redhat.com>
References: <54FDA533.2030707@redhat.com>
Message-ID: <54FDB3E5.4050402@redhat.com>

I can't answer for Hawkular as a whole. But for the metrics component, 
the principle is to grow the backend Cassandra and Wildfly servers 
clusters. You'll need a load balancer in front of the Wildfly servers.

There's no documentation yet. Cassandra cluster administration is 
extensively documented though.

Le 09/03/2015 14:50, Matt Wringe a ?crit :
> Hey,
>
> I am trying to figure out how clustering and scalability works in
> Hawkular/Hawkular metrics. Do we have any documentation on this?
>
> Thanks,
>
> Matt Wringe
>
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From tsegismo at redhat.com  Mon Mar  9 10:58:22 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 09 Mar 2015 15:58:22 +0100
Subject: [Hawkular-dev] [metrics] Influx gap analysis
In-Reply-To: <D2D76440-8302-4C64-852F-06D7967B491B@googlemail.com>
References: <54FDB2D5.6030900@redhat.com>
	<D2D76440-8302-4C64-852F-06D7967B491B@googlemail.com>
Message-ID: <54FDB50E.4040001@redhat.com>

Le 09/03/2015 15:50, Heiko Braun a ?crit :
> The biggest gap is probably the query language.
>

There's already partial support in metrics. Would you mind to comment 
the doc to say what's more important to you?

> Btw, there was post on the influx list recently, that it now supports windows as well.
>
>> On 09 Mar 2015, at 15:48, Thomas Segismont <tsegismo at redhat.com> wrote:
>>
>> Hi everyone,
>>
>> We've been talking about Influx support in Metrics recently so I've
>> started a gap analysis document:
>>
>> https://docs.google.com/document/d/1xZRt7MjvZJ7J8jKFNrR8bYebcObihfd1YIljvkzmem4/edit
>>
>> It doesn't say how we could implement missing features but rather lists
>> them (well, the most important).
>>
>> Feel free to comment.
>>
>> Regards,
>> Thomas
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lponce at redhat.com  Mon Mar  9 10:59:04 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 9 Mar 2015 10:59:04 -0400 (EDT)
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <54FDA533.2030707@redhat.com>
References: <54FDA533.2030707@redhat.com>
Message-ID: <1555985223.25727992.1425913144364.JavaMail.zimbra@redhat.com>

Related to Alerts, we have three aspects to consider in a clustering configuration:

a) Clustered Queues/Topics.
b) A common persistence datasource, at the moment we are using H2, and it is not decided yet what it will be the future one.
c) Our engine has a backend session for inference. We need to review if under a) we don't have concurrency hazards.

c) is in our todo list as soon as we progress in the MVP.

HTH,
Lucas

----- Original Message -----
> From: "Matt Wringe" <mwringe at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, March 9, 2015 2:50:43 PM
> Subject: [Hawkular-dev] Clustering and Scalability
> 
> Hey,
> 
> I am trying to figure out how clustering and scalability works in
> Hawkular/Hawkular metrics. Do we have any documentation on this?
> 
> Thanks,
> 
> Matt Wringe
> 
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jsanda at redhat.com  Mon Mar  9 11:27:08 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 9 Mar 2015 11:27:08 -0400
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <54FDB3E5.4050402@redhat.com>
References: <54FDA533.2030707@redhat.com> <54FDB3E5.4050402@redhat.com>
Message-ID: <71DEF577-D973-4601-BC4C-451CD53E4C48@redhat.com>

For metrics it is more than a load balancer and scaling Cassandra. We have to also consider things like,

* computing aggregates
* changing data retention
* deleting metrics

We need to decide how these types of work should be distributed across hawkular metrics nodes.

> On Mar 9, 2015, at 10:53 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> I can't answer for Hawkular as a whole. But for the metrics component, 
> the principle is to grow the backend Cassandra and Wildfly servers 
> clusters. You'll need a load balancer in front of the Wildfly servers.
> 
> There's no documentation yet. Cassandra cluster administration is 
> extensively documented though.
> 
> Le 09/03/2015 14:50, Matt Wringe a ?crit :
>> Hey,
>> 
>> I am trying to figure out how clustering and scalability works in
>> Hawkular/Hawkular metrics. Do we have any documentation on this?
>> 
>> Thanks,
>> 
>> Matt Wringe
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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



From miburman at redhat.com  Tue Mar 10 08:07:40 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 10 Mar 2015 14:07:40 +0200
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <71DEF577-D973-4601-BC4C-451CD53E4C48@redhat.com>
References: <54FDA533.2030707@redhat.com> <54FDB3E5.4050402@redhat.com>
	<71DEF577-D973-4601-BC4C-451CD53E4C48@redhat.com>
Message-ID: <54FEDE8C.7070206@redhat.com>

Hi,

So what we're looking for is basically YARN or equivalent. Batch 
operations, durable streaming applications, data warehousing, 
resilience, scalability.. All of the tools that provide us such features 
are quite heavyweight solutions. If we keep adding small solutions such 
as "Cassandra", "Spark" or others, we'll soon need to containerize them 
to stick together and so on.. and eventually we'll have a Hadoop.

And I hope we won't reinvent such platform. So more likely we'll need to 
scale down what we really really need.

   -  Micke

On 09.03.2015 17:27, John Sanda wrote:
> For metrics it is more than a load balancer and scaling Cassandra. We have to also consider things like,
>
> * computing aggregates
> * changing data retention
> * deleting metrics
>
> We need to decide how these types of work should be distributed across hawkular metrics nodes.
>
>> On Mar 9, 2015, at 10:53 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>
>> I can't answer for Hawkular as a whole. But for the metrics component,
>> the principle is to grow the backend Cassandra and Wildfly servers
>> clusters. You'll need a load balancer in front of the Wildfly servers.
>>
>> There's no documentation yet. Cassandra cluster administration is
>> extensively documented though.
>>
>> Le 09/03/2015 14:50, Matt Wringe a ?crit :
>>> Hey,
>>>
>>> I am trying to figure out how clustering and scalability works in
>>> Hawkular/Hawkular metrics. Do we have any documentation on this?
>>>
>>> Thanks,
>>>
>>> Matt Wringe
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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


From jsanda at redhat.com  Tue Mar 10 10:46:45 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 10 Mar 2015 10:46:45 -0400
Subject: [Hawkular-dev] Clustering and Scalability
In-Reply-To: <54FEDE8C.7070206@redhat.com>
References: <54FDA533.2030707@redhat.com> <54FDB3E5.4050402@redhat.com>
	<71DEF577-D973-4601-BC4C-451CD53E4C48@redhat.com>
	<54FEDE8C.7070206@redhat.com>
Message-ID: <3E5F4347-4079-46A1-AF5C-D3E431428DB7@redhat.com>

I am not sure why you think we are looking for YARN. I think we have been pretty consistent about needing to keep external dependencies to a minimum. Granted I have said that Spark is something we ought to look at, but I have also said that its biggest drawback is the additional external dependencies. As for Cassandra, we introduced that in RHQ after a lengthy, thorough, collaborative analysis because it was clear that the RDBMS was not the best fit for metrics. I think we should take a similar approach when considering new/other external dependencies. Trying to minimize external dependencies does not preclude the need for batch operations, streaming, resilience, scalability, etc. It may however make those features more difficult to implement.


> On Mar 10, 2015, at 8:07 AM, Michael Burman <miburman at redhat.com> wrote:
> 
> Hi,
> 
> So what we're looking for is basically YARN or equivalent. Batch 
> operations, durable streaming applications, data warehousing, 
> resilience, scalability.. All of the tools that provide us such features 
> are quite heavyweight solutions. If we keep adding small solutions such 
> as "Cassandra", "Spark" or others, we'll soon need to containerize them 
> to stick together and so on.. and eventually we'll have a Hadoop.
> 
> And I hope we won't reinvent such platform. So more likely we'll need to 
> scale down what we really really need.
> 
>   -  Micke
> 
> On 09.03.2015 17:27, John Sanda wrote:
>> For metrics it is more than a load balancer and scaling Cassandra. We have to also consider things like,
>> 
>> * computing aggregates
>> * changing data retention
>> * deleting metrics
>> 
>> We need to decide how these types of work should be distributed across hawkular metrics nodes.
>> 
>>> On Mar 9, 2015, at 10:53 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>> 
>>> I can't answer for Hawkular as a whole. But for the metrics component,
>>> the principle is to grow the backend Cassandra and Wildfly servers
>>> clusters. You'll need a load balancer in front of the Wildfly servers.
>>> 
>>> There's no documentation yet. Cassandra cluster administration is
>>> extensively documented though.
>>> 
>>> Le 09/03/2015 14:50, Matt Wringe a ?crit :
>>>> Hey,
>>>> 
>>>> I am trying to figure out how clustering and scalability works in
>>>> Hawkular/Hawkular metrics. Do we have any documentation on this?
>>>> 
>>>> Thanks,
>>>> 
>>>> Matt Wringe
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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



From jpkroehling at redhat.com  Tue Mar 10 11:14:18 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Tue, 10 Mar 2015 16:14:18 +0100
Subject: [Hawkular-dev] Heads up: registration/login for console is coming
	soon
Message-ID: <54FF0A4A.9070907@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I've just sent a PR for console that enables the Keycloak integration.
What does this mean for you, as a developer?

- - When opening the console, you'll be presented with the login page
provided by Keycloak. If it's the first time you are opening after
building the kettle, you'll need to register an account. After that,
you'll be redirected back to the console. On the subsequent runs,
you'll just need to login again, as long as the data directory is
preserved (ie: until you rebuild kettle)

- - Running your UI plugin via ui-components with "connect-COMPONENT" is
*not* affected.

- - Your WAR deployment is not protected, meaning, you can still call
your backend without passing any credentials.

Note that the UI integration is temporary, as hawt.io will provide a
better Keycloak integration "natively".

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU/wpKAAoJECKM1e+fkPrXKkUH/RDGtIIfTqxyVBxNhXfQcnzr
jpA2nRLTp56eMZYP43d2Om13lbDYtAguiUPP2k5Y3huDAYQLQLAVHbF9hRenaiie
actkuiEZ60rxZ+qYUMt/EjBpPdFupHnRra3Uc/G5LMAWOh1eSEjmrBM4bShSgj3M
CSmtrTcXuK+QdFJ7OkzA4BoX+uK5z/EX2iNsYRITAI1281xG1zK3ndAt6HQwKCvs
DDJauCw/DVdOiucJzXrfzFx4CwecjyK9lJUNRvCkyO4qtukH+i/LP09nnt+RC2Di
+fyeDhEzQrLIQTpk8vpbCe4aRKZvLP25AVCgVnh0017aUMgtMO2neOleM/4weWg=
=38rr
-----END PGP SIGNATURE-----

From raghuram.4350 at gmail.com  Tue Mar 10 12:11:46 2015
From: raghuram.4350 at gmail.com (Raghu Ram)
Date: Tue, 10 Mar 2015 21:41:46 +0530
Subject: [Hawkular-dev] Interested in android development
Message-ID: <CAHHB_vuL9cM13gW+dw-fZQm8ABq3E3cJRgcPKFinaK87uMk_pg@mail.gmail.com>

Hi all,
I am extremely interested in Android development.
And I came across the idea Hawkular in you ideas page.
I am excited by it. I am looking forward to contribute to JBoss during
this summer during GSoC.
I wanted to work on android client. Is there any repository already
existing or should I start a new one based on studying desktop version?
I could not find any android app here -https://github.com/hawkular.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150310/aff58f73/attachment.html 

From snegrea at redhat.com  Wed Mar 11 00:07:20 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 11 Mar 2015 00:07:20 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics - PR155 Merged
In-Reply-To: <48241491.2438027.1426045174724.JavaMail.zimbra@redhat.com>
Message-ID: <1089368918.2443146.1426046840834.JavaMail.zimbra@redhat.com>

Hello Everybody,

I've merged PR155 [1] into master of Hawkular Metrics. The code is in fairly good shape but will need adjustments since the refactoring is far from done. I wanted to merge today because the branch was diverging too much from master and was impeding other PRs from being completed and merged.

My focus was to simplify the public API implementation with two main goals: faster implementation of additional features and enable additional implementation in the future (eg. Undertow or Websocket). I've changed very little in the mechanics for storing and retrieving data from Cassandra.

Here are few principles that I tried to follow:
1) Simplify everything as much as possible
2) No more intermediary mapper classes in the jaxrs module; expose meaningful fields of domain models via the public API
3) No complicated and individual callbacks in the jaxrs module, prefer specialized data transforms with generic callbacks
4) The public API implementation should be as uniform and monotone as possible
5) Keep all domain code away from jaxrs module and vice-versa
6) Avoid circular dependencies between models where the children have a reference to the parent

Here is a list of things to cover in the following weeks:
1) Simplify core-api and core-impl composition; right now there is no clear differentiator between the two
2) The domain classes are not settled in yet, the composition needs more tweaks to get a clean domain
3) Add more integration tests, the set in there right now is really minimal
4) Add more swagger documentation
5) Expose schema for each end-point via */schema URL

Next steps for Hawkular integration:
1) Get the current API stable (probably another week)
2) Work with projects that interact and/or consume Hawkular Metrics to adjust the integration.


All feedback is more than welcomed :)


[1] https://github.com/hawkular/hawkular-metrics/pull/155

Thank you,
Stefan Negrea

Software Engineer


From hrupp at redhat.com  Wed Mar 11 09:35:29 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 11 Mar 2015 14:35:29 +0100
Subject: [Hawkular-dev] Interested in android development
In-Reply-To: <CAHHB_vuL9cM13gW+dw-fZQm8ABq3E3cJRgcPKFinaK87uMk_pg@mail.gmail.com>
References: <CAHHB_vuL9cM13gW+dw-fZQm8ABq3E3cJRgcPKFinaK87uMk_pg@mail.gmail.com>
Message-ID: <E0F9BEDC-F47D-499A-9CAB-4BC09F227A78@redhat.com>

Hey,

On 10 Mar 2015, at 17:11, Raghu Ram wrote:

> I am extremely interested in Android development.
> And I came across the idea Hawkular in you ideas page.
> I am excited by it. I am looking forward to contribute to JBoss during
> this summer during GSoC.
> I wanted to work on android client. Is there any repository already
> existing or should I start a new one based on studying desktop version?
> I could not find any android app here -https://github.com/hawkular.

No, no Android client already exists. Please join us in #hawkular
on irc.freenode.net so we could discuss further

 Heiko

From hrupp at redhat.com  Wed Mar 11 09:40:18 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 11 Mar 2015 14:40:18 +0100
Subject: [Hawkular-dev] GSOC2015 - Hawkular - Android client
In-Reply-To: <CAFEAaAAD1rWQes1v4Fi5FejJcZEhYYBGyf8-U+i+Aoy5UGNrOw@mail.gmail.com>
References: <CAFEAaAAD1rWQes1v4Fi5FejJcZEhYYBGyf8-U+i+Aoy5UGNrOw@mail.gmail.com>
Message-ID: <48E85063-29F7-44F3-BDA7-7CFED7AB7640@redhat.com>

Hello,

On 6 Mar 2015, at 19:02, Samat Gayazov wrote:

> Previously I developed some apps for mobile Windows platform and for
> Android. I know a lot about Android?s Material Design, and here is 
> my apps:
> https://play.google.com/store/apps/developer?id=dieserSamat
> http://apps.microsoft.com/windows/app/travelassist/83f6db61-b655-4986-be5f-7150f282ed75
> <http://www.google.com/url?q=http%3A%2F%2Fapps.microsoft.com%2Fwindows%2Fapp%2Ftravelassist%2F83f6db61-b655-4986-be5f-7150f282ed75&sa=D&sntz=1&usg=AFQjCNFH5MM8AcgmxFwhEwXstf4VPBjnjQ>

Cool.

>
> I have also finished course of iOS Swift Programming and course about
> building UIs, which, I think, will help me to develop better mobile 
> apps.

Could you join #hawkular on irc.frenode.net so we could discuss that 
further?

  Heiko


From mazz at redhat.com  Wed Mar 11 11:53:56 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 11 Mar 2015 11:53:56 -0400 (EDT)
Subject: [Hawkular-dev] agent implementation
In-Reply-To: <2019780590.27838272.1426088214681.JavaMail.zimbra@redhat.com>
Message-ID: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>

Time to start thinking about the agent. As you probably know, the "nest" started out being the "agent" - but it worked out to be something we could use for the server components and it ended up being used for the "kettle" - hosting everything (console, server components, data storage, etc). We can still use the "nest" for agents - that's not a problem. My question is - what do people think about that?

So, what do you think the Hawkular agent should "be"?

I see three options - Feel free to suggest others:

(I mention only one PRO/CON for each, though I'm sure there are many more)

1) It could be our own homegrown Java app (similar to what RHQ did, which means we build out our own agent container).

* PRO: We put in and control everything that goes into it - however big it gets (code size and runtime footprint size) is based on what we explicitly put in it.
* CON: We put in and control everything that goes into it :) It is not trivial to implement classloading isolation and plugin mechanisms.

2) Or it could be built on top of WildFly (either use the "nest" or use WildFly Core)

* PRO: We don't worry about things that WildFly gives us for free (e.g. JBoss Modules for plugin/deployments and classloading isolation; if we want, we can get EE capabilities)
* CON: The runtime footprint might be larger than we want or what customers expect.

3) Or it could be built on top of something else (Vert.x? Something else)?

* PRO: Depending on the technology, might provide us with a smaller runtime footprint than a full WildFly container
* CON: Depending on the technology, might not provide us all the capabilities we want

What are your ideas for what you think the "agent" should look like?

--John Mazz

From jpkroehling at redhat.com  Wed Mar 11 12:26:30 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 11 Mar 2015 17:26:30 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
Message-ID: <55006CB6.1020503@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Alexandre (and others) asked about the possibility of adding a default
user on Keycloak for the Hawkular realm.

While adding a default user with the requirement of changing the
password on the first login is a possibility, I'd rather have an
alternative realm file to import during first boot.

This means: a dev (or user) have to actively copy this JSON file into
standalone/configuration in order to have a default user.

The idea is that we wouldn't ship with a default username/password on
the main distribution. Having a default username is usually not
recommended from the security perspective, as it's half of the
information required to login with super power rights (and you would
be surprised to know how many admins set their passwords to "admin").

Given these two alternatives, which one would you prefer? Voting is
open and I'll take the results on Monday 9am CET (08:00 UTC).

[ ] Default user on the main realm JSON file that will ship with Kettle
[ ] Alternate JSON realm file with a default user, which can be copied
over the default JSON realm file.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
=G8QS
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Wed Mar 11 12:28:03 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 11 Mar 2015 17:28:03 +0100
Subject: [Hawkular-dev] agent implementation
In-Reply-To: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
Message-ID: <55006D13.6080802@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

On 03/11/2015 04:53 PM, John Mazzitelli wrote:
> So, what do you think the Hawkular agent should "be"?

I'm sorry for asking this, but I'm not familiar with the details of
how the RHQ agent works.

What is the scope of the agent? Will it gather only data about the
environment, like, memory consumption, span of worker threads, CPU
consumption, GC-time, ...? Or business metrics as well, like "requests
per second", "number of exceptions in the last X minutes", "average
time spent on database", and so on?

Also, is the same agent also responsible for capturing non-JVM related
data, like, disk space utilization, network traffic, ...?

- - Juca.


[re-sending to the list, as it seems I sent this only to John]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAG0TAAoJECKM1e+fkPrXv6EH/jFYQjtI4wqgqW8UzahiEbOF
uvmjrtdyLD1YbiA6ZGSLo9veFCBkz1pY9mm3sCe/yzG/ns6yaOIYQ0tYlyC26MI/
VthnBGSQKRjDSa9HGrwd9qoENdlD32VMZcPUp1TjZrLljz6c8kARojAFiCWlzxR/
PFyFTxxzFG85RFI1XXTzxX08f8aCUCaBLL6El/k0XQg1gEcQOmESgl9X0OaTEe3b
Zam3siF08cYjdS7YQETWGXuBoe+9tNkW3FynP6DmpASUv7+SZ2h8Wzx3FOGQqOUc
DR4Q+OHaRF3BZzCg3LDPNgGKhCQ0vPjhCJWM3qzLUOslw7yy2FFVW51vzyffRkM=
=uPBc
-----END PGP SIGNATURE-----

From theute at redhat.com  Wed Mar 11 12:55:27 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 11 Mar 2015 17:55:27 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <55006CB6.1020503@redhat.com>
References: <55006CB6.1020503@redhat.com>
Message-ID: <5500737F.2090901@redhat.com>

Not sure to understand the alternatives but I have comments:
     - Having 'admin' or 'root' for a super user IMO simplifies 
documentation/usage. (I can imagine that a user could forget what 
username he chose as superadmin for instance).
     - We need to force "complex passwords", this is actually a product 
requirement
     - Copying a file is a step that needs to be documented and is 
unfriendly + either you need to encode the password (some tool like for 
Wildfly) or worse have the password in clear in a file for import.

So I am a +1 on setting up the superuser password on first request as 
default. An alternative with a preset file (if present) would be welcome 
for those who are afraid of first request hijacking.

Thomas




On 03/11/2015 05:26 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Alexandre (and others) asked about the possibility of adding a default
> user on Keycloak for the Hawkular realm.
>
> While adding a default user with the requirement of changing the
> password on the first login is a possibility, I'd rather have an
> alternative realm file to import during first boot.
>
> This means: a dev (or user) have to actively copy this JSON file into
> standalone/configuration in order to have a default user.
>
> The idea is that we wouldn't ship with a default username/password on
> the main distribution. Having a default username is usually not
> recommended from the security perspective, as it's half of the
> information required to login with super power rights (and you would
> be surprised to know how many admins set their passwords to "admin").
>
> Given these two alternatives, which one would you prefer? Voting is
> open and I'll take the results on Monday 9am CET (08:00 UTC).
>
> [ ] Default user on the main realm JSON file that will ship with Kettle
> [ ] Alternate JSON realm file with a default user, which can be copied
> over the default JSON realm file.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
> =G8QS
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From amendonc at redhat.com  Wed Mar 11 13:29:05 2015
From: amendonc at redhat.com (Alexandre Mendonca)
Date: Wed, 11 Mar 2015 13:29:05 -0400 (EDT)
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5500737F.2090901@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
Message-ID: <1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>

The alternative of a file to be copied over would be used mostly for development, where after building we would copy it over so that after each rebuild it's not needed to go through the registrations process.

But, I think if the credentials are preset to admin/admin, needing to be changed on first login (with whichever strength enforcement we decide and keycloak supports) along with email address, it would be safe. The only possibility of an attacker logging in with default credentials would be for a never configured installation.. and for that, even the keycloak "master" realm is exposed to the same risk.

Actually, thinking of it, the "master" realm situation is dangerous, if a user never needs to login directly to it, he may leave it in "unconfigured" state, where it can be accessed later by an attacker.

So I vote for option 1. And we need to figure a solution for also forcing the user to change the default admin/admin of "master" realm.


Alexandre

----- Original Message -----
From: "Thomas Heute" <theute at redhat.com>
To: jpkroehling at redhat.com, hawkular-dev at lists.jboss.org
Sent: Wednesday, March 11, 2015 4:55:27 PM
Subject: Re: [Hawkular-dev] Default user, or alternative realm file?

Not sure to understand the alternatives but I have comments:
     - Having 'admin' or 'root' for a super user IMO simplifies 
documentation/usage. (I can imagine that a user could forget what 
username he chose as superadmin for instance).
     - We need to force "complex passwords", this is actually a product 
requirement
     - Copying a file is a step that needs to be documented and is 
unfriendly + either you need to encode the password (some tool like for 
Wildfly) or worse have the password in clear in a file for import.

So I am a +1 on setting up the superuser password on first request as 
default. An alternative with a preset file (if present) would be welcome 
for those who are afraid of first request hijacking.

Thomas




On 03/11/2015 05:26 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Alexandre (and others) asked about the possibility of adding a default
> user on Keycloak for the Hawkular realm.
>
> While adding a default user with the requirement of changing the
> password on the first login is a possibility, I'd rather have an
> alternative realm file to import during first boot.
>
> This means: a dev (or user) have to actively copy this JSON file into
> standalone/configuration in order to have a default user.
>
> The idea is that we wouldn't ship with a default username/password on
> the main distribution. Having a default username is usually not
> recommended from the security perspective, as it's half of the
> information required to login with super power rights (and you would
> be surprised to know how many admins set their passwords to "admin").
>
> Given these two alternatives, which one would you prefer? Voting is
> open and I'll take the results on Monday 9am CET (08:00 UTC).
>
> [ ] Default user on the main realm JSON file that will ship with Kettle
> [ ] Alternate JSON realm file with a default user, which can be copied
> over the default JSON realm file.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
> =G8QS
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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


From mazz at redhat.com  Wed Mar 11 13:30:47 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 11 Mar 2015 13:30:47 -0400 (EDT)
Subject: [Hawkular-dev] agent implementation
In-Reply-To: <55006A83.9080603@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<55006A83.9080603@redhat.com>
Message-ID: <2136958616.27899072.1426095047268.JavaMail.zimbra@redhat.com>

> I'm sorry for asking this, but I'm not familiar with the details of
> how the RHQ agent works.
> 
> What is the scope of the agent? Will it gather only data about the
> environment, like, memory consumption, span of worker threads, CPU
> consumption, GC-time, ...? Or business metrics as well, like "requests
> per second", "number of exceptions in the last X minutes", "average
> time spent on database", and so on?
> 
> Also, is the same agent also responsible for capturing non-JVM related
> data, like, disk space utilization, network traffic, ...?

Ahhh!! You are one step ahead of me! This was going to be the SECOND question I was going to ask  I haven't sent that email yet. But I will copy-n-paste your questions since it asks some of the things I was going to ask :-)

From mwringe at redhat.com  Wed Mar 11 13:35:22 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Wed, 11 Mar 2015 13:35:22 -0400
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5500737F.2090901@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
Message-ID: <55007CDA.5060204@redhat.com>

In LiveOak for the OpenShift cartridge, we had the system generate an 
initial default password. So on first login you would have to know the 
randomized initial password, and also be forced to set a new password on 
the first login. It wasn't too bad on OpenShift since the password was 
set it to the Mongodb cartridge's password which was visible in the 
OpenShift console. It solved the problem of first-to-access-hijacking 
(which in my opinion is a bad situation, things should be secure by 
default).

We could have something setup so that when the server is first started 
we look for a property to use for the initial credentials (eg 
-Dhawkular.initial.password=foo). If that property is not set, then 
generate a password and display it in the logs or in a file somewhere. 
When the user would login for the first time, they would need to enter 
this password and then be forced to set a real password. If they don't 
set the property it could be a bit annoying as they might have to ssh 
into a machine to read the file/logs to get the initial password.


On 11/03/15 12:55 PM, Thomas Heute wrote:
> Not sure to understand the alternatives but I have comments:
>       - Having 'admin' or 'root' for a super user IMO simplifies
> documentation/usage. (I can imagine that a user could forget what
> username he chose as superadmin for instance).
>       - We need to force "complex passwords", this is actually a product
> requirement
>       - Copying a file is a step that needs to be documented and is
> unfriendly + either you need to encode the password (some tool like for
> Wildfly) or worse have the password in clear in a file for import.
>
> So I am a +1 on setting up the superuser password on first request as
> default. An alternative with a preset file (if present) would be welcome
> for those who are afraid of first request hijacking.
>
> Thomas
>
>
>
>
> On 03/11/2015 05:26 PM, Juraci Paix?o Kr?hling wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> All,
>>
>> Alexandre (and others) asked about the possibility of adding a default
>> user on Keycloak for the Hawkular realm.
>>
>> While adding a default user with the requirement of changing the
>> password on the first login is a possibility, I'd rather have an
>> alternative realm file to import during first boot.
>>
>> This means: a dev (or user) have to actively copy this JSON file into
>> standalone/configuration in order to have a default user.
>>
>> The idea is that we wouldn't ship with a default username/password on
>> the main distribution. Having a default username is usually not
>> recommended from the security perspective, as it's half of the
>> information required to login with super power rights (and you would
>> be surprised to know how many admins set their passwords to "admin").
>>
>> Given these two alternatives, which one would you prefer? Voting is
>> open and I'll take the results on Monday 9am CET (08:00 UTC).
>>
>> [ ] Default user on the main realm JSON file that will ship with Kettle
>> [ ] Alternate JSON realm file with a default user, which can be copied
>> over the default JSON realm file.
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
>> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
>> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
>> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
>> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
>> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
>> =G8QS
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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


From mazz at redhat.com  Wed Mar 11 13:57:11 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 11 Mar 2015 13:57:11 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
Message-ID: <1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>

I was going to wait to post this, but since it was brought up already, might as well start this thread now.

Regardless of how the agent is to be implemented, we need to answer the question "WHAT will the agent DO?" It is an existential question - kind of like asking "What is the purpose to my life?" :)

So, what do we plan on having the agent do? What is its scope?

How much knowledge of the inventory does the agent need to know? How does it gain this knowledge of its inventory?

Does the agent auto-discover resources? How?

Can the agent be told about resources that it cannot auto-discover?

Does the agent need to be pluggable so it can load and interface with plugins to handle monitoring of different resources? What are these plugins?

Additionally, we can add (in Juca's words):

> What is the scope of the agent? Will it gather only data about the
> environment, like, memory consumption, span of worker threads, CPU
> consumption, GC-time, ...? Or business metrics as well, like "requests
> per second", "number of exceptions in the last X minutes", "average
> time spent on database", and so on?
> 
> Also, is the same agent also responsible for capturing non-JVM related
> data, like, disk space utilization, network traffic, ...?


From brmeyer at redhat.com  Wed Mar 11 15:01:12 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 11 Mar 2015 15:01:12 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <1178568100.4254464.1426100452077.JavaMail.zimbra@redhat.com>
Message-ID: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>

Excited to announce Artificer 1.0.0.Alpha1!  Details: https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released

From jpkroehling at redhat.com  Wed Mar 11 15:10:53 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 11 Mar 2015 20:10:53 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
Message-ID: <5500933D.9010507@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John,

On 03/11/2015 06:57 PM, John Mazzitelli wrote:
> Regardless of how the agent is to be implemented, we need to answer
> the question "WHAT will the agent DO?" It is an existential
> question - kind of like asking "What is the purpose to my life?"
> :)

I think the "what" needs to be defined before the "how", hence my
questions.

> So, what do we plan on having the agent do? What is its scope?

I take it that the agent is a "metrics collector". In my mind, it has
no power to influence the state of the application or machine: it just
collects and reports.

Collecting to me means: take a snapshot of the moment and store it
somewhere locally.

Reporting to me means: take the stored snapshots and send it to a
server somewhere. Once the server ACKs that it received, those
snapshots are then removed from the local storage.

> How much knowledge of the inventory does the agent need to know?
> How does it gain this knowledge of its inventory?

Is "inventory" also a definition from RHQ? Or can I assume that
"inventory" is "a thing that can be measured"? Like, "CPU" is an item
on the inventory, as well as "Memory" and "Web Application 'Acme
Travel System'".

> Does the agent auto-discover resources? How?

Yes.

For web applications, via a Java Agent, as this would allow to detect
"everything" that runs on the JVM. With that, it would be possible to
detect deployments and its capabilities (JAX-RS, EJBs, Batch jobs,
...) and apply specific metrics to specific facets. For instance, for
a JAX-RS application, there could be a collection of metrics per
endpoint (average/mean/max/min response times). For EJBs, the same but
per "business method". For JPA, it could collect the time spent on the
DB (and perhaps even aggregate that by prepared statement).

For system resources, I think it would need to be something that would
run with (high?) privileges, so that it can take data like disk space
in all partitions, CPU/memory/swap usage, network traffic, ...

> Can the agent be told about resources that it cannot
> auto-discover?

Do you have a sample use case for this? What I can imagine is: web
application 'Acme Travel System' is deployed but the agent can't
detect it automatically. Something tells the agent that there's a web
application deployed. But still, if it cannot see it, how can it
measure it?

> Does the agent need to be pluggable so it can load and interface
> with plugins to handle monitoring of different resources? What are
> these plugins?

Not sure I understand the question, but I'd say yes: as an application
developer, I want to be able to add custom metrics, such as "# of
logged in users", "# of registrations", "# of checkouts" and so on.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAJM9AAoJECKM1e+fkPrXIIYIAJcw5Ahx6izb5XrQFTXlNy34
gxgSaqQLsn7Dknj5VsftzdYjvOV/hQtX7frVmYoaq1mcLnZy+GrqVHxJQEaxdiFr
qb30GiKg6CYYP1n0kTSTpyhXTctKzukWDw9/CIxsy22eXnTuZkqclPJVGALL3yDS
kdYW7zZh87XV1M/TwIXFOjls7D0KhVlvyJBwLTH4PxHtraQKTTdq7Iwhl9SwZlgS
VEKDkRFCAXhbXUiG9eqkZOat8Pw9aWWP3cY90Q9M512WlXbAhVMEfxVuSX8NxHFp
lMgU2cHS5jzuJEyXaR8e0ggmit8WwM8jm08vvpGUqY1YE/xJ8UYG+HNH4DBNc2M=
=QWMp
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Wed Mar 11 15:20:30 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 11 Mar 2015 20:20:30 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5500737F.2090901@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
Message-ID: <5500957E.8010609@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/11/2015 05:55 PM, Thomas Heute wrote:
> Not sure to understand the alternatives but I have comments: -
> Having 'admin' or 'root' for a super user IMO simplifies 
> documentation/usage. (I can imagine that a user could forget what 
> username he chose as superadmin for instance).

I don't think we have a "super user" or "root". Do we actually need one?

> - We need to force "complex passwords", this is actually a product 
> requirement

That could be enforced on Keycloak, via the same realm configuration
file. I'll take a look at how to configure that and will add. Do you
have a definition of "complex password"?

> - Copying a file is a step that needs to be documented and is 
> unfriendly + either you need to encode the password (some tool like
> for Wildfly) or worse have the password in clear in a file for
> import.

Note that, right now, no file needs to be copied: we ship with a realm
template that does not contain any users. Opening the console when not
logged in presents the user with the login screen. If the user is not
registered yet, said user can self-register. This step (self-register)
is what is being questioned here: it's a PITA to self-register every
time a new build is done locally. So, to prevent self-registration, we
could ship with a default user.

In fact, I think we might have a third option: use the "dev" maven
profile to determine which realm template to use. If the "dev" profile
is active, then we can use the realm with a default user. Otherwise,
no default users.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
=rlWT
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Wed Mar 11 15:23:44 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 11 Mar 2015 20:23:44 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
Message-ID: <55009640.3040202@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/11/2015 06:29 PM, Alexandre Mendonca wrote:
> But, I think if the credentials are preset to admin/admin, needing
> to be changed on first login (with whichever strength enforcement
> we decide and keycloak supports) along with email address, it would
> be safe. The only possibility of an attacker logging in with
> default credentials would be for a never configured installation..
> and for that, even the keycloak "master" realm is exposed to the
> same risk.

Right, but it's a risk we don't need, as I see it only as a
convenience rather than a necessity.

> Actually, thinking of it, the "master" realm situation is
> dangerous, if a user never needs to login directly to it, he may
> leave it in "unconfigured" state, where it can be accessed later by
> an attacker.

> So I vote for option 1. And we need to figure a solution for also
> forcing the user to change the default admin/admin of "master"
> realm.

Indeed, I'll create a JIRA for myself to look into it.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAJZAAAoJECKM1e+fkPrXMeUH/iepqADxdFvGZcFM98+8p+x1
DvqkS4DTWO9uL3P9G7ph4AsR98YFfFhEZ39sZ+PNBLzY++t/Gk4onih3I26NvFhB
EpTwIbp6XfECBIhKBuGvijUxcXuPl01/55RjBhI3NySaW9T7UfqJSVCu/m33QgDj
Pc7xgUN9xn/f0ym22EUcg9jwZPgqs+HPZB+IBSVqhHubFYFDAaBnkT5AwWRsP47o
CTBkjT1gEtw2sYSZeI3V15MiLhjZt2/diKu/EUqwexQmhHcjRpbOG+vbWKJ7c9Ds
Llnv5RKpeb7ikMT0FivC2p80YrIXVU58poz7zF3cyivKTQJv1YqzV/XhGpcj9Pg=
=rDM9
-----END PGP SIGNATURE-----

From mazz at redhat.com  Wed Mar 11 16:12:52 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 11 Mar 2015 16:12:52 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <5500933D.9010507@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
Message-ID: <895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>

> > So, what do we plan on having the agent do? What is its scope?
> 
> I take it that the agent is a "metrics collector". In my mind, it has
> no power to influence the state of the application or machine: it just
> collects and reports.


There was talk some time ago to perhaps think about the agent also doing some preliminary alert processing (which brings up more questions - for example, how does the agent get alert definitions from the server?) In addition, are we going to have the agent be able to perform operations such as "start" or "stop" or "restart" on managed resources? Can an agent reconfigure a managed resource?

So an agent is potentially more than just a "metrics collector". If an agent is going to be nothing more than a metrics collector, that would be something important to decide now because the agent will be much easier to implement if so.


> Collecting to me means: take a snapshot of the moment and store it
> somewhere locally.
> 
> Reporting to me means: take the stored snapshots and send it to a
> server somewhere. Once the server ACKs that it received, those
> snapshots are then removed from the local storage.


This is roughly how we do envision this. Collecting means spooling the metrics until its time to send the data to the server (what you call "reporting"). I originally envisioned this as being metric messages we send to the server over the bus - but since it appears no one likes having a bus infrastructure as the core messaging infrastructure between components, it would have to be a REST request (with a load balancer in front to support scalability :-D). But that's getting into implementation details.


> > How much knowledge of the inventory does the agent need to know?
> > How does it gain this knowledge of its inventory?
> 
> Is "inventory" also a definition from RHQ? Or can I assume that
> "inventory" is "a thing that can be measured"? Like, "CPU" is an item
> on the inventory, as well as "Memory" and "Web Application 'Acme
> Travel System'".


Yes, "inventory" is a definition we used from RHQ-land.

Inventory just means those resources that are known to be installed/running and are being managed/monitored by Hawkular. They can be CPUs, file systems, or things like EAP instances, or other running products like that.

It can get very complicated to ensure agents synchronize the known inventory that the server has.


> > Does the agent auto-discover resources? How?
> 
> Yes.
> 
> For web applications, via a Java Agent, as this would allow to detect
> "everything" that runs on the JVM. With that, it would be possible to
> detect deployments and its capabilities (JAX-RS, EJBs, Batch jobs,
> ...) and apply specific metrics to specific facets. For instance, for
> a JAX-RS application, there could be a collection of metrics per
> endpoint (average/mean/max/min response times). For EJBs, the same but
> per "business method". For JPA, it could collect the time spent on the
> DB (and perhaps even aggregate that by prepared statement).
> 
> For system resources, I think it would need to be something that would
> run with (high?) privileges, so that it can take data like disk space
> in all partitions, CPU/memory/swap usage, network traffic, ...
> 
> > Can the agent be told about resources that it cannot
> > auto-discover?
> 
> Do you have a sample use case for this? What I can imagine is: web
> application 'Acme Travel System' is deployed but the agent can't
> detect it automatically. Something tells the agent that there's a web
> application deployed.

Exactly. That's right.


> But still, if it cannot see it, how can it measure it?


An prime example is we know an EAP instance is there, but we don't have the credentials to probe it. So the agent could know an EAP instance is there, but what's the admin password? Without it, we can't get that EAP's metrics; with it, we can.

Or, another example is that there is an EAP instance but it is not running. Agent has no idea where it is (or even that it exists). We can tell the agent "There is an EAP in directory '/my/app/foo' --- and oh, by the way, its admin credentials are 'admin/foo'".

Or, another example is that its running on a non-default port that the agent wasn't expecting and therefore didn't see. So we'd be able to say "Acme Travel System is installed on port 9091 (not the default 8080)."

So, there could be many reasons why an agent cannot auto-detect something but, with a little help from a human administrator to give it some hints, the agent can be told about a resource and be able to manage it that resource.


> > Does the agent need to be pluggable so it can load and interface
> > with plugins to handle monitoring of different resources? What are
> > these plugins?
> 
> Not sure I understand the question, but I'd say yes: as an application
> developer, I want to be able to add custom metrics, such as "# of
> logged in users", "# of registrations", "# of checkouts" and so on.


And not just add new, custom metrics, but add entirely new resource types, too. For example, we'd like Hawkular to be able to monitor all JBoss middleware products. Suppose we do that - Hawkular 1.0 is a success and people are using it to monitor every JBoss middleware product in existence. But the following year, JBoss might introduce a completely new "JBoss Awesome Product version 1.0" - we'd like an easy way to plug in new capabilities to an existing and running Hawkular system so it can quickly start managing JBoss Awesome Product instances without having to upgrade the entire Hawkular system.

From lkrejci at redhat.com  Wed Mar 11 16:48:12 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 11 Mar 2015 21:48:12 +0100
Subject: [Hawkular-dev] Titan's future at Datastax and Hawkular Inventory
Message-ID: <4177419.344lsAEP2d@localhost.localdomain>

Hi all,

today, Jirka and me attended the webinar organized by Datastax where they 
outlined their plans for Titan - our candidate graph database to use for 
inventory storage.

The outcome is IMHO both good and bad.

Datastax is committed to push Titan to 1.0 and port it to Tinkerpop3 API 
(which is due "imminently" and the port is well under way - 
https://github.com/thinkaurelius/titan/tree/titan09). They are also committed 
to be further involved in the design of the Tinkerpop3 API (i.e. the 
equivalent of JDBC for graph databases).

Once Titan 1.0 is out they plan to "let the community take over" and don't 
plan any further work on it.

After that, they're shifting focus on DSE Graph - a proprietary graph database 
that will be integrated into DSE - their proprietary offering expanding on 
Cassandra's capabilities. This is not going to be open source but will support 
the Tinkerpop3 API as its primary interface.

So there are 2 outcomes for us from this IMHO.

First, if we are to stick with a graph database as the storage platform (which 
I think makes sense), we should adopt Tinkerpop. We currently support 
Tinkerpop2 which is radically different from Tinkerpop3 but the contact 
surface between us and their API is quite small (at least at the moment) and 
in an area that actually didn't change that much (the Gremlin graph traversal 
DSL).

Second, given the unique advantage of the shared storage for metrics and 
inventory, we should stick with Titan (perf benchmarks still pending) for now 
and see how it will evolve post 1.0. If it dies slowly and we hit issues that 
we would not be able to solve ourselves, we can choose another database 
implementing Tinkerpop3. At the moment the only other choice is Neo4j, but 
given the involvement of many graphdb companies in the design of the 
Tinkerpop3 API
(http://www.tinkerpop.com/docs/3.0.0.M7/#tinkerpop-contributors), I am quite 
confident that there are going to be more choices in due time.

As a side note, our inventory API is not tied to the Tinkerpop API in any way. 
It's just that the graph API naturally fits for implementing the inventory API 
and in fact, the impl is quite compact. But should we, due to some cataclysmic 
findings, choose to abandon tinkerpop API altogether, then only a fraction of 
the inventory codebase would be affected - the REST API, UI and all the other 
future integration code would be unaffected by that departure.
 
WDYT?

Lukas




From lkrejci at redhat.com  Wed Mar 11 17:27:11 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 11 Mar 2015 22:27:11 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
Message-ID: <7867525.xgQlY5UXFa@localhost.localdomain>

On Wednesday, March 11, 2015 16:12:52 John Mazzitelli wrote:
> > > So, what do we plan on having the agent do? What is its scope?
> > 
> > I take it that the agent is a "metrics collector". In my mind, it has
> > no power to influence the state of the application or machine: it just
> > collects and reports.
> 
> There was talk some time ago to perhaps think about the agent also doing
> some preliminary alert processing (which brings up more questions - for
> example, how does the agent get alert definitions from the server?)

Alerting has a CRUD interface for it, doesn't it? Since we assume only agent-
>server traffic, the agent will have to know the server's address one way or 
another.

Also, I am not sure that we want to consider the agent a "monolith" doing 
"agenty" stuff and *also* something else like alert preprocessing. For the 
agent, I think we should too think about how we could slice it into individual 
(semi-)independent pieces that could potentially live on their own (imagine 
this topology: agent -> preprocessor -> inventory
                                     -> metrics
                                     -> alerting).
 
> In
> addition, are we going to have the agent be able to perform operations such
> as "start" or "stop" or "restart" on managed resources? Can an agent
> reconfigure a managed resource?
>

Yeah, I am not sure if operations and config management have been scoped in. 
If they end up in, though, agent is an active player in the environment.

> So an agent is potentially more than just a "metrics collector". If an agent
> is going to be nothing more than a metrics collector, that would be
> something important to decide now because the agent will be much easier to
> implement if so.

+1.

Also, because the agent's metrics collection is inherently polling-based, we 
need to figure how we are going to define how often the metrics are going to 
be collected.

> > Collecting to me means: take a snapshot of the moment and store it
> > somewhere locally.
> > 
> > Reporting to me means: take the stored snapshots and send it to a
> > server somewhere. Once the server ACKs that it received, those
> > snapshots are then removed from the local storage.
> 
> This is roughly how we do envision this. Collecting means spooling the
> metrics until its time to send the data to the server (what you call
> "reporting"). I originally envisioned this as being metric messages we send
> to the server over the bus - but since it appears no one likes having a bus
> infrastructure as the core messaging infrastructure between components, it
> would have to be a REST request (with a load balancer in front to support
> scalability :-D). But that's getting into implementation details.
> > > How much knowledge of the inventory does the agent need to know?
> > > How does it gain this knowledge of its inventory?
> > 
> > Is "inventory" also a definition from RHQ? Or can I assume that
> > "inventory" is "a thing that can be measured"? Like, "CPU" is an item
> > on the inventory, as well as "Memory" and "Web Application 'Acme
> > Travel System'".
> 
> Yes, "inventory" is a definition we used from RHQ-land.
> 

Also, it is a name of a lesser-known Hawkular component ;)

> Inventory just means those resources that are known to be installed/running
> and are being managed/monitored by Hawkular. They can be CPUs, file
> systems, or things like EAP instances, or other running products like that.
> 
> It can get very complicated to ensure agents synchronize the known inventory
> that the server has.

I don't think this needs to be too complex in Hawkular though. The agent just 
needs to be told what NOT to collect.

> > > Does the agent auto-discover resources? How?
> > 
> > Yes.

In RHQ ;) It is both a cool feature and a curse because discovery can 
literally take the machine to its knees with RHQ agent and extremely "densely 
populated" machines. We used to have problems with EAP5 for which the 
discovery was so heavyweight (not RHQ's fault actually, but hey) that we could 
spin the CPU on 100% for tens of minutes just to discover the 20 EAP5s running 
on the box.

> > 
> > For web applications, via a Java Agent, as this would allow to detect
> > "everything" that runs on the JVM. With that, it would be possible to
> > detect deployments and its capabilities (JAX-RS, EJBs, Batch jobs,
> > ...) and apply specific metrics to specific facets. For instance, for
> > a JAX-RS application, there could be a collection of metrics per
> > endpoint (average/mean/max/min response times). For EJBs, the same but
> > per "business method". For JPA, it could collect the time spent on the
> > DB (and perhaps even aggregate that by prepared statement).
> > 
> > For system resources, I think it would need to be something that would
> > run with (high?) privileges, so that it can take data like disk space
> > in all partitions, CPU/memory/swap usage, network traffic, ...
> > 

You just described RHQ ;)

> > > Can the agent be told about resources that it cannot
> > > auto-discover?
> > 
> > Do you have a sample use case for this? What I can imagine is: web
> > application 'Acme Travel System' is deployed but the agent can't
> > detect it automatically. Something tells the agent that there's a web
> > application deployed.
> 
> Exactly. That's right.
> 
> > But still, if it cannot see it, how can it measure it?
> 
> An prime example is we know an EAP instance is there, but we don't have the
> credentials to probe it. So the agent could know an EAP instance is there,
> but what's the admin password? Without it, we can't get that EAP's metrics;
> with it, we can.
> 
> Or, another example is that there is an EAP instance but it is not running.
> Agent has no idea where it is (or even that it exists). 

That is true unless we do discovery by filesystem scan (which I DO NOT 
propose, just pointing out the possibility).

> We can tell the
> agent "There is an EAP in directory '/my/app/foo' --- and oh, by the way,
> its admin credentials are 'admin/foo'".
> 
> Or, another example is that its running on a non-default port that the agent
> wasn't expecting and therefore didn't see. So we'd be able to say "Acme
> Travel System is installed on port 9091 (not the default 8080)."
> 
> So, there could be many reasons why an agent cannot auto-detect something
> but, with a little help from a human administrator to give it some hints,
> the agent can be told about a resource and be able to manage it that
> resource.
> > > Does the agent need to be pluggable so it can load and interface
> > > with plugins to handle monitoring of different resources? What are
> > > these plugins?
> > 
> > Not sure I understand the question, but I'd say yes: as an application
> > developer, I want to be able to add custom metrics, such as "# of
> > logged in users", "# of registrations", "# of checkouts" and so on.
> 
> And not just add new, custom metrics, but add entirely new resource types,
> too. For example, we'd like Hawkular to be able to monitor all JBoss
> middleware products. Suppose we do that - Hawkular 1.0 is a success and
> people are using it to monitor every JBoss middleware product in existence.
> But the following year, JBoss might introduce a completely new "JBoss
> Awesome Product version 1.0" - we'd like an easy way to plug in new
> capabilities to an existing and running Hawkular system so it can quickly
> start managing JBoss Awesome Product instances without having to upgrade
> the entire Hawkular system.

Well, in here I think we need to answer a crucial question. Do we want to 
continue the RHQ path of "writing agent plugin for X" or should we rather try 
to focus on "providing X with easy to use tools to report to Hawkular", i.e. 
easily consumable REST API, possibly some other niceties for Java-based 
applications, like annotations for declarative monitoring, or some kind of 
Wildfly extension that could be configured inject itself into deployments and 
collect configured metrics (byteman-based bytecode enhancements?), etc.

The latter I think is favorable if for nothing else then for the fact that it 
creates potentially less work for us and lets the "domain expert", i.e. the 
developer of X think about what and how to report instead of us learning X in 
haste and second guessing.

IMHO the agent exists only for the cases where embedding the "feed" into the 
managed software itself is not possible.

Note that the embedded feed has other benefits, too. For one, it is (or at 
least has a chance of being) in-process with the data, and more importantly, 
if it is in-process, it doesn't create any security concerns.

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From gbrown at redhat.com  Thu Mar 12 04:16:40 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 12 Mar 2015 04:16:40 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
Message-ID: <1465844597.25573915.1426148200734.JavaMail.zimbra@redhat.com>

Congrats on the release and full conformance to the spec!

Regards
Gary

----- Original Message -----
> Excited to announce Artificer 1.0.0.Alpha1!  Details:
> https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> 
> 

From theute at redhat.com  Thu Mar 12 04:31:02 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 Mar 2015 09:31:02 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5500957E.8010609@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<5500957E.8010609@redhat.com>
Message-ID: <55014EC6.6080803@redhat.com>


On 03/11/2015 08:20 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/11/2015 05:55 PM, Thomas Heute wrote:
>> Not sure to understand the alternatives but I have comments: -
>> Having 'admin' or 'root' for a super user IMO simplifies
>> documentation/usage. (I can imagine that a user could forget what
>> username he chose as superadmin for instance).
> I don't think we have a "super user" or "root". Do we actually need one?
Ok, we just discussed that on IRC, for the records as I was afraid that 
an admin would lock himself out by removing his own grants accidentally.

There are "owners" of resources, so they can't remove particular 
privileges unless they transfer full ownership. (They are superuser of 
their resources).

What is not yet defined is what happens when a user is deleted (who gets 
control)

>> - We need to force "complex passwords", this is actually a product
>> requirement
> That could be enforced on Keycloak, via the same realm configuration
> file. I'll take a look at how to configure that and will add. Do you
> have a definition of "complex password"?
Same as default rules when you add an admin user in EAP:
Password requirements are listed below. To modify these restrictions 
edit the add-user.properties configuration file.
  - The password must not be one of the following restricted values 
{root, admin, administrator}
  - The password must contain at least 8 characters, 1 alphabetic 
character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
  - The password must be different from the username
>> - Copying a file is a step that needs to be documented and is
>> unfriendly + either you need to encode the password (some tool like
>> for Wildfly) or worse have the password in clear in a file for
>> import.
> Note that, right now, no file needs to be copied: we ship with a realm
> template that does not contain any users. Opening the console when not
> logged in presents the user with the login screen. If the user is not
> registered yet, said user can self-register. This step (self-register)
> is what is being questioned here: it's a PITA to self-register every
> time a new build is done locally. So, to prevent self-registration, we
> could ship with a default user.
>
> In fact, I think we might have a third option: use the "dev" maven
> profile to determine which realm template to use. If the "dev" profile
> is active, then we can use the realm with a default user. Otherwise,
> no default users.
I quite like this idea, I would let developers comment if that's 
satisfactory.

Thomas


>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
> H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
> EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
> KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
> 7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
> VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
> =rlWT
> -----END PGP SIGNATURE-----


From gbrown at redhat.com  Thu Mar 12 04:37:30 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 12 Mar 2015 04:37:30 -0400 (EDT)
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5500957E.8010609@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<5500957E.8010609@redhat.com>
Message-ID: <264703137.25587439.1426149450011.JavaMail.zimbra@redhat.com>

+1 - dev profile to create default user, prod profile no users.

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/11/2015 05:55 PM, Thomas Heute wrote:
> > Not sure to understand the alternatives but I have comments: -
> > Having 'admin' or 'root' for a super user IMO simplifies
> > documentation/usage. (I can imagine that a user could forget what
> > username he chose as superadmin for instance).
> 
> I don't think we have a "super user" or "root". Do we actually need one?
> 
> > - We need to force "complex passwords", this is actually a product
> > requirement
> 
> That could be enforced on Keycloak, via the same realm configuration
> file. I'll take a look at how to configure that and will add. Do you
> have a definition of "complex password"?
> 
> > - Copying a file is a step that needs to be documented and is
> > unfriendly + either you need to encode the password (some tool like
> > for Wildfly) or worse have the password in clear in a file for
> > import.
> 
> Note that, right now, no file needs to be copied: we ship with a realm
> template that does not contain any users. Opening the console when not
> logged in presents the user with the login screen. If the user is not
> registered yet, said user can self-register. This step (self-register)
> is what is being questioned here: it's a PITA to self-register every
> time a new build is done locally. So, to prevent self-registration, we
> could ship with a default user.
> 
> In fact, I think we might have a third option: use the "dev" maven
> profile to determine which realm template to use. If the "dev" profile
> is active, then we can use the realm with a default user. Otherwise,
> no default users.
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
> H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
> EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
> KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
> 7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
> VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
> =rlWT
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gmorling at redhat.com  Thu Mar 12 06:41:46 2015
From: gmorling at redhat.com (Gunnar Morling)
Date: Thu, 12 Mar 2015 06:41:46 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
Message-ID: <514409150.3628108.1426156906198.JavaMail.zimbra@redhat.com>

Great news. Congrats, Brett!

----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "The Core" <thecore at redhat.com>, hawkular-dev at lists.jboss.org, sme-integration at redhat.com
> Sent: Wednesday, 11 March, 2015 8:01:12 PM
> Subject: Artificer 1.0.0.Alpha1 release
> 
> Excited to announce Artificer 1.0.0.Alpha1!  Details:
> https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> 
> 

From theute at redhat.com  Thu Mar 12 07:52:10 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 Mar 2015 12:52:10 +0100
Subject: [Hawkular-dev] Titan's future at Datastax and Hawkular Inventory
In-Reply-To: <4177419.344lsAEP2d@localhost.localdomain>
References: <4177419.344lsAEP2d@localhost.localdomain>
Message-ID: <55017DEA.1000809@redhat.com>

My main concern if our API can remain as-is is the (difficult) data 
migration. How can we mitigate the risks ?

Thomas

On 03/11/2015 09:48 PM, Lukas Krejci wrote:
> Hi all,
>
> today, Jirka and me attended the webinar organized by Datastax where they
> outlined their plans for Titan - our candidate graph database to use for
> inventory storage.
>
> The outcome is IMHO both good and bad.
>
> Datastax is committed to push Titan to 1.0 and port it to Tinkerpop3 API
> (which is due "imminently" and the port is well under way -
> https://github.com/thinkaurelius/titan/tree/titan09). They are also committed
> to be further involved in the design of the Tinkerpop3 API (i.e. the
> equivalent of JDBC for graph databases).
>
> Once Titan 1.0 is out they plan to "let the community take over" and don't
> plan any further work on it.
>
> After that, they're shifting focus on DSE Graph - a proprietary graph database
> that will be integrated into DSE - their proprietary offering expanding on
> Cassandra's capabilities. This is not going to be open source but will support
> the Tinkerpop3 API as its primary interface.
>
> So there are 2 outcomes for us from this IMHO.
>
> First, if we are to stick with a graph database as the storage platform (which
> I think makes sense), we should adopt Tinkerpop. We currently support
> Tinkerpop2 which is radically different from Tinkerpop3 but the contact
> surface between us and their API is quite small (at least at the moment) and
> in an area that actually didn't change that much (the Gremlin graph traversal
> DSL).
>
> Second, given the unique advantage of the shared storage for metrics and
> inventory, we should stick with Titan (perf benchmarks still pending) for now
> and see how it will evolve post 1.0. If it dies slowly and we hit issues that
> we would not be able to solve ourselves, we can choose another database
> implementing Tinkerpop3. At the moment the only other choice is Neo4j, but
> given the involvement of many graphdb companies in the design of the
> Tinkerpop3 API
> (http://www.tinkerpop.com/docs/3.0.0.M7/#tinkerpop-contributors), I am quite
> confident that there are going to be more choices in due time.
>
> As a side note, our inventory API is not tied to the Tinkerpop API in any way.
> It's just that the graph API naturally fits for implementing the inventory API
> and in fact, the impl is quite compact. But should we, due to some cataclysmic
> findings, choose to abandon tinkerpop API altogether, then only a fraction of
> the inventory codebase would be affected - the REST API, UI and all the other
> future integration code would be unaffected by that departure.
>   
> WDYT?
>
> Lukas
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From lkrejci at redhat.com  Thu Mar 12 08:03:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 12 Mar 2015 13:03:48 +0100
Subject: [Hawkular-dev] Titan's future at Datastax and Hawkular Inventory
In-Reply-To: <55017DEA.1000809@redhat.com>
References: <4177419.344lsAEP2d@localhost.localdomain>
	<55017DEA.1000809@redhat.com>
Message-ID: <4276289.QhzFeSIPe3@localhost.localdomain>

https://github.com/tinkerpop/tinkerpop3/blob/master/gremlin-core/src/main/java/com/tinkerpop/gremlin/structure/io/GraphMigrator.java

This is part of the core Tinkerpop3. So switching to another Tinkerpop3-based 
graph database shouldn't theoretically be an insurmountable obstacle. If we 
move away from graph dbs altogether, we might use the Gremlin IO to persist 
the graph to a file (GraphML) and work with that to migrate it to the 
different datastore.

On Thursday, March 12, 2015 12:52:10 Thomas Heute wrote:
> My main concern if our API can remain as-is is the (difficult) data
> migration. How can we mitigate the risks ?
> 
> Thomas
> 
> On 03/11/2015 09:48 PM, Lukas Krejci wrote:
> > Hi all,
> > 
> > today, Jirka and me attended the webinar organized by Datastax where they
> > outlined their plans for Titan - our candidate graph database to use for
> > inventory storage.
> > 
> > The outcome is IMHO both good and bad.
> > 
> > Datastax is committed to push Titan to 1.0 and port it to Tinkerpop3 API
> > (which is due "imminently" and the port is well under way -
> > https://github.com/thinkaurelius/titan/tree/titan09). They are also
> > committed to be further involved in the design of the Tinkerpop3 API
> > (i.e. the equivalent of JDBC for graph databases).
> > 
> > Once Titan 1.0 is out they plan to "let the community take over" and don't
> > plan any further work on it.
> > 
> > After that, they're shifting focus on DSE Graph - a proprietary graph
> > database that will be integrated into DSE - their proprietary offering
> > expanding on Cassandra's capabilities. This is not going to be open
> > source but will support the Tinkerpop3 API as its primary interface.
> > 
> > So there are 2 outcomes for us from this IMHO.
> > 
> > First, if we are to stick with a graph database as the storage platform
> > (which I think makes sense), we should adopt Tinkerpop. We currently
> > support Tinkerpop2 which is radically different from Tinkerpop3 but the
> > contact surface between us and their API is quite small (at least at the
> > moment) and in an area that actually didn't change that much (the Gremlin
> > graph traversal DSL).
> > 
> > Second, given the unique advantage of the shared storage for metrics and
> > inventory, we should stick with Titan (perf benchmarks still pending) for
> > now and see how it will evolve post 1.0. If it dies slowly and we hit
> > issues that we would not be able to solve ourselves, we can choose
> > another database implementing Tinkerpop3. At the moment the only other
> > choice is Neo4j, but given the involvement of many graphdb companies in
> > the design of the Tinkerpop3 API
> > (http://www.tinkerpop.com/docs/3.0.0.M7/#tinkerpop-contributors), I am
> > quite confident that there are going to be more choices in due time.
> > 
> > As a side note, our inventory API is not tied to the Tinkerpop API in any
> > way. It's just that the graph API naturally fits for implementing the
> > inventory API and in fact, the impl is quite compact. But should we, due
> > to some cataclysmic findings, choose to abandon tinkerpop API altogether,
> > then only a fraction of the inventory codebase would be affected - the
> > REST API, UI and all the other future integration code would be
> > unaffected by that departure.
> > 
> > WDYT?
> > 
> > Lukas
> > 
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev


From theute at redhat.com  Thu Mar 12 08:34:08 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 Mar 2015 13:34:08 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
Message-ID: <550187C0.2020806@redhat.com>

IMO for requirements:
     - Easy to install on a single host...
         - Download a package (from the server, so that it can be 
preconfigured, so that the server always deliver something compatible 
with itself ?), run it with no other dependency but Java (assuming this 
is Java based), have an interactive questionnaire if needed.
     - Easy to install on multiple hosts...
         - Configuration can be passed in CLI, RPM ?
     - Auto-upgradable (getting updates from the hawkular server) 
(Without data loss)
     - (Interactive) shell to troubleshoot/configure
     - Multi-OS support
     - "low" footprint

If we have that, the rest of the requirements are a bit less of an issue 
IMO as we can upgrade/reconfigure...

Then:
     - Auto-discovery capability (This is a very high added value)
     - Collect and report host data:
         - CPU usage/Memory usage/Disk usage metrics
         - OS / Kernel version / CPU&cores / Disks / Memory

For the servers monitoring, I am still unclear if it would be better to:
     - collect by the agent (like JON 3)
     - collect by the monitored server, such an EAP modules (needs the 
server to come with the piece of agent + configuration *or* be 
provisioned by the server or the agent...) talking straight to the server.
     - collect by the monitored server through the agent.
     - a mix depending on server capabilities...

We may not need to look into pluggable plugins right now. I'd rather 
have a solid monolithic solution that we can split apart if/when needed. 
Since the UI is made to be much more focused on the scenarios we want to 
support, it reduces the need for plug-able plugins IMO, of course this 
limits the project to what we can do out of the box and is not ideal, 
but shouldn't prevent someone to contribute extensions and the UI for it 
as part of the solution. (From a user point of view, he should be able 
to configure what he wants to collect or not unless this is dictated by 
the server)

 From a release perspective, we need to be able to release the agent 
much more often than the server.

The dev team has much more experience with agent possible issues than me :)

PS: we should also "discover" kubernetes/docker and what they contain.

Thomas



On 03/11/2015 06:57 PM, John Mazzitelli wrote:
> I was going to wait to post this, but since it was brought up already, might as well start this thread now.
>
> Regardless of how the agent is to be implemented, we need to answer the question "WHAT will the agent DO?" It is an existential question - kind of like asking "What is the purpose to my life?" :)
>
> So, what do we plan on having the agent do? What is its scope?
>
> How much knowledge of the inventory does the agent need to know? How does it gain this knowledge of its inventory?
>
> Does the agent auto-discover resources? How?
>
> Can the agent be told about resources that it cannot auto-discover?
>
> Does the agent need to be pluggable so it can load and interface with plugins to handle monitoring of different resources? What are these plugins?
>
> Additionally, we can add (in Juca's words):
>
>> What is the scope of the agent? Will it gather only data about the
>> environment, like, memory consumption, span of worker threads, CPU
>> consumption, GC-time, ...? Or business metrics as well, like "requests
>> per second", "number of exceptions in the last X minutes", "average
>> time spent on database", and so on?
>>
>> Also, is the same agent also responsible for capturing non-JVM related
>> data, like, disk space utilization, network traffic, ...?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From theute at redhat.com  Thu Mar 12 08:46:43 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 Mar 2015 13:46:43 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <55007CDA.5060204@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<55007CDA.5060204@redhat.com>
Message-ID: <55018AB3.2020105@redhat.com>


On 03/11/2015 06:35 PM, Matt Wringe wrote:
> In LiveOak for the OpenShift cartridge, we had the system generate an
> initial default password. So on first login you would have to know the
> randomized initial password, and also be forced to set a new password on
> the first login. It wasn't too bad on OpenShift since the password was
> set it to the Mongodb cartridge's password which was visible in the
> OpenShift console. It solved the problem of first-to-access-hijacking
> (which in my opinion is a bad situation, things should be secure by
> default).
>
> We could have something setup so that when the server is first started
> we look for a property to use for the initial credentials (eg
> -Dhawkular.initial.password=foo). If that property is not set, then
> generate a password and display it in the logs or in a file somewhere.
> When the user would login for the first time, they would need to enter
> this password and then be forced to set a real password. If they don't
> set the property it could be a bit annoying as they might have to ssh
> into a machine to read the file/logs to get the initial password.

I thought of that password generation, but finding the password seems 
like a steep barrier. With docker/VM, it's even worse IMO.

Thomas

>
>
> On 11/03/15 12:55 PM, Thomas Heute wrote:
>> Not sure to understand the alternatives but I have comments:
>>        - Having 'admin' or 'root' for a super user IMO simplifies
>> documentation/usage. (I can imagine that a user could forget what
>> username he chose as superadmin for instance).
>>        - We need to force "complex passwords", this is actually a product
>> requirement
>>        - Copying a file is a step that needs to be documented and is
>> unfriendly + either you need to encode the password (some tool like for
>> Wildfly) or worse have the password in clear in a file for import.
>>
>> So I am a +1 on setting up the superuser password on first request as
>> default. An alternative with a preset file (if present) would be welcome
>> for those who are afraid of first request hijacking.
>>
>> Thomas
>>
>>
>>
>>
>> On 03/11/2015 05:26 PM, Juraci Paix?o Kr?hling wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> All,
>>>
>>> Alexandre (and others) asked about the possibility of adding a default
>>> user on Keycloak for the Hawkular realm.
>>>
>>> While adding a default user with the requirement of changing the
>>> password on the first login is a possibility, I'd rather have an
>>> alternative realm file to import during first boot.
>>>
>>> This means: a dev (or user) have to actively copy this JSON file into
>>> standalone/configuration in order to have a default user.
>>>
>>> The idea is that we wouldn't ship with a default username/password on
>>> the main distribution. Having a default username is usually not
>>> recommended from the security perspective, as it's half of the
>>> information required to login with super power rights (and you would
>>> be surprised to know how many admins set their passwords to "admin").
>>>
>>> Given these two alternatives, which one would you prefer? Voting is
>>> open and I'll take the results on Monday 9am CET (08:00 UTC).
>>>
>>> [ ] Default user on the main realm JSON file that will ship with Kettle
>>> [ ] Alternate JSON realm file with a default user, which can be copied
>>> over the default JSON realm file.
>>>
>>> - - Juca.
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
>>> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
>>> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
>>> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
>>> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
>>> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
>>> =G8QS
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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


From hrupp at redhat.com  Thu Mar 12 09:20:17 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 12 Mar 2015 14:20:17 +0100
Subject: [Hawkular-dev] agent implementation
In-Reply-To: <55006D13.6080802@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<55006D13.6080802@redhat.com>
Message-ID: <2154D514-7D57-48EA-A2C3-ADB34B57F759@redhat.com>

Hey,

> What is the scope of the agent? Will it gather only data about the
> environment, like, memory consumption, span of worker threads, CPU
> consumption, GC-time, ...? Or business metrics as well, like "requests
> per second", "number of exceptions in the last X minutes", "average
> time spent on database", and so on?

There is no "one size fits all" answer, as we will most likely see more 
than one kind of "agent" in the future. Those are currently called 
feeds.
Like e.g. the wildfly-monitor being an agent inside a Wildfly instance.

The above mentioned agent probably corresponds best to the "platform 
agent" in RHQ, which gathers
data about the environment, most probably acts as a proxy for e.g. such 
WildFly monitor feeds, that can just connect to the local agent to 
deliver their data, which will reduce configuration complexity.

And then probably plugins for resource specific metrics.

> Also, is the same agent also responsible for capturing non-JVM related
> data, like, disk space utilization, network traffic, ...?

Isn't this sort of what you describe above as environment?

Some major differences between RHQ and Hawkular will most probably be 
that in the past we had a very generic framework and then a plugin 
descriptor hard-coding metadata. One platform agent was the only source 
of data for a certain resource. Those traits made it extremely hard to 
e.g. easily take arbitrary MBeans into inventory, because not 
ResourceType for that was defined. Or having servers that report their 
data over the REST-Interface only.

In Hawkular, we need to make sure that it gets easy to import Resources 
like said MBeans. Or "arbitrary" SNMP-MIB subtrees - Requiring a 
hard-coded (=at compile time) plugin descriptor is no longer an option 
(but such a descriptor could be used as a baseline).
Similarly it must be possible to incorporate feeds that are not tied to 
the (platform) agent. And / or cooperation, where a n agent inside a 
process reports data to the server and the (platform) agent provides 
additional information (e.g. paging info or network stats for an EAP 
with the WildFly-monitor). It may even be possible that this information 
is overriding other information (e.g. WildFly-monitor is not able to 
communicate with the Hawkular-server due to high load, so it is 
degraded, but the platform agent could still see the process as running. 
So the availability of the process would be "up" despite the 
WildFly-monitor not sending availability information).



From mwringe at redhat.com  Thu Mar 12 09:35:22 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 12 Mar 2015 09:35:22 -0400
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <55018AB3.2020105@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<55007CDA.5060204@redhat.com> <55018AB3.2020105@redhat.com>
Message-ID: <5501961A.8010503@redhat.com>



On 12/03/15 08:46 AM, Thomas Heute wrote:
>
> On 03/11/2015 06:35 PM, Matt Wringe wrote:
>> In LiveOak for the OpenShift cartridge, we had the system generate an
>> initial default password. So on first login you would have to know the
>> randomized initial password, and also be forced to set a new password on
>> the first login. It wasn't too bad on OpenShift since the password was
>> set it to the Mongodb cartridge's password which was visible in the
>> OpenShift console. It solved the problem of first-to-access-hijacking
>> (which in my opinion is a bad situation, things should be secure by
>> default).
>>
>> We could have something setup so that when the server is first started
>> we look for a property to use for the initial credentials (eg
>> -Dhawkular.initial.password=foo). If that property is not set, then
>> generate a password and display it in the logs or in a file somewhere.
>> When the user would login for the first time, they would need to enter
>> this password and then be forced to set a real password. If they don't
>> set the property it could be a bit annoying as they might have to ssh
>> into a machine to read the file/logs to get the initial password.
>
> I thought of that password generation, but finding the password seems 
> like a steep barrier. With docker/VM, it's even worse IMO.

If we were to set it as an environment variable, then its really not 
that bad on docker. You just need to run inspect on your container and 
it will show up. But ideally you would set the password as an option 
when starting your docker image so you don't need to look it up :)

For OpenShift, I would assume they would do something similar to what 
they had before with the password showing up somewhere in the console. 
So I think randomized passwords are probably something we will want to 
support for this.

But, yeah, its a bit of a pain to have to go searching for your password 
somewhere in certain situations. And its a bit strange to have to set 
one password and then immediately set another when you go to login.

I think the user configuration file is probably a more clean and better 
solution (and also matches what users are used to for other application 
servers). So +1 for a user configuration file (assuming in production 
the user file has to be created by the admin so that we don't have the 
first-to-access-wins situation).

>
> Thomas
>
>>
>>
>> On 11/03/15 12:55 PM, Thomas Heute wrote:
>>> Not sure to understand the alternatives but I have comments:
>>>        - Having 'admin' or 'root' for a super user IMO simplifies
>>> documentation/usage. (I can imagine that a user could forget what
>>> username he chose as superadmin for instance).
>>>        - We need to force "complex passwords", this is actually a 
>>> product
>>> requirement
>>>        - Copying a file is a step that needs to be documented and is
>>> unfriendly + either you need to encode the password (some tool like for
>>> Wildfly) or worse have the password in clear in a file for import.
>>>
>>> So I am a +1 on setting up the superuser password on first request as
>>> default. An alternative with a preset file (if present) would be 
>>> welcome
>>> for those who are afraid of first request hijacking.
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>> On 03/11/2015 05:26 PM, Juraci Paix?o Kr?hling wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> All,
>>>>
>>>> Alexandre (and others) asked about the possibility of adding a default
>>>> user on Keycloak for the Hawkular realm.
>>>>
>>>> While adding a default user with the requirement of changing the
>>>> password on the first login is a possibility, I'd rather have an
>>>> alternative realm file to import during first boot.
>>>>
>>>> This means: a dev (or user) have to actively copy this JSON file into
>>>> standalone/configuration in order to have a default user.
>>>>
>>>> The idea is that we wouldn't ship with a default username/password on
>>>> the main distribution. Having a default username is usually not
>>>> recommended from the security perspective, as it's half of the
>>>> information required to login with super power rights (and you would
>>>> be surprised to know how many admins set their passwords to "admin").
>>>>
>>>> Given these two alternatives, which one would you prefer? Voting is
>>>> open and I'll take the results on Monday 9am CET (08:00 UTC).
>>>>
>>>> [ ] Default user on the main realm JSON file that will ship with 
>>>> Kettle
>>>> [ ] Alternate JSON realm file with a default user, which can be copied
>>>> over the default JSON realm file.
>>>>
>>>> - - Juca.
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
>>>> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
>>>> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
>>>> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
>>>> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
>>>> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
>>>> =G8QS
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> 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
>


From lkrejci at redhat.com  Thu Mar 12 09:38:30 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 12 Mar 2015 14:38:30 +0100
Subject: [Hawkular-dev] Inventory to break its REST API
Message-ID: <3624121.hfUBEtuvOc@localhost.localdomain>

Hi,

the time has come to merge the "future" branch of inventory to its master so 
that we don't prolong the schizophrenic situation of the component. 

Because that merge will break the REST API, we need to sort out the recent 
discussion about how to handle the breaking changes in the builds.

There were 2 proposals:

[ ] adopt 0.x.y versioning or some such so that we can actually increase a 
version with breaking changes *, or
[ ] release timed snapshots and depend on them rather then simple -SNAPSHOT.

Please vote or propose other solutions so that we can move forward and not 
piss off whole nations..

Cheers,

Lukas

* semver allows 0.x to do breaking changes without increasing the major 
version, because leading zero means "before the first stable release"

From jpkroehling at redhat.com  Thu Mar 12 09:48:55 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 12 Mar 2015 14:48:55 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5501961A.8010503@redhat.com>
References: <55006CB6.1020503@redhat.com>
	<5500737F.2090901@redhat.com>	<55007CDA.5060204@redhat.com>
	<55018AB3.2020105@redhat.com> <5501961A.8010503@redhat.com>
Message-ID: <55019947.1020208@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/2015 02:35 PM, Matt Wringe wrote:
> I think the user configuration file is probably a more clean and
> better solution (and also matches what users are used to for other
> application servers). So +1 for a user configuration file (assuming
> in production the user file has to be created by the admin so that
> we don't have the first-to-access-wins situation).

Note that we don't actually *need* a default user, so, this poll is
about deciding on whether or not to include one. So far, I take it
that most prefer to have a default user for the dev profile.

Your suggestions are actually really good, and I might end up using an
approach similar to that in another part: the default Keycloak admin
password. Our window of attack for the default Keycloak admin's
credentials is far bigger than Keycloak itself: while Keycloak folks
expect admins to install and configure it right away, we don't expect
"admins" to open Keycloak as soon as they install Hawkular. So, the
default username/password for Keycloak might live for hours/days
before the admin realizes that it needs to be changed.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAZlGAAoJECKM1e+fkPrXRvEIAIOw0zdUuDtg8/DaVVg+o7U8
AAdbbZOOpstYZ2kq4m//Dx9xV89RkBYJYLgjeZcsJ+vYl1ZoU2M+8cqnVodXi8hU
r/quHqiNI5nZdvBN4lYLpXyWh08ljlcMmrCjNBSFvSFpk9l11QavtrXA1mr0t+N9
DYcleENnhs3IlHoX+bR5PtHvhd/+Plln2I4sIFB6EDZvjApvnCXDQjtWcI1gQa+S
zT0tF543BRCtbLiJ5ealmdL13Goid3srsueWt4e69KEvpuT2oL5dHtlWY2KR+c4m
ozIFB8FppN+o3lFe1ZNmJxQKZVYbdC/L4o3FvNL6udHsTaBVYLcNDVWovf/hH2Q=
=QSWJ
-----END PGP SIGNATURE-----

From snegrea at redhat.com  Thu Mar 12 12:31:22 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 12 Mar 2015 12:31:22 -0400 (EDT)
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <3624121.hfUBEtuvOc@localhost.localdomain>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
Message-ID: <1574666790.3611418.1426177882959.JavaMail.zimbra@redhat.com>

Hello,

It is not so much of a vote but an example of what Hawkular Metrics has been doing. The project has been released on 0.x.y version under RHQ Metrics name and will continue to get released under the same version scheme under the Hawkular organization. But Metrics is a little bit atypical because we had official releases along the way and will keep releasing. If you plan on getting community releases then it might be a good idea to use 0.x.y until the API is stable and the project matures.


Thank you,
Stefan

----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Thursday, March 12, 2015 8:38:30 AM
> Subject: [Hawkular-dev] Inventory to break its REST API
> 
> Hi,
> 
> the time has come to merge the "future" branch of inventory to its master so
> that we don't prolong the schizophrenic situation of the component.
> 
> Because that merge will break the REST API, we need to sort out the recent
> discussion about how to handle the breaking changes in the builds.
> 
> There were 2 proposals:
> 
> [ ] adopt 0.x.y versioning or some such so that we can actually increase a
> version with breaking changes *, or
> [ ] release timed snapshots and depend on them rather then simple -SNAPSHOT.
> 
> Please vote or propose other solutions so that we can move forward and not
> piss off whole nations..
> 
> Cheers,
> 
> Lukas
> 
> * semver allows 0.x to do breaking changes without increasing the major
> version, because leading zero means "before the first stable release"
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Thu Mar 12 13:08:03 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 12 Mar 2015 18:08:03 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
Message-ID: <0E9DABBF-0440-4DAE-8373-9F1EA1484F54@redhat.com>

On 11 Mar 2015, at 18:29, Alexandre Mendonca wrote:

> The alternative of a file to be copied over would be used mostly for 
> development, where after building we would copy it over so that after 
> each rebuild it's not needed to go through the registrations process.

Can we make sure that docker images get a sensible default that does not 
requiring ssh-ing into the container and manually copying things around?

From ppalaga at redhat.com  Thu Mar 12 13:19:22 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 12 Mar 2015 18:19:22 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <0E9DABBF-0440-4DAE-8373-9F1EA1484F54@redhat.com>
References: <55006CB6.1020503@redhat.com>
	<5500737F.2090901@redhat.com>	<1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
	<0E9DABBF-0440-4DAE-8373-9F1EA1484F54@redhat.com>
Message-ID: <5501CA9A.5090904@redhat.com>

Hi *, inline...

On 03/12/2015 06:08 PM, Heiko W.Rupp wrote:
> On 11 Mar 2015, at 18:29, Alexandre Mendonca wrote:
>
>> The alternative of a file to be copied over would be used mostly
>> for development, where after building we would copy it over so that
>> after each rebuild it's not needed to go through the registrations
>> process.
>
> Can we make sure that docker images get a sensible default that does
> not requiring ssh-ing into the container and manually copying things
> around?

Cite from OpenShift docs, Best Practices for writing images:

> It is best to avoid setting default passwords. Many people will
> extend the image and forget to remove or change the default password.
> This can lead to security issues if a user in production is assigned
> a well-known password. Passwords should be configurable using an
> environment variable instead. See the Using Environment Variables for
> Configuration topic for more information.

http://docs.openshift.org/latest/image_writers_guide/guidelines.html
-- P




> _______________________________________________ hawkular-dev mailing
> list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Thu Mar 12 14:04:19 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 12 Mar 2015 19:04:19 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5501CA9A.5090904@redhat.com>
References: <55006CB6.1020503@redhat.com>	<5500737F.2090901@redhat.com>	<1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>	<0E9DABBF-0440-4DAE-8373-9F1EA1484F54@redhat.com>
	<5501CA9A.5090904@redhat.com>
Message-ID: <5501D523.9060704@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, I'm more and more convinced that we should provide a default user
*only* when building from the developer profile :-)

- - Juca.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAdUjAAoJECKM1e+fkPrXN9AH/1m7hKvwpf3XasljPu4UQcDM
4bjWyk8S383bXt5d9g0oO/WhmOZx4fk5ZbP4XeslEpTVQbv58JJj1Nfm9cpUfkn7
lcjpiTwJx0GL/dBiS5iDrs5oqUSc/oYXgeBUkujGzDgYeQJ8F7pBY1iGiM1gMAuD
3Vslf3IajU5Z0givpoIZTt9iZkIN/UxCRCVkzrUX5njR1eoIt37TY5rvm33SNXTo
BxZaGUGOj0xOUo/AvsEN47g/2jU/FMcRuUKHyo7BNF1RaczcPacz687MyZPfvZ94
ZrgCWaXKbEzprMlKyyjScLn61VINp5NPMivcbbi5iKJn59RIDti0jknF0r8MXhE=
=Xo8Y
-----END PGP SIGNATURE-----

From mazz at redhat.com  Thu Mar 12 14:34:31 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 12 Mar 2015 14:34:31 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
Message-ID: <1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>

So what I heard today was we don't want a standalone agent, but we do want something that can be embedded in Wildfly/EAP so it can monitor things running in Wildfly (not just monitor Wildfly itself, but applications running inside wildfly).

That lends itself to supporting customizable modules that can be deployed in Wildfly/EAP as hawkular subsystems.

Can someone give me a quick summary of what Wildfly-Monitor does? https://github.com/hawkular/wildfly-monitor

From theute at redhat.com  Thu Mar 12 14:50:09 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 Mar 2015 19:50:09 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
Message-ID: <5501DFE1.7020601@redhat.com>

We still need:
     - something to monitor the platform, the container... (what is it 
if not a "standalone agent" ?)
     - monitoring non-WF/EAP based servers: Fuse, AMQ... (vert.x...)

Thomas


On 03/12/2015 07:34 PM, John Mazzitelli wrote:
> So what I heard today was we don't want a standalone agent, but we do want something that can be embedded in Wildfly/EAP so it can monitor things running in Wildfly (not just monitor Wildfly itself, but applications running inside wildfly).
>
> That lends itself to supporting customizable modules that can be deployed in Wildfly/EAP as hawkular subsystems.
>
> Can someone give me a quick summary of what Wildfly-Monitor does? https://github.com/hawkular/wildfly-monitor
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From brmeyer at redhat.com  Thu Mar 12 15:39:03 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 12 Mar 2015 15:39:03 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <1322582692.28649791.1426168710440.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
	<514409150.3628108.1426156906198.JavaMail.zimbra@redhat.com>
	<1322582692.28649791.1426168710440.JavaMail.zimbra@redhat.com>
Message-ID: <916845764.5033116.1426189143260.JavaMail.zimbra@redhat.com>

> Congratulations! I especially like the introduction chapter on the docs, now
> I finally have an idea of what you're working on ;-)

Thanks much!  Definitely up for suggestions on how to better introduce the capabilities.  The docs were a first step.  We've also started a series of end-to-end use case demos (see [1] as an example).  The website still needs work...

[1] https://developer.jboss.org/en/artificer/blog/2015/03/10/artificer-end-to-end-use-case-impact-analysis-with-xsds-wsdls-and-large-development-teams

> 
> Could this be suitable to build a repostory of JBoss Modules, so that - for
> example - WildFly could download components on demand?

It's already suitable to store *any* type of artifact, including built binaries/modules.  With adequate metadata, it certainly could be used to manage and serve-up Wildfly modules -- just a matter of lining-up the interfaces.

> 
> Sanne
> 
> ----- Original Message -----
> > Great news. Congrats, Brett!
> > 
> > ----- Original Message -----
> > > From: "Brett Meyer" <brmeyer at redhat.com>
> > > To: "The Core" <thecore at redhat.com>, hawkular-dev at lists.jboss.org,
> > > sme-integration at redhat.com
> > > Sent: Wednesday, 11 March, 2015 8:01:12 PM
> > > Subject: Artificer 1.0.0.Alpha1 release
> > > 
> > > Excited to announce Artificer 1.0.0.Alpha1!  Details:
> > > https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> > > 
> > > 
> > 
> > 
> 

From hrupp at redhat.com  Thu Mar 12 15:57:21 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 12 Mar 2015 20:57:21 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
Message-ID: <96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>

On 12 Mar 2015, at 19:34, John Mazzitelli wrote:

>
> Can someone give me a quick summary of what Wildfly-Monitor does? 
> https://github.com/hawkular/wildfly-monitor

http://pilhuhn.blogspot.de/2014/10/wildfly-subsystem-for-rhq-metrics_10.html

The current one is an improved version where Heiko Braun and Harald Pehl
have contributed some local scheduling and other stuff.
I think this needs some more love to get it into a state where it can be 
used with
Hawkular.

From jdoyle at redhat.com  Thu Mar 12 16:12:07 2015
From: jdoyle at redhat.com (John Doyle)
Date: Thu, 12 Mar 2015 16:12:07 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
Message-ID: <1060929678.4050154.1426191127417.JavaMail.zimbra@redhat.com>

Congratulations Brett!

----- Original Message -----
> Excited to announce Artificer 1.0.0.Alpha1!  Details:
> https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Thu Mar 12 16:15:06 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 12 Mar 2015 21:15:06 +0100
Subject: [Hawkular-dev] Onward to Alpha2 - not Alpha1
Message-ID: <33BB63BC-B461-4EFB-9DC0-6099BBF6C83D@redhat.com>

Hey,


we are

so we will not release an explicit Alpha1, but directly work on the Alpha2
requirements of the MVP. On top of that we also need to work on the 
Openshift integration.

  Heiko


From lkrejci at redhat.com  Thu Mar 12 16:56:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 12 Mar 2015 21:56:48 +0100
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <1574666790.3611418.1426177882959.JavaMail.zimbra@redhat.com>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
	<1574666790.3611418.1426177882959.JavaMail.zimbra@redhat.com>
Message-ID: <16810510.jl8rQis5B0@localhost.localdomain>

On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
> Hello,
> 
> It is not so much of a vote but an example of what Hawkular Metrics has been
> doing. The project has been released on 0.x.y version under RHQ Metrics
> name and will continue to get released under the same version scheme under
> the Hawkular organization. But Metrics is a little bit atypical because we
> had official releases along the way and will keep releasing. If you plan on
> getting community releases then it might be a good idea to use 0.x.y until
> the API is stable and the project matures.
> 

I think it is a reasonable thing to do also in a multi-module project. The 
releases don't even need to be "official" - it's just an acknowledgment of 
progress with the realization that the rest of the modules might not have 
adapted to that progress yet.

IMHO, going 0.x.y makes most sense for all components, not just metrics. This 
is supported by looking for example at Artificer, that had a great number of 
0.x releases (called S-RAMP then) before it reached today's 1.0.0.Alpha1. That 
milestone is significant and means that it has all the features deemed for 
1.0.0 and is ready for stabilization phase. All Hawk components are far from 
that stage.

> 
> Thank you,
> Stefan
> 
> ----- Original Message -----
> 
> > From: "Lukas Krejci" <lkrejci at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Thursday, March 12, 2015 8:38:30 AM
> > Subject: [Hawkular-dev] Inventory to break its REST API
> > 
> > Hi,
> > 
> > the time has come to merge the "future" branch of inventory to its master
> > so that we don't prolong the schizophrenic situation of the component.
> > 
> > Because that merge will break the REST API, we need to sort out the recent
> > discussion about how to handle the breaking changes in the builds.
> > 
> > There were 2 proposals:
> > 
> > [ ] adopt 0.x.y versioning or some such so that we can actually increase a
> > version with breaking changes *, or
> > [ ] release timed snapshots and depend on them rather then simple
> > -SNAPSHOT.
> > 
> > Please vote or propose other solutions so that we can move forward and not
> > piss off whole nations..
> > 
> > Cheers,
> > 
> > Lukas
> > 
> > * semver allows 0.x to do breaking changes without increasing the major
> > version, because leading zero means "before the first stable release"
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Thu Mar 12 17:28:09 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 12 Mar 2015 22:28:09 +0100
Subject: [Hawkular-dev] Default user, or alternative realm file?
In-Reply-To: <5501CA9A.5090904@redhat.com>
References: <55006CB6.1020503@redhat.com> <5500737F.2090901@redhat.com>
	<1032337417.2979998.1426094945296.JavaMail.zimbra@redhat.com>
	<0E9DABBF-0440-4DAE-8373-9F1EA1484F54@redhat.com>
	<5501CA9A.5090904@redhat.com>
Message-ID: <88A8BA86-70BB-4226-AE75-B53057AAD310@redhat.com>

Hi,

I guess my wording was bad.

On 12 Mar 2015, at 18:19, Peter Palaga wrote:

> Hi *, inline...
>
> On 03/12/2015 06:08 PM, Heiko W.Rupp wrote:
>> Can we make sure that docker images get a sensible default that does
>> not requiring ssh-ing into the container and manually copying things

>> a well-known password. Passwords should be configurable using an
>> environment variable instead. See the Using Environment Variables

This satisfies my request.

$ docker run -e password=bla hawkular/hawkular

is perfectly fine.

$ docker run -d -p 22:22 hawkular/hawkular
$ ssh <dockerip:22> cp /some/odd/path/pw.json 
/some/other/longer/path/realm.json

is not.

From mithomps at redhat.com  Thu Mar 12 19:05:27 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 12 Mar 2015 16:05:27 -0700
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <16810510.jl8rQis5B0@localhost.localdomain>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
	<1574666790.3611418.1426177882959.JavaMail.zimbra@redhat.com>
	<16810510.jl8rQis5B0@localhost.localdomain>
Message-ID: <6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>


> On 12 Mar 2015, at 13:56, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
>> Hello,
>> 
>> It is not so much of a vote but an example of what Hawkular Metrics has been
>> doing. The project has been released on 0.x.y version under RHQ Metrics
>> name and will continue to get released under the same version scheme under
>> the Hawkular organization. But Metrics is a little bit atypical because we
>> had official releases along the way and will keep releasing. If you plan on
>> getting community releases then it might be a good idea to use 0.x.y until
>> the API is stable and the project matures.
>> 
> 
> I think it is a reasonable thing to do also in a multi-module project. The 
> releases don't even need to be "official" - it's just an acknowledgment of 
> progress with the realization that the rest of the modules might not have 
> adapted to that progress yet.
> 
> IMHO, going 0.x.y makes most sense for all components, not just metrics. This 
> is supported by looking for example at Artificer, that had a great number of 
> 0.x releases (called S-RAMP then) before it reached today's 1.0.0.Alpha1. That 
> milestone is significant and means that it has all the features deemed for 
> 1.0.0 and is ready for stabilization phase. All Hawk components are far from 
> that stage.
> 
>> 
>> Thank you,
>> Stefan
>> 
>> ----- Original Message -----
>> 
>>> From: "Lukas Krejci" <lkrejci at redhat.com>
>>> To: hawkular-dev at lists.jboss.org
>>> Sent: Thursday, March 12, 2015 8:38:30 AM
>>> Subject: [Hawkular-dev] Inventory to break its REST API
>>> 
>>> Hi,
>>> 
>>> the time has come to merge the "future" branch of inventory to its master
>>> so that we don't prolong the schizophrenic situation of the component.
>>> 
>>> Because that merge will break the REST API, we need to sort out the recent
>>> discussion about how to handle the breaking changes in the builds.

Hopefully the merge will not happen in the next two weeks while we are trying to deliver our alpha 2 MVP?
There really is no time in the schedule to for changes this large and close to a deadline.


>>> 
>>> There were 2 proposals:
>>> 
>>> [ ] adopt 0.x.y versioning or some such so that we can actually increase a
>>> version with breaking changes *, or
>>> [ ] release timed snapshots and depend on them rather then simple
>>> -SNAPSHOT.
>>> 
>>> Please vote or propose other solutions so that we can move forward and not
>>> piss off whole nations..
>>> 
>>> Cheers,
>>> 
>>> Lukas
>>> 
>>> * semver allows 0.x to do breaking changes without increasing the major
>>> version, because leading zero means "before the first stable release"
>>> _______________________________________________
>>> 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



From lkrejci at redhat.com  Thu Mar 12 19:18:44 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 13 Mar 2015 00:18:44 +0100
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
	<16810510.jl8rQis5B0@localhost.localdomain>
	<6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>
Message-ID: <1571935.FfLB5MIgja@localhost.localdomain>

On Thursday, March 12, 2015 16:05:27 mike thompson wrote:
> > On 12 Mar 2015, at 13:56, Lukas Krejci <lkrejci at redhat.com> wrote:
> > 
> > On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
> >> Hello,
> >> 
> >> It is not so much of a vote but an example of what Hawkular Metrics has
> >> been doing. The project has been released on 0.x.y version under RHQ
> >> Metrics name and will continue to get released under the same version
> >> scheme under the Hawkular organization. But Metrics is a little bit
> >> atypical because we had official releases along the way and will keep
> >> releasing. If you plan on getting community releases then it might be a
> >> good idea to use 0.x.y until the API is stable and the project matures.
> > 
> > I think it is a reasonable thing to do also in a multi-module project. The
> > releases don't even need to be "official" - it's just an acknowledgment of
> > progress with the realization that the rest of the modules might not have
> > adapted to that progress yet.
> > 
> > IMHO, going 0.x.y makes most sense for all components, not just metrics.
> > This is supported by looking for example at Artificer, that had a great
> > number of 0.x releases (called S-RAMP then) before it reached today's
> > 1.0.0.Alpha1. That milestone is significant and means that it has all the
> > features deemed for 1.0.0 and is ready for stabilization phase. All Hawk
> > components are far from that stage.
> > 
> >> Thank you,
> >> Stefan
> >> 
> >> ----- Original Message -----
> >> 
> >>> From: "Lukas Krejci" <lkrejci at redhat.com>
> >>> To: hawkular-dev at lists.jboss.org
> >>> Sent: Thursday, March 12, 2015 8:38:30 AM
> >>> Subject: [Hawkular-dev] Inventory to break its REST API
> >>> 
> >>> Hi,
> >>> 
> >>> the time has come to merge the "future" branch of inventory to its
> >>> master
> >>> so that we don't prolong the schizophrenic situation of the component.
> >>> 
> >>> Because that merge will break the REST API, we need to sort out the
> >>> recent
> >>> discussion about how to handle the breaking changes in the builds.
> 
> Hopefully the merge will not happen in the next two weeks while we are
> trying to deliver our alpha 2 MVP? There really is no time in the schedule
> to for changes this large and close to a deadline.

Well, actually this was my plan. We're out of master for more than a month 
with great deal of features missing on any integration opportunities with the 
rest of the components because of the simple fact that we don't want to break 
other people's work. There's always going to be an Alpha, Beta or GA coming 
and the longer we wait with integrating the bigger a "bomb" it is going to be.

If the breaking changes are released in a different version than what the MVP 
components are using, then there's really no reason to not merge.

But I was thinking that we should actually incorporate the "true" inventory 
code into MVP proper and do it now. Otherwise it will never get there, IMHO. 

If Jirka lent his skillful Angular hand would that still not be possible?

> >>> There were 2 proposals:
> >>> 
> >>> [ ] adopt 0.x.y versioning or some such so that we can actually increase
> >>> a
> >>> version with breaking changes *, or
> >>> [ ] release timed snapshots and depend on them rather then simple
> >>> -SNAPSHOT.
> >>> 
> >>> Please vote or propose other solutions so that we can move forward and
> >>> not
> >>> piss off whole nations..
> >>> 
> >>> Cheers,
> >>> 
> >>> Lukas
> >>> 
> >>> * semver allows 0.x to do breaking changes without increasing the major
> >>> version, because leading zero means "before the first stable release"
> >>> _______________________________________________
> >>> 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


From mithomps at redhat.com  Thu Mar 12 19:26:35 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 12 Mar 2015 16:26:35 -0700
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <1571935.FfLB5MIgja@localhost.localdomain>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
	<16810510.jl8rQis5B0@localhost.localdomain>
	<6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>
	<1571935.FfLB5MIgja@localhost.localdomain>
Message-ID: <F0DCE539-982A-4593-B2E3-D999484A085B@redhat.com>


> On 12 Mar 2015, at 16:18, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Thursday, March 12, 2015 16:05:27 mike thompson wrote:
>>> On 12 Mar 2015, at 13:56, Lukas Krejci <lkrejci at redhat.com> wrote:
>>> 
>>> On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
>>>> Hello,
>>>> 
>>>> It is not so much of a vote but an example of what Hawkular Metrics has
>>>> been doing. The project has been released on 0.x.y version under RHQ
>>>> Metrics name and will continue to get released under the same version
>>>> scheme under the Hawkular organization. But Metrics is a little bit
>>>> atypical because we had official releases along the way and will keep
>>>> releasing. If you plan on getting community releases then it might be a
>>>> good idea to use 0.x.y until the API is stable and the project matures.
>>> 
>>> I think it is a reasonable thing to do also in a multi-module project. The
>>> releases don't even need to be "official" - it's just an acknowledgment of
>>> progress with the realization that the rest of the modules might not have
>>> adapted to that progress yet.
>>> 
>>> IMHO, going 0.x.y makes most sense for all components, not just metrics.
>>> This is supported by looking for example at Artificer, that had a great
>>> number of 0.x releases (called S-RAMP then) before it reached today's
>>> 1.0.0.Alpha1. That milestone is significant and means that it has all the
>>> features deemed for 1.0.0 and is ready for stabilization phase. All Hawk
>>> components are far from that stage.
>>> 
>>>> Thank you,
>>>> Stefan
>>>> 
>>>> ----- Original Message -----
>>>> 
>>>>> From: "Lukas Krejci" <lkrejci at redhat.com>
>>>>> To: hawkular-dev at lists.jboss.org
>>>>> Sent: Thursday, March 12, 2015 8:38:30 AM
>>>>> Subject: [Hawkular-dev] Inventory to break its REST API
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> the time has come to merge the "future" branch of inventory to its
>>>>> master
>>>>> so that we don't prolong the schizophrenic situation of the component.
>>>>> 
>>>>> Because that merge will break the REST API, we need to sort out the
>>>>> recent
>>>>> discussion about how to handle the breaking changes in the builds.
>> 
>> Hopefully the merge will not happen in the next two weeks while we are
>> trying to deliver our alpha 2 MVP? There really is no time in the schedule
>> to for changes this large and close to a deadline.
> 
> Well, actually this was my plan. We're out of master for more than a month 
> with great deal of features missing on any integration opportunities with the 
> rest of the components because of the simple fact that we don't want to break 
> other people's work. There's always going to be an Alpha, Beta or GA coming 
> and the longer we wait with integrating the bigger a "bomb" it is going to be.
> 
> If the breaking changes are released in a different version than what the MVP 
> components are using, then there's really no reason to not merge.
> 
> But I was thinking that we should actually incorporate the "true" inventory 
> code into MVP proper and do it now. Otherwise it will never get there, IMHO. 
> 
> If Jirka lent his skillful Angular hand would that still not be possible?

If Jirka did the integration I would feel confident and it would solve the resources issue. Now, ultimately this is a Thomas/Heiko call as they are doing the demo. ;)

> 
>>>>> There were 2 proposals:
>>>>> 
>>>>> [ ] adopt 0.x.y versioning or some such so that we can actually increase
>>>>> a
>>>>> version with breaking changes *, or
>>>>> [ ] release timed snapshots and depend on them rather then simple
>>>>> -SNAPSHOT.
>>>>> 
>>>>> Please vote or propose other solutions so that we can move forward and
>>>>> not
>>>>> piss off whole nations..
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Lukas
>>>>> 
>>>>> * semver allows 0.x to do breaking changes without increasing the major
>>>>> version, because leading zero means "before the first stable release"
>>>>> _______________________________________________
>>>>> 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



From jsanda at redhat.com  Thu Mar 12 22:56:26 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 12 Mar 2015 22:56:26 -0400
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>
Message-ID: <393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>

I think we need to consider having the following types of agents

* embedded, in-process
* co-located in separate process 
* agent-less where we do management/monitoring from the server side

There are different scenarios in which each of the above have advantages. For (only) collecting metrics, an embedded collector would be best as it involves the least overhead. Based on our experience of managing Cassandra in RHQ, I think that there are a lot of situations where agent-less makes things much easier. Consider running repair. It is a cluster-wide operation. In RHQ, we go through a complex workflow of server to agent to Cassandra node to agent to server to next agent to next Cassandra node to agent to server and so on. Managing the repair directly from server to Cassandra would make things a lot easier.

With respect to monitoring, the agent, particularly one that runs co-located in a separate process, should be capable of being more than just a collector. I am seeing that more and more with other systems I am looking at. With an Open TSDB extension for example, the agent/client side piece can convert data into a blob format that is optimized for storage. This blob conversion can be done on the server side but it causes a hit on performance. I believe that the DataDog agent is capable of performing client-side aggregations, like computing percentiles. This could be efficient and useful for computing method execution times, response times, etc.

With respect to alerting, I think it is something we should consider for an agent that runs its own process. The agent could push alerts onto the bus for instance. And if we look more closely at ISPN, we could do the same with distributed caches. The agent fires an alert by putting an entry into its alert cache to which the server is subscribed for notifications. This could also be used for the agent to obtain alert definitions. Something to consider...
> On Mar 12, 2015, at 3:57 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 12 Mar 2015, at 19:34, John Mazzitelli wrote:
> 
>> 
>> Can someone give me a quick summary of what Wildfly-Monitor does? 
>> https://github.com/hawkular/wildfly-monitor
> 
> http://pilhuhn.blogspot.de/2014/10/wildfly-subsystem-for-rhq-metrics_10.html
> 
> The current one is an improved version where Heiko Braun and Harald Pehl
> have contributed some local scheduling and other stuff.
> I think this needs some more love to get it into a state where it can be 
> used with
> Hawkular.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From theute at redhat.com  Fri Mar 13 03:57:15 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Mar 2015 08:57:15 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>	<96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>
	<393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>
Message-ID: <5502985B.60805@redhat.com>


On 03/13/2015 03:56 AM, John Sanda wrote:
> I think we need to consider having the following types of agents
>
> * embedded, in-process
> * co-located in separate process
> * agent-less where we do management/monitoring from the server side
+1

But that opens a can of worms and mix of options...

For uptime/downtime for instance, the embedded in-process, can only say 
"I'm up", if not up -> it's down or unknown (network issue ?). From a 
separate process you can tell if it's down, separate process is better 
in that case (but it may not be installed, so do we fallback on embedded 
process info ?).

Agent-less works *if* the network is open enough to allow it...

Also for embedded one, we may be bound to product releases, unless we 
instrument ourself the server and update as we wish.

Thomas


>
> There are different scenarios in which each of the above have advantages. For (only) collecting metrics, an embedded collector would be best as it involves the least overhead. Based on our experience of managing Cassandra in RHQ, I think that there are a lot of situations where agent-less makes things much easier. Consider running repair. It is a cluster-wide operation. In RHQ, we go through a complex workflow of server to agent to Cassandra node to agent to server to next agent to next Cassandra node to agent to server and so on. Managing the repair directly from server to Cassandra would make things a lot easier.
>
> With respect to monitoring, the agent, particularly one that runs co-located in a separate process, should be capable of being more than just a collector. I am seeing that more and more with other systems I am looking at. With an Open TSDB extension for example, the agent/client side piece can convert data into a blob format that is optimized for storage. This blob conversion can be done on the server side but it causes a hit on performance. I believe that the DataDog agent is capable of performing client-side aggregations, like computing percentiles. This could be efficient and useful for computing method execution times, response times, etc.
>
> With respect to alerting, I think it is something we should consider for an agent that runs its own process. The agent could push alerts onto the bus for instance. And if we look more closely at ISPN, we could do the same with distributed caches. The agent fires an alert by putting an entry into its alert cache to which the server is subscribed for notifications. This could also be used for the agent to obtain alert definitions. Something to consider...
>> On Mar 12, 2015, at 3:57 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>
>> On 12 Mar 2015, at 19:34, John Mazzitelli wrote:
>>
>>> Can someone give me a quick summary of what Wildfly-Monitor does?
>>> https://github.com/hawkular/wildfly-monitor
>> http://pilhuhn.blogspot.de/2014/10/wildfly-subsystem-for-rhq-metrics_10.html
>>
>> The current one is an improved version where Heiko Braun and Harald Pehl
>> have contributed some local scheduling and other stuff.
>> I think this needs some more love to get it into a state where it can be
>> used with
>> Hawkular.
>> _______________________________________________
>> 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


From theute at redhat.com  Fri Mar 13 04:01:10 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Mar 2015 09:01:10 +0100
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <F0DCE539-982A-4593-B2E3-D999484A085B@redhat.com>
References: <3624121.hfUBEtuvOc@localhost.localdomain>	<16810510.jl8rQis5B0@localhost.localdomain>	<6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>	<1571935.FfLB5MIgja@localhost.localdomain>
	<F0DCE539-982A-4593-B2E3-D999484A085B@redhat.com>
Message-ID: <55029946.10505@redhat.com>


On 03/13/2015 12:26 AM, mike thompson wrote:
>> On 12 Mar 2015, at 16:18, Lukas Krejci <lkrejci at redhat.com> wrote:
>>
>> On Thursday, March 12, 2015 16:05:27 mike thompson wrote:
>>>> On 12 Mar 2015, at 13:56, Lukas Krejci <lkrejci at redhat.com> wrote:
>>>>
>>>> On Thursday, March 12, 2015 12:31:22 Stefan Negrea wrote:
>>>>> Hello,
>>>>>
>>>>> It is not so much of a vote but an example of what Hawkular Metrics has
>>>>> been doing. The project has been released on 0.x.y version under RHQ
>>>>> Metrics name and will continue to get released under the same version
>>>>> scheme under the Hawkular organization. But Metrics is a little bit
>>>>> atypical because we had official releases along the way and will keep
>>>>> releasing. If you plan on getting community releases then it might be a
>>>>> good idea to use 0.x.y until the API is stable and the project matures.
>>>> I think it is a reasonable thing to do also in a multi-module project. The
>>>> releases don't even need to be "official" - it's just an acknowledgment of
>>>> progress with the realization that the rest of the modules might not have
>>>> adapted to that progress yet.
>>>>
>>>> IMHO, going 0.x.y makes most sense for all components, not just metrics.
>>>> This is supported by looking for example at Artificer, that had a great
>>>> number of 0.x releases (called S-RAMP then) before it reached today's
>>>> 1.0.0.Alpha1. That milestone is significant and means that it has all the
>>>> features deemed for 1.0.0 and is ready for stabilization phase. All Hawk
>>>> components are far from that stage.
>>>>
>>>>> Thank you,
>>>>> Stefan
>>>>>
>>>>> ----- Original Message -----
>>>>>
>>>>>> From: "Lukas Krejci" <lkrejci at redhat.com>
>>>>>> To: hawkular-dev at lists.jboss.org
>>>>>> Sent: Thursday, March 12, 2015 8:38:30 AM
>>>>>> Subject: [Hawkular-dev] Inventory to break its REST API
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> the time has come to merge the "future" branch of inventory to its
>>>>>> master
>>>>>> so that we don't prolong the schizophrenic situation of the component.
>>>>>>
>>>>>> Because that merge will break the REST API, we need to sort out the
>>>>>> recent
>>>>>> discussion about how to handle the breaking changes in the builds.
>>> Hopefully the merge will not happen in the next two weeks while we are
>>> trying to deliver our alpha 2 MVP? There really is no time in the schedule
>>> to for changes this large and close to a deadline.
>> Well, actually this was my plan. We're out of master for more than a month
>> with great deal of features missing on any integration opportunities with the
>> rest of the components because of the simple fact that we don't want to break
>> other people's work. There's always going to be an Alpha, Beta or GA coming
>> and the longer we wait with integrating the bigger a "bomb" it is going to be.
>>
>> If the breaking changes are released in a different version than what the MVP
>> components are using, then there's really no reason to not merge.
>>
>> But I was thinking that we should actually incorporate the "true" inventory
>> code into MVP proper and do it now. Otherwise it will never get there, IMHO.
>>
>> If Jirka lent his skillful Angular hand would that still not be possible?
> If Jirka did the integration I would feel confident and it would solve the resources issue. Now, ultimately this is a Thomas/Heiko call as they are doing the demo. ;)

I talked to Lukas prior to the email, I would like to see it integrated, 
but said that this would have to be merged once that works and not 
affect the UI team. For the UI effort to use the new API, this should be 
purely on Lukas/Jirka.
That means Lukas and Jirka work in a branch (rebase often) until this 
works properly and then merge. (If it doesn't "work fine" on time we 
won't merge for this milestone).

Thomas

>
>>>>>> There were 2 proposals:
>>>>>>
>>>>>> [ ] adopt 0.x.y versioning or some such so that we can actually increase
>>>>>> a
>>>>>> version with breaking changes *, or
>>>>>> [ ] release timed snapshots and depend on them rather then simple
>>>>>> -SNAPSHOT.
>>>>>>
>>>>>> Please vote or propose other solutions so that we can move forward and
>>>>>> not
>>>>>> piss off whole nations..
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Lukas
>>>>>>
>>>>>> * semver allows 0.x to do breaking changes without increasing the major
>>>>>> version, because leading zero means "before the first stable release"
>>>>>> _______________________________________________
>>>>>> 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


From miburman at redhat.com  Fri Mar 13 04:28:58 2015
From: miburman at redhat.com (Michael Burman)
Date: Fri, 13 Mar 2015 10:28:58 +0200
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <5502985B.60805@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>	<96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>	<393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>
	<5502985B.60805@redhat.com>
Message-ID: <55029FCA.7090508@redhat.com>

On 13.03.2015 09:57, Thomas Heute wrote:
> For uptime/downtime for instance, the embedded in-process, can only say
> "I'm up", if not up -> it's down or unknown (network issue ?). From a
> separate process you can tell if it's down, separate process is better
> in that case (but it may not be installed, so do we fallback on embedded
> process info ?).
The network issue will affect the embedded and process agent just as 
likely, there's no difference in that case. Also, separate process can't 
really tell if something is down or not, the example mentioned here was 
that the CPU of the process is overloaded and can't report anything but 
the system agent can see the pid is up. This definitely is not the case 
usually, having a PID up doesn't mean the software is alive anymore (who 
here hasn't booted their Cassandra with kill -9 more than once?).

As an example of agent system, BMC's Control-M handles this differently 
than we're planning. While it's a job monitoring system, it has two 
statuses, agent status and job status. If the agent can not be contacted 
for certain period of time, the agent is marked down (and alerted), 
while the job itself is marked with unknown state. If the agent is up, 
but can't read the job's status, job is again marked unknown. Only if it 
really knows something has failed, the job is marked as failed.

> Agent-less works *if* the network is open enough to allow it...
>
> Also for embedded one, we may be bound to product releases, unless we
> instrument ourself the server and update as we wish.
>
I don't think the product releases are an issue, if we have working 
versioning in our APIs. We should just log the version of the agents in 
our UI. As long as the API versioning is handled correctly, we should 
able to support older versions quite fine. Sure, those services wouldn't 
get new features, but I don't think this is an issue, if the new 
features are marked as product features (eg. EAP monitoring features) 
instead of our updated features.

My wish is that we would support multiple approaches. If we have 
platform agent, it should take care of connecting to this product 
'agents' and dispatching stuff to the server, but otherwise there could 
be smaller agents doing just a simple job. It's not unheard of that some 
enterprise wants to monitor infra with different tools than what's used 
to monitor running applications, as they could be monitored by different 
departments and with different responsibilities. For containers, we'll 
probably want to do something like cAdvisor, so running a container 
monitoring other containers.

Just one wish - very low overhead agent. From my past we had a test 
machine with slightly reduced resources, yet the infra installed first 
IBM's TSM agent (Storage Manager) that had increasing memory usage based 
on how many files there were, then BMC's Patrol with plugins for TSM etc 
and of course we needed CTM agent to run our jobs. In the end the 
machine couldn't actually run any tests because it had no memory left 
for those jobs. Sounds like horror story but it's very real (in the end 
I solved the issue by killing every agent except CTM before running the 
tests and then restarting them after the tests as I knew the root 
password and infra's SLA).

   -  Micke

From sanne at redhat.com  Thu Mar 12 09:58:30 2015
From: sanne at redhat.com (Sanne Grinovero)
Date: Thu, 12 Mar 2015 09:58:30 -0400 (EDT)
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <514409150.3628108.1426156906198.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
	<514409150.3628108.1426156906198.JavaMail.zimbra@redhat.com>
Message-ID: <1322582692.28649791.1426168710440.JavaMail.zimbra@redhat.com>


Congratulations! I especially like the introduction chapter on the docs, now I finally have an idea of what you're working on ;-)

Could this be suitable to build a repostory of JBoss Modules, so that - for example - WildFly could download components on demand?

Sanne

----- Original Message -----
> Great news. Congrats, Brett!
> 
> ----- Original Message -----
> > From: "Brett Meyer" <brmeyer at redhat.com>
> > To: "The Core" <thecore at redhat.com>, hawkular-dev at lists.jboss.org,
> > sme-integration at redhat.com
> > Sent: Wednesday, 11 March, 2015 8:01:12 PM
> > Subject: Artificer 1.0.0.Alpha1 release
> > 
> > Excited to announce Artificer 1.0.0.Alpha1!  Details:
> > https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> > 
> > 
> 
> 

From mlittle at redhat.com  Fri Mar 13 04:52:43 2015
From: mlittle at redhat.com (Mark Little)
Date: Fri, 13 Mar 2015 08:52:43 +0000
Subject: [Hawkular-dev] Artificer 1.0.0.Alpha1 release
In-Reply-To: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
References: <761949864.4254627.1426100472778.JavaMail.zimbra@redhat.com>
Message-ID: <C7E63916-57C9-45C2-864F-80EA44370933@redhat.com>

Congrats on the release.

Mark.


On 11 Mar 2015, at 19:01, Brett Meyer <brmeyer at redhat.com> wrote:

> Excited to announce Artificer 1.0.0.Alpha1!  Details: https://developer.jboss.org/en/artificer/blog/2015/03/11/artificer-100alpha1-released
> 

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).







From hrupp at redhat.com  Fri Mar 13 05:34:34 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 Mar 2015 10:34:34 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <5502985B.60805@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>
	<393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>
	<5502985B.60805@redhat.com>
Message-ID: <EE83550B-0580-44E3-9BC4-E89DCA41E10E@redhat.com>

On 13 Mar 2015, at 8:57, Thomas Heute wrote:

> But that opens a can of worms and mix of options...
>
> For uptime/downtime for instance, the embedded in-process, can only 
> say
> "I'm up", if not up -> it's down or unknown (network issue ?). From a
> separate process you can tell if it's down, separate process is better
> in that case (but it may not be installed, so do we fallback on 
> embedded
> process info ?).

While this may first sound like a disadvantage, it can also be seen as 
advantage.
In RHQ when we lost the connection to the agent, all the resources 
behind it were
at backfilling considered as down.
Now when when have e.g. the pinger in a different location and this sees 
that the
application is reachable, we could "overwrite" the unavailable data from 
the agent.
(and yes, I know that the previous sentence/scenario was 
oversimplified).

Similar when the embedded agent is not able to send perhaps due to high 
usage
of the app server, the platform agent can still see if the process is up 
and report it
as up.

Or the other way around. The embedded agent sends a "UP" report every 
minute, but the
external agent can detect that the PID has changed and can either report 
a "DOWN" for the
time in between two ups (which may be too much) or at least report a 
"tag" that the server
process was rebooted, which can then later be displayed to the user in 
the charts. This
may then explain why some resource usage is higher/lower than before.

We have started this discussion (from a different angle) in two 
different places
already - the Alert on URL return code mail 
http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000402.html
and "Computed Resource State" 
http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html

The point is that the very strict 1:1 mapping that we had in RHQ is not 
enough. In scenarios like Aircraft,
they often even have a 2 of 3 voting principle.

From theute at redhat.com  Fri Mar 13 06:02:42 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Mar 2015 11:02:42 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <55029FCA.7090508@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>	<96C6FD77-0858-4F2B-8B36-13BDB32A9513@redhat.com>	<393598F8-F5EE-4DBB-ABEE-1603C80246C6@redhat.com>	<5502985B.60805@redhat.com>
	<55029FCA.7090508@redhat.com>
Message-ID: <5502B5C2.6080008@redhat.com>


On 03/13/2015 09:28 AM, Michael Burman wrote:
> On 13.03.2015 09:57, Thomas Heute wrote:
>> For uptime/downtime for instance, the embedded in-process, can only say
>> "I'm up", if not up -> it's down or unknown (network issue ?). From a
>> separate process you can tell if it's down, separate process is better
>> in that case (but it may not be installed, so do we fallback on embedded
>> process info ?).
> The network issue will affect the embedded and process agent just as
> likely, there's no difference in that case.
The difference is that:
  - if embedded, it can only say "I'm up", "I'm up', "I'm up", if you 
receive nothing you can't differentiate from being down or not receiving 
the up message
  - if non embeeded, it can say "Resource is up", "Resource is down", if 
you receive nothing you can tell that the agent is messed up, the state 
of the resource is unknown.

>   Also, separate process can't
> really tell if something is down or not, the example mentioned here was
> that the CPU of the process is overloaded and can't report anything but
> the system agent can see the pid is up. This definitely is not the case
> usually, having a PID up doesn't mean the software is alive anymore (who
> here hasn't booted their Cassandra with kill -9 more than once?).
There are various way to say if something is down, we can find many 
exceptions but let's not the exceptions state the rule.

If there is no process running an agent can tell that it is down, but 
the process can't tell itself.

> As an example of agent system, BMC's Control-M handles this differently
> than we're planning. While it's a job monitoring system, it has two
> statuses, agent status and job status. If the agent can not be contacted
> for certain period of time, the agent is marked down (and alerted),
> while the job itself is marked with unknown state. If the agent is up,
> but can't read the job's status, job is again marked unknown. Only if it
> really knows something has failed, the job is marked as failed.
So they still have an agent
>
>> Agent-less works *if* the network is open enough to allow it...
>>
>> Also for embedded one, we may be bound to product releases, unless we
>> instrument ourself the server and update as we wish.
>>
> I don't think the product releases are an issue, if we have working
> versioning in our APIs. We should just log the version of the agents in
> our UI. As long as the API versioning is handled correctly, we should
> able to support older versions quite fine. Sure, those services wouldn't
> get new features, but I don't think this is an issue, if the new
> features are marked as product features (eg. EAP monitoring features)
> instead of our updated features.
I raised it because it has been a big issue for JON updates. So if not a 
blocker it is a concern and need to be taken into account.

> My wish is that we would support multiple approaches.
We need to be careful, multiple approaches = increased QE and since this 
is not infinite this leads to decreased quality.
>   If we have
> platform agent, it should take care of connecting to this product
> 'agents' and dispatching stuff to the server, but otherwise there could
> be smaller agents doing just a simple job. It's not unheard of that some
> enterprise wants to monitor infra with different tools than what's used
> to monitor running applications, as they could be monitored by different
> departments and with different responsibilities. For containers, we'll
> probably want to do something like cAdvisor, so running a container
> monitoring other containers.
I am not sure to understand. In any case "smaller" agents need to be 
easily manageable.
> Just one wish - very low overhead agent. From my past we had a test
> machine with slightly reduced resources, yet the infra installed first
> IBM's TSM agent (Storage Manager) that had increasing memory usage based
> on how many files there were, then BMC's Patrol with plugins for TSM etc
> and of course we needed CTM agent to run our jobs. In the end the
> machine couldn't actually run any tests because it had no memory left
> for those jobs. Sounds like horror story but it's very real (in the end
> I solved the issue by killing every agent except CTM before running the
> tests and then restarting them after the tests as I knew the root
> password and infra's SLA).
I think we'll all agree on the req, but we need to agree on what that 
means for the implementation...
There will be a tradeoff to make between low overhead and some 
capabilities (like generating alerts itself)... Will likely need to be 
configurable...

Thomas
>
>     -  Micke
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jkremser at redhat.com  Fri Mar 13 08:42:04 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Fri, 13 Mar 2015 08:42:04 -0400 (EDT)
Subject: [Hawkular-dev] Inventory to break its REST API
In-Reply-To: <F0DCE539-982A-4593-B2E3-D999484A085B@redhat.com>
References: <3624121.hfUBEtuvOc@localhost.localdomain>
	<16810510.jl8rQis5B0@localhost.localdomain>
	<6DC80FF4-6AE1-4E49-8AAC-98BD0F25568D@redhat.com>
	<1571935.FfLB5MIgja@localhost.localdomain>
	<F0DCE539-982A-4593-B2E3-D999484A085B@redhat.com>
Message-ID: <529274260.3869206.1426250524611.JavaMail.zimbra@redhat.com>

> If Jirka did the integration..

I'll do my best. I'll start a new branch in ui-components and/or ui-services repos

jk

From gbrown at redhat.com  Mon Mar 16 04:13:41 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 16 Mar 2015 04:13:41 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
Message-ID: <1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>

This embedded 'agent' would also be useful for collecting the activity information for RTGov. I assume information will be routed depending on type at the backend?

Regards
Gary

----- Original Message -----
> So what I heard today was we don't want a standalone agent, but we do want
> something that can be embedded in Wildfly/EAP so it can monitor things
> running in Wildfly (not just monitor Wildfly itself, but applications
> running inside wildfly).
> 
> That lends itself to supporting customizable modules that can be deployed in
> Wildfly/EAP as hawkular subsystems.
> 
> Can someone give me a quick summary of what Wildfly-Monitor does?
> https://github.com/hawkular/wildfly-monitor
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Mon Mar 16 10:02:48 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 16 Mar 2015 15:02:48 +0100
Subject: [Hawkular-dev] Stuff to share? Blog about it
Message-ID: <845A6239-9EBA-4270-9D7B-4A31EF75C915@redhat.com>

Hey,

if you have stuff to share like
- a new release of metrics
- a new subsystem / component
- some cool way of doing stuff
- clever way to test the combination of collected, ptrans and 
hawkular-metrics?

Then please write a blog entry for hawkular.org

You do that by adding a new adoc file with your blog content to
https://github.com/hawkular/hawkular.github.io/tree/pages/src/main/jbake/content/blog/2015

After this is merged in master, it will become live on 
http://www.hawkular.org/blog.html

The blog post itself should have headers like this:

= The Kettle starts boiling   (1)
Heiko W. Rupp           (2)
2015-02-24         (3)
:jbake-type: post    (4)
:jbake-status: published   (5)
:jbake-tags: blog, kettle, integration (6)

1) subject line
2) author name
3) post date
4) type post - should be fixed
5) status - could be draft (I think) or published as seen

There are already existing posts that can serve a example.


From jsanda at redhat.com  Mon Mar 16 15:07:10 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Mar 2015 15:07:10 -0400
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
Message-ID: <B555EF84-8870-40B5-993A-5737D262C479@redhat.com>

For monitoring purposes, do we really need to write an agent? Should we just leverage existing tools/libraries? I previously cited three common architectures for monitoring agents,

1) embedded, in-process
2) separate process but co-located on same host
3) remote monitoring from different host

Let?s consider monitoring the JVM and applications running on it. Coda Hale Metrics is a widely used metrics library that is becoming ubiquitous. It provides reporters for exporting metrics that are collected. The core metrics library provides several reporters, console, JMX, CSV, to name a few. There are plenty of 3rd party reported as well, like the Graphite reporter. We could implement a hawkular reporter which then makes it very easy then for any application, library, etc. that uses Coda Hale Metrics to collect and report to hawkular. 

The in-process collector might not always be possible or desirable. For those situations the co-located agent is a better fit. jmxtrans could be an excellent option. It can query and collect metrics from external JVMs and then write them to other systems like Graphite, Ganglia, Open TSDB, and more. We could implement a hawkular metrics writer.

Maybe we take a similar approach for platform metrics with collectd for example. We are already doing something similar by seeing how we can integrate more directly with cadvisor. Is it worth considering doing the same with some of the tools/libraries that are already in wide spread use?

> On Mar 16, 2015, at 4:13 AM, Gary Brown <gbrown at redhat.com> wrote:
> 
> This embedded 'agent' would also be useful for collecting the activity information for RTGov. I assume information will be routed depending on type at the backend?
> 
> Regards
> Gary
> 
> ----- Original Message -----
>> So what I heard today was we don't want a standalone agent, but we do want
>> something that can be embedded in Wildfly/EAP so it can monitor things
>> running in Wildfly (not just monitor Wildfly itself, but applications
>> running inside wildfly).
>> 
>> That lends itself to supporting customizable modules that can be deployed in
>> Wildfly/EAP as hawkular subsystems.
>> 
>> Can someone give me a quick summary of what Wildfly-Monitor does?
>> https://github.com/hawkular/wildfly-monitor
>> _______________________________________________
>> 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



From hrupp at redhat.com  Mon Mar 16 15:24:50 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 16 Mar 2015 20:24:50 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
Message-ID: <C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>

On 16 Mar 2015, at 20:07, John Sanda wrote:

> For monitoring purposes, do we really need to write an agent? Should 
> we just leverage existing tools/libraries? I previously cited three

(Re)using all those tools is fine and certainly desired, but the issue 
is less
about what some random tool uses to collect metrics inside an app, but
rather how to access and transport them. Using JMX like in the good ol'
days is certainly a way. Or using the Jolokia Java agent. But still 
someone
needs to talk to them.

Writing a subsystem for inside Wildfly to actively report/submit data
is in fact an (embedded) agent. Not a general purpose one.

We already have converters from collectd, gmon and a few other
protocols into Hawkular(-metrics). So yes, they should all be allowable
as input.

And then we will have more specialized use cases that most probably go 
much
further than just submitting some metrics to the Hawkular(-metrics) 
server.
In this case some more specialized code may be needed too.

From jsanda at redhat.com  Mon Mar 16 15:42:19 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Mar 2015 15:42:19 -0400
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
Message-ID: <CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>


> On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 16 Mar 2015, at 20:07, John Sanda wrote:
> 
>> For monitoring purposes, do we really need to write an agent? Should 
>> we just leverage existing tools/libraries? I previously cited three
> 
> (Re)using all those tools is fine and certainly desired, but the issue 
> is less
> about what some random tool uses to collect metrics inside an app, but
> rather how to access and transport them. Using JMX like in the good ol'
> days is certainly a way. Or using the Jolokia Java agent. But still 
> someone
> needs to talk to them.

Accessing and transporting the data is already answered to a large degree. That is the primary reason I brought it up in the first place. Another aspect to consider is that different types of monitoring agents lend themselves better to different scenarios. I think that focusing more on integration with existing agents/collectors gives us a better chance of being able to use the best tool for a particular situation.

> 
> Writing a subsystem for inside Wildfly to actively report/submit data
> is in fact an (embedded) agent. Not a general purpose one.
> 
> We already have converters from collectd, gmon and a few other
> protocols into Hawkular(-metrics). So yes, they should all be allowable
> as input.
> 
> And then we will have more specialized use cases that most probably go 
> much
> further than just submitting some metrics to the Hawkular(-metrics) 
> server.
> In this case some more specialized code may be needed too.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From lkrejci at redhat.com  Mon Mar 16 15:58:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 16 Mar 2015 20:58:48 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
Message-ID: <1657103.cJvZiUMysr@localhost.localdomain>

On Monday, March 16, 2015 15:42:19 John Sanda wrote:
> > On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> > 
> > On 16 Mar 2015, at 20:07, John Sanda wrote:
> >> For monitoring purposes, do we really need to write an agent? Should
> >> we just leverage existing tools/libraries? I previously cited three
> > 
> > (Re)using all those tools is fine and certainly desired, but the issue
> > is less
> > about what some random tool uses to collect metrics inside an app, but
> > rather how to access and transport them. Using JMX like in the good ol'
> > days is certainly a way. Or using the Jolokia Java agent. But still
> > someone
> > needs to talk to them.
> 
> Accessing and transporting the data is already answered to a large degree.
> That is the primary reason I brought it up in the first place. Another
> aspect to consider is that different types of monitoring agents lend
> themselves better to different scenarios. I think that focusing more on
> integration with existing agents/collectors gives us a better chance of
> being able to use the best tool for a particular situation.

+1

That's why I was advocating for "no agent at all" a couple of days ago. 
Frankly, that was a little bit too radical and not thought through. You 
articulated the point I wanted to make much better.

On the "agent side" there are more than plenty of tools that are already in 
use. We should first try to find ways of integrating with these tools and only 
when none of pre-existing stuff implements our usecase (in a good enough way) 
we should look to implement an "agent" of our own.

It is my current (most probably naive) understanding that those agents should 
be small tools for particular jobs (or maybe extensions to existing tools), 
not some "heavy" agent in the RHQ sense.

Better yet, in addition to integration with existing metric-collection tools, 
I think we could write some "integration libraries" for some popular languages 
(bash, java, python, ...) that would enable easy integration of hawk metrics 
into existing software or enable users to write new "feeds" (because "agent" 
is a too overloaded term) on their own. These feeds could be any of the 3 
types you mentioned and we wouldn't actually care on the server side.

> > Writing a subsystem for inside Wildfly to actively report/submit data
> > is in fact an (embedded) agent. Not a general purpose one.
> > 
> > We already have converters from collectd, gmon and a few other
> > protocols into Hawkular(-metrics). So yes, they should all be allowable
> > as input.
> > 
> > And then we will have more specialized use cases that most probably go
> > much
> > further than just submitting some metrics to the Hawkular(-metrics)
> > server.
> > In this case some more specialized code may be needed too.
> > _______________________________________________
> > 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


From lkrejci at redhat.com  Mon Mar 16 16:02:40 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 16 Mar 2015 21:02:40 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
Message-ID: <1776487.4d6Z0ErrLG@localhost.localdomain>

On Monday, March 16, 2015 15:07:10 John Sanda wrote:
> For monitoring purposes, do we really need to write an agent? Should we just
> leverage existing tools/libraries? I previously cited three common
> architectures for monitoring agents,
> 
> 1) embedded, in-process
> 2) separate process but co-located on same host
> 3) remote monitoring from different host
> 

I think re-using existing stuff is desirable but 1 question needs to be 
addressed first:

How are we going to configure these tools? We could just say that that is out 
of the scope for Hawkular, but I don't find that too user friendly. Things 
like collection intervals or disabling/enabling should be configurable from 
inside Hawkular if the external tool has such capability.

> Let?s consider monitoring the JVM and applications running on it. Coda Hale
> Metrics is a widely used metrics library that is becoming ubiquitous. It
> provides reporters for exporting metrics that are collected. The core
> metrics library provides several reporters, console, JMX, CSV, to name a
> few. There are plenty of 3rd party reported as well, like the Graphite
> reporter. We could implement a hawkular reporter which then makes it very
> easy then for any application, library, etc. that uses Coda Hale Metrics to
> collect and report to hawkular.
> 
> The in-process collector might not always be possible or desirable. For
> those situations the co-located agent is a better fit. jmxtrans could be an
> excellent option. It can query and collect metrics from external JVMs and
> then write them to other systems like Graphite, Ganglia, Open TSDB, and
> more. We could implement a hawkular metrics writer.
> 
> Maybe we take a similar approach for platform metrics with collectd for
> example. We are already doing something similar by seeing how we can
> integrate more directly with cadvisor. Is it worth considering doing the
> same with some of the tools/libraries that are already in wide spread use?
> > On Mar 16, 2015, at 4:13 AM, Gary Brown <gbrown at redhat.com> wrote:
> > 
> > This embedded 'agent' would also be useful for collecting the activity
> > information for RTGov. I assume information will be routed depending on
> > type at the backend?
> > 
> > Regards
> > Gary
> > 
> > ----- Original Message -----
> > 
> >> So what I heard today was we don't want a standalone agent, but we do
> >> want
> >> something that can be embedded in Wildfly/EAP so it can monitor things
> >> running in Wildfly (not just monitor Wildfly itself, but applications
> >> running inside wildfly).
> >> 
> >> That lends itself to supporting customizable modules that can be deployed
> >> in Wildfly/EAP as hawkular subsystems.
> >> 
> >> Can someone give me a quick summary of what Wildfly-Monitor does?
> >> https://github.com/hawkular/wildfly-monitor
> >> _______________________________________________
> >> 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



From jsanda at redhat.com  Mon Mar 16 16:19:41 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Mar 2015 16:19:41 -0400
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1657103.cJvZiUMysr@localhost.localdomain>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
Message-ID: <1E69A857-7429-42ED-BF51-1E49318B584D@redhat.com>


> On Mar 16, 2015, at 3:58 PM, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Monday, March 16, 2015 15:42:19 John Sanda wrote:
>>> On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>> 
>>> On 16 Mar 2015, at 20:07, John Sanda wrote:
>>>> For monitoring purposes, do we really need to write an agent? Should
>>>> we just leverage existing tools/libraries? I previously cited three
>>> 
>>> (Re)using all those tools is fine and certainly desired, but the issue
>>> is less
>>> about what some random tool uses to collect metrics inside an app, but
>>> rather how to access and transport them. Using JMX like in the good ol'
>>> days is certainly a way. Or using the Jolokia Java agent. But still
>>> someone
>>> needs to talk to them.
>> 
>> Accessing and transporting the data is already answered to a large degree.
>> That is the primary reason I brought it up in the first place. Another
>> aspect to consider is that different types of monitoring agents lend
>> themselves better to different scenarios. I think that focusing more on
>> integration with existing agents/collectors gives us a better chance of
>> being able to use the best tool for a particular situation.
> 
> +1
> 
> That's why I was advocating for "no agent at all" a couple of days ago. 
> Frankly, that was a little bit too radical and not thought through. You 
> articulated the point I wanted to make much better.
> 
> On the "agent side" there are more than plenty of tools that are already in 
> use. We should first try to find ways of integrating with these tools and only 
> when none of pre-existing stuff implements our usecase (in a good enough way) 
> we should look to implement an "agent" of our own.
> 
> It is my current (most probably naive) understanding that those agents should 
> be small tools for particular jobs (or maybe extensions to existing tools), 
> not some "heavy" agent in the RHQ sense.
> 
> Better yet, in addition to integration with existing metric-collection tools, 
> I think we could write some "integration libraries" for some popular languages 
> (bash, java, python, ...) that would enable easy integration of hawk metrics 
> into existing software or enable users to write new "feeds" (because "agent" 
> is a too overloaded term) on their own. These feeds could be any of the 3 
> types you mentioned and we wouldn't actually care on the server side.

I definitely agree that we should be thinking about integration libraries for different languages. We have a clear use case for Go already, and I think Python makes sense too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150316/db3b4acd/attachment-0001.html 

From jsanda at redhat.com  Mon Mar 16 16:30:41 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Mar 2015 16:30:41 -0400
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1776487.4d6Z0ErrLG@localhost.localdomain>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
	<1776487.4d6Z0ErrLG@localhost.localdomain>
Message-ID: <01EDDDC2-5040-4224-8253-9355514C5FF5@redhat.com>


> On Mar 16, 2015, at 4:02 PM, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Monday, March 16, 2015 15:07:10 John Sanda wrote:
>> For monitoring purposes, do we really need to write an agent? Should we just
>> leverage existing tools/libraries? I previously cited three common
>> architectures for monitoring agents,
>> 
>> 1) embedded, in-process
>> 2) separate process but co-located on same host
>> 3) remote monitoring from different host
>> 
> 
> I think re-using existing stuff is desirable but 1 question needs to be 
> addressed first:
> 
> How are we going to configure these tools? We could just say that that is out 
> of the scope for Hawkular, but I don't find that too user friendly. Things 
> like collection intervals or disabling/enabling should be configurable from 
> inside Hawkular if the external tool has such capability.

Configuration is an open question, but I think it is a question that applies equally whether we are talking integration with existing tools or our own, custom monitoring agent(s). I agree that stuff like collection intervals and enabling/disabling metrics should be configurable via Hawkular. On one end of the spectrum, the integration could be completely exposed. This places the largest burden on the user because the user has to understand the various tools used in/by Hawkular. For users familiar with those tools though, it provides benefits because it gives them greater flexibility in how to set up and configure things. At the other end of the spectrum, the integration is an implementation detail to the greatest extent possible. Users only need to know how to set up/configure Hawkular. This is more along the lines of the approach we took with integrating Cassandra into RHQ. I think that answer should be somewhere in the middle so that we can give users the flexibility when they want it, but at the same time not force it on users.

> 
>> Let?s consider monitoring the JVM and applications running on it. Coda Hale
>> Metrics is a widely used metrics library that is becoming ubiquitous. It
>> provides reporters for exporting metrics that are collected. The core
>> metrics library provides several reporters, console, JMX, CSV, to name a
>> few. There are plenty of 3rd party reported as well, like the Graphite
>> reporter. We could implement a hawkular reporter which then makes it very
>> easy then for any application, library, etc. that uses Coda Hale Metrics to
>> collect and report to hawkular.
>> 
>> The in-process collector might not always be possible or desirable. For
>> those situations the co-located agent is a better fit. jmxtrans could be an
>> excellent option. It can query and collect metrics from external JVMs and
>> then write them to other systems like Graphite, Ganglia, Open TSDB, and
>> more. We could implement a hawkular metrics writer.
>> 
>> Maybe we take a similar approach for platform metrics with collectd for
>> example. We are already doing something similar by seeing how we can
>> integrate more directly with cadvisor. Is it worth considering doing the
>> same with some of the tools/libraries that are already in wide spread use?
>>> On Mar 16, 2015, at 4:13 AM, Gary Brown <gbrown at redhat.com> wrote:
>>> 
>>> This embedded 'agent' would also be useful for collecting the activity
>>> information for RTGov. I assume information will be routed depending on
>>> type at the backend?
>>> 
>>> Regards
>>> Gary
>>> 
>>> ----- Original Message -----
>>> 
>>>> So what I heard today was we don't want a standalone agent, but we do
>>>> want
>>>> something that can be embedded in Wildfly/EAP so it can monitor things
>>>> running in Wildfly (not just monitor Wildfly itself, but applications
>>>> running inside wildfly).
>>>> 
>>>> That lends itself to supporting customizable modules that can be deployed
>>>> in Wildfly/EAP as hawkular subsystems.
>>>> 
>>>> Can someone give me a quick summary of what Wildfly-Monitor does?
>>>> https://github.com/hawkular/wildfly-monitor
>>>> _______________________________________________
>>>> 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 <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150316/e8aba3c8/attachment.html 

From hrupp at redhat.com  Tue Mar 17 04:04:55 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Mar 2015 09:04:55 +0100
Subject: [Hawkular-dev] Fwd: Introducing 'osc login'
References: <9965987.8807.1426565680154.JavaMail.luke@rh-t520.sosiouxme.lan>
Message-ID: <D1892A69-73F0-4515-9F70-6F12D9552302@redhat.com>

Could this "osc login" flow serve as a blueprint for us when configuring 
external feeds? Like
providing such a tool and then some "base classes" (*) that the feed can 
use to read the data?


*) This of course depends on programming language etc.

Forwarded message:

> From: Luke Meyer <lmeyer at redhat.com>
> To: Fabiano Franz <ffranz at redhat.com>
> Cc: Openshift Dev <dev at lists.openshift.redhat.com>
> Subject: Re: Introducing 'osc login'
> Date: Tue, 17 Mar 2015 00:14:44 -0400 (EDT)
>
> *cheers* \o/
>
> The users (and their administrators) will thank you!
>
> ----- Original Message -----
> From: "Fabiano Franz" <ffranz at redhat.com>
> To: "Openshift Dev" <dev at lists.openshift.redhat.com>
> Sent: Monday, March 16, 2015 6:07:14 PM
> Subject: Introducing 'osc login'
>
> The 'osc login' command were merged[1] earlier today featuring a lot 
> of improvements in terms of usability for users of the OpenShift v3 
> command line tools.
>
> This new command is intended to be the "entry point" for first-time 
> users, featuring not only the negotiation of a session token with the 
> OpenShift server, but also an interactive setup flow for configuring 
> the command line tools. Basically when running 'osc login', users will 
> be presented to an interactive process that will ask a few questions 
> (server URL, credentials, etc) and in the end will *automatically 
> save* a config file compliant with .kubeconfig that will later be used 
> by every subsequent command.
>
> Were also added OpenShift-specific ways for providing a config file: 
> the path to a config can now be provided by either the --config flag, 
> OPENSHIFTCONFIG env var, ~/.config/openshift/.config file or 
> .openshiftconfig file in the current directory (some of these path 
> names are still under discussion).
>
> Notice that a couple things that were originally part of this pull 
> request, like user-friendly messages with colors, were not merged and 
> will be in forthcoming improvements.
>
> Finally, the package also introduces the 'osc project' command that 
> can be used to either display the project currently in use or switch 
> to another project, through 'osc project <project-name>'.
>
> End-user docs will follow. Please let us know if you have comments or 
> suggestions.
>
> Fabiano Franz
>
> [1] https://github.com/openshift/origin/pull/992
>
> _______________________________________________
> dev mailing list
> dev at lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev at lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

From jpkroehling at redhat.com  Tue Mar 17 04:09:23 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 17 Mar 2015 09:09:23 +0100
Subject: [Hawkular-dev] Fwd: Introducing 'osc login'
In-Reply-To: <D1892A69-73F0-4515-9F70-6F12D9552302@redhat.com>
References: <9965987.8807.1426565680154.JavaMail.luke@rh-t520.sosiouxme.lan>
	<D1892A69-73F0-4515-9F70-6F12D9552302@redhat.com>
Message-ID: <5507E133.4010606@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Definitely. I'll add this as a JIRA for me.

- - Juca.

On 03/17/2015 09:04 AM, Heiko W.Rupp wrote:
> Could this "osc login" flow serve as a blueprint for us when
> configuring external feeds? Like providing such a tool and then
> some "base classes" (*) that the feed can use to read the data?
> 
> 
> *) This of course depends on programming language etc.
> 
> Forwarded message:
> 
>> From: Luke Meyer <lmeyer at redhat.com> To: Fabiano Franz
>> <ffranz at redhat.com> Cc: Openshift Dev
>> <dev at lists.openshift.redhat.com> Subject: Re: Introducing 'osc
>> login' Date: Tue, 17 Mar 2015 00:14:44 -0400 (EDT)
>> 
>> *cheers* \o/
>> 
>> The users (and their administrators) will thank you!
>> 
>> ----- Original Message ----- From: "Fabiano Franz"
>> <ffranz at redhat.com> To: "Openshift Dev"
>> <dev at lists.openshift.redhat.com> Sent: Monday, March 16, 2015
>> 6:07:14 PM Subject: Introducing 'osc login'
>> 
>> The 'osc login' command were merged[1] earlier today featuring a
>> lot of improvements in terms of usability for users of the
>> OpenShift v3 command line tools.
>> 
>> This new command is intended to be the "entry point" for
>> first-time users, featuring not only the negotiation of a session
>> token with the OpenShift server, but also an interactive setup
>> flow for configuring the command line tools. Basically when
>> running 'osc login', users will be presented to an interactive
>> process that will ask a few questions (server URL, credentials,
>> etc) and in the end will *automatically save* a config file
>> compliant with .kubeconfig that will later be used by every
>> subsequent command.
>> 
>> Were also added OpenShift-specific ways for providing a config
>> file: the path to a config can now be provided by either the
>> --config flag, OPENSHIFTCONFIG env var,
>> ~/.config/openshift/.config file or .openshiftconfig file in the
>> current directory (some of these path names are still under
>> discussion).
>> 
>> Notice that a couple things that were originally part of this
>> pull request, like user-friendly messages with colors, were not
>> merged and will be in forthcoming improvements.
>> 
>> Finally, the package also introduces the 'osc project' command
>> that can be used to either display the project currently in use
>> or switch to another project, through 'osc project
>> <project-name>'.
>> 
>> End-user docs will follow. Please let us know if you have
>> comments or suggestions.
>> 
>> Fabiano Franz
>> 
>> [1] https://github.com/openshift/origin/pull/992
>> 
>> _______________________________________________ dev mailing list 
>> dev at lists.openshift.redhat.com 
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>> 
>> _______________________________________________ dev mailing list 
>> dev at lists.openshift.redhat.com 
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> _______________________________________________ hawkular-dev
> mailing list hawkular-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVB+EzAAoJECKM1e+fkPrXgJYH/i639hPvpUsYWNi8LpCyKINd
GV4gQDSmndVavQBPNj5Luk7hXA4D6ujR2oi7lBqdZj76zPjJ3wck00wAQGHtjVNT
awDpK6tGF67ZDUzVbd9GSgP5rwSv3H8BlTYizmI10iNCe+EnfsRt2UCc8uA37+sn
J3rWc6K85EdtMy+LECXZI2IgAaWBUAlC/qyTWti7LCFMNC3XcC8CZIdzjQzsZEe4
WOFulVBafVk25ch8L97LxxpVPNrHxV4k9U7jSl2S2A6ZlfMYgBNE0dqiU16Ox7hs
3TRx1w1RAeYjfnE6a6mw6XQdu8Eng23sBYqBKjBnsIY5/vpwzQSGpSRULDi3TLI=
=nIcL
-----END PGP SIGNATURE-----

From theute at redhat.com  Tue Mar 17 04:35:05 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 17 Mar 2015 09:35:05 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1657103.cJvZiUMysr@localhost.localdomain>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
Message-ID: <5507E739.3040804@redhat.com>



On 03/16/2015 08:58 PM, Lukas Krejci wrote:
> On Monday, March 16, 2015 15:42:19 John Sanda wrote:
>>> On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>>
>>> On 16 Mar 2015, at 20:07, John Sanda wrote:
>>>> For monitoring purposes, do we really need to write an agent? Should
>>>> we just leverage existing tools/libraries? I previously cited three
>>> (Re)using all those tools is fine and certainly desired, but the issue
>>> is less
>>> about what some random tool uses to collect metrics inside an app, but
>>> rather how to access and transport them. Using JMX like in the good ol'
>>> days is certainly a way. Or using the Jolokia Java agent. But still
>>> someone
>>> needs to talk to them.
>> Accessing and transporting the data is already answered to a large degree.
>> That is the primary reason I brought it up in the first place. Another
>> aspect to consider is that different types of monitoring agents lend
>> themselves better to different scenarios. I think that focusing more on
>> integration with existing agents/collectors gives us a better chance of
>> being able to use the best tool for a particular situation.
> +1
>
> That's why I was advocating for "no agent at all" a couple of days ago.
> Frankly, that was a little bit too radical and not thought through. You
> articulated the point I wanted to make much better.
>
> On the "agent side" there are more than plenty of tools that are already in
> use. We should first try to find ways of integrating with these tools and only
> when none of pre-existing stuff implements our usecase (in a good enough way)
> we should look to implement an "agent" of our own.
>
> It is my current (most probably naive) understanding that those agents should
> be small tools for particular jobs (or maybe extensions to existing tools),
> not some "heavy" agent in the RHQ sense.
>
> Better yet, in addition to integration with existing metric-collection tools,
> I think we could write some "integration libraries" for some popular languages
> (bash, java, python, ...) that would enable easy integration of hawk metrics
> into existing software or enable users to write new "feeds" (because "agent"
> is a too overloaded term) on their own. These feeds could be any of the 3
> types you mentioned and we wouldn't actually care on the server side.

We also need auto-discovery to fill-in the inventory. It's not just a 
flow of data but we need to know how those "feeds" are related.

Thomas

>
>>> Writing a subsystem for inside Wildfly to actively report/submit data
>>> is in fact an (embedded) agent. Not a general purpose one.
>>>
>>> We already have converters from collectd, gmon and a few other
>>> protocols into Hawkular(-metrics). So yes, they should all be allowable
>>> as input.
>>>
>>> And then we will have more specialized use cases that most probably go
>>> much
>>> further than just submitting some metrics to the Hawkular(-metrics)
>>> server.
>>> In this case some more specialized code may be needed too.
>>> _______________________________________________
>>> 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


From theute at redhat.com  Tue Mar 17 04:48:14 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 17 Mar 2015 09:48:14 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <01EDDDC2-5040-4224-8253-9355514C5FF5@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>	<1776487.4d6Z0ErrLG@localhost.localdomain>
	<01EDDDC2-5040-4224-8253-9355514C5FF5@redhat.com>
Message-ID: <5507EA4E.8040100@redhat.com>



On 03/16/2015 09:30 PM, John Sanda wrote:
>
>> On Mar 16, 2015, at 4:02 PM, Lukas Krejci <lkrejci at redhat.com 
>> <mailto:lkrejci at redhat.com>> wrote:
>>
>> On Monday, March 16, 2015 15:07:10 John Sanda wrote:
>>> For monitoring purposes, do we really need to write an agent? Should 
>>> we just
>>> leverage existing tools/libraries? I previously cited three common
>>> architectures for monitoring agents,
>>>
>>> 1) embedded, in-process
>>> 2) separate process but co-located on same host
>>> 3) remote monitoring from different host
>>>
>>
>> I think re-using existing stuff is desirable but 1 question needs to be
>> addressed first:
>>
>> How are we going to configure these tools? We could just say that 
>> that is out
>> of the scope for Hawkular, but I don't find that too user friendly. 
>> Things
>> like collection intervals or disabling/enabling should be 
>> configurable from
>> inside Hawkular if the external tool has such capability.
>
> Configuration is an open question, but I think it is a question that 
> applies equally whether we are talking integration with existing tools 
> or our own, custom monitoring agent(s). I agree that stuff like 
> collection intervals and enabling/disabling metrics should be 
> configurable via Hawkular. On one end of the spectrum, the integration 
> could be completely exposed. This places the largest burden on the 
> user because the user has to understand the various tools used in/by 
> Hawkular. For users familiar with those tools though, it provides 
> benefits because it gives them greater flexibility in how to set up 
> and configure things. At the other end of the spectrum, the 
> integration is an implementation detail to the greatest extent 
> possible. Users only need to know how to set up/configure Hawkular. 
> This is more along the lines of the approach we took with integrating 
> Cassandra into RHQ. I think that answer should be somewhere in the 
> middle so that we can give users the flexibility when they want it, 
> but at the same time not force it on users.

Using/Reusing those tools should be done (there is no reason to rewrite 
cAdvisor for instance which should work on any platform that supports 
Docker today), but we need a way to easily be able to configure them 
"from the server". For some "tools" we may also need to check if they 
are available and if not, use an alternative solution, install the 
missing piece, or inform the user that he's missing something.


Thomas


>
>>
>>> Let?s consider monitoring the JVM and applications running on it. 
>>> Coda Hale
>>> Metrics is a widely used metrics library that is becoming ubiquitous. It
>>> provides reporters for exporting metrics that are collected. The core
>>> metrics library provides several reporters, console, JMX, CSV, to name a
>>> few. There are plenty of 3rd party reported as well, like the Graphite
>>> reporter. We could implement a hawkular reporter which then makes it 
>>> very
>>> easy then for any application, library, etc. that uses Coda Hale 
>>> Metrics to
>>> collect and report to hawkular.
>>>
>>> The in-process collector might not always be possible or desirable. For
>>> those situations the co-located agent is a better fit. jmxtrans 
>>> could be an
>>> excellent option. It can query and collect metrics from external 
>>> JVMs and
>>> then write them to other systems like Graphite, Ganglia, Open TSDB, and
>>> more. We could implement a hawkular metrics writer.
>>>
>>> Maybe we take a similar approach for platform metrics with collectd for
>>> example. We are already doing something similar by seeing how we can
>>> integrate more directly with cadvisor. Is it worth considering doing the
>>> same with some of the tools/libraries that are already in wide 
>>> spread use?
>>>> On Mar 16, 2015, at 4:13 AM, Gary Brown <gbrown at redhat.com 
>>>> <mailto:gbrown at redhat.com>> wrote:
>>>>
>>>> This embedded 'agent' would also be useful for collecting the activity
>>>> information for RTGov. I assume information will be routed depending on
>>>> type at the backend?
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> So what I heard today was we don't want a standalone agent, but we do
>>>>> want
>>>>> something that can be embedded in Wildfly/EAP so it can monitor things
>>>>> running in Wildfly (not just monitor Wildfly itself, but applications
>>>>> running inside wildfly).
>>>>>
>>>>> That lends itself to supporting customizable modules that can be 
>>>>> deployed
>>>>> in Wildfly/EAP as hawkular subsystems.
>>>>>
>>>>> Can someone give me a quick summary of what Wildfly-Monitor does?
>>>>> https://github.com/hawkular/wildfly-monitor
>>>>> _______________________________________________
>>>>> 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 <mailto:hawkular-dev at lists.jboss.org>
>>>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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/20150317/fed065aa/attachment-0001.html 

From hrupp at redhat.com  Tue Mar 17 06:10:22 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Mar 2015 11:10:22 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>
	<5500933D.9010507@redhat.com>
	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>
	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>
	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>
	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
Message-ID: <E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>

On 16 Mar 2015, at 20:42, John Sanda wrote:
> Accessing and transporting the data is already answered to a large 
> degree. That is the primary reason I brought it up in the first

Still, someone needs to go out and talk to Jolokia and fetch the data
periodically.
Past experience has shown that users like the fact that the 
(RHQ/Hawkular)
server is not talking to all the end-resources  / - processes 
individually, but
that this is channeled through the agent.


From hrupp at redhat.com  Tue Mar 17 06:13:32 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Mar 2015 11:13:32 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1657103.cJvZiUMysr@localhost.localdomain>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
Message-ID: <94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>

On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> On the "agent side" there are more than plenty of tools that are 
> already in
> use. We should first try to find ways of integrating with these tools 
> and only
> when none of pre-existing stuff implements our usecase (in a good 
> enough way)
> we should look to implement an "agent" of our own.

What if the users does not have any of those tools installed?
Do we tell them "install Ganglia, but not the graphing, only the 
monitoring".
Ah and as this does not cope well with WildFly 94 please install 
collectd on top?

> not some "heavy" agent in the RHQ sense.

Running many of the small tools in parallel also has a cost. Similar
to forking hundreds and thousands of shell commands.

From miburman at redhat.com  Tue Mar 17 06:41:38 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 17 Mar 2015 06:41:38 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
Message-ID: <1034419289.41470394.1426588898491.JavaMail.zimbra@redhat.com>

Hi,

Not to mention all the integration weight we'll have to carry. Keeping up with the third party software versions and backwards compatibility is going to incur a huge cost in terms of development hours. The same issue we had with building RHQ plugins for every product.

Supporting software where we can send plugins for the third-party to "keep up" is going to be easier for us (assuming we get some users for those - in which case there might be community updates to some of those plugins to keep them working) than building compatible APIs to our core. And in any case, those third-party agents will not provide us the USP we want. 

  - Micke

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Tuesday, March 17, 2015 12:13:32 PM
Subject: Re: [Hawkular-dev] scope of the agent design

On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> On the "agent side" there are more than plenty of tools that are 
> already in
> use. We should first try to find ways of integrating with these tools 
> and only
> when none of pre-existing stuff implements our usecase (in a good 
> enough way)
> we should look to implement an "agent" of our own.

What if the users does not have any of those tools installed?
Do we tell them "install Ganglia, but not the graphing, only the 
monitoring".
Ah and as this does not cope well with WildFly 94 please install 
collectd on top?

> not some "heavy" agent in the RHQ sense.

Running many of the small tools in parallel also has a cost. Similar
to forking hundreds and thousands of shell commands.
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

From lkrejci at redhat.com  Tue Mar 17 11:07:43 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Mar 2015 16:07:43 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1034419289.41470394.1426588898491.JavaMail.zimbra@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
	<1034419289.41470394.1426588898491.JavaMail.zimbra@redhat.com>
Message-ID: <3137584.NPHvWljx8H@localhost.localdomain>

On Tuesday, March 17, 2015 06:41:38 Michael Burman wrote:
> Hi,
> 
> Not to mention all the integration weight we'll have to carry. Keeping up
> with the third party software versions and backwards compatibility is going
> to incur a huge cost in terms of development hours. The same issue we had
> with building RHQ plugins for every product.
> 

I don't see a difference here.

IMHO, integration with a 3rd party monitoring tool is the same as writing a 
plugin for monitoring an application. Both can change incompatibly out of our 
control and we'll always be just catching up on.

The reason I think integration with 3rd party monitoring is better is that, 
more probably than not, people will have used some monitoring solution by the 
time they decide to use Hawkular.

If we offer them integration with their existing monitoring solution they will 
love us. If we tell them they need to toss everything they have and instead 
deploy our stuff that might or might not do what they were used to, they might 
not love us at all ;)

> Supporting software where we can send plugins for the third-party to "keep
> up" is going to be easier for us (assuming we get some users for those - in
> which case there might be community updates to some of those plugins to
> keep them working) than building compatible APIs to our core. And in any
> case, those third-party agents will not provide us the USP we want.
> 

Well, that is a big question. How are you going to force people to write 
Hawkular plugins? Sure, this can be done inside Red Hat were we follow the 
common goal and divide the work across the teams, but I doubt community will 
be chuffed to learn yet another way of monitoring. But then again, that is 
what we propose, too ;) Integrate with existing monitoring solutions AND 
provide libraries for people to easily write their own feeds to Hawkular.

>   - Micke
> 
> ----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, March 17, 2015 12:13:32 PM
> Subject: Re: [Hawkular-dev] scope of the agent design
> 
> On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> > On the "agent side" there are more than plenty of tools that are
> > already in
> > use. We should first try to find ways of integrating with these tools
> > and only
> > when none of pre-existing stuff implements our usecase (in a good
> > enough way)
> > we should look to implement an "agent" of our own.
> 
> What if the users does not have any of those tools installed?
> Do we tell them "install Ganglia, but not the graphing, only the
> monitoring".
> Ah and as this does not cope well with WildFly 94 please install
> collectd on top?
> 
> > not some "heavy" agent in the RHQ sense.
> 
> Running many of the small tools in parallel also has a cost. Similar
> to forking hundreds and thousands of shell commands.
> _______________________________________________
> 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


From lkrejci at redhat.com  Tue Mar 17 11:17:26 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Mar 2015 16:17:26 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
Message-ID: <1840598.iiPUEzcYuK@localhost.localdomain>

On Tuesday, March 17, 2015 11:13:32 Heiko W.Rupp wrote:
> On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> > On the "agent side" there are more than plenty of tools that are
> > already in
> > use. We should first try to find ways of integrating with these tools
> > and only
> > when none of pre-existing stuff implements our usecase (in a good
> > enough way)
> > we should look to implement an "agent" of our own.
> 
> What if the users does not have any of those tools installed?
> Do we tell them "install Ganglia, but not the graphing, only the
> monitoring".

I think that is going to just depend on the usecase. It might be easier to 
tell them "install Ganglia" if it provides just the monitoring capabilities 
they need. It also might be easier to tell them use Hawkular agent.

Or they might have requirements that neither can meet.

> Ah and as this does not cope well with WildFly 94 please install
> collectd on top?
> 

I am pretty much sure Hawkular will have the same kind of problems. RHQ had 
them for sure because incompatibilities are pretty much unavoidable IMHO.

> > not some "heavy" agent in the RHQ sense.
> 
> Running many of the small tools in parallel also has a cost. Similar
> to forking hundreds and thousands of shell commands.

In my mind, the most optimal feed is an in-process feed - no problems with 
security, inter-process/network comms overhead, etc.

The way people do "small" monitoring IMHO, is to run many small scripts on 
schedule. Even if there is a thousand of them, they run for a short period of 
time so the load spreads nicely (usually, of course everything is a function 
of scale as we know from RHQ ;) ).

Having 1 external process to do all monitoring, as we had in RHQ, has also its 
pros - for one it is easier to estimate the monitoring "cost" by looking at 
the memory and CPU consumption of the external agent.

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From lkrejci at redhat.com  Tue Mar 17 11:19:25 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Mar 2015 16:19:25 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>
Message-ID: <1492894.IVMPbP4hBn@localhost.localdomain>

On Tuesday, March 17, 2015 11:10:22 Heiko W.Rupp wrote:
> On 16 Mar 2015, at 20:42, John Sanda wrote:
> > Accessing and transporting the data is already answered to a large
> > degree. That is the primary reason I brought it up in the first
> 
> Still, someone needs to go out and talk to Jolokia and fetch the data
> periodically.
> Past experience has shown that users like the fact that the
> (RHQ/Hawkular)
> server is not talking to all the end-resources  / - processes
> individually, but
> that this is channeled through the agent.
> 

They also complained about it because it made filesystem permissions and other 
security aspects more complex.

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From theute at redhat.com  Tue Mar 17 11:50:59 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 17 Mar 2015 16:50:59 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <1840598.iiPUEzcYuK@localhost.localdomain>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
	<1840598.iiPUEzcYuK@localhost.localdomain>
Message-ID: <55084D63.4000301@redhat.com>

I don't think we are on the same page regarding the focus of the 
project/product.

Hawkular is targeted toward Red Hat Middleware management, for 
infrastructure management there are gazillion other solutions.
We need "some" basic infrastructure management, for those basic needs a 
user shouldn't need to maintain a solution made of multiple puzzle pieces.

Look at NewRelic or ruxit those are dead simple to install and to start 
monitoring.

Thomas



On 03/17/2015 04:17 PM, Lukas Krejci wrote:
> On Tuesday, March 17, 2015 11:13:32 Heiko W.Rupp wrote:
>> On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
>>> On the "agent side" there are more than plenty of tools that are
>>> already in
>>> use. We should first try to find ways of integrating with these tools
>>> and only
>>> when none of pre-existing stuff implements our usecase (in a good
>>> enough way)
>>> we should look to implement an "agent" of our own.
>> What if the users does not have any of those tools installed?
>> Do we tell them "install Ganglia, but not the graphing, only the
>> monitoring".
> I think that is going to just depend on the usecase. It might be easier to
> tell them "install Ganglia" if it provides just the monitoring capabilities
> they need. It also might be easier to tell them use Hawkular agent.
>
> Or they might have requirements that neither can meet.
>
>> Ah and as this does not cope well with WildFly 94 please install
>> collectd on top?
>>
> I am pretty much sure Hawkular will have the same kind of problems. RHQ had
> them for sure because incompatibilities are pretty much unavoidable IMHO.
>
>>> not some "heavy" agent in the RHQ sense.
>> Running many of the small tools in parallel also has a cost. Similar
>> to forking hundreds and thousands of shell commands.
> In my mind, the most optimal feed is an in-process feed - no problems with
> security, inter-process/network comms overhead, etc.
>
> The way people do "small" monitoring IMHO, is to run many small scripts on
> schedule. Even if there is a thousand of them, they run for a short period of
> time so the load spreads nicely (usually, of course everything is a function
> of scale as we know from RHQ ;) ).
>
> Having 1 external process to do all monitoring, as we had in RHQ, has also its
> pros - for one it is easier to estimate the monitoring "cost" by looking at
> the memory and CPU consumption of the external agent.
>
>> _______________________________________________
>> 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


From jdoyle at redhat.com  Tue Mar 17 12:57:05 2015
From: jdoyle at redhat.com (John Doyle)
Date: Tue, 17 Mar 2015 12:57:05 -0400 (EDT)
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <55084D63.4000301@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
	<1840598.iiPUEzcYuK@localhost.localdomain>
	<55084D63.4000301@redhat.com>
Message-ID: <830285337.6782447.1426611425361.JavaMail.zimbra@redhat.com>

+1, we want to be up and running very rapidly, even if that means in a limited fashion.

~jd

----- Original Message -----
> I don't think we are on the same page regarding the focus of the
> project/product.
> 
> Hawkular is targeted toward Red Hat Middleware management, for
> infrastructure management there are gazillion other solutions.
> We need "some" basic infrastructure management, for those basic needs a
> user shouldn't need to maintain a solution made of multiple puzzle pieces.
> 
> Look at NewRelic or ruxit those are dead simple to install and to start
> monitoring.
> 
> Thomas
> 
> 
> 
> On 03/17/2015 04:17 PM, Lukas Krejci wrote:
> > On Tuesday, March 17, 2015 11:13:32 Heiko W.Rupp wrote:
> >> On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> >>> On the "agent side" there are more than plenty of tools that are
> >>> already in
> >>> use. We should first try to find ways of integrating with these tools
> >>> and only
> >>> when none of pre-existing stuff implements our usecase (in a good
> >>> enough way)
> >>> we should look to implement an "agent" of our own.
> >> What if the users does not have any of those tools installed?
> >> Do we tell them "install Ganglia, but not the graphing, only the
> >> monitoring".
> > I think that is going to just depend on the usecase. It might be easier to
> > tell them "install Ganglia" if it provides just the monitoring capabilities
> > they need. It also might be easier to tell them use Hawkular agent.
> >
> > Or they might have requirements that neither can meet.
> >
> >> Ah and as this does not cope well with WildFly 94 please install
> >> collectd on top?
> >>
> > I am pretty much sure Hawkular will have the same kind of problems. RHQ had
> > them for sure because incompatibilities are pretty much unavoidable IMHO.
> >
> >>> not some "heavy" agent in the RHQ sense.
> >> Running many of the small tools in parallel also has a cost. Similar
> >> to forking hundreds and thousands of shell commands.
> > In my mind, the most optimal feed is an in-process feed - no problems with
> > security, inter-process/network comms overhead, etc.
> >
> > The way people do "small" monitoring IMHO, is to run many small scripts on
> > schedule. Even if there is a thousand of them, they run for a short period
> > of
> > time so the load spreads nicely (usually, of course everything is a
> > function
> > of scale as we know from RHQ ;) ).
> >
> > Having 1 external process to do all monitoring, as we had in RHQ, has also
> > its
> > pros - for one it is easier to estimate the monitoring "cost" by looking at
> > the memory and CPU consumption of the external agent.
> >
> >> _______________________________________________
> >> 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
> 

From jpkroehling at redhat.com  Tue Mar 17 13:03:07 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Tue, 17 Mar 2015 18:03:07 +0100
Subject: [Hawkular-dev] Default user is (almost) there!
Message-ID: <55085E4B.2070204@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

Once the PR #50 [1] is merged, there will be a new Keycloak realm
available for dev builds, shipping with an user and without passwords
restrictions.

The username is "jdoe" and the password is "password". This will
automatically be available if you build Kettle with the "dev" maven
profile (hint: check your settings.xml).

For production builds (ie: without the "dev" profile active), there's
no such user and there are password restrictions inline with the rules
from Wildfly.

1 - https://github.com/hawkular/hawkular/pull/50

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVCF5LAAoJECKM1e+fkPrXsjgH/joCvprBiyx3CYdH9aR2WdA2
kAvi8KL+qn+fJYyhC0jKv6cVph85rffe3upu1LsqI07o/8ltxCGbPQofbYyKrOGS
mz6EtbZ8o1L6m3W+39SPBXJv0AYgeVuZq0f1zHVNIR0WwHny5+aos39G9At0R/eN
OykDKwocufK/O3NMxtLfS9Ra+WXtEzZX5DrhuWjQ2JCtbi1KVfZ8IQD4uG9jm9pD
QVRpVlPC/Ps9ZiH0CBKWFgBvBvFq4sftNB8Ix0XbYpp+2EHWCf/loqhyEJuWZLmL
TvpyLbcsPCiMeJY0yTVIcuErz2/i33+HvgFPGBq+9if44OmFBs7YIpsaAXWlXXM=
=SjPg
-----END PGP SIGNATURE-----

From lkrejci at redhat.com  Tue Mar 17 13:14:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Mar 2015 18:14:48 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <55084D63.4000301@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<1840598.iiPUEzcYuK@localhost.localdomain>
	<55084D63.4000301@redhat.com>
Message-ID: <1731416.BbdfZ1JBnX@localhost.localdomain>

On Tuesday, March 17, 2015 16:50:59 Thomas Heute wrote:
> I don't think we are on the same page regarding the focus of the
> project/product.
> 
> Hawkular is targeted toward Red Hat Middleware management, for
> infrastructure management there are gazillion other solutions.
> We need "some" basic infrastructure management, for those basic needs a
> user shouldn't need to maintain a solution made of multiple puzzle pieces.
> 
> Look at NewRelic or ruxit those are dead simple to install and to start
> monitoring.
> 

As great as ruxit is, it requires to run their agent as root, forcing itself 
into ld.so.preload and modifying selinux policies. That gave me a bit of 
shivers (https://answers.ruxit.com/questions/286/).

I thought Red Hat does things the UNIX/microservice way - integrating tools 
that do 1 thing and do it well. Hence my focus on integration.

I do hope we are on the same page, though. I was maybe a bit loud at stressing 
the integration aspect because I saw the tendencies to write yet another RHQ 
agent. IMHO, that is something we should try to avoid/minimize if possible 
(and I am not saying there won't be usecases requiring it - I just think it 
should not be the first choice when trying to implement something).

The good thing about integrating with 3rd party monitoring is that we get what 
they are able to monitor "for free" (where free is the cost of keeping 
ourselves compatible with the 3rd party tool ;) ) which enables our users to 
reuse the monitoring they most probably have already set up and only upgrade 
the server-side to a hopefully much more capable thing that Hawkular will be.

As I said already below, I think it is worth pursuing the in-process 
management where possible as that should avoid the pitfalls/usability problems 
we ran into with RHQ agent.

The proportion of work on in-process management versus the integration with 
3rd party tools vs out-of-process "full" agent is of course a function of 
priorities and project/product focus. I just wanted to try and persuade people 
that relying on there being an "Hawkular agent" is IMHO not the best solution 
to our overall "agent-side" architecture. It probably will be a part of the 
picture, but it should not be required, IMHO.

> Thomas
> 
> On 03/17/2015 04:17 PM, Lukas Krejci wrote:
> > On Tuesday, March 17, 2015 11:13:32 Heiko W.Rupp wrote:
> >> On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
> >>> On the "agent side" there are more than plenty of tools that are
> >>> already in
> >>> use. We should first try to find ways of integrating with these tools
> >>> and only
> >>> when none of pre-existing stuff implements our usecase (in a good
> >>> enough way)
> >>> we should look to implement an "agent" of our own.
> >> 
> >> What if the users does not have any of those tools installed?
> >> Do we tell them "install Ganglia, but not the graphing, only the
> >> monitoring".
> > 
> > I think that is going to just depend on the usecase. It might be easier to
> > tell them "install Ganglia" if it provides just the monitoring
> > capabilities
> > they need. It also might be easier to tell them use Hawkular agent.
> > 
> > Or they might have requirements that neither can meet.
> > 
> >> Ah and as this does not cope well with WildFly 94 please install
> >> collectd on top?
> > 
> > I am pretty much sure Hawkular will have the same kind of problems. RHQ
> > had
> > them for sure because incompatibilities are pretty much unavoidable IMHO.
> > 
> >>> not some "heavy" agent in the RHQ sense.
> >> 
> >> Running many of the small tools in parallel also has a cost. Similar
> >> to forking hundreds and thousands of shell commands.
> > 
> > In my mind, the most optimal feed is an in-process feed - no problems with
> > security, inter-process/network comms overhead, etc.
> > 
> > The way people do "small" monitoring IMHO, is to run many small scripts on
> > schedule. Even if there is a thousand of them, they run for a short period
> > of time so the load spreads nicely (usually, of course everything is a
> > function of scale as we know from RHQ ;) ).
> > 
> > Having 1 external process to do all monitoring, as we had in RHQ, has also
> > its pros - for one it is easier to estimate the monitoring "cost" by
> > looking at the memory and CPU consumption of the external agent.
> > 
> >> _______________________________________________
> >> 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


From theute at redhat.com  Wed Mar 18 04:32:56 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 18 Mar 2015 09:32:56 +0100
Subject: [Hawkular-dev] Inventory browsing UXD
Message-ID: <55093838.8090804@redhat.com>

We want to shift focus away from the "infrastructure focused" view to 
"application focused" view.
In that sense we'd rather traverse resources by relationships rather 
than plain parent/child like in RHQ.

The starting point should be an "application" a logical piece for the 
user. His Intranet, his e-commerce website, his b2b backend... (In fact 
I think we should let the user pinpoint the resource of his choice as 
starting points but if we can do for an "Application" we can easily do 
for a host or a server) (We'll fine-tune the notion of "application", 
OpenShift also has a related notion)

IMO an application is just a "virtual" resource with a collection of 
resources and some metadata, for instance a load balancer + EAP domain 
(and its EAP servers) + Database.
That resource will have a KPI associated with it and other information. 
It could also just be an "ear" file.

In terms of visualization, we would certainly like to see those 3 pieces 
(in that simple example) and be able to "zoom in" into one of them (to 
configure the load balancer), to see database metrics or to see the EAP 
servers and domain controller that forms the EAP domain.
The user should also be able to "zoom out", from a deployed ear to the 
EAP domain it's deployed on...
The user should also be able to look at the infrastructure (is EAP in 
some docker container ? how is the CPU/memory ?)

We'll also want to reflect health in those relationship, if my database 
is down, my "application" should reflect this.

It's going to be a challenge to get this right, with the right level of 
granularity/detail, but the user experience should be much better in 
most common situations.

For this we also need a good understanding of the relationship between 
all the resources, it should be mostly automated.

Thomas




From jsanda at redhat.com  Thu Mar 19 00:17:38 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 19 Mar 2015 00:17:38 -0400
Subject: [Hawkular-dev] [metrics] aggregate metrics
Message-ID: <C2AA03E5-3476-483D-9B36-17974BBF1C4D@redhat.com>

I have written up a short document[1] on initial support for aggregate metrics. Thanks in advance for any feedback.

[1] http://bit.ly/1BAfF8d <http://bit.ly/1BAfF8d>

- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150319/964f4e3e/attachment.html 

From ppalaga at redhat.com  Thu Mar 19 03:52:02 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 19 Mar 2015 08:52:02 +0100
Subject: [Hawkular-dev] Changes in upcoming Hawkular Parent v10
Message-ID: <550A8022.1020201@redhat.com>

Ladies and Gentlemen,

* Jirka added swagger plugin
https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L261
* Jirka also added two artifacts to dependencyManagement that are 
supposed to be used together with swagger plugin:
https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L185-L194

* My PRs https://github.com/hawkular/hawkular-build-tools/pull/13 and 
https://github.com/hawkular/hawkular-parent-pom/pull/19 are waiting for 
review. They upgrade license plugin to the last version 2.10. The most 
important change for all of you is

   <license.failIfUnknown>true</license.failIfUnknown> [1]

which causes the license verification to fail if the plugin sees a file 
that is neither ignored or has a license style definition. The 
motivation for this is, clearly, that we want to have 100% certainty 
that all files have proper headers.

See here how to ignore files in your project:
https://github.com/ppalaga/hawkular-alerts/commit/afa2b9e4839a64150c3449d3cdefa3e06c783b93#diff-d9833a3afb9198bca769bb318c86148aR128

The style definitions are done per file extension. Many file types are 
supported out of the box by the plugin (see [2]) and such a definition 
can be made ad hoc, too. We had such ones for .ts and .mustache in build 
tools [3], but they were recently accepted in upstream. Feel free to ask 
me if you need to cover some new file type.

I'd release Parent v10 just after merging the above two PRs unless 
anybody has some urgent topic for the next Parent.

Best,

Peter

[1] 
https://github.com/hawkular/hawkular-parent-pom/commit/4f16fc75bd8105858a077e6def04e2e3bacf73dc#diff-600376dffeb79835ede4a0b285078036R107

[2] 
https://github.com/mycila/license-maven-plugin/blob/master/license-maven-plugin/src/main/java/com/mycila/maven/plugin/license/header/HeaderType.java#L34

[3] 
https://github.com/hawkular/hawkular-build-tools/commit/510aebe891fdfedb14d353605f09416d8100ea45


From jkremser at redhat.com  Thu Mar 19 09:41:37 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Thu, 19 Mar 2015 09:41:37 -0400 (EDT)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <800729833.17117898.1425061705131.JavaMail.zimbra@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
	<2081603888.19682454.1424986552577.JavaMail.zimbra@redhat.com>
	<800729833.17117898.1425061705131.JavaMail.zimbra@redhat.com>
Message-ID: <1898078090.6027770.1426772497126.JavaMail.zimbra@redhat.com>

Hello,

I hit this issue so I'd like to 'reopen' the topic.

What about introducing a new repo only schemas and swagger docs. Not to mix it with the bus (dumb pipes principle). Currently the swagger is auto-pushed here https://github.com/hawkular/hawkular.github.io/tree/swagger and I think it's not perfect.

We need some shared API/serialization contract. The minimum is having it for the msg format. However message is often composed of concrete entities, arrays of entities, etc. We can go further and leverage the fact of composability. If we have schema for X it's easy to derive the schema for List<X>. I think each component should be autonomous enough and have right to define its own entity classes, but why to repeat all the time definition of, say, the resource? 

If there is an agreement how resource should look like, we can define it in the schema (possibly with a version).

Is 1 json message something like DTO (ad-hoc format, almost no patterns) or rather set of smaller well-defined "sub-messages" (possibly entities)? Of course, I am not talking about those stupid messages with something like "{ "result": 12 }".

wdyt?


----- Original Message -----
| From: "Stefan Negrea" <snegrea at redhat.com>
| To: "John Mazzitelli" <mazz at redhat.com>
| Cc: hawkular-dev at lists.jboss.org
| Sent: Friday, February 27, 2015 7:28:25 PM
| Subject: Re: [Hawkular-dev] generation of message POJOs via JSON schema
| 
| Hello,
| 
| Very seldom REST API's come with schemas; the typical workflow when working
| with REST:
| 1) read documentation about the rest end-point
| 2) if the project has a test site, try a few live queries
| 3) Write application code (TDD or not)
|  3.1) if something is wrong with the request, the service will return an
|  error; read the documentation again
|  3.2) if something is wrong with the reply (not what expected), then read the
|  documentation again
| 4) Add plenty of integration tests
| 
| This workflow gets simplified if the project provides an SDK for integration;
| but not by a lot, there is still documentation to be read, tests, errors,
| etc.
| 
| Because of JSON's ease of use and the possibility of implementing the client
| in many languages/frameworks, the schemas are no longer relevant. Good
| documentation (with examples), good REST API design, good errors, a live
| test tool, and an SDK are far more important.
| 
| Here are a few samples on how Google, Facebook, Twitter, ans AWS approach
| this:
| 1) Documentation:
| https://developers.facebook.com/docs/graph-api/reference/v2.2/album/photos
| 2) Documentation: https://developers.google.com/accounts/docs/OAuth2WebServer
| 3) Test Tool:
| https://developers.google.com/apis-explorer/#p/blogger/v3/blogger.blogs.getByUrl
| 4) Documentation:
| https://dev.twitter.com/rest/reference/get/statuses/home_timeline
| 5) SDK: http://aws.amazon.com/sdk-for-python/
| 
| With all this being said, here is how I would see using these tools in
| Hawkular:
| 1) Do all the work in the individual projects (write classes; annotated
| classes if necessary).
| 2) Use a tool to generate schemas from code
| 3) Make the schemas definitions part of the documentation or SDK
| 
| 
| I like the concepts from swagger tool that Micke talked about because you can
| drive the schema generation from the code. Now if we find a tool that is
| bi-directional, that's even better. The users and community members could
| then use the schemas to generate our code for their own applications to
| interact with Hawkular.
| 
| 
| Now, one thing that I would be very concerned to see is transforming the bus
| into a central repository and source for schemas. The bus should be designed
| following the "dumb pipes" [1] principle. It should take care of delivery
| but never ever inspect or make decisions based on actual content piped.
| 
| [1]
| http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes
| 
| 
| 
| Thank you,
| Stefan
| 
| 
| ----- Original Message -----
| > From: "John Mazzitelli" <mazz at redhat.com>
| > To: hawkular-dev at lists.jboss.org
| > Sent: Thursday, February 26, 2015 3:35:52 PM
| > Subject: Re: [Hawkular-dev] generation of message POJOs via JSON schema
| > 
| > Here's an example PR that can show where we can build this "glue code":
| > 
| > https://github.com/hawkular/hawkular/pull/31
| > 
| > It's a JSON schema with generated POJOs. In this case, it is just the
| > metrics. Stefan mentioned he'd rather the metrics provide this - which is
| > fine, we don't have to merge this PR - we just do something similar in the
| > metrics repo rather than in the hawkular project itself.
| > 
| > But the point is, this shows how we can produce a small jar with just the
| > JSON schema files and the Java classes that represent those JSON objects.
| > These generated POJOs play nice with the bus infrastructure and the API we
| > are using to produce/consume messages.
| > _______________________________________________
| > 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
| 

From hrupp at redhat.com  Thu Mar 19 10:15:00 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 19 Mar 2015 15:15:00 +0100
Subject: [Hawkular-dev] Breaking (REST-) api changes
Message-ID: <69CBCA99-12EB-4537-BF60-9CD236D31804@redhat.com>

Hello,

please if you can't resist making breaking changes in (REST) apis, at 
least announce them here.

There are clients / consumers out there that may need to change.
There may be easy cases like the consumer is in one of our repos.
Or it may be somewhere totally different.

From ppalaga at redhat.com  Thu Mar 19 10:54:05 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 19 Mar 2015 15:54:05 +0100
Subject: [Hawkular-dev] Changes in upcoming Hawkular Parent v10
In-Reply-To: <550A8022.1020201@redhat.com>
References: <550A8022.1020201@redhat.com>
Message-ID: <550AE30D.9090607@redhat.com>

hawkular-parent 10 was released today. I have sent PRs to upgrade it to 
(hopefully?) all hawkular projects. -- P


On 03/19/2015 08:52 AM, Peter Palaga wrote:
> Ladies and Gentlemen,
>
> * Jirka added swagger plugin
> https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L261
> * Jirka also added two artifacts to dependencyManagement that are
> supposed to be used together with swagger plugin:
> https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L185-L194
>
> * My PRs https://github.com/hawkular/hawkular-build-tools/pull/13 and
> https://github.com/hawkular/hawkular-parent-pom/pull/19 are waiting for
> review. They upgrade license plugin to the last version 2.10. The most
> important change for all of you is
>
>     <license.failIfUnknown>true</license.failIfUnknown> [1]
>
> which causes the license verification to fail if the plugin sees a file
> that is neither ignored or has a license style definition. The
> motivation for this is, clearly, that we want to have 100% certainty
> that all files have proper headers.
>
> See here how to ignore files in your project:
> https://github.com/ppalaga/hawkular-alerts/commit/afa2b9e4839a64150c3449d3cdefa3e06c783b93#diff-d9833a3afb9198bca769bb318c86148aR128
>
> The style definitions are done per file extension. Many file types are
> supported out of the box by the plugin (see [2]) and such a definition
> can be made ad hoc, too. We had such ones for .ts and .mustache in build
> tools [3], but they were recently accepted in upstream. Feel free to ask
> me if you need to cover some new file type.
>
> I'd release Parent v10 just after merging the above two PRs unless
> anybody has some urgent topic for the next Parent.
>
> Best,
>
> Peter
>
> [1]
> https://github.com/hawkular/hawkular-parent-pom/commit/4f16fc75bd8105858a077e6def04e2e3bacf73dc#diff-600376dffeb79835ede4a0b285078036R107
>
> [2]
> https://github.com/mycila/license-maven-plugin/blob/master/license-maven-plugin/src/main/java/com/mycila/maven/plugin/license/header/HeaderType.java#L34
>
> [3]
> https://github.com/hawkular/hawkular-build-tools/commit/510aebe891fdfedb14d353605f09416d8100ea45
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lkrejci at redhat.com  Thu Mar 19 11:14:14 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 19 Mar 2015 16:14:14 +0100
Subject: [Hawkular-dev] Inventory changed
Message-ID: <7065446.gfnGLt5pYm@localhost.localdomain>

Hey,

this is just to inform you that we finally merged the "future" branch of 
inventory into the master.

This doesn't actually change anything for people that used to depend on the 
old 1.0.0-SNAPSHOT builds of inventory. Those are still available in 
repositories and will not change.

The merged code changed version to 0.0.1-SNAPSHOT.

What this means is that once the integration with the "new" inventory is 
ready, you can just swap the version of inventory from 1.0.0-SNAPSHOT to 
0.0.1-SNAPSHOT (or whatever version it will at the time) and you will be using 
the new stuff.

Why we rolled the version back?

Because we want to follow the semantic versioning and starting at 1.0.0-
SNAPSHOT didn't give us much room to "breathe". Having a 0.y.z versioning 
scheme enables us to introduce incompatible changes yet allow people to still 
depend on the older versions if they are not ready to move.

We also didn't want to release "timed snapshots" of 1.0.0. This is more a 
matter of personal taste, but I'd rather depend on 0.2.3 than on 
1.0.0-20150314-5. While timed snapshots would give us the same benefits as 
0.y.z versioning, we chose the subjectively better readability of 0.y.z over 
timed snapshots.

If you ever wanted to look at the code as it existed prior to the big merge, 
the github repo has the "mvp-poc" tag that points to the last version of the 
"old" inventory code.

Thanks,

Lukas



From hrupp at redhat.com  Fri Mar 20 06:20:17 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 11:20:17 +0100
Subject: [Hawkular-dev] RfC: Availability
Message-ID: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>

Hey,

there was apparently some watercooler discussion yesterday without any 
minutes, so the following
will not be able to refer to it in any way.

Hawkular needs to have a way to store, retrieve and display availability 
of a resource or a bunch of them [1].

While we have some short term goals, for the longer run we need to 
better identify what needs to be done.
I think we need to separately look at the following concerns:

* availability reporting
   * api
   *values
* availability computation
* availability storage
* availability retrieval
* alerting on availability
* computed resource state

The basic assumption here is that availability is something relatively 
stable. Meaning that usually
the same state (hopefully "UP") is reported each time in a row for a 
veeery long period of time (there
are some servers with uptimes >> 1 year).

== reporting

Feeds report availability to Hawkular, where the data may be further 
processed and stored.
The reported values are probably in the range of "UP", "DOWN". I can 
also imagine that e.g.
an application server that starts shutting down could send a 
"GOING_DOWN" value.

On the API side, we need to be able to receive (a list of) tuples
`< resource id, report time, state >`
In case of full Hawkular, the _resource id_ needs to be a valid one from 
Inventory.
_Report time_ is the local time on the resource / agent when that state 
was retrieved,
represented in ms since the epoch UTC and
then finally the _state_ which would be an Enum of "UP", "DOWN" and 
potentially some other
values. While I have described them as string here, the representation 
on the wire may be
implemented differently like 1 and 0 or true and false.


== computed availability

In addition to above reporting we may have feeds that either are not 
able to deliver availability or
where the availability is delivered as a numeric value - see e.g. the 
pinger, where a <rid>.status.code
is delivered as metric value representing the http status codes.
Here we need to be apply a mapping from return code -> availability.

     f(code) ->  code < 400 ? "UP" : "DOWN"

and then further proceed with that computed availability value.

See also [2] and [3]

=== "Backfill"

As feeds may not report back all the time, we may want to have a 
watchdog which adds
a transition into "UNKNOWN" state.


=== Admin-down

A feed may discover resources that report their state as DOWN but where 
this is not an issue and rather an
administrative decision. Take a network card as example where the card 
as 8 ports, but only 4 of them
are connected. So the other 4 will be reported as DOWN, but in fact they 
are DOWN on purpose.
The admin may mark those interfaces as ADMIN_DOWN, which also implies 
that further incoming
DOWN-reports (what about UP, UNKNOWN?) reports can be ignored until the 
admin re-enables the
interface.
This admin-down probably also needs to be marked in inventory.

=== Maintenance mode

On top of the availability we also have maintenance mode which is 
orthogonal to availability and is more meant for alert suppression and 
SLA computation. Maintenance mode should not overwrite the recorded or 
computed availability.
We still want to record the original state no matter how maintenance 
mode is.

== Storage

As I wrote earlier, the base assumption is that availability is supposed 
to stay the same for
long periods of time. For that reason run-length encoded storage is 
advised

     < resource id, state, from , to >

The fields are more or less self-explanatory - to would be "null" if the 
current state continues.

This is also sort of what we have done in RHQ, where we have also been 
running into some issues,
(especially as we had a very db-bound approach). One issue is that if 
you have a transition from UP to DOWN

the DB situation looks like this:

Start:
     <rid , UP,  from1 , null >

up-> Down at time = from2

find tuple <rid, ??, ??, null > and update to
     <rid, UP, from1, from2>
append new tuple
      <rid, DOWN, from2, null>

The other issue is to get the current availability (for display in UI 
and/or in the previous transition)

find tuple <rid, ??, ??, null>

which are expensive.

The retrieval of the current availability for a resource can be improved 
by introducing a cache that stores
as minimal information  <rid, last state>.

Another issue that Yak pointed out is that if availability is recorded 
infrequently and at random points in time,
just recording when a transition from UP to DOWN or even UNKNOWN 
happened may be not enough, as there are scenarios when it is still 
important to know when we heard the last UP report.

So above storage (and cache) tuple needs to be extended to contain the 
_last heard_ time:

     < resource id, state, from , to, last_head >

In this case, as we do not want to update that record for each incoming 
availability report, we need to really
cache this information and have either some periodic write back to the 
store or at least when a shutdown listener indicates that Hawkular is 
going down. In case that we have multiple API endpoints that receive 
alert reports , this may need to be a distributed cache.


== Retrieval

Retrieval of availability information may actually a bit more tricky as 
returning the current availability state,
as there will be more information to convey:

We have two basic cases
* return current availability / resource state : this can probably be 
answered directly from above mentioned cache
* return a timeline between some arbitrary start and end times. Here we 
need to go out and return all records
that satisfy something like ( start_time < requested start && end_time > 
requested start ) || (start_time > requested start && end_time <= 
requested_end  )

=== application / group of resources

For applications the situation becomes more complicated as we need to 
retrieve the state (records) for each involved resource and then compute 
the total state of the application.

Take an app with a load balancer, 3 app servers and a DB then this 
computation may go like

     avail ( app  ) :=
          UP  if all resources are UP
          MIXED  if one app server  is not UP
          DOWN otherwise

Actually this may even contain a time component

     avail ( app , time of day ) :=
          if (business_hours (time of day) )
              UP  if all resources are UP
              MIXED  if one app server  is not UP
              DOWN otherwise
          else
              UP  if all resources are UP
              MIXED  if two app servers are not UP
              DOWN otherwise


It may be a good idea to not compute that on the fly at retrieval time, 
but to add the result as synthetic availability records for the 
computation into the normal availability processing stream as indicated 
earlier in the "computed availability" section. This way, the computed 
information is also available for alerting as input

== Alerting on availability

Alerting will need to see the (computed) availability data and also the 
maintenance mode information to be able to
alert on
* is UP/DOWN/...  ( for X time )
* goes UP/DOWN/...

With the above I think that alerting should not need to do complex 
availability calculations on its own, but rather
work on the stream of incoming (compute


[1] https://issues.jboss.org/browse/HWKMETRICS-35
[2] http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html
[3] http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000402.html

From lkrejci at redhat.com  Fri Mar 20 08:55:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 20 Mar 2015 13:55:48 +0100
Subject: [Hawkular-dev] RfC: Availability
In-Reply-To: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
Message-ID: <1997792.nRBWP4ZPt4@localhost.localdomain>

Great write-up Heiko, let me try to intersperse the outcomes of the 
yesterday's watercooler into it so that we get the discussion started.

tl;dr - your ideas match almost exactly what we discussed on the meeting ;)

The basic outcome of the meeting IMHO was that availability is in its most 
generic form a computed value and that the feeds might not be able to decide 
whether something is up or down. Judging such thing on "logical" resources 
like "applications" must be handled at some other layer either by polling for 
other data on a schedule and reporting the findings back into Hawkular by a 
completely 3rd party "reporter" or maybe such reporters would be hooked on the 
bus to receive "realtime" info about events and be able to compute the avail 
reactively.

Also, it was agreed that even the availability states are not something we can 
decide upfront. Maybe we'd provide a number of avail values with undefined 
meaning that only avail "reporter" would be able define or we could understand 
avail as "health" ranging from 0-100% and again let the avail reporter decide 
on a value.

On metrics level, the agreement was to keep the "availability" endpoints to be 
able to distinguish it from "normal" metrics. But there also were suggestions 
to just be able to mark some metrics as run-length encoded and consider avail 
as an ordinary metric.

Other subsystems need to distinguish between avail and other metrics. 
Especially inventory needs to be told which metric corresponds to an avail 
value for particular resource.

On Friday, March 20, 2015 11:20:17 Heiko W.Rupp wrote:
> Hey,
> 
> there was apparently some watercooler discussion yesterday without any
> minutes, so the following
> will not be able to refer to it in any way.
> 
> Hawkular needs to have a way to store, retrieve and display availability
> of a resource or a bunch of them [1].
> 
> While we have some short term goals, for the longer run we need to
> better identify what needs to be done.
> I think we need to separately look at the following concerns:
> 
> * availability reporting
>    * api
>    *values
> * availability computation
> * availability storage
> * availability retrieval
> * alerting on availability
> * computed resource state
> 
> The basic assumption here is that availability is something relatively
> stable. Meaning that usually
> the same state (hopefully "UP") is reported each time in a row for a
> veeery long period of time (there
> are some servers with uptimes >> 1 year).
> 
> == reporting
> 
> Feeds report availability to Hawkular, where the data may be further
> processed and stored.
> The reported values are probably in the range of "UP", "DOWN". I can
> also imagine that e.g.
> an application server that starts shutting down could send a
> "GOING_DOWN" value.
> 

If the feed is able to report on a "state" of something, I imagine we need at 
least 3 states: UP, DOWN and UNKNOWN. I imagine that a feed in and of itself 
wouldn't be able to report more elaborate states like "degraded" or "half-
functional" or "up but rest api under heavy load" or such like.

I imagine there either being a reporter that would compute such more involved 
states somewhere "up in the pipeline" or there could be some default simple 
translation like UP = 100%, DOWN = 0%, UNKNOWN = UNKNOWN (btw. I think 
"unknown" should be implicitly possible on any metric when I think about it, 
because it is distinctively different from "not collected").

The problem with GOING_DOWN is that it seems to me to be a one time event 
rather than a value of a metric.

> On the API side, we need to be able to receive (a list of) tuples
> `< resource id, report time, state >`
> In case of full Hawkular, the _resource id_ needs to be a valid one from
> Inventory.

The inventory has metrics and resources decoupled from each other with just an 
m:n relationship between them. As such, I think inventory will just mark one 
of such relationships with an "avail" flag.

The tuples therefore will just be

`< avail_id, report_time, state >`

> _Report time_ is the local time on the resource / agent when that state
> was retrieved,
> represented in ms since the epoch UTC and
> then finally the _state_ which would be an Enum of "UP", "DOWN" and
> potentially some other
> values. While I have described them as string here, the representation
> on the wire may be
> implemented differently like 1 and 0 or true and false.
> 
> 
> == computed availability
> 
> In addition to above reporting we may have feeds that either are not
> able to deliver availability or
> where the availability is delivered as a numeric value - see e.g. the
> pinger, where a <rid>.status.code
> is delivered as metric value representing the http status codes.
> Here we need to be apply a mapping from return code -> availability.
> 
>      f(code) ->  code < 400 ? "UP" : "DOWN"
> 
> and then further proceed with that computed availability value.
>

Yes, exactly. Further to this, I think we may want (on case by case basis, I 
think) to actually NOT store the reported value but only store the computed 
one.
 
> See also [2] and [3]
> 
> === "Backfill"
> 
> As feeds may not report back all the time, we may want to have a
> watchdog which adds
> a transition into "UNKNOWN" state.
>

+1
 
> 
> === Admin-down
> 
> A feed may discover resources that report their state as DOWN but where
> this is not an issue and rather an
> administrative decision. Take a network card as example where the card
> as 8 ports, but only 4 of them
> are connected. So the other 4 will be reported as DOWN, but in fact they
> are DOWN on purpose.
> The admin may mark those interfaces as ADMIN_DOWN, which also implies
> that further incoming
> DOWN-reports (what about UP, UNKNOWN?) reports can be ignored until the
> admin re-enables the
> interface.
> This admin-down probably also needs to be marked in inventory.
>

I am not sure we even want to have ADMIN_DOWN as an explicit avail state. All 
we need to have is some kind of metric reporting that right now, a flag called 
ON_PURPOSE = true (this can be just another metric coming from an actual user 
for example or as you say it can be a property on a resource or even the avail 
metric itself in inventory (every entity in inventory can store arbitrary key-
value pairs)). 

We still can have avail UP or DOWN reported but because we know that this is 
ON_PURPOSE, alerts may choose to react differently for example.

> === Maintenance mode
> 
> On top of the availability we also have maintenance mode which is
> orthogonal to availability and is more meant for alert suppression and
> SLA computation. Maintenance mode should not overwrite the recorded or
> computed availability.
> We still want to record the original state no matter how maintenance
> mode is.
> 

+1

As with ADMIN_DOWN, this can be modeled in a number of ways.

> == Storage
> 
> As I wrote earlier, the base assumption is that availability is supposed
> to stay the same for
> long periods of time. For that reason run-length encoded storage is
> advised
> 
>      < resource id, state, from , to >
> 
> The fields are more or less self-explanatory - to would be "null" if the
> current state continues.
> 
> This is also sort of what we have done in RHQ, where we have also been
> running into some issues,
> (especially as we had a very db-bound approach). One issue is that if
> you have a transition from UP to DOWN
> 

This implies a read on each store of new incoming data. Logically, it makes 
sense, by I assume that internally, metrics will do this differently like for 
example actually store the raw values for a short-ish period of time and 
aggregate them to run-length encoded periodically.

> the DB situation looks like this:
> 
> Start:
>      <rid , UP,  from1 , null >
> 
> up-> Down at time = from2
> 
> find tuple <rid, ??, ??, null > and update to
>      <rid, UP, from1, from2>
> append new tuple
>       <rid, DOWN, from2, null>
> 

I think this is not precise. Let me illustrate on another example:

Incoming data:
1) <rid, t1, UP>
2) <rid, t2, UP>
3) <rid, t3, DOWN>

I think this should be encoded as:

<rid, UP, t1, t2>
<rid, UNKNOWN, t2, t3>
<rid, DOWN, t3, t3>


I.e. I would explicitly encode the information about the impossibility of 
knowing the precise time of going down. This also means that you know the last 
time you saw a resource up.

I would also not store the "null" for the last run-length encoded piece, 
because you actually don't know that the resource is still up. Instead if 
someone asks for avail at time t4 (before next avail report comes after t3), I 
would report "unknown, last seen "down" at t3).

(We could also just not store the UNKNOWN altogether and only interpret it 
from the lack of data for that period of time)

> The other issue is to get the current availability (for display in UI
> and/or in the previous transition)
> 
> find tuple <rid, ??, ??, null>
> 
> which are expensive.
> 
> The retrieval of the current availability for a resource can be improved
> by introducing a cache that stores
> as minimal information  <rid, last state>.
> 

+1

> Another issue that Yak pointed out is that if availability is recorded
> infrequently and at random points in time,
> just recording when a transition from UP to DOWN or even UNKNOWN
> happened may be not enough, as there are scenarios when it is still
> important to know when we heard the last UP report.
> 
> So above storage (and cache) tuple needs to be extended to contain the
> _last heard_ time:
> 
>      < resource id, state, from , to, last_head >
>

if we encode the transition from up to down as I outlined above, the last 
heard time is the start time of the unknown between the up and down.
 
> In this case, as we do not want to update that record for each incoming
> availability report, we need to really
> cache this information and have either some periodic write back to the
> store or at least when a shutdown listener indicates that Hawkular is
> going down. In case that we have multiple API endpoints that receive
> alert reports , this may need to be a distributed cache.
> 
> 
> == Retrieval
> 
> Retrieval of availability information may actually a bit more tricky as
> returning the current availability state,
> as there will be more information to convey:
> 
> We have two basic cases
> * return current availability / resource state : this can probably be
> answered directly from above mentioned cache
> * return a timeline between some arbitrary start and end times. Here we
> need to go out and return all records
> that satisfy something like ( start_time < requested start && end_time >
> requested start ) || (start_time > requested start && end_time <=
> requested_end  )
> 
> === application / group of resources
> 
> For applications the situation becomes more complicated as we need to
> retrieve the state (records) for each involved resource and then compute
> the total state of the application.
> 
> Take an app with a load balancer, 3 app servers and a DB then this
> computation may go like
> 
>      avail ( app  ) :=
>           UP  if all resources are UP
>           MIXED  if one app server  is not UP
>           DOWN otherwise
> 
> Actually this may even contain a time component
> 
>      avail ( app , time of day ) :=
>           if (business_hours (time of day) )
>               UP  if all resources are UP
>               MIXED  if one app server  is not UP
>               DOWN otherwise
>           else
>               UP  if all resources are UP
>               MIXED  if two app servers are not UP
>               DOWN otherwise
> 
> 
> It may be a good idea to not compute that on the fly at retrieval time,
> but to add the result as synthetic availability records for the
> computation into the normal availability processing stream as indicated
> earlier in the "computed availability" section. This way, the computed
> information is also available for alerting as input
>

+1
 
> == Alerting on availability
> 
> Alerting will need to see the (computed) availability data and also the
> maintenance mode information to be able to
> alert on
> * is UP/DOWN/...  ( for X time )
> * goes UP/DOWN/...
> 

I personally am a fan of avail being a percentage rather than a simple 
boolean. That makes the goes up/down less intuitive but if we understand the 
percentage as "health" it might not be that bad to understand:

alert on
   health < 50%

> With the above I think that alerting should not need to do complex
> availability calculations on its own, but rather
> work on the stream of incoming (compute
>

+1
 
> 
> [1] https://issues.jboss.org/browse/HWKMETRICS-35
> [2] http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html
> [3] http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000402.html
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Fri Mar 20 09:37:39 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 14:37:39 +0100
Subject: [Hawkular-dev] Availability
In-Reply-To: <1997792.nRBWP4ZPt4@localhost.localdomain>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
	<1997792.nRBWP4ZPt4@localhost.localdomain>
Message-ID: <920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>

On 20 Mar 2015, at 13:55, Lukas Krejci wrote:

> tl;dr - your ideas match almost exactly what we discussed on the 
> meeting ;)

Nice :-)

> completely 3rd party "reporter" or maybe such reporters would be 
> hooked on the
> bus to receive "realtime" info about events and be able to compute the 
> avail
> reactively.

Yes, which is in fact something I've started yesterday for pinger 
status.code
to metrics

>
> Also, it was agreed that even the availability states are not 
> something we can
> decide upfront. Maybe we'd provide a number of avail values with 
> undefined
> meaning that only avail "reporter" would be able define or we could 
> understand
> avail as "health" ranging from 0-100% and again let the avail reporter 
> decide
> on a value.

We may need to distinguish here between external value and internal
computed state.
For external values, I think what you say is just a different version of
the mapping function(s) I proposed.
For internal processing, I think we need to have a set of read-made
values that we map the external ones to.

In the computed resource state email I got those:

UP: Resource is available and working normally
DEGRADED: Resource is available but not at full performance
DOWN: Resource is at fault and not working normally
MISSING: The resource was recorded in inventory, but does not exist in 
reality (e.g. was deleted on file system)
ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin 
(e.g. a network interface on a 8 port card where only 1 cable is 
connected)
UNKNOWN: Resource state can not be determined
MIXED: for groups / applications

And then, but which I now think should be orthogonal:
MAINTENANCE: There is a scheduled maintenance period, availability may 
be UP or DOWN

>
> On metrics level, the agreement was to keep the "availability" 
> endpoints to be
> able to distinguish it from "normal" metrics. But there also were 
> suggestions
> to just be able to mark some metrics as run-length encoded and 
> consider avail
> as an ordinary metric.

I am not convinced (yet) that availability should be recorded into 
Hawkular-Metrics,
as the Metrics api is lacking the mapping functionality.
I rather think we need "Hawkular-Availability" which offers some 
end-points + api
and which then defers the storage to the Hawkular-Inventory metrics 
storage engine.

From jsanda at redhat.com  Fri Mar 20 10:36:51 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 10:36:51 -0400
Subject: [Hawkular-dev] Availability
In-Reply-To: <920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
	<1997792.nRBWP4ZPt4@localhost.localdomain>
	<920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
Message-ID: <F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>


> On Mar 20, 2015, at 9:37 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 20 Mar 2015, at 13:55, Lukas Krejci wrote:
> 
>> tl;dr - your ideas match almost exactly what we discussed on the 
>> meeting ;)
> 
> Nice :-)
> 
>> completely 3rd party "reporter" or maybe such reporters would be 
>> hooked on the
>> bus to receive "realtime" info about events and be able to compute the 
>> avail
>> reactively.
> 
> Yes, which is in fact something I've started yesterday for pinger 
> status.code
> to metrics
> 
>> 
>> Also, it was agreed that even the availability states are not 
>> something we can
>> decide upfront. Maybe we'd provide a number of avail values with 
>> undefined
>> meaning that only avail "reporter" would be able define or we could 
>> understand
>> avail as "health" ranging from 0-100% and again let the avail reporter 
>> decide
>> on a value.
> 
> We may need to distinguish here between external value and internal
> computed state.
> For external values, I think what you say is just a different version of
> the mapping function(s) I proposed.
> For internal processing, I think we need to have a set of read-made
> values that we map the external ones to.
> 
> In the computed resource state email I got those:
> 
> UP: Resource is available and working normally
> DEGRADED: Resource is available but not at full performance
> DOWN: Resource is at fault and not working normally
> MISSING: The resource was recorded in inventory, but does not exist in 
> reality (e.g. was deleted on file system)
> ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin 
> (e.g. a network interface on a 8 port card where only 1 cable is 
> connected)
> UNKNOWN: Resource state can not be determined
> MIXED: for groups / applications
> 
> And then, but which I now think should be orthogonal:
> MAINTENANCE: There is a scheduled maintenance period, availability may 
> be UP or DOWN
> 
>> 
>> On metrics level, the agreement was to keep the "availability" 
>> endpoints to be
>> able to distinguish it from "normal" metrics. But there also were 
>> suggestions
>> to just be able to mark some metrics as run-length encoded and 
>> consider avail
>> as an ordinary metric.
> 
> I am not convinced (yet) that availability should be recorded into 
> Hawkular-Metrics,
> as the Metrics api is lacking the mapping functionality.
> I rather think we need "Hawkular-Availability" which offers some 
> end-points + api
> and which then defers the storage to the Hawkular-Inventory metrics 
> storage engine.

I suppose I am a bit biased since I work on metrics, but I do think availability should be stored in metrics. I think that the mapping functionality belongs on the client/agent side just as it was in RHQ. Those mapping functions should probably stored be stored in inventory so that users can see precisely how availability is determined for a particular type of resource and so that the user can also change how availability is calculated.

From jsanda at redhat.com  Fri Mar 20 11:00:22 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 11:00:22 -0400
Subject: [Hawkular-dev] availability and metric endpoints
Message-ID: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>

There has been some good discussion around availability lately. I want to add one more to the mix, but hopefully this one is not as in-depth as some of the other topics. Right in metrics we have endpoints like,

POST   /metrics/numeric/data
GET     /metrics/numeric/{id}/data
POST  /metrics/availability/data
GET    /metrics/availability/{id}/data

I would like to change these to,

POST   /metrics/data
GET     /metrics/{id}/data
POST  /availability/data
GET    /availability/{id}/data

I think the ?metrics? prefix is awkward and unnecessary. I think that it is intuitive enough that metrics on its own refers to numeric data. Thoughts?


- John

From mithomps at redhat.com  Fri Mar 20 11:08:54 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 20 Mar 2015 08:08:54 -0700
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
Message-ID: <5B82834B-FDEE-4243-B799-ECA1B882B7AB@redhat.com>


> On 20 Mar 2015, at 08:00, John Sanda <jsanda at redhat.com> wrote:
> 
> There has been some good discussion around availability lately. I want to add one more to the mix, but hopefully this one is not as in-depth as some of the other topics. Right in metrics we have endpoints like,
> 
> POST   /metrics/numeric/data
> GET     /metrics/numeric/{id}/data
> POST  /metrics/availability/data
> GET    /metrics/availability/{id}/data
> 
> I would like to change these to,
> 
> POST   /metrics/data
> GET     /metrics/{id}/data
> POST  /availability/data
> GET    /availability/{id}/data
> 
> I think the ?metrics? prefix is awkward and unnecessary. I think that it is intuitive enough that metrics on its own refers to numeric data. Thoughts?

I think the ?data? postfix is redundant as well.


> 
> 
> - John
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jsanda at redhat.com  Fri Mar 20 11:18:57 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 11:18:57 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <5B82834B-FDEE-4243-B799-ECA1B882B7AB@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<5B82834B-FDEE-4243-B799-ECA1B882B7AB@redhat.com>
Message-ID: <5E264F65-BE2A-4261-B2FB-4393EA51A75C@redhat.com>


> On Mar 20, 2015, at 11:08 AM, mike thompson <mithomps at redhat.com> wrote:
> 
>> 
>> On 20 Mar 2015, at 08:00, John Sanda <jsanda at redhat.com> wrote:
>> 
>> There has been some good discussion around availability lately. I want to add one more to the mix, but hopefully this one is not as in-depth as some of the other topics. Right in metrics we have endpoints like,
>> 
>> POST   /metrics/numeric/data
>> GET     /metrics/numeric/{id}/data
>> POST  /metrics/availability/data
>> GET    /metrics/availability/{id}/data
>> 
>> I would like to change these to,
>> 
>> POST   /metrics/data
>> GET     /metrics/{id}/data
>> POST  /availability/data
>> GET    /availability/{id}/data
>> 
>> I think the ?metrics? prefix is awkward and unnecessary. I think that it is intuitive enough that metrics on its own refers to numeric data. Thoughts?
> 
> I think the ?data? postfix is redundant as well.
> 

I agree, and we already have https://issues.jboss.org/browse/HWKMETRICS-24 <https://issues.jboss.org/browse/HWKMETRICS-24> for the data part. I will create a new ticket for the other proposed changes, and they can be addressed together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150320/eccf0be8/attachment.html 

From lkrejci at redhat.com  Fri Mar 20 11:19:25 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 20 Mar 2015 16:19:25 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
Message-ID: <1794732.esVurXqKhI@localhost.localdomain>

I think the "metrics" should actually be dropped instead of "numeric".

Hawk metrics will never deal with anything else than some kind of metric, so 
way have it in the path? On the other hand having the type of the metric in 
the path is IMHO more useful.

It is the context root of the metrics rest web app that should be called 
"metrics", IMHO.

So the paths in metrics would look like:

/{tenantId}/numeric/data
/{tenantId}/availability/data

and the REST API user would reach those on the URLs like:

http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data

conversely, inventory could be reached on the same host like:

http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}


On Friday, March 20, 2015 11:00:22 John Sanda wrote:
> There has been some good discussion around availability lately. I want to
> add one more to the mix, but hopefully this one is not as in-depth as some
> of the other topics. Right in metrics we have endpoints like,
> 
> POST   /metrics/numeric/data
> GET     /metrics/numeric/{id}/data
> POST  /metrics/availability/data
> GET    /metrics/availability/{id}/data
> 
> I would like to change these to,
> 
> POST   /metrics/data
> GET     /metrics/{id}/data
> POST  /availability/data
> GET    /availability/{id}/data
> 
> I think the ?metrics? prefix is awkward and unnecessary. I think that it is
> intuitive enough that metrics on its own refers to numeric data. Thoughts?
> 
> 
> - John
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jsanda at redhat.com  Fri Mar 20 11:29:56 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 11:29:56 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <1794732.esVurXqKhI@localhost.localdomain>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
Message-ID: <86594346-5FBB-452F-A9CB-ADF3A2BF47A3@redhat.com>

Good points. Looks like we need to think about this a bit more.


> On Mar 20, 2015, at 11:19 AM, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> I think the "metrics" should actually be dropped instead of "numeric".
> 
> Hawk metrics will never deal with anything else than some kind of metric, so 
> way have it in the path? On the other hand having the type of the metric in 
> the path is IMHO more useful.
> 
> It is the context root of the metrics rest web app that should be called 
> "metrics", IMHO.
> 
> So the paths in metrics would look like:
> 
> /{tenantId}/numeric/data
> /{tenantId}/availability/data
> 
> and the REST API user would reach those on the URLs like:
> 
> http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
> 
> conversely, inventory could be reached on the same host like:
> 
> http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}
> 
> 
> On Friday, March 20, 2015 11:00:22 John Sanda wrote:
>> There has been some good discussion around availability lately. I want to
>> add one more to the mix, but hopefully this one is not as in-depth as some
>> of the other topics. Right in metrics we have endpoints like,
>> 
>> POST   /metrics/numeric/data
>> GET     /metrics/numeric/{id}/data
>> POST  /metrics/availability/data
>> GET    /metrics/availability/{id}/data
>> 
>> I would like to change these to,
>> 
>> POST   /metrics/data
>> GET     /metrics/{id}/data
>> POST  /availability/data
>> GET    /availability/{id}/data
>> 
>> I think the ?metrics? prefix is awkward and unnecessary. I think that it is
>> intuitive enough that metrics on its own refers to numeric data. Thoughts?
>> 
>> 
>> - John
>> _______________________________________________
>> 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



From hrupp at redhat.com  Fri Mar 20 11:43:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 16:43:56 +0100
Subject: [Hawkular-dev] Availability
In-Reply-To: <F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
	<1997792.nRBWP4ZPt4@localhost.localdomain>
	<920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
	<F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>
Message-ID: <8CE3BD16-97AD-44B9-9B04-F2EBB41AEB46@redhat.com>

>> I am not convinced (yet) that availability should be recorded into
>> Hawkular-Metrics,
>> as the Metrics api is lacking the mapping functionality.
>> I rather think we need "Hawkular-Availability" which offers some
>> end-points + api
>> and which then defers the storage to the Hawkular-Inventory metrics
>> storage engine.
>
> I suppose I am a bit biased since I work on metrics, but I do think 
> availability should be stored in metrics. I think that the mapping

I did not write it should not be stored in metrics, but rather that it 
should
not be reported into metrics in the first place, but into a (logical)
availability component.

> functionality belongs on the client/agent side just as it was in RHQ.

Well, this only partially works, as an application most probably 
consists
of resources that are distributed over several machines and thus feeds.
In this case we need to take multiple values into account to compute
the final value.
Also in cases where e.g. we have an agent like in classic RHQ that 
monitors
an application and also a pinger in some other place, wich also pings 
that application.
Now suppose that the agent loses its connection to the server, but the 
pinger reports
the application as UP. In this case we may even want to override the 
"unknown"
information from the agent, as the pinger shows that the app is up.

> Those mapping functions should probably stored be stored in inventory 
> so that users can see precisely how availability is determined for a 
> particular type of resource and so that the user can also change how 
> availability is calculated.

Absolutely.

From mithomps at redhat.com  Fri Mar 20 12:03:19 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 20 Mar 2015 09:03:19 -0700
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <1794732.esVurXqKhI@localhost.localdomain>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
Message-ID: <A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>


> On 20 Mar 2015, at 08:19, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> I think the "metrics" should actually be dropped instead of "numeric?.

The only thing about ?numeric? is that it is not very specific. Numeric just means number ? every metric is a number so its really not adding anything. Even availability data is numeric.

> 
> Hawk metrics will never deal with anything else than some kind of metric, so 
> way have it in the path? On the other hand having the type of the metric in 
> the path is IMHO more useful.
> 
> It is the context root of the metrics rest web app that should be called 
> "metrics", IMHO.
> 
> So the paths in metrics would look like:
> 
> /{tenantId}/numeric/data
> /{tenantId}/availability/data
> 
> and the REST API user would reach those on the URLs like:
> 
> http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
> 
> conversely, inventory could be reached on the same host like:
> 
> http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}
> 
> 
> On Friday, March 20, 2015 11:00:22 John Sanda wrote:
>> There has been some good discussion around availability lately. I want to
>> add one more to the mix, but hopefully this one is not as in-depth as some
>> of the other topics. Right in metrics we have endpoints like,
>> 
>> POST   /metrics/numeric/data
>> GET     /metrics/numeric/{id}/data
>> POST  /metrics/availability/data
>> GET    /metrics/availability/{id}/data
>> 
>> I would like to change these to,
>> 
>> POST   /metrics/data
>> GET     /metrics/{id}/data
>> POST  /availability/data
>> GET    /availability/{id}/data
>> 
>> I think the ?metrics? prefix is awkward and unnecessary. I think that it is
>> intuitive enough that metrics on its own refers to numeric data. Thoughts?
>> 
>> 
>> - John
>> _______________________________________________
>> 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



From hrupp at redhat.com  Fri Mar 20 12:22:21 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 17:22:21 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
Message-ID: <04866A67-EBA8-46E8-9DD0-DDAB9520D398@redhat.com>

On 20 Mar 2015, at 17:03, mike thompson wrote:


> The only thing about ?numeric? is that it is not very specific. 
> Numeric just means number ? every metric is a number so its really 
> not adding anything. Even availability data is numeric.

on top it is "just double" and not a more specific format.
I often think that if we know that the input is an integer
format, we should process it as such.
But that is a different can of worms :)

From lkrejci at redhat.com  Fri Mar 20 12:23:48 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 20 Mar 2015 17:23:48 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
Message-ID: <2816525.LstGQiV138@localhost.localdomain>

On Friday, March 20, 2015 09:03:19 mike thompson wrote:
> > On 20 Mar 2015, at 08:19, Lukas Krejci <lkrejci at redhat.com> wrote:
> > 
> > I think the "metrics" should actually be dropped instead of "numeric?.
> 
> The only thing about ?numeric? is that it is not very specific. Numeric just
> means number ? every metric is a number so its really not adding anything.
> Even availability data is numeric.

Isn't metrics going to store "events" eventually, too? Those would be textual, 
wouldn't they?

Also, IMHO, even config could be stored in metrics. Even though that is a bit 
of a stretch, configuration is after all a time series of structured data...

You're right that at the moment numeric doesn't add much information. So maybe 
instead of that, the type would specify what should be done with the metric?

Something along the lines of dropwizard-metrics' distinction between a meter, 
counter, gauge, histogram, etc?

So like:

http://asdf.com/hawkular/metrics/tenant1/histogram/{id}
http://asdf.com/hawkular/metrics/tenant1/counter/{id}


> > Hawk metrics will never deal with anything else than some kind of metric,
> > so way have it in the path? On the other hand having the type of the
> > metric in the path is IMHO more useful.
> > 
> > It is the context root of the metrics rest web app that should be called
> > "metrics", IMHO.
> > 
> > So the paths in metrics would look like:
> > 
> > /{tenantId}/numeric/data
> > /{tenantId}/availability/data
> > 
> > and the REST API user would reach those on the URLs like:
> > 
> > http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
> > 
> > conversely, inventory could be reached on the same host like:
> > 
> > http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}
> > 
> > On Friday, March 20, 2015 11:00:22 John Sanda wrote:
> >> There has been some good discussion around availability lately. I want to
> >> add one more to the mix, but hopefully this one is not as in-depth as
> >> some
> >> of the other topics. Right in metrics we have endpoints like,
> >> 
> >> POST   /metrics/numeric/data
> >> GET     /metrics/numeric/{id}/data
> >> POST  /metrics/availability/data
> >> GET    /metrics/availability/{id}/data
> >> 
> >> I would like to change these to,
> >> 
> >> POST   /metrics/data
> >> GET     /metrics/{id}/data
> >> POST  /availability/data
> >> GET    /availability/{id}/data
> >> 
> >> I think the ?metrics? prefix is awkward and unnecessary. I think that it
> >> is
> >> intuitive enough that metrics on its own refers to numeric data.
> >> Thoughts?
> >> 
> >> 
> >> - John
> >> _______________________________________________
> >> 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



From hrupp at redhat.com  Fri Mar 20 12:29:35 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 17:29:35 +0100
Subject: [Hawkular-dev] ADMIN: set reply-to list?
Message-ID: <24B42F92-F433-4620-B390-95E0FEB763AE@redhat.com>

Hey,

currently the reply-to for this list is not set,
to hitting reply makes the reply only go to the
author of an article and hitting reply all will also
put the author in cc.

Are there objections to add a reply-to header that
points to the list, so that simple replies go to this
list?

Thanks
   Heiko

From jsanda at redhat.com  Fri Mar 20 12:35:13 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 12:35:13 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
Message-ID: <75541DFF-F49D-448D-BD63-CB8F4F1DC155@redhat.com>


> On Mar 20, 2015, at 12:03 PM, mike thompson <mithomps at redhat.com> wrote:
> 
>> 
>> On 20 Mar 2015, at 08:19, Lukas Krejci <lkrejci at redhat.com <mailto:lkrejci at redhat.com>> wrote:
>> 
>> I think the "metrics" should actually be dropped instead of "numeric?.
> 
> The only thing about ?numeric? is that it is not very specific. Numeric just means number ? every metric is a number so its really not adding anything. Even availability data is numeric.

Metrics might not just be numeric. Right now we have simple numeric and availability. We will probably have events at in the future. We might also have multi-value numeric metrics, e.g., call time in RHQ. And I could also see multi-value metrics consisting of numeric and text data.

> 
>> 
>> Hawk metrics will never deal with anything else than some kind of metric, so 
>> way have it in the path? On the other hand having the type of the metric in 
>> the path is IMHO more useful.
>> 
>> It is the context root of the metrics rest web app that should be called 
>> "metrics", IMHO.
>> 
>> So the paths in metrics would look like:
>> 
>> /{tenantId}/numeric/data
>> /{tenantId}/availability/data
>> 
>> and the REST API user would reach those on the URLs like:
>> 
>> http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
>> 
>> conversely, inventory could be reached on the same host like:
>> 
>> http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}
>> 
>> 
>> On Friday, March 20, 2015 11:00:22 John Sanda wrote:
>>> There has been some good discussion around availability lately. I want to
>>> add one more to the mix, but hopefully this one is not as in-depth as some
>>> of the other topics. Right in metrics we have endpoints like,
>>> 
>>> POST   /metrics/numeric/data
>>> GET     /metrics/numeric/{id}/data
>>> POST  /metrics/availability/data
>>> GET    /metrics/availability/{id}/data
>>> 
>>> I would like to change these to,
>>> 
>>> POST   /metrics/data
>>> GET     /metrics/{id}/data
>>> POST  /availability/data
>>> GET    /availability/{id}/data
>>> 
>>> I think the ?metrics? prefix is awkward and unnecessary. I think that it is
>>> intuitive enough that metrics on its own refers to numeric data. Thoughts?
>>> 
>>> 
>>> - John
>>> _______________________________________________
>>> 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 <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150320/e933d6b9/attachment.html 

From jsanda at redhat.com  Fri Mar 20 12:42:35 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 12:42:35 -0400
Subject: [Hawkular-dev] Availability
In-Reply-To: <8CE3BD16-97AD-44B9-9B04-F2EBB41AEB46@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>
	<1997792.nRBWP4ZPt4@localhost.localdomain>
	<920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
	<F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>
	<8CE3BD16-97AD-44B9-9B04-F2EBB41AEB46@redhat.com>
Message-ID: <DB16DFC9-2D1D-41A5-AA57-DF3B55787EEE@redhat.com>


> On Mar 20, 2015, at 11:43 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
>>> I am not convinced (yet) that availability should be recorded into
>>> Hawkular-Metrics,
>>> as the Metrics api is lacking the mapping functionality.
>>> I rather think we need "Hawkular-Availability" which offers some
>>> end-points + api
>>> and which then defers the storage to the Hawkular-Inventory metrics
>>> storage engine.
>> 
>> I suppose I am a bit biased since I work on metrics, but I do think 
>> availability should be stored in metrics. I think that the mapping
> 
> I did not write it should not be stored in metrics, but rather that it 
> should
> not be reported into metrics in the first place, but into a (logical)
> availability component.
> 
>> functionality belongs on the client/agent side just as it was in RHQ.
> 
> Well, this only partially works, as an application most probably 
> consists
> of resources that are distributed over several machines and thus feeds.
> In this case we need to take multiple values into account to compute
> the final value.
> Also in cases where e.g. we have an agent like in classic RHQ that 
> monitors
> an application and also a pinger in some other place, wich also pings 
> that application.
> Now suppose that the agent loses its connection to the server, but the 
> pinger reports
> the application as UP. In this case we may even want to override the 
> "unknown"
> information from the agent, as the pinger shows that the app is up.

Great point about multiple resources. I have to therefore slightly refine my previous statement. I think that the functionality belongs on the agent. As I said in the agent discussions, I think that there are use cases for different types of agents - embedded, c-located, and remote. For the example of monitoring availability for a resource (or resources) spanning several machines, I think it should be the job of a remote agent. Maybe that remote agent is running inside the hawkular server. I am not sure. They key though is that the approach is consistent in terms of who is applying that availability function.

> 
>> Those mapping functions should probably stored be stored in inventory 
>> so that users can see precisely how availability is determined for a 
>> particular type of resource and so that the user can also change how 
>> availability is calculated.
> 
> Absolutely.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From hrupp at redhat.com  Fri Mar 20 12:47:18 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Mar 2015 17:47:18 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <75541DFF-F49D-448D-BD63-CB8F4F1DC155@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<75541DFF-F49D-448D-BD63-CB8F4F1DC155@redhat.com>
Message-ID: <398507CB-F535-4F9D-872A-BCD4CF9BC51F@redhat.com>

On 20 Mar 2015, at 17:35, John Sanda wrote:

> Metrics might not just be numeric. Right now we have simple numeric 
> and availability. We will probably have events at in the future. We 
> might also have multi-value numeric metrics, e.g., call time in RHQ. 
> And I could also see multi-value metrics consisting of numeric and 
> text data.

You mean, as everything in software is internally represented as bits, 
which
are number 0 and 1, everything is a long number and thus belongs
into Hawkular-metrics?

SCNR


From jsanda at redhat.com  Fri Mar 20 12:47:20 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 12:47:20 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <2816525.LstGQiV138@localhost.localdomain>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
Message-ID: <98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>


> On Mar 20, 2015, at 12:23 PM, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Friday, March 20, 2015 09:03:19 mike thompson wrote:
>>> On 20 Mar 2015, at 08:19, Lukas Krejci <lkrejci at redhat.com> wrote:
>>> 
>>> I think the "metrics" should actually be dropped instead of "numeric?.
>> 
>> The only thing about ?numeric? is that it is not very specific. Numeric just
>> means number ? every metric is a number so its really not adding anything.
>> Even availability data is numeric.
> 
> Isn't metrics going to store "events" eventually, too? Those would be textual, 
> wouldn't they?
> 
> Also, IMHO, even config could be stored in metrics. Even though that is a bit 
> of a stretch, configuration is after all a time series of structured data...
> 
> You're right that at the moment numeric doesn't add much information. So maybe 
> instead of that, the type would specify what should be done with the metric?
> 
> Something along the lines of dropwizard-metrics' distinction between a meter, 
> counter, gauge, histogram, etc?
> 
> So like:
> 
> http://asdf.com/hawkular/metrics/tenant1/histogram/{id}
> http://asdf.com/hawkular/metrics/tenant1/counter/{id}
> 

My aggregate metrics design doc[1] talks about formally introducing gauges and counters. The question I have about endpoints like this is what about pushing a batch of metrics? Do we need to make a separate request for each type? That seems cumbersome and inefficient.

[1] http://bit.ly/1BAfF8d <http://bit.ly/1BAfF8d>


>>> Hawk metrics will never deal with anything else than some kind of metric,
>>> so way have it in the path? On the other hand having the type of the
>>> metric in the path is IMHO more useful.
>>> 
>>> It is the context root of the metrics rest web app that should be called
>>> "metrics", IMHO.
>>> 
>>> So the paths in metrics would look like:
>>> 
>>> /{tenantId}/numeric/data
>>> /{tenantId}/availability/data
>>> 
>>> and the REST API user would reach those on the URLs like:
>>> 
>>> http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
>>> 
>>> conversely, inventory could be reached on the same host like:
>>> 
>>> http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}
>>> 
>>> On Friday, March 20, 2015 11:00:22 John Sanda wrote:
>>>> There has been some good discussion around availability lately. I want to
>>>> add one more to the mix, but hopefully this one is not as in-depth as
>>>> some
>>>> of the other topics. Right in metrics we have endpoints like,
>>>> 
>>>> POST   /metrics/numeric/data
>>>> GET     /metrics/numeric/{id}/data
>>>> POST  /metrics/availability/data
>>>> GET    /metrics/availability/{id}/data
>>>> 
>>>> I would like to change these to,
>>>> 
>>>> POST   /metrics/data
>>>> GET     /metrics/{id}/data
>>>> POST  /availability/data
>>>> GET    /availability/{id}/data
>>>> 
>>>> I think the ?metrics? prefix is awkward and unnecessary. I think that it
>>>> is
>>>> intuitive enough that metrics on its own refers to numeric data.
>>>> Thoughts?
>>>> 
>>>> 
>>>> - John
>>>> _______________________________________________
>>>> 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/20150320/a7ad74d1/attachment.html 

From jsanda at redhat.com  Fri Mar 20 12:49:42 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 12:49:42 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <398507CB-F535-4F9D-872A-BCD4CF9BC51F@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<75541DFF-F49D-448D-BD63-CB8F4F1DC155@redhat.com>
	<398507CB-F535-4F9D-872A-BCD4CF9BC51F@redhat.com>
Message-ID: <60B5C07B-1147-48D3-B6D2-CB7312E59DBC@redhat.com>


> On Mar 20, 2015, at 12:47 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 20 Mar 2015, at 17:35, John Sanda wrote:
> 
>> Metrics might not just be numeric. Right now we have simple numeric and availability. We will probably have events at in the future. We might also have multi-value numeric metrics, e.g., call time in RHQ. And I could also see multi-value metrics consisting of numeric and text data.
> 
> You mean, as everything in software is internally represented as bits, which
> are number 0 and 1, everything is a long number and thus belongs
> into Hawkular-metrics?
> 
> SCNR
> 

well now that you mention it?. :)

From tsegismo at redhat.com  Fri Mar 20 13:10:02 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 18:10:02 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>
Message-ID: <550C546A.9080702@redhat.com>

Sorry, very late reply. Others to come.

Le 17/03/2015 11:10, Heiko W.Rupp a ?crit :
> Past experience has shown that users like the fact that the
> (RHQ/Hawkular)
> server is not talking to all the end-resources  / - processes
> individually, but
> that this is channeled through the agent.

We could enhance ptrans to turn it into some sort of proxy for the 
Metrics API.

From tsegismo at redhat.com  Fri Mar 20 13:17:39 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 18:17:39 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
Message-ID: <550C5633.5010109@redhat.com>

Le 17/03/2015 11:13, Heiko W.Rupp a ?crit :
> What if the users does not have any of those tools installed?
> Do we tell them "install Ganglia, but not the graphing, only the
> monitoring".
> Ah and as this does not cope well with WildFly 94 please install
> collectd on top?
>

 From my perspective, there's no point in writing collectd/ganglia/... 
plugins for JBoss middleware projects.

The value I see in integrating with third party collectors is that users 
may have their own scripts/plugins or use one of their many community 
plugins.

> Running many of the small tools in parallel also has a cost. Similar
> to forking hundreds and thousands of shell commands.

I'm not sure about others, but you could run a few collectd processes in 
parallel and still have a lower memory footprint than a single JVM :)


From tsegismo at redhat.com  Fri Mar 20 13:23:14 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 18:23:14 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <550C546A.9080702@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1857556038.27965676.1426096631375.JavaMail.zimbra@redhat.com>	<5500933D.9010507@redhat.com>	<895251803.28067677.1426104772670.JavaMail.zimbra@redhat.com>	<1733669769.28892430.1426185271542.JavaMail.zimbra@redhat.com>	<1162641959.27285992.1426493621110.JavaMail.zimbra@redhat.com>	<B555EF84-8870-40B5-993A-5737D262C479@redhat.com>	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>	<E9EF7983-FF8B-44F8-8B26-F2378A91AAB7@redhat.com>
	<550C546A.9080702@redhat.com>
Message-ID: <550C5782.4070701@redhat.com>

Le 20/03/2015 18:10, Thomas Segismont a ?crit :
> Sorry, very late reply. Others to come.
>
> Le 17/03/2015 11:10, Heiko W.Rupp a ?crit :
>> Past experience has shown that users like the fact that the
>> (RHQ/Hawkular)
>> server is not talking to all the end-resources  / - processes
>> individually, but
>> that this is channeled through the agent.
>
> We could enhance ptrans to turn it into some sort of proxy for the
> Metrics API.

Just realized you were talking about the server to managed resource use 
case.



From tsegismo at redhat.com  Fri Mar 20 13:42:15 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 18:42:15 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <55084D63.4000301@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>	<1840598.iiPUEzcYuK@localhost.localdomain>
	<55084D63.4000301@redhat.com>
Message-ID: <550C5BF7.2080303@redhat.com>

Le 17/03/2015 16:50, Thomas Heute a ?crit :
> Look at NewRelic or ruxit those are dead simple to install and to start
> monitoring.

AFAIK, with NewRelic you have to install:
* their _sysmond_ for OS level monitoring
* a Java agent (a true JVM agent, not an external process written in 
Java) for each JVM you want to monitor

I don't know about ruxit

From tsegismo at redhat.com  Fri Mar 20 14:07:52 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 19:07:52 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <55084D63.4000301@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>	<1840598.iiPUEzcYuK@localhost.localdomain>
	<55084D63.4000301@redhat.com>
Message-ID: <550C61F8.5050607@redhat.com>

Le 17/03/2015 16:50, Thomas Heute a ?crit :
> I don't think we are on the same page regarding the focus of the
> project/product.
>
> Hawkular is targeted toward Red Hat Middleware management, for
> infrastructure management there are gazillion other solutions.
> We need "some" basic infrastructure management, for those basic needs a
> user shouldn't need to maintain a solution made of multiple puzzle pieces.

So in this thread we talked about what we want the user experience to be 
(simple install, works across different systems) and what we don't the 
developer experience to be (with the RHQ agent pain points in mind).

That's important but could we elaborate on the use cases we want to 
solve in the next milestones?

From tsegismo at redhat.com  Fri Mar 20 14:12:13 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Mar 2015 19:12:13 +0100
Subject: [Hawkular-dev] ADMIN: set reply-to list?
In-Reply-To: <24B42F92-F433-4620-B390-95E0FEB763AE@redhat.com>
References: <24B42F92-F433-4620-B390-95E0FEB763AE@redhat.com>
Message-ID: <550C62FD.9000609@redhat.com>

Le 20/03/2015 17:29, Heiko W.Rupp a ?crit :
> Hey,
>
> currently the reply-to for this list is not set,
> to hitting reply makes the reply only go to the
> author of an article and hitting reply all will also
> put the author in cc.

For old-fashioned people like me, still using Thunderbird, there's a 
very nice "Reply to the list" button.

>
> Are there objections to add a reply-to header that
> points to the list, so that simple replies go to this
> list?

Yes, do this please. I can't remember how many times my email filters 
failed to triage incoming messages because someone replied to me instead 
of the mailing list.

From jsanda at redhat.com  Fri Mar 20 20:22:32 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 20 Mar 2015 20:22:32 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
Message-ID: <EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>


> On Mar 20, 2015, at 12:47 PM, John Sanda <jsanda at redhat.com> wrote:
> 
>> 
>> On Mar 20, 2015, at 12:23 PM, Lukas Krejci <lkrejci at redhat.com <mailto:lkrejci at redhat.com>> wrote:
>> 
>> On Friday, March 20, 2015 09:03:19 mike thompson wrote:
>>>> On 20 Mar 2015, at 08:19, Lukas Krejci <lkrejci at redhat.com <mailto:lkrejci at redhat.com>> wrote:
>>>> 
>>>> I think the "metrics" should actually be dropped instead of "numeric?.
>>> 
>>> The only thing about ?numeric? is that it is not very specific. Numeric just
>>> means number ? every metric is a number so its really not adding anything.
>>> Even availability data is numeric.
>> 
>> Isn't metrics going to store "events" eventually, too? Those would be textual, 
>> wouldn't they?
>> 
>> Also, IMHO, even config could be stored in metrics. Even though that is a bit 
>> of a stretch, configuration is after all a time series of structured data...
>> 
>> You're right that at the moment numeric doesn't add much information. So maybe 
>> instead of that, the type would specify what should be done with the metric?
>> 
>> Something along the lines of dropwizard-metrics' distinction between a meter, 
>> counter, gauge, histogram, etc?
>> 
>> So like:
>> 
>> http://asdf.com/hawkular/metrics/tenant1/histogram/{id} <http://asdf.com/hawkular/metrics/tenant1/histogram/{id}>
>> http://asdf.com/hawkular/metrics/tenant1/counter/{id}
>> 
> 
> My aggregate metrics design doc[1] talks about formally introducing gauges and counters. The question I have about endpoints like this is what about pushing a batch of metrics? Do we need to make a separate request for each type? That seems cumbersome and inefficient.
> 
> [1] http://bit.ly/1BAfF8d <http://bit.ly/1BAfF8d>
> 

I spent time today thinking about how we might implement counters. There is likely going to be different write paths and schema involved for counters and gauges; consquently, I think that the last suggestion from Lukas makes the most sense. We might have,

POST  /hawkular/metrics/tenant1/gauages
GET    /hawkular/metrics/tenant1/gauges
GET    /hawkular/metrics/tenant1/gauges/{id}

POST  /hawkular/metrics/tenant1/counters
GET    /hawkular/metrics/tenant1/counters 
GET    /hawkular/metrics/tenant1/counters/{id}

And to put my REST education to the test here, If I want to find out about the types of metrics that are supported, I would do a GET /hawkular/metrics/tenant1 and the response should tell me about gauges, counters, tags, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150320/a45e9f2f/attachment.html 

From hrupp at redhat.com  Mon Mar 23 04:04:15 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 09:04:15 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
Message-ID: <1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>

On 21 Mar 2015, at 1:22, John Sanda wrote:
> And to put my REST education to the test here, If I want to find out 
> about the types of metrics that are supported, I would do a GET 
> /hawkular/metrics/tenant1 and the response should tell me about 
> gauges, counters, tags,

Yes. HATEOAS ftw.

But first: do we know that we need counters and gauges right now?

From hrupp at redhat.com  Mon Mar 23 04:19:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 09:19:13 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <550C5633.5010109@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
	<550C5633.5010109@redhat.com>
Message-ID: <60665015-C6B8-405D-88D6-743C48B662B1@redhat.com>

On 20 Mar 2015, at 18:17, Thomas Segismont wrote:

> Le 17/03/2015 11:13, Heiko W.Rupp a ?crit :
>> What if the users does not have any of those tools installed?
>> Do we tell them "install Ganglia, but not the graphing, only the
>> monitoring".
>> Ah and as this does not cope well with WildFly 94 please install
>> collectd on top?
>>
>
> From my perspective, there's no point in writing collectd/ganglia/...
> plugins for JBoss middleware projects.

Absolutely - which means we (= larger JBoss teams) need to do that.

> The value I see in integrating with third party collectors is that users
> may have their own scripts/plugins or use one of their many community
> plugins.

Yes.

From hrupp at redhat.com  Mon Mar 23 04:19:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 09:19:13 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <2816525.LstGQiV138@localhost.localdomain>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
Message-ID: <F6F8CFDC-E96A-41AD-938F-62069391E54E@redhat.com>

On 20 Mar 2015, at 17:23, Lukas Krejci wrote:

> Isn't metrics going to store "events" eventually, too? Those would be 
> textual,
> wouldn't they?
>
> Also, IMHO, even config could be stored in metrics. Even though that 
> is a bit
> of a stretch, configuration is after all a time series of structured 
> data...

If so, would we need to rename this to Hawkular-storage (?) :-)

Seriously, I think we should consider better decoupling the actual 
storage from
api and semantics. Sounds probably pretty strange, so let me explain:
If we consider everything a "metric" we are sucking in more and more
dependencies into metrics or vice versa. But in fact (and we are seeing
it with the availability discussion), items like availability / computed 
resource state,
inventory data, ... have a semantic that differs a lot from metrics.

We may still want to store all that in Cassandra, but not necessarily in 
the
same place inside it. And even less have one api "POST /stuff" where 
people
throw everything at, but rather specialized ones.

From hrupp at redhat.com  Mon Mar 23 04:19:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 09:19:13 +0100
Subject: [Hawkular-dev] ADMIN: set reply-to list?
In-Reply-To: <24B42F92-F433-4620-B390-95E0FEB763AE@redhat.com>
References: <24B42F92-F433-4620-B390-95E0FEB763AE@redhat.com>
Message-ID: <9F3EE0B6-9266-4A6B-A671-95D9CB647D9D@redhat.com>

Hey,

On 20 Mar 2015, at 17:29, Heiko W.Rupp wrote:

> Are there objections to add a reply-to header that
> points to the list, so that simple replies go to this
> list?

This has been now changed so that a Reply to list header
is added.

From theute at redhat.com  Mon Mar 23 05:07:52 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 23 Mar 2015 10:07:52 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <550C61F8.5050607@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>	<1840598.iiPUEzcYuK@localhost.localdomain>	<55084D63.4000301@redhat.com>
	<550C61F8.5050607@redhat.com>
Message-ID: <550FD7E8.4070900@redhat.com>



On 03/20/2015 07:07 PM, Thomas Segismont wrote:
> Le 17/03/2015 16:50, Thomas Heute a ?crit :
>> I don't think we are on the same page regarding the focus of the
>> project/product.
>>
>> Hawkular is targeted toward Red Hat Middleware management, for
>> infrastructure management there are gazillion other solutions.
>> We need "some" basic infrastructure management, for those basic needs a
>> user shouldn't need to maintain a solution made of multiple puzzle pieces.
>
> So in this thread we talked about what we want the user experience to be
> (simple install, works across different systems) and what we don't the
> developer experience to be (with the RHQ agent pain points in mind).
>
> That's important but could we elaborate on the use cases we want to
> solve in the next milestones?

	- Monitor Middleware servers (Metrics/alerts) running either in 
OpenShift (Online/Enterprise) or "on premise".
	- "Basic" monitoring of the underlying infrastructure (CPU/Memory/Disk 
of the host or kube/docker environment)
	- Have an inventory to relates "resources": what runs where ?
	- Operate/Provision servers: the "mutable kind" a la JON and the 
"immutable"  kind (with F8)


For the "kube/docker/OpenShift" environment, we'll go though this 
kadvisor thing, this should collect CPU/Memory/disk about a docker image 
(cAdvisor) + CPU/Memory/disk at a cluster level (heapster) + any metric 
expose through JMX or DMR. IMO we should be able to read the same data 
when our servers are running outside of that environment.

Thomas

> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From lkrejci at redhat.com  Mon Mar 23 05:23:13 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 23 Mar 2015 10:23:13 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <F6F8CFDC-E96A-41AD-938F-62069391E54E@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<F6F8CFDC-E96A-41AD-938F-62069391E54E@redhat.com>
Message-ID: <1513950.o4BRVUQzHi@localhost.localdomain>

+100, very well said.

I wasn't 100% sure if config was really the right candidate to be stored in 
metrics, I just saw the many similarities and potentials for reuse of the 
existing code (or code we plan to have anyway).

But you're very right about the need to semantically split these into separate 
pieces at least on the API level.

Reuse can be achieved internally but should not be exposed to the user.

On Monday, March 23, 2015 09:19:13 Heiko W.Rupp wrote:
> On 20 Mar 2015, at 17:23, Lukas Krejci wrote:
> > Isn't metrics going to store "events" eventually, too? Those would be
> > textual,
> > wouldn't they?
> > 
> > Also, IMHO, even config could be stored in metrics. Even though that
> > is a bit
> > of a stretch, configuration is after all a time series of structured
> > data...
> 
> If so, would we need to rename this to Hawkular-storage (?) :-)
> 
> Seriously, I think we should consider better decoupling the actual
> storage from
> api and semantics.
> Sounds probably pretty strange, so let me explain:
> If we consider everything a "metric" we are sucking in more and more
> dependencies into metrics or vice versa. But in fact (and we are seeing
> it with the availability discussion), items like availability / computed
> resource state,
> inventory data, ... have a semantic that differs a lot from metrics.
>
> We may still want to store all that in Cassandra, but not necessarily in
> the
> same place inside it. And even less have one api "POST /stuff" where
> people
> throw everything at, but rather specialized ones.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From tsegismo at redhat.com  Mon Mar 23 05:43:37 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 10:43:37 +0100
Subject: [Hawkular-dev] Availability
In-Reply-To: <920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>	<1997792.nRBWP4ZPt4@localhost.localdomain>
	<920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
Message-ID: <550FE049.5000801@redhat.com>

Le 20/03/2015 14:37, Heiko W.Rupp a ?crit :
> I am not convinced (yet) that availability should be recorded into
> Hawkular-Metrics,
> as the Metrics api is lacking the mapping functionality.
> I rather think we need "Hawkular-Availability" which offers some
> end-points + api
> and which then defers the storage to the Hawkular-Inventory metrics
> storage engine.

+1

From tsegismo at redhat.com  Mon Mar 23 05:45:39 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 10:45:39 +0100
Subject: [Hawkular-dev] Availability
In-Reply-To: <F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>
References: <5B9D3EC5-2BBB-4DBA-B0B6-C07AF61CEAA4@redhat.com>	<1997792.nRBWP4ZPt4@localhost.localdomain>	<920594E5-9EF1-4C9D-B1C3-D9C1C42184AB@redhat.com>
	<F37C113C-6D90-4558-ABEC-7E91244C3916@redhat.com>
Message-ID: <550FE0C3.4040406@redhat.com>

Le 20/03/2015 15:36, John Sanda a ?crit :
> I suppose I am a bit biased since I work on metrics, but I do think availability should be stored in metrics. I think that the mapping functionality belongs on the client/agent side just as it was in RHQ. Those mapping functions should probably stored be stored in inventory so that users can see precisely how availability is determined for a particular type of resource and so that the user can also change how availability is calculated.

It should be stored in Metrics, as anything evolving with time. It 
doesn't mean Metrics has to maintain a dedicated metric type.

From tsegismo at redhat.com  Mon Mar 23 05:48:01 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 10:48:01 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <5E264F65-BE2A-4261-B2FB-4393EA51A75C@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>	<5B82834B-FDEE-4243-B799-ECA1B882B7AB@redhat.com>
	<5E264F65-BE2A-4261-B2FB-4393EA51A75C@redhat.com>
Message-ID: <550FE151.9030300@redhat.com>

Le 20/03/2015 16:18, John Sanda a ?crit :
>>>
>>> I think the ?metrics? prefix is awkward and unnecessary. I think that
>>> it is intuitive enough that metrics on its own refers to numeric
>>> data. Thoughts?
>>
>> I think the ?data? postfix is redundant as well.
>>
>
> I agree, and we already have
> https://issues.jboss.org/browse/HWKMETRICS-24 for the data part. I will
> create a new ticket for the other proposed changes, and they can be
> addressed together.

I'm not opposed to such a change. HWKMETRICS-24 sounds more important to me.

From jpkroehling at redhat.com  Mon Mar 23 05:50:46 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 23 Mar 2015 10:50:46 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <550C5BF7.2080303@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>	<1840598.iiPUEzcYuK@localhost.localdomain>	<55084D63.4000301@redhat.com>
	<550C5BF7.2080303@redhat.com>
Message-ID: <550FE1F6.1010602@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/2015 06:42 PM, Thomas Segismont wrote:
> Le 17/03/2015 16:50, Thomas Heute a ?crit :
>> Look at NewRelic or ruxit those are dead simple to install and to
>> start monitoring.
> 
> AFAIK, with NewRelic you have to install: * their _sysmond_ for OS
> level monitoring

Their system monitoring tool is provided in RPM format (and probably
other formats) which includes their own repository, meaning, it
installs everything it needs + auto updates using the system's
mechanism. No need to check a special website to see if there are
updates.

> * a Java agent (a true JVM agent, not an external process written
> in Java) for each JVM you want to monitor

For this, they have an "installer" that auto detects most application
servers and add whatever is needed wherever is needed (including
changing standalone.conf). So, this is somewhat transparent to the
system's administrator.

- - Juca.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVD+H2AAoJECKM1e+fkPrXS0UIAIQuvd1TzwlyeCJ1WQJ5c6UL
3q0UKDFW9rTRlGfFsCK8QTRA6mLvBHlrI3HyNyMXvv5+9AMa/BELDCrxfVyESUJ/
T9M9hGAc0RgzL27bYi8gqo3xulSkrP4E49RW8s6Cb0oIFsolxpYzV7B3o0XlNn2J
JNl4WWADYr7vHQ2jnbvEkQfSa7iFGaIs0uvBOI59IzYUmAP/2p+gUWfd5YOAYfUo
sqj95ZhWiktpOsvZdAg87a4dkhuD6q7L2OemMA82f3peL/4DGDA6FMGvvNcZsJZ5
aZD9aqF/nVuZvfFGiswgiLX/aAWtZuKo+6+hUpfw1dBFghj9jcu4fUbnddZzDWs=
=gf7E
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Mon Mar 23 05:51:06 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 10:51:06 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <1794732.esVurXqKhI@localhost.localdomain>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
Message-ID: <550FE20A.6050100@redhat.com>

I hope that, sooner or later, Metrics will be able to store multicolumn 
string + numeric series. So I'd rather keep "metric".

Le 20/03/2015 16:19, Lukas Krejci a ?crit :
> I think the "metrics" should actually be dropped instead of "numeric".
>
> Hawk metrics will never deal with anything else than some kind of metric, so
> way have it in the path? On the other hand having the type of the metric in
> the path is IMHO more useful.
>
> It is the context root of the metrics rest web app that should be called
> "metrics", IMHO.
>
> So the paths in metrics would look like:
>
> /{tenantId}/numeric/data
> /{tenantId}/availability/data
>
> and the REST API user would reach those on the URLs like:
>
> http://asdf.com/hawkular/metrics/tenant1/numeric/{id}/data
>
> conversely, inventory could be reached on the same host like:
>
> http://asdf.com/hawkular/inventory/tenant1/production/resources/{id}


From tsegismo at redhat.com  Mon Mar 23 06:04:59 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 11:04:59 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>	<1794732.esVurXqKhI@localhost.localdomain>	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>	<2816525.LstGQiV138@localhost.localdomain>	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
Message-ID: <550FE54B.9030407@redhat.com>

Le 23/03/2015 09:04, Heiko W.Rupp a ?crit :
> But first: do we know that we need counters and gauges right now?

I can't see why need special semantics for storing values coming from 
counters and gauges (and availability).

From tsegismo at redhat.com  Mon Mar 23 06:16:38 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 11:16:38 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <550FE1F6.1010602@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>	<1657103.cJvZiUMysr@localhost.localdomain>	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>	<1840598.iiPUEzcYuK@localhost.localdomain>	<55084D63.4000301@redhat.com>	<550C5BF7.2080303@redhat.com>
	<550FE1F6.1010602@redhat.com>
Message-ID: <550FE806.9010008@redhat.com>

Le 23/03/2015 10:50, Juraci Paix?o Kr?hling a ?crit :
> On 03/20/2015 06:42 PM, Thomas Segismont wrote:
>> >Le 17/03/2015 16:50, Thomas Heute a ?crit :
>>> >>Look at NewRelic or ruxit those are dead simple to install and to
>>> >>start monitoring.
>> >
>> >AFAIK, with NewRelic you have to install: * their_sysmond_  for OS
>> >level monitoring
> Their system monitoring tool is provided in RPM format (and probably
> other formats) which includes their own repository, meaning, it
> installs everything it needs + auto updates using the system's
> mechanism. No need to check a special website to see if there are
> updates.

Thanks for emphasizing the value of distribution through package managers.

>
>> >* a Java agent (a true JVM agent, not an external process written
>> >in Java) for each JVM you want to monitor
> For this, they have an "installer" that auto detects most application
> servers and add whatever is needed wherever is needed (including
> changing standalone.conf). So, this is somewhat transparent to the
> system's administrator.
>
> - - Juca.

I didn't know about that.

From hrupp at redhat.com  Mon Mar 23 07:19:03 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 12:19:03 +0100
Subject: [Hawkular-dev] scope of the agent design
In-Reply-To: <60665015-C6B8-405D-88D6-743C48B662B1@redhat.com>
References: <1752364308.27845557.1426089236821.JavaMail.zimbra@redhat.com>
	<C5FA052C-9733-4854-8684-5DE3D936E750@redhat.com>
	<CD568F03-5B68-4EB0-809F-3615918D8C20@redhat.com>
	<1657103.cJvZiUMysr@localhost.localdomain>
	<94478B1D-8063-497E-9F1A-58DCFD137447@redhat.com>
	<550C5633.5010109@redhat.com>
	<60665015-C6B8-405D-88D6-743C48B662B1@redhat.com>
Message-ID: <956CD57A-57A1-43B5-B1FD-4BD3A2436D33@redhat.com>

On 23 Mar 2015, at 9:19, Heiko W.Rupp wrote:
>> From my perspective, there's no point in writing collectd/ganglia/...
>> plugins for JBoss middleware projects.
>
> Absolutely - which means we (= larger JBoss teams) need to do that.

As I re-read, this can be misunderstood -- I am not advocating to
write collectd/ganglia plugins, but "agents" that do the job for
monitoring/management of JBoss Middleware products.

From hrupp at redhat.com  Mon Mar 23 07:28:15 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 12:28:15 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <550FE54B.9030407@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
Message-ID: <1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>

On 23 Mar 2015, at 11:04, Thomas Segismont wrote:

> Le 23/03/2015 09:04, Heiko W.Rupp a ?crit :
>> But first: do we know that we need counters and gauges right now?
>
> I can't see why need special semantics for storing values coming from
> counters and gauges (and availability).

If they need no special semantics, why would one want to add counters 
and gauges?


And for availability, do we really want to have feeds deliver random 
numbers
as their availability and then in the UI show the random numbers as we 
can
not determine what availability state they mean?

If all you have is a double, then everything will look like 
2.999999975687 pentium processors :)

From tsegismo at redhat.com  Mon Mar 23 09:34:47 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 14:34:47 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>	<1794732.esVurXqKhI@localhost.localdomain>	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>	<2816525.LstGQiV138@localhost.localdomain>	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
Message-ID: <55101677.6090906@redhat.com>

Le 23/03/2015 12:28, Heiko W.Rupp a ?crit :
> On 23 Mar 2015, at 11:04, Thomas Segismont wrote:
>
>> Le 23/03/2015 09:04, Heiko W.Rupp a ?crit :
>>> But first: do we know that we need counters and gauges right now?
>>
>> I can't see why need special semantics for storing values coming from
>> counters and gauges (and availability).
>
> If they need no special semantics, why would one want to add counters
> and gauges?
>
>
> And for availability, do we really want to have feeds deliver random
> numbers
> as their availability and then in the UI show the random numbers as we
> can
> not determine what availability state they mean?
>
> If all you have is a double, then everything will look like
> 2.999999975687 pentium processors :)

What I meant is that we shouldn't care about how the data is stored, if 
it's a counter, a gauge, a string. It's a "value point" in time.

What matters is how we query this data. For example, if you're working 
with a counter you'll probably be interested in applying a derivative 
function.

From hrupp at redhat.com  Mon Mar 23 09:52:19 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 14:52:19 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <55101677.6090906@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
	<55101677.6090906@redhat.com>
Message-ID: <433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>

> What I meant is that we shouldn't care about how the data is stored, if
> it's a counter, a gauge, a string. It's a "value point" in time.

While I think it is good to separate the storage from the semantics,
I do not think we should not care how it is stored.

For counters, which are integral values, we should probably not
store them as double.

Similar, a log line should not be stored as double either :-)

>
> What matters is how we query this data. For example, if you're working
> with a counter you'll probably be interested in applying a derivative
> function.

Yes

From jsanda at redhat.com  Mon Mar 23 10:18:04 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 23 Mar 2015 10:18:04 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
	<55101677.6090906@redhat.com>
	<433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
Message-ID: <418FB4EE-F493-46EC-B77F-F1DC6F6045EF@redhat.com>


> On Mar 23, 2015, at 9:52 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
>> What I meant is that we shouldn't care about how the data is stored, if
>> it's a counter, a gauge, a string. It's a "value point" in time.
> 
> While I think it is good to separate the storage from the semantics,
> I do not think we should not care how it is stored.
> 
> For counters, which are integral values, we should probably not
> store them as double.
> 
> Similar, a log line should not be stored as double either :-)
> 
>> 
>> What matters is how we query this data. For example, if you're working
>> with a counter you'll probably be interested in applying a derivative
>> function.
> 
> Yes

The semantics of metric type are precisely about querying. The type information tells us which aggregation functions to apply to the data points. And these functions should be utilized in both ad-hoc queries as well as the generation of pre-computed aggregates/rollups; however, I am not suggesting that this should preclude the use of other functions.

From jsanda at redhat.com  Mon Mar 23 10:47:35 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 23 Mar 2015 10:47:35 -0400
Subject: [Hawkular-dev] availability as a computed metric (was availability
	and metric endpoints)
In-Reply-To: <1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
Message-ID: <504D063E-8BF2-4130-8B67-0C0F2418AC20@redhat.com>


> On Mar 23, 2015, at 7:28 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> And for availability, do we really want to have feeds deliver random 
> numbers
> as their availability and then in the UI show the random numbers as we 
> can
> not determine what availability state they mean?
> 
> If all you have is a double, then everything will look like 
> 2.999999975687 pentium processors :)

I think that there was some general consensus or at least convergence towards the notion that availability is a function that reports resource state change. It could be a function of metric data or something else. In RHQ, those functions were defined implicitly by and hard coded into plugins. There are a couple of important implications with this. First, users cannot easily determine how availability is computed for a particular resource type. Secondly, availability is computed by the agent and not by the server.

I think we need to expand on what was done in RHQ. I think that availability functions should be explicit and stored in inventory so that users can easily see how availability is determined and also change how availability is computed should the need arise. The monitoring agent, not the server, should compute availability. I am using the term agent loosely here because it applies to agents that embedded in-process, agents that are co-located in a separate process, and agents that are remote possibly embedded in the hawkular server.

There needs to be more done in terms of correlation. When there is a state change, we should be reporting an accompanying event, e.g., server shutdown, server restarted, etc. If we compute availability based on some metric, then maybe the event reported is something like, http status code is X or the response time is Y.

- John
 



From tsegismo at redhat.com  Mon Mar 23 10:57:48 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 23 Mar 2015 15:57:48 +0100
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>	<1794732.esVurXqKhI@localhost.localdomain>	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>	<2816525.LstGQiV138@localhost.localdomain>	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>	<550FE54B.9030407@redhat.com>	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>	<55101677.6090906@redhat.com>
	<433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
Message-ID: <551029EC.5050408@redhat.com>

Le 23/03/2015 14:52, Heiko W.Rupp a ?crit :
> Similar, a log line should not be stored as double either:-)

I though everything was a series of bits :p

From hrupp at redhat.com  Mon Mar 23 11:00:00 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Mar 2015 16:00:00 +0100
Subject: [Hawkular-dev] availability as a computed metric (was
 availability and metric endpoints)
In-Reply-To: <504D063E-8BF2-4130-8B67-0C0F2418AC20@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
	<504D063E-8BF2-4130-8B67-0C0F2418AC20@redhat.com>
Message-ID: <8FE61EAB-1629-49C6-B34F-E86DEC42D3AA@redhat.com>

On 23 Mar 2015, at 15:47, John Sanda wrote:
> I think that there was some general consensus or at least convergence 
> towards the notion that availability is a function that reports 
> resource state change. It could be a function of metric data or

Yes.

> I think we need to expand on what was done in RHQ. I think that 
> availability functions should be explicit and stored in inventory so 
> that users can easily see how availability is determined and also 
> change how availability is computed should the need arise. The

As I said.

> monitoring agent, not the server, should compute availability. I am 
> using the term agent loosely here because it applies to agents that

Which may be ok for the simple case, but certainly neither in cases
where availability is a composite (application with resources 
distributed
over several agents).
In fact I have proposed in the past that agents can do some local 
computation
and only forward metrics in case of error/change.

> There needs to be more done in terms of correlation. When there is a 
> state change, we should be reporting an accompanying event, e.g., 
> server shutdown, server restarted, etc. If we compute availability 
> based on some metric, then maybe the event reported is something like, 
> http status code is X or the response time is Y.

Yes.

See also 
http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html

From hrupp at redhat.com  Tue Mar 24 04:51:48 2015
From: hrupp at redhat.com (Heiko Rupp)
Date: Tue, 24 Mar 2015 04:51:48 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular-Team Update
Message-ID: <277648388.2604542.1427187108922.JavaMail.zimbra@redhat.com>

Neue Sitzungsanfrage:

Betreff: Hawkular-Team Update 
Organisator: "Heiko Rupp" <hrupp at redhat.com> 

Ort: pc 204 2160 481 
Uhrzeit: Dienstag, 24. M?rz 2015, 15:30:00 - 16:00:00 GMT +01:00 Amsterdam, Berlin, Bern, Rom, Stockholm, Wien
 
Eingeladene Teilnehmer: hawkular-dev at lists.jboss.org 


*~*~*~*~*~*~*~*~*~*

This is a all-Hawkular team meeting to give updates where we are and so on.

This is *open to the public*.

Location: teleconference Reservationless+ , passcode 204 2160 481

You can find Dial-In telephone numbers here: https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481

RedHat internal short dial numbers are 16666 and 15555 (and probably others, depends on your location)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1822 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150324/8716994a/attachment.bin 

From hrupp at redhat.com  Tue Mar 24 04:52:07 2015
From: hrupp at redhat.com (Heiko Rupp)
Date: Tue, 24 Mar 2015 04:52:07 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular-Team Update
Message-ID: <551920455.2604656.1427187127032.JavaMail.zimbra@redhat.com>

Der folgende Sitzungstermin wurde ge?ndert:

Betreff: Hawkular-Team Update 
Organisator: "Heiko Rupp" <hrupp at redhat.com> 

Ort: pc 204 2160 481 
Uhrzeit: 15:30:00 - 16:00:00 GMT +01:00 Amsterdam, Berlin, Bern, Rom, Stockholm, Wien
 Wiederkehrend : Jeden Dienstag Kein Enddatum Ab 24. Mrz 2015

Eingeladene Teilnehmer: hawkular-dev at lists.jboss.org 


*~*~*~*~*~*~*~*~*~*

This is a all-Hawkular team meeting to give updates where we are and so on. 

This is *open to the public*. 

Location: teleconference Reservationless+ , passcode 204 2160 481 

You can find Dial-In telephone numbers here: https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481 

RedHat internal short dial numbers are 16666 and 15555 (and probably others, depends on your location)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1915 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150324/837f1379/attachment.bin 

From hrupp at redhat.com  Tue Mar 24 05:15:52 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Mar 2015 10:15:52 +0100
Subject: [Hawkular-dev] Jira issues
Message-ID: <46D2AEC7-FC24-41A3-BDEC-59F9B91FF38B@redhat.com>

Hey,

when it is obvious that a Jira issue does not need QA (e.g. "mavenize 
build"), then directly close it after merging to master and do not put 
it "ON QA".

  Thanks

From hrupp at redhat.com  Tue Mar 24 10:50:11 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Mar 2015 15:50:11 +0100
Subject: [Hawkular-dev] Recording of today's call
Message-ID: <88913640-271C-4AFD-BC17-087DD7903CEF@redhat.com>

1. Click on the link below or paste the entire URL into your browser:
http://www2.eintercall.com/moderator/presentation/Playback?id=7f718975-82f4-4005-ab86-e9b54a4d60f7.rpm
2. At the prompt, enter your name and email address.
3. Choose your player.
3. Click Listen.


From hrupp at redhat.com  Tue Mar 24 13:05:29 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Mar 2015 18:05:29 +0100
Subject: [Hawkular-dev] Jira and pull-requests
Message-ID: <2B723B35-D557-4623-977A-DCE053AA0449@redhat.com>

Hey,

please after merging a pull-request, also mark the jira as resolved.

Thanks
  Heiko

From araz.abishov.gsoc at gmail.com  Wed Mar 25 06:02:00 2015
From: araz.abishov.gsoc at gmail.com (Araz Abishov)
Date: Wed, 25 Mar 2015 14:02:00 +0400
Subject: [Hawkular-dev] [GSoC 2015] Hawkular Android Client Project details
Message-ID: <CA+jpPErqWKWaRXkWd0tE1hkWGDv_YY+08zCdSXUj=0WDsF_sgg@mail.gmail.com>

Dear Hawkular community,

The purpose of this letter is to briefly introduce myself as candidate for
implementation of "Hawkular Android client" project during this summer.

In first order, I want to apologize for contacting you so late. The reason
was time consuming work on my thesis at university.

My name is Araz Abishov and I am 4th year student pursuing bachelor's
degree in computer science at Azerbaijan State Oil Academy. My main passion
is contemporary technology, in particular development of mobile and web
applications. I have already participated in GSoC 2013 and GSoC 2014
working on mobile data capture application for District Health Information
System. GSoC 2015 is a great chance for me to face new challenges. It would
be pleasure for me to contribute to Hawkular community this summer.

I would like to learn more about main project goals as well as other
specific requirements:

Could you please:
 - provide more details on REST API available for mobile apps?
 - describe which features you are expecting in Android application?

I would like also to provide more details about me and my working
experience (I have attached my CV in pdf).

Hope to hear from you soon on project details.

Best Regards,
Araz Abishov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150325/8782394c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Curriculum Vitae.pdf
Type: application/pdf
Size: 433030 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150325/8782394c/attachment-0001.pdf 

From gbrown at redhat.com  Thu Mar 26 04:23:56 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 26 Mar 2015 04:23:56 -0400 (EDT)
Subject: [Hawkular-dev] Relationship between Accounts and KeyCloak
In-Reply-To: <1630948861.3410505.1427358199345.JavaMail.zimbra@redhat.com>
Message-ID: <1832008864.3410574.1427358236024.JavaMail.zimbra@redhat.com>

Hi

Just curious whether there have been discussions with the KeyCloak project on the boundaries with Hawkular Accounts?

Its just it seems like concepts such as Organizations and Roles are generic and therefore should really be work contributed to KeyCloak, leaving just the relationship from Orgs/Users to resources as Accounts specific?

Regards
Gary

From jpkroehling at redhat.com  Thu Mar 26 04:43:42 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 26 Mar 2015 09:43:42 +0100
Subject: [Hawkular-dev] Relationship between Accounts and KeyCloak
In-Reply-To: <1832008864.3410574.1427358236024.JavaMail.zimbra@redhat.com>
References: <1832008864.3410574.1427358236024.JavaMail.zimbra@redhat.com>
Message-ID: <5513C6BE.9080106@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/26/2015 09:23 AM, Gary Brown wrote:
> Just curious whether there have been discussions with the KeyCloak 
> project on the boundaries with Hawkular Accounts?

Sort of. There were some discussions with some KC members about multi
tenancy, which is really the "key" feature we need. Unfortunately, our
model of multi tenancy doesn't match nicely with Keycloak's.

Basically, Keycloak's multi tenancy capability is achieved in the form
of realms: each realm is a tenant. In our case, that could work (we
even contributed some code for allowing multi tenancy on the adapter
side), *but*, there we have a scenario where users from one tenant
would be given permission to access resources from another tenant. And
there's no easy/pretty solution for that, as it's a conceptual
mismatch, not a technical one.

> Its just it seems like concepts such as Organizations and Roles
> are generic and therefore should really be work contributed to 
> KeyCloak, leaving just the relationship from Orgs/Users to 
> resources as Accounts specific?

Indeed. I sent an email to the PicketLink lead last week, as it's a
component that already has all the features we need (on the
Permissions API), including multi tenancy (with the concept of
partitions, which relates to our 'organizations'). But the work in
integrating PicketLink and Keycloak will still take some time. And
this specific part of PicketLink is dependent on PicketLink IDM,
conflicting with Keycloak, so, we can't use that as a standalone
component.

My plan is to ditch our custom code as soon as possible, as much as
possible, to reuse what can be provided by specialized frameworks and
tools. But "as soon as possible" is, as of now, "not soon enough for MVP
".

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVE8a+AAoJECKM1e+fkPrXzL0H/jaI6+rYNSibEPKf5ormkB3r
9KpX7HapkLrvpGwBXRW+L8WPAbeMncZnkbbmQMlrn4SrjUIUb9qibKYcAr44n7mG
tvZNYye0+Z3+K0i9RxQ+W4rrsLvseRfaywcO1sr7UQkVLLOthK3fWQ9797TJ0Re7
pNY5rI0ae9iBaHxHKc0OoWdsqLZPWuKBHtL+Yrntwb7dLL3Kpu2+WPJgsCtOeEQZ
7pebdESjBV/sNZoMh9yXJQoKlniC82lniWrWRfJ3QGH5MylkjEdp1bOnkpxo3OSY
pim8qSgvNPFOE1d2qTxa3KC0pERFNvaeSv9EMlyjqTAJ/pCPwEh29eL0YRHXjYM=
=QP2u
-----END PGP SIGNATURE-----

From gbrown at redhat.com  Thu Mar 26 04:53:12 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 26 Mar 2015 04:53:12 -0400 (EDT)
Subject: [Hawkular-dev] Relationship between Accounts and KeyCloak
In-Reply-To: <5513C6BE.9080106@redhat.com>
References: <1832008864.3410574.1427358236024.JavaMail.zimbra@redhat.com>
	<5513C6BE.9080106@redhat.com>
Message-ID: <803674746.3442932.1427359992672.JavaMail.zimbra@redhat.com>

Ok thanks - that sounds like a good approach.

Regards
Gary

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/26/2015 09:23 AM, Gary Brown wrote:
> > Just curious whether there have been discussions with the KeyCloak
> > project on the boundaries with Hawkular Accounts?
> 
> Sort of. There were some discussions with some KC members about multi
> tenancy, which is really the "key" feature we need. Unfortunately, our
> model of multi tenancy doesn't match nicely with Keycloak's.
> 
> Basically, Keycloak's multi tenancy capability is achieved in the form
> of realms: each realm is a tenant. In our case, that could work (we
> even contributed some code for allowing multi tenancy on the adapter
> side), *but*, there we have a scenario where users from one tenant
> would be given permission to access resources from another tenant. And
> there's no easy/pretty solution for that, as it's a conceptual
> mismatch, not a technical one.
> 
> > Its just it seems like concepts such as Organizations and Roles
> > are generic and therefore should really be work contributed to
> > KeyCloak, leaving just the relationship from Orgs/Users to
> > resources as Accounts specific?
> 
> Indeed. I sent an email to the PicketLink lead last week, as it's a
> component that already has all the features we need (on the
> Permissions API), including multi tenancy (with the concept of
> partitions, which relates to our 'organizations'). But the work in
> integrating PicketLink and Keycloak will still take some time. And
> this specific part of PicketLink is dependent on PicketLink IDM,
> conflicting with Keycloak, so, we can't use that as a standalone
> component.
> 
> My plan is to ditch our custom code as soon as possible, as much as
> possible, to reuse what can be provided by specialized frameworks and
> tools. But "as soon as possible" is, as of now, "not soon enough for MVP
> ".
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJVE8a+AAoJECKM1e+fkPrXzL0H/jaI6+rYNSibEPKf5ormkB3r
> 9KpX7HapkLrvpGwBXRW+L8WPAbeMncZnkbbmQMlrn4SrjUIUb9qibKYcAr44n7mG
> tvZNYye0+Z3+K0i9RxQ+W4rrsLvseRfaywcO1sr7UQkVLLOthK3fWQ9797TJ0Re7
> pNY5rI0ae9iBaHxHKc0OoWdsqLZPWuKBHtL+Yrntwb7dLL3Kpu2+WPJgsCtOeEQZ
> 7pebdESjBV/sNZoMh9yXJQoKlniC82lniWrWRfJ3QGH5MylkjEdp1bOnkpxo3OSY
> pim8qSgvNPFOE1d2qTxa3KC0pERFNvaeSv9EMlyjqTAJ/pCPwEh29eL0YRHXjYM=
> =QP2u
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From theute at redhat.com  Thu Mar 26 05:08:28 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 26 Mar 2015 10:08:28 +0100
Subject: [Hawkular-dev] Relationship between Accounts and KeyCloak
In-Reply-To: <803674746.3442932.1427359992672.JavaMail.zimbra@redhat.com>
References: <1832008864.3410574.1427358236024.JavaMail.zimbra@redhat.com>	<5513C6BE.9080106@redhat.com>
	<803674746.3442932.1427359992672.JavaMail.zimbra@redhat.com>
Message-ID: <5513CC8C.4010702@redhat.com>

+1

On 03/26/2015 09:53 AM, Gary Brown wrote:
> Ok thanks - that sounds like a good approach.
>
> Regards
> Gary
>
> ----- Original Message -----
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/26/2015 09:23 AM, Gary Brown wrote:
>>> Just curious whether there have been discussions with the KeyCloak
>>> project on the boundaries with Hawkular Accounts?
>> Sort of. There were some discussions with some KC members about multi
>> tenancy, which is really the "key" feature we need. Unfortunately, our
>> model of multi tenancy doesn't match nicely with Keycloak's.
>>
>> Basically, Keycloak's multi tenancy capability is achieved in the form
>> of realms: each realm is a tenant. In our case, that could work (we
>> even contributed some code for allowing multi tenancy on the adapter
>> side), *but*, there we have a scenario where users from one tenant
>> would be given permission to access resources from another tenant. And
>> there's no easy/pretty solution for that, as it's a conceptual
>> mismatch, not a technical one.
>>
>>> Its just it seems like concepts such as Organizations and Roles
>>> are generic and therefore should really be work contributed to
>>> KeyCloak, leaving just the relationship from Orgs/Users to
>>> resources as Accounts specific?
>> Indeed. I sent an email to the PicketLink lead last week, as it's a
>> component that already has all the features we need (on the
>> Permissions API), including multi tenancy (with the concept of
>> partitions, which relates to our 'organizations'). But the work in
>> integrating PicketLink and Keycloak will still take some time. And
>> this specific part of PicketLink is dependent on PicketLink IDM,
>> conflicting with Keycloak, so, we can't use that as a standalone
>> component.
>>
>> My plan is to ditch our custom code as soon as possible, as much as
>> possible, to reuse what can be provided by specialized frameworks and
>> tools. But "as soon as possible" is, as of now, "not soon enough for MVP
>> ".
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQEcBAEBAgAGBQJVE8a+AAoJECKM1e+fkPrXzL0H/jaI6+rYNSibEPKf5ormkB3r
>> 9KpX7HapkLrvpGwBXRW+L8WPAbeMncZnkbbmQMlrn4SrjUIUb9qibKYcAr44n7mG
>> tvZNYye0+Z3+K0i9RxQ+W4rrsLvseRfaywcO1sr7UQkVLLOthK3fWQ9797TJ0Re7
>> pNY5rI0ae9iBaHxHKc0OoWdsqLZPWuKBHtL+Yrntwb7dLL3Kpu2+WPJgsCtOeEQZ
>> 7pebdESjBV/sNZoMh9yXJQoKlniC82lniWrWRfJ3QGH5MylkjEdp1bOnkpxo3OSY
>> pim8qSgvNPFOE1d2qTxa3KC0pERFNvaeSv9EMlyjqTAJ/pCPwEh29eL0YRHXjYM=
>> =QP2u
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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


From gbrown at redhat.com  Mon Mar 30 07:13:51 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 30 Mar 2015 07:13:51 -0400 (EDT)
Subject: [Hawkular-dev] Business Transaction Management integration with
 Hawkular Components
In-Reply-To: <1555146203.5837702.1427713166646.JavaMail.zimbra@redhat.com>
Message-ID: <781455107.5846863.1427714031441.JavaMail.zimbra@redhat.com>

Hi all

I'm working on some ideas related to Business Transaction Management and how it integrates with Hawkular components. I've started documenting these ideas here: https://docs.google.com/document/d/1p387e8U9I2rim7ZRRZ8FU0s2KU7zfCdssCppUz93sL8/edit?usp=sharing

I would appreciate any feedback on the concepts in general, but more specifically I have created some comments with questions regarding Hawkular Inventory, "Agent", Metrics and Alerts. It would be great if we can start some discussions around these areas to understand whether there are any new requirements on those components.

Thanks in advance.

Regards
Gary

From ppalaga at redhat.com  Mon Mar 30 09:37:17 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 30 Mar 2015 15:37:17 +0200
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources via
	Maven
Message-ID: <5519518D.7030308@redhat.com>

Hi *, there is a question about handling JavaDoc checks violations at 
the bottom.

I have added maven-javadoc-plugin and maven-source-plugin to the new 
"release" profile in Hawkular Parent.
https://github.com/hawkular/hawkular-parent-pom/pull/20

I have tested the above only with Hawkular Bus. Therefore, please test 
the setup with your Hawkular component:
* Make whatever is appropriate to make your component use the pom from 
https://github.com/hawkular/hawkular-parent-pom/pull/20
* Invoke

   mvn clean install -Prelease

* Figure out, how many "[WARNING] Javadoc Warnings" are there.
* Look into target folders if *-javadoc.jar and *-sources.jar files were 
generated


== Handling JavaDoc checks violations

The present setup turns all javadoc violations into warnings using 
-Xdoclint:none [1]. I can only say that there *are* violations in Bus.

I think that we should aim at having no violations at all - i.e. that 
the components should be given a week or two to fix and that we should 
switch to -Xdoclint:all after that. WDYT?

More about -Xdoclint can be found in [2].

Thanks,

Peter

[1] 
https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110

[2] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html

From ppalaga at redhat.com  Mon Mar 30 09:58:58 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 30 Mar 2015 15:58:58 +0200
Subject: [Hawkular-dev] Proposal: Add PGP artifact signing
Message-ID: <551956A2.5090200@redhat.com>

Hi *,

I propose to add maven-gpg-plugin to the release profile, similarly as I 
did for javadoc and sources in 
https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R630

A pom.xml snippet is in https://issues.jboss.org/browse/HAWKULAR-108


== Why?

Because Maven Central requires it [1]. Although apparently, they already 
have accepted our unsigned artifacts already.

I would not let our CI to sign the SNAPSHOT releases.


== So what is the problem?

The team members doing releases would have to
* install native OS-level gpg software
* generate a key pair
* publish their public key
See [2]

Is the above acceptable?

Thanks,

Peter

[1] 
http://maven.apache.org/guides/mini/guide-central-repository-upload.html#PGP_Signature
[2] 
http://blog.sonatype.com/2010/01/how-to-generate-pgp-signatures-with-maven

From snegrea at redhat.com  Mon Mar 30 10:29:48 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 30 Mar 2015 10:29:48 -0400 (EDT)
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <5519518D.7030308@redhat.com>
References: <5519518D.7030308@redhat.com>
Message-ID: <1707730512.7171668.1427725788434.JavaMail.zimbra@redhat.com>

Hello Peter,

We would like to disable (or not have it all) in the Hawkular Metrics project. Hawkular Metrics iterates at a fast pace and this would be a huge distraction due to the rapidly changing design and implementation. At this stage we are focused on building a great project so agile tooling and minimal requirements are paramount.

Can you please provide documentation on how to disable this at the project level?


Thank you,
Stefan 

----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, March 30, 2015 8:37:17 AM
> Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources via	Maven
> 
> Hi *, there is a question about handling JavaDoc checks violations at
> the bottom.
> 
> I have added maven-javadoc-plugin and maven-source-plugin to the new
> "release" profile in Hawkular Parent.
> https://github.com/hawkular/hawkular-parent-pom/pull/20
> 
> I have tested the above only with Hawkular Bus. Therefore, please test
> the setup with your Hawkular component:
> * Make whatever is appropriate to make your component use the pom from
> https://github.com/hawkular/hawkular-parent-pom/pull/20
> * Invoke
> 
>    mvn clean install -Prelease
> 
> * Figure out, how many "[WARNING] Javadoc Warnings" are there.
> * Look into target folders if *-javadoc.jar and *-sources.jar files were
> generated
> 
> 
> == Handling JavaDoc checks violations
> 
> The present setup turns all javadoc violations into warnings using
> -Xdoclint:none [1]. I can only say that there *are* violations in Bus.
> 
> I think that we should aim at having no violations at all - i.e. that
> the components should be given a week or two to fix and that we should
> switch to -Xdoclint:all after that. WDYT?
> 
> More about -Xdoclint can be found in [2].
> 
> Thanks,
> 
> Peter
> 
> [1]
> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
> 
> [2] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jshaughn at redhat.com  Mon Mar 30 10:38:59 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 30 Mar 2015 10:38:59 -0400
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <5519518D.7030308@redhat.com>
References: <5519518D.7030308@redhat.com>
Message-ID: <55196003.9090202@redhat.com>


Hi Peter, to get an idea of the type and volume of issues this will 
report, can you list the current bus warnings you're seeing?


On 3/30/2015 9:37 AM, Peter Palaga wrote:
> Hi *, there is a question about handling JavaDoc checks violations at
> the bottom.
>
> I have added maven-javadoc-plugin and maven-source-plugin to the new
> "release" profile in Hawkular Parent.
> https://github.com/hawkular/hawkular-parent-pom/pull/20
>
> I have tested the above only with Hawkular Bus. Therefore, please test
> the setup with your Hawkular component:
> * Make whatever is appropriate to make your component use the pom from
> https://github.com/hawkular/hawkular-parent-pom/pull/20
> * Invoke
>
>     mvn clean install -Prelease
>
> * Figure out, how many "[WARNING] Javadoc Warnings" are there.
> * Look into target folders if *-javadoc.jar and *-sources.jar files were
> generated
>
>
> == Handling JavaDoc checks violations
>
> The present setup turns all javadoc violations into warnings using
> -Xdoclint:none [1]. I can only say that there *are* violations in Bus.
>
> I think that we should aim at having no violations at all - i.e. that
> the components should be given a week or two to fix and that we should
> switch to -Xdoclint:all after that. WDYT?
>
> More about -Xdoclint can be found in [2].
>
> Thanks,
>
> Peter
>
> [1]
> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
>
> [2] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
> _______________________________________________
> 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/20150330/43d73885/attachment-0001.html 

From snegrea at redhat.com  Mon Mar 30 10:40:22 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 30 Mar 2015 10:40:22 -0400 (EDT)
Subject: [Hawkular-dev] Proposal: Add PGP artifact signing
In-Reply-To: <551956A2.5090200@redhat.com>
References: <551956A2.5090200@redhat.com>
Message-ID: <1491341575.7180200.1427726422960.JavaMail.zimbra@redhat.com>

Hello Peter,

Hawkular Metrics is the only project that has official pre 1.0 releases. For Hawkular Metrics automated deployments of SNAPSHOTS and simple releases (by any Hawkular Metrics member) are essential. 

At this point, Hawkular Metrics will not consider adding pgp. The only way this would be viable for Hawkular Metrics is with a release engineer permanently on staff that will automate and maintain every single aspect of the pgp signing via CI tooling.


Thank you,
Stefan

----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, March 30, 2015 8:58:58 AM
> Subject: [Hawkular-dev] Proposal: Add PGP artifact signing
> 
> Hi *,
> 
> I propose to add maven-gpg-plugin to the release profile, similarly as I
> did for javadoc and sources in
> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R630
> 
> A pom.xml snippet is in https://issues.jboss.org/browse/HAWKULAR-108
> 
> 
> == Why?
> 
> Because Maven Central requires it [1]. Although apparently, they already
> have accepted our unsigned artifacts already.
> 
> I would not let our CI to sign the SNAPSHOT releases.
> 
> 
> == So what is the problem?
> 
> The team members doing releases would have to
> * install native OS-level gpg software
> * generate a key pair
> * publish their public key
> See [2]
> 
> Is the above acceptable?
> 
> Thanks,
> 
> Peter
> 
> [1]
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html#PGP_Signature
> [2]
> http://blog.sonatype.com/2010/01/how-to-generate-pgp-signatures-with-maven
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Mon Mar 30 10:53:39 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 30 Mar 2015 10:53:39 -0400 (EDT)
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <55196003.9090202@redhat.com>
References: <5519518D.7030308@redhat.com> <55196003.9090202@redhat.com>
Message-ID: <1595320278.6483910.1427727219296.JavaMail.zimbra@redhat.com>

FWIW, the only way I would say we do javadoc checks is if we really javadoc things. I don't want javadoc to just look like this so people can pass the checks:

/**
 * @param firstArg
 * @param secondArg
 * @return int
 */

Because if that's all its going to look like (just to get it to pass the checks) the javadoc is useless, increases the size of the .java files for no reason, and it's just yet another "check" phase we need to worry about and fix during builds with no value-add.

If the Javadoc is going to be fully fleshed out with REAL comments about what the parameters are, what it returns, what the method does, yadda yadda, then OK. But don't do this just for the sake of saying "we have javadoc jars" if the javadocs don't add anything helpful.

And FWIW#2, I find source jars more valuable than javadoc jars.

$0.02 deposited.

----- Original Message -----
> 
> Hi Peter, to get an idea of the type and volume of issues this will report,
> can you list the current bus warnings you're seeing?
> 
> 
> On 3/30/2015 9:37 AM, Peter Palaga wrote:
> 
> 
> 
> Hi *, there is a question about handling JavaDoc checks violations at
> the bottom.
> 
> I have added maven-javadoc-plugin and maven-source-plugin to the new
> "release" profile in Hawkular Parent.
> https://github.com/hawkular/hawkular-parent-pom/pull/20 I have tested the
> above only with Hawkular Bus. Therefore, please test
> the setup with your Hawkular component:
> * Make whatever is appropriate to make your component use the pom from
> https://github.com/hawkular/hawkular-parent-pom/pull/20 * Invoke
> 
>    mvn clean install -Prelease
> 
> * Figure out, how many "[WARNING] Javadoc Warnings" are there.
> * Look into target folders if *-javadoc.jar and *-sources.jar files were
> generated
> 
> 
> == Handling JavaDoc checks violations
> 
> The present setup turns all javadoc violations into warnings using
> -Xdoclint:none [1]. I can only say that there *are* violations in Bus.
> 
> I think that we should aim at having no violations at all - i.e. that
> the components should be given a week or two to fix and that we should
> switch to -Xdoclint:all after that. WDYT?
> 
> More about -Xdoclint can be found in [2].
> 
> Thanks,
> 
> Peter
> 
> [1]
> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
> [2] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
> _______________________________________________
> 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
> 

From ppalaga at redhat.com  Mon Mar 30 15:28:43 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 30 Mar 2015 21:28:43 +0200
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <1707730512.7171668.1427725788434.JavaMail.zimbra@redhat.com>
References: <5519518D.7030308@redhat.com>
	<1707730512.7171668.1427725788434.JavaMail.zimbra@redhat.com>
Message-ID: <5519A3EB.5010904@redhat.com>

Hi Stefan,

The motivation for this change is to get source and JavaDoc loaded 
automagically by IDEs. Is that not an aim worth pursuing?
The change was proposed by mazz https://issues.jboss.org/browse/HAWKULAR-86

More inline...

On 03/30/2015 04:29 PM, Stefan Negrea wrote:
> Hello Peter,
>
> Wewould like to disable (or not have it all) in the Hawkular Metrics
> project.
> Hawkular Metrics iterates at a fast pace and this would be a
> huge distraction due to the rapidly changing design and
> implementation. At this stage we are focused on building a great
> project so agile tooling and minimal requirements are paramount.

Could you please be more specific what kind of distraction you have in 
mind?
To put it more clearly, JavaDoc and source jars are generated only when 
"release" profile is active. I would not say running those two plugins 
is a part of anyone's daily routine. Releases done by CI taking a couple 
of seconds longer is outweighted by the benefit of getting the sources 
in IDEs.
Perhaps it is also necessary to note that the plugins as configured in 
https://github.com/hawkular/hawkular-parent-pom/pull/20 *just work* - 
they produce what they are supposed to and they do not shout loudly 
about the quality. The quality checks for JavaDoc are explicitly 
disabled by -Xdoclint:none and it is an open question if this should be 
changed in the future. Maybe it is just here that you vote against?

> Can you please provide documentation on how to disable this at the
> project level?

Are you sure you need it, given all the above?

Best,

Peter

>
> Thank you, Stefan
>
> ----- Original Message -----
>> From: "Peter Palaga" <ppalaga at redhat.com> To:
>> hawkular-dev at lists.jboss.org Sent: Monday, March 30, 2015 8:37:17
>> AM Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and
>> sources via	Maven
>>
>> Hi *, there is a question about handling JavaDoc checks violations
>> at the bottom.
>>
>> I have added maven-javadoc-plugin and maven-source-plugin to the
>> new "release" profile in Hawkular Parent.
>> https://github.com/hawkular/hawkular-parent-pom/pull/20
>>
>> I have tested the above only with Hawkular Bus. Therefore, please
>> test the setup with your Hawkular component: * Make whatever is
>> appropriate to make your component use the pom from
>> https://github.com/hawkular/hawkular-parent-pom/pull/20 * Invoke
>>
>> mvn clean install -Prelease
>>
>> * Figure out, how many "[WARNING] Javadoc Warnings" are there. *
>> Look into target folders if *-javadoc.jar and *-sources.jar files
>> were generated
>>
>>
>> == Handling JavaDoc checks violations
>>
>> The present setup turns all javadoc violations into warnings using
>> -Xdoclint:none [1]. I can only say that there *are* violations in
>> Bus.
>>
>> I think that we should aim at having no violations at all - i.e.
>> that the components should be given a week or two to fix and that
>> we should switch to -Xdoclint:all after that. WDYT?
>>
>> More about -Xdoclint can be found in [2].
>>
>> Thanks,
>>
>> Peter
>>
>> [1]
>> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
>>
>>
>>
[2] http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
>> _______________________________________________ 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
>


From ppalaga at redhat.com  Mon Mar 30 15:34:21 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 30 Mar 2015 21:34:21 +0200
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <55196003.9090202@redhat.com>
References: <5519518D.7030308@redhat.com> <55196003.9090202@redhat.com>
Message-ID: <5519A53D.2020005@redhat.com>

Hi Jay, there is just a couple of them in Bus - see the attached file. -- P


On 03/30/2015 04:38 PM, Jay Shaughnessy wrote:
>
> Hi Peter, to get an idea of the type and volume of issues this will
> report, can you list the current bus warnings you're seeing?
>
>
> On 3/30/2015 9:37 AM, Peter Palaga wrote:
>> Hi *, there is a question about handling JavaDoc checks violations at
>> the bottom.
>>
>> I have added maven-javadoc-plugin and maven-source-plugin to the new
>> "release" profile in Hawkular Parent.
>> https://github.com/hawkular/hawkular-parent-pom/pull/20
>>
>> I have tested the above only with Hawkular Bus. Therefore, please test
>> the setup with your Hawkular component:
>> * Make whatever is appropriate to make your component use the pom from
>> https://github.com/hawkular/hawkular-parent-pom/pull/20
>> * Invoke
>>
>>     mvn clean install -Prelease
>>
>> * Figure out, how many "[WARNING] Javadoc Warnings" are there.
>> * Look into target folders if *-javadoc.jar and *-sources.jar files were
>> generated
>>
>>
>> == Handling JavaDoc checks violations
>>
>> The present setup turns all javadoc violations into warnings using
>> -Xdoclint:none [1]. I can only say that there *are* violations in Bus.
>>
>> I think that we should aim at having no violations at all - i.e. that
>> the components should be given a week or two to fix and that we should
>> switch to -Xdoclint:all after that. WDYT?
>>
>> More about -Xdoclint can be found in [2].
>>
>> Thanks,
>>
>> Peter
>>
>> [1]
>> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
>>
>> [2]http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
>> _______________________________________________
>> 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 --------------
...
20 warnings
[WARNING] Javadoc Warnings
[WARNING] /home/data/gtn-m2-repository/com/google/guava/guava/16.0.1/guava-16.0.1.jar(com/google/common/util/concurrent/ExecutionList.class): warning: Cannot find annotation method 'value()' in type 'GuardedBy': class file for javax.annotation.concurrent.GuardedBy not found
[WARNING] /home/data/gtn-m2-repository/com/google/guava/guava/16.0.1/guava-16.0.1.jar(com/google/common/util/concurrent/ExecutionList.class): warning: Cannot find annotation method 'value()' in type 'GuardedBy'
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/ConnectionContextFactory.java:270: warning - Missing closing '}' character for inline tag: "{@link #createOrReuseConnection(ConnectionContext, boolean)."
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:57: warning - Tag @see:illegal character: "123" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createConsumerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:57: warning - Tag @see:illegal character: "64" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createConsumerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:96: warning - Tag @see:illegal character: "123" in "{@link ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:96: warning - Tag @see:illegal character: "64" in "{@link ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:167: warning - Tag @see:illegal character: "123" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:167: warning - Tag @see:illegal character: "64" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:257: warning - Tag @see:illegal character: "123" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:257: warning - Tag @see:illegal character: "64" in "{@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}"
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:167: warning - Tag @link: can't find sendRPC(ProducerConnectionContext, BasicMessage) in org.hawkular.bus.common.MessageProcessor
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:57: warning - Tag @see: reference not found: {@link org.hawkular.bus.common.ConnectionContextFactory#createConsumerConnectionContext(Endpoint)}
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:96: warning - Tag @see: reference not found: {@link ConnectionContextFactory#createProducerConnectionContext(Endpoint)}
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:167: warning - @param argument "T" is not a parameter name.
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:167: warning - Tag @see: reference not found: {@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:257: warning - @param argument "R" is not a parameter name.
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java:257: warning - Tag @see: reference not found: {@link org.hawkular.bus.common.ConnectionContextFactory#createProducerConnectionContext(Endpoint)}
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/consumer/BasicMessageListener.java:59: warning - @param argument "message" is not a parameter name.
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-common/src/main/java/org/hawkular/bus/common/consumer/RPCBasicMessageListener.java:130: warning - @param argument "message" is not a parameter name.
...
1 warning
[WARNING] Javadoc Warnings
[WARNING] /home/ppalaga/git/hawkular-bus/hawkular-bus-test-common/src/main/java/org/hawkular/bus/common/test/SimpleTestListener.java:34: warning - Tag @link: can't find getBasicMessage() in org.hawkular.bus.common.test.SimpleTestListener

From ppalaga at redhat.com  Mon Mar 30 15:46:24 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 30 Mar 2015 21:46:24 +0200
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <5519A53D.2020005@redhat.com>
References: <5519518D.7030308@redhat.com> <55196003.9090202@redhat.com>
	<5519A53D.2020005@redhat.com>
Message-ID: <5519A810.6000901@redhat.com>

On 03/30/2015 09:34 PM, Peter Palaga wrote:
> Hi Jay, there is just a couple of them in Bus - see the attached file. -- P

There is no single warning about missing JavaDoc. All the warnings are 
about inconsistencies and broken syntax inside JavaDoc which indeed is 
worth fixing. -- P

> On 03/30/2015 04:38 PM, Jay Shaughnessy wrote:
>>
>> Hi Peter, to get an idea of the type and volume of issues this will
>> report, can you list the current bus warnings you're seeing?
>>
>>
>> On 3/30/2015 9:37 AM, Peter Palaga wrote:
>>> Hi *, there is a question about handling JavaDoc checks violations at
>>> the bottom.
>>>
>>> I have added maven-javadoc-plugin and maven-source-plugin to the new
>>> "release" profile in Hawkular Parent.
>>> https://github.com/hawkular/hawkular-parent-pom/pull/20
>>>
>>> I have tested the above only with Hawkular Bus. Therefore, please test
>>> the setup with your Hawkular component:
>>> * Make whatever is appropriate to make your component use the pom from
>>> https://github.com/hawkular/hawkular-parent-pom/pull/20
>>> * Invoke
>>>
>>>     mvn clean install -Prelease
>>>
>>> * Figure out, how many "[WARNING] Javadoc Warnings" are there.
>>> * Look into target folders if *-javadoc.jar and *-sources.jar files were
>>> generated
>>>
>>>
>>> == Handling JavaDoc checks violations
>>>
>>> The present setup turns all javadoc violations into warnings using
>>> -Xdoclint:none [1]. I can only say that there *are* violations in Bus.
>>>
>>> I think that we should aim at having no violations at all - i.e. that
>>> the components should be given a week or two to fix and that we should
>>> switch to -Xdoclint:all after that. WDYT?
>>>
>>> More about -Xdoclint can be found in [2].
>>>
>>> Thanks,
>>>
>>> Peter
>>>
>>> [1]
>>> https://github.com/hawkular/hawkular-parent-pom/commit/d54a8d03b4ef251d594f1cc4ff3fadfa4a1d4dd3#diff-600376dffeb79835ede4a0b285078036R110
>>>
>>>
>>> [2]http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html
>>> _______________________________________________
>>> 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
>


From mazz at redhat.com  Mon Mar 30 16:53:21 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 30 Mar 2015 16:53:21 -0400 (EDT)
Subject: [Hawkular-dev] Coming to Parent: publishing JavaDoc and sources
 via Maven
In-Reply-To: <5519A53D.2020005@redhat.com>
References: <5519518D.7030308@redhat.com> <55196003.9090202@redhat.com>
	<5519A53D.2020005@redhat.com>
Message-ID: <1073938809.6663690.1427748801386.JavaMail.zimbra@redhat.com>

> Hi Jay, there is just a couple of them in Bus - see the attached file. -- P

If everyone writes as good as javadocs as I do, I'm all for the javadoc checker :-D

From gbrown at redhat.com  Tue Mar 31 04:37:53 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 31 Mar 2015 04:37:53 -0400 (EDT)
Subject: [Hawkular-dev] Business app/services representation in Inventory
In-Reply-To: <855377734.6579916.1427789919765.JavaMail.zimbra@redhat.com>
Message-ID: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>

Hi

Before going too far down the BTM road, I just wanted to confirm whether or not we want the business app, their components services, and their relationships to IT resources they use, stored in Hawkular Inventory?

An alternative approach would be to derive the structure and relationships dynamically from the business transaction instance information.

The benefit of storing in Inventory is it enables end users to navigate through the inventory to understand the relationships to the business apps/services, as well as allow other tooling (e.g. impact analysis) to determine the effect of IT resource downtime on business apps.

Thoughts?

Regards
Gary

From lkrejci at redhat.com  Tue Mar 31 08:30:15 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 31 Mar 2015 08:30:15 -0400 (EDT)
Subject: [Hawkular-dev] Business app/services representation in Inventory
In-Reply-To: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>
References: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>
Message-ID: <1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, 31 March, 2015 10:37:53 AM
> Subject: [Hawkular-dev] Business app/services representation in Inventory
> 
> Hi
> 
> Before going too far down the BTM road, I just wanted to confirm whether or
> not we want the business app, their components services, and their
> relationships to IT resources they use, stored in Hawkular Inventory?
> 

Inventory definitely is the right place to store such information.

> An alternative approach would be to derive the structure and relationships
> dynamically from the business transaction instance information.
> 

Deriving the structure and relationships dynamically is basically
a "discovery" as called in ye olde RHQ days. That is a capability
which we'd very much like to keep.

The new inventory is (so far) unaware of special "discovery" step - everything
from resource creation to establishing relationships is done through 1 public
API that "anyone" can use.

> The benefit of storing in Inventory is it enables end users to navigate
> through the inventory to understand the relationships to the business
> apps/services, as well as allow other tooling (e.g. impact analysis) to
> determine the effect of IT resource downtime on business apps.
>

+1. I know Brett will object that that's what Artificer is for, too, but I
personally see the difference in Inventory's focus on relationships, while
Artificer is more geared towards managing content.
 
> Thoughts?
> 
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Tue Mar 31 08:53:35 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 31 Mar 2015 08:53:35 -0400 (EDT)
Subject: [Hawkular-dev] Business app/services representation in Inventory
In-Reply-To: <1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>
References: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>
	<1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>
Message-ID: <1735048842.6798059.1427806415238.JavaMail.zimbra@redhat.com>

Ok thanks for the info. 

Just to be clear - so as components are dynamically deployed/undeployed from a server, these should be reflected in the Inventory - so it represents a current view of the environment being managed?

Are there any plans to represent docker images in Inventory, associated with the servers that have been launched using them?

Regards
Gary

----- Original Message -----
> ----- Original Message -----
> > From: "Gary Brown" <gbrown at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Tuesday, 31 March, 2015 10:37:53 AM
> > Subject: [Hawkular-dev] Business app/services representation in Inventory
> > 
> > Hi
> > 
> > Before going too far down the BTM road, I just wanted to confirm whether or
> > not we want the business app, their components services, and their
> > relationships to IT resources they use, stored in Hawkular Inventory?
> > 
> 
> Inventory definitely is the right place to store such information.
> 
> > An alternative approach would be to derive the structure and relationships
> > dynamically from the business transaction instance information.
> > 
> 
> Deriving the structure and relationships dynamically is basically
> a "discovery" as called in ye olde RHQ days. That is a capability
> which we'd very much like to keep.
> 
> The new inventory is (so far) unaware of special "discovery" step -
> everything
> from resource creation to establishing relationships is done through 1 public
> API that "anyone" can use.
> 
> > The benefit of storing in Inventory is it enables end users to navigate
> > through the inventory to understand the relationships to the business
> > apps/services, as well as allow other tooling (e.g. impact analysis) to
> > determine the effect of IT resource downtime on business apps.
> >
> 
> +1. I know Brett will object that that's what Artificer is for, too, but I
> personally see the difference in Inventory's focus on relationships, while
> Artificer is more geared towards managing content.
>  
> > Thoughts?
> > 
> > Regards
> > Gary
> > _______________________________________________
> > 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
> 

From mazz at redhat.com  Tue Mar 31 09:42:09 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 31 Mar 2015 09:42:09 -0400 (EDT)
Subject: [Hawkular-dev] hawkular wildfly agent
In-Reply-To: <518105314.7161984.1427809153225.JavaMail.zimbra@redhat.com>
Message-ID: <730404591.7163585.1427809329094.JavaMail.zimbra@redhat.com>

I am almost done with the hawkular monitor agent - I basically took the wildfly-monitor project and updated it as our first agent.

I created hawkular-agent repo with stuff in it: https://github.com/hawkular/hawkular-agent

I should be done by today - just have to finish integrating with metrics.

What this will give us is a subsystem that you install in Wildfly that can then monitor other subsystems in that wildfly instance. So it should be that once done, I can put it in kettle, and we'll get nice graphs for the internals of the kettle itself.

Today it does not monitor external wildfly instances, but that should be an easy enhancement.

From lkrejci at redhat.com  Tue Mar 31 10:33:43 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 31 Mar 2015 16:33:43 +0200
Subject: [Hawkular-dev] Business app/services representation in Inventory
In-Reply-To: <1735048842.6798059.1427806415238.JavaMail.zimbra@redhat.com>
References: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>
	<1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>
	<1735048842.6798059.1427806415238.JavaMail.zimbra@redhat.com>
Message-ID: <1600858.Ta68xvy6xL@localhost.localdomain>

On Tuesday, March 31, 2015 08:53:35 Gary Brown wrote:
> Ok thanks for the info.
> 
> Just to be clear - so as components are dynamically deployed/undeployed from
> a server, these should be reflected in the Inventory - so it represents a
> current view of the environment being managed?
> 
> Are there any plans to represent docker images in Inventory, associated with
> the servers that have been launched using them?
> 

There are plans to only have a core set of predefined relationship types that 
define most basic concepts (along with semantics) like "contains", "defines", 
etc. and a couple of data types:

* tenant
* environment (these two just to model the common structure of infrastructure)
* resource type
* metric type (metadata about resources or metrics, optional)
* resource
* metric

On top of the predefined relationship types, the user is free to create any 
another relationship between any 2 entities. The semantics of those will be in 
the hand of the user.
 
All will be dynamically creatable and amendable so if you wish to create a 
resource representing a docker image, go ahead.

Things will probably get a little bit more complicated at the UI level for how 
to represent things but data model wise, we won't care what the inventory 
stores.

> Regards
> Gary
> 
> ----- Original Message -----
> 
> > ----- Original Message -----
> > 
> > > From: "Gary Brown" <gbrown at redhat.com>
> > > To: "Discussions around Hawkular development"
> > > <hawkular-dev at lists.jboss.org>
> > > Sent: Tuesday, 31 March, 2015 10:37:53 AM
> > > Subject: [Hawkular-dev] Business app/services representation in
> > > Inventory
> > > 
> > > Hi
> > > 
> > > Before going too far down the BTM road, I just wanted to confirm whether
> > > or
> > > not we want the business app, their components services, and their
> > > relationships to IT resources they use, stored in Hawkular Inventory?
> > 
> > Inventory definitely is the right place to store such information.
> > 
> > > An alternative approach would be to derive the structure and
> > > relationships
> > > dynamically from the business transaction instance information.
> > 
> > Deriving the structure and relationships dynamically is basically
> > a "discovery" as called in ye olde RHQ days. That is a capability
> > which we'd very much like to keep.
> > 
> > The new inventory is (so far) unaware of special "discovery" step -
> > everything
> > from resource creation to establishing relationships is done through 1
> > public API that "anyone" can use.
> > 
> > > The benefit of storing in Inventory is it enables end users to navigate
> > > through the inventory to understand the relationships to the business
> > > apps/services, as well as allow other tooling (e.g. impact analysis) to
> > > determine the effect of IT resource downtime on business apps.
> > 
> > +1. I know Brett will object that that's what Artificer is for, too, but I
> > personally see the difference in Inventory's focus on relationships, while
> > Artificer is more geared towards managing content.
> > 
> > > Thoughts?
> > > 
> > > Regards
> > > Gary
> > > _______________________________________________
> > > 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


From mmahoney at redhat.com  Tue Mar 31 10:38:06 2015
From: mmahoney at redhat.com (Matthew Mahoney)
Date: Tue, 31 Mar 2015 10:38:06 -0400 (EDT)
Subject: [Hawkular-dev] Public Hawkular Instances
In-Reply-To: <1647802291.9169087.1427809861520.JavaMail.zimbra@redhat.com>
Message-ID: <594183060.9221248.1427812686912.JavaMail.zimbra@redhat.com>

A couple notes on the Public Hawkular instance: 

1) Improvements have been made to the Public Hawkular instance ( http://209.132.178.218:18080 ) smoke test, as to mitigate the number of false failures that were happening. 

We invite & encourage community use of this instance. 

2) A new Public Hawkular instance ( http://209.132.178.218:18090 ) has been created which is intended to be used by Development/community for those use-cases such as Demos where you need to ensure that the instance will not be randomly restarted (for reasons such as when new Hawkular images are created, test cases git pushes, infrastructure improvements, etc). 
This instance is an on-demand build only. Please ping/email me ( mmahoney at redhat.com ) if you want access to the Jenkins Hawkular Dev build job. 

Thanks, 

Matt 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150331/98e387eb/attachment.html 

From tsegismo at redhat.com  Tue Mar 31 12:52:35 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 31 Mar 2015 18:52:35 +0200
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <418FB4EE-F493-46EC-B77F-F1DC6F6045EF@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>	<1794732.esVurXqKhI@localhost.localdomain>	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>	<2816525.LstGQiV138@localhost.localdomain>	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>	<550FE54B.9030407@redhat.com>	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>	<55101677.6090906@redhat.com>	<433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
	<418FB4EE-F493-46EC-B77F-F1DC6F6045EF@redhat.com>
Message-ID: <551AD0D3.7050304@redhat.com>

Hi,

Last week I had a long phone conversation with John about the impact of 
the coming changes to metrics on the Influx API support. I'd like to 
share the conclusion I've come to.

So in the future we'll have counters and gauges series. The goal is to 
qualify the data inserted upfront so that things like 
statistics/aggregates are automatically computed.

If we're going this way it's going to be difficult (and less relevant) 
to maintain the Influx API support, because we'll lose the 1 to 1 
mapping between an Influx series and an Hawkular Metrics series. When a 
user will post/read data, should it be stored/read to/from a counter or 
a gauge?

As Micke is working on a Go lang sink for cAdvisor/Heapster, the Influx 
support API is less important regarding our immediate needs. But we'll 
lose the ability to integrate with all the tools which support Influx 
already (Grafana and JMeter among others).

It doesn't mean we can't write our own integration code for these tools. 
But that's not for free.

Regards,
Thomas


Le 23/03/2015 15:18, John Sanda a ?crit :
>
>> On Mar 23, 2015, at 9:52 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>
>>> What I meant is that we shouldn't care about how the data is stored, if
>>> it's a counter, a gauge, a string. It's a "value point" in time.
>>
>> While I think it is good to separate the storage from the semantics,
>> I do not think we should not care how it is stored.
>>
>> For counters, which are integral values, we should probably not
>> store them as double.
>>
>> Similar, a log line should not be stored as double either :-)
>>
>>>
>>> What matters is how we query this data. For example, if you're working
>>> with a counter you'll probably be interested in applying a derivative
>>> function.
>>
>> Yes
>
> The semantics of metric type are precisely about querying. The type information tells us which aggregation functions to apply to the data points. And these functions should be utilized in both ad-hoc queries as well as the generation of pre-computed aggregates/rollups; however, I am not suggesting that this should preclude the use of other functions.


From jdoyle at redhat.com  Tue Mar 31 14:39:06 2015
From: jdoyle at redhat.com (John Doyle)
Date: Tue, 31 Mar 2015 14:39:06 -0400 (EDT)
Subject: [Hawkular-dev] Business app/services representation in Inventory
In-Reply-To: <1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>
References: <647407669.6594118.1427791073691.JavaMail.zimbra@redhat.com>
	<1837689158.7959369.1427805015434.JavaMail.zimbra@redhat.com>
Message-ID: <1122568546.10127626.1427827146205.JavaMail.zimbra@redhat.com>



----- Original Message -----
> ----- Original Message -----
> > From: "Gary Brown" <gbrown at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Tuesday, 31 March, 2015 10:37:53 AM
> > Subject: [Hawkular-dev] Business app/services representation in Inventory
> > 
> > Hi
> > 
> > Before going too far down the BTM road, I just wanted to confirm whether or
> > not we want the business app, their components services, and their
> > relationships to IT resources they use, stored in Hawkular Inventory?
> > 
> 
> Inventory definitely is the right place to store such information.
> 
> > An alternative approach would be to derive the structure and relationships
> > dynamically from the business transaction instance information.
> > 
> 
> Deriving the structure and relationships dynamically is basically
> a "discovery" as called in ye olde RHQ days. That is a capability
> which we'd very much like to keep.

+1 Very powerful and important in getting a great user experience.

> 
> The new inventory is (so far) unaware of special "discovery" step -
> everything
> from resource creation to establishing relationships is done through 1 public
> API that "anyone" can use.
> 
> > The benefit of storing in Inventory is it enables end users to navigate
> > through the inventory to understand the relationships to the business
> > apps/services, as well as allow other tooling (e.g. impact analysis) to
> > determine the effect of IT resource downtime on business apps.
> >
> 
> +1. I know Brett will object that that's what Artificer is for, too, but I
> personally see the difference in Inventory's focus on relationships, while
> Artificer is more geared towards managing content.
>  
> > Thoughts?
> > 
> > Regards
> > Gary
> > _______________________________________________
> > 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
> 

From mazz at redhat.com  Tue Mar 31 15:47:55 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 31 Mar 2015 15:47:55 -0400 (EDT)
Subject: [Hawkular-dev] hawkular agent reporting metrics
In-Reply-To: <1081580192.7464055.1427830716124.JavaMail.zimbra@redhat.com>
Message-ID: <566785324.7473295.1427831275562.JavaMail.zimbra@redhat.com>

OK, I can report some success.

In our new Hawkular Agent repo [1] I have a new-and-improved hawkular-wildfly-monitor maven module. It produces the hawkular monitor subsystem that gets deployed inside Wildfly and can monitor any number of attributes of any number of wildfly resources (right now I just have it configured to collect some memory and thread metric data - see [2] for the subsystem configuration's metricSet definitions).

It isn't baked into kettle, but using Libor's nice maven plugin, when you build that new agent you can tell maven to install it in your kettle instance (see [3] for the command to run when building hawkular-agent/hawkular-wildfly-monitor).

You won't be able to see anything in any nice graphs since kettle is strongly typed to that pinger thing. But the kettle log file should show many messages about the data getting pushed into hawkular-metrics. So, it should be in there.

This hawular agent's sole job is to monitor the wildfly instance it is running in.

That's all for now. Just wanted to give an early status since I was out last week.

--John Mazz

[1] https://github.com/hawkular/hawkular-agent
[2] https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-monitor/src/main/assembly/subsystem.xml#L32L64
[3] mvn -Dorg.hawkular.wildfly.home=/source/hawkular/kettle/target/wildfly-8.2.0.Final clean install wildfly-extension:deploy 

From mazz at redhat.com  Tue Mar 31 17:55:32 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 31 Mar 2015 17:55:32 -0400 (EDT)
Subject: [Hawkular-dev] hawkular agent reporting metrics
In-Reply-To: <566785324.7473295.1427831275562.JavaMail.zimbra@redhat.com>
References: <566785324.7473295.1427831275562.JavaMail.zimbra@redhat.com>
Message-ID: <111608951.7561205.1427838932272.JavaMail.zimbra@redhat.com>

I just added something else that Heiko and I talked about.

This agent now installs a MetricStorage object in JNDI (which is what this log message means):

2015-03-31 17:43:32,025 INFO  [org.hawkular.agent.monitor] (MSC service thread 1-4) HAWKMONITOR010003: JNDI binding [java:global/hawkular/agent/monitor/metrics]: bound to object of type [org.hawkular.agent.monitor.scheduler.storage.MetricStorage]

So this (should) mean in anyone's app that is deployed in a Wildfly instance that has our agent installed, you can do something like:

   @Resource("java:global/hawkular/agent/monitor/metrics")
   MetricStorage metricStorage;

Once you have that, you can use it to store your own metrics. Something like this:

   MetricDataPayloadBuilder data = metricStorage.getMetricDataPayloadBuilder();
   data.addDataPoint("my-metric-key", System.currentMillis, 23.846);
   data.addDataPoint("my-other-metric-key", System.currentMillis, -1.03);
   metricStorage.store(data)

Here's the MetricStorage interface - it is not complex:

https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-monitor/src/main/java/org/hawkular/agent/monitor/scheduler/storage/MetricStorage.java#L19

This now allows apps to be their own feeds.

NOTE: no inventory stuff is integrated here.

----- Original Message -----
> OK, I can report some success.
> 
> In our new Hawkular Agent repo [1] I have a new-and-improved
> hawkular-wildfly-monitor maven module. It produces the hawkular monitor
> subsystem that gets deployed inside Wildfly and can monitor any number of
> attributes of any number of wildfly resources (right now I just have it
> configured to collect some memory and thread metric data - see [2] for the
> subsystem configuration's metricSet definitions).
> 
> It isn't baked into kettle, but using Libor's nice maven plugin, when you
> build that new agent you can tell maven to install it in your kettle
> instance (see [3] for the command to run when building
> hawkular-agent/hawkular-wildfly-monitor).
> 
> You won't be able to see anything in any nice graphs since kettle is strongly
> typed to that pinger thing. But the kettle log file should show many
> messages about the data getting pushed into hawkular-metrics. So, it should
> be in there.
> 
> This hawular agent's sole job is to monitor the wildfly instance it is
> running in.
> 
> That's all for now. Just wanted to give an early status since I was out last
> week.
> 
> --John Mazz
> 
> [1] https://github.com/hawkular/hawkular-agent
> [2]
> https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-monitor/src/main/assembly/subsystem.xml#L32L64
> [3] mvn
> -Dorg.hawkular.wildfly.home=/source/hawkular/kettle/target/wildfly-8.2.0.Final
> clean install wildfly-extension:deploy
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jsanda at redhat.com  Tue Mar 31 21:36:44 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 31 Mar 2015 21:36:44 -0400
Subject: [Hawkular-dev] updated design doc for computing aggregate metrics
Message-ID: <D75AA896-7F05-42F5-BABF-B3DB832903D5@redhat.com>

I have updated update the design doc[1] for aggregate metrics to include a brief summary of a few different approaches in terms of overall architecture. I have also included details on how work can be distributed and coordinated among instances of hawkular-metrics. The changes I am proposing will also have an impact on the REST API as has been discussed in some other recent threads. Thanks in advance for any feedback.

[1] http://bit.ly/1BAfF8d

- John

From jsanda at redhat.com  Tue Mar 31 21:45:29 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 31 Mar 2015 21:45:29 -0400
Subject: [Hawkular-dev] availability and metric endpoints
In-Reply-To: <551AD0D3.7050304@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<1794732.esVurXqKhI@localhost.localdomain>
	<A7C47EDA-E75E-453D-9707-EAB7BA2B0EC1@redhat.com>
	<2816525.LstGQiV138@localhost.localdomain>
	<98985029-2B6B-471D-9A29-CF9D00E5FAC9@redhat.com>
	<EC448DA3-5B4B-48F0-A0CE-398A3B7FFA2A@redhat.com>
	<1ABEF694-99B4-4E18-A3B3-3420B99E5BB4@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
	<55101677.6090906@redhat.com>
	<433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
	<418FB4EE-F493-46EC-B77F-F1DC6F6045EF@redhat.com>
	<551AD0D3.7050304@redhat.com>
Message-ID: <8CB6E5FB-4874-49C6-BE74-A0B6E9469727@redhat.com>


> On Mar 31, 2015, at 12:52 PM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi,
> 
> Last week I had a long phone conversation with John about the impact of 
> the coming changes to metrics on the Influx API support. I'd like to 
> share the conclusion I've come to.
> 
> So in the future we'll have counters and gauges series. The goal is to 
> qualify the data inserted upfront so that things like 
> statistics/aggregates are automatically computed.

I have thought a lot about this. The need for storing aggregated metrics has been established. We may not want to store aggregate metrics for everything as we did in RHQ, but we do want the ability to store data at lower resolutions. Given that, the question that naturally follows is how should the data be aggregated. At some point that needs to be specified. I anticipate that the vast majority of metrics will be created by inventory. The inventory service will likely know about the metric type at creation time, so on that basis I think that qualifying it up front makes sense.

> 
> If we're going this way it's going to be difficult (and less relevant) 
> to maintain the Influx API support, because we'll lose the 1 to 1 
> mapping between an Influx series and an Hawkular Metrics series. When a 
> user will post/read data, should it be stored/read to/from a counter or 
> a gauge?
> 
> As Micke is working on a Go lang sink for cAdvisor/Heapster, the Influx 
> support API is less important regarding our immediate needs. But we'll 
> lose the ability to integrate with all the tools which support Influx 
> already (Grafana and JMeter among others).
> 
> It doesn't mean we can't write our own integration code for these tools. 
> But that's not for free.
> 
> Regards,
> Thomas
> 
> 
> Le 23/03/2015 15:18, John Sanda a ?crit :
>> 
>>> On Mar 23, 2015, at 9:52 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>> 
>>>> What I meant is that we shouldn't care about how the data is stored, if
>>>> it's a counter, a gauge, a string. It's a "value point" in time.
>>> 
>>> While I think it is good to separate the storage from the semantics,
>>> I do not think we should not care how it is stored.
>>> 
>>> For counters, which are integral values, we should probably not
>>> store them as double.
>>> 
>>> Similar, a log line should not be stored as double either :-)
>>> 
>>>> 
>>>> What matters is how we query this data. For example, if you're working
>>>> with a counter you'll probably be interested in applying a derivative
>>>> function.
>>> 
>>> Yes
>> 
>> The semantics of metric type are precisely about querying. The type information tells us which aggregation functions to apply to the data points. And these functions should be utilized in both ad-hoc queries as well as the generation of pre-computed aggregates/rollups; however, I am not suggesting that this should preclude the use of other functions.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From vnguyen at redhat.com  Tue Mar 31 22:17:50 2015
From: vnguyen at redhat.com (Viet Nguyen)
Date: Tue, 31 Mar 2015 22:17:50 -0400 (EDT)
Subject: [Hawkular-dev] Lots of activemq warnings in Kubernetes
In-Reply-To: <8CB6E5FB-4874-49C6-BE74-A0B6E9469727@redhat.com>
References: <94835064-8C24-41F0-AA49-B3B82412C615@redhat.com>
	<550FE54B.9030407@redhat.com>
	<1B5E3DBF-2F82-4756-AC34-CDFBD0573022@redhat.com>
	<55101677.6090906@redhat.com>
	<433D5B62-723F-4966-BC05-6F89FEA9095D@redhat.com>
	<418FB4EE-F493-46EC-B77F-F1DC6F6045EF@redhat.com>
	<551AD0D3.7050304@redhat.com>
	<8CB6E5FB-4874-49C6-BE74-A0B6E9469727@redhat.com>
Message-ID: <274908814.5860811.1427854670638.JavaMail.zimbra@redhat.com>

Just an FYI.
We are running 3 separate instances (aka pods) of Hawkular in our Kubernetes cluster.  I started seeing a lot of warnings in the log where DiscoveryNetworkConnector from one container attempts to connect to the other two. 

I'm not sure if these warnings have any undesirable effects.  

Viet

---

00:22:18,851 WARN  [org.apache.activemq.network.DiscoveryNetworkConnector] (Notifier-MulticastDiscoveryAgent-listener:DiscoveryNetworkConnector:NC:BrokerService[org.hawkular.bus.broker.hawkular-one]) Could not start network bridge between: vm://org.hawkular.bus.broker.hawkular-one?async=false&network=true and: tcp://hawkular-one-qe:62626 due to: hawkular-one-qe

00:22:19,343 INFO  [org.apache.activemq.network.DiscoveryNetworkConnector] (Notifier-MulticastDiscoveryAgent-listener:DiscoveryNetworkConnector:NC:BrokerService[org.hawkular.bus.broker.hawkular-one]) Establishing network connection from vm://org.hawkular.bus.broker.hawkular-one?async=false&network=true to tcp://hawkular-one-dev:62626

00:22:19,345 INFO  [org.apache.activemq.network.DemandForwardingBridgeSupport] (ActiveMQ BrokerService[org.hawkular.bus.broker.hawkular-one] Task-497) org.hawkular.bus.broker.hawkular-one Shutting down

00:22:19,348 INFO  [org.apache.activemq.network.DemandForwardingBridgeSupport] (ActiveMQ BrokerService[org.hawkular.bus.broker.hawkular-one] Task-497) org.hawkular.bus.broker.hawkular-one bridge to Unknown stopped

From brmeyer at redhat.com  Tue Mar 31 10:18:52 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 31 Mar 2015 14:18:52 -0000
Subject: [Hawkular-dev] "Getting Things Done" (David Allen) System: Artificer
In-Reply-To: <1200340678.9195709.1427811432431.JavaMail.zimbra@redhat.com>
Message-ID: <124157555.9197359.1427811532420.JavaMail.zimbra@redhat.com>

FWIW, I've been experimenting with Artificer as a "Getting Things Done" solution, mainly as a bit of dogfooding.  However, it fits in surprisingly well.  I'll be maintaining a demo that showcases a GTD ontology/classifier system, showing Artificer as not-just-another-artifact-repo, but also a powerful information and reference system.

https://developer.jboss.org/en/artificer/blog/2015/03/31/getting-things-done-david-allen-system-artificer-end-to-end-use-case