From ppalaga at redhat.com  Mon Feb  2 04:19:01 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 02 Feb 2015 10:19:01 +0100
Subject: [Hawkular-dev] checkstyle/enforcer
In-Reply-To: <57CDCF3D-DA5A-4678-A6A6-52C686D1BF25@redhat.com>
References: <246466987.4393386.1422659796474.JavaMail.zimbra@redhat.com>
	<57CDCF3D-DA5A-4678-A6A6-52C686D1BF25@redhat.com>
Message-ID: <54CF4105.2000005@redhat.com>

On 01/31/2015 06:09 PM, Heiko W.Rupp wrote:
>
>> Am 31.01.2015 um 00:16 schrieb John Mazzitelli <mazz at redhat.com>:
>>
>> I just converted the bus code to use hawkular-parent which in turn brought checkstyle/enforcer into play.
>>
>> I highly recommend everyone do this for your code as soon as you can - the earlier you integrate parent, and especially checkstyle/enforcer, the easier it will be on yourself. Lots of checkstyle and enforcer errors in my stuff that I had to go about fixing... you don't want to do this after you have lots of code that needs to be cleaned up.

+1

> I think those checks (while sometimes are annoying) are good.
>
> Having said that, I'd like to see a way to apply them as pre-commit and not on each
> mvn compile run.
> While devlopping in
>
> while (!working) {
>      change_some_stuff();
>      compile();
>      deploy();
>      test();
> }
>
> mode, being forced to fix import or line length issues is certainly reducing my productivity.
>
> And to repeat: I am very much in favor of enforcing all those checks once the code has left the
> above loop.

-Dlicense.skip and -Dcheckstyle.skip can help.

However, learning to code in a way acceptable for checkstyle is the way 
to go, IMO. Hence, I do not recommend using -Dcheckstyle.skip at any 
time unless you are 99.9% sure that you can comply with Checkstyle 
expectations. This is because the code you are changing should be 
formatted straight away rather than in a subsequent commit.

Your IDE can help a lot too:

* Turn on the displaying of non-printable characters in editors - to see 
tabs indentation, and trailing spaces

* Turn on the rendering of max line length border at 120. This is called 
"Show print margin" in Eclipse.

* Set automatic trailing whitespace removal on save. For Eclipse: 
http://stackoverflow.com/questions/1043433/how-to-auto-remove-trailing-whitespace-in-eclipse/26140346#26140346 
This was buggy in older Eclipse versions. You may want to try AnyEdit 
plugin from Marketplace

* Set all the Java stuff properly: import preferences, '{' placement, ...

-- P

From hrupp at redhat.com  Mon Feb  2 04:27:01 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 2 Feb 2015 10:27:01 +0100
Subject: [Hawkular-dev] checkstyle/enforcer
In-Reply-To: <54CF4105.2000005@redhat.com>
References: <246466987.4393386.1422659796474.JavaMail.zimbra@redhat.com>
	<57CDCF3D-DA5A-4678-A6A6-52C686D1BF25@redhat.com>
	<54CF4105.2000005@redhat.com>
Message-ID: <AFC2FD80-60D8-49A7-BBF0-2DB814947144@redhat.com>


> Am 02.02.2015 um 10:19 schrieb Peter Palaga <ppalaga at redhat.com>:
> However, learning to code in a way acceptable for checkstyle is the way to go, IMO. Hence, I do not recommend using -


TBH, when I debug something ( and comment out a line, which may has impact on line length, imports and so on),
I want to concentrate on debugging. And not on code formatting.



From jpkroehling at redhat.com  Mon Feb  2 05:11:48 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 02 Feb 2015 11:11:48 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54CB6964.10905@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>	<54CA5AFD.5010102@redhat.com>	<54CB55CF.3040207@redhat.com>
	<54CB6964.10905@redhat.com>
Message-ID: <54CF4D64.2000203@redhat.com>

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

On 01/30/2015 12:22 PM, Thomas Heute wrote:
> That said I am fine not providing security within Metrics and have
> it part of Hawkular only if we can. I am much more hesitant
> providing multiple stacks for multiple purposes as it makes testing
> much more complicated.

Not sure how it would work by not having security within metrics (or
any other component). Each component would have a security layer
around it, and the security is propagated from the outermost layer to
the inner layers. Example:

- - user
  -- UI console
     -- backend A
        -- backend B
     -- backend C

On this situation, UI console is protected via keycloak.js, which
sends a token to "backend A" representing the "user". If "backend A"
needs to talk to "backend B" on behalf of the user, it sends the token
with the request. But each of those components (UI console, backend A,
B, C) are protected.

Of course, we could also have unprotected backends and only the UI
console being protected, but I think it's not really an option.

Note that each component is secured by a Keycloak *adapter*. The
server needs to be "somewhere", not necessarily on the same
application server instance that a specific component resides (if
that's what you meant above by not having it "within Metrics").

- - Juca.

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

iQEcBAEBAgAGBQJUz01kAAoJECKM1e+fkPrXlz4H/2BHmd3FwVlOyJu/CBU5rrvW
PnhvI8ELWqKNzD7FRAbHaTKw5ULAOB2qYa6iKtAyqijQXqC1/ijGWVSfkavuH06V
SeA6eYUwmGGZo5O6DSs9rGFbDZJ+wXvQ3RdX4uOt9RLZQj/EMAwLefT39Rg+i+je
/FVSY/9Kd9LGNuuIcn0sh4oBzXmFKXMtXtC/39Wylb0eF0bM/phEXq/0E40S6V6S
to2MUXeYjdoAOedgE0kxpEgI+Lv86rFedpsyJ8cdo5Az8vZtErWcg8h8dti0RCkP
SFf+A+zwyVfX5/2aLPBC1k+rUSATCJtlVFAjcwZSsrlBIcIZtOu2FI68uqT5JXg=
=BDpA
-----END PGP SIGNATURE-----

From ppalaga at redhat.com  Mon Feb  2 07:45:38 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 02 Feb 2015 13:45:38 +0100
Subject: [Hawkular-dev] Time for BoM
Message-ID: <54CF7172.7000007@redhat.com>

Hi *,

now that hk projects start to switch to jboss logging, it seems to be 
inevitable to introduce the internal BoM in some form.

The task is basically to manage the common dependencies (such as 
jboss-logging) of hk projects in a central place.

I see two options:

(a) put all to hawkular-parent

(b) introduce a new artifact called "hawkular-dep" in 
hawkular-parent-pom repo. (I use "hawkular-dep" because "hawkular-bom" 
should stay reserved for an "external BoM" that would contain only our 
public APIs targeted at hawkular customers.)

Pros and cons

(b) is kind of cleaner, not mixing the build configuration with 
dependency management. But I do not see any necessity in preferring (b)

With (a), it would be easier for the hk projects to consume the 
depManagement (they would not need to import the BoM).

And even with (a), if a project cannot use hawkular-parent as its parent 
for some reason, it still can import hawkular-parent in its 
depentencyManagement as it would import any stock BoM.

I am going to try (a) if no one vetoes it within a reasonable time.

Thanks,

Peter

From ppalaga at redhat.com  Mon Feb  2 08:22:13 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 02 Feb 2015 14:22:13 +0100
Subject: [Hawkular-dev] Status on IRC
Message-ID: <54CF7A05.6040109@redhat.com>

Dear colleagues,

please consider adding some meaningful suffix such as

   |afk

or

   _away

to your IRC nick whenever you do not work so that others have a chance 
to estimate if it is worth asking you anything at the given time.

Thanks,

Peter

From miburman at redhat.com  Mon Feb  2 09:39:22 2015
From: miburman at redhat.com (Michael Burman)
Date: Mon, 02 Feb 2015 16:39:22 +0200
Subject: [Hawkular-dev] Status on IRC
In-Reply-To: <54CF7A05.6040109@redhat.com>
References: <54CF7A05.6040109@redhat.com>
Message-ID: <54CF8C1A.1050505@redhat.com>

Hi,

What's wrong with the IRC's builtin away-message and idle times that are 
designed just for that?

eg. my status from Freenode:

| gaYak (poburman at gateway/shell/tkk.fi/x-djankiicscvyrucp) (unknown)
? ircname  : Michael Burman
| channels : #go-nuts #hawkular #rhq
? server   : rajaniemi.freenode.net (Helsinki, FI, EU)
| away     : gaYak - is away: (Muualla) [BX-MsgLog On]
| actually : gaYak is connecting from *@gateway/shell/tkk.fi/session 
255.255.255.255
: idle     : 0 hours 20 mins 41 secs (signon: Thu Jan 29 20:10:39 2015)

You can see other user's info with /whois (use /whois nick nick to get 
more complex info from linked server, though some clients default to this).

   -  Micke

On 02.02.2015 15:22, Peter Palaga wrote:
> Dear colleagues,
>
> please consider adding some meaningful suffix such as
>
>     |afk
>
> or
>
>     _away
>
> to your IRC nick whenever you do not work so that others have a chance
> to estimate if it is worth asking you anything at the given time.
>
> Thanks,
>
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From mazz at redhat.com  Mon Feb  2 11:07:48 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 2 Feb 2015 11:07:48 -0500 (EST)
Subject: [Hawkular-dev] logging notes from call
In-Reply-To: <58623442.5258207.1422891981886.JavaMail.zimbra@redhat.com>
Message-ID: <697248839.5291918.1422893268299.JavaMail.zimbra@redhat.com>

Here's the notes from our call this morning regarding the use of jboss logging - chime in if I got something wrong, or if you disagree (say, for example, we should use some other third party logging framework rather than JBoss Logging :-)

Here's an example from Undertow:

https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/websockets/core/WebSocketLogger.java

We agreed that Hawkular will not use this mechanism for DEBUG or TRACE level messages, but will use it for INFO, WARN, ERROR, and FATAL.

In our message interfaces, we can do what undertow does - that is, declare the logger instance right in the interface, for example, put this in your MsgLogger interface:

   MsgLogger LOGGER = Logger.getMessageLogger(MsgLogger.class, MsgLogger.class.getPackage().getName());

Each major component will have its own logging prefix (alerts will have, for example, "HAWKALRT" or whatever they want to call it; metrics will have "HAWK-METRICS" or whatever; inventory another like "HAWKINV"). Each major component will then divy up the ID ranges how it sees fit.

It is most likely useful to have one logging interface per maven module within the major component; however, this is up to the developers how they want to separate or combine their messages - one uber interface or one per maven module or something else. but just keep in mind the pros and cons of each (e.g. if you have one uber interface, all of your maven modules will have a dependency on it - and if you add a message, all maven modules that depend on it will need to rebuild with it, even if they don't need the message - plus, all your developers will need to edit the same file throughout development, so there will be alot of git pulling, merging, and conflict resolutions).

Note that in my work, I put one message interface in each maven module that needs messages. I put them in a package called .log and I named them all "MsgLogger". I don't know if its the right thing to do to name them all the same - but having the package names differentiate them was all I needed so far to be able to find them when I needed to edit them in Eclipse (I just searched for "MsgLogger" and I got the full list of all my message loggers in the search window - each for me to pick which one I wanted). Again, time will tell if I should have named them differently rather than all the same - I really don't have an opinion either way. I don't have good argument for naming them the same OR naming them differently. Up to you what to do.

To log ad-hoc messages in the debug and trace level, you'll need to define a JBoss Logging Logger like this:

   private final Logger log = Logger.getLogger(YourClass.class);

and use debugf to log debug messages as an example:

   log.debugf("This is the first arg [%d] and this is the second [%s].", myNum, myStr);

We are hopefully going to have the parent pom declare the logging processor for us, so you only should have to declare logging deps in your maven modules, and the log code generation will just work. You need these two deps:

<dependency>
  <groupId>org.jboss.logging</groupId>
  <artifactId>jboss-logging</artifactId>
</dependency>

<dependency>
  <groupId>org.jboss.logging</groupId>
  <artifactId>jboss-logging-annotations</artifactId>
  <scope>provided</scope>
</dependency>


From jpkroehling at redhat.com  Tue Feb  3 04:52:10 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Tue, 03 Feb 2015 10:52:10 +0100
Subject: [Hawkular-dev] Keycloak + Hawt.io
Message-ID: <54D09A4A.20200@redhat.com>

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

All,

There was some progress last week with hawt.io 1.x and Keycloak
integration, thanks to mposolda.

As our target is to run on hawt.io 2.x, I think our PoC for Keycloak
on rhq-metrics is now outdated. How Keycloak will work with hawt.io
2.0 is not clear yet, though.

Besides, there's been a lot of progress in the Hawkular modules, so,
it doesn't make sense to keep the KC server embedded on rhq-metrics.

On another front, Keycloak has released 1.1.0.Final and they have
plans to better support embedding and auto registration of
applications on the next versions, with a special focus on seamless
integration between consoles (Wildfly console with Hawt.io console,
for instance). From what I'm following on their mailing list, a lot
could change on this area, which is a good thing for us.

That said, I'd expect this to move fast on the next days/weeks. Hence,
I think it's not a good idea to keep *our* efforts on this front until
that stabilizes. I'll be talking with the Keycloak team today (or
later this week, depending on their schedule), as they seemed very
interested in knowing our needs. For this, I'll use the information
gathered on the "define: tenant" thread.

As a result, I'll be closing the PR for Keycloak integration on
rhq-metrics.

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

iQEcBAEBAgAGBQJU0JpKAAoJECKM1e+fkPrXyOMH/2OmklrsocxNZ+t72rXfe6kE
WbCLSUfc93Roa+pbMgmO4CNLf3PeWZ4HHDNy02RMdwC7lSrUidK+ad/UE4ePva18
bE+NcyeZqzCErYX6vaGcp4phAhIqzKwTEO+f26UB/H5GjX8d18XDGW2zVrRIvbpd
QV3ihuXC0U7avvb3rveJj4OLst5e7diVHr863Ogxq76EJkpBQevJxAf/6hfMqQkO
PGZKeiYaPZ16YZ0mHSJIK+++KjolWwcKygHVIJUZH4bhteLclUgUV2R+y9Y6s+JH
Bt5J7LFuniKOaqrNCFU7p5ZZ/MzI1CATVo3nEtOriKo4kbxq0Kztv9CxHxL8zyU=
=OrYk
-----END PGP SIGNATURE-----

From ppalaga at redhat.com  Tue Feb  3 09:51:09 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 03 Feb 2015 15:51:09 +0100
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
Message-ID: <54D0E05D.6070904@redhat.com>

Hi *,

Heiko has proposed to add apache httpclient to parents dependency 
management. I countered that okhhttp is recently getting a lot of 
positive buzz. Please say loudly which http client you prefer to have in 
parent.

Thanks,

Peter

From snegrea at redhat.com  Tue Feb  3 09:58:51 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 3 Feb 2015 09:58:51 -0500 (EST)
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <1329002676.4309089.1422975293997.JavaMail.zimbra@redhat.com>
Message-ID: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>

Hello Everybody,

Aurelius (the company behind Titan graph database) has been acquired by DataStax (the main Cassandra developer company).

Here are two articles around the web about the acquisition and strategic direction:

http://techcrunch.com/2015/02/03/datastax-plots-aurelius-graph-database-acquihire/
http://www.zdnet.com/article/datastax-snaps-up-aurelius-and-its-titan-team-to-build-new-graph-database/



Thank you,
Stefan Negrea

Software Engineer


From hrupp at redhat.com  Tue Feb  3 10:22:40 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 3 Feb 2015 16:22:40 +0100
Subject: [Hawkular-dev] Recoding of todays meeting wrt Sample setup and Jira
	workflow
Message-ID: <79208184-A4B3-4047-A91B-F7B45202F49F@redhat.com>


Hey,

here is the link to the recording of todays meeting. 

https://bluejeans.com/s/82L@/

For reference also find the Agile board columns to the JIRA git-pull-workflow and the state transitions attached.

  Heiko




-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150203/3cac0031/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hawk-jira-workflow.png
Type: image/png
Size: 94385 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150203/3cac0031/attachment-0001.png 

From jpkroehling at redhat.com  Tue Feb  3 10:24:48 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 03 Feb 2015 16:24:48 +0100
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
In-Reply-To: <54D0E05D.6070904@redhat.com>
References: <54D0E05D.6070904@redhat.com>
Message-ID: <54D0E840.30602@redhat.com>

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

I'm for a mature library. I don't know much about OkHttp, but there
are a lot of details that a competing library needs to implement in
order to beat Apache's HTTP Client (or even Java's native
HttpUrlConnection). One common example: SNI (Server Name Indication).

- - Juca.

On 02/03/2015 03:51 PM, Peter Palaga wrote:
> Hi *,
> 
> Heiko has proposed to add apache httpclient to parents dependency 
> management. I countered that okhhttp is recently getting a lot of 
> positive buzz. Please say loudly which http client you prefer to
> have in parent.
> 
> Thanks,
> 
> Peter _______________________________________________ hawkular-dev
> mailing list hawkular-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

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

iQEcBAEBAgAGBQJU0Og/AAoJECKM1e+fkPrXh+EH/3Z9+lKMPhKzj9zWBt7r3gmK
s32yepsWfDV2ldwULkvSlmaPlRt8XwJrLjCKOjDxW0nl7tww+ov8GpAkHZAZ8BiK
n8oXS6dnwKZ8KTXB4mzNJPhd3XcOnb1AOT+5ey7FSNHMuEAvzcwZP1dvn0LSMsCU
KMBUmqDtt/WS8M0qVCtJ0APmHoUytp6/NMBgCsWo2nVbT0Gho3Yt9WmCaHn3ySpI
+teWY8S7q1gr+jzGiB3SNF7QHHPGdNjgzAzlLNodakmy2zw68Q3Ltkb1q3xMnMgt
Uyjp2hHKx6nCUzfbFQfjg5lICyBulGDa+EtEaz0lQui/EA+kqiMT91pwirQ8z8s=
=MlOs
-----END PGP SIGNATURE-----

From ike.braun at googlemail.com  Tue Feb  3 10:44:21 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Tue, 3 Feb 2015 16:44:21 +0100
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
In-Reply-To: <54D0E840.30602@redhat.com>
References: <54D0E05D.6070904@redhat.com> <54D0E840.30602@redhat.com>
Message-ID: <A2F02C1B-3361-4AA4-9757-CF60504D0776@googlemail.com>



+1 for apache http client


> On 03 Feb 2015, at 16:24, Juraci Paix?o Kr?hling <jpkroehling at redhat.com> wrote:
> 
> I'm for a mature library.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150203/5e0c3a26/attachment.html 

From gbrown at redhat.com  Tue Feb  3 12:00:36 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 3 Feb 2015 12:00:36 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <1301681968.5281948.1422982744259.JavaMail.zimbra@redhat.com>
Message-ID: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>

Hi

Just started using the hawkular parent pom and noticed that the checkstyle config does not check the javadoc comments.

Not sure if this was previously discussed and decided that it shouldn't be checked, but thought I had better check, as this is one area that can be time consuming to update code after enabling.

Previously I had been using this config in Overlord: https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97

Regards
Gary

From mazz at redhat.com  Tue Feb  3 13:11:49 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 3 Feb 2015 13:11:49 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
Message-ID: <297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>

Does this just look to see if all public methods have SOME javadoc? (i.e. it just sees if they are missing)

Does it impose some type of formatting as well?

----- Original Message -----
> Hi
> 
> Just started using the hawkular parent pom and noticed that the checkstyle
> config does not check the javadoc comments.
> 
> Not sure if this was previously discussed and decided that it shouldn't be
> checked, but thought I had better check, as this is one area that can be
> time consuming to update code after enabling.
> 
> Previously I had been using this config in Overlord:
> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> 
> 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 Feb  3 13:19:50 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 3 Feb 2015 13:19:50 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
Message-ID: <2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>

It checks presence of javadoc, and matching entries for parameters and return values.

----- Original Message -----
> Does this just look to see if all public methods have SOME javadoc? (i.e. it
> just sees if they are missing)
> 
> Does it impose some type of formatting as well?
> 
> ----- Original Message -----
> > Hi
> > 
> > Just started using the hawkular parent pom and noticed that the checkstyle
> > config does not check the javadoc comments.
> > 
> > Not sure if this was previously discussed and decided that it shouldn't be
> > checked, but thought I had better check, as this is one area that can be
> > time consuming to update code after enabling.
> > 
> > Previously I had been using this config in Overlord:
> > https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> > 
> > 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 ppalaga at redhat.com  Tue Feb  3 15:35:55 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 03 Feb 2015 21:35:55 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
Message-ID: <54D1312B.8080409@redhat.com>

 > Not sure if this was previously discussed and decided

Not that I knew. We decided to start from a very minimal set of rules 
that we initially copied from wildfly. We have not changed much: we just 
increased the line length to 120 chars and extended the plaintext checks 
to non-java files.

I am personally undecided about JavaDoc checks. Having a meaningful 
JavaDoc is a good thing.
Checkstyle can certainly help to some extent, but:
(1) It is not enough as it will never check the meaningfulness
(2) I tend to believe that some methods (incl. getters and setters) do 
not need JavaDoc
(3) Non-public methods often should have JavaDoc too.

I am a strong proponent of four eyes principle: no single commit can go 
to master without being reviewed properly. It should be reviewer's 
responsibility to check test coverage, JavaDoc, etc.

Best wishes,

-- Peter

On 02/03/2015 07:19 PM, Gary Brown wrote:
> It checks presence of javadoc, and matching entries for parameters and return values.
>
> ----- Original Message -----
>> Does this just look to see if all public methods have SOME javadoc? (i.e. it
>> just sees if they are missing)
>>
>> Does it impose some type of formatting as well?
>>
>> ----- Original Message -----
>>> Hi
>>>
>>> Just started using the hawkular parent pom and noticed that the checkstyle
>>> config does not check the javadoc comments.
>>>
>>> Not sure if this was previously discussed and decided that it shouldn't be
>>> checked, but thought I had better check, as this is one area that can be
>>> time consuming to update code after enabling.
>>>
>>> Previously I had been using this config in Overlord:
>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>
>>> 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 gbrown at redhat.com  Wed Feb  4 03:34:52 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 4 Feb 2015 03:34:52 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D1312B.8080409@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
	<54D1312B.8080409@redhat.com>
Message-ID: <324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>

Hi Peter

The main reason I mentioned it was because although I had been diligent in Overlord re javadoc, once the rule was enabled it picked up many issues - primarily inconsistency between parameter names, or missing parameter entries.

I agree meaningful text can only be picked up by review, but think that areas where automated checking is possible shouldn't be part of the reviewers responsibility (i.e. to reduce their burden so they can focus on other areas).

Regards
Gary

----- Original Message -----
> > Not sure if this was previously discussed and decided
> 
> Not that I knew. We decided to start from a very minimal set of rules
> that we initially copied from wildfly. We have not changed much: we just
> increased the line length to 120 chars and extended the plaintext checks
> to non-java files.
> 
> I am personally undecided about JavaDoc checks. Having a meaningful
> JavaDoc is a good thing.
> Checkstyle can certainly help to some extent, but:
> (1) It is not enough as it will never check the meaningfulness
> (2) I tend to believe that some methods (incl. getters and setters) do
> not need JavaDoc
> (3) Non-public methods often should have JavaDoc too.
> 
> I am a strong proponent of four eyes principle: no single commit can go
> to master without being reviewed properly. It should be reviewer's
> responsibility to check test coverage, JavaDoc, etc.
> 
> Best wishes,
> 
> -- Peter
> 
> On 02/03/2015 07:19 PM, Gary Brown wrote:
> > It checks presence of javadoc, and matching entries for parameters and
> > return values.
> >
> > ----- Original Message -----
> >> Does this just look to see if all public methods have SOME javadoc? (i.e.
> >> it
> >> just sees if they are missing)
> >>
> >> Does it impose some type of formatting as well?
> >>
> >> ----- Original Message -----
> >>> Hi
> >>>
> >>> Just started using the hawkular parent pom and noticed that the
> >>> checkstyle
> >>> config does not check the javadoc comments.
> >>>
> >>> Not sure if this was previously discussed and decided that it shouldn't
> >>> be
> >>> checked, but thought I had better check, as this is one area that can be
> >>> time consuming to update code after enabling.
> >>>
> >>> Previously I had been using this config in Overlord:
> >>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> >>>
> >>> 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 hrupp at redhat.com  Wed Feb  4 03:51:45 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Feb 2015 09:51:45 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
	<54D1312B.8080409@redhat.com>
	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>
Message-ID: <3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>

Hey,

I am in favor of JavaDoc and having some checking - especially as in RHQ we have many places
where the param list of a method and the one in JavaDoc have diverged over time.

I am not in favor of forcing javadoc on every method (especially getter/setter), as this will just end up in

/** This is the getter for foo */
public foo getFoo() {}

Which is imo worse than no doc.

Unfortunately I think the default for JavaDoc is not to document private properties (=not include in the generated html),
so that putting the comment on the property itself does not help for browsing docs.




> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
> 
> Hi Peter
> 
> The main reason I mentioned it was because although I had been diligent in Overlord re javadoc, once the rule was enabled it picked up many issues - primarily inconsistency between parameter names, or missing parameter entries.
> 
> I agree meaningful text can only be picked up by review, but think that areas where automated checking is possible shouldn't be part of the reviewers responsibility (i.e. to reduce their burden so they can focus on other areas).
> 
> Regards
> Gary
> 
> ----- Original Message -----
>>> Not sure if this was previously discussed and decided
>> 
>> Not that I knew. We decided to start from a very minimal set of rules
>> that we initially copied from wildfly. We have not changed much: we just
>> increased the line length to 120 chars and extended the plaintext checks
>> to non-java files.
>> 
>> I am personally undecided about JavaDoc checks. Having a meaningful
>> JavaDoc is a good thing.
>> Checkstyle can certainly help to some extent, but:
>> (1) It is not enough as it will never check the meaningfulness
>> (2) I tend to believe that some methods (incl. getters and setters) do
>> not need JavaDoc
>> (3) Non-public methods often should have JavaDoc too.
>> 
>> I am a strong proponent of four eyes principle: no single commit can go
>> to master without being reviewed properly. It should be reviewer's
>> responsibility to check test coverage, JavaDoc, etc.
>> 
>> Best wishes,
>> 
>> -- Peter
>> 
>> On 02/03/2015 07:19 PM, Gary Brown wrote:
>>> It checks presence of javadoc, and matching entries for parameters and
>>> return values.
>>> 
>>> ----- Original Message -----
>>>> Does this just look to see if all public methods have SOME javadoc? (i.e.
>>>> it
>>>> just sees if they are missing)
>>>> 
>>>> Does it impose some type of formatting as well?
>>>> 
>>>> ----- Original Message -----
>>>>> Hi
>>>>> 
>>>>> Just started using the hawkular parent pom and noticed that the
>>>>> checkstyle
>>>>> config does not check the javadoc comments.
>>>>> 
>>>>> Not sure if this was previously discussed and decided that it shouldn't
>>>>> be
>>>>> checked, but thought I had better check, as this is one area that can be
>>>>> time consuming to update code after enabling.
>>>>> 
>>>>> Previously I had been using this config in Overlord:
>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>>> 
>>>>> 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
>>> 
>> 
>> 
> _______________________________________________
> 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  Wed Feb  4 04:02:02 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 4 Feb 2015 04:02:02 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
	<54D1312B.8080409@redhat.com>
	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>
	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
Message-ID: <748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>

Hi

According to the docs (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod) the 'allowMissingPropertyJavadocs' parameter can be used to skip checking of getters/setters.

Regards
Gary

----- Original Message -----
> Hey,
> 
> I am in favor of JavaDoc and having some checking - especially as in RHQ we
> have many places
> where the param list of a method and the one in JavaDoc have diverged over
> time.
> 
> I am not in favor of forcing javadoc on every method (especially
> getter/setter), as this will just end up in
> 
> /** This is the getter for foo */
> public foo getFoo() {}
> 
> Which is imo worse than no doc.
> 
> Unfortunately I think the default for JavaDoc is not to document private
> properties (=not include in the generated html),
> so that putting the comment on the property itself does not help for browsing
> docs.
> 
> 
> 
> 
> > Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
> > 
> > Hi Peter
> > 
> > The main reason I mentioned it was because although I had been diligent in
> > Overlord re javadoc, once the rule was enabled it picked up many issues -
> > primarily inconsistency between parameter names, or missing parameter
> > entries.
> > 
> > I agree meaningful text can only be picked up by review, but think that
> > areas where automated checking is possible shouldn't be part of the
> > reviewers responsibility (i.e. to reduce their burden so they can focus on
> > other areas).
> > 
> > Regards
> > Gary
> > 
> > ----- Original Message -----
> >>> Not sure if this was previously discussed and decided
> >> 
> >> Not that I knew. We decided to start from a very minimal set of rules
> >> that we initially copied from wildfly. We have not changed much: we just
> >> increased the line length to 120 chars and extended the plaintext checks
> >> to non-java files.
> >> 
> >> I am personally undecided about JavaDoc checks. Having a meaningful
> >> JavaDoc is a good thing.
> >> Checkstyle can certainly help to some extent, but:
> >> (1) It is not enough as it will never check the meaningfulness
> >> (2) I tend to believe that some methods (incl. getters and setters) do
> >> not need JavaDoc
> >> (3) Non-public methods often should have JavaDoc too.
> >> 
> >> I am a strong proponent of four eyes principle: no single commit can go
> >> to master without being reviewed properly. It should be reviewer's
> >> responsibility to check test coverage, JavaDoc, etc.
> >> 
> >> Best wishes,
> >> 
> >> -- Peter
> >> 
> >> On 02/03/2015 07:19 PM, Gary Brown wrote:
> >>> It checks presence of javadoc, and matching entries for parameters and
> >>> return values.
> >>> 
> >>> ----- Original Message -----
> >>>> Does this just look to see if all public methods have SOME javadoc?
> >>>> (i.e.
> >>>> it
> >>>> just sees if they are missing)
> >>>> 
> >>>> Does it impose some type of formatting as well?
> >>>> 
> >>>> ----- Original Message -----
> >>>>> Hi
> >>>>> 
> >>>>> Just started using the hawkular parent pom and noticed that the
> >>>>> checkstyle
> >>>>> config does not check the javadoc comments.
> >>>>> 
> >>>>> Not sure if this was previously discussed and decided that it shouldn't
> >>>>> be
> >>>>> checked, but thought I had better check, as this is one area that can
> >>>>> be
> >>>>> time consuming to update code after enabling.
> >>>>> 
> >>>>> Previously I had been using this config in Overlord:
> >>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> >>>>> 
> >>>>> 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
> >>> 
> >> 
> >> 
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From tsegismo at redhat.com  Wed Feb  4 04:57:10 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 10:57:10 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>	<54D1312B.8080409@redhat.com>	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
Message-ID: <54D1ECF6.7050203@redhat.com>

There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks 
provided we don't fail the build on missing Javadoc. It's not just 
getters/setters: sometimes your method has a meaningful name and it does 
not make any sense to write Javadoc for it.

Le 04/02/2015 10:02, Gary Brown a ?crit :
> Hi
>
> According to the docs (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod) the 'allowMissingPropertyJavadocs' parameter can be used to skip checking of getters/setters.
>
> Regards
> Gary
>
> ----- Original Message -----
>> Hey,
>>
>> I am in favor of JavaDoc and having some checking - especially as in RHQ we
>> have many places
>> where the param list of a method and the one in JavaDoc have diverged over
>> time.
>>
>> I am not in favor of forcing javadoc on every method (especially
>> getter/setter), as this will just end up in
>>
>> /** This is the getter for foo */
>> public foo getFoo() {}
>>
>> Which is imo worse than no doc.
>>
>> Unfortunately I think the default for JavaDoc is not to document private
>> properties (=not include in the generated html),
>> so that putting the comment on the property itself does not help for browsing
>> docs.
>>
>>
>>
>>
>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
>>>
>>> Hi Peter
>>>
>>> The main reason I mentioned it was because although I had been diligent in
>>> Overlord re javadoc, once the rule was enabled it picked up many issues -
>>> primarily inconsistency between parameter names, or missing parameter
>>> entries.
>>>
>>> I agree meaningful text can only be picked up by review, but think that
>>> areas where automated checking is possible shouldn't be part of the
>>> reviewers responsibility (i.e. to reduce their burden so they can focus on
>>> other areas).
>>>
>>> Regards
>>> Gary
>>>
>>> ----- Original Message -----
>>>>> Not sure if this was previously discussed and decided
>>>>
>>>> Not that I knew. We decided to start from a very minimal set of rules
>>>> that we initially copied from wildfly. We have not changed much: we just
>>>> increased the line length to 120 chars and extended the plaintext checks
>>>> to non-java files.
>>>>
>>>> I am personally undecided about JavaDoc checks. Having a meaningful
>>>> JavaDoc is a good thing.
>>>> Checkstyle can certainly help to some extent, but:
>>>> (1) It is not enough as it will never check the meaningfulness
>>>> (2) I tend to believe that some methods (incl. getters and setters) do
>>>> not need JavaDoc
>>>> (3) Non-public methods often should have JavaDoc too.
>>>>
>>>> I am a strong proponent of four eyes principle: no single commit can go
>>>> to master without being reviewed properly. It should be reviewer's
>>>> responsibility to check test coverage, JavaDoc, etc.
>>>>
>>>> Best wishes,
>>>>
>>>> -- Peter
>>>>
>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
>>>>> It checks presence of javadoc, and matching entries for parameters and
>>>>> return values.
>>>>>
>>>>> ----- Original Message -----
>>>>>> Does this just look to see if all public methods have SOME javadoc?
>>>>>> (i.e.
>>>>>> it
>>>>>> just sees if they are missing)
>>>>>>
>>>>>> Does it impose some type of formatting as well?
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> Hi
>>>>>>>
>>>>>>> Just started using the hawkular parent pom and noticed that the
>>>>>>> checkstyle
>>>>>>> config does not check the javadoc comments.
>>>>>>>
>>>>>>> Not sure if this was previously discussed and decided that it shouldn't
>>>>>>> be
>>>>>>> checked, but thought I had better check, as this is one area that can
>>>>>>> be
>>>>>>> time consuming to update code after enabling.
>>>>>>>
>>>>>>> Previously I had been using this config in Overlord:
>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>>>>>
>>>>>>> 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
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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  Wed Feb  4 05:03:03 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Feb 2015 11:03:03 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D1ECF6.7050203@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>
	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>
	<54D1312B.8080409@redhat.com>
	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>
	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
	<54D1ECF6.7050203@redhat.com>
Message-ID: <457D1853-B418-4272-B219-7FEBBD087927@redhat.com>


> Am 04.02.2015 um 10:57 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> getters/setters: sometimes your method has a meaningful name and it does 
> not make any sense to write Javadoc for it.

While I agree in general, we have also seen during JON development, that we
were asked to document all methods in remote interfaces. I don't think this is a
task that we want to do retroactively in a year or two



From tsegismo at redhat.com  Wed Feb  4 05:18:09 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 11:18:09 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <457D1853-B418-4272-B219-7FEBBD087927@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>	<54D1312B.8080409@redhat.com>	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>	<54D1ECF6.7050203@redhat.com>
	<457D1853-B418-4272-B219-7FEBBD087927@redhat.com>
Message-ID: <54D1F1E1.9070604@redhat.com>

Le 04/02/2015 11:03, Heiko W.Rupp a ?crit :
>
>> Am 04.02.2015 um 10:57 schrieb Thomas Segismont <tsegismo at redhat.com>:
>>
>> getters/setters: sometimes your method has a meaningful name and it does
>> not make any sense to write Javadoc for it.
>
> While I agree in general, we have also seen during JON development, that we
> were asked to document all methods in remote interfaces. I don't think this is a
> task that we want to do retroactively in a year or two

Couldn't remote APIs be moved to their own Maven module, which would 
override the default config wrt Javadoc checks?



From tsegismo at redhat.com  Wed Feb  4 05:33:23 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 11:33:23 +0100
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
In-Reply-To: <A2F02C1B-3361-4AA4-9757-CF60504D0776@googlemail.com>
References: <54D0E05D.6070904@redhat.com> <54D0E840.30602@redhat.com>
	<A2F02C1B-3361-4AA4-9757-CF60504D0776@googlemail.com>
Message-ID: <54D1F573.2050107@redhat.com>

+1 for Apache Http Client and Async Http client.

It's just a BOM managed dependency declaration. It doesn't mean that we 
can't use something if there's a good reason to do so (it does mean we 
won't use 5 different versions of the tool).


Le 03/02/2015 16:44, Heiko Braun a ?crit :
>
>
> +1 for apache http client
>
>
>> On 03 Feb 2015, at 16:24, Juraci Paix?o Kr?hling
>> <jpkroehling at redhat.com <mailto:jpkroehling at redhat.com>> wrote:
>>
>> I'm for a mature library.
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From miburman at redhat.com  Wed Feb  4 07:33:09 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 04 Feb 2015 14:33:09 +0200
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
In-Reply-To: <54D1F573.2050107@redhat.com>
References: <54D0E05D.6070904@redhat.com>
	<54D0E840.30602@redhat.com>	<A2F02C1B-3361-4AA4-9757-CF60504D0776@googlemail.com>
	<54D1F573.2050107@redhat.com>
Message-ID: <54D21185.3040508@redhat.com>

HttpAsyncClient should not be used, it hasn't been updated after 2011 
and uses a very old version of HttpClient.

   -  Micke

On 04.02.2015 12:33, Thomas Segismont wrote:
> +1 for Apache Http Client and Async Http client.
>
> It's just a BOM managed dependency declaration. It doesn't mean that we
> can't use something if there's a good reason to do so (it does mean we
> won't use 5 different versions of the tool).
>
>
> Le 03/02/2015 16:44, Heiko Braun a ?crit :
>>
>> +1 for apache http client
>>
>>
>>> On 03 Feb 2015, at 16:24, Juraci Paix?o Kr?hling
>>> <jpkroehling at redhat.com <mailto:jpkroehling at redhat.com>> wrote:
>>>
>>> I'm for a mature library.
>>
>>
>> _______________________________________________
>> 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  Wed Feb  4 07:49:39 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 04 Feb 2015 13:49:39 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D1ECF6.7050203@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>	<54D1312B.8080409@redhat.com>	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
	<54D1ECF6.7050203@redhat.com>
Message-ID: <54D21563.7010308@redhat.com>

On 02/04/2015 10:57 AM, Thomas Segismont wrote:
> There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks
> provided we don't fail the build on missing Javadoc.

Not failing and just having the warnings in the build log is useless. 
What is not enforced, will be ignored. I am against introducing anything 
that can be ignored or overseen to checkstyle.

> It's not just
> getters/setters: sometimes your method has a meaningful name and it does
> not make any sense to write Javadoc for it.

I do not believe that something like this can be configured with 
Checkstyle.

However given that the general idea of adding JavaDoc checks has become 
some level of support here, Gary or anybody else, feel free to submit a 
PR to our checkstyle.xml [1] plus do not forget to test your proposal 
with metrics, bus and alerts.

[1] 
https://github.com/hawkular/hawkular-build-tools/blob/master/src/main/resources/hawkular-checkstyle/checkstyle.xml

-- P

> Le 04/02/2015 10:02, Gary Brown a ?crit :
>> Hi
>>
>> According to the docs (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod) the 'allowMissingPropertyJavadocs' parameter can be used to skip checking of getters/setters.
>>
>> Regards
>> Gary
>>
>> ----- Original Message -----
>>> Hey,
>>>
>>> I am in favor of JavaDoc and having some checking - especially as in RHQ we
>>> have many places
>>> where the param list of a method and the one in JavaDoc have diverged over
>>> time.
>>>
>>> I am not in favor of forcing javadoc on every method (especially
>>> getter/setter), as this will just end up in
>>>
>>> /** This is the getter for foo */
>>> public foo getFoo() {}
>>>
>>> Which is imo worse than no doc.
>>>
>>> Unfortunately I think the default for JavaDoc is not to document private
>>> properties (=not include in the generated html),
>>> so that putting the comment on the property itself does not help for browsing
>>> docs.
>>>
>>>
>>>
>>>
>>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
>>>>
>>>> Hi Peter
>>>>
>>>> The main reason I mentioned it was because although I had been diligent in
>>>> Overlord re javadoc, once the rule was enabled it picked up many issues -
>>>> primarily inconsistency between parameter names, or missing parameter
>>>> entries.
>>>>
>>>> I agree meaningful text can only be picked up by review, but think that
>>>> areas where automated checking is possible shouldn't be part of the
>>>> reviewers responsibility (i.e. to reduce their burden so they can focus on
>>>> other areas).
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>>> Not sure if this was previously discussed and decided
>>>>>
>>>>> Not that I knew. We decided to start from a very minimal set of rules
>>>>> that we initially copied from wildfly. We have not changed much: we just
>>>>> increased the line length to 120 chars and extended the plaintext checks
>>>>> to non-java files.
>>>>>
>>>>> I am personally undecided about JavaDoc checks. Having a meaningful
>>>>> JavaDoc is a good thing.
>>>>> Checkstyle can certainly help to some extent, but:
>>>>> (1) It is not enough as it will never check the meaningfulness
>>>>> (2) I tend to believe that some methods (incl. getters and setters) do
>>>>> not need JavaDoc
>>>>> (3) Non-public methods often should have JavaDoc too.
>>>>>
>>>>> I am a strong proponent of four eyes principle: no single commit can go
>>>>> to master without being reviewed properly. It should be reviewer's
>>>>> responsibility to check test coverage, JavaDoc, etc.
>>>>>
>>>>> Best wishes,
>>>>>
>>>>> -- Peter
>>>>>
>>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
>>>>>> It checks presence of javadoc, and matching entries for parameters and
>>>>>> return values.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> Does this just look to see if all public methods have SOME javadoc?
>>>>>>> (i.e.
>>>>>>> it
>>>>>>> just sees if they are missing)
>>>>>>>
>>>>>>> Does it impose some type of formatting as well?
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Just started using the hawkular parent pom and noticed that the
>>>>>>>> checkstyle
>>>>>>>> config does not check the javadoc comments.
>>>>>>>>
>>>>>>>> Not sure if this was previously discussed and decided that it shouldn't
>>>>>>>> be
>>>>>>>> checked, but thought I had better check, as this is one area that can
>>>>>>>> be
>>>>>>>> time consuming to update code after enabling.
>>>>>>>>
>>>>>>>> Previously I had been using this config in Overlord:
>>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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 tsegismo at redhat.com  Wed Feb  4 07:57:20 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 13:57:20 +0100
Subject: [Hawkular-dev] httpclient vs okhhttp vs other
In-Reply-To: <54D21185.3040508@redhat.com>
References: <54D0E05D.6070904@redhat.com>	<54D0E840.30602@redhat.com>	<A2F02C1B-3361-4AA4-9757-CF60504D0776@googlemail.com>	<54D1F573.2050107@redhat.com>
	<54D21185.3040508@redhat.com>
Message-ID: <54D21730.8060807@redhat.com>

This one was released in August 2014

http://search.maven.org/#artifactdetails|org.apache.httpcomponents|httpasyncclient|4.0.2|jar

Which one are you talking about?

Le 04/02/2015 13:33, Michael Burman a ?crit :
> HttpAsyncClient should not be used, it hasn't been updated after 2011
> and uses a very old version of HttpClient.
>
>     -  Micke
>
> On 04.02.2015 12:33, Thomas Segismont wrote:
>> +1 for Apache Http Client and Async Http client.
>>
>> It's just a BOM managed dependency declaration. It doesn't mean that we
>> can't use something if there's a good reason to do so (it does mean we
>> won't use 5 different versions of the tool).
>>
>>
>> Le 03/02/2015 16:44, Heiko Braun a ?crit :
>>>
>>> +1 for apache http client
>>>
>>>
>>>> On 03 Feb 2015, at 16:24, Juraci Paix?o Kr?hling
>>>> <jpkroehling at redhat.com <mailto:jpkroehling at redhat.com>> wrote:
>>>>
>>>> I'm for a mature library.
>>>
>>>
>>> _______________________________________________
>>> 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 tsegismo at redhat.com  Wed Feb  4 08:10:00 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 14:10:00 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54CB6964.10905@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>	<54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com> <54CB6964.10905@redhat.com>
Message-ID: <54D21A28.2030405@redhat.com>

Le 30/01/2015 12:22, Thomas Heute a ?crit :
>> When you install InfluxDB, carbon/whisper, opentsdb, you don't need to
>> install an identity management server, period.
>
> They are also not multi-tenant solutions AFAIK. I don't see Metrics
> competing with the solution mentioned, actually we looked into those to
> use as underlying solution.
>

To me, it doesn't matter if the team doesn't put all its efforts in 
maintaining a standalone metrics distribution. But it does matter to 
enable and help re-use outside of our principal use case (the hawkular 
suite), because we'd miss important feedback/bug reports/contributions 
from the community.

From tsegismo at redhat.com  Wed Feb  4 08:30:59 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 14:30:59 +0100
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D21563.7010308@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>	<54D1312B.8080409@redhat.com>	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
	<54D1ECF6.7050203@redhat.com> <54D21563.7010308@redhat.com>
Message-ID: <54D21F13.40209@redhat.com>

Le 04/02/2015 13:49, Peter Palaga a ?crit :
> On 02/04/2015 10:57 AM, Thomas Segismont wrote:
>> There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks
>> provided we don't fail the build on missing Javadoc.
>
> Not failing and just having the warnings in the build log is useless.

There's a misunderstanding: I'm talking about not failing the build if a 
single method does not have Javadoc.

If a method has Javadoc which does not represent reality (wrong list of 
parameters for example) then yes, the build should fail.

> What is not enforced, will be ignored.

That's not my opinion.

> I am against introducing anything that can be ignored or overseen to checkstyle.

See my first comment, I'm talking about not failing the build if a 
single method does not have Javadoc.

>
>> It's not just
>> getters/setters: sometimes your method has a meaningful name and it does
>> not make any sense to write Javadoc for it.
>
> I do not believe that something like this can be configured with
> Checkstyle.

Isn't that the purpose of "allowMissingJavadoc"?

>
> However given that the general idea of adding JavaDoc checks has become
> some level of support here, Gary or anybody else, feel free to submit a
> PR to our checkstyle.xml [1] plus do not forget to test your proposal
> with metrics, bus and alerts.
>
> [1]
> https://github.com/hawkular/hawkular-build-tools/blob/master/src/main/resources/hawkular-checkstyle/checkstyle.xml
>
>
> -- P
>
>> Le 04/02/2015 10:02, Gary Brown a ?crit :
>>> Hi
>>>
>>> According to the docs
>>> (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod)
>>> the 'allowMissingPropertyJavadocs' parameter can be used to skip
>>> checking of getters/setters.
>>>
>>> Regards
>>> Gary
>>>
>>> ----- Original Message -----
>>>> Hey,
>>>>
>>>> I am in favor of JavaDoc and having some checking - especially as in
>>>> RHQ we
>>>> have many places
>>>> where the param list of a method and the one in JavaDoc have
>>>> diverged over
>>>> time.
>>>>
>>>> I am not in favor of forcing javadoc on every method (especially
>>>> getter/setter), as this will just end up in
>>>>
>>>> /** This is the getter for foo */
>>>> public foo getFoo() {}
>>>>
>>>> Which is imo worse than no doc.
>>>>
>>>> Unfortunately I think the default for JavaDoc is not to document
>>>> private
>>>> properties (=not include in the generated html),
>>>> so that putting the comment on the property itself does not help for
>>>> browsing
>>>> docs.
>>>>
>>>>
>>>>
>>>>
>>>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
>>>>>
>>>>> Hi Peter
>>>>>
>>>>> The main reason I mentioned it was because although I had been
>>>>> diligent in
>>>>> Overlord re javadoc, once the rule was enabled it picked up many
>>>>> issues -
>>>>> primarily inconsistency between parameter names, or missing parameter
>>>>> entries.
>>>>>
>>>>> I agree meaningful text can only be picked up by review, but think
>>>>> that
>>>>> areas where automated checking is possible shouldn't be part of the
>>>>> reviewers responsibility (i.e. to reduce their burden so they can
>>>>> focus on
>>>>> other areas).
>>>>>
>>>>> Regards
>>>>> Gary
>>>>>
>>>>> ----- Original Message -----
>>>>>>> Not sure if this was previously discussed and decided
>>>>>>
>>>>>> Not that I knew. We decided to start from a very minimal set of rules
>>>>>> that we initially copied from wildfly. We have not changed much:
>>>>>> we just
>>>>>> increased the line length to 120 chars and extended the plaintext
>>>>>> checks
>>>>>> to non-java files.
>>>>>>
>>>>>> I am personally undecided about JavaDoc checks. Having a meaningful
>>>>>> JavaDoc is a good thing.
>>>>>> Checkstyle can certainly help to some extent, but:
>>>>>> (1) It is not enough as it will never check the meaningfulness
>>>>>> (2) I tend to believe that some methods (incl. getters and
>>>>>> setters) do
>>>>>> not need JavaDoc
>>>>>> (3) Non-public methods often should have JavaDoc too.
>>>>>>
>>>>>> I am a strong proponent of four eyes principle: no single commit
>>>>>> can go
>>>>>> to master without being reviewed properly. It should be reviewer's
>>>>>> responsibility to check test coverage, JavaDoc, etc.
>>>>>>
>>>>>> Best wishes,
>>>>>>
>>>>>> -- Peter
>>>>>>
>>>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
>>>>>>> It checks presence of javadoc, and matching entries for
>>>>>>> parameters and
>>>>>>> return values.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> Does this just look to see if all public methods have SOME javadoc?
>>>>>>>> (i.e.
>>>>>>>> it
>>>>>>>> just sees if they are missing)
>>>>>>>>
>>>>>>>> Does it impose some type of formatting as well?
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Just started using the hawkular parent pom and noticed that the
>>>>>>>>> checkstyle
>>>>>>>>> config does not check the javadoc comments.
>>>>>>>>>
>>>>>>>>> Not sure if this was previously discussed and decided that it
>>>>>>>>> shouldn't
>>>>>>>>> be
>>>>>>>>> checked, but thought I had better check, as this is one area
>>>>>>>>> that can
>>>>>>>>> be
>>>>>>>>> time consuming to update code after enabling.
>>>>>>>>>
>>>>>>>>> Previously I had been using this config in Overlord:
>>>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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  Wed Feb  4 09:18:15 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 04 Feb 2015 09:18:15 -0500
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54D21A28.2030405@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>	<54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com> <54CB6964.10905@redhat.com>
	<54D21A28.2030405@redhat.com>
Message-ID: <54D22A27.2020702@redhat.com>



On 02/04/2015 08:10 AM, Thomas Segismont wrote:
> Le 30/01/2015 12:22, Thomas Heute a ?crit :
>>> When you install InfluxDB, carbon/whisper, opentsdb, you don't need to
>>> install an identity management server, period.
>>
>> They are also not multi-tenant solutions AFAIK. I don't see Metrics
>> competing with the solution mentioned, actually we looked into those to
>> use as underlying solution.
>>
>
> To me, it doesn't matter if the team doesn't put all its efforts in
> maintaining a standalone metrics distribution. But it does matter to
> enable and help re-use outside of our principal use case (the hawkular
> suite), because we'd miss important feedback/bug reports/contributions
> from the community.

That doesn't mean we compete head to head with the solutions above :)

Having a multitenant solution is a differentiator and having too many 
options is confusing (as you can take the full hawkular, or hawkular 
metrics with and without secure multitenancy), we need to make choices 
and we need to deliver ;)

From ike.braun at googlemail.com  Wed Feb  4 09:23:53 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Wed, 4 Feb 2015 15:23:53 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54D21A28.2030405@redhat.com>
References: <54C28AE2.3010509@redhat.com> <54C601D9.9030102@redhat.com>
	<54C75B94.8080103@redhat.com> <54C79ECF.7020109@redhat.com>
	<54CA1768.8050105@redhat.com> <54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com> <54CB6964.10905@redhat.com>
	<54D21A28.2030405@redhat.com>
Message-ID: <D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>

Several questions: 

Does keycloak support other auth mechanisms that don't build on http?

Does keycloak limit the reuse of hawkular components?

Does keycloak have a desirable out-of-the-box experience? (Read addtional setup costs)






> Am 04.02.2015 um 14:10 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> Le 30/01/2015 12:22, Thomas Heute a ?crit :
>>> When you install InfluxDB, carbon/whisper, opentsdb, you don't need to
>>> install an identity management server, period.
>> 
>> They are also not multi-tenant solutions AFAIK. I don't see Metrics
>> competing with the solution mentioned, actually we looked into those to
>> use as underlying solution.
>> 
> 
> To me, it doesn't matter if the team doesn't put all its efforts in 
> maintaining a standalone metrics distribution. But it does matter to 
> enable and help re-use outside of our principal use case (the hawkular 
> suite), because we'd miss important feedback/bug reports/contributions 
> from the community.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jshaughn at redhat.com  Wed Feb  4 09:24:08 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 04 Feb 2015 09:24:08 -0500
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D21F13.40209@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>	<297048310.6121018.1422987109766.JavaMail.zimbra@redhat.com>	<2129537193.5354619.1422987590955.JavaMail.zimbra@redhat.com>	<54D1312B.8080409@redhat.com>	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>	<54D1ECF6.7050203@redhat.com>
	<54D21563.7010308@redhat.com> <54D21F13.40209@redhat.com>
Message-ID: <54D22B88.5060401@redhat.com>


+1 to Thomas.  If a method has jdoc then it should be correct. If it 
doesn't then no problem.  I think at the class level it should always 
have some kind of jdoc. And no formatting of jdoc, which is a change I 
believe we already made to the formatter imports.

On 2/4/2015 8:30 AM, Thomas Segismont wrote:
> Le 04/02/2015 13:49, Peter Palaga a ?crit :
>> On 02/04/2015 10:57 AM, Thomas Segismont wrote:
>>> There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks
>>> provided we don't fail the build on missing Javadoc.
>> Not failing and just having the warnings in the build log is useless.
> There's a misunderstanding: I'm talking about not failing the build if a
> single method does not have Javadoc.
>
> If a method has Javadoc which does not represent reality (wrong list of
> parameters for example) then yes, the build should fail.
>
>> What is not enforced, will be ignored.
> That's not my opinion.
>
>> I am against introducing anything that can be ignored or overseen to checkstyle.
> See my first comment, I'm talking about not failing the build if a
> single method does not have Javadoc.
>
>>> It's not just
>>> getters/setters: sometimes your method has a meaningful name and it does
>>> not make any sense to write Javadoc for it.
>> I do not believe that something like this can be configured with
>> Checkstyle.
> Isn't that the purpose of "allowMissingJavadoc"?
>
>> However given that the general idea of adding JavaDoc checks has become
>> some level of support here, Gary or anybody else, feel free to submit a
>> PR to our checkstyle.xml [1] plus do not forget to test your proposal
>> with metrics, bus and alerts.
>>
>> [1]
>> https://github.com/hawkular/hawkular-build-tools/blob/master/src/main/resources/hawkular-checkstyle/checkstyle.xml
>>
>>
>> -- P
>>
>>> Le 04/02/2015 10:02, Gary Brown a ?crit :
>>>> Hi
>>>>
>>>> According to the docs
>>>> (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod)
>>>> the 'allowMissingPropertyJavadocs' parameter can be used to skip
>>>> checking of getters/setters.
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>> Hey,
>>>>>
>>>>> I am in favor of JavaDoc and having some checking - especially as in
>>>>> RHQ we
>>>>> have many places
>>>>> where the param list of a method and the one in JavaDoc have
>>>>> diverged over
>>>>> time.
>>>>>
>>>>> I am not in favor of forcing javadoc on every method (especially
>>>>> getter/setter), as this will just end up in
>>>>>
>>>>> /** This is the getter for foo */
>>>>> public foo getFoo() {}
>>>>>
>>>>> Which is imo worse than no doc.
>>>>>
>>>>> Unfortunately I think the default for JavaDoc is not to document
>>>>> private
>>>>> properties (=not include in the generated html),
>>>>> so that putting the comment on the property itself does not help for
>>>>> browsing
>>>>> docs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>> The main reason I mentioned it was because although I had been
>>>>>> diligent in
>>>>>> Overlord re javadoc, once the rule was enabled it picked up many
>>>>>> issues -
>>>>>> primarily inconsistency between parameter names, or missing parameter
>>>>>> entries.
>>>>>>
>>>>>> I agree meaningful text can only be picked up by review, but think
>>>>>> that
>>>>>> areas where automated checking is possible shouldn't be part of the
>>>>>> reviewers responsibility (i.e. to reduce their burden so they can
>>>>>> focus on
>>>>>> other areas).
>>>>>>
>>>>>> Regards
>>>>>> Gary
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>>> Not sure if this was previously discussed and decided
>>>>>>> Not that I knew. We decided to start from a very minimal set of rules
>>>>>>> that we initially copied from wildfly. We have not changed much:
>>>>>>> we just
>>>>>>> increased the line length to 120 chars and extended the plaintext
>>>>>>> checks
>>>>>>> to non-java files.
>>>>>>>
>>>>>>> I am personally undecided about JavaDoc checks. Having a meaningful
>>>>>>> JavaDoc is a good thing.
>>>>>>> Checkstyle can certainly help to some extent, but:
>>>>>>> (1) It is not enough as it will never check the meaningfulness
>>>>>>> (2) I tend to believe that some methods (incl. getters and
>>>>>>> setters) do
>>>>>>> not need JavaDoc
>>>>>>> (3) Non-public methods often should have JavaDoc too.
>>>>>>>
>>>>>>> I am a strong proponent of four eyes principle: no single commit
>>>>>>> can go
>>>>>>> to master without being reviewed properly. It should be reviewer's
>>>>>>> responsibility to check test coverage, JavaDoc, etc.
>>>>>>>
>>>>>>> Best wishes,
>>>>>>>
>>>>>>> -- Peter
>>>>>>>
>>>>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
>>>>>>>> It checks presence of javadoc, and matching entries for
>>>>>>>> parameters and
>>>>>>>> return values.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> Does this just look to see if all public methods have SOME javadoc?
>>>>>>>>> (i.e.
>>>>>>>>> it
>>>>>>>>> just sees if they are missing)
>>>>>>>>>
>>>>>>>>> Does it impose some type of formatting as well?
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Just started using the hawkular parent pom and noticed that the
>>>>>>>>>> checkstyle
>>>>>>>>>> config does not check the javadoc comments.
>>>>>>>>>>
>>>>>>>>>> Not sure if this was previously discussed and decided that it
>>>>>>>>>> shouldn't
>>>>>>>>>> be
>>>>>>>>>> checked, but thought I had better check, as this is one area
>>>>>>>>>> that can
>>>>>>>>>> be
>>>>>>>>>> time consuming to update code after enabling.
>>>>>>>>>>
>>>>>>>>>> Previously I had been using this config in Overlord:
>>>>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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  Wed Feb  4 09:28:30 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 04 Feb 2015 15:28:30 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>
References: <54C28AE2.3010509@redhat.com>
	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>
	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>
	<54CA5AFD.5010102@redhat.com>	<54CB55CF.3040207@redhat.com>
	<54CB6964.10905@redhat.com>	<54D21A28.2030405@redhat.com>
	<D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>
Message-ID: <54D22C8E.30601@redhat.com>

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

On 02/04/2015 03:23 PM, Heiko Braun wrote:
> Does keycloak support other auth mechanisms that don't build on
> http?

No. Keycloak is a "super OAuth" solution, and that's on top of HTTP.
What kind of other authentication mechanisms are you thinking about?

> Does keycloak limit the reuse of hawkular components?

Not that I'm aware of. All it does is to put a layer between the
incoming request and the business method on the backend, like JAAS.

> Does keycloak have a desirable out-of-the-box experience? (Read
> addtional setup costs)

Depends on the definition of "desirable". Right now, the common
practice for projects consuming Keycloak seems to build an "appliance"
distribution, which builds on top of Wildfly and delivers Keycloak
pre-installed/configured + the target application (hawkular, in our
case).

- - Juca.

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

iQEcBAEBAgAGBQJU0iyOAAoJECKM1e+fkPrXj+AH/2hF7EBlQ2n7VVSbkjGLODgo
C33cMgBpsonGUFZcd8LXAOdl2ZpklpRzjdcOpVB6OJUasV5Ek/pONyTn8LMStJzV
nJrHTBKtR71+V9+A2g/cSbv4x7vynhNqSAHEq3a+OwEhzZ8DT+sQnxFRr+QdMMWh
e+QiVUBCgx/4IBL1gsw40OBy/I1d7NULwS7fzMvunnacHYEibZc4ACgQwy/LPCih
xbAmYn8SP5IgLT+TqLSnNUMJps44phkdYsSkku3wotH9YkOI55PNlYU9iTbYa9kr
SCe1aIeIeA5hooCVJ92FMeRF5Pyf9OOgn1flKdurC0nvdWBe3mIlza32KOWLY9U=
=ZYJJ
-----END PGP SIGNATURE-----

From snegrea at redhat.com  Wed Feb  4 10:26:16 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 4 Feb 2015 10:26:16 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <54D22B88.5060401@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<324028695.5658070.1423038892193.JavaMail.zimbra@redhat.com>
	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
	<54D1ECF6.7050203@redhat.com> <54D21563.7010308@redhat.com>
	<54D21F13.40209@redhat.com> <54D22B88.5060401@redhat.com>
Message-ID: <183356984.5230485.1423063576697.JavaMail.zimbra@redhat.com>


This morning, I noticed a lot of activity on this mailing list and got really excited; only to be flabbergasted that the vast majority is about checkstyle. I would rather have a very popular project than a project with pristine code by whatever standards but absolutely no users. With the time put so far into this, we are getting dangerously close to the "bike-shed effect", not to mentioned that any overly bureaucratic process has the side effect of slowing down real progress ...

Thank you,
Stefan 

----- Original Message -----
> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, February 4, 2015 8:24:08 AM
> Subject: Re: [Hawkular-dev] Checkstyle javadoc settings
> 
> 
> +1 to Thomas.  If a method has jdoc then it should be correct. If it
> doesn't then no problem.  I think at the class level it should always
> have some kind of jdoc. And no formatting of jdoc, which is a change I
> believe we already made to the formatter imports.
> 
> On 2/4/2015 8:30 AM, Thomas Segismont wrote:
> > Le 04/02/2015 13:49, Peter Palaga a ?crit :
> >> On 02/04/2015 10:57 AM, Thomas Segismont wrote:
> >>> There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks
> >>> provided we don't fail the build on missing Javadoc.
> >> Not failing and just having the warnings in the build log is useless.
> > There's a misunderstanding: I'm talking about not failing the build if a
> > single method does not have Javadoc.
> >
> > If a method has Javadoc which does not represent reality (wrong list of
> > parameters for example) then yes, the build should fail.
> >
> >> What is not enforced, will be ignored.
> > That's not my opinion.
> >
> >> I am against introducing anything that can be ignored or overseen to
> >> checkstyle.
> > See my first comment, I'm talking about not failing the build if a
> > single method does not have Javadoc.
> >
> >>> It's not just
> >>> getters/setters: sometimes your method has a meaningful name and it does
> >>> not make any sense to write Javadoc for it.
> >> I do not believe that something like this can be configured with
> >> Checkstyle.
> > Isn't that the purpose of "allowMissingJavadoc"?
> >
> >> However given that the general idea of adding JavaDoc checks has become
> >> some level of support here, Gary or anybody else, feel free to submit a
> >> PR to our checkstyle.xml [1] plus do not forget to test your proposal
> >> with metrics, bus and alerts.
> >>
> >> [1]
> >> https://github.com/hawkular/hawkular-build-tools/blob/master/src/main/resources/hawkular-checkstyle/checkstyle.xml
> >>
> >>
> >> -- P
> >>
> >>> Le 04/02/2015 10:02, Gary Brown a ?crit :
> >>>> Hi
> >>>>
> >>>> According to the docs
> >>>> (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod)
> >>>> the 'allowMissingPropertyJavadocs' parameter can be used to skip
> >>>> checking of getters/setters.
> >>>>
> >>>> Regards
> >>>> Gary
> >>>>
> >>>> ----- Original Message -----
> >>>>> Hey,
> >>>>>
> >>>>> I am in favor of JavaDoc and having some checking - especially as in
> >>>>> RHQ we
> >>>>> have many places
> >>>>> where the param list of a method and the one in JavaDoc have
> >>>>> diverged over
> >>>>> time.
> >>>>>
> >>>>> I am not in favor of forcing javadoc on every method (especially
> >>>>> getter/setter), as this will just end up in
> >>>>>
> >>>>> /** This is the getter for foo */
> >>>>> public foo getFoo() {}
> >>>>>
> >>>>> Which is imo worse than no doc.
> >>>>>
> >>>>> Unfortunately I think the default for JavaDoc is not to document
> >>>>> private
> >>>>> properties (=not include in the generated html),
> >>>>> so that putting the comment on the property itself does not help for
> >>>>> browsing
> >>>>> docs.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
> >>>>>>
> >>>>>> Hi Peter
> >>>>>>
> >>>>>> The main reason I mentioned it was because although I had been
> >>>>>> diligent in
> >>>>>> Overlord re javadoc, once the rule was enabled it picked up many
> >>>>>> issues -
> >>>>>> primarily inconsistency between parameter names, or missing parameter
> >>>>>> entries.
> >>>>>>
> >>>>>> I agree meaningful text can only be picked up by review, but think
> >>>>>> that
> >>>>>> areas where automated checking is possible shouldn't be part of the
> >>>>>> reviewers responsibility (i.e. to reduce their burden so they can
> >>>>>> focus on
> >>>>>> other areas).
> >>>>>>
> >>>>>> Regards
> >>>>>> Gary
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>>> Not sure if this was previously discussed and decided
> >>>>>>> Not that I knew. We decided to start from a very minimal set of rules
> >>>>>>> that we initially copied from wildfly. We have not changed much:
> >>>>>>> we just
> >>>>>>> increased the line length to 120 chars and extended the plaintext
> >>>>>>> checks
> >>>>>>> to non-java files.
> >>>>>>>
> >>>>>>> I am personally undecided about JavaDoc checks. Having a meaningful
> >>>>>>> JavaDoc is a good thing.
> >>>>>>> Checkstyle can certainly help to some extent, but:
> >>>>>>> (1) It is not enough as it will never check the meaningfulness
> >>>>>>> (2) I tend to believe that some methods (incl. getters and
> >>>>>>> setters) do
> >>>>>>> not need JavaDoc
> >>>>>>> (3) Non-public methods often should have JavaDoc too.
> >>>>>>>
> >>>>>>> I am a strong proponent of four eyes principle: no single commit
> >>>>>>> can go
> >>>>>>> to master without being reviewed properly. It should be reviewer's
> >>>>>>> responsibility to check test coverage, JavaDoc, etc.
> >>>>>>>
> >>>>>>> Best wishes,
> >>>>>>>
> >>>>>>> -- Peter
> >>>>>>>
> >>>>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
> >>>>>>>> It checks presence of javadoc, and matching entries for
> >>>>>>>> parameters and
> >>>>>>>> return values.
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> Does this just look to see if all public methods have SOME javadoc?
> >>>>>>>>> (i.e.
> >>>>>>>>> it
> >>>>>>>>> just sees if they are missing)
> >>>>>>>>>
> >>>>>>>>> Does it impose some type of formatting as well?
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> Hi
> >>>>>>>>>>
> >>>>>>>>>> Just started using the hawkular parent pom and noticed that the
> >>>>>>>>>> checkstyle
> >>>>>>>>>> config does not check the javadoc comments.
> >>>>>>>>>>
> >>>>>>>>>> Not sure if this was previously discussed and decided that it
> >>>>>>>>>> shouldn't
> >>>>>>>>>> be
> >>>>>>>>>> checked, but thought I had better check, as this is one area
> >>>>>>>>>> that can
> >>>>>>>>>> be
> >>>>>>>>>> time consuming to update code after enabling.
> >>>>>>>>>>
> >>>>>>>>>> Previously I had been using this config in Overlord:
> >>>>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> hawkular-dev mailing list
> >>>>> hawkular-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>>>
> >>>> _______________________________________________
> >>>> hawkular-dev mailing list
> >>>> hawkular-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>>
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From gbrown at redhat.com  Wed Feb  4 10:29:28 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 4 Feb 2015 10:29:28 -0500 (EST)
Subject: [Hawkular-dev] Checkstyle javadoc settings
In-Reply-To: <183356984.5230485.1423063576697.JavaMail.zimbra@redhat.com>
References: <1401310628.5283822.1422982836462.JavaMail.zimbra@redhat.com>
	<3529AAE2-D719-48E8-A62E-EE9299362ADE@redhat.com>
	<748976527.5673385.1423040522132.JavaMail.zimbra@redhat.com>
	<54D1ECF6.7050203@redhat.com> <54D21563.7010308@redhat.com>
	<54D21F13.40209@redhat.com> <54D22B88.5060401@redhat.com>
	<183356984.5230485.1423063576697.JavaMail.zimbra@redhat.com>
Message-ID: <735952333.6040194.1423063768165.JavaMail.zimbra@redhat.com>

Hi Stefan

I don't disagree with your point - the only reason I raised it was that it is one of those rules, that if not sorted out upfront, can be very expensive to fix up later on.

Regards
Gary

----- Original Message -----
> 
> This morning, I noticed a lot of activity on this mailing list and got really
> excited; only to be flabbergasted that the vast majority is about
> checkstyle. I would rather have a very popular project than a project with
> pristine code by whatever standards but absolutely no users. With the time
> put so far into this, we are getting dangerously close to the "bike-shed
> effect", not to mentioned that any overly bureaucratic process has the side
> effect of slowing down real progress ...
> 
> Thank you,
> Stefan
> 
> ----- Original Message -----
> > From: "Jay Shaughnessy" <jshaughn at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Wednesday, February 4, 2015 8:24:08 AM
> > Subject: Re: [Hawkular-dev] Checkstyle javadoc settings
> > 
> > 
> > +1 to Thomas.  If a method has jdoc then it should be correct. If it
> > doesn't then no problem.  I think at the class level it should always
> > have some kind of jdoc. And no formatting of jdoc, which is a change I
> > believe we already made to the formatter imports.
> > 
> > On 2/4/2015 8:30 AM, Thomas Segismont wrote:
> > > Le 04/02/2015 13:49, Peter Palaga a ?crit :
> > >> On 02/04/2015 10:57 AM, Thomas Segismont wrote:
> > >>> There's also "allowMissingJavadoc". I'm +1 for adding Javadoc checks
> > >>> provided we don't fail the build on missing Javadoc.
> > >> Not failing and just having the warnings in the build log is useless.
> > > There's a misunderstanding: I'm talking about not failing the build if a
> > > single method does not have Javadoc.
> > >
> > > If a method has Javadoc which does not represent reality (wrong list of
> > > parameters for example) then yes, the build should fail.
> > >
> > >> What is not enforced, will be ignored.
> > > That's not my opinion.
> > >
> > >> I am against introducing anything that can be ignored or overseen to
> > >> checkstyle.
> > > See my first comment, I'm talking about not failing the build if a
> > > single method does not have Javadoc.
> > >
> > >>> It's not just
> > >>> getters/setters: sometimes your method has a meaningful name and it
> > >>> does
> > >>> not make any sense to write Javadoc for it.
> > >> I do not believe that something like this can be configured with
> > >> Checkstyle.
> > > Isn't that the purpose of "allowMissingJavadoc"?
> > >
> > >> However given that the general idea of adding JavaDoc checks has become
> > >> some level of support here, Gary or anybody else, feel free to submit a
> > >> PR to our checkstyle.xml [1] plus do not forget to test your proposal
> > >> with metrics, bus and alerts.
> > >>
> > >> [1]
> > >> https://github.com/hawkular/hawkular-build-tools/blob/master/src/main/resources/hawkular-checkstyle/checkstyle.xml
> > >>
> > >>
> > >> -- P
> > >>
> > >>> Le 04/02/2015 10:02, Gary Brown a ?crit :
> > >>>> Hi
> > >>>>
> > >>>> According to the docs
> > >>>> (http://checkstyle.sourceforge.net/config_javadoc.html#JavadocMethod)
> > >>>> the 'allowMissingPropertyJavadocs' parameter can be used to skip
> > >>>> checking of getters/setters.
> > >>>>
> > >>>> Regards
> > >>>> Gary
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> Hey,
> > >>>>>
> > >>>>> I am in favor of JavaDoc and having some checking - especially as in
> > >>>>> RHQ we
> > >>>>> have many places
> > >>>>> where the param list of a method and the one in JavaDoc have
> > >>>>> diverged over
> > >>>>> time.
> > >>>>>
> > >>>>> I am not in favor of forcing javadoc on every method (especially
> > >>>>> getter/setter), as this will just end up in
> > >>>>>
> > >>>>> /** This is the getter for foo */
> > >>>>> public foo getFoo() {}
> > >>>>>
> > >>>>> Which is imo worse than no doc.
> > >>>>>
> > >>>>> Unfortunately I think the default for JavaDoc is not to document
> > >>>>> private
> > >>>>> properties (=not include in the generated html),
> > >>>>> so that putting the comment on the property itself does not help for
> > >>>>> browsing
> > >>>>> docs.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Am 04.02.2015 um 09:34 schrieb Gary Brown <gbrown at redhat.com>:
> > >>>>>>
> > >>>>>> Hi Peter
> > >>>>>>
> > >>>>>> The main reason I mentioned it was because although I had been
> > >>>>>> diligent in
> > >>>>>> Overlord re javadoc, once the rule was enabled it picked up many
> > >>>>>> issues -
> > >>>>>> primarily inconsistency between parameter names, or missing
> > >>>>>> parameter
> > >>>>>> entries.
> > >>>>>>
> > >>>>>> I agree meaningful text can only be picked up by review, but think
> > >>>>>> that
> > >>>>>> areas where automated checking is possible shouldn't be part of the
> > >>>>>> reviewers responsibility (i.e. to reduce their burden so they can
> > >>>>>> focus on
> > >>>>>> other areas).
> > >>>>>>
> > >>>>>> Regards
> > >>>>>> Gary
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>>> Not sure if this was previously discussed and decided
> > >>>>>>> Not that I knew. We decided to start from a very minimal set of
> > >>>>>>> rules
> > >>>>>>> that we initially copied from wildfly. We have not changed much:
> > >>>>>>> we just
> > >>>>>>> increased the line length to 120 chars and extended the plaintext
> > >>>>>>> checks
> > >>>>>>> to non-java files.
> > >>>>>>>
> > >>>>>>> I am personally undecided about JavaDoc checks. Having a meaningful
> > >>>>>>> JavaDoc is a good thing.
> > >>>>>>> Checkstyle can certainly help to some extent, but:
> > >>>>>>> (1) It is not enough as it will never check the meaningfulness
> > >>>>>>> (2) I tend to believe that some methods (incl. getters and
> > >>>>>>> setters) do
> > >>>>>>> not need JavaDoc
> > >>>>>>> (3) Non-public methods often should have JavaDoc too.
> > >>>>>>>
> > >>>>>>> I am a strong proponent of four eyes principle: no single commit
> > >>>>>>> can go
> > >>>>>>> to master without being reviewed properly. It should be reviewer's
> > >>>>>>> responsibility to check test coverage, JavaDoc, etc.
> > >>>>>>>
> > >>>>>>> Best wishes,
> > >>>>>>>
> > >>>>>>> -- Peter
> > >>>>>>>
> > >>>>>>> On 02/03/2015 07:19 PM, Gary Brown wrote:
> > >>>>>>>> It checks presence of javadoc, and matching entries for
> > >>>>>>>> parameters and
> > >>>>>>>> return values.
> > >>>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> Does this just look to see if all public methods have SOME
> > >>>>>>>>> javadoc?
> > >>>>>>>>> (i.e.
> > >>>>>>>>> it
> > >>>>>>>>> just sees if they are missing)
> > >>>>>>>>>
> > >>>>>>>>> Does it impose some type of formatting as well?
> > >>>>>>>>>
> > >>>>>>>>> ----- Original Message -----
> > >>>>>>>>>> Hi
> > >>>>>>>>>>
> > >>>>>>>>>> Just started using the hawkular parent pom and noticed that the
> > >>>>>>>>>> checkstyle
> > >>>>>>>>>> config does not check the javadoc comments.
> > >>>>>>>>>>
> > >>>>>>>>>> Not sure if this was previously discussed and decided that it
> > >>>>>>>>>> shouldn't
> > >>>>>>>>>> be
> > >>>>>>>>>> checked, but thought I had better check, as this is one area
> > >>>>>>>>>> that can
> > >>>>>>>>>> be
> > >>>>>>>>>> time consuming to update code after enabling.
> > >>>>>>>>>>
> > >>>>>>>>>> Previously I had been using this config in Overlord:
> > >>>>>>>>>> https://github.com/Governance/overlord-commons/blob/master/overlord-commons-build/src/main/resources/checkstyle/checkstyle.xml#L83-L97
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>
> > >>>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> hawkular-dev mailing list
> > >>>>> hawkular-dev at lists.jboss.org
> > >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >>>>>
> > >>>> _______________________________________________
> > >>>> hawkular-dev mailing list
> > >>>> hawkular-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >>>>
> > >>> _______________________________________________
> > >>> hawkular-dev mailing list
> > >>> hawkular-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >>>
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing 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 jshaughn at redhat.com  Wed Feb  4 10:38:20 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 04 Feb 2015 10:38:20 -0500
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
References: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
Message-ID: <54D23CEC.1060603@redhat.com>


This is maybe good and bad for us.  It means that depending on a graph 
DB may be well supported in the future DSE Graph offering, but for now 
it would seem that Titan will not get much TLC past this point. So if we 
go with Titan we may need to be happy with what we see today.


On 2/3/2015 9:58 AM, Stefan Negrea wrote:
> Hello Everybody,
>
> Aurelius (the company behind Titan graph database) has been acquired by DataStax (the main Cassandra developer company).
>
> Here are two articles around the web about the acquisition and strategic direction:
>
> http://techcrunch.com/2015/02/03/datastax-plots-aurelius-graph-database-acquihire/
> http://www.zdnet.com/article/datastax-snaps-up-aurelius-and-its-titan-team-to-build-new-graph-database/
>
>
>
> Thank you,
> Stefan Negrea
>
> Software Engineer
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From hrupp at redhat.com  Wed Feb  4 11:00:26 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 4 Feb 2015 17:00:26 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <54CA6C3C.9080808@redhat.com>
References: <54CA6C3C.9080808@redhat.com>
Message-ID: <CCE59838-49B1-49D1-9DAD-78F1B82ED4DD@redhat.com>

Hi,

> One possible solution is to have "users" and "organizations", a la
> Github. Users can be part of zero or more organizations and
> organizations have one or more members. Data (git repos or resources)
> belongs to either an user or an organization.

I think I like this idea.

> 
> - -> http://user:password at hawkular/resource/{resourceId}/metrics
>   all metrics for this specific resource, if the resource belongs to
> the user or to an organization where the user is a member of

How would we model the user / org stuff? Well, that could probably
just become a part of inventory

Question is though: if a user has his own pet server and works as
part of an org. Do we want to prevent "leaking" org data to the private
project? Or is that purely up to the user?


> For this scenario, I think the UI could be built with a "context
> switcher". This way, the user would have access to a dashboard with
> resources from his main account and could switch to a dashboard with
> resources from an organization. The backend, though, would not have
> such a notion of "context". Either the user has access to the resource
> or not (via the main account or via an organization).

Wouldn't the backend still need to know the context - and if only for
performance reason when the user wants to only see his personal resources?

> 
> The main disadvantage of this is that we have to also care about the
> authorization, as we cannot rely on permission data coming from Keycloak.


Well, I guess a good deal of authorization needs to be done in some custom
code anyway and would not be covered by stock-JAAS, so it may not be that bad.

  Heiko



From lkrejci at redhat.com  Wed Feb  4 11:39:43 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 04 Feb 2015 17:39:43 +0100
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <54D23CEC.1060603@redhat.com>
References: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
	<54D23CEC.1060603@redhat.com>
Message-ID: <8680602.h9C1rabEam@localhost.localdomain>

Reading this

http://thinkaurelius.com/2015/02/03/aurelius-acquired-by-datastax/

I think this is more on the side of bad.

If I read the following correctly:

"
The Aurelius team, at DataStax, has two primary missions: 1.) provide a Titan-
inspired graph product to their DSE product offering and 2.) continue to work 
with the Apache TinkerPop community to ensure an open source, graph standard 
for everyone.
"

They will work on a commercial graph DB and contribute to TinkerPop which is 
NOT a graph db in itself - its a JDBC-like API for graph dbs + a set of tools 
on top of that API.

Crap. And I was so looking forward to using it... :(


On Wednesday, February 04, 2015 10:38:20 Jay Shaughnessy wrote:
> This is maybe good and bad for us.  It means that depending on a graph
> DB may be well supported in the future DSE Graph offering, but for now
> it would seem that Titan will not get much TLC past this point. So if we
> go with Titan we may need to be happy with what we see today.
> 
> On 2/3/2015 9:58 AM, Stefan Negrea wrote:
> > Hello Everybody,
> > 
> > Aurelius (the company behind Titan graph database) has been acquired by
> > DataStax (the main Cassandra developer company).
> > 
> > Here are two articles around the web about the acquisition and strategic
> > direction:
> > 
> > http://techcrunch.com/2015/02/03/datastax-plots-aurelius-graph-database-ac
> > quihire/
> > http://www.zdnet.com/article/datastax-snaps-up-aurelius-and-its-titan-tea
> > m-to-build-new-graph-database/
> > 
> > 
> > 
> > Thank you,
> > Stefan Negrea
> > 
> > Software Engineer
> > 
> > _______________________________________________
> > 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  Wed Feb  4 11:56:25 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 04 Feb 2015 17:56:25 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <CCE59838-49B1-49D1-9DAD-78F1B82ED4DD@redhat.com>
References: <54CA6C3C.9080808@redhat.com>
	<CCE59838-49B1-49D1-9DAD-78F1B82ED4DD@redhat.com>
Message-ID: <54D24F39.2030305@redhat.com>

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

On 02/04/2015 05:00 PM, Heiko W.Rupp wrote:
> How would we model the user / org stuff? Well, that could probably 
> just become a part of inventory

I'd say that this mapping should be part of a new module, with an API
being provided to other modules.

The model would be something like this:
* Metric belongs to Owner.
* Organization belongs to Owner.
* Owner is an interface, implemented by User and Organization.
* User can be the owner of one or more organizations.

This way, organizations can be owned by other organizations. Not sure
if this will work, though. I'm starting to work on this right now on a
new module (hawkular-accounts).

> Question is though: if a user has his own pet server and works as 
> part of an org. Do we want to prevent "leaking" org data to the
> private project? Or is that purely up to the user?

If an user makes a REST call to retrieve all metrics that he has
access to, I'd expect that he'd receive both metrics for his pet
projects and metrics for organizations he's part of.

> Wouldn't the backend still need to know the context - and if only
> for performance reason when the user wants to only see his personal
> resources?

The backend *needs* to check if the current user has access to the
resource. Other than that, I'd say it's up to the individual
components (alerts, metrics, inventory, ...) what/how they want to
expose data to the consumers. For instance, metrics might want to have
the following REST endpoints:

/{owner}/metrics
  --> all metrics owned by "owner" (organization or user)

/metrics
  --> all metrics to which the current user has access to

/metric/{metricId}
  --> a specific metric, as long as the user has access to it

So, on the metrics backend and UI, they might decide to always require
an owner (like, with a context switcher on the UI), or to provide both
endpoints.

> Well, I guess a good deal of authorization needs to be done in some
> custom code anyway and would not be covered by stock-JAAS, so it
> may not be that bad.

Indeed. The more I think about this problem, the more I'm convinced
that we should be handling the authorization ourselves.

- - Juca.

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

iQEcBAEBAgAGBQJU0k85AAoJECKM1e+fkPrXMUEH/jRCxeAuERAP761WZQmPlUvH
GItzQRMPBW+M+CHEdzYJGErCARrJeWPSOjtMp/xKz+W8Iw7SBMH/KDlfDDILooFk
JEXKSdITJIGHNSE+SQ9A+33LfVYUM2CfS4oeWgOmOOmemKP1HTO7z479qljXUPDN
NLn0pSSynZhONMH3l5M1IEuCthCFHqrPzzWBpmhrmL8+rhBkrm5tQU4IjfFGERcP
VmFiFut7tJreq2Yr3kqPoidJiHs37ZFlQzfZmbwcdDjBtO+m/uz9g3pp49JhHAKY
eAAdb4mhNBu8hrYLm1fx0jwBzyG6R7nNQUO9O+aTi7ODd38BR4HJE76H6TjBQqE=
=oTDA
-----END PGP SIGNATURE-----

From jkremser at redhat.com  Wed Feb  4 12:46:37 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Wed, 4 Feb 2015 12:46:37 -0500 (EST)
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <8680602.h9C1rabEam@localhost.localdomain>
References: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
	<54D23CEC.1060603@redhat.com>
	<8680602.h9C1rabEam@localhost.localdomain>
Message-ID: <1198627348.4771976.1423071997597.JavaMail.zimbra@redhat.com>

Hi, 
  In my opinion we can still use the Blueprints API, because there are numerous implementations out there

https://github.com/tinkerpop/blueprints/wiki

including neo4j (gpl), Mongo, OrientDB and possibly jdbc as a fallback (or even start for mvp). If we pick something Blueprints compliant, we get the bunch of graph algorithms for free:

https://github.com/tinkerpop/furnace/wiki

To be clear, titan will be still open-source, but without core developers, I guess, they will give it to the apache incubator.


more info about the situation here:
https://groups.google.com/forum/#!topic/aureliusgraphs/WtU6om8CtqI
and here: https://groups.google.com/forum/#!topic/aureliusgraphs/c07WEdH-epY

jk

From snegrea at redhat.com  Wed Feb  4 13:15:26 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 4 Feb 2015 13:15:26 -0500 (EST)
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <54D23CEC.1060603@redhat.com>
References: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
	<54D23CEC.1060603@redhat.com>
Message-ID: <558035839.5299175.1423073725996.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, February 4, 2015 9:38:20 AM
> Subject: Re: [Hawkular-dev] Cassandra & Titan
> 
> 
> This is maybe good and bad for us.  It means that depending on a graph
> DB may be well supported in the future DSE Graph offering, but for now
> it would seem that Titan will not get much TLC past this point. So if we
> go with Titan we may need to be happy with what we see today.

The Metrics project will to move to Cassandra 3 as soon as possible (fuzzy timeline but on it's on the horizon). Titan currently advertises support for Cassandra 2.0.8, which is older than 2.1.x used by Metrics. So from the perspective of being happy with what is there, Titan is already considerably behind. This acquisition really puts a dent on Titan ....


> 
> 
> On 2/3/2015 9:58 AM, Stefan Negrea wrote:
> > Hello Everybody,
> >
> > Aurelius (the company behind Titan graph database) has been acquired by
> > DataStax (the main Cassandra developer company).
> >
> > Here are two articles around the web about the acquisition and strategic
> > direction:
> >
> > http://techcrunch.com/2015/02/03/datastax-plots-aurelius-graph-database-acquihire/
> > http://www.zdnet.com/article/datastax-snaps-up-aurelius-and-its-titan-team-to-build-new-graph-database/
> >
> >
> >
> > Thank you,
> > Stefan Negrea
> >
> > Software Engineer
> >
> > _______________________________________________
> > 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 Feb  4 13:53:39 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 4 Feb 2015 13:53:39 -0500 (EST)
Subject: [Hawkular-dev] logging bug
In-Reply-To: <113358450.6829600.1423073467646.JavaMail.zimbra@redhat.com>
Message-ID: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>

Well, that didn't take long. As predicted by John "Trelawney" Sanda, in only took a few days after integrating with jboss logging that we've hit a pretty nasty javac bug.

Peter and I have investigated a little and found the following that look related:

https://jira.codehaus.org/browse/MCOMPILER-236

https://bugs.openjdk.java.net/browse/JDK-8067747

There are several workarounds that we've discovered:

1) Always do a mvn clean before building. If you "mvn clean install" things work. If you later to "mvn install" you will fail to build. This is "less than optimal" because it requires everyone to always clean before building thus forcing the entire project code to be recompiled each and every time.

2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus modules build successfully with this, Peter says this causes other things to fail to build (IIRC, alerts was one of them).

3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true."

I have found either of those three work around the issue.  I think #3 is probably the best, unless someone knows for sure that we need that setting to be true.

FWIW: You can read about the bsc plugin options here: http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-plugin/site3/process-mojo.html - perhaps there are other settings we can set to workaround the issue?

From jsanda at redhat.com  Wed Feb  4 15:08:09 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 04 Feb 2015 20:08:09 -0000
Subject: [Hawkular-dev] logging bug
In-Reply-To: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
References: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
Message-ID: <48542C88-9477-4221-8E09-D3498EE350B5@redhat.com>

At the risk of sounding like I have come unhinged, what about a fourth option? Use a simpler, yet performant solution like slf4j or logback.

> On Feb 4, 2015, at 1:53 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> Well, that didn't take long. As predicted by John "Trelawney" Sanda, in only took a few days after integrating with jboss logging that we've hit a pretty nasty javac bug.
> 
> Peter and I have investigated a little and found the following that look related:
> 
> https://jira.codehaus.org/browse/MCOMPILER-236
> 
> https://bugs.openjdk.java.net/browse/JDK-8067747
> 
> There are several workarounds that we've discovered:
> 
> 1) Always do a mvn clean before building. If you "mvn clean install" things work. If you later to "mvn install" you will fail to build. This is "less than optimal" because it requires everyone to always clean before building thus forcing the entire project code to be recompiled each and every time.
> 
> 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus modules build successfully with this, Peter says this causes other things to fail to build (IIRC, alerts was one of them).
> 
> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true."
> 
> I have found either of those three work around the issue.  I think #3 is probably the best, unless someone knows for sure that we need that setting to be true.
> 
> FWIW: You can read about the bsc plugin options here: http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-plugin/site3/process-mojo.html - perhaps there are other settings we can set to workaround the issue?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jsanda at redhat.com  Wed Feb  4 15:30:42 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 04 Feb 2015 20:30:42 -0000
Subject: [Hawkular-dev] logging bug
In-Reply-To: <EE7E5D1A-D093-4F8D-8009-0B891109E86B@redhat.com>
References: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
	<48542C88-9477-4221-8E09-D3498EE350B5@redhat.com>
	<EE7E5D1A-D093-4F8D-8009-0B891109E86B@redhat.com>
Message-ID: <3296ADD2-E888-468C-892E-06F5B0325C9D@redhat.com>

Let me see if I understand. We could for the interim switch to a different logging framework like slf4j or logback that is widely used, mature, performant, etc in large part to avoid these problems mazz and others have hit. At some point in the future though, we once again revert back. Why?

> On Feb 4, 2015, at 3:20 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Perhaps interim. But not for medium or long term.
> 
>> Am 22.02.2015 um 20:08 schrieb John Sanda <jsanda at redhat.com>:
>> 
>> At the risk of sounding like I have come unhinged, what about a fourth option? Use a simpler, yet performant solution like slf4j or logback.
>> 
>>> On Feb 4, 2015, at 1:53 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>> 
>>> Well, that didn't take long. As predicted by John "Trelawney" Sanda, in only took a few days after integrating with jboss logging that we've hit a pretty nasty javac bug.
>>> 
>>> Peter and I have investigated a little and found the following that look related:
>>> 
>>> https://jira.codehaus.org/browse/MCOMPILER-236
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8067747
>>> 
>>> There are several workarounds that we've discovered:
>>> 
>>> 1) Always do a mvn clean before building. If you "mvn clean install" things work. If you later to "mvn install" you will fail to build. This is "less than optimal" because it requires everyone to always clean before building thus forcing the entire project code to be recompiled each and every time.
>>> 
>>> 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus modules build successfully with this, Peter says this causes other things to fail to build (IIRC, alerts was one of them).
>>> 
>>> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true."
>>> 
>>> I have found either of those three work around the issue.  I think #3 is probably the best, unless someone knows for sure that we need that setting to be true.
>>> 
>>> FWIW: You can read about the bsc plugin options here: http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-plugin/site3/process-mojo.html - perhaps there are other settings we can set to workaround the issue?
>>> _______________________________________________
>>> 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
> 
> -- 
> 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 mazz at redhat.com  Wed Feb  4 15:54:16 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 4 Feb 2015 15:54:16 -0500 (EST)
Subject: [Hawkular-dev] logging bug
In-Reply-To: <3296ADD2-E888-468C-892E-06F5B0325C9D@redhat.com>
References: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
	<48542C88-9477-4221-8E09-D3498EE350B5@redhat.com>
	<EE7E5D1A-D093-4F8D-8009-0B891109E86B@redhat.com>
	<3296ADD2-E888-468C-892E-06F5B0325C9D@redhat.com>
Message-ID: <1972325682.6898560.1423083256766.JavaMail.zimbra@redhat.com>

1) do these other logging frameworks provide a message ID feature and the I18N-resource-bundle-generation feature? because if not, I don't think it will fly - those are going to be requirements I believe.

2) I think it is quite possible we are processing the annotations wrong. The Wfly folks don't even use this bsc plugin that seems to be the cause of the problem. I'm going to see what I did that caused this bug to appear, its possible this will "just go away"



----- Original Message -----
> Let me see if I understand. We could for the interim switch to a different
> logging framework like slf4j or logback that is widely used, mature,
> performant, etc in large part to avoid these problems mazz and others have
> hit. At some point in the future though, we once again revert back. Why?
> 
> > On Feb 4, 2015, at 3:20 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> > 
> > Perhaps interim. But not for medium or long term.
> > 
> >> Am 22.02.2015 um 20:08 schrieb John Sanda <jsanda at redhat.com>:
> >> 
> >> At the risk of sounding like I have come unhinged, what about a fourth
> >> option? Use a simpler, yet performant solution like slf4j or logback.
> >> 
> >>> On Feb 4, 2015, at 1:53 PM, John Mazzitelli <mazz at redhat.com> wrote:
> >>> 
> >>> Well, that didn't take long. As predicted by John "Trelawney" Sanda, in
> >>> only took a few days after integrating with jboss logging that we've hit
> >>> a pretty nasty javac bug.
> >>> 
> >>> Peter and I have investigated a little and found the following that look
> >>> related:
> >>> 
> >>> https://jira.codehaus.org/browse/MCOMPILER-236
> >>> 
> >>> https://bugs.openjdk.java.net/browse/JDK-8067747
> >>> 
> >>> There are several workarounds that we've discovered:
> >>> 
> >>> 1) Always do a mvn clean before building. If you "mvn clean install"
> >>> things work. If you later to "mvn install" you will fail to build. This
> >>> is "less than optimal" because it requires everyone to always clean
> >>> before building thus forcing the entire project code to be recompiled
> >>> each and every time.
> >>> 
> >>> 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus
> >>> modules build successfully with this, Peter says this causes other
> >>> things to fail to build (IIRC, alerts was one of them).
> >>> 
> >>> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to
> >>> false (which is the default if not specified, but it is specified today
> >>> and set to "true" in parent-pom). I am not sure exactly what
> >>> addCompileSourceRoots does, but I think it adds generated source to the
> >>> list of source directories that get processed by the annotation
> >>> processor. I doubt (though I don't know for sure) that our other
> >>> generated code (like antlr) actually use the jboss logging annotations,
> >>> so I therefore doubt we actually need this setting to be "true."
> >>> 
> >>> I have found either of those three work around the issue.  I think #3 is
> >>> probably the best, unless someone knows for sure that we need that
> >>> setting to be true.
> >>> 
> >>> FWIW: You can read about the bsc plugin options here:
> >>> http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-plugin/site3/process-mojo.html
> >>> - perhaps there are other settings we can set to workaround the issue?
> >>> _______________________________________________
> >>> 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
> > 
> > --
> > 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
> > 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From tsegismo at redhat.com  Wed Feb  4 16:00:37 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 04 Feb 2015 22:00:37 +0100
Subject: [Hawkular-dev] logging bug
In-Reply-To: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
References: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
Message-ID: <54D28875.3000207@redhat.com>

Le 04/02/2015 19:53, John Mazzitelli a ?crit :
> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to false (which is the default if not specified, but it is specified today and set to "true" in parent-pom). I am not sure exactly what addCompileSourceRoots does, but I think it adds generated source to the list of source directories that get processed by the annotation processor. I doubt (though I don't know for sure) that our other generated code (like antlr) actually use the jboss logging annotations, so I therefore doubt we actually need this setting to be "true."

I can confirm it doesn't. The generated code in the metrics project is 
pure ANTLR.

From mazz at redhat.com  Wed Feb  4 21:38:25 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 4 Feb 2015 21:38:25 -0500 (EST)
Subject: [Hawkular-dev] logging bug
In-Reply-To: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
References: <957163827.6856295.1423076019160.JavaMail.zimbra@redhat.com>
Message-ID: <258960379.6990947.1423103905669.JavaMail.zimbra@redhat.com>

> after integrating with jboss logging that we've hit a pretty nasty javac bug.

Thanks to James Perkins, we've got a solution to this. Just needs a maven compiler plugin configuration setting that we were missing. That has been added to the parent pom - see PR https://github.com/hawkular/hawkular-parent-pom/pull/10/files

Once this is merged, all should be well. I tested it and it seems to solve the problem:

This requires an additional dependency on all maven modules that need jboss logging - it is another "provided" scope dependency that is only needed at compile time, not runtime:

<dependency>
  <groupId>org.jboss.logging</groupId>
  <artifactId>jboss-logging-processor</artifactId>
  <scope>provided</scope>
</dependency>


From lkrejci at redhat.com  Thu Feb  5 04:49:33 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 05 Feb 2015 10:49:33 +0100
Subject: [Hawkular-dev] Cassandra & Titan
In-Reply-To: <1198627348.4771976.1423071997597.JavaMail.zimbra@redhat.com>
References: <602399252.4328419.1422975531707.JavaMail.zimbra@redhat.com>
	<8680602.h9C1rabEam@localhost.localdomain>
	<1198627348.4771976.1423071997597.JavaMail.zimbra@redhat.com>
Message-ID: <3414933.cE9XsUUuNH@localhost.localdomain>

Well, using blueprints or not (or maybe we should start looking at tinkerpop3 
which merges blueprints, gremlin and all other tinkerpop projects into 1 lib), 
the main advantage of using Titan is the shared storage with metrics.

I am a little bit afraid of committing to using something that will quite 
likely just slowly die.

On Wednesday, February 04, 2015 12:46:37 Jiri Kremser wrote:
> Hi,
>   In my opinion we can still use the Blueprints API, because there are
> numerous implementations out there
> 
> https://github.com/tinkerpop/blueprints/wiki
> 
> including neo4j (gpl), Mongo, OrientDB and possibly jdbc as a fallback (or
> even start for mvp). If we pick something Blueprints compliant, we get the
> bunch of graph algorithms for free:
> 
> https://github.com/tinkerpop/furnace/wiki
> 
> To be clear, titan will be still open-source, but without core developers, I
> guess, they will give it to the apache incubator.
> 
> 
> more info about the situation here:
> https://groups.google.com/forum/#!topic/aureliusgraphs/WtU6om8CtqI
> and here: https://groups.google.com/forum/#!topic/aureliusgraphs/c07WEdH-epY
> 
> jk
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From bdawidow at redhat.com  Thu Feb  5 04:55:20 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Thu, 05 Feb 2015 10:55:20 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54D22C8E.30601@redhat.com>
References: <54C28AE2.3010509@redhat.com>	<54C601D9.9030102@redhat.com>	<54C75B94.8080103@redhat.com>	<54C79ECF.7020109@redhat.com>	<54CA1768.8050105@redhat.com>	<54CA5AFD.5010102@redhat.com>	<54CB55CF.3040207@redhat.com>	<54CB6964.10905@redhat.com>	<54D21A28.2030405@redhat.com>	<D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>
	<54D22C8E.30601@redhat.com>
Message-ID: <54D33E08.7070102@redhat.com>

I think major question is what do you need - and then please let us know 
on keycloak-dev ;) We'll either try to convince you that you are wrong 
or put your usecase on our roadmap.

If question is between somehow "embedding" keycloak or just have it 
locally installed there is also second part of the story. As it is Auth 
server (Identity Provider) with SSO capabilities for true production 
deployment you would rather want to have this separately deployed. 
You'll likely need to be able to switch to using external instance anyway.

W dniu 2015-02-04 o 15:28, Juraci Paix?o Kr?hling pisze:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/04/2015 03:23 PM, Heiko Braun wrote:
>> Does keycloak support other auth mechanisms that don't build on
>> http?
>
> No. Keycloak is a "super OAuth" solution, and that's on top of HTTP.
> What kind of other authentication mechanisms are you thinking about?
>
>> Does keycloak limit the reuse of hawkular components?
>
> Not that I'm aware of. All it does is to put a layer between the
> incoming request and the business method on the backend, like JAAS.
>
>> Does keycloak have a desirable out-of-the-box experience? (Read
>> addtional setup costs)
>
> Depends on the definition of "desirable". Right now, the common
> practice for projects consuming Keycloak seems to build an "appliance"
> distribution, which builds on top of Wildfly and delivers Keycloak
> pre-installed/configured + the target application (hawkular, in our
> case).
>
> - - Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU0iyOAAoJECKM1e+fkPrXj+AH/2hF7EBlQ2n7VVSbkjGLODgo
> C33cMgBpsonGUFZcd8LXAOdl2ZpklpRzjdcOpVB6OJUasV5Ek/pONyTn8LMStJzV
> nJrHTBKtR71+V9+A2g/cSbv4x7vynhNqSAHEq3a+OwEhzZ8DT+sQnxFRr+QdMMWh
> e+QiVUBCgx/4IBL1gsw40OBy/I1d7NULwS7fzMvunnacHYEibZc4ACgQwy/LPCih
> xbAmYn8SP5IgLT+TqLSnNUMJps44phkdYsSkku3wotH9YkOI55PNlYU9iTbYa9kr
> SCe1aIeIeA5hooCVJ92FMeRF5Pyf9OOgn1flKdurC0nvdWBe3mIlza32KOWLY9U=
> =ZYJJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

-- 
Boles?aw Dawidowicz
Supervisor, Software Engineering | Red Hat Middleware Security


From tsegismo at redhat.com  Thu Feb  5 05:01:53 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 05 Feb 2015 11:01:53 +0100
Subject: [Hawkular-dev] About configuration
Message-ID: <54D33F91.9050202@redhat.com>

Hi everyone,

Yesterday Lukas asked on IRC if there was a discussion about 
configuration. AFAIK, there wasn't, hence I'm sharing how we support 
configuration in metrics.

# Metrics REST server

The REST server runs on top of Wildfly.

Configuration is a set of key/value pairs (configuration properties) 
defined by the following sources, in order of precedence:

* system properties (-Dkey=value)
* external java.util.Properties file, which path is defined by the 
metrics.conf system property; by default, <user.home>/.metrics.conf is 
used (if it exists)
* internal java.util.Properties file (META-INF/metrics.conf)

The rationale behind is that the system should be able to:

1. start with reasonable defaults
2. switch to another configuration easily

# pTrans

pTrans is different because it's a standalone application, so it's much 
easier to follow the daemon configuration habits.

pTrans takes a path to a properties configuration file as a program 
argument. This argument is mandatory.

# Configuration file format.

metrics started with properties file and I think it's fine.

But if we feel the need for a more structured format, we should pick 
something which can be easily parsed by a variety of programming 
languages, especially languages widely used for administration (Python 
and Ruby).


Regards,
Thomas

From lkrejci at redhat.com  Thu Feb  5 05:41:15 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 05 Feb 2015 11:41:15 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D33F91.9050202@redhat.com>
References: <54D33F91.9050202@redhat.com>
Message-ID: <54738031.WzPpYkhSPl@localhost.localdomain>

I am not for or against using properties for config simply because I do not 
yet know what the requirements for the configuration will end up being.

On the other hand I feel we should from the start use something that is 
capable of handling more structured configuration formats without us needing 
to rewrite all the configuration handling code if that need arose (by 
abandoning java's Properties and moving to something different).

Hence I propose using Apache Commons Configuration for reading the 
configuration files. I think Artificer uses it, too, so Brett et al. can 
comment if that would be the right thing to do or not.

Commons configuration supports XPATH for accessing nested data so working with 
hierarchical properties should be quite nice with it. The disadvantage is that 
it drags several other deps with it - 
http://commons.apache.org/proper/commons-configuration/dependencies_1_10.html.

Other option could be to commit to a single configuration format and use a 
dedicated parser for that with minimal deps. For example if we chose JSON as 
the config format we could use JBoss DMR for reading/writing such configs. The 
advantage of that approach is that DMR is absolutely tiny with no external 
deps. The disadvantage is that JSON cannot have comments (which is easily 
amended by a custom reader that would strip the comments before the contents 
are passed to DMR for parsing (a recommended approach from the author of JSON 
- https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).

On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
> Hi everyone,
> 
> Yesterday Lukas asked on IRC if there was a discussion about
> configuration. AFAIK, there wasn't, hence I'm sharing how we support
> configuration in metrics.
> 
> # Metrics REST server
> 
> The REST server runs on top of Wildfly.
> 
> Configuration is a set of key/value pairs (configuration properties)
> defined by the following sources, in order of precedence:
> 
> * system properties (-Dkey=value)
> * external java.util.Properties file, which path is defined by the
> metrics.conf system property; by default, <user.home>/.metrics.conf is
> used (if it exists)
> * internal java.util.Properties file (META-INF/metrics.conf)
> 
> The rationale behind is that the system should be able to:
> 
> 1. start with reasonable defaults
> 2. switch to another configuration easily
> 
> # pTrans
> 
> pTrans is different because it's a standalone application, so it's much
> easier to follow the daemon configuration habits.
> 
> pTrans takes a path to a properties configuration file as a program
> argument. This argument is mandatory.
> 
> # Configuration file format.
> 
> metrics started with properties file and I think it's fine.
> 
> But if we feel the need for a more structured format, we should pick
> something which can be easily parsed by a variety of programming
> languages, especially languages widely used for administration (Python
> and Ruby).
> 
> 
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From mazz at redhat.com  Thu Feb  5 09:09:54 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 5 Feb 2015 09:09:54 -0500 (EST)
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54738031.WzPpYkhSPl@localhost.localdomain>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
Message-ID: <682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>

I have a few points:

1) pick one way to configure, not N ways. I've since learned that while it is nice that the agent has so many ways to configure itself (-D cmd line, agent-configuration.xml, setconfig prompt, -c <file> command line option, config <file> option, etc.) its a pain to keep track of it all and making sure all of it works and never breaks along the line.

2) If at all possible, have a single configuration point (a single .xml file for example), not multiple files and certainly not multiple files in multiple different directories.

3) Why not try to have all our configuration set in standalone.xml? If we are going to be deployed in Wildfly, it would be nice to have everything (not just our config, but the config for the wildfly subsystems too) in one place. This also allows us to piggyback on jboss-cli - we simply use the jboss-cli to have a cmdline interface to our configuration.

4) Keep in mind installation use-cases - don't make configuration so hard that we have to write a convoluted installer to get things to run.

Note that standalone.xml has a section for just system properties - so if you want to use system properties as your way of configuration, that can be done in standalone.xml as well.

Anyway, those are my thoughts. If they can't be done with metrics, or inventory, or whatever, then so be it. But I take those points above from experience with the RHQ's configuration.

----- Original Message -----
> I am not for or against using properties for config simply because I do not
> yet know what the requirements for the configuration will end up being.
> 
> On the other hand I feel we should from the start use something that is
> capable of handling more structured configuration formats without us needing
> to rewrite all the configuration handling code if that need arose (by
> abandoning java's Properties and moving to something different).
> 
> Hence I propose using Apache Commons Configuration for reading the
> configuration files. I think Artificer uses it, too, so Brett et al. can
> comment if that would be the right thing to do or not.
> 
> Commons configuration supports XPATH for accessing nested data so working
> with
> hierarchical properties should be quite nice with it. The disadvantage is
> that
> it drags several other deps with it -
> http://commons.apache.org/proper/commons-configuration/dependencies_1_10.html.
> 
> Other option could be to commit to a single configuration format and use a
> dedicated parser for that with minimal deps. For example if we chose JSON as
> the config format we could use JBoss DMR for reading/writing such configs.
> The
> advantage of that approach is that DMR is absolutely tiny with no external
> deps. The disadvantage is that JSON cannot have comments (which is easily
> amended by a custom reader that would strip the comments before the contents
> are passed to DMR for parsing (a recommended approach from the author of JSON
> - https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
> 
> On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
> > Hi everyone,
> > 
> > Yesterday Lukas asked on IRC if there was a discussion about
> > configuration. AFAIK, there wasn't, hence I'm sharing how we support
> > configuration in metrics.
> > 
> > # Metrics REST server
> > 
> > The REST server runs on top of Wildfly.
> > 
> > Configuration is a set of key/value pairs (configuration properties)
> > defined by the following sources, in order of precedence:
> > 
> > * system properties (-Dkey=value)
> > * external java.util.Properties file, which path is defined by the
> > metrics.conf system property; by default, <user.home>/.metrics.conf is
> > used (if it exists)
> > * internal java.util.Properties file (META-INF/metrics.conf)
> > 
> > The rationale behind is that the system should be able to:
> > 
> > 1. start with reasonable defaults
> > 2. switch to another configuration easily
> > 
> > # pTrans
> > 
> > pTrans is different because it's a standalone application, so it's much
> > easier to follow the daemon configuration habits.
> > 
> > pTrans takes a path to a properties configuration file as a program
> > argument. This argument is mandatory.
> > 
> > # Configuration file format.
> > 
> > metrics started with properties file and I think it's fine.
> > 
> > But if we feel the need for a more structured format, we should pick
> > something which can be easily parsed by a variety of programming
> > languages, especially languages widely used for administration (Python
> > and Ruby).
> > 
> > 
> > Regards,
> > Thomas
> > _______________________________________________
> > 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  Thu Feb  5 09:22:30 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 05 Feb 2015 15:22:30 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54738031.WzPpYkhSPl@localhost.localdomain>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
Message-ID: <54D37CA6.1010500@redhat.com>

I believe the way we read/use config can be decided at the sub-project 
level (provided we don't use an exotic format).

Le 05/02/2015 11:41, Lukas Krejci a ?crit :
> I am not for or against using properties for config simply because I do not
> yet know what the requirements for the configuration will end up being.
>
> On the other hand I feel we should from the start use something that is
> capable of handling more structured configuration formats without us needing
> to rewrite all the configuration handling code if that need arose (by
> abandoning java's Properties and moving to something different).
>
> Hence I propose using Apache Commons Configuration for reading the
> configuration files. I think Artificer uses it, too, so Brett et al. can
> comment if that would be the right thing to do or not.
>
> Commons configuration supports XPATH for accessing nested data so working with
> hierarchical properties should be quite nice with it. The disadvantage is that
> it drags several other deps with it -
> http://commons.apache.org/proper/commons-configuration/dependencies_1_10.html.
>
> Other option could be to commit to a single configuration format and use a
> dedicated parser for that with minimal deps. For example if we chose JSON as
> the config format we could use JBoss DMR for reading/writing such configs. The
> advantage of that approach is that DMR is absolutely tiny with no external
> deps. The disadvantage is that JSON cannot have comments (which is easily
> amended by a custom reader that would strip the comments before the contents
> are passed to DMR for parsing (a recommended approach from the author of JSON
> - https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
>
> On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
>> Hi everyone,
>>
>> Yesterday Lukas asked on IRC if there was a discussion about
>> configuration. AFAIK, there wasn't, hence I'm sharing how we support
>> configuration in metrics.
>>
>> # Metrics REST server
>>
>> The REST server runs on top of Wildfly.
>>
>> Configuration is a set of key/value pairs (configuration properties)
>> defined by the following sources, in order of precedence:
>>
>> * system properties (-Dkey=value)
>> * external java.util.Properties file, which path is defined by the
>> metrics.conf system property; by default, <user.home>/.metrics.conf is
>> used (if it exists)
>> * internal java.util.Properties file (META-INF/metrics.conf)
>>
>> The rationale behind is that the system should be able to:
>>
>> 1. start with reasonable defaults
>> 2. switch to another configuration easily
>>
>> # pTrans
>>
>> pTrans is different because it's a standalone application, so it's much
>> easier to follow the daemon configuration habits.
>>
>> pTrans takes a path to a properties configuration file as a program
>> argument. This argument is mandatory.
>>
>> # Configuration file format.
>>
>> metrics started with properties file and I think it's fine.
>>
>> But if we feel the need for a more structured format, we should pick
>> something which can be easily parsed by a variety of programming
>> languages, especially languages widely used for administration (Python
>> and Ruby).
>>
>>
>> Regards,
>> Thomas
>> _______________________________________________
>> 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  Thu Feb  5 09:58:39 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 05 Feb 2015 15:58:39 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>
References: <54D33F91.9050202@redhat.com>	<54738031.WzPpYkhSPl@localhost.localdomain>
	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>
Message-ID: <54D3851F.3050400@redhat.com>

Le 05/02/2015 15:09, John Mazzitelli a ?crit :
> I have a few points:
>
> 1) pick one way to configure, not N ways. I've since learned that while it is nice that the agent has so many ways to configure itself (-D cmd line, agent-configuration.xml, setconfig prompt, -c <file> command line option, config <file> option, etc.) its a pain to keep track of it all and making sure all of it works and never breaks along the line.

Not N, 2 ways :)

I had in mind that the configuration file was the "main" way. I'd be 
fine with removing the system property override mechanism.

>
> 2) If at all possible, have a single configuration point (a single .xml file for example), not multiple files and certainly not multiple files in multiple different directories.

Agreed. That's what metrics does. When we'll have alerts and a bunch of 
notifiers in the same nest then multiple files might be inevitable.

>
> 3) Why not try to have all our configuration set in standalone.xml? If we are going to be deployed in Wildfly, it would be nice to have everything (not just our config, but the config for the wildfly subsystems too) in one place. This also allows us to piggyback on jboss-cli - we simply use the jboss-cli to have a cmdline interface to our configuration.

I'd rather keep our apps config out the Wildfly config.

>
> 4) Keep in mind installation use-cases - don't make configuration so hard that we have to write a convoluted installer to get things to run.

Yes. Storing configuration in a file and then pointing to this file with 
a command line parameter or a system property is the best way to make it 
easy to automate installation with a config management tool.

>
> Note that standalone.xml has a section for just system properties - so if you want to use system properties as your way of configuration, that can be done in standalone.xml as well.
>
> Anyway, those are my thoughts. If they can't be done with metrics, or inventory, or whatever, then so be it. But I take those points above from experience with the RHQ's configuration.
>
> ----- Original Message -----
>> I am not for or against using properties for config simply because I do not
>> yet know what the requirements for the configuration will end up being.
>>
>> On the other hand I feel we should from the start use something that is
>> capable of handling more structured configuration formats without us needing
>> to rewrite all the configuration handling code if that need arose (by
>> abandoning java's Properties and moving to something different).
>>
>> Hence I propose using Apache Commons Configuration for reading the
>> configuration files. I think Artificer uses it, too, so Brett et al. can
>> comment if that would be the right thing to do or not.
>>
>> Commons configuration supports XPATH for accessing nested data so working
>> with
>> hierarchical properties should be quite nice with it. The disadvantage is
>> that
>> it drags several other deps with it -
>> http://commons.apache.org/proper/commons-configuration/dependencies_1_10.html.
>>
>> Other option could be to commit to a single configuration format and use a
>> dedicated parser for that with minimal deps. For example if we chose JSON as
>> the config format we could use JBoss DMR for reading/writing such configs.
>> The
>> advantage of that approach is that DMR is absolutely tiny with no external
>> deps. The disadvantage is that JSON cannot have comments (which is easily
>> amended by a custom reader that would strip the comments before the contents
>> are passed to DMR for parsing (a recommended approach from the author of JSON
>> - https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
>>
>> On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
>>> Hi everyone,
>>>
>>> Yesterday Lukas asked on IRC if there was a discussion about
>>> configuration. AFAIK, there wasn't, hence I'm sharing how we support
>>> configuration in metrics.
>>>
>>> # Metrics REST server
>>>
>>> The REST server runs on top of Wildfly.
>>>
>>> Configuration is a set of key/value pairs (configuration properties)
>>> defined by the following sources, in order of precedence:
>>>
>>> * system properties (-Dkey=value)
>>> * external java.util.Properties file, which path is defined by the
>>> metrics.conf system property; by default, <user.home>/.metrics.conf is
>>> used (if it exists)
>>> * internal java.util.Properties file (META-INF/metrics.conf)
>>>
>>> The rationale behind is that the system should be able to:
>>>
>>> 1. start with reasonable defaults
>>> 2. switch to another configuration easily
>>>
>>> # pTrans
>>>
>>> pTrans is different because it's a standalone application, so it's much
>>> easier to follow the daemon configuration habits.
>>>
>>> pTrans takes a path to a properties configuration file as a program
>>> argument. This argument is mandatory.
>>>
>>> # Configuration file format.
>>>
>>> metrics started with properties file and I think it's fine.
>>>
>>> But if we feel the need for a more structured format, we should pick
>>> something which can be easily parsed by a variety of programming
>>> languages, especially languages widely used for administration (Python
>>> and Ruby).
>>>
>>>
>>> Regards,
>>> Thomas
>>> _______________________________________________
>>> 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  Thu Feb  5 10:25:53 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 5 Feb 2015 10:25:53 -0500 (EST)
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D3851F.3050400@redhat.com>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>
	<54D3851F.3050400@redhat.com>
Message-ID: <120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>

> > 3) Why not try to have all our configuration set in standalone.xml? If we
> > are going to be deployed in Wildfly, it would be nice to have everything
> > (not just our config, but the config for the wildfly subsystems too) in
> > one place. This also allows us to piggyback on jboss-cli - we simply use
> > the jboss-cli to have a cmdline interface to our configuration.
> 
> I'd rather keep our apps config out the Wildfly config.

What is your reasoning for wanting to keep our apps config out of Wildfly config?

The reason why I say it would be nice to use standalone.xml for our config is:

1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).

2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems.

3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.

4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.

The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.

But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs.

From lkrejci at redhat.com  Thu Feb  5 11:01:26 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 05 Feb 2015 17:01:26 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
References: <54D33F91.9050202@redhat.com> <54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
Message-ID: <9553805.Z0D4WbdfI0@localhost.localdomain>

On Thursday, February 05, 2015 10:25:53 John Mazzitelli wrote:
> > > 3) Why not try to have all our configuration set in standalone.xml? If
> > > we
> > > are going to be deployed in Wildfly, it would be nice to have everything
> > > (not just our config, but the config for the wildfly subsystems too) in
> > > one place. This also allows us to piggyback on jboss-cli - we simply use
> > > the jboss-cli to have a cmdline interface to our configuration.
> > 
> > I'd rather keep our apps config out the Wildfly config.
> 
> What is your reasoning for wanting to keep our apps config out of Wildfly
> config?
> 

The main reason for me is that I don't want to require running in Wildfly. 
IMHO, the core component implementations should be consumable as libraries and 
for that requiring wildfly is a big no-no.

At the same time the core impl needs to be configured somehow, too. We can say 
that that can only be done by "filling" the configuration "pojo" 
programmatically and leave the exercise of reading and storing the data to the 
user of the library. Or we could use commons configuration for a similar 
purpose with the benefit of it already knowing how to read/persist. Or as I 
said, we could use DMR or whatever else. I just don't want to tie ourselves so 
strongly to Wildfly. If we can only be configured when deployed inside a 
container then I think we will not support an important usecase of us (the 
individual components of hawkular that is) being able to function as a 
library.

That said, I wholly agree with you that IF we are deployed inside Wildfly then 
standalone.xml is the exact place to read the config from.

> The reason why I say it would be nice to use standalone.xml for our config
> is:
> 
> 1) all configuration, for everything, is in one place. Remember JBoss 4,
> with all their many .xml config files? It was hard to manage, which is one
> reason why they went to a single .xml file (though, granted, I believe they
> are thinking about making it possible to import .xml files into the main
> config - don't know if that's available yet).
> 
> 2) It gives us, for free, a CLI - we don't have to write and maintain one.
> If everything is in standalone.xml, we can use the JBoss CLI to look at our
> config and change it along with the rest of the wildfly subsystems.
> 
> 3) If our components consist of Wildfly Extensions, then this is how you
> configure that extension. So it would be natural to have all config (for
> the extension and the other pieces of the component) in the same place.
> 
> 4) Address and port assignments. Right now, standalone.xml allows you to
> define socket binding groups - allowing a "one stop shop" to define all
> your port bindings. Adjusting the port-offset provides a nice way to easily
> offset ports so you can run multiple components on the same box. If we have
> different configs (that need to specify hostnames/ports), we now have
> multiple places where this is configured - thus opening up to possible
> conflicts plus just a pain to have to now go to different places to
> configure bindings. The port bindings in one place is nice for
> manageability.
> 
> The one negative of this approach is if our components can run outside of
> being embedded in Wildfly, we lose all of the above. We would need our own
> configuration mechanism (and CLI) if we can run outside of WildFly.
>

So in another words, we're on the same page.

> But I see alot of positives for putting our subsystem configuration in with
> the rest of WildFly subsystem configs.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jshaughn at redhat.com  Thu Feb  5 13:32:56 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 05 Feb 2015 13:32:56 -0500
Subject: [Hawkular-dev] About configuration
In-Reply-To: <9553805.Z0D4WbdfI0@localhost.localdomain>
References: <54D33F91.9050202@redhat.com>
	<54D3851F.3050400@redhat.com>	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
	<9553805.Z0D4WbdfI0@localhost.localdomain>
Message-ID: <54D3B758.4080605@redhat.com>


 From what I can see at the moment H Alerts will depend on H Bus, and be 
deployed in WFly via the nest.  I see no use case past that at the 
moment.  As such, using standalone.xml seems like an obvious choice and 
I expect that's what we'll use.  If and when we ever need to be consumed 
in another way then we, or the community, could add another 
configuration option.

On 2/5/2015 11:01 AM, Lukas Krejci wrote:
> On Thursday, February 05, 2015 10:25:53 John Mazzitelli wrote:
>>>> 3) Why not try to have all our configuration set in standalone.xml? If
>>>> we
>>>> are going to be deployed in Wildfly, it would be nice to have everything
>>>> (not just our config, but the config for the wildfly subsystems too) in
>>>> one place. This also allows us to piggyback on jboss-cli - we simply use
>>>> the jboss-cli to have a cmdline interface to our configuration.
>>> I'd rather keep our apps config out the Wildfly config.
>> What is your reasoning for wanting to keep our apps config out of Wildfly
>> config?
>>
> The main reason for me is that I don't want to require running in Wildfly.
> IMHO, the core component implementations should be consumable as libraries and
> for that requiring wildfly is a big no-no.
>
> At the same time the core impl needs to be configured somehow, too. We can say
> that that can only be done by "filling" the configuration "pojo"
> programmatically and leave the exercise of reading and storing the data to the
> user of the library. Or we could use commons configuration for a similar
> purpose with the benefit of it already knowing how to read/persist. Or as I
> said, we could use DMR or whatever else. I just don't want to tie ourselves so
> strongly to Wildfly. If we can only be configured when deployed inside a
> container then I think we will not support an important usecase of us (the
> individual components of hawkular that is) being able to function as a
> library.
>
> That said, I wholly agree with you that IF we are deployed inside Wildfly then
> standalone.xml is the exact place to read the config from.
>
>> The reason why I say it would be nice to use standalone.xml for our config
>> is:
>>
>> 1) all configuration, for everything, is in one place. Remember JBoss 4,
>> with all their many .xml config files? It was hard to manage, which is one
>> reason why they went to a single .xml file (though, granted, I believe they
>> are thinking about making it possible to import .xml files into the main
>> config - don't know if that's available yet).
>>
>> 2) It gives us, for free, a CLI - we don't have to write and maintain one.
>> If everything is in standalone.xml, we can use the JBoss CLI to look at our
>> config and change it along with the rest of the wildfly subsystems.
>>
>> 3) If our components consist of Wildfly Extensions, then this is how you
>> configure that extension. So it would be natural to have all config (for
>> the extension and the other pieces of the component) in the same place.
>>
>> 4) Address and port assignments. Right now, standalone.xml allows you to
>> define socket binding groups - allowing a "one stop shop" to define all
>> your port bindings. Adjusting the port-offset provides a nice way to easily
>> offset ports so you can run multiple components on the same box. If we have
>> different configs (that need to specify hostnames/ports), we now have
>> multiple places where this is configured - thus opening up to possible
>> conflicts plus just a pain to have to now go to different places to
>> configure bindings. The port bindings in one place is nice for
>> manageability.
>>
>> The one negative of this approach is if our components can run outside of
>> being embedded in Wildfly, we lose all of the above. We would need our own
>> configuration mechanism (and CLI) if we can run outside of WildFly.
>>
> So in another words, we're on the same page.
>
>> But I see alot of positives for putting our subsystem configuration in with
>> the rest of WildFly subsystem configs.
>> _______________________________________________
>> 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  Thu Feb  5 15:34:41 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 5 Feb 2015 15:34:41 -0500 (EST)
Subject: [Hawkular-dev] integration project
In-Reply-To: <BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
References: <AA68ED56-1301-476F-8FD4-76FA2ADEF53B@redhat.com>
	<415096932.7531096.1423166525769.JavaMail.zimbra@redhat.com>
	<BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
Message-ID: <1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>

OK, good news/bad news.

I got all the pieces in the integration distribution here - its in a branch in the hawkular repo:

https://github.com/hawkular/hawkular/tree/mazz/integration-assembly

This has everything - inventory, alerts, metrics, and bus - installed in the nest.

Bad news - metrics is broken. When you start, you'll get an exception because it appears the embedded cassandra EAR initializes too late - after the metrics war tries to find C*. You'll get deployment errors due to this.

But everything else appears to deploy successfully.

Just need to find out how to get metrics deployed properly with embedded C*. Can we put some kind of optional dependency in the metrics WAR? Have it depend on the embedded EAR?

From snegrea at redhat.com  Thu Feb  5 15:43:17 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 5 Feb 2015 15:43:17 -0500 (EST)
Subject: [Hawkular-dev] RHQ Metrics - 0.2.7 & Hawkular Future
In-Reply-To: <20025789.5904988.1423167745827.JavaMail.zimbra@redhat.com>
Message-ID: <1969397940.5917124.1423168997249.JavaMail.zimbra@redhat.com>

Hello Everybody,

I want to summarize the latest release of the RHQ Metrics project and the future of the project.


1) RHQ Metrics migrates to Hawkular organization

Release 0.2.7 of the RHQ Metrics is the last one from the current repository. But do not panic! Beyond the mechanics of the transfer and rename, the development will continue with the regular crew.

For the migration, two project repositories (rhq-metrics and rhq-metrics-openshift) will just be transferred to the Hawkular organization. The code from rhqm-charts was already moved to Hawkular, so we will just close the RHQ repository. We will have a follow up communication once all the infrastructure is in place under the new organization.


2) RHQ Metrics 0.2.7 was released today

This release has mainly stability fixes and minor enhancements. The Keycloak integration was delayed and not part of this release (as announced in the planning notes). For more details checkout the Github release notes.

Github Release:
https://github.com/rhq-project/rhq-metrics/releases/tag/0.2.7

JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/rhq/metrics/


2) OpenShift Cartridge for RHQ Metrics 0.2.7

The cartridge supports RHQ Metrics 0.2.7, 0.2.6, and 0.2.5. Just a reminder, the cartridge is the simplest and easiest way to get a public facing instance of RHQ Metrics in just a few minutes with a single command. The cartridge configures Cassandra, Wildfly, and RHQ Metrics (REST interface and UI console) to run in a single gear. For more details please visit the Github repository of the project.

Sample command to create a new RHQ Metrics deployment:
rhc app create test_app https://raw.githubusercontent.com/rhq-project/rhq-metrics-openshift/master/metadata/manifest.yml

Github Repository:
https://github.com/rhq-project/rhq-metrics-openshift


A big "Thank you!" goes to John Sanda, Mike Thompson, Heiko Rupp, and Thomas Segismont for their project contributions.


Any discussion, suggestions or contributions are more than welcomed; so feel free to reply to this email or comment directly on the various forum threads. 


Thank you,
Stefan Negrea

Software Engineer

_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

From snegrea at redhat.com  Thu Feb  5 16:34:45 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 5 Feb 2015 16:34:45 -0500 (EST)
Subject: [Hawkular-dev] Hawkular Migration - RHQ Metrics
In-Reply-To: <30753472.5919084.1423169083700.JavaMail.zimbra@redhat.com>
Message-ID: <1570201958.5941384.1423172085417.JavaMail.zimbra@redhat.com>

Hello Everybody, 

Here is the plan migrating RHQ Metrics and related projects to Hawkular organization (timeline in chronological order):

1) Remove access to rhq-metrics-openshift, rhq-metrics, rhqm-charts, and wildfly-cassandra repositories
2) Transfer rhq-metrics-openshift, rhq-metrics, and widlfly-cassandra to the Hawkular organization
3) Replace the README.md for rhqm-charts with a link to the new Hawkular repository
4) Rename rhq-metrics-openshift and rhq-metrics repositories to reflect the new organization
5) Create new teams inside the new organization for write access to the migrated repositories
6) Update files inside the migrated repositories to reflect the new name
7) Re-organize the metrics project modules

I will start the migration tonight to have minimum impact on development. I will send updated links after all repositories get fully migrated.


Thank you,
Stefan Negrea

Software Engineer


From snegrea at redhat.com  Fri Feb  6 01:53:43 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Fri, 6 Feb 2015 01:53:43 -0500 (EST)
Subject: [Hawkular-dev] Hawkular Migration - RHQ Metrics
In-Reply-To: <1570201958.5941384.1423172085417.JavaMail.zimbra@redhat.com>
References: <1570201958.5941384.1423172085417.JavaMail.zimbra@redhat.com>
Message-ID: <793203187.6099976.1423205623405.JavaMail.zimbra@redhat.com>

Hello Everybody,

Steps 1 through 5 have been completed from the plan below.

Here are the URLs of newly migrated repositories:

1) Metrics: https://github.com/hawkular/hawkular-metrics
2) Metrics Openshift Cartridge: https://github.com/hawkular/hawkular-metrics-openshift
3) Charts: https://github.com/hawkular/hawkular-charts
4) Wildfly Cassandra Extension: https://github.com/hawkular/wildfly-cassandra
5) Widlfly Monitor: https://github.com/hawkular/wildfly-monitor

With the exception of Hawkular Charts, the only local action needed is to update the remote git URL. For Hawkular Charts, please clone the new repository.

Will continue with rest of the steps tomorrow.


Thank you,
Stefan


----- Original Message -----
> From: "Stefan Negrea" <snegrea at redhat.com>
> To: "rhq-devel" <rhq-devel at lists.fedorahosted.org>, hawkular-dev at lists.jboss.org
> Sent: Thursday, February 5, 2015 3:34:45 PM
> Subject: [Hawkular-dev] Hawkular Migration - RHQ Metrics
> 
> Hello Everybody,
> 
> Here is the plan migrating RHQ Metrics and related projects to Hawkular
> organization (timeline in chronological order):
> 
> 1) Remove access to rhq-metrics-openshift, rhq-metrics, rhqm-charts, and
> wildfly-cassandra repositories
> 2) Transfer rhq-metrics-openshift, rhq-metrics, and widlfly-cassandra to the
> Hawkular organization
> 3) Replace the README.md for rhqm-charts with a link to the new Hawkular
> repository
> 4) Rename rhq-metrics-openshift and rhq-metrics repositories to reflect the
> new organization
> 5) Create new teams inside the new organization for write access to the
> migrated repositories
> 6) Update files inside the migrated repositories to reflect the new name
> 7) Re-organize the metrics project modules
> 
> I will start the migration tonight to have minimum impact on development. I
> will send updated links after all repositories get fully migrated.
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From tsegismo at redhat.com  Fri Feb  6 03:45:32 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 09:45:32 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
References: <54D33F91.9050202@redhat.com>	<54738031.WzPpYkhSPl@localhost.localdomain>	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>	<54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
Message-ID: <54D47F2C.6010606@redhat.com>

Because to me, it looks simpler to have a hawkular-server.properties (or 
.yaml/.json/.xml) which groups all the hawkular components configuration 
(from adapters to applications).

I have the feeling that inserting our configuration in the Wildfly 
config file will make building assemblies and setting up integration 
tests more difficult.

Le 05/02/2015 16:25, John Mazzitelli a ?crit :
>>> 3) Why not try to have all our configuration set in standalone.xml? If we
>>> are going to be deployed in Wildfly, it would be nice to have everything
>>> (not just our config, but the config for the wildfly subsystems too) in
>>> one place. This also allows us to piggyback on jboss-cli - we simply use
>>> the jboss-cli to have a cmdline interface to our configuration.
>>
>> I'd rather keep our apps config out the Wildfly config.
>
> What is your reasoning for wanting to keep our apps config out of Wildfly config?
>
> The reason why I say it would be nice to use standalone.xml for our config is:
>
> 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).
>
> 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems.
>
> 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.
>
> 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.
>
> The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.
>
> But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Fri Feb  6 03:54:34 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 06 Feb 2015 09:54:34 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D47F2C.6010606@redhat.com>
References: <54D33F91.9050202@redhat.com>	<54738031.WzPpYkhSPl@localhost.localdomain>	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>	<54D3851F.3050400@redhat.com>	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
	<54D47F2C.6010606@redhat.com>
Message-ID: <54D4814A.9080404@redhat.com>

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

On 02/06/2015 09:45 AM, Thomas Segismont wrote:
> I have the feeling that inserting our configuration in the Wildfly
>  config file will make building assemblies and setting up
> integration tests more difficult.

Not sure about tests, but surely not making assemblies :-) Keycloak
uses something similar, with XSLT:

https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/src/main/xslt/standalone.xsl

https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/pom.xml#L154

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

iQEcBAEBAgAGBQJU1IFJAAoJECKM1e+fkPrXp4cH/iMBKi5bXY4sAQF6hM3+nYoH
hhTvchwAHCtiAznRidYDdugOempD+d69xuEjEWJEM4Q2g4+F62Aqk/efJPJ/3mq9
6O4lCHsPwZKlEsCTjvJI7aNw7EIy6qQ+o5K7pTv3X3OQZwF1GIFhryVBSuqrMLZ3
qV70BYuK5cc08rUMQmOg7+MAiFnUxLFIk63D3QC4jXPOF7mpTGIOnm8qamu+WhGQ
+Uo0tZXIS4DVaHQWeS1mVqCK1w1XKq4+oEve43pVgjxBl8Zr5AiQNmOeruDnb576
zoSciyB6TyKEzBRcZ/ECP+Myrqf0tcFeFFYvGtrlgoRbynPOfdcIm69ESngTAxs=
=RtXM
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Fri Feb  6 04:43:37 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 10:43:37 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D4814A.9080404@redhat.com>
References: <54D33F91.9050202@redhat.com>	<54738031.WzPpYkhSPl@localhost.localdomain>	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>	<54D3851F.3050400@redhat.com>	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>	<54D47F2C.6010606@redhat.com>
	<54D4814A.9080404@redhat.com>
Message-ID: <54D48CC9.5080301@redhat.com>

Le 06/02/2015 09:54, Juraci Paix?o Kr?hling a ?crit :
> On 02/06/2015 09:45 AM, Thomas Segismont wrote:
>> >I have the feeling that inserting our configuration in the Wildfly
>> >  config file will make building assemblies and setting up
>> >integration tests more difficult.
> Not sure about tests, but surely not making assemblies:-)  Keycloak
> uses something similar, with XSLT:
>
> https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/src/main/xslt/standalone.xsl
>
> https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/pom.xml#L154

Indeed, they use XSLT to declare the extensions (not configuration) in 
the standalone.xml file.

And then in the assembly descriptor they add a keycloak-server.json file 
to the configuration directory:
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/assembly.xml

The keycloak-server.json file is where you actually configure KC. But I 
guess you know that :)

From hrupp at redhat.com  Fri Feb  6 05:08:37 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 11:08:37 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54738031.WzPpYkhSPl@localhost.localdomain>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
Message-ID: <18351016-D137-409A-AA47-1E1C7B5E09CD@redhat.com>


> to rewrite all the configuration handling code if that need arose (by 
> abandoning java's Properties and moving to something different).


Can we solve that issue when it arises? We have bigger fish to fry
right now.


From hrupp at redhat.com  Fri Feb  6 05:13:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 11:13:13 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>
	<54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
Message-ID: <3075E3DE-328E-410C-B864-0C6BB1F8682F@redhat.com>


> Am 05.02.2015 um 16:25 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).
> 
> 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems.
> 
> 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.
> 
> 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.
> 
I am absolutely with Mazz here.


> The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.

And still. Hawkular Metrics will still need a container (e.g. WildFly to run on), so for now that standalone metrics will not
be a process. 
And as Mazz said, the properties inside standalone.xml can be read like system properties you pass in via -Dkey=val,
but just live in that central place and not scattered around.

Ptrans is different, agreed.

And in general: we should out of the box (as it was said) deliver settings that are good most of the time.
The installer in RHQ, that is firing a AS7, then modifying its port settings, then rebooting it and using the new
settings should have taught us something...



From hrupp at redhat.com  Fri Feb  6 05:14:25 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 11:14:25 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D3B758.4080605@redhat.com>
References: <54D33F91.9050202@redhat.com> <54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
	<9553805.Z0D4WbdfI0@localhost.localdomain>
	<54D3B758.4080605@redhat.com>
Message-ID: <F45E6471-188A-4B33-98AA-FE61E4E10533@redhat.com>


> Am 05.02.2015 um 19:32 schrieb Jay Shaughnessy <jshaughn at redhat.com>:
> From what I can see at the moment H Alerts will depend on H Bus, and be 
> deployed in WFly via the nest.  I see no use case past that at the 
> moment.  As such, using standalone.xml seems like an obvious choice and 
> I expect that's what we'll use.  If and when we ever need to be consumed 
> in another way then we, or the community, could add another 
> configuration option.

Right said Fred


From hrupp at redhat.com  Fri Feb  6 05:16:20 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 11:16:20 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D47F2C.6010606@redhat.com>
References: <54D33F91.9050202@redhat.com>
	<54738031.WzPpYkhSPl@localhost.localdomain>
	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>
	<54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
	<54D47F2C.6010606@redhat.com>
Message-ID: <9745403A-17EF-4189-9095-62E6A787645F@redhat.com>


> Am 06.02.2015 um 09:45 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> I have the feeling that inserting our configuration in the Wildfly 
> config file will make building assemblies and setting up integration 
> tests more difficult.

I do expect that we created hand-tailored versions of standalone.xml
And not fancy tooling like that RHQ installer.


From jpkroehling at redhat.com  Fri Feb  6 05:16:46 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 06 Feb 2015 11:16:46 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D48CC9.5080301@redhat.com>
References: <54D33F91.9050202@redhat.com>	<54738031.WzPpYkhSPl@localhost.localdomain>	<682810167.7241341.1423145394299.JavaMail.zimbra@redhat.com>	<54D3851F.3050400@redhat.com>	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>	<54D47F2C.6010606@redhat.com>	<54D4814A.9080404@redhat.com>
	<54D48CC9.5080301@redhat.com>
Message-ID: <54D4948E.1050604@redhat.com>

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

On 02/06/2015 10:43 AM, Thomas Segismont wrote:
> And then in the assembly descriptor they add a keycloak-server.json
> file to the configuration directory: 
> https://github.com/keycloak/keycloak/blob/master/distribution/appliance-dist/assembly.xml
>
>  The keycloak-server.json file is where you actually configure KC.
> But I guess you know that :)

Which they are actually thinking in dropping it, in favor of putting
everything on the standalone.xml .

http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003622.html

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

iQEcBAEBAgAGBQJU1JSOAAoJECKM1e+fkPrXqgEH/16w5o00vBQ5+L5WbcKXeVRE
QhiNlGTEVeGxJgK8O9xKuM4OhK4eQv+aeFb3Ikg5hdshsPNxBn3xZyosh4dLBjQ9
TZvsj2PDqFpb+3Afkfk2wK/ukE1cDXd34QvXxrSVT/9pmQ9i8mUYdbwjRoHXHRVy
3GOyDorh8yIGAmbYOh5WVBspRljOrc1KyWHfrDyMDK0hrfObS8eZHbl24MwAptPt
64OYRSOIAGvig2VM9sJauQiVJdt5nRdRjAS45oScOnITjQDrSsvcnxbhLVTbU3dI
tAQRhWyebS4Wd0H6nNLirWAvDWhG+s2Wp8tomo+XJWTJnlkeHwCeG5M0I63S7xY=
=+VIo
-----END PGP SIGNATURE-----

From hrupp at redhat.com  Fri Feb  6 05:55:07 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 11:55:07 +0100
Subject: [Hawkular-dev] integration project
In-Reply-To: <1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>
References: <AA68ED56-1301-476F-8FD4-76FA2ADEF53B@redhat.com>
	<415096932.7531096.1423166525769.JavaMail.zimbra@redhat.com>
	<BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
	<1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>
Message-ID: <A5AC1495-B8A4-4598-A66B-D4447FC503F1@redhat.com>

Hey,

> Am 05.02.2015 um 21:34 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> 
> Bad news - metrics is broken. When you start, you'll get an exception because it appears the embedded cassandra EAR initializes too late - after the metrics war tries to find C*. You'll get deployment errors due to this.

As said on the channel already the wildfly-cassandra extension from 

https://github.com/hawkular/wildfly-cassandra





From hrupp at redhat.com  Fri Feb  6 06:54:37 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 12:54:37 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <54D24F39.2030305@redhat.com>
References: <54CA6C3C.9080808@redhat.com>
	<CCE59838-49B1-49D1-9DAD-78F1B82ED4DD@redhat.com>
	<54D24F39.2030305@redhat.com>
Message-ID: <59B00CAD-C38D-4C41-8846-585502D5CB34@redhat.com>


> Am 04.02.2015 um 17:56 schrieb Juraci Paix?o Kr?hling <jpkroehling at redhat.com>:
> 
> This way, organizations can be owned by other organizations. Not sure

I think that makes sense and follows the idea of acme.org and foo.acme.org, bar.acme.org

> if this will work, though. I'm starting to work on this right now on a
> new module (hawkular-accounts).

Once you have a little bit of it : can you make it publicly available?
Perhaps including some drawings :)

> 
> If an user makes a REST call to retrieve all metrics that he has
> access to, I'd expect that he'd receive both metrics for his pet
> projects and metrics for organizations he's part of.

Now suppose that user creates a dashboard with (graphs of) org resources and pet resources
and shares (=clones + distributes) that to another user. I guess the dashboard would
then show those pet resources in a bad state (no data, or worse).  Or how could
we deal with that?

> The backend *needs* to check if the current user has access to the
> resource. Other than that, I'd say it's up to the individual
> components (alerts, metrics, inventory, ...) what/how they want to
> expose data to the consumers. For instance, metrics might want to have

Well, we should try to be consistent?

> the following REST endpoints:
> 
> /{owner}/metrics
>  --> all metrics owned by "owner" (organization or user)
> 
> /metrics
>  --> all metrics to which the current user has access to
> 
The difference between the above is that the first is "org XOR user"
resources not "union-or"? While the 2nd one is (org || user) - right?

 Thanks
     Heiko




From tsegismo at redhat.com  Fri Feb  6 07:17:30 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 13:17:30 +0100
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
Message-ID: <54D4B0DA.90202@redhat.com>

Hi,

I've been thinking about the alert notification system lately.

What's the information needed to send a notification?
How to convert the information into text when a human is the recipient? 
How to configure the system?
How to make it fit into the Hawkular suite?

1. Contextual data

A notification has contextual data. Contextual data is comprised of:
- alert definition data
- data involved in the trigger (for example metrics and availability values)

2. Notifier data

2.1 Who is the recipient?

Email: address
SMS: phone number

Sometimes the recipient is fixed (for example when sending email to a 
mailing-list).
Sometimes it should be picked from user information (for example when 
sending emails to a group of users)

This information depends on the alert definition, but a default should 
be configurable for convenience.

2.2 How should the message be sent?

Email: SMTP address/port and credentials
SMS: Web service HTTP URL and credentials

The information depends on the tenant (in rare cases, on the alert 
definition, but let's ignore the problem for now)

3. How should the message be formatted?

When a human is the recipient, information can be turned into text with 
a template engine (like freemarker).

Information depends on the alert definition, but a default should be 
configurable for convenience.

4. Configuration

Notifiers may expose REST endpoints (with standardized URIs)

- default config: /emailnotifier/configuration

- alert definition level config: /emailnotifier/configuration/1

Example:

{
     "to": ["paul at foobar.com", "alfred at foobar.com"],
     "cc": ["backoffice-mw-ops at foobar.com"],
     "subject": "Pool soon exhausted",
     "mode": "plaintext+html"
     "templates":
         [{
             name: "plaintext",
             uri: "/emailnotifier/configuration/1/templates/plaintext"
         },{
             name: "html",
             uri: "/emailnotifier/configuration/1/templates/html"
         }]
}

- template configs:

Example:

/emailnotifier/configuration/1/templates/plaintext
/emailnotifier/configuration/1/templates/html


I'm still not sure which component should be responsible of loading user 
information when a user (or a group of users) is selected as the recipient.

5. Process

- Alerts sends contextual data on the bus
- Notifier picks it up
- Notifier loads configuration for this alert definition or the default one
- Notifier applies the template (optional)
- Notifier sends email or invoke sender API

6. Storage

There needs to be some shared storage where to bind configuration and 
templates to alert definitions.


Comments?

Regards,
Thomas

From jpkroehling at redhat.com  Fri Feb  6 07:19:51 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 06 Feb 2015 13:19:51 +0100
Subject: [Hawkular-dev] define: tenant
In-Reply-To: <59B00CAD-C38D-4C41-8846-585502D5CB34@redhat.com>
References: <54CA6C3C.9080808@redhat.com>
	<CCE59838-49B1-49D1-9DAD-78F1B82ED4DD@redhat.com>
	<54D24F39.2030305@redhat.com>
	<59B00CAD-C38D-4C41-8846-585502D5CB34@redhat.com>
Message-ID: <54D4B167.4070802@redhat.com>

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

On 02/06/2015 12:54 PM, Heiko W.Rupp wrote:
> I think that makes sense and follows the idea of acme.org and
> foo.acme.org, bar.acme.org

Yes. We'll need to take a closer look once it gets ready, to see if
the rules I made up make sense. For instance, are users of
bar.acme.org supposed to access acme.org? Or just users which are
directly assigned to acme.org? This question can be answered later.

>> if this will work, though. I'm starting to work on this right now
>> on a new module (hawkular-accounts).
> 
> Once you have a little bit of it : can you make it publicly
> available? Perhaps including some drawings :)

Sure, I'm almost done with the basics of the backend and should start
with the UI (with hawt.io) this afternoon. Let's see if I have
something to show next week during a water cooler.

>> If an user makes a REST call to retrieve all metrics that he has 
>> access to, I'd expect that he'd receive both metrics for his pet 
>> projects and metrics for organizations he's part of.
> 
> Now suppose that user creates a dashboard with (graphs of) org
> resources and pet resources and shares (=clones + distributes) that
> to another user. I guess the dashboard would then show those pet
> resources in a bad state (no data, or worse).  Or how could we deal
> with that?

Not sure I follow. You mean the case where I share a graph of a
resource of mine with you? I suppose that this graph would have a
unique URL (/graph/{graphId}), and I could create an organization to
share this graph. Would that work? Another solution could be to tell
the user "this unique URL is unsecured, anyone you share this with
will have access, no matter what".

>> The backend *needs* to check if the current user has access to
>> the resource. Other than that, I'd say it's up to the individual 
>> components (alerts, metrics, inventory, ...) what/how they want
>> to expose data to the consumers. For instance, metrics might want
>> to have
> 
> Well, we should try to be consistent?

Absolutely. But in the end, it's a decision of the component itself.
If there's a situation where breaking consistency makes sense, it's
still possible from the auth/authz perspective.

>> the following REST endpoints:
>> 
>> /{owner}/metrics --> all metrics owned by "owner" (organization
>> or user)
>> 
>> /metrics --> all metrics to which the current user has access to
>> 
> The difference between the above is that the first is "org XOR
> user" resources not "union-or"? While the 2nd one is (org || user)
> - right?

Yes, I'd expect metrics to return only the metrics for a specific
owner on the first case, and all metrics in the second case.

- - Juca.

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

iQEcBAEBAgAGBQJU1LFnAAoJECKM1e+fkPrXrRMH/3bDZH5vUgMcyC8Yw0ULk57I
O2jimv5GrH/xMEpWke1f4GbSrEnqYeNIfH9etO8bTgWNMerjKiwE/jvcOB0rMvq2
TKQm3JOKAokjPowQVaH8o2oHZeddIWoS6P2P6t6W16SztJh+Yp6wl2pe0jMugpvD
JAiSzZ+mhPsm82ICLaB+430cTi3WXwtW/UQhCVx1IHzddEgZG0NTWCFdMP38QafN
tXnLqkvYct2uF9egDjXpijt64S43ayT3dPKapim6FJsBI4uzLtbrULiRm2XL6agN
Ysj9KZ4f/z0ZFEIGV2rLVXbh5tt8fpZBYmWBd1ftr9ZZX80blBnAerG6d5RA0ts=
=wuu9
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Fri Feb  6 08:00:44 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 14:00:44 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <F45E6471-188A-4B33-98AA-FE61E4E10533@redhat.com>
References: <54D33F91.9050202@redhat.com>
	<54D3851F.3050400@redhat.com>	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>	<9553805.Z0D4WbdfI0@localhost.localdomain>	<54D3B758.4080605@redhat.com>
	<F45E6471-188A-4B33-98AA-FE61E4E10533@redhat.com>
Message-ID: <54D4BAFC.80105@redhat.com>

Le 06/02/2015 11:14, Heiko W.Rupp a ?crit :
>
>> Am 05.02.2015 um 19:32 schrieb Jay Shaughnessy <jshaughn at redhat.com>:
>>  From what I can see at the moment H Alerts will depend on H Bus, and be
>> deployed in WFly via the nest.  I see no use case past that at the
>> moment.  As such, using standalone.xml seems like an obvious choice and
>> I expect that's what we'll use.  If and when we ever need to be consumed
>> in another way then we, or the community, could add another
>> configuration option.
>
> Right said Fred
>

OK. Then how should we provide configuration to a deployment then? There 
are two ways I'm aware of:

- System properties defined in standalone.xml

Configuration properties can be read with System.getProperty

- JNDI entries

Configuration properties can be read with @Resource or a programmatic 
lookup.

Any other option?



From crobson at redhat.com  Fri Feb  6 08:14:52 2015
From: crobson at redhat.com (Catherine Robson)
Date: Fri, 06 Feb 2015 08:14:52 -0500
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4B0DA.90202@redhat.com>
References: <54D4B0DA.90202@redhat.com>
Message-ID: <54D4BE4C.7060502@redhat.com>



> Thomas Segismont <mailto:tsegismo at redhat.com>
> February 6, 2015 at 7:17 AM
> Hi,
>
> I've been thinking about the alert notification system lately.
>
> What's the information needed to send a notification?
> How to convert the information into text when a human is the recipient?
> How to configure the system?
> How to make it fit into the Hawkular suite?
>
> 1. Contextual data
>
> A notification has contextual data. Contextual data is comprised of:
> - alert definition data
> - data involved in the trigger (for example metrics and availability 
> values)
Many times there are symptoms of a problem that are seen through 
alerts.  If there are many alerts happening around the same trigger 
time, should we be adding pointers to other potentially related alerts 
to help users diagnose the root cause faster?
>
> 2. Notifier data
>
> 2.1 Who is the recipient?
>
> Email: address
> SMS: phone number
>
> Sometimes the recipient is fixed (for example when sending email to a
> mailing-list).
> Sometimes it should be picked from user information (for example when
> sending emails to a group of users)
>
> This information depends on the alert definition, but a default should
> be configurable for convenience.
Are we considering alert escalation?  Setting up a list that the alerts 
go to by default, and then if they are not resolved by some configurable 
SLA, they are then sent to another group of people to raise the 
awareness of the problem?
>
> 2.2 How should the message be sent?
>
> Email: SMTP address/port and credentials
> SMS: Web service HTTP URL and credentials
>
> The information depends on the tenant (in rare cases, on the alert
> definition, but let's ignore the problem for now)
>
> 3. How should the message be formatted?
>
> When a human is the recipient, information can be turned into text with
> a template engine (like freemarker).
>
> Information depends on the alert definition, but a default should be
> configurable for convenience.
Can we do full HTML format (maybe txt vs. HTML configurable).  It would 
be nice to add links directly into the web console for that resource 
that alerted so users can very quickly click through to investigate the 
problem.
>
> 4. Configuration
>
> Notifiers may expose REST endpoints (with standardized URIs)
>
> - default config: /emailnotifier/configuration
>
> - alert definition level config: /emailnotifier/configuration/1
>
> Example:
>
> {
> "to": ["paul at foobar.com", "alfred at foobar.com"],
> "cc": ["backoffice-mw-ops at foobar.com"],
> "subject": "Pool soon exhausted",
> "mode": "plaintext+html"
> "templates":
> [{
> name: "plaintext",
> uri: "/emailnotifier/configuration/1/templates/plaintext"
> },{
> name: "html",
> uri: "/emailnotifier/configuration/1/templates/html"
> }]
> }
>
> - template configs:
>
> Example:
>
> /emailnotifier/configuration/1/templates/plaintext
> /emailnotifier/configuration/1/templates/html
>
>
> I'm still not sure which component should be responsible of loading user
> information when a user (or a group of users) is selected as the 
> recipient.
>
> 5. Process
>
> - Alerts sends contextual data on the bus
> - Notifier picks it up
> - Notifier loads configuration for this alert definition or the 
> default one
> - Notifier applies the template (optional)
> - Notifier sends email or invoke sender API
>
> 6. Storage
>
> There needs to be some shared storage where to bind configuration and
> templates to alert definitions.
>
>
> Comments?
>
> Regards,
> Thomas
> _______________________________________________
> 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/20150206/77a4004a/attachment-0001.html 
-------------- 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/20150206/77a4004a/attachment-0001.jpg 

From hrupp at redhat.com  Fri Feb  6 08:45:44 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 14:45:44 +0100
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4BE4C.7060502@redhat.com>
References: <54D4B0DA.90202@redhat.com> <54D4BE4C.7060502@redhat.com>
Message-ID: <D8C3AF8B-3568-4DC0-8103-9E38F16B4258@redhat.com>


> Am 06.02.2015 um 14:14 schrieb Catherine Robson <crobson at redhat.com>:
> 
> 
> 
>> 	Thomas Segismont	February 6, 2015 at 7:17 AM
>> Hi,
>> 
>> I've been thinking about the alert notification system lately.
>> 
>> What's the information needed to send a notification?
>> How to convert the information into text when a human is the recipient? 
>> How to configure the system?
>> How to make it fit into the Hawkular suite?
>> 
>> 1. Contextual data
>> 
>> A notification has contextual data. Contextual data is comprised of:
>> - alert definition data
>> - data involved in the trigger (for example metrics and availability values)
> Many times there are symptoms of a problem that are seen through alerts.  If there are many alerts happening around the same trigger time, should we be adding pointers to other potentially related alerts to help users diagnose the root cause faster?

Yes in the medium to long term.

>> be configurable for convenience.
> Are we considering alert escalation?  Setting up a list that the alerts go to by default, and then if they are not resolved by some configurable SLA, they are then sent to another group of people to raise the awareness of the problem?

Yes.

>> 
>> When a human is the recipient, information can be turned into text with 
>> a template engine (like freemarker).
>> 
>> Information depends on the alert definition, but a default should be 
>> configurable for convenience.
> Can we do full HTML format (maybe txt vs. HTML configurable).  It would be nice to add links directly into the web console for that resource that alerted so users can very quickly click through to investigate the problem.

please only do html if explicitly enabled. There are enough admins with text clients, that prefer not to wade through html

With the idea of templates, the user can create templates on html and without. We would provide some defaults, but the
user needs to have the possibility to tailor them to their needs.

>> 
>> 4. Configuration
>> 
>> Notifiers may expose REST endpoints (with standardized URIs)

What for?

>> 6. Storage
>> 
>> There needs to be some shared storage where to bind configuration and 
>> templates to alert definitions.

Can you elaborate?

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

From tsegismo at redhat.com  Fri Feb  6 08:48:11 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 14:48:11 +0100
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4BE4C.7060502@redhat.com>
References: <54D4B0DA.90202@redhat.com> <54D4BE4C.7060502@redhat.com>
Message-ID: <54D4C61B.2040100@redhat.com>

Le 06/02/2015 14:14, Catherine Robson a ?crit :
>
>
>> Thomas Segismont <mailto:tsegismo at redhat.com>
>> February 6, 2015 at 7:17 AM
>> Hi,
>>
>> I've been thinking about the alert notification system lately.
>>
>> What's the information needed to send a notification?
>> How to convert the information into text when a human is the recipient?
>> How to configure the system?
>> How to make it fit into the Hawkular suite?
>>
>> 1. Contextual data
>>
>> A notification has contextual data. Contextual data is comprised of:
>> - alert definition data
>> - data involved in the trigger (for example metrics and availability
>> values)
> Many times there are symptoms of a problem that are seen through
> alerts.  If there are many alerts happening around the same trigger
> time, should we be adding pointers to other potentially related alerts
> to help users diagnose the root cause faster?

I think we should, yes. But I'm not sure it's related to the 
notification system. It's more about the alert system integration with 
inventory (inventory is the service which knows about resources 
relationship).


>>
>> 2. Notifier data
>>
>> 2.1 Who is the recipient?
>>
>> Email: address
>> SMS: phone number
>>
>> Sometimes the recipient is fixed (for example when sending email to a
>> mailing-list).
>> Sometimes it should be picked from user information (for example when
>> sending emails to a group of users)
>>
>> This information depends on the alert definition, but a default should
>> be configurable for convenience.
> Are we considering alert escalation?  Setting up a list that the alerts
> go to by default, and then if they are not resolved by some configurable
> SLA, they are then sent to another group of people to raise the
> awareness of the problem?

Excellent remark. We haven't discussed escalation so far. I need to 
think about how it would impact the notification system.

>>
>> 2.2 How should the message be sent?
>>
>> Email: SMTP address/port and credentials
>> SMS: Web service HTTP URL and credentials
>>
>> The information depends on the tenant (in rare cases, on the alert
>> definition, but let's ignore the problem for now)
>>
>> 3. How should the message be formatted?
>>
>> When a human is the recipient, information can be turned into text with
>> a template engine (like freemarker).
>>
>> Information depends on the alert definition, but a default should be
>> configurable for convenience.
> Can we do full HTML format (maybe txt vs. HTML configurable).  It would
> be nice to add links directly into the web console for that resource
> that alerted so users can very quickly click through to investigate the
> problem.

Yes, HTML output makes sense in the case of email.

In section 4, I've written an example configuration. The "mode" 
attribute tells the email notifier how it should be the email.

"plaintext" -> send a plain text email
"html" -> send an HTML email
"plaintext+html" -> send a multipart email (plaintext part and HTML part)

http://en.wikipedia.org/wiki/HTML_email#Multi-part_formats

In either format, the template can be be made to include a link to the 
alert details in the console.

>>
>> 4. Configuration
>>
>> Notifiers may expose REST endpoints (with standardized URIs)
>>
>> - default config: /emailnotifier/configuration
>>
>> - alert definition level config: /emailnotifier/configuration/1
>>
>> Example:
>>
>> {
>> "to": ["paul at foobar.com", "alfred at foobar.com"],
>> "cc": ["backoffice-mw-ops at foobar.com"],
>> "subject": "Pool soon exhausted",
>> "mode": "plaintext+html"
>> "templates":
>> [{
>> name: "plaintext",
>> uri: "/emailnotifier/configuration/1/templates/plaintext"
>> },{
>> name: "html",
>> uri: "/emailnotifier/configuration/1/templates/html"
>> }]
>> }
>>
>> - template configs:
>>
>> Example:
>>
>> /emailnotifier/configuration/1/templates/plaintext
>> /emailnotifier/configuration/1/templates/html
>>
>>
>> I'm still not sure which component should be responsible of loading user
>> information when a user (or a group of users) is selected as the
>> recipient.
>>
>> 5. Process
>>
>> - Alerts sends contextual data on the bus
>> - Notifier picks it up
>> - Notifier loads configuration for this alert definition or the
>> default one
>> - Notifier applies the template (optional)
>> - Notifier sends email or invoke sender API
>>
>> 6. Storage
>>
>> There needs to be some shared storage where to bind configuration and
>> templates to alert definitions.
>>
>>
>> Comments?
>>
>> Regards,
>> Thomas
>> _______________________________________________
>> 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
>


From mazz at redhat.com  Fri Feb  6 09:12:23 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 Feb 2015 09:12:23 -0500 (EST)
Subject: [Hawkular-dev] integration project
In-Reply-To: <A5AC1495-B8A4-4598-A66B-D4447FC503F1@redhat.com>
References: <AA68ED56-1301-476F-8FD4-76FA2ADEF53B@redhat.com>
	<415096932.7531096.1423166525769.JavaMail.zimbra@redhat.com>
	<BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
	<1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>
	<A5AC1495-B8A4-4598-A66B-D4447FC503F1@redhat.com>
Message-ID: <165659311.7881078.1423231943618.JavaMail.zimbra@redhat.com>

> > Bad news - metrics is broken. When you start, you'll get an exception
> > because it appears the embedded cassandra EAR initializes too late - after
> > the metrics war tries to find C*. You'll get deployment errors due to
> > this.
> 
> As said on the channel already the wildfly-cassandra extension from
> 
> https://github.com/hawkular/wildfly-cassandra

I talked to Stefan and John S. about that - unfortunately (and Stefan/John correct me if I'm wrong) we can't use that because h-metrics needs a later version of C* which wildfly-cassandra does not support.

From theute at redhat.com  Fri Feb  6 09:31:06 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 06 Feb 2015 15:31:06 +0100
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4B0DA.90202@redhat.com>
References: <54D4B0DA.90202@redhat.com>
Message-ID: <54D4D02A.2030309@redhat.com>

Does it need possibility and template for end of alert notification 
(back to normal) ?

In general we need to think about alert lifecycle.

alert is raised at 9am -> situation is back to normal by itself at 10am
or
alert is raised at 9am -> alert is acked at 9:30am (still an issue 
though) and mute the alert for "some time" someone change the alert 
definition, delete it or fix the actual issue -> situation is back to 
normal at 10am

For the 1 case there would be 2 notifications I guess. For the case 2, 
we may want to let others know if it's a distribution list ("bob as 
acked the alert, you can ignore")

In both cases this should likely create an "event" from 9am to 10am that 
is displayed in the UI console (which is another kind of notification).


Thomas

On 02/06/2015 01:17 PM, Thomas Segismont wrote:
> Hi,
>
> I've been thinking about the alert notification system lately.
>
> What's the information needed to send a notification?
> How to convert the information into text when a human is the recipient?
> How to configure the system?
> How to make it fit into the Hawkular suite?
>
> 1. Contextual data
>
> A notification has contextual data. Contextual data is comprised of:
> - alert definition data
> - data involved in the trigger (for example metrics and availability values)
>
> 2. Notifier data
>
> 2.1 Who is the recipient?
>
> Email: address
> SMS: phone number
>
> Sometimes the recipient is fixed (for example when sending email to a
> mailing-list).
> Sometimes it should be picked from user information (for example when
> sending emails to a group of users)
>
> This information depends on the alert definition, but a default should
> be configurable for convenience.
>
> 2.2 How should the message be sent?
>
> Email: SMTP address/port and credentials
> SMS: Web service HTTP URL and credentials
>
> The information depends on the tenant (in rare cases, on the alert
> definition, but let's ignore the problem for now)
>
> 3. How should the message be formatted?
>
> When a human is the recipient, information can be turned into text with
> a template engine (like freemarker).
>
> Information depends on the alert definition, but a default should be
> configurable for convenience.
>
> 4. Configuration
>
> Notifiers may expose REST endpoints (with standardized URIs)
>
> - default config: /emailnotifier/configuration
>
> - alert definition level config: /emailnotifier/configuration/1
>
> Example:
>
> {
>       "to": ["paul at foobar.com", "alfred at foobar.com"],
>       "cc": ["backoffice-mw-ops at foobar.com"],
>       "subject": "Pool soon exhausted",
>       "mode": "plaintext+html"
>       "templates":
>           [{
>               name: "plaintext",
>               uri: "/emailnotifier/configuration/1/templates/plaintext"
>           },{
>               name: "html",
>               uri: "/emailnotifier/configuration/1/templates/html"
>           }]
> }
>
> - template configs:
>
> Example:
>
> /emailnotifier/configuration/1/templates/plaintext
> /emailnotifier/configuration/1/templates/html
>
>
> I'm still not sure which component should be responsible of loading user
> information when a user (or a group of users) is selected as the recipient.
>
> 5. Process
>
> - Alerts sends contextual data on the bus
> - Notifier picks it up
> - Notifier loads configuration for this alert definition or the default one
> - Notifier applies the template (optional)
> - Notifier sends email or invoke sender API
>
> 6. Storage
>
> There needs to be some shared storage where to bind configuration and
> templates to alert definitions.
>
>
> Comments?
>
> 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  Fri Feb  6 09:14:02 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 06 Feb 2015 15:14:02 +0100
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <D8C3AF8B-3568-4DC0-8103-9E38F16B4258@redhat.com>
References: <54D4B0DA.90202@redhat.com> <54D4BE4C.7060502@redhat.com>
	<D8C3AF8B-3568-4DC0-8103-9E38F16B4258@redhat.com>
Message-ID: <54D4CC2A.6000302@redhat.com>

Le 06/02/2015 14:45, Heiko W.Rupp a ?crit :
>
>>>
>>> 4. Configuration
>>>
>>> Notifiers may expose REST endpoints (with standardized URIs)
>
> What for?

To expose and receive configuration related to an alert definition.

One of the components (alerts or notifier) needs to know the details for 
sending the notification. In the case email notification case:
- who should be in the "to" list
- who should be in the "cc" list
- email subject
- email format (plain text, html, multipart)
- content template(s)

I was thinking that this data should be managed by the notification module.

>
>>> 6. Storage
>>>
>>> There needs to be some shared storage where to bind configuration and
>>> templates to alert definitions.
>
> Can you elaborate?
>

If the details for sending the notification are managed by the 
notification module, then it must be able to store and load it. For 
prototyping it can be memory or DefaultDS, but at some point we might 
have multiple instances of the same notifier picking up notification 
messages. Or just one instance which could run on server A until server 
A crashed and server B is started for backup.


From mazz at redhat.com  Fri Feb  6 10:08:59 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 Feb 2015 10:08:59 -0500 (EST)
Subject: [Hawkular-dev] REST endpoints are multiplying
In-Reply-To: <47776053.7939070.1423235265691.JavaMail.zimbra@redhat.com>
Message-ID: <1746932452.7939640.1423235339365.JavaMail.zimbra@redhat.com>

I see all the components implementing REST APIs.

How will that scale if we cluster multiple components? Are we going to ask people to install and configure a load balancer? Is there another way to make client configuration easier? Because as I see it, unless clients are told of all the different endpoints of all the different REST servers, how will they know where to go to talk REST to these components? Even if we have load balancers, they will still need to know "here's the REST URL for alerts, here's the REST URL for metrics, here's the REST URL for inventory."


From hrupp at redhat.com  Fri Feb  6 10:24:46 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 16:24:46 +0100
Subject: [Hawkular-dev] REST endpoints are multiplying
In-Reply-To: <1746932452.7939640.1423235339365.JavaMail.zimbra@redhat.com>
References: <1746932452.7939640.1423235339365.JavaMail.zimbra@redhat.com>
Message-ID: <C0105ECB-7171-4F25-9209-661C7B3A9ADE@redhat.com>

Not sure I understood you correctly, as I have some issues concentrating right now.

Usually rest-apis are build around the concept of

* one well known entry point
* linking of resources.

So basically there is e.g.

GET /hawkular

which returns

{
  {"rel":"metrics", "url":"/metrics",
   "rel":"alerts","url":/alerts", 
  ...
}
and then on e.g. a single resource there is

{ 
  "rel":"alerts", "url":/alerts/1234/"
} 

and so on.

Like on a web page, but with links for machines.

The urls returned can be relative or also absolute. There may be some details to solve,but the general
concept is built into the REST-way already.


> Am 06.02.2015 um 16:08 schrieb John Mazzitelli <mazz at redhat.com>:
> 
> I see all the components implementing REST APIs.
> 
> How will that scale if we cluster multiple components? Are we going to ask people to install and configure a load balancer? Is there another way to make client configuration easier? Because as I see it, unless clients are told of all the different endpoints of all the different REST servers, how will they know where to go to talk REST to these components? Even if we have load balancers, they will still need to know "here's the REST URL for alerts, here's the REST URL for metrics, here's the REST URL for inventory."
> 
> _______________________________________________
> 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 mazz at redhat.com  Fri Feb  6 10:49:24 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 Feb 2015 10:49:24 -0500 (EST)
Subject: [Hawkular-dev] REST endpoints are multiplying
In-Reply-To: <C0105ECB-7171-4F25-9209-661C7B3A9ADE@redhat.com>
References: <1746932452.7939640.1423235339365.JavaMail.zimbra@redhat.com>
	<C0105ECB-7171-4F25-9209-661C7B3A9ADE@redhat.com>
Message-ID: <815752910.7968751.1423237764586.JavaMail.zimbra@redhat.com>

> Not sure I understood you correctly, as I have some issues concentrating
> right now.

The thing I'm wondering about is - how do the clients of our components know what the REST URLs are for the different components?

For example, suppose we have a cluster of two h-inventory servers - one is running on host1 and another on host2. They both have a REST endpoint (http://host1/hawkular-inventory and http://host2/hawkular-inventory).

Where do we tell clients to talk to? host1? What if host1 goes down? How do they know about host2. How do we effectively spread the load so all clients don't hit host1's REST endpoint leaving host2's REST server under-utilized?

Now add in the other components - what if we have multiple machines running alerts? Multiple running metrics?

In the case of the bus, it doesn't matter if we run multiple ones of those because there is a failover protocol and a networking of auto-discovered brokers that allow a client to point to a single server and have the brokers and the failover protocol deal with clusters and failover scenarios. The h-bus also has a REST endpoint, too, but then again, any client can point to any bus REST endpoint, send a message to the bus, and that message will get to where it needs to go whether the message listener is living on that same machine as the REST endpoint or another machine.

Aside from the bus then, are we going to ask people to install and configure load balancers in front of these other components? Or do we ask them to somehow configure the clients with all the different REST URLs and somehow balance the load?

Hopefully, that made sense. I'm just wondering how everyone will know where all the REST URLs are going to be and how we support clusters and failover scenarios (other than the bus component).

----- Original Message -----
> Not sure I understood you correctly, as I have some issues concentrating
> right now.
> 
> Usually rest-apis are build around the concept of
> 
> * one well known entry point
> * linking of resources.
> 
> So basically there is e.g.
> 
> GET /hawkular
> 
> which returns
> 
> {
>   {"rel":"metrics", "url":"/metrics",
>    "rel":"alerts","url":/alerts",
>   ...
> }
> and then on e.g. a single resource there is
> 
> {
>   "rel":"alerts", "url":/alerts/1234/"
> }
> 
> and so on.
> 
> Like on a web page, but with links for machines.
> 
> The urls returned can be relative or also absolute. There may be some details
> to solve,but the general
> concept is built into the REST-way already.
> 
> 
> > Am 06.02.2015 um 16:08 schrieb John Mazzitelli <mazz at redhat.com>:
> > 
> > I see all the components implementing REST APIs.
> > 
> > How will that scale if we cluster multiple components? Are we going to ask
> > people to install and configure a load balancer? Is there another way to
> > make client configuration easier? Because as I see it, unless clients are
> > told of all the different endpoints of all the different REST servers, how
> > will they know where to go to talk REST to these components? Even if we
> > have load balancers, they will still need to know "here's the REST URL for
> > alerts, here's the REST URL for metrics, here's the REST URL for
> > inventory."
> > 
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jshaughn at redhat.com  Fri Feb  6 11:04:42 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 06 Feb 2015 11:04:42 -0500
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4C61B.2040100@redhat.com>
References: <54D4B0DA.90202@redhat.com> <54D4BE4C.7060502@redhat.com>
	<54D4C61B.2040100@redhat.com>
Message-ID: <54D4E61A.20705@redhat.com>


In Hawkular AlertDefintion -> Trigger.  Other comments inline...

On 2/6/2015 8:48 AM, Thomas Segismont wrote:
> Le 06/02/2015 14:14, Catherine Robson a ?crit :
>>
>>> Thomas Segismont <mailto:tsegismo at redhat.com>
>>> February 6, 2015 at 7:17 AM
>>> Hi,
>>>
>>> I've been thinking about the alert notification system lately.
>>>
>>> What's the information needed to send a notification?
>>> How to convert the information into text when a human is the recipient?
>>> How to configure the system?
>>> How to make it fit into the Hawkular suite?
>>>
>>> 1. Contextual data
>>>
>>> A notification has contextual data. Contextual data is comprised of:
>>> - alert definition data
>>> - data involved in the trigger (for example metrics and availability
>>> values)
>> Many times there are symptoms of a problem that are seen through
>> alerts.  If there are many alerts happening around the same trigger
>> time, should we be adding pointers to other potentially related alerts
>> to help users diagnose the root cause faster?
> I think we should, yes. But I'm not sure it's related to the
> notification system. It's more about the alert system integration with
> inventory (inventory is the service which knows about resources
> relationship).

Definitely could be useful.  I agree with Heiko somewhat, in that I 
think it may fall outside of alerting and likely more into a 
presentation layer feature.

>
>
>>> 2. Notifier data
>>>
>>> 2.1 Who is the recipient?
>>>
>>> Email: address
>>> SMS: phone number
>>>
>>> Sometimes the recipient is fixed (for example when sending email to a
>>> mailing-list).
>>> Sometimes it should be picked from user information (for example when
>>> sending emails to a group of users)
>>>
>>> This information depends on the alert definition, but a default should
>>> be configurable for convenience.
>> Are we considering alert escalation?  Setting up a list that the alerts
>> go to by default, and then if they are not resolved by some configurable
>> SLA, they are then sent to another group of people to raise the
>> awareness of the problem?
> Excellent remark. We haven't discussed escalation so far. I need to
> think about how it would impact the notification system.
>
>>> 2.2 How should the message be sent?
>>>
>>> Email: SMTP address/port and credentials
>>> SMS: Web service HTTP URL and credentials
>>>
>>> The information depends on the tenant (in rare cases, on the alert
>>> definition, but let's ignore the problem for now)
>>>
>>> 3. How should the message be formatted?
>>>
>>> When a human is the recipient, information can be turned into text with
>>> a template engine (like freemarker).
>>>
>>> Information depends on the alert definition, but a default should be
>>> configurable for convenience.
>> Can we do full HTML format (maybe txt vs. HTML configurable).  It would
>> be nice to add links directly into the web console for that resource
>> that alerted so users can very quickly click through to investigate the
>> problem.
> Yes, HTML output makes sense in the case of email.
>
> In section 4, I've written an example configuration. The "mode"
> attribute tells the email notifier how it should be the email.
>
> "plaintext" -> send a plain text email
> "html" -> send an HTML email
> "plaintext+html" -> send a multipart email (plaintext part and HTML part)
>
> http://en.wikipedia.org/wiki/HTML_email#Multi-part_formats
>
> In either format, the template can be be made to include a link to the
> alert details in the console.

The Alert will provide only the most basic information, whatever the 
Alerting system can provide.  For the most part that will be the Trigger 
information and the triggering data.  The out-of-box notifiers will 
forward only that information.  For Hawkular/Inventory, we'll want to 
provide extended notifiers that can take that data and decorate it with 
more context.  For example, If we trigger on DataId X > 50.  The default 
notifier would report just that.  But an extended notifier, one that 
knows about inventory, could query to find out which metric ID is X, and 
from there get the resource info, etc.

>
>>> 4. Configuration
>>>
>>> Notifiers may expose REST endpoints (with standardized URIs)
>>>
>>> - default config: /emailnotifier/configuration
>>>
>>> - alert definition level config: /emailnotifier/configuration/1
>>>
>>> Example:
>>>
>>> {
>>> "to": ["paul at foobar.com", "alfred at foobar.com"],
>>> "cc": ["backoffice-mw-ops at foobar.com"],
>>> "subject": "Pool soon exhausted",
>>> "mode": "plaintext+html"
>>> "templates":
>>> [{
>>> name: "plaintext",
>>> uri: "/emailnotifier/configuration/1/templates/plaintext"
>>> },{
>>> name: "html",
>>> uri: "/emailnotifier/configuration/1/templates/html"
>>> }]
>>> }
>>>
>>> - template configs:
>>>
>>> Example:
>>>
>>> /emailnotifier/configuration/1/templates/plaintext
>>> /emailnotifier/configuration/1/templates/html
>>>
>>>
>>> I'm still not sure which component should be responsible of loading user
>>> information when a user (or a group of users) is selected as the
>>> recipient.

I'm not so sure about the REST endpoints but this is something we need 
to discuss further for sure.  We'll likely want some standard format for 
the notifier configuration, something we can easily supply 
programmatically or via a standard GUI component.  And that config 
information will need to be tagged onto the Trigger so it can be applied 
to the generated Alerts.


>>>
>>> 5. Process
>>>
>>> - Alerts sends contextual data on the bus
>>> - Notifier picks it up
>>> - Notifier loads configuration for this alert definition or the
>>> default one
>>> - Notifier applies the template (optional)
>>> - Notifier sends email or invoke sender API

I think the entire Alert should likely be put on the bus, and configured 
notifiers subscribe to the Alerts topic and consume the Alerts for which 
they are relevant.  This is not the way it is currently set up in the 
code, but is an approach I think we should consider.   Also, I'm not 
sure about the need for template configurations, but maybe.


>>> 6. Storage
>>>
>>> There needs to be some shared storage where to bind configuration and
>>> templates to alert definitions.

For now I think we should probably look to H2 for persistence.



From jshaughn at redhat.com  Fri Feb  6 11:12:48 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 06 Feb 2015 11:12:48 -0500
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4D02A.2030309@redhat.com>
References: <54D4B0DA.90202@redhat.com> <54D4D02A.2030309@redhat.com>
Message-ID: <54D4E800.40902@redhat.com>


This is a good overall topic for discussion, how far we want to go with 
Alert management in H-Alerts.   At the moment we haven't entered this 
arena at all.  We are just firing Triggers, generating Alerts, and 
presumably handing them off to Notifiers to do what they wish.   We 
currently don't even persist the Alerts but that will likely come next, 
along with whatever post-notification handling we want to provide.   
Lifecycle, ack, duration, etc is all pending.  As is any kind of 
auto-disable/enable of Triggers, a la recovery alerting in RHQ.

On 2/6/2015 9:31 AM, Thomas Heute wrote:
> Does it need possibility and template for end of alert notification
> (back to normal) ?
>
> In general we need to think about alert lifecycle.
>
> alert is raised at 9am -> situation is back to normal by itself at 10am
> or
> alert is raised at 9am -> alert is acked at 9:30am (still an issue
> though) and mute the alert for "some time" someone change the alert
> definition, delete it or fix the actual issue -> situation is back to
> normal at 10am
>
> For the 1 case there would be 2 notifications I guess. For the case 2,
> we may want to let others know if it's a distribution list ("bob as
> acked the alert, you can ignore")
>
> In both cases this should likely create an "event" from 9am to 10am that
> is displayed in the UI console (which is another kind of notification).
>
>
> Thomas
>
> On 02/06/2015 01:17 PM, Thomas Segismont wrote:
>> Hi,
>>
>> I've been thinking about the alert notification system lately.
>>
>> What's the information needed to send a notification?
>> How to convert the information into text when a human is the recipient?
>> How to configure the system?
>> How to make it fit into the Hawkular suite?
>>
>> 1. Contextual data
>>
>> A notification has contextual data. Contextual data is comprised of:
>> - alert definition data
>> - data involved in the trigger (for example metrics and availability values)
>>
>> 2. Notifier data
>>
>> 2.1 Who is the recipient?
>>
>> Email: address
>> SMS: phone number
>>
>> Sometimes the recipient is fixed (for example when sending email to a
>> mailing-list).
>> Sometimes it should be picked from user information (for example when
>> sending emails to a group of users)
>>
>> This information depends on the alert definition, but a default should
>> be configurable for convenience.
>>
>> 2.2 How should the message be sent?
>>
>> Email: SMTP address/port and credentials
>> SMS: Web service HTTP URL and credentials
>>
>> The information depends on the tenant (in rare cases, on the alert
>> definition, but let's ignore the problem for now)
>>
>> 3. How should the message be formatted?
>>
>> When a human is the recipient, information can be turned into text with
>> a template engine (like freemarker).
>>
>> Information depends on the alert definition, but a default should be
>> configurable for convenience.
>>
>> 4. Configuration
>>
>> Notifiers may expose REST endpoints (with standardized URIs)
>>
>> - default config: /emailnotifier/configuration
>>
>> - alert definition level config: /emailnotifier/configuration/1
>>
>> Example:
>>
>> {
>>        "to": ["paul at foobar.com", "alfred at foobar.com"],
>>        "cc": ["backoffice-mw-ops at foobar.com"],
>>        "subject": "Pool soon exhausted",
>>        "mode": "plaintext+html"
>>        "templates":
>>            [{
>>                name: "plaintext",
>>                uri: "/emailnotifier/configuration/1/templates/plaintext"
>>            },{
>>                name: "html",
>>                uri: "/emailnotifier/configuration/1/templates/html"
>>            }]
>> }
>>
>> - template configs:
>>
>> Example:
>>
>> /emailnotifier/configuration/1/templates/plaintext
>> /emailnotifier/configuration/1/templates/html
>>
>>
>> I'm still not sure which component should be responsible of loading user
>> information when a user (or a group of users) is selected as the recipient.
>>
>> 5. Process
>>
>> - Alerts sends contextual data on the bus
>> - Notifier picks it up
>> - Notifier loads configuration for this alert definition or the default one
>> - Notifier applies the template (optional)
>> - Notifier sends email or invoke sender API
>>
>> 6. Storage
>>
>> There needs to be some shared storage where to bind configuration and
>> templates to alert definitions.
>>
>>
>> Comments?
>>
>> Regards,
>> Thomas
>> _______________________________________________
>> 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 Feb  6 11:14:17 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 6 Feb 2015 17:14:17 +0100
Subject: [Hawkular-dev] Fwd: [wildfly-dev] Administrator Encouragement
References: <54D33125.3050109@jboss.com>
Message-ID: <BAF84772-65AD-46F0-A0AA-757B1DC9D79F@redhat.com>

Interesting mail on wildfly-dev 

> Anfang der weitergeleiteten Nachricht:
> 
> Datum: 5. Februar 2015 10:00:21 MEZ
> Von: Darran Lofthouse <darran.lofthouse at jboss.com>
> An: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> Betreff: [wildfly-dev] Administrator Encouragement
> 
> Last week a few of us started talking about the possibility of adding a 
> capability to WildFly that for want of a better name I was calling 
> "Administrator Encouragement".
> 
> I am not looking for this to be a design thread, that can come later but 
> the general principal was that subsystems could register warnings with 
> some kind of central service that admin tools could then retrieve later 
> to advise administrators that some configuration could be required to 
> improve their installation.  Warnings would potentially have a severity 
> level and tooling would potentially have the option to guide the user to 
> the correct place to resolve the issue.
> 
> Anyway the purpose of this thread is that I wanted to try and gather 
> together the kinds of warnings that we could be outputting, below is a 
> list of some I have thought of already but would be interested in 
> hearing any additional ideas.
> 
>  - SSL is not configured.
>  - SSL certificates are due to expire.
>  - Plain text password detected in the configuration.
>  - Some form of file based storage in use but growing beyond intended size.
>  - Default node name  has not been changed.
>  - Patches available but not applied, subsequent releases available.
> 
> Anyway these are just a few ideas and interested in hearing any more.
> 
> Regards,
> Darran Lofthouse.
> _______________________________________________
> 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 jdoyle at redhat.com  Fri Feb  6 14:52:25 2015
From: jdoyle at redhat.com (John Doyle)
Date: Fri, 6 Feb 2015 14:52:25 -0500 (EST)
Subject: [Hawkular-dev] Fwd: [wildfly-dev] Administrator Encouragement
In-Reply-To: <BAF84772-65AD-46F0-A0AA-757B1DC9D79F@redhat.com>
References: <54D33125.3050109@jboss.com>
	<BAF84772-65AD-46F0-A0AA-757B1DC9D79F@redhat.com>
Message-ID: <834887738.9282652.1423252345246.JavaMail.zimbra@redhat.com>

I like the concept that subsystems can provided notifications to a central system.  I have to imagine that's going to result in more and better warnings than if an external systems is responsible for monitoring all subsystems and creating warnings.  But it only covers use cases where the subsystem has all the data it needs.  There's still a place for a higher order of analysis.

That central system should also provide an API for external systems rather than just report warnings through the WF GUI.

~john

----- Original Message -----
> Interesting mail on wildfly-dev
> 
> > Anfang der weitergeleiteten Nachricht:
> > 
> > Datum: 5. Februar 2015 10:00:21 MEZ
> > Von: Darran Lofthouse <darran.lofthouse at jboss.com>
> > An: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> > Betreff: [wildfly-dev] Administrator Encouragement
> > 
> > Last week a few of us started talking about the possibility of adding a
> > capability to WildFly that for want of a better name I was calling
> > "Administrator Encouragement".
> > 
> > I am not looking for this to be a design thread, that can come later but
> > the general principal was that subsystems could register warnings with
> > some kind of central service that admin tools could then retrieve later
> > to advise administrators that some configuration could be required to
> > improve their installation.  Warnings would potentially have a severity
> > level and tooling would potentially have the option to guide the user to
> > the correct place to resolve the issue.
> > 
> > Anyway the purpose of this thread is that I wanted to try and gather
> > together the kinds of warnings that we could be outputting, below is a
> > list of some I have thought of already but would be interested in
> > hearing any additional ideas.
> > 
> >  - SSL is not configured.
> >  - SSL certificates are due to expire.
> >  - Plain text password detected in the configuration.
> >  - Some form of file based storage in use but growing beyond intended size.
> >  - Default node name  has not been changed.
> >  - Patches available but not applied, subsequent releases available.
> > 
> > Anyway these are just a few ideas and interested in hearing any more.
> > 
> > Regards,
> > Darran Lofthouse.
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From mazz at redhat.com  Fri Feb  6 15:49:42 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 Feb 2015 15:49:42 -0500 (EST)
Subject: [Hawkular-dev] Fwd: [wildfly-dev] Administrator Encouragement
In-Reply-To: <834887738.9282652.1423252345246.JavaMail.zimbra@redhat.com>
References: <54D33125.3050109@jboss.com>
	<BAF84772-65AD-46F0-A0AA-757B1DC9D79F@redhat.com>
	<834887738.9282652.1423252345246.JavaMail.zimbra@redhat.com>
Message-ID: <739360686.8088066.1423255782366.JavaMail.zimbra@redhat.com>

This sounds awfully similar to my Hawkular "audit" component I've been prototyping  :)

https://github.com/jmazzitelli/hawkular-audit

In short, its just sitting on the bus listening for audit events (these audit events can come over JMS or through REST, such as I demoed a few weeks ago with curl on the command line submitting an audit event) and when received, those audit events are simply stored to a backend datastore for later retrieval by whatever we want (GUI front end, reporting tool, etc).

----- Original Message -----
> I like the concept that subsystems can provided notifications to a central
> system.  I have to imagine that's going to result in more and better
> warnings than if an external systems is responsible for monitoring all
> subsystems and creating warnings.  But it only covers use cases where the
> subsystem has all the data it needs.  There's still a place for a higher
> order of analysis.
> 
> That central system should also provide an API for external systems rather
> than just report warnings through the WF GUI.
> 
> ~john
> 
> ----- Original Message -----
> > Interesting mail on wildfly-dev
> > 
> > > Anfang der weitergeleiteten Nachricht:
> > > 
> > > Datum: 5. Februar 2015 10:00:21 MEZ
> > > Von: Darran Lofthouse <darran.lofthouse at jboss.com>
> > > An: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> > > Betreff: [wildfly-dev] Administrator Encouragement
> > > 
> > > Last week a few of us started talking about the possibility of adding a
> > > capability to WildFly that for want of a better name I was calling
> > > "Administrator Encouragement".
> > > 
> > > I am not looking for this to be a design thread, that can come later but
> > > the general principal was that subsystems could register warnings with
> > > some kind of central service that admin tools could then retrieve later
> > > to advise administrators that some configuration could be required to
> > > improve their installation.  Warnings would potentially have a severity
> > > level and tooling would potentially have the option to guide the user to
> > > the correct place to resolve the issue.
> > > 
> > > Anyway the purpose of this thread is that I wanted to try and gather
> > > together the kinds of warnings that we could be outputting, below is a
> > > list of some I have thought of already but would be interested in
> > > hearing any additional ideas.
> > > 
> > >  - SSL is not configured.
> > >  - SSL certificates are due to expire.
> > >  - Plain text password detected in the configuration.
> > >  - Some form of file based storage in use but growing beyond intended
> > >  size.
> > >  - Default node name  has not been changed.
> > >  - Patches available but not applied, subsequent releases available.
> > > 
> > > Anyway these are just a few ideas and interested in hearing any more.
> > > 
> > > Regards,
> > > Darran Lofthouse.
> > > _______________________________________________
> > > 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
> > 
> > 
> > _______________________________________________
> > 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  Fri Feb  6 15:52:31 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 Feb 2015 15:52:31 -0500 (EST)
Subject: [Hawkular-dev] Fwd: [wildfly-dev] Administrator Encouragement
In-Reply-To: <739360686.8088066.1423255782366.JavaMail.zimbra@redhat.com>
References: <54D33125.3050109@jboss.com>
	<BAF84772-65AD-46F0-A0AA-757B1DC9D79F@redhat.com>
	<834887738.9282652.1423252345246.JavaMail.zimbra@redhat.com>
	<739360686.8088066.1423255782366.JavaMail.zimbra@redhat.com>
Message-ID: <989987301.8088935.1423255951984.JavaMail.zimbra@redhat.com>

BTW: this is very simple to implement (the audit WAR I don't think is even 50K) and it deploys in the hawkular nest module extension that is deployed in Wildfly as just another subsystem along with the bus infrastructure (which itself is just another bus subsystem). Right now the prototype uses an in-memory H2 DB for simplicity's sake, but its pluggable so you can store the audit events anywhere (I have a listener that merely logs the events in the jboss log file, as an example - but we can store them in a real RDBMS too).

----- Original Message -----
> This sounds awfully similar to my Hawkular "audit" component I've been
> prototyping  :)
> 
> https://github.com/jmazzitelli/hawkular-audit
> 
> In short, its just sitting on the bus listening for audit events (these audit
> events can come over JMS or through REST, such as I demoed a few weeks ago
> with curl on the command line submitting an audit event) and when received,
> those audit events are simply stored to a backend datastore for later
> retrieval by whatever we want (GUI front end, reporting tool, etc).
> 
> ----- Original Message -----
> > I like the concept that subsystems can provided notifications to a central
> > system.  I have to imagine that's going to result in more and better
> > warnings than if an external systems is responsible for monitoring all
> > subsystems and creating warnings.  But it only covers use cases where the
> > subsystem has all the data it needs.  There's still a place for a higher
> > order of analysis.
> > 
> > That central system should also provide an API for external systems rather
> > than just report warnings through the WF GUI.
> > 
> > ~john
> > 
> > ----- Original Message -----
> > > Interesting mail on wildfly-dev
> > > 
> > > > Anfang der weitergeleiteten Nachricht:
> > > > 
> > > > Datum: 5. Februar 2015 10:00:21 MEZ
> > > > Von: Darran Lofthouse <darran.lofthouse at jboss.com>
> > > > An: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> > > > Betreff: [wildfly-dev] Administrator Encouragement
> > > > 
> > > > Last week a few of us started talking about the possibility of adding a
> > > > capability to WildFly that for want of a better name I was calling
> > > > "Administrator Encouragement".
> > > > 
> > > > I am not looking for this to be a design thread, that can come later
> > > > but
> > > > the general principal was that subsystems could register warnings with
> > > > some kind of central service that admin tools could then retrieve later
> > > > to advise administrators that some configuration could be required to
> > > > improve their installation.  Warnings would potentially have a severity
> > > > level and tooling would potentially have the option to guide the user
> > > > to
> > > > the correct place to resolve the issue.
> > > > 
> > > > Anyway the purpose of this thread is that I wanted to try and gather
> > > > together the kinds of warnings that we could be outputting, below is a
> > > > list of some I have thought of already but would be interested in
> > > > hearing any additional ideas.
> > > > 
> > > >  - SSL is not configured.
> > > >  - SSL certificates are due to expire.
> > > >  - Plain text password detected in the configuration.
> > > >  - Some form of file based storage in use but growing beyond intended
> > > >  size.
> > > >  - Default node name  has not been changed.
> > > >  - Patches available but not applied, subsequent releases available.
> > > > 
> > > > Anyway these are just a few ideas and interested in hearing any more.
> > > > 
> > > > Regards,
> > > > Darran Lofthouse.
> > > > _______________________________________________
> > > > 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
> > > 
> > > 
> > > _______________________________________________
> > > 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 mithomps at redhat.com  Fri Feb  6 17:28:42 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 6 Feb 2015 14:28:42 -0800
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
Message-ID: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>

Agenda Item: Hawkular Website (http://hawkular.github.io/ <http://hawkular.github.io/>)

Now that we officially have a Hawkular web presence, maybe we should chat about what we would like to see here. I?m sure everyone has opinions and it would be nice to get them out in a open discussion. Especially since this will be the launcher for our MVP.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150206/65e25e10/attachment.html 

From ike.braun at googlemail.com  Sun Feb  8 02:17:14 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Sun, 8 Feb 2015 08:17:14 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <54D22C8E.30601@redhat.com>
References: <54C28AE2.3010509@redhat.com> <54C601D9.9030102@redhat.com>
	<54C75B94.8080103@redhat.com> <54C79ECF.7020109@redhat.com>
	<54CA1768.8050105@redhat.com> <54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com> <54CB6964.10905@redhat.com>
	<54D21A28.2030405@redhat.com>
	<D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>
	<54D22C8E.30601@redhat.com>
Message-ID: <F8BAF729-23F2-4C4C-A1DF-C918C72E301B@googlemail.com>

I did assume that the communication between hawkular components is not limited to HTTP. How would you secure the communication when another protocol is used?

Maybe this question helps to look at security requirements within hawkular on an abstract level. 

What security requirements exist? What communication channels need to be secured? 

Maybe you'll find that keycloak only addresses part of the requirements. This will impact the question wether or not to make it a technological constraint.

/HeikoB



> Am 04.02.2015 um 15:28 schrieb Juraci Paix?o Kr?hling <jpkroehling at redhat.com>:
> 
> No. Keycloak is a "super OAuth" solution, and that's on top of HTTP.
> What kind of other authentication mechanisms are you thinking about?


From ppalaga at redhat.com  Mon Feb  9 02:38:46 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 09 Feb 2015 08:38:46 +0100
Subject: [Hawkular-dev] Hawkular Migration - RHQ Metrics
In-Reply-To: <793203187.6099976.1423205623405.JavaMail.zimbra@redhat.com>
References: <1570201958.5941384.1423172085417.JavaMail.zimbra@redhat.com>
	<793203187.6099976.1423205623405.JavaMail.zimbra@redhat.com>
Message-ID: <54D86406.8020506@redhat.com>


Hi Stefan,

not sure if it is somehow implicitly present in your plan but anyway, 
you wanted to merge 
https://github.com/hawkular/hawkular-metrics/pull/139 once Metrics 0.2.7 
is released. Please note that the PR can be thrown away if you already 
you started with 6).

Best,

-- Peter

On 02/06/2015 07:53 AM, Stefan Negrea wrote:
> Hello Everybody,
>
> Steps 1 through 5 have been completed from the plan below.
>
> Here are the URLs of newly migrated repositories:
>
> 1) Metrics: https://github.com/hawkular/hawkular-metrics
> 2) Metrics Openshift Cartridge: https://github.com/hawkular/hawkular-metrics-openshift
> 3) Charts: https://github.com/hawkular/hawkular-charts
> 4) Wildfly Cassandra Extension: https://github.com/hawkular/wildfly-cassandra
> 5) Widlfly Monitor: https://github.com/hawkular/wildfly-monitor
>
> With the exception of Hawkular Charts, the only local action needed is to update the remote git URL. For Hawkular Charts, please clone the new repository.
>
> Will continue with rest of the steps tomorrow.
>
>
> Thank you,
> Stefan
>
>
> ----- Original Message -----
>> From: "Stefan Negrea" <snegrea at redhat.com>
>> To: "rhq-devel" <rhq-devel at lists.fedorahosted.org>, hawkular-dev at lists.jboss.org
>> Sent: Thursday, February 5, 2015 3:34:45 PM
>> Subject: [Hawkular-dev] Hawkular Migration - RHQ Metrics
>>
>> Hello Everybody,
>>
>> Here is the plan migrating RHQ Metrics and related projects to Hawkular
>> organization (timeline in chronological order):
>>
>> 1) Remove access to rhq-metrics-openshift, rhq-metrics, rhqm-charts, and
>> wildfly-cassandra repositories
>> 2) Transfer rhq-metrics-openshift, rhq-metrics, and widlfly-cassandra to the
>> Hawkular organization
>> 3) Replace the README.md for rhqm-charts with a link to the new Hawkular
>> repository
>> 4) Rename rhq-metrics-openshift and rhq-metrics repositories to reflect the
>> new organization
>> 5) Create new teams inside the new organization for write access to the
>> migrated repositories
>> 6) Update files inside the migrated repositories to reflect the new name
>> 7) Re-organize the metrics project modules
>>
>> I will start the migration tonight to have minimum impact on development. I
>> will send updated links after all repositories get fully migrated.
>>
>>
>> Thank you,
>> Stefan Negrea
>>
>> Software Engineer
>>
>> _______________________________________________
>> 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 ike.braun at googlemail.com  Mon Feb  9 03:05:42 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Mon, 9 Feb 2015 09:05:42 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <54D4BAFC.80105@redhat.com>
References: <54D33F91.9050202@redhat.com> <54D3851F.3050400@redhat.com>
	<120669201.7360516.1423149953758.JavaMail.zimbra@redhat.com>
	<9553805.Z0D4WbdfI0@localhost.localdomain>
	<54D3B758.4080605@redhat.com>
	<F45E6471-188A-4B33-98AA-FE61E4E10533@redhat.com>
	<54D4BAFC.80105@redhat.com>
Message-ID: <B517795E-79D6-4D7B-B157-DD006982BCC4@googlemail.com>



If the main hawkular deliverable is an integrated solution that builds on wildfly, then the priorities are clear and the configuration question is already answered. 

It doesn?t matter what configuration option you provide for the components themselves, because once integrated the configuration becomes subject of the target environment. Whatever mechanism you chose, it?s very likely going to be replaced by the mechanism the target environment uses. 

Therefore I would suggest the following:

a) every component provides configuration builder interface (java, programmatically)
b) the main configuration use the default wildfly mechanism

a) allows the community to build custom adapters if needed. b) interfaces with a) and covers the main hawkular use cases. 

/HeikoB





From jpkroehling at redhat.com  Mon Feb  9 03:06:50 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Mon, 09 Feb 2015 09:06:50 +0100
Subject: [Hawkular-dev] Should Keycloak integration be optional?
In-Reply-To: <F8BAF729-23F2-4C4C-A1DF-C918C72E301B@googlemail.com>
References: <54C28AE2.3010509@redhat.com> <54C601D9.9030102@redhat.com>
	<54C75B94.8080103@redhat.com> <54C79ECF.7020109@redhat.com>
	<54CA1768.8050105@redhat.com> <54CA5AFD.5010102@redhat.com>
	<54CB55CF.3040207@redhat.com> <54CB6964.10905@redhat.com>
	<54D21A28.2030405@redhat.com>
	<D46B98CA-96C3-4861-8B22-7F0DE4DE83E6@googlemail.com>
	<54D22C8E.30601@redhat.com>
	<F8BAF729-23F2-4C4C-A1DF-C918C72E301B@googlemail.com>
Message-ID: <54D86A9A.7060409@redhat.com>

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

On 02/08/2015 08:17 AM, Heiko Braun wrote:
> Maybe you'll find that keycloak only addresses part of the
> requirements. This will impact the question wether or not to make
> it a technological constraint.

Right, hence the question about the concrete use case you have in mind
:-) What kind of non-HTTP communication do you anticipate?

Note that even if Keycloak itself doesn't provides an adapter for
non-HTTP authentication, we could build one ourselves that takes the
authentication data from the "request" (or client) and does the HTTP
request to Keycloak server on its behalf.

- - Juca.

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

iQEcBAEBAgAGBQJU2GqaAAoJECKM1e+fkPrXLmgH/jQwlnF1J2CZHOsFuE1FvjZS
NhWFNldNLa91pgbMuvncEKgKmRpKynRlfMsWQBD1RqrrSAivl3XUrNBR9m/W6EIL
SRnKSevISKXscJg90VVJnzD/tJsMVXDBS22HSOP7u6ENqZfdOCgUv3C6j5fgsLVS
cRfxG/yj6dZ66ueYmtBZ/wcrIzhSjKPXW/FW/1woR+i8pp2Q4yOX6TFcQ27/uO5q
IelQrjJqYaSnZtKEgVSF7QtUlrz+Cu4m4GnYr41OxuY2LQlX59PutJvS5UGipHJN
BY1G8EuAoZNWm1wirOhwl9N43+F8xW/gUqVluinwh7Ax0WMYAgiX5shcn/YO2Pc=
=5fau
-----END PGP SIGNATURE-----

From ike.braun at googlemail.com  Mon Feb  9 03:10:15 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Mon, 9 Feb 2015 09:10:15 +0100
Subject: [Hawkular-dev] integration project
In-Reply-To: <12A90508-BF38-4A7C-873A-0EEAF8201FB3@redhat.com>
References: <AA68ED56-1301-476F-8FD4-76FA2ADEF53B@redhat.com>
	<415096932.7531096.1423166525769.JavaMail.zimbra@redhat.com>
	<BAD9995D-288B-46A0-B672-CC979039D034@redhat.com>
	<1119863261.7549138.1423168481278.JavaMail.zimbra@redhat.com>
	<A5AC1495-B8A4-4598-A66B-D4447FC503F1@redhat.com>
	<165659311.7881078.1423231943618.JavaMail.zimbra@redhat.com>
	<12A90508-BF38-4A7C-873A-0EEAF8201FB3@redhat.com>
Message-ID: <9F62E666-8711-4984-A380-88E10DFAE0DE@googlemail.com>


If needed I can backport the changes I did to C* onto 2.x. But I would not use C* 2.x without the patches for https://issues.apache.org/jira/browse/CASSANDRA-7998


> On 22 Jan 2015, at 20:00, John Sanda <jsanda at redhat.com> wrote:
> 
> wildfly-cassandra requires building upstream C* trunk branch which is currently targeted for 3.0. I have been developing/testing against 2.1.2.  It may work fine. I don?t know. I can test and let you know in about an hour or so whether or not there will be problems.
> 
>> On Feb 6, 2015, at 9:12 AM, John Mazzitelli <mazz at redhat.com> wrote:
>> 
>>>> Bad news - metrics is broken. When you start, you'll get an exception
>>>> because it appears the embedded cassandra EAR initializes too late - after
>>>> the metrics war tries to find C*. You'll get deployment errors due to
>>>> this.
>>> 
>>> As said on the channel already the wildfly-cassandra extension from
>>> 
>>> https://github.com/hawkular/wildfly-cassandra
>> 
>> I talked to Stefan and John S. about that - unfortunately (and Stefan/John correct me if I'm wrong) we can't use that because h-metrics needs a later version of C* which wildfly-cassandra does not support.
>> _______________________________________________
>> 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 lponce at redhat.com  Mon Feb  9 03:24:34 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 9 Feb 2015 03:24:34 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Thoughts on the notification system
In-Reply-To: <54D4B0DA.90202@redhat.com>
References: <54D4B0DA.90202@redhat.com>
Message-ID: <316094092.8448942.1423470274850.JavaMail.zimbra@redhat.com>



> 
> 1. Contextual data
> 
> A notification has contextual data. Contextual data is comprised of:
> - alert definition data
> - data involved in the trigger (for example metrics and availability values)
>

+1
 
> 2. Notifier data
> 
> 2.1 Who is the recipient?
> 
> Email: address
> SMS: phone number
> 
> Sometimes the recipient is fixed (for example when sending email to a
> mailing-list).
> Sometimes it should be picked from user information (for example when
> sending emails to a group of users)
> 
> This information depends on the alert definition, but a default should
> be configurable for convenience.
> 
> 2.2 How should the message be sent?
> 
> Email: SMTP address/port and credentials
> SMS: Web service HTTP URL and credentials
> 
> The information depends on the tenant (in rare cases, on the alert
> definition, but let's ignore the problem for now)
> 
> 3. How should the message be formatted?
> 
> When a human is the recipient, information can be turned into text with
> a template engine (like freemarker).
> 
> Information depends on the alert definition, but a default should be
> configurable for convenience.
> 
> 4. Configuration
> 
> Notifiers may expose REST endpoints (with standardized URIs)
> 
> - default config: /emailnotifier/configuration
> 
> - alert definition level config: /emailnotifier/configuration/1
>

I am not sue if notifiers should expose directly these end-points for the configuration tasks.

I was thinking in a way where when a plugin is deployed, the plugin configuration is sent to the alert-engine component.
Then UI or consumers of alerts can access to notifiers info through the DefinitionService.

In practice, flow would be similar, but instead to use specific /emailnotifier/ just using a centralized by alerts /hawkular/alerts/notifier/email/....
 

> Example:
> 
> {
>      "to": ["paul at foobar.com", "alfred at foobar.com"],
>      "cc": ["backoffice-mw-ops at foobar.com"],
>      "subject": "Pool soon exhausted",
>      "mode": "plaintext+html"
>      "templates":
>          [{
>              name: "plaintext",
>              uri: "/emailnotifier/configuration/1/templates/plaintext"
>          },{
>              name: "html",
>              uri: "/emailnotifier/configuration/1/templates/html"
>          }]
> }
> 
> - template configs:
> 
> Example:
> 
> /emailnotifier/configuration/1/templates/plaintext
> /emailnotifier/configuration/1/templates/html
> 
> 
> I'm still not sure which component should be responsible of loading user
> information when a user (or a group of users) is selected as the recipient.
>

Good question, my main doubt if it is notifier plugin should be responsible to know this info by itself or it has to call a third-party component for that. 


> 5. Process
> 
> - Alerts sends contextual data on the bus
> - Notifier picks it up
> - Notifier loads configuration for this alert definition or the default one
> - Notifier applies the template (optional)
> - Notifier sends email or invoke sender API
> 

+1

> 6. Storage
> 
> There needs to be some shared storage where to bind configuration and
> templates to alert definitions.
> 
>

+1

We raised this concern before and if I am not wrong idea is to use H2 at this stage and change in the future.
 
> Comments?
> 
> 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 Feb  9 05:44:27 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 09 Feb 2015 11:44:27 +0100
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
In-Reply-To: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
References: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
Message-ID: <54D88F8B.3010200@redhat.com>

Le 06/02/2015 23:28, mike thompson a ?crit :
> Agenda Item: Hawkular Website (http://hawkular.github.io/)

Nice work Jirka!

>
> Now that we officially have a Hawkular web presence, maybe we should
> chat about what we would like to see here. I?m sure everyone has
> opinions and it would be nice to get them out in a open discussion.
> Especially since this will be the launcher for our MVP.
>
>

I believe we need:

* A front page (I like the existing one)
  -> with a "try it online" button
  -> with a "getting started" button
  -> with social links at the bottom
* Download page
* Docs page
* Contributing page



From mwringe at redhat.com  Mon Feb  9 09:36:10 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Mon, 09 Feb 2015 09:36:10 -0500
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
In-Reply-To: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
References: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
Message-ID: <54D8C5DA.9090307@redhat.com>


On 06/02/15 05:28 PM, mike thompson wrote:
> Agenda Item: Hawkular Website (http://hawkular.github.io/)
>

Ah, nice site, it looks very very familiar :)

> Now that we officially have a Hawkular web presence, maybe we should 
> chat about what we would like to see here. I?m sure everyone has 
> opinions and it would be nice to get them out in a open discussion. 
> Especially since this will be the launcher for our MVP.
>
>
>
>
> _______________________________________________
> 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/20150209/09dd5626/attachment.html 

From lponce at redhat.com  Mon Feb  9 10:13:40 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 9 Feb 2015 10:13:40 -0500 (EST)
Subject: [Hawkular-dev] Authorization flow
In-Reply-To: <1192547564.8713015.1423494239219.JavaMail.zimbra@redhat.com>
Message-ID: <1732023915.8728092.1423494820888.JavaMail.zimbra@redhat.com>

Hi,

I have read the threads about the tenantId/integration with Keycloak, but I am still having some doubts about the ideal flow.

Please, let me know if my flow is correct:

- We will have users associated by tenants, so a tuple (tenantId, userId) should be unique i.e. (tenantA, userA), (tenantB, userA).
- A tuple (tenantId, userId) will have associated a list of roles (with hierarchy like an organization ?).
- Metrics/Definitions/Resources should be unique by tenant, so our backend should have something like (tenantId, {metricId|resourceId|definitionId}).
- In the APIs, tenantId will be explicit nor implicit.
- Keycloak would be responsible to pass a (tenantId, userId) + roles list to the component/application.

So, my main doubt is about how are we thinking to work with the authorization, I guess that component backend should define some authorization rules based on roles and permissions, right ?

I guess that this part should be more or less shared for all components.

Is there any draft about it ?

Perhaps this question is very early and it can be put on hold for later, but just curious about it, as I would like to think in possible impacts.

Thanks,
Lucas

 

From jpkroehling at redhat.com  Mon Feb  9 11:44:56 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 09 Feb 2015 17:44:56 +0100
Subject: [Hawkular-dev] Authorization flow
In-Reply-To: <1732023915.8728092.1423494820888.JavaMail.zimbra@redhat.com>
References: <1732023915.8728092.1423494820888.JavaMail.zimbra@redhat.com>
Message-ID: <54D8E408.4040904@redhat.com>

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

On 02/09/2015 04:13 PM, Lucas Ponce wrote:
> - We will have users associated by tenants, so a tuple (tenantId,
> userId) should be unique i.e. (tenantA, userA), (tenantB, userA).

Not exactly. We'll have "users" and "organizations", a la github. So,
no "tenants".

> - A tuple (tenantId, userId) will have associated a list of roles
> (with hierarchy like an organization ?).

Instead of roles, it's more likely that there will be permissions on
resources. For instance:

- - user jdoe belongs to "acme", and "acme" has read access to
"metric1". Therefore, jdoe has read access to "metric1". For this to
work, I'd need to be notified whenever a resource is created (probably
via the bus?).

> - Metrics/Definitions/Resources should be unique by tenant, so our
> backend should have something like (tenantId,
> {metricId|resourceId|definitionId}).

A resource (metric, alert, ...) will have an "Owner", which can either
be an user or an organization. At this point, I think you won't need
to track the ownership of the resource, as I intend to track this on
my side.

> - In the APIs, tenantId will be explicit nor implicit.

I think this needs a broader discussion, to get a consensus. I would
be happy with paths with resource IDs, without mentioning the owner:
"/metric/{metricId}", but I see also advantages in having
"/{owner}/metrics".

> - Keycloak would be responsible to pass a (tenantId, userId) +
> roles list to the component/application.

Not a tenant, but an user. But I don't think you'd need to have
explicit access to an user.

> So, my main doubt is about how are we thinking to work with the
> authorization, I guess that component backend should define some
> authorization rules based on roles and permissions, right ?

I hope to have this very transparent to the individual components, but
I'll need to know the "resource" (ie: metric1) and the "operation"
(ie: "read metric"). With that, I should be able to build a filter
that would automatically block the request if the user has no
permission to run the operation on the resource.

> I guess that this part should be more or less shared for all
> components.

Yes, that's the hawkular-accounts repository.

> Is there any draft about it ?

Sort of. I'm building the basics of it right now:

https://github.com/hawkular/hawkular-accounts

I intend to make a service like this one available to the individual
components:
https://github.com/hawkular/hawkular-accounts/blob/master/backend/src/main/java/org/hawkular/accounts/backend/boundary/PermissionChecker.java

> Perhaps this question is very early and it can be put on hold for
> later, but just curious about it, as I would like to think in
> possible impacts.

I hope to have something available soon to be consumed by other
components. But the above should give you a picture of what's planned.
If not, let me know :-)

- - Juca.

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

iQEcBAEBAgAGBQJU2OQHAAoJECKM1e+fkPrXeg0H/12/04nv8MGPK6XugdT/29kW
UYs/vmu0Ftd9nR5gwbQR7/goZu76bTGmfRUdijSR5d1lkO6JdHQ7kscHkjcPbWPc
bMMlWmWxkwyBu9XKa0D7a5s/6zURJkn1rQ/qFCvXbdIrqjFl5oKdpzes+BB4ZrW5
LeEKFuzHoeWlCTf/nDB0jz9c04PUMqrVzrHoq8iW+c92HWge7H6s3cS6qlfM1pQp
mMwcOCLHsMd2jiXAbpYw5tr+3fq7de9/8Fx8SmlPmow20ISii31lexi4MvUEYx/H
Kt2MbROqcY96yKu0edBzvPFs1GWFAYoZa7MRUyPCM02NaRzGwsJVXd0HyFNvtK4=
=btut
-----END PGP SIGNATURE-----

From jkremser at redhat.com  Mon Feb  9 16:02:23 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Mon, 9 Feb 2015 16:02:23 -0500 (EST)
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
In-Reply-To: <54D8C5DA.9090307@redhat.com>
References: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
	<54D8C5DA.9090307@redhat.com>
Message-ID: <1890043225.874374.1423515743829.JavaMail.zimbra@redhat.com>

| Now that we officially have a Hawkular web presence, maybe we should chat about what we would like to see here. I?m sure everyone has opinions and it would | be nice to get them out in a open discussion. Especially since this will be the launcher for our MVP.

I am on RHCE course whole week. Each day, we end on 17:00 GMT+1. I'll see if I can attend (if the call haven't already happened)


| Ah, nice site, it looks very very familiar :)

Kudos for L&F should go to whomever designed liveoak.org, of course :]


From mithomps at redhat.com  Mon Feb  9 22:22:03 2015
From: mithomps at redhat.com (mike thompson)
Date: Mon, 9 Feb 2015 19:22:03 -0800
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
In-Reply-To: <1890043225.874374.1423515743829.JavaMail.zimbra@redhat.com>
References: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>
	<54D8C5DA.9090307@redhat.com>
	<1890043225.874374.1423515743829.JavaMail.zimbra@redhat.com>
Message-ID: <F63D407C-1976-4082-82B3-FB817AEACF3E@redhat.com>


> On 9 Feb 2015, at 13:02, Jiri Kremser <jkremser at redhat.com> wrote:
> 
> | Now that we officially have a Hawkular web presence, maybe we should chat about what we would like to see here. I?m sure everyone has opinions and it would | be nice to get them out in a open discussion. Especially since this will be the launcher for our MVP.
> 
> I am on RHCE course whole week. Each day, we end on 17:00 GMT+1. I'll see if I can attend (if the call haven't already happened)

Jirka, it probably makes sense to wait until you are available. So maybe next week. Unless someone else has a driving need for now. 

> 
> 
> | Ah, nice site, it looks very very familiar :)
> 
> Kudos for L&F should go to whomever designed liveoak.org, of course :]
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From theute at redhat.com  Tue Feb 10 03:31:24 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 10 Feb 2015 09:31:24 +0100
Subject: [Hawkular-dev] Agenda Item for Hawkular Tech Exchange Calls
In-Reply-To: <1890043225.874374.1423515743829.JavaMail.zimbra@redhat.com>
References: <6A8147DB-91E0-4D05-86EE-4AE21C18522D@redhat.com>	<54D8C5DA.9090307@redhat.com>
	<1890043225.874374.1423515743829.JavaMail.zimbra@redhat.com>
Message-ID: <54D9C1DC.7050408@redhat.com>


On 02/09/2015 10:02 PM, Jiri Kremser wrote:
> | Now that we officially have a Hawkular web presence, maybe we should chat about what we would like to see here. I?m sure everyone has opinions and it would | be nice to get them out in a open discussion. Especially since this will be the launcher for our MVP.
>
> I am on RHCE course whole week. Each day, we end on 17:00 GMT+1. I'll see if I can attend (if the call haven't already happened)
>
>
> | Ah, nice site, it looks very very familiar :)
>
> Kudos for L&F should go to whomever designed liveoak.org, of course :]

Gabriel :) And Jirka did some twists

From hrupp at redhat.com  Tue Feb 10 05:10:59 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 10 Feb 2015 11:10:59 +0100
Subject: [Hawkular-dev] Repositories under github.com/rhq_project
Message-ID: <815B6007-24DA-4EA3-B078-76A9D9585FBA@redhat.com>

Hello,

since we have moved a lot of the .next repositories from https://github.com/rhq_project to
https://github.com/hawkular,

there are a few leftovers that I am not sure if they belong to hawkular or what we do with them

* rhqm-charts
* rhq-audit
* rhq-msg
* rhq-next-bom
* angular-ui
* rhq-checkstyle-config

I guess -msg and -bom can just go, same for angular-ui, which is empty anyway.
What about the others?

  Heiko

-- 
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 mazz at redhat.com  Tue Feb 10 09:11:07 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 10 Feb 2015 09:11:07 -0500 (EST)
Subject: [Hawkular-dev] Repositories under github.com/rhq_project
In-Reply-To: <815B6007-24DA-4EA3-B078-76A9D9585FBA@redhat.com>
References: <815B6007-24DA-4EA3-B078-76A9D9585FBA@redhat.com>
Message-ID: <1750577510.9494476.1423577467448.JavaMail.zimbra@redhat.com>

> there are a few leftovers that I am not sure if they belong to hawkular or
> what we do with them
> 
> * rhqm-charts
> * rhq-audit
> * rhq-msg
> * rhq-next-bom
> * angular-ui
> * rhq-checkstyle-config


rhq-audit, rhq-msg, rhq-next-bom can get deleted. I don't know about the rest.

From ike.braun at googlemail.com  Tue Feb 10 10:28:35 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Tue, 10 Feb 2015 16:28:35 +0100
Subject: [Hawkular-dev] REST over messaging middleware
Message-ID: <D41E7079-AD72-43C7-96AE-CB469F5C992C@googlemail.com>

An interesting article, somewhat related to the hawkular architecture:

A Protocol for REST over ZeroMQ
http://getprismatic.com/story/1423479470656?share=NDAwMA.MTQyMzQ3OTQ3MDY1Ng.zW_b8Xtq1bZLnmfUnYQ3eQBO6LU



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

From miburman at redhat.com  Tue Feb 10 11:12:48 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 10 Feb 2015 18:12:48 +0200
Subject: [Hawkular-dev] REST over messaging middleware
In-Reply-To: <D41E7079-AD72-43C7-96AE-CB469F5C992C@googlemail.com>
References: <D41E7079-AD72-43C7-96AE-CB469F5C992C@googlemail.com>
Message-ID: <54DA2E00.1020606@redhat.com>

Yes, very:
{

  * "error": "clojure.lang.ExceptionInfo: non-200 resp: 503 {:message
    \"non-200 resp: 503 \", :resp {:status 503, :headers
    {\"content-length\" \"0\", \"connection\" \"Close\"}, :body \"\",
    :url
    \"http://api.getprismatic.com/2.1/docs/1423479470656/meta-info\",
    :redirects []}}",
  * "trace": null

}

It seems to be very difficult subject ;)

   - Micke

On 10.02.2015 17:28, Heiko Braun wrote:
> An interesting article, somewhat related to the hawkular architecture:
>
> *A Protocol for REST over ZeroMQ*
> http://getprismatic.com/story/1423479470656?share=NDAwMA.MTQyMzQ3OTQ3MDY1Ng.zW_b8Xtq1bZLnmfUnYQ3eQBO6LU
>
>
>
>
>
> _______________________________________________
> 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/20150210/7825c888/attachment.html 

From ike.braun at googlemail.com  Tue Feb 10 12:52:13 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Tue, 10 Feb 2015 18:52:13 +0100
Subject: [Hawkular-dev] REST over messaging middleware
In-Reply-To: <54DA2E00.1020606@redhat.com>
References: <D41E7079-AD72-43C7-96AE-CB469F5C992C@googlemail.com>
	<54DA2E00.1020606@redhat.com>
Message-ID: <033276B4-C6AB-46A1-B553-722433D19D1C@googlemail.com>

Sorry for the broken link. Here's the correct one if you are still interested:

http://hintjens.com/blog:86




> Am 10.02.2015 um 17:12 schrieb Michael Burman <miburman at redhat.com>:
> 
> Yes, very:
> {
> "error": "clojure.lang.ExceptionInfo: non-200 resp: 503 {:message \"non-200 resp: 503 \", :resp {:status 503, :headers {\"content-length\" \"0\", \"connection\" \"Close\"}, :body \"\", :url \"http://api.getprismatic.com/2.1/docs/1423479470656/meta-info\", :redirects []}}",
> "trace": null
> }
> 
> It seems to be very difficult subject ;)
> 
>   - Micke
> 
>> On 10.02.2015 17:28, Heiko Braun wrote:
>> An interesting article, somewhat related to the hawkular architecture:
>> 
>> A Protocol for REST over ZeroMQ
>> http://getprismatic.com/story/1423479470656?share=NDAwMA.MTQyMzQ3OTQ3MDY1Ng.zW_b8Xtq1bZLnmfUnYQ3eQBO6LU
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20150210/51ec98a3/attachment.html 

From lponce at redhat.com  Wed Feb 11 04:40:08 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 11 Feb 2015 04:40:08 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and current
	work
In-Reply-To: <2104313690.9961260.1423644158182.JavaMail.zimbra@redhat.com>
Message-ID: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>

Hello,

We have had several threads and discussion about notifications architecture, and we have also a small draft of the API in the current work.
So, to unify all this conversations I am going to describe in the ML the current approach to summary all discussion around it.

The conceptual requeriments are the following:

Req1: Notifications will follow a plugin-based architecture
-----------------------------------------------------------

So, we can add/remove plugins into the system, without impact of rest of the components.


Req2: There are two concepts: plugin (notifier type) and notifier
-----------------------------------------------------------------

A plugin will be responsible of a type of notifications 
(i.e. email-plugin, sms-plugin, snmp-plugin, etc...).

A notifier is a representation of a destination with status about how it has to process the notification.
A notifier can be reused in several triggers definitions.
(i.e. in json pseudo-format
      { notifierId: "email-admins-and-ceo",
        properties: {
              NotifierType: "email",
              to: ["admin1 at corp.org", "admin2 at corp.org", "cep at corp.org"]
              template: "Incident in %MSG% at %TIME%. Alert description: %ALERT_DETAILS% ..."
              }
      } 
)

So, we can have several triggers definitions that will use the notifier "email-admins-and-ceo".

A plugin can have properties that are shared for all plugin.
(i.e. the server/gateway used for email/snmp/sms).

A notifier can have specific properties.
(i.e. list of destination, decoration of the message, other).


Req3: There should be a central way where plugins are notifier are available
----------------------------------------------------------------------------

New triggers definitions will be create through UI, so in the API we need to perform:
- Get the list of notifiers created in the system (for an specific plugin or all plugins).
- Link a notifier with a specific trigger(s) definition(s).
- Create a new notifier of a specific type.


Req4: Alerts engine sends alerts in a decoupled way
---------------------------------------------------

Alerts engine is responsible to process data and to infer which alerts have to be sent.
The alert engine should provide a decoupled way to send a notification through the notifier attached.

===

There are also some technical requeriments that we are following in the current approach:

TechReq1: Alerts engine should work in a decoupled way from other components
----------------------------------------------------------------------------

The alerts engine implementation should not have a strong dependency with the bus component
or any specific plugin implementation.
So, the engine should be able to run in the whole hawkular architecture or it can be reusable
for third party scenarios where other developers can create their own notifications architecture.

More details of the architecture proposed are under this article:
https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture


TechReq2: Notifications plugins flow
------------------------------------

A preliminar flow for the notifications plugins can be the following:

- When a plugin is deployed, it should be registered, then it is available/visible for the API.
- When a notifier is created through the UI using the API, a plugin should be notified.
- Main use case of the plugin is to listen for notifications messages to process its specific sent.


TechReq3: Predefined notifiers
------------------------------

Notifiers can be pre-created from an initialization configuration.


===

These are the requeriments used for the current draft of this area.
The idea of this thread is to discuss about it to clarify/explain/modify it.

After that I will try to collect all comments in a new article.

Thanks in advance for your comments.

Lucas







From vrockai at redhat.com  Wed Feb 11 08:23:34 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Wed, 11 Feb 2015 14:23:34 +0100
Subject: [Hawkular-dev] REST ideas
Message-ID: <1423661014.17656.1.camel@vrockai-laptop>

Hi,

I'm looking at hawkular-inventory and I've got several comments (liveoak
legacy) which could apply on other rest endpoints, too:

1. I think it would be easier to use/get if we make it more
hierarchical. That means; instead of using two distinct URLs (resources
vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
only one (/hawkular/inventory/rest-test/resources/x1422733176502).

2. Sometimes, in the docs, attribute called "name" is used, and referred
to, as an "id". Would it be possible and make sense to choose just one
notation and use it in the representation? 

3. Usage of methods: When you want to create a metric, you use the PUT
method. What about unifying methods in some commonly used manner. Like
post for create, put for edit?

WDYT?

Viliam



From hrupp at redhat.com  Wed Feb 11 08:43:00 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 11 Feb 2015 14:43:00 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1423661014.17656.1.camel@vrockai-laptop>
References: <1423661014.17656.1.camel@vrockai-laptop>
Message-ID: <563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>


> Am 11.02.2015 um 14:23 schrieb Viliam Rockai <vrockai at redhat.com>:
> 
> Hi,
> 
> I'm looking at hawkular-inventory and I've got several comments (liveoak
> legacy) which could apply on other rest endpoints, too:
> 
> 1. I think it would be easier to use/get if we make it more
> hierarchical. That means; instead of using two distinct URLs (resources
> vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> only one (/hawkular/inventory/rest-test/resources/x1422733176502).

This is a good question/suggestion. I tried to follow the pattern of <foo>S 
for list + creation
and <foo>/x for identifying individual objects - sort of like in natural language.



> 2. Sometimes, in the docs, attribute called "name" is used, and referred
> to, as an "id". Would it be possible and make sense to choose just one
> notation and use it in the representation? 

Yes. I think we may need some more overall cleanup as soon as we know
more about some terms and semantics we want to use.
> 
> 3. Usage of methods: When you want to create a metric, you use the PUT
> method. What about unifying methods in some commonly used manner. Like
> post for create, put for edit?

I guess you are right here. I used put instead of post for the metrics, as they are
sort of dependent objects. 



  Heiko



From lkrejci at redhat.com  Wed Feb 11 09:08:40 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 11 Feb 2015 09:08:40 -0500 (EST)
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
Message-ID: <2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, 11 February, 2015 2:43:00 PM
> Subject: Re: [Hawkular-dev] REST ideas
> 
> 
> > Am 11.02.2015 um 14:23 schrieb Viliam Rockai <vrockai at redhat.com>:
> > 
> > Hi,
> > 
> > I'm looking at hawkular-inventory and I've got several comments (liveoak
> > legacy) which could apply on other rest endpoints, too:
> > 
> > 1. I think it would be easier to use/get if we make it more
> > hierarchical. That means; instead of using two distinct URLs (resources
> > vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> > entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> > only one (/hawkular/inventory/rest-test/resources/x1422733176502).
> 
> This is a good question/suggestion. I tried to follow the pattern of <foo>S
> for list + creation
> and <foo>/x for identifying individual objects - sort of like in natural
> language.
> 
> 
> 
> > 2. Sometimes, in the docs, attribute called "name" is used, and referred
> > to, as an "id". Would it be possible and make sense to choose just one
> > notation and use it in the representation?
> 
> Yes. I think we may need some more overall cleanup as soon as we know
> more about some terms and semantics we want to use.
> > 
> > 3. Usage of methods: When you want to create a metric, you use the PUT
> > method. What about unifying methods in some commonly used manner. Like
> > post for create, put for edit?
> 

Well, I am actually not so sure here.

For some entities, like tenants themselves or environments, I think
the URL pattern for creation could look like:

/tenants/{tenantId}

or

/{tenantId}/environments/{environmentId}

These guys are a little bit different because the USER supplies the ID.

so we could have a POST like

/tenants/?tenantId=asdf

or an empty POST or PUT into

/tentants/{tenantId}

both tenant or environment are essentially non-updateable.

I am no REST expert but an "empty POST" seems weird to me as does specifying
the ID as an parameter in POST request. It is just my personal taste, but I
find the PUT for creation here the most natural.

I am easily swayed though ;)

> I guess you are right here. I used put instead of post for the metrics, as
> they are
> sort of dependent objects.
> 
> 
> 
>   Heiko
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From vrockai at redhat.com  Wed Feb 11 09:45:20 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Wed, 11 Feb 2015 15:45:20 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
Message-ID: <1423665920.30188.5.camel@vrockai-laptop>

On Wed, 2015-02-11 at 14:43 +0100, Heiko W.Rupp wrote:
> > Am 11.02.2015 um 14:23 schrieb Viliam Rockai <vrockai at redhat.com>:
> > 
> > Hi,
> > 
> > I'm looking at hawkular-inventory and I've got several comments (liveoak
> > legacy) which could apply on other rest endpoints, too:
> > 
> > 1. I think it would be easier to use/get if we make it more
> > hierarchical. That means; instead of using two distinct URLs (resources
> > vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> > entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> > only one (/hawkular/inventory/rest-test/resources/x1422733176502).
> 
> This is a good question/suggestion. I tried to follow the pattern of <foo>S 
> for list + creation
> and <foo>/x for identifying individual objects - sort of like in natural language.


Yeah, I thought this is the reason. My way of looking at it is as if it
were folders. So "resources" is the name of the folder, I can create new
item there with POST, I can list the "directory" with GET on the
directory itself, or list the contents of items by GETing some
particular item and so on...

> 
> 
> 
> > 2. Sometimes, in the docs, attribute called "name" is used, and referred
> > to, as an "id". Would it be possible and make sense to choose just one
> > notation and use it in the representation? 
> 
> Yes. I think we may need some more overall cleanup as soon as we know
> more about some terms and semantics we want to use.
> > 
> > 3. Usage of methods: When you want to create a metric, you use the PUT
> > method. What about unifying methods in some commonly used manner. Like
> > post for create, put for edit?
> 
> I guess you are right here. I used put instead of post for the metrics, as they are
> sort of dependent objects. 
> 
> 
> 
>   Heiko
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From vrockai at redhat.com  Wed Feb 11 09:49:10 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Wed, 11 Feb 2015 15:49:10 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
	<2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
Message-ID: <1423666150.30188.8.camel@vrockai-laptop>

On Wed, 2015-02-11 at 09:08 -0500, Lukas Krejci wrote:
> 
> ----- Original Message -----
> > From: "Heiko W.Rupp" <hrupp at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Wednesday, 11 February, 2015 2:43:00 PM
> > Subject: Re: [Hawkular-dev] REST ideas
> > 
> > 
> > > Am 11.02.2015 um 14:23 schrieb Viliam Rockai <vrockai at redhat.com>:
> > > 
> > > Hi,
> > > 
> > > I'm looking at hawkular-inventory and I've got several comments (liveoak
> > > legacy) which could apply on other rest endpoints, too:
> > > 
> > > 1. I think it would be easier to use/get if we make it more
> > > hierarchical. That means; instead of using two distinct URLs (resources
> > > vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> > > entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> > > only one (/hawkular/inventory/rest-test/resources/x1422733176502).
> > 
> > This is a good question/suggestion. I tried to follow the pattern of <foo>S
> > for list + creation
> > and <foo>/x for identifying individual objects - sort of like in natural
> > language.
> > 
> > 
> > 
> > > 2. Sometimes, in the docs, attribute called "name" is used, and referred
> > > to, as an "id". Would it be possible and make sense to choose just one
> > > notation and use it in the representation?
> > 
> > Yes. I think we may need some more overall cleanup as soon as we know
> > more about some terms and semantics we want to use.
> > > 
> > > 3. Usage of methods: When you want to create a metric, you use the PUT
> > > method. What about unifying methods in some commonly used manner. Like
> > > post for create, put for edit?
> > 
> 
> Well, I am actually not so sure here.
> 
> For some entities, like tenants themselves or environments, I think
> the URL pattern for creation could look like:
> 
> /tenants/{tenantId}
> 
> or
> 
> /{tenantId}/environments/{environmentId}
> 
> These guys are a little bit different because the USER supplies the ID.
> 
> so we could have a POST like
> 
> /tenants/?tenantId=asdf
> 
> or an empty POST or PUT into
> 
> /tentants/{tenantId}
> 
> both tenant or environment are essentially non-updateable.
> 
> I am no REST expert but an "empty POST" seems weird to me as does specifying
> the ID as an parameter in POST request. It is just my personal taste, but I
> find the PUT for creation here the most natural.


I'm not sure I get it. What's wrong with a POST on /tenants with data
like {id: 'myNewId'}?

> 
> I am easily swayed though ;)
> 
> > I guess you are right here. I used put instead of post for the metrics, as
> > they are
> > sort of dependent objects.
> > 
> > 
> > 
> >   Heiko
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jkremser at redhat.com  Wed Feb 11 14:08:24 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Wed, 11 Feb 2015 14:08:24 -0500 (EST)
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
	<2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
Message-ID: <1288064555.1866201.1423681704223.JavaMail.zimbra@redhat.com>

| I am no REST expert but an "empty POST" seems weird to me as does specifying
| the ID as an parameter in POST request. It is just my personal taste, but I
| find the PUT for creation here the most natural.

-1. PUT is for modifying and POST for creating new resources, that's the convention. That's what client writers would expect. The POST request doesn't have to be completely empty, there can be the id as Viliam had mentioned or in the future there can be additional fields. Let's listen to the wisdom of RESTafarians here :) 

http://www.restapitutorial.com/lessons/httpmethods.html

jk

From jshaughn at redhat.com  Wed Feb 11 14:30:53 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 11 Feb 2015 14:30:53 -0500
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
Message-ID: <54DBADED.7050905@redhat.com>

On 2/11/2015 4:40 AM, Lucas Ponce wrote:
> Hello,
>
> We have had several threads and discussion about notifications architecture, and we have also a small draft of the API in the current work.
> So, to unify all this conversations I am going to describe in the ML the current approach to summary all discussion around it.
>
> The conceptual requeriments are the following:
>
> Req1: Notifications will follow a plugin-based architecture
> -----------------------------------------------------------
>
> So, we can add/remove plugins into the system, without impact of rest of the components.

Is it correct to assume that for Hawkular a NotifierType Plugin will be 
an MDB listening on the Bus for published Alerts?  And that 
Hawkular-Alerts will supply some default NotifierType MDBs?

If that is true, then I think the NotifierType MDBs could self-register 
by sending a message to the Alerts Queue.  This would be as an 
alternative to using the Rest API to register, and then avoiding the 
need for a plugin to know any endpoint information.  It also avoids any 
disconnect that could happen if registration and deployment are done 
separately.  Did you have a different idea?

> Req2: There are two concepts: plugin (notifier type) and notifier
> -----------------------------------------------------------------
>
> A plugin will be responsible of a type of notifications
> (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
>
> A notifier is a representation of a destination with status about how it has to process the notification.
> A notifier can be reused in several triggers definitions.
> (i.e. in json pseudo-format
>        { notifierId: "email-admins-and-ceo",
>          properties: {
>                NotifierType: "email",
>                to: ["admin1 at corp.org", "admin2 at corp.org", "cep at corp.org"]
>                template: "Incident in %MSG% at %TIME%. Alert description: %ALERT_DETAILS% ..."
>                }
>        }
> )
>
> So, we can have several triggers definitions that will use the notifier "email-admins-and-ceo".

I don't think it should be required that a Trigger use a pre-defined 
Notifier.   I think it's OK that we could have pre-defined Notifiers, 
although it may be necessary then to ensure only a
proper subset are displayed, not just by Type but possibly tenant/user, 
etc.  So, the Trigger definer could select an existing Notifier, or 
supply an ad-hoc property-set.

I expect a NotifierType could have optional and required properties.  
Above, "to" would be required and "template" would likely be optional, 
with some default text.

> A plugin can have properties that are shared for all plugin.
> (i.e. the server/gateway used for email/snmp/sms).

I'm not sure I understand, but I'm not sure we need to have 
shared/global properties for the NotifierType plugins.  It seems a 
self-contained plugin may be best.

> A notifier can have specific properties.
> (i.e. list of destination, decoration of the message, other).
>
>
> Req3: There should be a central way where plugins are notifier are available
> ----------------------------------------------------------------------------
>
> New triggers definitions will be create through UI, so in the API we need to perform:
> - Get the list of notifiers created in the system (for an specific plugin or all plugins).
> - Link a notifier with a specific trigger(s) definition(s).
> - Create a new notifier of a specific type.

Right, we only need the first thing is we persist Notifiers.  We 
definitely need the ability to define an ad-hoc Notifier for a Trigger.


> Req4: Alerts engine sends alerts in a decoupled way
> ---------------------------------------------------
>
> Alerts engine is responsible to process data and to infer which alerts have to be sent.
> The alert engine should provide a decoupled way to send a notification through the notifier attached.

I agree.  The engine should be responsible for generating Alerts. For 
Hawkular the Alerts should be "tagged" with (perhaps JMS Headers for 
filtering) and likely be publish to a TriggeredAlerts topic for 
consumption by NotifierType plugins, and possibly anything else 
interested in generated alerts.

> ===
>
> There are also some technical requeriments that we are following in the current approach:
>
> TechReq1: Alerts engine should work in a decoupled way from other components
> ----------------------------------------------------------------------------
>
> The alerts engine implementation should not have a strong dependency with the bus component
> or any specific plugin implementation.
> So, the engine should be able to run in the whole hawkular architecture or it can be reusable
> for third party scenarios where other developers can create their own notifications architecture.

I think this is fine.  It means that some of the Hawkular-Alerts 
artifacts are independent of Hawkular "Kettle", although I don't think 
we need to split up the project repo.


> More details of the architecture proposed are under this article:
> https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
>
>
> TechReq2: Notifications plugins flow
> ------------------------------------
>
> A preliminar flow for the notifications plugins can be the following:
>
> - When a plugin is deployed, it should be registered, then it is available/visible for the API.
> - When a notifier is created through the UI using the API, a plugin should be notified.

Why is this?  Why does the plugin need to know about the defined Notifiers?

> - Main use case of the plugin is to listen for notifications messages to process its specific sent.

I'm not sure it should be listening for notification messages but rather 
published Alerts, which would contain/include the Notifier 
configuration/properties.

> TechReq3: Predefined notifiers
> ------------------------------
>
> Notifiers can be pre-created from an initialization configuration.

Like other definitions, it should be possible to import/export 
Notifiers, if we persist them.

> ===
>
> These are the requeriments used for the current draft of this area.
> The idea of this thread is to discuss about it to clarify/explain/modify it.
>
> After that I will try to collect all comments in a new article.
>
> Thanks in advance for your comments.
>

One last comment.  I wonder if we should maybe avoid RHQ's "Notifier" 
terminology.  It is OK, but it became sort of clunky when you would say 
that performing an operation on a resource was a Notification.   Perhaps 
"Action" may be a better term?  So we have Trigger Actions and Trigger 
Action Plugins.   Just a thought...



From mazz at redhat.com  Wed Feb 11 14:37:47 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 11 Feb 2015 14:37:47 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <54DBADED.7050905@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
	<54DBADED.7050905@redhat.com>
Message-ID: <939516925.10599873.1423683467533.JavaMail.zimbra@redhat.com>

> If that is true, then I think the NotifierType MDBs could self-register
> by sending a message to the Alerts Queue.  This would be as an
> alternative to using the Rest API to register, and then avoiding the
> need for a plugin to know any endpoint information.

I agree with this. BTW: this is/was my fear that I mentioned earlier with all these REST endpoints. We shouldn't expect every component to know all about the REST endpoints for all the other components (just like we don't want the bus API to require someone to supply a broker URL to point to a broker). That would just end up with a configuration nightmare (all of our components would have to have configuration settings to point to all the REST URLs that they want to talk to - and we'd have to expect the user to wire up all the components together by specifying where their REST endpoints are, unless we assume they are all on localhost). In my opinion, things like this should be done over the bus since everyone knows where the bus is (assuming they are deployed in the nest and/or can inject a @Resource to the connection factory) and there is no need to then have to be configured to point to REST endpoints.


From miburman at redhat.com  Wed Feb 11 15:22:20 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 11 Feb 2015 22:22:20 +0200
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1288064555.1866201.1423681704223.JavaMail.zimbra@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>	<2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
	<1288064555.1866201.1423681704223.JavaMail.zimbra@redhat.com>
Message-ID: <54DBB9FC.4080900@redhat.com>

Hi,

No, I disagree. PUT can create just as well as POST. Idempotency is the 
only difference. With PUT, you give the full resource path (thus, you 
will always modify the same instance).

Thus, with inventory the usage of:

PUT /resource/id
vs.
POST /resources

Would be correct. Just like GET /resources vs. GET /resource/id. 
However, with POST /resources, one could create an element without the 
resource id element, as the full path would be returned in the HTTP 
response (Location).

I'm not however advocating for pure HATEOAS, as that's often painful to 
follow, but if we can - we should. It forces to think about the interface.

   - Micke

On 11.02.2015 21:08, Jiri Kremser wrote:
> | I am no REST expert but an "empty POST" seems weird to me as does specifying
> | the ID as an parameter in POST request. It is just my personal taste, but I
> | find the PUT for creation here the most natural.
>
> -1. PUT is for modifying and POST for creating new resources, that's the convention. That's what client writers would expect. The POST request doesn't have to be completely empty, there can be the id as Viliam had mentioned or in the future there can be additional fields. Let's listen to the wisdom of RESTafarians here :)
>
> http://www.restapitutorial.com/lessons/httpmethods.html
>
> jk
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jkremser at redhat.com  Wed Feb 11 19:18:58 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Wed, 11 Feb 2015 19:18:58 -0500 (EST)
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <54DBB9FC.4080900@redhat.com>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<563F02D6-552F-43A5-8DA1-E3AD2B897030@redhat.com>
	<2019824061.12108704.1423663720346.JavaMail.zimbra@redhat.com>
	<1288064555.1866201.1423681704223.JavaMail.zimbra@redhat.com>
	<54DBB9FC.4080900@redhat.com>
Message-ID: <199110419.1977755.1423700338744.JavaMail.zimbra@redhat.com>

hey,

| PUT can create just as well as POST.

  well, almost every HTTP method can create a resource. I was more talking about conventions. But you are right that both can be used for creating and people do that. The question is what is more often and what people can expect. Perhaps mapping the POST,GET,PUT,DELETE directly to CRUD operations isn't the best idea even if it is natural thing to do, and the idempotency should be taken into consideration when deciding what to use. Also, it's important if we know the id(put) or we need the id to be auto-generated(post).

Here is some comprehensive flame war about it 
https://stackoverflow.com/questions/630453/put-vs-post-in-rest

Unfortunately, no clear winner on the SO, but it looks like your suggestion is the most accepted.

jk


| Hi,
| 
| No, I disagree. PUT can create just as well as POST. Idempotency is the
| only difference. With PUT, you give the full resource path (thus, you
| will always modify the same instance).
| 
| Thus, with inventory the usage of:
| 
| PUT /resource/id
| vs.
| POST /resources
| 
| Would be correct. Just like GET /resources vs. GET /resource/id.
| However, with POST /resources, one could create an element without the
| resource id element, as the full path would be returned in the HTTP
| response (Location).
| 
| I'm not however advocating for pure HATEOAS, as that's often painful to
| follow, but if we can - we should. It forces to think about the interface.
| 
|    - Micke

From lponce at redhat.com  Thu Feb 12 04:51:50 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 12 Feb 2015 04:51:50 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <54DBADED.7050905@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
	<54DBADED.7050905@redhat.com>
Message-ID: <1070660589.10919064.1423734710343.JavaMail.zimbra@redhat.com>


> >
> > Req1: Notifications will follow a plugin-based architecture
> > -----------------------------------------------------------
> >
> > So, we can add/remove plugins into the system, without impact of rest of
> > the components.
> 
> Is it correct to assume that for Hawkular a NotifierType Plugin will be
> an MDB listening on the Bus for published Alerts?  And that
> Hawkular-Alerts will supply some default NotifierType MDBs?
> 


Yes, but I would put a comment:

- From alerts-engine perspective I would like to maintain an abstract separation, so a notifierType plugin and a notifier can / can't depend of MDB.
- MDB is the implementation used in a bus-architecture for the whole hawkular suite.
- For example, in an embedded scenario, we would like to maintain the concept of plugin/notifier but without the bus dependencies.
(i.e. I am thinking in a case where a third party wants to create a "console-plugin" or similar without dealing with MDBs).

That is my main motivation for this abstraction layer.


> If that is true, then I think the NotifierType MDBs could self-register
> by sending a message to the Alerts Queue.  This would be as an
> alternative to using the Rest API to register, and then avoiding the
> need for a plugin to know any endpoint information.  It also avoids any
> disconnect that could happen if registration and deployment are done
> separately.  Did you have a different idea?
> 


No, that's the current idea drafted in the API.
In the hawkular "suite" implementation the examples plugins send an init message for registering.
In these case, plugins interacts with the bus only.


> > Req2: There are two concepts: plugin (notifier type) and notifier
> > -----------------------------------------------------------------
> >
> > A plugin will be responsible of a type of notifications
> > (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
> >
> > A notifier is a representation of a destination with status about how it
> > has to process the notification.
> > A notifier can be reused in several triggers definitions.
> > (i.e. in json pseudo-format
> >        { notifierId: "email-admins-and-ceo",
> >          properties: {
> >                NotifierType: "email",
> >                to: ["admin1 at corp.org", "admin2 at corp.org", "cep at corp.org"]
> >                template: "Incident in %MSG% at %TIME%. Alert description:
> >                %ALERT_DETAILS% ..."
> >                }
> >        }
> > )
> >
> > So, we can have several triggers definitions that will use the notifier
> > "email-admins-and-ceo".
> 
> I don't think it should be required that a Trigger use a pre-defined
> Notifier.   I think it's OK that we could have pre-defined Notifiers,
> although it may be necessary then to ensure only a
> proper subset are displayed, not just by Type but possibly tenant/user,
> etc.  So, the Trigger definer could select an existing Notifier, or
> supply an ad-hoc property-set.
> 


+1 

Exactly, I was referring to pre-defined triggers "available" in the persistence/repository, but not prefilled in the Trigger definition.

I was thinking more like an UI role, that when I'm in the UI create-new-trigger page, I would like to see at least a couple of pre-defined notifiers.
(i.e. console, or something like that, I don't know, it's an open point).


> I expect a NotifierType could have optional and required properties.
> Above, "to" would be required and "template" would likely be optional,
> with some default text.
> 


+1


> > A plugin can have properties that are shared for all plugin.
> > (i.e. the server/gateway used for email/snmp/sms).
> 
> I'm not sure I understand, but I'm not sure we need to have
> shared/global properties for the NotifierType plugins.  It seems a
> self-contained plugin may be best.
> 


My use case is the following: we have a new plugin to send info through a mobile gateway, and that gateway can be changed, let's say by and admin.
Instead of change that property in a configuration file of the plugin at deployment phase, I was thinking that option can be available for UI.

Of course, this can have sense in some scenarios, for example, an email plugin that needs a email server configured in an standalone.xml can't use this scenario, as it could not change this info.

But as the API was generic, I was considering to introduce this feature in an optional way.


> > A notifier can have specific properties.
> > (i.e. list of destination, decoration of the message, other).
> >
> >
> > Req3: There should be a central way where plugins are notifier are
> > available
> > ----------------------------------------------------------------------------
> >
> > New triggers definitions will be create through UI, so in the API we need
> > to perform:
> > - Get the list of notifiers created in the system (for an specific plugin
> > or all plugins).
> > - Link a notifier with a specific trigger(s) definition(s).
> > - Create a new notifier of a specific type.
> 
> Right, we only need the first thing is we persist Notifiers.  We
> definitely need the ability to define an ad-hoc Notifier for a Trigger.
> 
> 
> > Req4: Alerts engine sends alerts in a decoupled way
> > ---------------------------------------------------
> >
> > Alerts engine is responsible to process data and to infer which alerts have
> > to be sent.
> > The alert engine should provide a decoupled way to send a notification
> > through the notifier attached.
> 
> I agree.  The engine should be responsible for generating Alerts. For
> Hawkular the Alerts should be "tagged" with (perhaps JMS Headers for
> filtering) and likely be publish to a TriggeredAlerts topic for
> consumption by NotifierType plugins, and possibly anything else
> interested in generated alerts.
> 


+1

That's the current design.
Just a detail comment, the communication to/from the bus is done under the hawkular-alerts-bus project, to maintain the scheme that the engine should be decoupled from any explicit bus dependency.


> > ===
> >
> > There are also some technical requeriments that we are following in the
> > current approach:
> >
> > TechReq1: Alerts engine should work in a decoupled way from other
> > components
> > ----------------------------------------------------------------------------
> >
> > The alerts engine implementation should not have a strong dependency with
> > the bus component
> > or any specific plugin implementation.
> > So, the engine should be able to run in the whole hawkular architecture or
> > it can be reusable
> > for third party scenarios where other developers can create their own
> > notifications architecture.
> 
> I think this is fine.  It means that some of the Hawkular-Alerts
> artifacts are independent of Hawkular "Kettle", although I don't think
> we need to split up the project repo.
> 
> 


+1

Yeap,  as I commented, the idea is that a possible third party user can use metrics/alerts/other just picking the engine, using the API and adding their own notifications mechanism without have to deal with JMS semantic or add extra dependencies.


> > More details of the architecture proposed are under this article:
> > https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
> >
> >
> > TechReq2: Notifications plugins flow
> > ------------------------------------
> >
> > A preliminar flow for the notifications plugins can be the following:
> >
> > - When a plugin is deployed, it should be registered, then it is
> > available/visible for the API.
> > - When a notifier is created through the UI using the API, a plugin should
> > be notified.
> 
> Why is this?  Why does the plugin need to know about the defined Notifiers?
> 


The idea is that UI can create a new notifier, so it uses the central API, so a new notifier is persisted.

In my first draft I was thinking that in an alert/notification message only is saved the notifierId, but not the full properties.

So, when a notifierId is created a plugin should receive this info (for example to cache this data, instead to query per each message what are the properties).

Another option is to add al notifier properties in the notification message, my first thought is that could be a lot of info.
(i.e. If we have a long template for a notifierId, in each notification message I don't need to send full template, but the plugin needs to know - and possible cache - this template).


> > - Main use case of the plugin is to listen for notifications messages to
> > process its specific sent.
> 
> I'm not sure it should be listening for notification messages but rather
> published Alerts, which would contain/include the Notifier
> configuration/properties.
> 


I guess that we are talking about the same, I understand a Notification message as a consequence of an Alert.

Perhaps, an Alert can create multiple notifications messages, for example, if a trigger definition has more than 1 notifier attached.

Of course, each notification message has its own header in the message to filter the specific plugin responsible for its processing.


> > TechReq3: Predefined notifiers
> > ------------------------------
> >
> > Notifiers can be pre-created from an initialization configuration.
> 
> Like other definitions, it should be possible to import/export
> Notifiers, if we persist them.
> 

+1

> > ===
> >
> > These are the requeriments used for the current draft of this area.
> > The idea of this thread is to discuss about it to clarify/explain/modify
> > it.
> >
> > After that I will try to collect all comments in a new article.
> >
> > Thanks in advance for your comments.
> >
> 
> One last comment.  I wonder if we should maybe avoid RHQ's "Notifier"
> terminology.  It is OK, but it became sort of clunky when you would say
> that performing an operation on a resource was a Notification.   Perhaps
> "Action" may be a better term?  So we have Trigger Actions and Trigger
> Action Plugins.   Just a thought...
> 
> 


+1

I'm using "notifier"/"notifier type"/"notification" wording just as a continuation of rhq terminology, but whatever that is more clear, the best.


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

From jsanda at redhat.com  Thu Feb 12 08:15:05 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 12 Feb 2015 08:15:05 -0500 (EST)
Subject: [Hawkular-dev] Intro to Cassandra
Message-ID: <1548866859.11173651.1423746905411.JavaMail.zimbra@redhat.com>

The following is a new meeting request:

Subject: Intro to Cassandra  
Organizer: "John Sanda" <jsanda at redhat.com> 

Location: bluejeans 
Time: Friday, February 13, 2015, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: hawkular-dev at lists.jboss.org 


*~*~*~*~*~*~*~*~*~*

I will cover topics such as, 

* High availability 
* Consistency 
* Fault tolerance 
* Data modeling 

Assumes no prior knowledge of or experience with Cassandra. 

--- 

Meeting URL: https://bluejeans.com/217788152 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1607 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150212/7ed4753b/attachment.bin 

From lzoubek at redhat.com  Thu Feb 12 08:38:40 2015
From: lzoubek at redhat.com (Libor Zoubek)
Date: Thu, 12 Feb 2015 14:38:40 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1423661014.17656.1.camel@vrockai-laptop>
References: <1423661014.17656.1.camel@vrockai-laptop>
Message-ID: <op.xtx5iqxeyqhume@localhost.localdomain>

I'd like to bring

4. when returning collections from api. I think we should not stick with  
simply returning an array of objects. When we in future realize we need to  
include paging info or other helper data, we'd have to break the API and  
transform the response to somethine like

{
  "result":[{....},{...}],
  "paging"...
}

Yes .. in case of paging, we can put it into HTTP headers, but for client  
it is much easier to reach paging info from the response.

So simply wrapping returned array into response object does not hurt at  
all, brings consistency (data is always provided under same key "result")  
and extensibility.

I can see this trend in other projects - Foreman's moved to this concept  
in REST APIv2, and ie. djangorestframework or Kodi.

Libor

Dne Wed, 11 Feb 2015 14:23:34 +0100 Viliam Rockai <vrockai at redhat.com>  
napsal(a):

> Hi,
>
> I'm looking at hawkular-inventory and I've got several comments (liveoak
> legacy) which could apply on other rest endpoints, too:
>
> 1. I think it would be easier to use/get if we make it more
> hierarchical. That means; instead of using two distinct URLs (resources
> vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> only one (/hawkular/inventory/rest-test/resources/x1422733176502).
>
> 2. Sometimes, in the docs, attribute called "name" is used, and referred
> to, as an "id". Would it be possible and make sense to choose just one
> notation and use it in the representation?
>
> 3. Usage of methods: When you want to create a metric, you use the PUT
> method. What about unifying methods in some commonly used manner. Like
> post for create, put for edit?
>
> WDYT?
>
> Viliam
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


-- 
Libor Zoubek

From tsegismo at redhat.com  Thu Feb 12 11:20:59 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 12 Feb 2015 17:20:59 +0100
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
Message-ID: <54DCD2EB.2070402@redhat.com>

Le 11/02/2015 10:40, Lucas Ponce a ?crit :
> Req2: There are two concepts: plugin (notifier type) and notifier
> -----------------------------------------------------------------
>
> A plugin will be responsible of a type of notifications
> (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
>
> A notifier is a representation of a destination with status about how it has to process the notification.
> A notifier can be reused in several triggers definitions.
> (i.e. in json pseudo-format
>        { notifierId: "email-admins-and-ceo",
>          properties: {
>                NotifierType: "email",
>                to: ["admin1 at corp.org","admin2 at corp.org","cep at corp.org"]
>                template: "Incident in %MSG% at %TIME%. Alert description: %ALERT_DETAILS% ..."
>                }
>        }
> )
>
> So, we can have several triggers definitions that will use the notifier "email-admins-and-ceo".

We can have various notifiers for a single trigger definition, right?

RHQ lets you define different notifications for the same alert 
definition. Like: when server goes down:
- email admins and ceo
- send an snmp trap to space
- turn the fire sprinkler system on in the developers' openspace

From lponce at redhat.com  Thu Feb 12 11:33:15 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 12 Feb 2015 11:33:15 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <54DCD2EB.2070402@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
	<54DCD2EB.2070402@redhat.com>
Message-ID: <439516145.11198605.1423758795783.JavaMail.zimbra@redhat.com>

> 
> Le 11/02/2015 10:40, Lucas Ponce a ?crit :
> > Req2: There are two concepts: plugin (notifier type) and notifier
> > -----------------------------------------------------------------
> >
> > A plugin will be responsible of a type of notifications
> > (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
> >
> > A notifier is a representation of a destination with status about how it
> > has to process the notification.
> > A notifier can be reused in several triggers definitions.
> > (i.e. in json pseudo-format
> >        { notifierId: "email-admins-and-ceo",
> >          properties: {
> >                NotifierType: "email",
> >                to: ["admin1 at corp.org","admin2 at corp.org","cep at corp.org"]
> >                template: "Incident in %MSG% at %TIME%. Alert description:
> >                %ALERT_DETAILS% ..."
> >                }
> >        }
> > )
> >
> > So, we can have several triggers definitions that will use the notifier
> > "email-admins-and-ceo".
> 
> We can have various notifiers for a single trigger definition, right?
> 
> RHQ lets you define different notifications for the same alert
> definition. Like: when server goes down:
> - email admins and ceo
> - send an snmp trap to space
> - turn the fire sprinkler system on in the developers' openspace

Yes, the trigger definition can have a list of notifier, so that scenario is possible.



From tsegismo at redhat.com  Thu Feb 12 11:42:47 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 12 Feb 2015 17:42:47 +0100
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
Message-ID: <54DCD807.7090609@redhat.com>

Le 11/02/2015 10:40, Lucas Ponce a ?crit :
> Req3: There should be a central way where plugins are notifier are available
> ----------------------------------------------------------------------------
>
> New triggers definitions will be create through UI, so in the API we need to perform:
> - Get the list of notifiers created in the system (for an specific plugin or all plugins).
> - Link a notifier with a specific trigger(s) definition(s).

It feels more natural to me to attach a trigger definition to different 
notifiers.

> - Create a new notifier of a specific type.

How would the UI/engine know about the properties needed to configure a 
notifier?

The UI would also need some hints to display input fields. Like: this 
notifier property is a template, it needs a textarea instead of a text 
input.

From tsegismo at redhat.com  Thu Feb 12 11:44:47 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 12 Feb 2015 17:44:47 +0100
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <54DCD807.7090609@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
	<54DCD807.7090609@redhat.com>
Message-ID: <54DCD87F.8010700@redhat.com>

Le 12/02/2015 17:42, Thomas Segismont a ?crit :
> It feels more natural to me to attach a trigger definition to different
> notifiers.

Maybe bad wording. I meant attach different notifiers to a trigger 
definition.

From vrockai at redhat.com  Thu Feb 12 11:45:39 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Thu, 12 Feb 2015 17:45:39 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <op.xtx5iqxeyqhume@localhost.localdomain>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<op.xtx5iqxeyqhume@localhost.localdomain>
Message-ID: <1423759539.1996.2.camel@vrockai-laptop>

On Thu, 2015-02-12 at 14:38 +0100, Libor Zoubek wrote:
> I'd like to bring
> 
> 4. when returning collections from api. I think we should not stick with  
> simply returning an array of objects. When we in future realize we need to  
> include paging info or other helper data, we'd have to break the API and  
> transform the response to somethine like

+1, good point

> 
> {
>   "result":[{....},{...}],
>   "paging"...
> }
> 
> Yes .. in case of paging, we can put it into HTTP headers, but for client  
> it is much easier to reach paging info from the response.
> 
> So simply wrapping returned array into response object does not hurt at  
> all, brings consistency (data is always provided under same key "result")  
> and extensibility.
> 
> I can see this trend in other projects - Foreman's moved to this concept  
> in REST APIv2, and ie. djangorestframework or Kodi.
> 
> Libor
> 
> Dne Wed, 11 Feb 2015 14:23:34 +0100 Viliam Rockai <vrockai at redhat.com>  
> napsal(a):
> 
> > Hi,
> >
> > I'm looking at hawkular-inventory and I've got several comments (liveoak
> > legacy) which could apply on other rest endpoints, too:
> >
> > 1. I think it would be easier to use/get if we make it more
> > hierarchical. That means; instead of using two distinct URLs (resources
> > vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
> > entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
> > only one (/hawkular/inventory/rest-test/resources/x1422733176502).
> >
> > 2. Sometimes, in the docs, attribute called "name" is used, and referred
> > to, as an "id". Would it be possible and make sense to choose just one
> > notation and use it in the representation?
> >
> > 3. Usage of methods: When you want to create a metric, you use the PUT
> > method. What about unifying methods in some commonly used manner. Like
> > post for create, put for edit?
> >
> > WDYT?
> >
> > Viliam
> >
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 



From lponce at redhat.com  Thu Feb 12 11:45:53 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 12 Feb 2015 11:45:53 -0500 (EST)
Subject: [Hawkular-dev] [Alerts] Requeriments for notifications and
 current work
In-Reply-To: <54DCD807.7090609@redhat.com>
References: <1383608985.10027026.1423647608090.JavaMail.zimbra@redhat.com>
	<54DCD807.7090609@redhat.com>
Message-ID: <1110795776.11206243.1423759553395.JavaMail.zimbra@redhat.com>


> 
> Le 11/02/2015 10:40, Lucas Ponce a ?crit :
> > Req3: There should be a central way where plugins are notifier are
> > available
> > ----------------------------------------------------------------------------
> >
> > New triggers definitions will be create through UI, so in the API we need
> > to perform:
> > - Get the list of notifiers created in the system (for an specific plugin
> > or all plugins).
> > - Link a notifier with a specific trigger(s) definition(s).
> 
> It feels more natural to me to attach a trigger definition to different
> notifiers.
>

I was thinking more in the UI flow:

- I create a trigger definition.
- Set conditions.
- Set the notifier (from a notifier list or I can create a new one).
 
> > - Create a new notifier of a specific type.
> 
> How would the UI/engine know about the properties needed to configure a
> notifier?
> 
> The UI would also need some hints to display input fields. Like: this
> notifier property is a template, it needs a textarea instead of a text
> input.

+1

That's why we have the notifierType REST end point, the UI can have what are the properties for an specific notifier Type (i.e. email, snmp, sms).


From lkrejci at redhat.com  Thu Feb 12 12:03:47 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 12 Feb 2015 18:03:47 +0100
Subject: [Hawkular-dev] [inventory] API beyond the MVP
Message-ID: <3138385.mlsrQnEbdS@localhost.localdomain>

Hey,

I just created a PR https://github.com/hawkular/hawkular-inventory/pull/10 
with my idea about how the "true" inventory API could look like + an 
implementation of that idea on top of Tinkerpop Blueprints graph API.

A lot of stuff is missing there but they should hopefully fit in the basic 
picture outlined in the PR.

I kindly ask for your comments and ideas about it. It does not exactly follow 
the ideas we were talking about in the various design talks but I think it 
captures the essence of them.

Thanks,

Lukas

From crobson at redhat.com  Thu Feb 12 17:25:37 2015
From: crobson at redhat.com (Catherine Robson)
Date: Thu, 12 Feb 2015 17:25:37 -0500
Subject: [Hawkular-dev] Alerts - Response Time and Downtime requirements
Message-ID: <54DD2861.3020909@redhat.com>

Hi -

We see that alerting on response time and downtime are part of what we 
hope to provide in the first iteration of Hawkular.  We'd like to get 
started on the designs related to alert definition/configuration.  I'm 
hoping that you can all share some of the requirements around alert 
definitions that you think we need to have for Hawkular at this point.  
I don't want to overdo it by looking at JON - I'd like to start simple.  
Here's the requirements for the web console as I currently am thinking 
of them, but would like the team to comment on them and add/remove 
requirements as you see necessary.

Overall Alerts
As an administrator of a website, I would like to have all alerts sent 
to me through e-mail.
Ad an administrator of a website, I would like to have all alerts sent 
to me via text message.

Downtime
As an administrator of a website, I would like to configure Hawkular so 
an alert is sent to me every time the system goes down.
As an administrator of a website, I would like to configure Hawkular so 
an alert is only sent to me after the system is down for a certain 
length of time, so I'm not alerted if there is a very minor downtime event.

Response time
As an administrator of a website, I would like to configure Hawkular to 
alert me when my website's response time is slower than a threshold I 
have set so I know there may be performance problems.

Are there any other "settings" to the alerts that we should be 
considering at this point?

Thanks,
Catherine
-- 
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/20150212/f67c8a08/attachment.html 

From theute at redhat.com  Fri Feb 13 04:22:59 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Feb 2015 10:22:59 +0100
Subject: [Hawkular-dev] Alerts - Response Time and Downtime requirements
In-Reply-To: <54DD2861.3020909@redhat.com>
References: <54DD2861.3020909@redhat.com>
Message-ID: <54DDC273.2050501@redhat.com>


On 02/12/2015 11:25 PM, Catherine Robson wrote:
> Hi -
>
> We see that alerting on response time and downtime are part of what we 
> hope to provide in the first iteration of Hawkular.  We'd like to get 
> started on the designs related to alert definition/configuration.  I'm 
> hoping that you can all share some of the requirements around alert 
> definitions that you think we need to have for Hawkular at this 
> point.  I don't want to overdo it by looking at JON - I'd like to 
> start simple. 
+1
> Here's the requirements for the web console as I currently am thinking 
> of them, but would like the team to comment on them and add/remove 
> requirements as you see necessary.
>
> Overall Alerts
> As an administrator of a website, I would like to have all alerts sent 
> to me through e-mail.
> Ad an administrator of a website, I would like to have all alerts sent 
> to me via text message.

That may be implicit but:
     - As an administrator of a website, I would like to have all alerts 
listed only to the console.

We may not implement SMS right from the beginning but having 2 ways may 
be good to initiate the design. (Later we should embed Aerogear UPS and 
have a small app for push on phones, note to potential readers, a good 
student subject or contribution).

1 important thing:
     - we need some alert "profiles", if I look at my 1000s resources I 
may want them all to follow a same profile and when I want to change who 
receive an email I should do that in a single place (and not go through 
the 1000s resources). There would be several profiles.

3 potential improvements that we may want to think about in the design 
right now (or not):
     - Different addressee: Support for sending email/SMS to someone 
else but the owner
     - Escalamation: if resource is down for 5 min, send me (or someone 
else) an email, if still down after 30min send me a SMS
     - Multiple alerts for 1 particular event: if resource is down for 5 
min, send me an email, send my boss an email and send the IT guy a SMS


> Downtime
> As an administrator of a website, I would like to configure Hawkular 
> so an alert is sent to me every time the system goes down.
> As an administrator of a website, I would like to configure Hawkular 
> so an alert is only sent to me after the system is down for a certain 
> length of time, so I'm not alerted if there is a very minor downtime 
> event.
+1
>
> Response time
> As an administrator of a website, I would like to configure Hawkular 
> to alert me when my website's response time is slower than a threshold 
> I have set so I know there may be performance problems.
It would have to be for some configurable period of time
>
> Are there any other "settings" to the alerts that we should be 
> considering at this point?

At some point in the future we may want to have a warning state, but I 
don't want to surcharge this thread :)

Thomas
> Thanks,
> Catherine
> -- 
> Catherine Robson
> User Experience Design
> Red Hat JBoss Middleware
> c: 978-944-3825
>
>
>
> _______________________________________________
> 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/20150213/797b6d57/attachment-0001.html 

From theute at redhat.com  Fri Feb 13 07:01:04 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Feb 2015 13:01:04 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
Message-ID: <54DDE780.1050207@redhat.com>


Getting back to availability discussion...

To me availability is a set of periods, not so much "time series" and we 
should just record change of status (closing the previous event and 
opening a new one).

     - Server is up from 8:00am to 11:30am
     - Server is down from 11:30am to 11:32am
     - Server is unknown from 11:32am to 12:00pm (an agent running on a 
machine can tell if a server is up or down, if the agent dies then we 
don't know if the server is up or down)
     - Server is in erratic state from 12:00pm to 12:30pm (agent reports 
down every few requests)

We were discussing the best way to represent availability over time in a 
graph, representation in RHQ [1] is very decent IMO, can be extended 
with more colors to reflect how often/long the website was down for each 
"brick" (if the line represent a year with 52 blocks, 1 block can be 
more or less red depending on how long it was done during the week).

But thinking of it more, availability graph is not that interesting by 
itself IMO and more interesting in the context of other values.
I attached a mockup of what I meant, a red area is displayed on response 
time graph, that means that the system is down, obviously there is no 
response time reported anymore in that period. Earlier there is an 
erratic area, seems related to higher response time ;) Rest of the time 
the system is just up and running...

Additionally I would want to see reports of availability:
     - overall availability over a period of time (a day, a month, a 
year...). "99.99% available in the past month"
     - lists of the down periods with start dates and duration for a 
particular resource or set of resources (filtering options)

Thoughts ?

[1] 
http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: responsetime_availability.png
Type: image/png
Size: 84334 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150213/c2c5e12f/attachment-0001.png 

From crobson at redhat.com  Fri Feb 13 07:32:44 2015
From: crobson at redhat.com (Catherine Robson)
Date: Fri, 13 Feb 2015 07:32:44 -0500
Subject: [Hawkular-dev] Alerts - Response Time and Downtime requirements
In-Reply-To: <54DDC273.2050501@redhat.com>
References: <54DD2861.3020909@redhat.com> <54DDC273.2050501@redhat.com>
Message-ID: <54DDEEEC.5090902@redhat.com>



> Thomas Heute <mailto:theute at redhat.com>
> February 13, 2015 at 4:22 AM
>
> On 02/12/2015 11:25 PM, Catherine Robson wrote:
>> Hi -
>>
>> We see that alerting on response time and downtime are part of what 
>> we hope to provide in the first iteration of Hawkular.  We'd like to 
>> get started on the designs related to alert 
>> definition/configuration.  I'm hoping that you can all share some of 
>> the requirements around alert definitions that you think we need to 
>> have for Hawkular at this point.  I don't want to overdo it by 
>> looking at JON - I'd like to start simple. 
> +1
>> Here's the requirements for the web console as I currently am 
>> thinking of them, but would like the team to comment on them and 
>> add/remove requirements as you see necessary.
>>
>> Overall Alerts
>> As an administrator of a website, I would like to have all alerts 
>> sent to me through e-mail.
>> Ad an administrator of a website, I would like to have all alerts 
>> sent to me via text message.
>
> That may be implicit but:
>     - As an administrator of a website, I would like to have all 
> alerts listed only  to the console.
Ha! Right :)
>
> We may not implement SMS right from the beginning but having 2 ways 
> may be good to initiate the design. (Later we should embed Aerogear 
> UPS and have a small app for push on phones, note to potential 
> readers, a good student subject or contribution).
>
> 1 important thing:
>     - we need some alert "profiles", if I look at my 1000s resources I 
> may want them all to follow a same profile and when I want to change 
> who receive an email I should do that in a single place (and not go 
> through the 1000s resources). There would be several profiles.
Great - this makes sense.  Do we need to hand enter user information 
(e-mails/phones) or can some of this information be gathered through 
KeyCloak potentially? To clarify exactly what we think a "profile" 
contains - please verify below.

An alert profile is a place where users can set up alerting contact 
information and rules for many resources.  An alert profile contains:

  * A name & description
  * Contact information of everyone associated with this profile (auto
    or manual?)
  * A group of resources this profile applies to

Another alternative is that the resources are not mentioned in the 
profile, and you just assign the profile when you're working in the 
resources.  This feels much more like an "Alert contact group" than a 
profile to me in that case, so it is just a terminology change I think 
to make it clearer for what to expect from this capability.
>
> 3 potential improvements that we may want to think about in the design 
> right now (or not):
>     - Different addressee: Support for sending email/SMS to someone 
> else but the owner
Let me see if I can expand on this use case to make sure we're all on 
the same page.

Precondition:  An alert fired.  It was sent to person A.
Step 1: User sees the alert, and wants to "share" this alert with person B.
Step 2: User manually enters Person B's e-mail or SMS information.
Step 2 alternate:  User selects from a dropdown list of existing known 
users to find Person B, and Person B's preferred contact method is used 
for sending the alert.
End Goal:  Alert is sent to Person B based on the method chosen above.
>     - Escalamation: if resource is down for 5 min, send me (or someone 
> else) an email, if still down after 30min send me a SMS
Could this use those alert profiles too?
>     - Multiple alerts for 1 particular event: if resource is down for 
> 5 min, send me an email, send my boss an email and send the IT guy a SMS

>
>
>> Downtime
>> As an administrator of a website, I would like to configure Hawkular 
>> so an alert is sent to me every time the system goes down.
>> As an administrator of a website, I would like to configure Hawkular 
>> so an alert is only sent to me after the system is down for a certain 
>> length of time, so I'm not alerted if there is a very minor downtime 
>> event.
> +1
>>
>> Response time
>> As an administrator of a website, I would like to configure Hawkular 
>> to alert me when my website's response time is slower than a 
>> threshold I have set so I know there may be performance problems.
> It would have to be for some configurable period of time
Ok - so you would never want to alert if we go over *at all* for this 
metric, you would only ever want to alert based on a time interval it 
was above the threshold for.
>>
>> Are there any other "settings" to the alerts that we should be 
>> considering at this point?
>
> At some point in the future we may want to have a warning state, but I 
> don't want to surcharge this thread :)
>
> Thomas
>> Thanks,
>> Catherine
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> Catherine Robson <mailto:crobson at redhat.com>
> February 12, 2015 at 5:25 PM
> Hi -
>
> We see that alerting on response time and downtime are part of what we 
> hope to provide in the first iteration of Hawkular.  We'd like to get 
> started on the designs related to alert definition/configuration.  I'm 
> hoping that you can all share some of the requirements around alert 
> definitions that you think we need to have for Hawkular at this 
> point.  I don't want to overdo it by looking at JON - I'd like to 
> start simple.  Here's the requirements for the web console as I 
> currently am thinking of them, but would like the team to comment on 
> them and add/remove requirements as you see necessary.
>
> Overall Alerts
> As an administrator of a website, I would like to have all alerts sent 
> to me through e-mail.
> Ad an administrator of a website, I would like to have all alerts sent 
> to me via text message.
>
> Downtime
> As an administrator of a website, I would like to configure Hawkular 
> so an alert is sent to me every time the system goes down.
> As an administrator of a website, I would like to configure Hawkular 
> so an alert is only sent to me after the system is down for a certain 
> length of time, so I'm not alerted if there is a very minor downtime 
> event.
>
> Response time
> As an administrator of a website, I would like to configure Hawkular 
> to alert me when my website's response time is slower than a threshold 
> I have set so I know there may be performance problems.
>
> Are there any other "settings" to the alerts that we should be 
> considering at this point?
>
> Thanks,
> Catherine

-- 
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/20150213/9507dec4/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1230 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150213/9507dec4/attachment.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/20150213/9507dec4/attachment-0001.jpg 

From theute at redhat.com  Fri Feb 13 08:07:41 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 Feb 2015 14:07:41 +0100
Subject: [Hawkular-dev] Alerts - Response Time and Downtime requirements
In-Reply-To: <54DDEEEC.5090902@redhat.com>
References: <54DD2861.3020909@redhat.com> <54DDC273.2050501@redhat.com>
	<54DDEEEC.5090902@redhat.com>
Message-ID: <54DDF71D.6000504@redhat.com>


On 02/13/2015 01:32 PM, Catherine Robson wrote:
>
>
>> Thomas Heute <mailto:theute at redhat.com>
>> February 13, 2015 at 4:22 AM
>>
>> On 02/12/2015 11:25 PM, Catherine Robson wrote:
>>> Hi -
>>>
>>> We see that alerting on response time and downtime are part of what 
>>> we hope to provide in the first iteration of Hawkular.  We'd like to 
>>> get started on the designs related to alert 
>>> definition/configuration.  I'm hoping that you can all share some of 
>>> the requirements around alert definitions that you think we need to 
>>> have for Hawkular at this point. I don't want to overdo it by 
>>> looking at JON - I'd like to start simple. 
>> +1
>>> Here's the requirements for the web console as I currently am 
>>> thinking of them, but would like the team to comment on them and 
>>> add/remove requirements as you see necessary.
>>>
>>> Overall Alerts
>>> As an administrator of a website, I would like to have all alerts 
>>> sent to me through e-mail.
>>> Ad an administrator of a website, I would like to have all alerts 
>>> sent to me via text message.
>>
>> That may be implicit but:
>>     - As an administrator of a website, I would like to have all 
>> alerts listed only  to the console.
> Ha! Right :)
>>
>> We may not implement SMS right from the beginning but having 2 ways 
>> may be good to initiate the design. (Later we should embed Aerogear 
>> UPS and have a small app for push on phones, note to potential 
>> readers, a good student subject or contribution).
>>
>> 1 important thing:
>>     - we need some alert "profiles", if I look at my 1000s resources 
>> I may want them all to follow a same profile and when I want to 
>> change who receive an email I should do that in a single place (and 
>> not go through the 1000s resources). There would be several profiles.
> Great - this makes sense.  Do we need to hand enter user information 
> (e-mails/phones) or can some of this information be gathered through 
> KeyCloak potentially? 
I think a "contact list" would make sense (and use Keycloak) for email 
and SMS (and later for mobile push). Not necessarily in the first 
iteration though.
> To clarify exactly what we think a "profile" contains - please verify 
> below.
>
> An alert profile is a place where users can set up alerting contact 
> information and rules for many resources.  An alert profile contains:
>
>   * A name & description
>
Yes a user may choose to have various profiles depending on the gravity 
of the problem, or set of machines (different people in charge) so he 
needs to identify the profile easily.
>
>   * Contact information of everyone associated with this profile (auto
>     or manual?)
>
This would be explicitely listed, we may need to add "shortcuts" at some 
point for instance if a resource has an "owner" we may want to be able 
to send an email to the "owner" of the affected resource rather than a 
fix person, but that's already more advanced.
>
>   * A group of resources this profile applies to
>

> Another alternative is that the resources are not mentioned in the 
> profile, and you just assign the profile when you're working in the 
> resources.  This feels much more like an "Alert contact group" than a 
> profile to me in that case, so it is just a terminology change I think 
> to make it clearer for what to expect from this capability.

A user could be interested to check which resources are affected before 
making a change, but that doesn't need to be prominent.

I took the example of changing the email "Alert contact group", but it 
could be changing the acceptable response time for all servers. So an 
additional point would be

  * Alert conditions


So one example of an "alert profile"
     - Name: "Neuchatel Datacenter Critical issue"
     - Description: "blah blah"
     - Condition: "Down for 10min"
     - Alerts: "Email bob immediately", "SMS mary after 20min if still down"

That profile would normally be applied to all EAP servers in Neuchatel 
datacenter. If bob gets fired, someone comes in and change the email to 
someone else in that alert profile. If the neuchatel datacenter becomes 
more critical, someone comes in and change "Down for 10min" to "Down for 
2 min"



>>
>> 3 potential improvements that we may want to think about in the 
>> design right now (or not):
>>     - Different addressee: Support for sending email/SMS to someone 
>> else but the owner
> Let me see if I can expand on this use case to make sure we're all on 
> the same page.
>
> Precondition:  An alert fired.  It was sent to person A.
> Step 1: User sees the alert, and wants to "share" this alert with 
> person B.
> Step 2: User manually enters Person B's e-mail or SMS information.
> Step 2 alternate:  User selects from a dropdown list of existing known 
> users to find Person B, and Person B's preferred contact method is 
> used for sending the alert.
> End Goal:  Alert is sent to Person B based on the method chosen above.

I really just meant that we can send the email to someone else than the 
logged-in user

>>     - Escalamation: if resource is down for 5 min, send me (or 
>> someone else) an email, if still down after 30min send me a SMS
> Could this use those alert profiles too?

Yes definitely.
(Sorry for that "Escalamation" typo :) I really meant escalation)

>>     - Multiple alerts for 1 particular event: if resource is down for 
>> 5 min, send me an email, send my boss an email and send the IT guy a SMS
>
>>
>>
>>> Downtime
>>> As an administrator of a website, I would like to configure Hawkular 
>>> so an alert is sent to me every time the system goes down.
>>> As an administrator of a website, I would like to configure Hawkular 
>>> so an alert is only sent to me after the system is down for a 
>>> certain length of time, so I'm not alerted if there is a very minor 
>>> downtime event.
>> +1
>>>
>>> Response time
>>> As an administrator of a website, I would like to configure Hawkular 
>>> to alert me when my website's response time is slower than a 
>>> threshold I have set so I know there may be performance problems.
>> It would have to be for some configurable period of time
> Ok - so you would never want to alert if we go over *at all* for this 
> metric, you would only ever want to alert based on a time interval it 
> was above the threshold for.

Right, unless we look at a percentile (or average) a single response 
time value outside the norm doesn't mean anything, this would only 
frustrate the person notified. So this needs to include some period of time.

Thomas

>>>
>>> Are there any other "settings" to the alerts that we should be 
>>> considering at this point?
>>
>> At some point in the future we may want to have a warning state, but 
>> I don't want to surcharge this thread :)
>>
>> Thomas
>>> Thanks,
>>> Catherine
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> Catherine Robson <mailto:crobson at redhat.com>
>> February 12, 2015 at 5:25 PM
>> Hi -
>>
>> We see that alerting on response time and downtime are part of what 
>> we hope to provide in the first iteration of Hawkular. We'd like to 
>> get started on the designs related to alert 
>> definition/configuration.  I'm hoping that you can all share some of 
>> the requirements around alert definitions that you think we need to 
>> have for Hawkular at this point.  I don't want to overdo it by 
>> looking at JON - I'd like to start simple.  Here's the requirements 
>> for the web console as I currently am thinking of them, but would 
>> like the team to comment on them and add/remove requirements as you 
>> see necessary.
>>
>> Overall Alerts
>> As an administrator of a website, I would like to have all alerts 
>> sent to me through e-mail.
>> Ad an administrator of a website, I would like to have all alerts 
>> sent to me via text message.
>>
>> Downtime
>> As an administrator of a website, I would like to configure Hawkular 
>> so an alert is sent to me every time the system goes down.
>> As an administrator of a website, I would like to configure Hawkular 
>> so an alert is only sent to me after the system is down for a certain 
>> length of time, so I'm not alerted if there is a very minor downtime 
>> event.
>>
>> Response time
>> As an administrator of a website, I would like to configure Hawkular 
>> to alert me when my website's response time is slower than a 
>> threshold I have set so I know there may be performance problems.
>>
>> Are there any other "settings" to the alerts that we should be 
>> considering at this point?
>>
>> Thanks,
>> Catherine
>
> -- 
> 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/20150213/9f7235dd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1230 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150213/9f7235dd/attachment-0002.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/20150213/9f7235dd/attachment-0003.jpg 

From vrockai at redhat.com  Fri Feb 13 09:08:34 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Fri, 13 Feb 2015 15:08:34 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1423661014.17656.1.camel@vrockai-laptop>
References: <1423661014.17656.1.camel@vrockai-laptop>
Message-ID: <1423836514.2011.4.camel@vrockai-laptop>

Hey all,

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

WDYT?

Viliam


From jpkroehling at redhat.com  Fri Feb 13 09:13:49 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 13 Feb 2015 15:13:49 +0100
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1423836514.2011.4.camel@vrockai-laptop>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<1423836514.2011.4.camel@vrockai-laptop>
Message-ID: <54DE069D.2080901@redhat.com>

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

On 02/13/2015 03:08 PM, Viliam Rockai wrote:
> 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):

My turn. Case:

Resource "resource1" belongs to user "user1".
User "user2" tries to access /resources/resource1 .

What should be the response? "Not found", because the resource
"resource1" doesn't exists on the context of "user2", or Forbidden,
because the resource exists in our database, but "user2" can't access it?

- - Juca.

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

iQEcBAEBAgAGBQJU3gadAAoJECKM1e+fkPrXJS8H/3KgcizkKZekW+PZV4HpwlMo
+9MPDMxtxnPtXq0o5GYTdEL3uRHVqRwMK04Fwx5dYJ+2bJQ9EXFK/hQhg0mWuHzh
kSKGwBQD+zDb9IPHVUSKoYvkkXBcZjsQscYL6uNA/TiTp8pT+JxTw6aRkSylW/95
UOdC8aoEZQqGzOO2tBcwiIoF7TXa+tVuY5TgV/ldydBCbQgPl2/iQY++Mwj4h6ri
VEacrDoGe0sNrrEMOJf4YvyCXgkVWdeaviscZ816LQ2dKFU4CocgY/0IeGwlwz9F
IDevKUWqbrj+UXSjZoUh+p2+7dSJyjob2jfHev+TayC7nlbj6/TrSmTK0t7O7qg=
=r0UU
-----END PGP SIGNATURE-----

From rhauch at redhat.com  Fri Feb 13 10:12:38 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 13 Feb 2015 09:12:38 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
Message-ID: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>

Forgive my ignorance, but I?m new to the list and I didn?t see anything in the archives about $subject, detailed below. Lately I?ve been very interested in several topics ancillary to monitoring, so I?m quite intrigued by the planned direction and approach.

How do clients/systems/services that are to be monitored actually send their monitorable information? What is the granularity of this information: is it already summarized or somewhat aggregated in the client, or is it very low-level and fine-grained events? What is the impact on the client of adding this extra overhead?

Do you have an estimate or goal for how much volume of incoming data can be handled without impacting on clients? What, if anything, does a client submission wait for on the back-end?

Also, how do you plan to ensure that, no matter what happens to the Hawkular system or anything it depends upon, no client information is every lost or dropped?

Finally, is the plan to make Hawkular embeddable (excluding the stuff that has to be embedded in monitored clients/systems/services), or only a separate turn-key (i.e., install-and-run-and-use) system?

Thanks!

Randall Hauch

From tsegismo at redhat.com  Fri Feb 13 11:49:36 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 13 Feb 2015 17:49:36 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
Message-ID: <54DE2B20.7040801@redhat.com>

Hi Randall,

Answers inline.

Le 13/02/2015 16:12, Randall Hauch a ?crit :
> Forgive my ignorance, but I?m new to the list and I didn?t see anything in the archives about $subject, detailed below. Lately I?ve been very interested in several topics ancillary to monitoring, so I?m quite intrigued by the planned direction and approach.
>
> How do clients/systems/services that are to be monitored actually send their monitorable information? What is the granularity of this information: is it already summarized or somewhat aggregated in the client, or is it very low-level and fine-grained events? What is the impact on the client of adding this extra overhead?

There are different options for sending:

1. External collectors
A collector running as independent process queries the monitored system, 
which exposes, somehow, runtime information. Then the collector sends 
the information Hawkular.
Examples: rhq agent, collectd, jmxtrans

2. Embedded collectors
Same as above, except that the collector runs in the same process as the 
monitored system.
Examples: Wildfly monitor, embedded-jmxtrans, codahale metrics (if 
configured with a reporter other than JMX)

3. Custom
Any solution which sends information to Hawkular without resorting to a 
collector.

Granularity is not enforced: at different points in time, you could send 
the values of a counter or send a locally computed derivative for the 
last minute.

The impact when sending information with a collector or embedded 
collector should be pretty low. Most of existing solutions do some sort 
of batching. With a custom sender, it all depends on how it's designed, 
obviously.

>
> Do you have an estimate or goal for how much volume of incoming data can be handled without impacting on clients? What, if anything, does a client submission wait for on the back-end?

Hawkular metrics is designed to be horizontally scalable so the volume 
of data you can absorb should depend on the number of machines you can 
throw in the game.

Most collectors buffer data to be sent and operate in separate threads. 
So if the metrics ingestion rate decreases, they'll consume more memory. 
Other than that, it should have limited impact on your service.

>
> Also, how do you plan to ensure that, no matter what happens to the Hawkular system or anything it depends upon, no client information is every lost or dropped?

Usually collectors will drop data once buffers are full. If you want to 
make sure no data is lost, then you need to build a custom sender. 
Hawkular metrics has an HTTP interface so the response code should tell 
you if a metric was successfully persisted.

>
> Finally, is the plan to make Hawkular embeddable (excluding the stuff that has to be embedded in monitored clients/systems/services), or only a separate turn-key (i.e., install-and-run-and-use) system?

Hawkular metrics comes in two forms:
* a Java library (metrics-core)
* a Java EE web application (built on top of the library)

metrics-core can be embedded in any sort of JVM application but it 
expects to find a Cassandra cluster somewhere.



I hope it helps. Feel free to ask for details.

And welcome to Hawkular!

Thomas

From rhauch at redhat.com  Fri Feb 13 12:43:42 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 13 Feb 2015 11:43:42 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <54DE2B20.7040801@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
Message-ID: <2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>

Thanks for the response, Thomas. I have more questions inline. Thanks for humoring me.

> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi Randall,
> 
> Answers inline.
> 
> Le 13/02/2015 16:12, Randall Hauch a ?crit :
>> Forgive my ignorance, but I?m new to the list and I didn?t see anything in the archives about $subject, detailed below. Lately I?ve been very interested in several topics ancillary to monitoring, so I?m quite intrigued by the planned direction and approach.
>> 
>> How do clients/systems/services that are to be monitored actually send their monitorable information? What is the granularity of this information: is it already summarized or somewhat aggregated in the client, or is it very low-level and fine-grained events? What is the impact on the client of adding this extra overhead?
> 
> There are different options for sending:
> 
> 1. External collectors
> A collector running as independent process queries the monitored system, 
> which exposes, somehow, runtime information. Then the collector sends 
> the information Hawkular.
> Examples: rhq agent, collectd, jmxtrans
> 
> 2. Embedded collectors
> Same as above, except that the collector runs in the same process as the 
> monitored system.
> Examples: Wildfly monitor, embedded-jmxtrans, codahale metrics (if 
> configured with a reporter other than JMX)
> 
> 3. Custom
> Any solution which sends information to Hawkular without resorting to a 
> collector.
> 
> Granularity is not enforced: at different points in time, you could send 
> the values of a counter or send a locally computed derivative for the 
> last minute.

What do the collectors submit? It seems like there are two options:

a) periodically capture metrics; or
b) capture every ?event of interest? whenever it occurs

IIUC, monitoring something like JMX-enabled system would likely be (a), but (b) is really where the value is. Yes, (b) is more invasive but it let?s you capture every possible activity and derive metrics accurately without losing transient spikes.

The problem with (a) is that you might miss important cases, since each captured metric represents a measurement at a single instant in time. Consider monitoring a system periodically (e.g., every 15 seconds) to obtain some metric (e.g., the size of a db connection pool, etc). If a spike occurs and is resolved *within a single interval*, then the captured metric will never reflect this, and any derived aggregate (max, min, aggregate) will also not reflect the spike.

Examples of (b) include low-level system information like "create database connection?, ?closed database connection?, ?start new thread?, ?stop thread?, etc., but it also includes recording business-related events, such as ?received request from user X from IP address A to read resource R?. The latter is insanely valuable, because customers can build downstream services that consume Hawkular output and get valuable business insight and perform business analytics. Those custom services can do all kinds of interesting things, such as automatically rate-limit requests from a specific user, bill based upon usage, audit access for compliance purposes, prevent DoS by rejecting requests from suspect IP addresses, etc.

This is what is called ?event sourcing?, and it records all interesting events and forms the basis for a lot of near-real-time analytics and monitoring solutions. And, an architecture designed for this purpose can do things will persist every event in a persistent transaction log, and services will consume this stream/log, do work, and output to other persistent logs/streams. These streams and services form a workflow, but it?s not quite the same as a traditional pub/sub set of services because each service consume the events at their own pace. The net effect is that you can take a service down for maintenance (or it can crash), and when it comes back up it will simply continue where it left off. Upstream services are unaffected, and downstream services just see a lull in events but otherwise are unaffected. Plus, you never lose any events or any data, and all aggregates and windowing (done in downstream services) are entirely accurate. You can even set up separate streams for windowed metrics (e.g., minute, hour, day, week, etc.)

Here?s an article that describes how LinkedIn is using stream-oriented processing to capture metrics and events for their systems, and how they derive benefit for the business: http://engineering.linkedin.com/samza/real-time-insights-linkedins-performance-using-apache-samza <http://engineering.linkedin.com/samza/real-time-insights-linkedins-performance-using-apache-samza>. They process 500 billion events per day (yes, billion). Here are a couple of other links: http://blog.confluent.io/2015/01/29/making-sense-of-stream-processing/ <http://blog.confluent.io/2015/01/29/making-sense-of-stream-processing/>, http://www.slideshare.net/InfoQ/samza-in-linkedin-how-linkedin-processes-billions-of-events-everyday-in-realtime <http://www.slideshare.net/InfoQ/samza-in-linkedin-how-linkedin-processes-billions-of-events-everyday-in-realtime>, http://scale-out-blog.blogspot.co.uk/2014/02/why-arent-all-data-immutable.html <http://scale-out-blog.blogspot.co.uk/2014/02/why-arent-all-data-immutable.html>, and the ever-essential http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying <http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying>


> 
> The impact when sending information with a collector or embedded 
> collector should be pretty low. Most of existing solutions do some sort 
> of batching. With a custom sender, it all depends on how it's designed, 
> obviously.

Sounds good.

> 
>> 
>> Do you have an estimate or goal for how much volume of incoming data can be handled without impacting on clients? What, if anything, does a client submission wait for on the back-end?
> 
> Hawkular metrics is designed to be horizontally scalable so the volume 
> of data you can absorb should depend on the number of machines you can 
> throw in the game.

How will the work be split up across the cluster? Are the incoming messages stored before they?re processed? 

> 
> Most collectors buffer data to be sent and operate in separate threads. 
> So if the metrics ingestion rate decreases, they'll consume more memory. 
> Other than that, it should have limited impact on your service.

Sounds good.

> 
>> 
>> Also, how do you plan to ensure that, no matter what happens to the Hawkular system or anything it depends upon, no client information is every lost or dropped?
> 
> Usually collectors will drop data once buffers are full. If you want to 
> make sure no data is lost, then you need to build a custom sender. 
> Hawkular metrics has an HTTP interface so the response code should tell 
> you if a metric was successfully persisted.

So I understand that the collectors will drop any buffered data, since that will be unsent if the monitored system (or external collectors) crash. But what happens if Hawkular suffers a partial or total crash? What data is lost? What happens to data that was in-process when the crash occurred? Stream-based architectures are interesting because they often can handle more load, partition it more effectively, and are more durable.

> 
>> 
>> Finally, is the plan to make Hawkular embeddable (excluding the stuff that has to be embedded in monitored clients/systems/services), or only a separate turn-key (i.e., install-and-run-and-use) system?
> 
> Hawkular metrics comes in two forms:
> * a Java library (metrics-core)
> * a Java EE web application (built on top of the library)
> 
> metrics-core can be embedded in any sort of JVM application but it 
> expects to find a Cassandra cluster somewhere.
> 
> 
> 
> I hope it helps. Feel free to ask for details.
> 
> And welcome to Hawkular!
> 
> Thomas
> _______________________________________________
> 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/20150213/46853ebf/attachment-0001.html 

From rhauch at redhat.com  Fri Feb 13 13:01:53 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 13 Feb 2015 12:01:53 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
Message-ID: <9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>

Oh, one more thing:

>> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com <mailto:tsegismo at redhat.com>> wrote:
>> ...
>> Hawkular metrics comes in two forms:
> 
>> * a Java library (metrics-core)
>> * a Java EE web application (built on top of the library)
>> 
>> metrics-core can be embedded in any sort of JVM application but it 
>> expects to find a Cassandra cluster somewhere.


I understand that the collectors will be libraries; you?ll probably eventually want these in multiple languages. But it sure seems strange to have the Hawkular engine (for lack of a better term) be a library. Not only is that more complicated to set up, but if you design it to be embeddable then it will be harder to also make it scale.

It sure seems easier to focus on only installing Hawkular as a separate (potentially distributed) system that is set up and used. Sure, config it to point to the Cassandra cluster. But that can be easily wrapped up in a Docker image that people download and simply start, pointing via ENV variables to a Cassandra instance/cluster (perhaps also started from a Docker image). Better still is that these Docker images can be wrapped in a Kubernetes pod (that uses a Cassandra pod) and deployed on OpenShift. Now you have Hawkular as a service, but still easily installed on a customer?s network.

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

From cpitman at redhat.com  Fri Feb 13 14:19:03 2015
From: cpitman at redhat.com (Chris Pitman)
Date: Fri, 13 Feb 2015 14:19:03 -0500 (EST)
Subject: [Hawkular-dev] About configuration
In-Reply-To: <1738676483.12357413.1423854651267.JavaMail.zimbra@redhat.com>
Message-ID: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>

Hey guys, 

I'm a bit late to the party, but here are my two cents as someone who has spent 
months integrating Puppet with EAP 6 ( https://github.com/cpitman/puppet-jboss_admin ). 

> > > 3) Why not try to have all our configuration set in standalone.xml? If we > > > are going to be deployed in Wildfly, it would be nice to have everything > > > (not just our config, but the config for the wildfly subsystems too) in > > > one place. This also allows us to piggyback on jboss-cli - we simply use
> > > the jboss-cli to have a cmdline interface to our configuration.
> > > > I'd rather keep our apps config out the Wildfly config. > What is your reasoning for wanting to keep our apps config out of Wildfly config?
> The reason why I say it would be nice to use standalone.xml for our config is:
> 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).
> 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems. 
The CLI is a painful way to automate deployment using declarative tools like Puppet. 
If the goal is to make it easy to configure and deploy, files are superior. Yes, 
standalone.xml is a file, but you can only edit it by shutting down the container 
first (and scripting doing this in Puppet is also non-fun). 

Not to say it impossible. The module I linked above could be used, but it is still 
vastly more complicated than a solution that just needs a templated config file. 
> 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.
> 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.
> The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.
> But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs. 

Chris Pitman 
Architect, Red Hat Consulting 
DevOps Community of Practice Manager 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150213/656cd1d3/attachment.html 

From miburman at redhat.com  Fri Feb 13 16:38:17 2015
From: miburman at redhat.com (Michael Burman)
Date: Fri, 13 Feb 2015 23:38:17 +0200
Subject: [Hawkular-dev] REST ideas
In-Reply-To: <1423836514.2011.4.camel@vrockai-laptop>
References: <1423661014.17656.1.camel@vrockai-laptop>
	<1423836514.2011.4.camel@vrockai-laptop>
Message-ID: <54DE6EC9.7020806@redhat.com>

Hi,

What's very important is that we don't try to redefine HTTP error codes. 
If there's an error code for it, then it should be used and it should be 
enough in most cases for the client to understand what happened.

I've seen some horrible APIs, which return generic error code and one 
should read the returned error message to understand what's wrong. 
That's not how a REST-interface should work.

   -  Micke

On 13.02.2015 16:08, Viliam Rockai wrote:
> Hey all,
>
> 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
>
> WDYT?
>
> Viliam
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From rhauch at redhat.com  Fri Feb 13 16:39:49 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 13 Feb 2015 15:39:49 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>
Message-ID: <A54C4742-4B42-4F6D-87EB-487F17FCE121@redhat.com>

Just posted today: Parse.ly?s time series backend is log-oriented and uses the same technology I discussed earlier. But they have details about data volumes and how they aggregate/window data. Might be useful.

http://blog.parsely.com/post/1633/mage/ <http://blog.parsely.com/post/1633/mage/>


> On Feb 13, 2015, at 12:01 PM, Randall Hauch <rhauch at redhat.com> wrote:
> 
> Oh, one more thing:
> 
>>> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com <mailto:tsegismo at redhat.com>> wrote:
>>> ...
>>> Hawkular metrics comes in two forms:
>> 
>>> * a Java library (metrics-core)
>>> * a Java EE web application (built on top of the library)
>>> 
>>> metrics-core can be embedded in any sort of JVM application but it 
>>> expects to find a Cassandra cluster somewhere.
> 
> 
> I understand that the collectors will be libraries; you?ll probably eventually want these in multiple languages. But it sure seems strange to have the Hawkular engine (for lack of a better term) be a library. Not only is that more complicated to set up, but if you design it to be embeddable then it will be harder to also make it scale.
> 
> It sure seems easier to focus on only installing Hawkular as a separate (potentially distributed) system that is set up and used. Sure, config it to point to the Cassandra cluster. But that can be easily wrapped up in a Docker image that people download and simply start, pointing via ENV variables to a Cassandra instance/cluster (perhaps also started from a Docker image). Better still is that these Docker images can be wrapped in a Kubernetes pod (that uses a Cassandra pod) and deployed on OpenShift. Now you have Hawkular as a service, but still easily installed on a customer?s network.
> 
> _______________________________________________
> 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/20150213/11583925/attachment.html 

From miburman at redhat.com  Fri Feb 13 17:18:37 2015
From: miburman at redhat.com (Michael Burman)
Date: Sat, 14 Feb 2015 00:18:37 +0200
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54DDE780.1050207@redhat.com>
References: <54DDE780.1050207@redhat.com>
Message-ID: <54DE783D.4030002@redhat.com>

Hi,

I disagree, seeing this pattern first hand in resulting large penalty 
payment on one case (inability to prove that monitoring reported up on 
certain time when it wasn't responsive). If there's a need to monitor 
availability, there must be recorded event flow, eg:

Up 11:00
Up 11:05
Up 11:10
Down 11:15
Down 11:20
Up 11:25

And why? If we only record:

Up 11:00 - 11:10
Down 11:15 - 11:20
Up 11:25 - ..

There's a difference. Did the monitoring system report 11:05 or was the 
monitoring system down 11:05? In many cases a need to prove that system 
was in certain state in certain times. Especially when there are SLA 
disagreements. Even more importantly, what happened between 11:10 - 
11:15 and 11:20 - 11:25?

The SLA behaviour requires that some system noticed something happening 
at certain point of time. And if there's issues with system 
responsibility say at 11:05, there needs to be a event showing that the 
system really did report up.

    - Micke


On 13.02.2015 14:01, Thomas Heute wrote:
>
> Getting back to availability discussion...
>
> To me availability is a set of periods, not so much "time series" and 
> we should just record change of status (closing the previous event and 
> opening a new one).
>
>     - Server is up from 8:00am to 11:30am
>     - Server is down from 11:30am to 11:32am
>     - Server is unknown from 11:32am to 12:00pm (an agent running on a 
> machine can tell if a server is up or down, if the agent dies then we 
> don't know if the server is up or down)
>     - Server is in erratic state from 12:00pm to 12:30pm (agent 
> reports down every few requests)
>
> We were discussing the best way to represent availability over time in 
> a graph, representation in RHQ [1] is very decent IMO, can be extended 
> with more colors to reflect how often/long the website was down for 
> each "brick" (if the line represent a year with 52 blocks, 1 block can 
> be more or less red depending on how long it was done during the week).
>
> But thinking of it more, availability graph is not that interesting by 
> itself IMO and more interesting in the context of other values.
> I attached a mockup of what I meant, a red area is displayed on 
> response time graph, that means that the system is down, obviously 
> there is no response time reported anymore in that period. Earlier 
> there is an erratic area, seems related to higher response time ;) 
> Rest of the time the system is just up and running...
>
> Additionally I would want to see reports of availability:
>     - overall availability over a period of time (a day, a month, a 
> year...). "99.99% available in the past month"
>     - lists of the down periods with start dates and duration for a 
> particular resource or set of resources (filtering options)
>
> Thoughts ?
>
> [1] 
> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
>
> Thomas
>
>
> _______________________________________________
> 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/20150214/7bf5e408/attachment-0001.html 

From mithomps at redhat.com  Fri Feb 13 22:23:29 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 13 Feb 2015 19:23:29 -0800
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <A54C4742-4B42-4F6D-87EB-487F17FCE121@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>
	<A54C4742-4B42-4F6D-87EB-487F17FCE121@redhat.com>
Message-ID: <A8810A52-E0C9-4EC7-A72F-6FC75017C804@redhat.com>


> On 13 Feb 2015, at 13:39, Randall Hauch <rhauch at redhat.com> wrote:
> 
> Just posted today: Parse.ly <http://parse.ly/>?s time series backend is log-oriented and uses the same technology I discussed earlier. But they have details about data volumes and how they aggregate/window data. Might be useful.
> 
> http://blog.parsely.com/post/1633/mage/ <http://blog.parsely.com/post/1633/mage/>
We had a conversation about the Pasre.ly tweet this morning on #hawkular.


> 
> 
>> On Feb 13, 2015, at 12:01 PM, Randall Hauch <rhauch at redhat.com <mailto:rhauch at redhat.com>> wrote:
>> 
>> Oh, one more thing:
>> 
>>>> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com <mailto:tsegismo at redhat.com>> wrote:
>>>> ...
>>>> Hawkular metrics comes in two forms:
>>> 
>>>> * a Java library (metrics-core)
>>>> * a Java EE web application (built on top of the library)
>>>> 
>>>> metrics-core can be embedded in any sort of JVM application but it 
>>>> expects to find a Cassandra cluster somewhere.
>> 
>> 
>> I understand that the collectors will be libraries; you?ll probably eventually want these in multiple languages. But it sure seems strange to have the Hawkular engine (for lack of a better term) be a library. Not only is that more complicated to set up, but if you design it to be embeddable then it will be harder to also make it scale.
>> 
>> It sure seems easier to focus on only installing Hawkular as a separate (potentially distributed) system that is set up and used. Sure, config it to point to the Cassandra cluster. But that can be easily wrapped up in a Docker image that people download and simply start, pointing via ENV variables to a Cassandra instance/cluster (perhaps also started from a Docker image). Better still is that these Docker images can be wrapped in a Kubernetes pod (that uses a Cassandra pod) and deployed on OpenShift. Now you have Hawkular as a service, but still easily installed on a customer?s network.
>> 
>> _______________________________________________
>> 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/20150213/0c2e6867/attachment.html 

From mazz at redhat.com  Sat Feb 14 00:19:54 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 14 Feb 2015 00:19:54 -0500 (EST)
Subject: [Hawkular-dev] nexus populated
In-Reply-To: <1071973582.12126122.1423890356426.JavaMail.zimbra@redhat.com>
Message-ID: <2121474528.12126807.1423891194527.JavaMail.zimbra@redhat.com>

(Almost) all our snapshots are now getting published to Nexus thanks to Stefan doing the grunt work.

However, inventory and pinger still need to be built locally (they are in different non-master branches, and their artifacts are not on nexus).

git clone git at github.com:pilhuhn/hawkular-inventory.git heiko-inv
cd heiko-inv
git co notifier
mvn clean install -DskipTests

git clone git at github.com:pilhuhn/hawkular.git heiko-hawk
cd heiko-hawk
git co pinger
mvn clean install -DskipTests

Once you do this, you can build the integration distribution, which is currently in hawkular repo under the branch mazz/integration-assembly:

git clone git at github.com:hawkular/hawkular.git
cd hawkular
git co mazz/integration-assembly
mvn clean install -Pdev

Go in target/wildfly*/bin and run standalone.sh to run the server. Its got bus, alerts, metrics, inventory, pinger and Cassandra running inside "the nest"

From theute at redhat.com  Mon Feb 16 04:49:12 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 16 Feb 2015 10:49:12 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54DE783D.4030002@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
Message-ID: <54E1BD18.5010905@redhat.com>



On 02/13/2015 11:18 PM, Michael Burman wrote:
> Hi,
>
> I disagree, seeing this pattern first hand in resulting large penalty
> payment on one case (inability to prove that monitoring reported up on
> certain time when it wasn't responsive). If there's a need to monitor
> availability, there must be recorded event flow, eg:
>
> Up 11:00
> Up 11:05
> Up 11:10
> Down 11:15
> Down 11:20
> Up 11:25
>
> And why? If we only record:
>
> Up 11:00 - 11:10
> Down 11:15 - 11:20
> Up 11:25 - ..
>
> There's a difference. Did the monitoring system report 11:05 or was the
> monitoring system down 11:05? In many cases a need to prove that system
> was in certain state in certain times. Especially when there are SLA
> disagreements. Even more importantly, what happened between 11:10 -
> 11:15 and 11:20 - 11:25?

Recording all datapoints doesn't give you more information on what 
happened between 2 recordings though.

But I get your point on the "inability to prove that monitoring reported 
up on certain time when it wasn't responsive".
I didn't see availability recording as SLA proofs though.

> The SLA behaviour requires that some system noticed something happening
> at certain point of time. And if there's issues with system
> responsibility say at 11:05, there needs to be a event showing that the
> system really did report up.

You can't prove that system is up and running at a special point in 
time, you can only prove over a period of time if you made enough checks 
(interval lesser than the period of time of the SLA).

Thomas

>
>     - Micke
>
>
> On 13.02.2015 14:01, Thomas Heute wrote:
>>
>> Getting back to availability discussion...
>>
>> To me availability is a set of periods, not so much "time series" and
>> we should just record change of status (closing the previous event and
>> opening a new one).
>>
>>     - Server is up from 8:00am to 11:30am
>>     - Server is down from 11:30am to 11:32am
>>     - Server is unknown from 11:32am to 12:00pm (an agent running on a
>> machine can tell if a server is up or down, if the agent dies then we
>> don't know if the server is up or down)
>>     - Server is in erratic state from 12:00pm to 12:30pm (agent
>> reports down every few requests)
>>
>> We were discussing the best way to represent availability over time in
>> a graph, representation in RHQ [1] is very decent IMO, can be extended
>> with more colors to reflect how often/long the website was down for
>> each "brick" (if the line represent a year with 52 blocks, 1 block can
>> be more or less red depending on how long it was done during the week).
>>
>> But thinking of it more, availability graph is not that interesting by
>> itself IMO and more interesting in the context of other values.
>> I attached a mockup of what I meant, a red area is displayed on
>> response time graph, that means that the system is down, obviously
>> there is no response time reported anymore in that period. Earlier
>> there is an erratic area, seems related to higher response time ;)
>> Rest of the time the system is just up and running...
>>
>> Additionally I would want to see reports of availability:
>>     - overall availability over a period of time (a day, a month, a
>> year...). "99.99% available in the past month"
>>     - lists of the down periods with start dates and duration for a
>> particular resource or set of resources (filtering options)
>>
>> Thoughts ?
>>
>> [1]
>> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
>>
>> Thomas
>>
>>
>> _______________________________________________
>> 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 Feb 16 05:03:49 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 16 Feb 2015 11:03:49 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
Message-ID: <54E1C085.2070702@redhat.com>

Le 13/02/2015 18:43, Randall Hauch a ?crit :
> Thanks for the response, Thomas. I have more questions inline. Thanks
> for humoring me.
>
>> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com
>> <mailto:tsegismo at redhat.com>> wrote:
>>
>> Hi Randall,
>>
>> Answers inline.
>>
>> Le 13/02/2015 16:12, Randall Hauch a ?crit :
>>> Forgive my ignorance, but I?m new to the list and I didn?t see
>>> anything in the archives about $subject, detailed below. Lately I?ve
>>> been very interested in several topics ancillary to monitoring, so
>>> I?m quite intrigued by the planned direction and approach.
>>>
>>> How do clients/systems/services that are to be monitored actually
>>> send their monitorable information? What is the granularity of this
>>> information: is it already summarized or somewhat aggregated in the
>>> client, or is it very low-level and fine-grained events? What is the
>>> impact on the client of adding this extra overhead?
>>
>> There are different options for sending:
>>
>> 1. External collectors
>> A collector running as independent process queries the monitored system,
>> which exposes, somehow, runtime information. Then the collector sends
>> the information Hawkular.
>> Examples: rhq agent, collectd, jmxtrans
>>
>> 2. Embedded collectors
>> Same as above, except that the collector runs in the same process as the
>> monitored system.
>> Examples: Wildfly monitor, embedded-jmxtrans, codahale metrics (if
>> configured with a reporter other than JMX)
>>
>> 3. Custom
>> Any solution which sends information to Hawkular without resorting to a
>> collector.
>>
>> Granularity is not enforced: at different points in time, you could send
>> the values of a counter or send a locally computed derivative for the
>> last minute.
>
> What do the collectors submit? It seems like there are two options:
>
> a) periodically capture metrics; or
> b) capture every ?event of interest? whenever it occurs

The collectors I've talked about earlier fall in category (a).

>
> IIUC, monitoring something like JMX-enabled system would likely be (a),
> but (b) is really where the value is. Yes, (b) is more invasive but it
> let?s you capture every possible activity and derive metrics accurately
> without losing transient spikes.
>

You need (a) *and* (b) to build a comprehensive view of what is/was 
going on your system.


RHQ has always been (a) only. Hawkular will focus on (a) initially.

> The problem with (a) is that you might miss important cases, since each
> captured metric represents a measurement at a single instant in time.
> Consider monitoring a system periodically (e.g., every 15 seconds) to
> obtain some metric (e.g., the size of a db connection pool, etc). If a
> spike occurs and is resolved *within a single interval*, then the
> captured metric will never reflect this, and any derived aggregate (max,
> min, aggregate) will also not reflect the spike.
>
> Examples of (b) include low-level system information like "create
> database connection?, ?closed database connection?, ?start new thread?,
> ?stop thread?, etc., but it also includes recording business-related
> events, such as ?received request from user X from IP address A to read
> resource R?. The latter is insanely valuable, because customers can
> build downstream services that consume Hawkular output and get valuable
> business insight and perform business analytics. Those custom services
> can do all kinds of interesting things, such as automatically rate-limit
> requests from a specific user, bill based upon usage, audit access for
> compliance purposes, prevent DoS by rejecting requests from suspect IP
> addresses, etc.
>
> This is what is called ?event sourcing?, and it records all interesting
> events and forms the basis for a lot of near-real-time analytics and
> monitoring solutions. And, an architecture designed for this purpose can
> do things will persist every event in a persistent transaction log, and
> services will consume this stream/log, do work, and output to other
> persistent logs/streams. These streams and services form a workflow, but
> it?s not quite the same as a traditional pub/sub set of services because
> each service consume the events at their own pace. The net effect is
> that you can take a service down for maintenance (or it can crash), and
> when it comes back up it will simply continue where it left off.
> Upstream services are unaffected, and downstream services just see a
> lull in events but otherwise are unaffected. Plus, you never lose any
> events or any data, and all aggregates and windowing (done in downstream
> services) are entirely accurate. You can even set up separate streams
> for windowed metrics (e.g., minute, hour, day, week, etc.)
>
> Here?s an article that describes how LinkedIn is using stream-oriented
> processing to capture metrics and events for their systems, and how they
> derive benefit for the business:
> http://engineering.linkedin.com/samza/real-time-insights-linkedins-performance-using-apache-samza.
> They process 500 billion events per day (yes, billion). Here are a
> couple of other links:
> http://blog.confluent.io/2015/01/29/making-sense-of-stream-processing/,
> http://www.slideshare.net/InfoQ/samza-in-linkedin-how-linkedin-processes-billions-of-events-everyday-in-realtime,
> http://scale-out-blog.blogspot.co.uk/2014/02/why-arent-all-data-immutable.html,
> and the ever-essential
> http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
>

We have plans for "events" storage in Hawkular metrics. You can already 
add tags to your numeric data, but without "events" you can't build 
something like you describe above.

>
>>
>> The impact when sending information with a collector or embedded
>> collector should be pretty low. Most of existing solutions do some sort
>> of batching. With a custom sender, it all depends on how it's designed,
>> obviously.
>
> Sounds good.
>
>>
>>>
>>> Do you have an estimate or goal for how much volume of incoming data
>>> can be handled without impacting on clients? What, if anything, does
>>> a client submission wait for on the back-end?
>>
>> Hawkular metrics is designed to be horizontally scalable so the volume
>> of data you can absorb should depend on the number of machines you can
>> throw in the game.
>
> How will the work be split up across the cluster? Are the incoming
> messages stored before they?re processed?
>

An Hawkular metrics server is web server (Wildfly) in front of a 
Cassandra cluster.

So you'd distribute the work with a load balancer.

I'm not sure I understand your second question.

>>
>> Most collectors buffer data to be sent and operate in separate threads.
>> So if the metrics ingestion rate decreases, they'll consume more memory.
>> Other than that, it should have limited impact on your service.
>
> Sounds good.
>
>>
>>>
>>> Also, how do you plan to ensure that, no matter what happens to the
>>> Hawkular system or anything it depends upon, no client information is
>>> every lost or dropped?
>>
>> Usually collectors will drop data once buffers are full. If you want to
>> make sure no data is lost, then you need to build a custom sender.
>> Hawkular metrics has an HTTP interface so the response code should tell
>> you if a metric was successfully persisted.
>
> So I understand that the collectors will drop any buffered data, since
> that will be unsent if the monitored system (or external collectors)
> crash. But what happens if Hawkular suffers a partial or total crash?
> What data is lost? What happens to data that was in-process when the
> crash occurred? Stream-based architectures are interesting because they
> often can handle more load, partition it more effectively, and are more
> durable.

If you lose Wildfly servers or Cassandra nodes then the rest of cluster 
should continue to work.

As a Hawkular metrics client, you can't say what happened to your data 
if you lose the connection before you get a response with a status code. 
When a Wildfly server crashes, your data may be still being unmarshaled, 
or might have reached the Cassandra driver, or have been written to the 
Cassandra logs.

We have no plan ATM to implement log-based event processors ourselves. 
In the beginning, we'll focus on existing and wide-spread collectors 
(generally buffer-based) and in-house collectors like the wildfly-monitor.

>
>>
>>>
>>> Finally, is the plan to make Hawkular embeddable (excluding the stuff
>>> that has to be embedded in monitored clients/systems/services), or
>>> only a separate turn-key (i.e., install-and-run-and-use) system?
>>
>> Hawkular metrics comes in two forms:
>> * a Java library (metrics-core)
>> * a Java EE web application (built on top of the library)
>>
>> metrics-core can be embedded in any sort of JVM application but it
>> expects to find a Cassandra cluster somewhere.
>>
>>
>>
>> I hope it helps. Feel free to ask for details.
>>
>> And welcome to Hawkular!
>>
>> Thomas
>> _______________________________________________
>> 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
>


From tsegismo at redhat.com  Mon Feb 16 05:08:27 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 16 Feb 2015 11:08:27 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<9EB1D6A5-FCD4-4924-A99A-8978E1B7ADE4@redhat.com>
Message-ID: <54E1C19B.3040307@redhat.com>

Le 13/02/2015 19:01, Randall Hauch a ?crit :
> Oh, one more thing:
>
>>> On Feb 13, 2015, at 10:49 AM, Thomas Segismont <tsegismo at redhat.com
>>> <mailto:tsegismo at redhat.com>> wrote:
>>> ...
>>> Hawkular metrics comes in two forms:
>>> * a Java library (metrics-core)
>>> * a Java EE web application (built on top of the library)
>>>
>>> metrics-core can be embedded in any sort of JVM application but it
>>> expects to find a Cassandra cluster somewhere.
>
> I understand that the collectors will be libraries; you?ll probably
> eventually want these in multiple languages. But it sure seems strange
> to have the Hawkular engine (for lack of a better term) be a library.
> Not only is that more complicated to set up, but if you design it to be
> embeddable then it will be harder to also make it scale.
>

Most consumers of the metrics tool will use the web application. The 
metrics-core library might be used in projects in advanced integration 
scenarios.

> It sure seems easier to focus on only installing Hawkular as a separate
> (potentially distributed) system that is set up and used. Sure, config
> it to point to the Cassandra cluster. But that can be easily wrapped up
> in a Docker image that people download and simply start, pointing via
> ENV variables to a Cassandra instance/cluster (perhaps also started from
> a Docker image). Better still is that these Docker images can be wrapped
> in a Kubernetes pod (that uses a Cassandra pod) and deployed on
> OpenShift. Now you have Hawkular as a service, but still easily
> installed on a customer?s network.
>

This is already in our plans.

From ppalaga at redhat.com  Mon Feb 16 06:53:30 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 12:53:30 +0100
Subject: [Hawkular-dev] How to Contribute to Hawkular Parent
Message-ID: <54E1DA3A.60609@redhat.com>

Hi *,

so that bad things do not happen in Hawkular Parent, here a proposal for 
explicit contribution rules:

https://github.com/hawkular/hawkular-parent-pom/pull/13

Please comment directly in the PR

Peter

From miburman at redhat.com  Mon Feb 16 08:21:52 2015
From: miburman at redhat.com (Michael Burman)
Date: Mon, 16 Feb 2015 15:21:52 +0200
Subject: [Hawkular-dev] [Metrics] Python client and perspective from client
	developing..
Message-ID: <54E1EEF0.70604@redhat.com>

Hi,

As we need clients to actually push data to our system (and that way to 
get users & community), I've written one for the Python. I've tried to 
follow what a normal contributor would do and just read the 
documentation that's available. Short story - there isn't enough 
documentation.

I don't think we reached a consensus yet where to push the client source 
codes, so I haven't created a pull request for this and for that reason 
haven't renamed the repository either. It is available from 
https://github.com/burmanm/rhq-metrics-python-client with documentation. 
I'll gladly take ideas, my Python most likely looks like some other 
language written in Python syntax - but it works.

There are tests that trigger against the real hawkular-metrics server 
(0.30.0-SNAPSHOT). Usually the Python client developers target a mocked 
endpoint, but I decided to go after the real server as I believe our API 
might still change and the documentation isn't a reliable reference 
point. I tried to follow the documentation on 
https://github.com/hawkular/hawkular-metrics/tree/master/api/metrics-api-jaxrs 
but I had to revert in some cases to reading the source code on what was 
really wanted, especially after receiving 400 / 500 error codes while 
doing the testing (when the json looked like in the examples). I also 
only created abilities that are defined on that page, as I have no idea 
if rest of the undocumented REST APIs are actually there to stay or to 
be removed.

Which brings me to the question, what parts of the API are stable at the 
moment? There's counters and such which are not documented at all. We 
have huge selection of endpoints for any client developer to implement, 
perhaps too many of them. I can try to improve documentation, but even 
then I would want to know what's going on. I heard alerts is getting 
swagger-annotations, which is nice.

   -  Micke

From ppalaga at redhat.com  Mon Feb 16 08:37:40 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 14:37:40 +0100
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
Message-ID: <54E1F2A4.7010401@redhat.com>

Hi John,

was there any discussion (that I may have missed during my PTO) around 
importing the jboss-javaee-7.0-with-all to parent? Could you please 
justify the idea once again for me?

I must say I'd veto the change if I was at work. Here is why:

(1) Tying to WildFly only. The change might be understood like this. I 
am not sure this was your intention, but please consider that importing 
another similar BoM (say EAP BoM) in paralel would in fact be extremely 
impractical, because of version conflicts.

(2) Pulling in many artifacts we do not use, do not need, some of them 
maybe being implicitly unwanted ones. But having them in parent is 
actually legalizing them without any discussion. That is especially 
dangerous.

(3) "Political" dependence on WildFly. WildFly may do changes at any 
time in their BoMs that may have bad consequences in Hawkular.

The bottom line is that it would be much better to avoid situations this 
through discussing proposals prior to merging them in master. I have 
proposed explicit parent contribution rules in 
https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to 
comment on them.

From ppalaga at redhat.com  Mon Feb 16 08:39:31 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 14:39:31 +0100
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <54E1F2A4.7010401@redhat.com>
References: <54E1F2A4.7010401@redhat.com>
Message-ID: <54E1F313.9060406@redhat.com>

Sorry, I have sent this prematurely, but it was only my signature 
missing there -- Peter


On 02/16/2015 02:37 PM, Peter Palaga wrote:
> Hi John,
>
> was there any discussion (that I may have missed during my PTO) around
> importing the jboss-javaee-7.0-with-all to parent? Could you please
> justify the idea once again for me?
>
> I must say I'd veto the change if I was at work. Here is why:
>
> (1) Tying to WildFly only. The change might be understood like this. I
> am not sure this was your intention, but please consider that importing
> another similar BoM (say EAP BoM) in paralel would in fact be extremely
> impractical, because of version conflicts.
>
> (2) Pulling in many artifacts we do not use, do not need, some of them
> maybe being implicitly unwanted ones. But having them in parent is
> actually legalizing them without any discussion. That is especially
> dangerous.
>
> (3) "Political" dependence on WildFly. WildFly may do changes at any
> time in their BoMs that may have bad consequences in Hawkular.
>
> The bottom line is that it would be much better to avoid situations this
> through discussing proposals prior to merging them in master. I have
> proposed explicit parent contribution rules in
> https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to
> comment on them.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From mazz at redhat.com  Mon Feb 16 09:12:11 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 16 Feb 2015 09:12:11 -0500 (EST)
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <54E1F313.9060406@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
Message-ID: <428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>

My bad - it has been my intention to never touch the parent pom (or global maven stuff in general) anymore. I slipped up here. I was only trying to keep everyone on the same version as the Wildfly container we are embedding in (so, for example, the integration assembly will work). Didn't think it would be a problem since we are all running in Wildfly (at least, that is how the integration assembly that heiko had me create is working). Not sure how we can ensure we all use all the same versions as provided by the container we are in unless we pull in the BOM, but perhaps there is another way. (BTW: this doesn't pull in all those dependencies, it is just pulling in the dependency definitions and individual projects pull in whatever deps they want with the provided scope. But if there is a better way to ensure we keep on the same versions that the container provides, we can do that.

> On 02/16/2015 02:37 PM, Peter Palaga wrote:
> > Hi John,
> >
> > was there any discussion (that I may have missed during my PTO) around
> > importing the jboss-javaee-7.0-with-all to parent? Could you please
> > justify the idea once again for me?
> >
> > I must say I'd veto the change if I was at work. Here is why:
> >
> > (1) Tying to WildFly only. The change might be understood like this. I
> > am not sure this was your intention, but please consider that importing
> > another similar BoM (say EAP BoM) in paralel would in fact be extremely
> > impractical, because of version conflicts.
> >
> > (2) Pulling in many artifacts we do not use, do not need, some of them
> > maybe being implicitly unwanted ones. But having them in parent is
> > actually legalizing them without any discussion. That is especially
> > dangerous.
> >
> > (3) "Political" dependence on WildFly. WildFly may do changes at any
> > time in their BoMs that may have bad consequences in Hawkular.
> >
> > The bottom line is that it would be much better to avoid situations this
> > through discussing proposals prior to merging them in master. I have
> > proposed explicit parent contribution rules in
> > https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to
> > comment on them.
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 
> 

From theute at redhat.com  Mon Feb 16 09:22:07 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 16 Feb 2015 15:22:07 +0100
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
Message-ID: <54E1FD0F.3090506@redhat.com>

My take is that if something is in the parent/BOM that means "free 
buffet, use it without any question".

So this raise the question of:
	- Have we moved away from "usable in a non full-JavaEE environment" ? ( 
https://developer.jboss.org/wiki/HighLevelRequirements )
	- Do we tie Hawkular and its components to Wildfly ? (RHQ Metrics used 
to be embedded-able as a war within Karaf (without pulling tons of 
dependencies))

(note that there are flavours in the answer such as wildfly-core).

If so we should explicitly say so and check the consequences.

Thomas



On 02/16/2015 03:12 PM, John Mazzitelli wrote:
> My bad - it has been my intention to never touch the parent pom (or global maven stuff in general) anymore. I slipped up here. I was only trying to keep everyone on the same version as the Wildfly container we are embedding in (so, for example, the integration assembly will work). Didn't think it would be a problem since we are all running in Wildfly (at least, that is how the integration assembly that heiko had me create is working). Not sure how we can ensure we all use all the same versions as provided by the container we are in unless we pull in the BOM, but perhaps there is another way. (BTW: this doesn't pull in all those dependencies, it is just pulling in the dependency definitions and individual projects pull in whatever deps they want with the provided scope. But if there is a better way to ensure we keep on the same versions that the container provides, we can do that.
>
>> On 02/16/2015 02:37 PM, Peter Palaga wrote:
>>> Hi John,
>>>
>>> was there any discussion (that I may have missed during my PTO) around
>>> importing the jboss-javaee-7.0-with-all to parent? Could you please
>>> justify the idea once again for me?
>>>
>>> I must say I'd veto the change if I was at work. Here is why:
>>>
>>> (1) Tying to WildFly only. The change might be understood like this. I
>>> am not sure this was your intention, but please consider that importing
>>> another similar BoM (say EAP BoM) in paralel would in fact be extremely
>>> impractical, because of version conflicts.
>>>
>>> (2) Pulling in many artifacts we do not use, do not need, some of them
>>> maybe being implicitly unwanted ones. But having them in parent is
>>> actually legalizing them without any discussion. That is especially
>>> dangerous.
>>>
>>> (3) "Political" dependence on WildFly. WildFly may do changes at any
>>> time in their BoMs that may have bad consequences in Hawkular.
>>>
>>> The bottom line is that it would be much better to avoid situations this
>>> through discussing proposals prior to merging them in master. I have
>>> proposed explicit parent contribution rules in
>>> https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to
>>> comment on them.
>>> _______________________________________________
>>> 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 Feb 16 09:22:06 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 15:22:06 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
Message-ID: <54E1FD0E.8070407@redhat.com>

Hi Stefan,

what was your specific motivation for adding the JBoss Repos?

The topic was discussed before [1] with the result, that we will not 
hard code any Maven repositories in Hawkular Parent. All we produce and 
all we depend on should be on Maven Central.

The only inconvenience with Central is that JBoss Nexus is synced to 
central once a day only. The ones wanting to rely on freshly released 
artifacts are recommended to add JBoss Nexus to their settings.xml. This 
holds also for CI jobs.

Thanks,

Peter

[1] on #hawkular on 2015-01-21, reasons against it are summed in 
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

From jpkroehling at redhat.com  Mon Feb 16 09:23:11 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Mon, 16 Feb 2015 15:23:11 +0100
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <54E1F2A4.7010401@redhat.com>
References: <54E1F2A4.7010401@redhat.com>
Message-ID: <54E1FD4F.4000202@redhat.com>

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

Peter,

Some questions inline:

On 02/16/2015 02:37 PM, Peter Palaga wrote:
> (1) Tying to WildFly only. The change might be understood like
> this. I am not sure this was your intention, but please consider
> that importing another similar BoM (say EAP BoM) in paralel would
> in fact be extremely impractical, because of version conflicts.

Aren't we targeting Wildfly? If so, then it makes sense to tie it to
Wildfly, at least for this bootstrap phase. Tying to a specific
application server at the beginning removes the need to solve problems
that we would have if we were targeting multiple application servers.
In other words, we can concentrate better on the business when we
don't need to make decisions about the integration/environment.

About EAP and similar derivatives: it should be close enough to
Wildfly to provide a mostly smooth transition. A possible solution
would be to use profiles, so that we import the appropriate BOMs
depending on the build type. But I'd suggest to worry about it once it
becomes a real problem.

Unless we know already that we *need* to also be able to run on other
application servers not compatible with Wildfly and that a refactoring
later is too expensive to be done at this later point.

> (2) Pulling in many artifacts we do not use, do not need, some of
> them maybe being implicitly unwanted ones. But having them in
> parent is actually legalizing them without any discussion. That is
> especially dangerous.

I might have missed your point here, but when you import a BOM, aren't
you just importing the dependency definitions? In such case, you can
always override on our parent if there's a unwanted dependency (with
an excludes). For the consumer of the dependency, it's usually easier
to just import a dependency without specifying the version, as there's
usually no reason why I would use a very specific version of a
library. And in such unusual cases, we can, again, override it on our
parent.

> (3) "Political" dependence on WildFly. WildFly may do changes at
> any time in their BoMs that may have bad consequences in Hawkular.

Shouldn't matter if we stick with an already released version of
Wildfly and its BOM, right?

All in all, I completely agree with your points. I just do not think
it's the right time to be concerned about those points *yet*. All the
platforms we intend to run on do support Wildfly, which is "good
enough" for a first phase.

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

iQEcBAEBAgAGBQJU4f1OAAoJECKM1e+fkPrXIIAIAIMvk2JnLVz0w9GPpUC+Hw0x
0UM+ADNDHQdNhs7GHlHhszbewAdfAOk2HBpq645M5Eg66t8HLIh7EW8/r9D1VD0r
okBLLs2WNf9z9HehKFiLuHSM6iziZ4njypGrOMQoX5B1ErqwmrrcHBnzn1pI8ayM
INoBsjVjrxNbL3m/CtNgw9+4yc8bhBTZI7cMt2Zud8JESFLlXmzshi0lB6udnT8X
ytfY0ZyRNpA/uBcVPrFw5lPP3xc0qbqLWRfRbRcXXHtMiTt6ybQQUWEPyrdmAROu
gGbHg6P6Ya/jmtd9fbkHGynGvVg0E3kEyWsnugIuEl5fXhAdHoASZy1y2qpLMVE=
=REZt
-----END PGP SIGNATURE-----

From jshaughn at redhat.com  Mon Feb 16 09:23:34 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 16 Feb 2015 09:23:34 -0500
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <54E1F2A4.7010401@redhat.com>
References: <54E1F2A4.7010401@redhat.com>
Message-ID: <54E1FD66.9000004@redhat.com>


What is the better alternative at the moment, to have each component's 
root pom import the bom?  Either way we sort of end up with the same 
thing.Perhaps we could have profiles for the different deployment envs, 
with WFly as our first one?  Not sure, but the benefit of all components 
layering on the same provided deps seems important.

On 2/16/2015 8:37 AM, Peter Palaga wrote:
> Hi John,
>
> was there any discussion (that I may have missed during my PTO) around
> importing the jboss-javaee-7.0-with-all to parent? Could you please
> justify the idea once again for me?
>
> I must say I'd veto the change if I was at work. Here is why:
>
> (1) Tying to WildFly only. The change might be understood like this. I
> am not sure this was your intention, but please consider that importing
> another similar BoM (say EAP BoM) in paralel would in fact be extremely
> impractical, because of version conflicts.
>
> (2) Pulling in many artifacts we do not use, do not need, some of them
> maybe being implicitly unwanted ones. But having them in parent is
> actually legalizing them without any discussion. That is especially
> dangerous.
>
> (3) "Political" dependence on WildFly. WildFly may do changes at any
> time in their BoMs that may have bad consequences in Hawkular.
>
> The bottom line is that it would be much better to avoid situations this
> through discussing proposals prior to merging them in master. I have
> proposed explicit parent contribution rules in
> https://github.com/hawkular/hawkular-parent-pom/pull/13 Feel free to
> comment on them.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


From jsanda at redhat.com  Mon Feb 16 09:58:07 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Feb 2015 09:58:07 -0500
Subject: [Hawkular-dev] Intro to Cassandra
In-Reply-To: <1548866859.11173651.1423746905411.JavaMail.zimbra@redhat.com>
References: <1548866859.11173651.1423746905411.JavaMail.zimbra@redhat.com>
Message-ID: <9D251A1B-9402-438F-BAA0-B5AF651CB65A@redhat.com>

For anyone interest or who missed my presentation, here are the slides[1] and the bluejeans recording[2]

[1] https://docs.google.com/presentation/d/1z6Z9_Fxr8gmWtSTzxTd8L-VXJUrCezWRIJvBtLeUIFk/edit?usp=sharing
[2] https://bluejeans.com/s/84pV/ <https://bluejeans.com/s/84pV/>

> On Feb 12, 2015, at 8:15 AM, John Sanda <jsanda at redhat.com> wrote:
> 
> The following is a new meeting request:
> 
> Subject: Intro to Cassandra  
> Organizer: "John Sanda" <jsanda at redhat.com> 
> 
> Location: bluejeans 
> Time: Friday, February 13, 2015, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
> 
> Invitees: hawkular-dev at lists.jboss.org 
> 
> 
> *~*~*~*~*~*~*~*~*~*
> 
> I will cover topics such as, 
> 
> * High availability 
> * Consistency 
> * Fault tolerance 
> * Data modeling 
> 
> Assumes no prior knowledge of or experience with Cassandra. 
> 
> --- 
> 
> Meeting URL: https://bluejeans.com/217788152 <meeting.ics>_______________________________________________
> 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/20150216/af27e87f/attachment.html 

From ppalaga at redhat.com  Mon Feb 16 10:07:37 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 16:07:37 +0100
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
Message-ID: <54E207B9.1090204@redhat.com>

Hi John and others,

First, I am not against including WildFly in some form. But I vote for 
the least possible set. jboss-javaee-7.0-with-all [1] is unnecessarily 
broad. Hibernate anyone?

Second, the possibility to run in a non-WF-like container is still 
somewhere in my consciousness. Importing wf BoM does not seem to be a 
step in that direction.

[1] 
http://central.maven.org/maven2/org/wildfly/bom/jboss-javaee-7.0-with-all/8.2.0.Final/jboss-javaee-7.0-with-all-8.2.0.Final.pom

Thanks,

Peter

On 02/16/2015 03:12 PM, John Mazzitelli wrote:
> My bad - it has been my intention to never touch the parent pom (or
> global maven stuff in general) anymore. I slipped up here. I was only
> trying to keep everyone on the same version as the Wildfly container
> we are embedding in (so, for example, the integration assembly will
> work). Didn't think it would be a problem since we are all running in
> Wildfly (at least, that is how the integration assembly that heiko
> had me create is working). Not sure how we can ensure we all use all
> the same versions as provided by the container we are in unless we
> pull in the BOM, but perhaps there is another way. (BTW: this doesn't
> pull in all those dependencies, it is just pulling in the dependency
> definitions and individual projects pull in whatever deps they want
> with the provided scope.



> But if there is a better way to ensure we
> keep on the same versions that the container provides, we can do
> that.
>
>> On 02/16/2015 02:37 PM, Peter Palaga wrote:
>>> Hi John,
>>>
>>> was there any discussion (that I may have missed during my PTO)
>>> around importing the jboss-javaee-7.0-with-all to parent? Could
>>> you please justify the idea once again for me?
>>>
>>> I must say I'd veto the change if I was at work. Here is why:
>>>
>>> (1) Tying to WildFly only. The change might be understood like
>>> this. I am not sure this was your intention, but please consider
>>> that importing another similar BoM (say EAP BoM) in paralel would
>>> in fact be extremely impractical, because of version conflicts.
>>>
>>> (2) Pulling in many artifacts we do not use, do not need, some of
>>> them maybe being implicitly unwanted ones. But having them in
>>> parent is actually legalizing them without any discussion. That
>>> is especially dangerous.
>>>
>>> (3) "Political" dependence on WildFly. WildFly may do changes at
>>> any time in their BoMs that may have bad consequences in
>>> Hawkular.
>>>
>>> The bottom line is that it would be much better to avoid
>>> situations this through discussing proposals prior to merging
>>> them in master. I have proposed explicit parent contribution
>>> rules in https://github.com/hawkular/hawkular-parent-pom/pull/13
>>> Feel free to comment on them.
>>> _______________________________________________ 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 snegrea at redhat.com  Mon Feb 16 10:08:55 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 16 Feb 2015 10:08:55 -0500 (EST)
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <54E1FD0E.8070407@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
Message-ID: <1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>

Hello Peter,

This came up on Friday, when me and Mazz worked on getting all the Travis builds to publish -SNAPSHOT artifacts. The goal was to get the main project (with the pinger) built both on Travis and locally. 

I think it is essential to have the default repositories in the parent pom. Community users should just do 'clone & mvn' to get started. Anything more complicated (like changing settings.xml or setting up profiles) is completely unacceptable. Since we are working with snapshots and have a myriad of projects, the essential repositories need to be in the parent pom.

If you notice, the repositories are in a profile that can be disabled. So there is a lot of configuration flexibility for power users (eg. the link you posted below).

Please do not revert these changes.

Thank you,
Stefan

----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "Stefan Negrea" <snegrea at redhat.com>
> Cc: hawkular-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 8:22:06 AM
> Subject: Maven repositories in Hawkular Parent
> 
> Hi Stefan,
> 
> what was your specific motivation for adding the JBoss Repos?
> 
> The topic was discussed before [1] with the result, that we will not
> hard code any Maven repositories in Hawkular Parent. All we produce and
> all we depend on should be on Maven Central.
> 
> The only inconvenience with Central is that JBoss Nexus is synced to
> central once a day only. The ones wanting to rely on freshly released
> artifacts are recommended to add JBoss Nexus to their settings.xml. This
> holds also for CI jobs.
> 
> Thanks,
> 
> Peter
> 
> [1] on #hawkular on 2015-01-21, reasons against it are summed in
> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
> 

From mazz at redhat.com  Mon Feb 16 10:17:35 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 16 Feb 2015 10:17:35 -0500 (EST)
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <54E207B9.1090204@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
	<54E207B9.1090204@redhat.com>
Message-ID: <2112640565.12721503.1424099855265.JavaMail.zimbra@redhat.com>

> First, I am not against including WildFly in some form. But I vote for
> the least possible set. jboss-javaee-7.0-with-all [1] is unnecessarily
> broad. Hibernate anyone?

I didn't think it mattered because this doesn't import the dependencies anyway. It only imports the dependency definitions (so yeah if someone wants to use hibernate, they can pull it in if they want - but it is not like we now have a dependency on Hibernate just because the parent pom has the WF BOM in it. It is just letting us know what version of Hibernate we CAN pull in if we want to).

But if we don't even want our sub-projects to even use EE/Wildfly dependencies, then I can see pulling it out (to avoid tempting them to use it?)

From jshaughn at redhat.com  Mon Feb 16 10:21:18 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 16 Feb 2015 10:21:18 -0500
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54E1BD18.5010905@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com>
Message-ID: <54E20AEE.9000608@redhat.com>


I think this comes down more to what we *can* record.   As we discussed 
a little bit in the past [1],  the Hawkular model is not the RHQ model, 
meaning there is no heavy external agent performing scheduled avail 
checks and maintaining avail state for all of the resources.  There may 
optionally be a lightweight agent checking a subset of resources for 
live-ness, the basic approach will be a push model, with feeds sending 
avail info as they see fit, for only the resources they see fit.   And 
we have H Metrics doing the storage, which means no updates of current 
state, instead, just write values as they stream in.  This results in 
Avail storage that will likely be more of what Micke is talking about, a 
lot of data points (most likely a lot of UP), very likely not just at 
the times of avail change.

We can do a couple of things with this data.  It could be aggregated and 
stored as change intervals in the persistence layer (as a feature of H 
Metrics perhaps), and lose the individual data points.  It can, at query 
time for an interval, be aggregated into change intervals, and also 
maintain the collection granularity.

Th decisions made here have a lot of impact on alerting, because at the 
moment the basic avail alerting use cases are not actually covered. Take 
Catherine's "basic" use-cases:

 1. As an administrator of a website, I would like to configure Hawkular
    so an alert is sent to me every time the system goes down.
 2. As an administrator of a website, I would like to configure Hawkular
    so an alert is only sent to me after the system is down for a
    certain length of time, so I'm not alerted if there is a very minor
    downtime event.

Case-1 is more subtle than it looks.  This, I think, does not mean that 
the admin wants to be alerted every time the system is *reported* down, 
but rather when it goes down.  This sort of alerting was easy in RHQ 
because we were only notified of changes in availability.  "Goes DOWN" 
as opposed to "Is DOWN".  In Hawkular we are likely talking about "Is 
DOWN", or possibly even the lack of "Is UP" reports.  It's unclear yet, 
but we may need to somehow infer that something is down if it does not 
report "Is UP" for some period.  In a push-oriented feed (like a ping), 
if something goes physically down it won't be able to report at all.  
Case-2 can't really be definitively solved until case-1 is well-defined.

At the moment alerting can fire an alert on every "Goes DOWN" report, or 
apply various dampening to those events.   It can not guarantee a single 
alert for a specific down event unless the feed itself reports only 
changes in avail.   Although, it can actually Having said that, we will 
shortly be looking at how to replace the "recovery-alert" logic of RHQ.

[1] 
https://developer.jboss.org/message/915970?et=watches.email.thread#915970


On 2/16/2015 4:49 AM, Thomas Heute wrote:
>
> On 02/13/2015 11:18 PM, Michael Burman wrote:
>> Hi,
>>
>> I disagree, seeing this pattern first hand in resulting large penalty
>> payment on one case (inability to prove that monitoring reported up on
>> certain time when it wasn't responsive). If there's a need to monitor
>> availability, there must be recorded event flow, eg:
>>
>> Up 11:00
>> Up 11:05
>> Up 11:10
>> Down 11:15
>> Down 11:20
>> Up 11:25
>>
>> And why? If we only record:
>>
>> Up 11:00 - 11:10
>> Down 11:15 - 11:20
>> Up 11:25 - ..
>>
>> There's a difference. Did the monitoring system report 11:05 or was the
>> monitoring system down 11:05? In many cases a need to prove that system
>> was in certain state in certain times. Especially when there are SLA
>> disagreements. Even more importantly, what happened between 11:10 -
>> 11:15 and 11:20 - 11:25?
> Recording all datapoints doesn't give you more information on what
> happened between 2 recordings though.
>
> But I get your point on the "inability to prove that monitoring reported
> up on certain time when it wasn't responsive".
> I didn't see availability recording as SLA proofs though.
>
>> The SLA behaviour requires that some system noticed something happening
>> at certain point of time. And if there's issues with system
>> responsibility say at 11:05, there needs to be a event showing that the
>> system really did report up.
> You can't prove that system is up and running at a special point in
> time, you can only prove over a period of time if you made enough checks
> (interval lesser than the period of time of the SLA).
>
> Thomas
>
>>      - Micke
>>
>>
>> On 13.02.2015 14:01, Thomas Heute wrote:
>>> Getting back to availability discussion...
>>>
>>> To me availability is a set of periods, not so much "time series" and
>>> we should just record change of status (closing the previous event and
>>> opening a new one).
>>>
>>>      - Server is up from 8:00am to 11:30am
>>>      - Server is down from 11:30am to 11:32am
>>>      - Server is unknown from 11:32am to 12:00pm (an agent running on a
>>> machine can tell if a server is up or down, if the agent dies then we
>>> don't know if the server is up or down)
>>>      - Server is in erratic state from 12:00pm to 12:30pm (agent
>>> reports down every few requests)
>>>
>>> We were discussing the best way to represent availability over time in
>>> a graph, representation in RHQ [1] is very decent IMO, can be extended
>>> with more colors to reflect how often/long the website was down for
>>> each "brick" (if the line represent a year with 52 blocks, 1 block can
>>> be more or less red depending on how long it was done during the week).
>>>
>>> But thinking of it more, availability graph is not that interesting by
>>> itself IMO and more interesting in the context of other values.
>>> I attached a mockup of what I meant, a red area is displayed on
>>> response time graph, that means that the system is down, obviously
>>> there is no response time reported anymore in that period. Earlier
>>> there is an erratic area, seems related to higher response time ;)
>>> Rest of the time the system is just up and running...
>>>
>>> Additionally I would want to see reports of availability:
>>>      - overall availability over a period of time (a day, a month, a
>>> year...). "99.99% available in the past month"
>>>      - lists of the down periods with start dates and duration for a
>>> particular resource or set of resources (filtering options)
>>>
>>> Thoughts ?
>>>
>>> [1]
>>> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
>>>
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> 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/20150216/fcd2d51b/attachment-0001.html 

From hrupp at redhat.com  Mon Feb 16 11:54:39 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 16 Feb 2015 17:54:39 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
Message-ID: <DB8C4DB2-C670-43E3-8D67-CF00F0A30CB9@redhat.com>


> Am 16.02.2015 um 16:08 schrieb Stefan Negrea <snegrea at redhat.com>:
> I think it is essential to have the default repositories in the parent pom. Community users should just do 'clone & mvn' to get started. 

I agree.

> Anything more complicated (like changing settings.xml or setting up profiles) is completely unacceptable. Since we are working with 

I think we may be able to go / do some middle ground that if we can't use the "profile trick", we at least deliver 
pre-configured hawkular-settings.xml files (like we do now for Travis) that users can use with
mvn -s hawkular-settings.xml install to get going.

What we need to prevent is that the user has to guess and/or copy/paste the settings from somewhere into ~/.m2/settings.xml,
as many users don't even know what to copy&paste.



From snegrea at redhat.com  Mon Feb 16 12:54:25 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 16 Feb 2015 12:54:25 -0500 (EST)
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <DB8C4DB2-C670-43E3-8D67-CF00F0A30CB9@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
	<DB8C4DB2-C670-43E3-8D67-CF00F0A30CB9@redhat.com>
Message-ID: <2083510953.10925304.1424109265359.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 10:54:39 AM
> Subject: Re: [Hawkular-dev] Maven repositories in Hawkular Parent
> 
> 
> > Am 16.02.2015 um 16:08 schrieb Stefan Negrea <snegrea at redhat.com>:
> > I think it is essential to have the default repositories in the parent pom.
> > Community users should just do 'clone & mvn' to get started.
> 
> I agree.
> 
> > Anything more complicated (like changing settings.xml or setting up
> > profiles) is completely unacceptable. Since we are working with
> 
> I think we may be able to go / do some middle ground that if we can't use the
> "profile trick", we at least deliver

The profile trick works now, that is how it is implemented. There is a profile that gets activated automatically and can be disabled via a property. So power users have a way to do exactly what they want without pom changes, while regular users enjoy 'clone & mvn' with nothing else.

> pre-configured hawkular-settings.xml files (like we do now for Travis) that
> users can use with
> mvn -s hawkular-settings.xml install to get going.
> 
> What we need to prevent is that the user has to guess and/or copy/paste the
> settings from somewhere into ~/.m2/settings.xml,
> as many users don't even know what to copy&paste.
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From snegrea at redhat.com  Mon Feb 16 13:10:59 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 16 Feb 2015 13:10:59 -0500 (EST)
Subject: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
In-Reply-To: <2112640565.12721503.1424099855265.JavaMail.zimbra@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
	<54E207B9.1090204@redhat.com>
	<2112640565.12721503.1424099855265.JavaMail.zimbra@redhat.com>
Message-ID: <555321336.10931322.1424110259024.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 9:17:35 AM
> Subject: Re: [Hawkular-dev] Importing JBoss BoMs to Hawkular Parent
> 
> > First, I am not against including WildFly in some form. But I vote for
> > the least possible set. jboss-javaee-7.0-with-all [1] is unnecessarily
> > broad. Hibernate anyone?
> 
> I didn't think it mattered because this doesn't import the dependencies
> anyway. It only imports the dependency definitions (so yeah if someone wants
> to use hibernate, they can pull it in if they want - but it is not like we
> now have a dependency on Hibernate just because the parent pom has the WF
> BOM in it. It is just letting us know what version of Hibernate we CAN pull
> in if we want to).
> 
> But if we don't even want our sub-projects to even use EE/Wildfly
> dependencies, then I can see pulling it out (to avoid tempting them to use
> it?)

Almost all the subprojects have some Wildfly dependency. Until those dependencies go away, it is better to have the BOM at the parent level. That way individual sub-projects are forced to be on the same page when it comes to versions.

I would like to not speculate on the future. Right now we depend on Wildfly. When only one project (or none) has Wildfly dependencies, then we clean up the parent pom. 

I would focus on the positive of having the BOM in the parent pom, and focus less on the potential ways the Wildfly team would do something to break us. I want to be positive about things ...

Here are just a few pluses for having a BOM in the parent pom:
1) All the subprojects will be on the same version of Wildfly dependencies
2) If we need to change the version, it is done in a single place
3) A single place means special builds (such as productization) are easy to adjust
4) No configuration required at project level, other than inherit the parent pom
5) Dependencies do not get force imported, but if somebody adds a dependency in a sub-project, the version is well known


We need to keep this change in the parent pom until one or none of the projects dependent on Wildfly components. Also, we should expand this to any other commonly used dependencies.


Thank you,
Stefan


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

From mazz at redhat.com  Mon Feb 16 15:48:45 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 16 Feb 2015 15:48:45 -0500 (EST)
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54E20AEE.9000608@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
Message-ID: <1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>

I will add the following to the discussion:

If past history with customers of JON/users of RHQ/salespeople is any indication, we will get requests to support collecting availability every second (if not every sub-second) even AFTER telling people, documenting, and shouting from the mountaintop that we are not a realtime profiler. So, do we have the throughput/infrastructure that can support one "UP" datapoint coming in every minute for N resources. Do we want to support this?

Resource #1: 11:00:01 UP
Resource #1: 11:00:02 UP
Resource #1: 11:00:03 UP
Resource #1: 11:00:04 UP
...56 datapoints later....
Resource #1: 11:01:00 UP
Resource #1: 11:01:01 UP
Resource #1: 11:01:02 UP
... and on ... and repeat for Resource #3, #5, etc (not every resource, but many of them).

Perhaps we store data like this, but only quickly aggregate them (say, every hour, aggregate this data into a tuple like "UP, 11:00:01, 11:01:02" where that is "avail state, begin time, end time").

I also find the pattern of the typical avail state of resources should be considered when designing the best storage schema for availability data (i.e. changes are very infrequent in between large amounts of time where the avail state is the same - "UP UP UP UP UP ... UP DOWN DOWN DOWN DOWN ..." - what's the best way to store that?). Storing just state changes has problems as we know (e.g. with alerts - we can only alert on state changes, like "Going UP" or "Going DOWN" not to mention what about admin states like "maintenance".

----- Original Message -----
> 
> I think this comes down more to what we *can* record. As we discussed a
> little bit in the past [1], the Hawkular model is not the RHQ model, meaning
> there is no heavy external agent performing scheduled avail checks and
> maintaining avail state for all of the resources. There may optionally be a
> lightweight agent checking a subset of resources for live-ness, the basic
> approach will be a push model, with feeds sending avail info as they see
> fit, for only the resources they see fit. And we have H Metrics doing the
> storage, which means no updates of current state, instead, just write values
> as they stream in. This results in Avail storage that will likely be more of
> what Micke is talking about, a lot of data points (most likely a lot of UP),
> very likely not just at the times of avail change.
> 
> We can do a couple of things with this data. It could be aggregated and
> stored as change intervals in the persistence layer (as a feature of H
> Metrics perhaps), and lose the individual data points. It can, at query time
> for an interval, be aggregated into change intervals, and also maintain the
> collection granularity.
> 
> Th decisions made here have a lot of impact on alerting, because at the
> moment the basic avail alerting use cases are not actually covered. Take
> Catherine's "basic" use-cases:
> 
> 
>     1. As an administrator of a website, I would like to configure Hawkular
>     so an alert is sent to me every time the system goes down.
>     2. As an administrator of a website, I would like to configure Hawkular
>     so an alert is only sent to me after the system is down for a certain
>     length of time, so I'm not alerted if there is a very minor downtime
>     event.
> 
> Case-1 is more subtle than it looks. This, I think, does not mean that the
> admin wants to be alerted every time the system is *reported* down, but
> rather when it goes down. This sort of alerting was easy in RHQ because we
> were only notified of changes in availability. "Goes DOWN" as opposed to "Is
> DOWN". In Hawkular we are likely talking about "Is DOWN", or possibly even
> the lack of "Is UP" reports. It's unclear yet, but we may need to somehow
> infer that something is down if it does not report "Is UP" for some period.
> In a push-oriented feed (like a ping), if something goes physically down it
> won't be able to report at all. Case-2 can't really be definitively solved
> until case-1 is well-defined.
> 
> At the moment alerting can fire an alert on every "Goes DOWN" report, or
> apply various dampening to those events. It can not guarantee a single alert
> for a specific down event unless the feed itself reports only changes in
> avail. Although, it can actually Having said that, we will shortly be
> looking at how to replace the "recovery-alert" logic of RHQ.
> 
> [1] https://developer.jboss.org/message/915970?et=watches.email.thread#915970
> 
> 
> On 2/16/2015 4:49 AM, Thomas Heute wrote:
> 
> 
> 
> On 02/13/2015 11:18 PM, Michael Burman wrote:
> 
> 
> 
> Hi,
> 
> I disagree, seeing this pattern first hand in resulting large penalty
> payment on one case (inability to prove that monitoring reported up on
> certain time when it wasn't responsive). If there's a need to monitor
> availability, there must be recorded event flow, eg:
> 
> Up 11:00
> Up 11:05
> Up 11:10
> Down 11:15
> Down 11:20
> Up 11:25
> 
> And why? If we only record:
> 
> Up 11:00 - 11:10
> Down 11:15 - 11:20
> Up 11:25 - ..
> 
> There's a difference. Did the monitoring system report 11:05 or was the
> monitoring system down 11:05? In many cases a need to prove that system
> was in certain state in certain times. Especially when there are SLA
> disagreements. Even more importantly, what happened between 11:10 -
> 11:15 and 11:20 - 11:25?
> Recording all datapoints doesn't give you more information on what
> happened between 2 recordings though.
> 
> But I get your point on the "inability to prove that monitoring reported
> up on certain time when it wasn't responsive".
> I didn't see availability recording as SLA proofs though.
> 
> 
> 
> The SLA behaviour requires that some system noticed something happening
> at certain point of time. And if there's issues with system
> responsibility say at 11:05, there needs to be a event showing that the
> system really did report up.
> You can't prove that system is up and running at a special point in
> time, you can only prove over a period of time if you made enough checks
> (interval lesser than the period of time of the SLA).
> 
> Thomas
> 
> 
> 
> - Micke
> 
> 
> On 13.02.2015 14:01, Thomas Heute wrote:
> 
> 
> 
> Getting back to availability discussion...
> 
> To me availability is a set of periods, not so much "time series" and
> we should just record change of status (closing the previous event and
> opening a new one).
> 
>     - Server is up from 8:00am to 11:30am
>     - Server is down from 11:30am to 11:32am
>     - Server is unknown from 11:32am to 12:00pm (an agent running on a
> machine can tell if a server is up or down, if the agent dies then we
> don't know if the server is up or down)
>     - Server is in erratic state from 12:00pm to 12:30pm (agent
> reports down every few requests)
> 
> We were discussing the best way to represent availability over time in
> a graph, representation in RHQ [1] is very decent IMO, can be extended
> with more colors to reflect how often/long the website was down for
> each "brick" (if the line represent a year with 52 blocks, 1 block can
> be more or less red depending on how long it was done during the week).
> 
> But thinking of it more, availability graph is not that interesting by
> itself IMO and more interesting in the context of other values.
> I attached a mockup of what I meant, a red area is displayed on
> response time graph, that means that the system is down, obviously
> there is no response time reported anymore in that period. Earlier
> there is an erratic area, seems related to higher response time ;)
> Rest of the time the system is just up and running...
> 
> Additionally I would want to see reports of availability:
>     - overall availability over a period of time (a day, a month, a
> year...). "99.99% available in the past month"
>     - lists of the down periods with start dates and duration for a
> particular resource or set of resources (filtering options)
> 
> Thoughts ?
> 
> [1]
> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
> Thomas
> 
> 
> _______________________________________________
> 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 ppalaga at redhat.com  Mon Feb 16 15:49:04 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 16 Feb 2015 21:49:04 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
Message-ID: <54E257C0.4040008@redhat.com>

Hi Stefan, inline...

On 02/16/2015 04:08 PM, Stefan Negrea wrote:
> Hello Peter,
>
> This came up on Friday, when me and Mazz worked on getting all the
> Travis builds to publish -SNAPSHOT artifacts. The goal was to get the
> main project (with the pinger) built both on Travis and locally.

Where could I have a look at that effort? I have seen something in
hawkular-bus master, but I do not see it in the main hawkular project.
Are you wanting to make the main hawkular project dependent on
components's SNAPSHOTs?

> I think it is essential to have the default repositories in the
> parent pom.

Yes, we have all in Maven Central. There is no need to introduce JBoss
Nexus because of the synchronisation delay.

> Community users should just do 'clone & mvn' to get started.

Yes, with the notice that there is this sync window that has a well
known workaround.

> Anything more complicated (like changing settings.xml or setting up
> profiles) is completely unacceptable. Since we are working with
> snapshots and have a myriad of projects, the essential repositories
> need to be in the parent pom.

Once again, you really want to introduce -SNAPSHOT deps master branches?

> If you notice, the repositories are in a profile that can be
> disabled. So there is a lot of configuration flexibility for power
> users (eg. the link you posted below).

Yes, we can offer hawkular-settings.xml for power users.

> Please do not revert these changes.

I do not see a need for these repos.

Thanks,

Peter

> Thank you, Stefan
>
> ----- Original Message -----
>> From: "Peter Palaga" <ppalaga at redhat.com> To: "Stefan Negrea"
>> <snegrea at redhat.com> Cc: hawkular-dev at lists.jboss.org Sent: Monday,
>> February 16, 2015 8:22:06 AM Subject: Maven repositories in
>> Hawkular Parent
>>
>> Hi Stefan,
>>
>> what was your specific motivation for adding the JBoss Repos?
>>
>> The topic was discussed before [1] with the result, that we will
>> not hard code any Maven repositories in Hawkular Parent. All we
>> produce and all we depend on should be on Maven Central.
>>
>> The only inconvenience with Central is that JBoss Nexus is synced
>> to central once a day only. The ones wanting to rely on freshly
>> released artifacts are recommended to add JBoss Nexus to their
>> settings.xml. This holds also for CI jobs.
>>
>> Thanks,
>>
>> Peter
>>
>> [1] on #hawkular on 2015-01-21, reasons against it are summed in
>> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>>

From mazz at redhat.com  Mon Feb 16 16:05:42 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 16 Feb 2015 16:05:42 -0500 (EST)
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <54E257C0.4040008@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
	<54E257C0.4040008@redhat.com>
Message-ID: <1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>

> Once again, you really want to introduce -SNAPSHOT deps master branches?

For now, in my opinion (which may not be worth much in these discussions) the answer is "yes." We already saw the problem last week when no one could really build the integration server without having to manually build all the components themselves (alerts, inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this work is moving at a fast pace - we don't want to have to worry about, say, waiting for Jay/Lucas to bump up their alerts version #, and releasing it.

BTW: we still can't build the integration server because the pinger and notifier/inventory stuff is in heiko's branches - so you still need to build those. But soon we should think about getting them in the hawkular repo - that might cause a heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the hospital visit. :}

Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual product out the door, but right now, we are moving so fast to try to get something out ASAP that we really need to support SNAPSHOT builds.

Again, I am not advocating one way or the other - I'm just pointing out the pain point I had last week, and the fact that it was the inability to get SNAPSHOTs from the repos is what was the cause.

From jsanda at redhat.com  Mon Feb 16 16:24:07 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Feb 2015 21:24:07 -0000
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
	<54E257C0.4040008@redhat.com>
	<1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
Message-ID: <E95FF13C-3E08-431C-8D24-73DC78E012EE@redhat.com>


> On Feb 16, 2015, at 4:05 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>> Once again, you really want to introduce -SNAPSHOT deps master branches?
> 
> For now, in my opinion (which may not be worth much in these discussions) the answer is "yes." We already saw the problem last week when no one could really build the integration server without having to manually build all the components themselves (alerts, inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this work is moving at a fast pace - we don't want to have to worry about, say, waiting for Jay/Lucas to bump up their alerts version #, and releasing it.
> 
> BTW: we still can't build the integration server because the pinger and notifier/inventory stuff is in heiko's branches - so you still need to build those. But soon we should think about getting them in the hawkular repo - that might cause a heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the hospital visit. :}
> 
> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual product out the door, but right now, we are moving so fast to try to get something out ASAP that we really need to support SNAPSHOT builds.

+1 I think that trying to depend on non-snapshot versions right now would just create a lot of extra work since things are really fluid right now.

> 
> Again, I am not advocating one way or the other - I'm just pointing out the pain point I had last week, and the fact that it was the inability to get SNAPSHOTs from the repos is what was the cause.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jsanda at redhat.com  Mon Feb 16 16:27:16 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Feb 2015 21:27:16 -0000
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
	<54E257C0.4040008@redhat.com>
	<1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
Message-ID: <E95FF13C-3E08-431C-8D24-73DC78E012EE@redhat.com>


> On Feb 16, 2015, at 4:05 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>> Once again, you really want to introduce -SNAPSHOT deps master branches?
> 
> For now, in my opinion (which may not be worth much in these discussions) the answer is "yes." We already saw the problem last week when no one could really build the integration server without having to manually build all the components themselves (alerts, inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this work is moving at a fast pace - we don't want to have to worry about, say, waiting for Jay/Lucas to bump up their alerts version #, and releasing it.
> 
> BTW: we still can't build the integration server because the pinger and notifier/inventory stuff is in heiko's branches - so you still need to build those. But soon we should think about getting them in the hawkular repo - that might cause a heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the hospital visit. :}
> 
> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual product out the door, but right now, we are moving so fast to try to get something out ASAP that we really need to support SNAPSHOT builds.

+1 I think that trying to depend on non-snapshot versions right now would just create a lot of extra work since things are really fluid right now.

> 
> Again, I am not advocating one way or the other - I'm just pointing out the pain point I had last week, and the fact that it was the inability to get SNAPSHOTs from the repos is what was the cause.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jsanda at redhat.com  Mon Feb 16 17:50:46 2015
From: jsanda at redhat.com (John Sanda)
Date: Mon, 16 Feb 2015 22:50:46 -0000
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
Message-ID: <F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>


> On Feb 16, 2015, at 3:48 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I will add the following to the discussion:
> 
> If past history with customers of JON/users of RHQ/salespeople is any indication, we will get requests to support collecting availability every second (if not every sub-second) even AFTER telling people, documenting, and shouting from the mountaintop that we are not a realtime profiler. So, do we have the throughput/infrastructure that can support one "UP" datapoint coming in every minute for N resources. Do we want to support this?

It seems like this should be a question of scale. Do we provide the scalability both in terms of storage and in terms of processing data to deal with those scenarios? Our strategy around scalability is a topic in its own right, but I do think it is relevant to some of the questions being raised in this thread.

> 
> Resource #1: 11:00:01 UP
> Resource #1: 11:00:02 UP
> Resource #1: 11:00:03 UP
> Resource #1: 11:00:04 UP
> ...56 datapoints later....
> Resource #1: 11:01:00 UP
> Resource #1: 11:01:01 UP
> Resource #1: 11:01:02 UP
> ... and on ... and repeat for Resource #3, #5, etc (not every resource, but many of them).
> 
> Perhaps we store data like this, but only quickly aggregate them (say, every hour, aggregate this data into a tuple like "UP, 11:00:01, 11:01:02" where that is "avail state, begin time, end time").
> 
> I also find the pattern of the typical avail state of resources should be considered when designing the best storage schema for availability data (i.e. changes are very infrequent in between large amounts of time where the avail state is the same - "UP UP UP UP UP ... UP DOWN DOWN DOWN DOWN ..." - what's the best way to store that?). Storing just state changes has problems as we know (e.g. with alerts - we can only alert on state changes, like "Going UP" or "Going DOWN" not to mention what about admin states like "maintenance".
> 
> ----- Original Message -----
>> 
>> I think this comes down more to what we *can* record. As we discussed a
>> little bit in the past [1], the Hawkular model is not the RHQ model, meaning
>> there is no heavy external agent performing scheduled avail checks and
>> maintaining avail state for all of the resources. There may optionally be a
>> lightweight agent checking a subset of resources for live-ness, the basic
>> approach will be a push model, with feeds sending avail info as they see
>> fit, for only the resources they see fit. And we have H Metrics doing the
>> storage, which means no updates of current state, instead, just write values
>> as they stream in. This results in Avail storage that will likely be more of
>> what Micke is talking about, a lot of data points (most likely a lot of UP),
>> very likely not just at the times of avail change.
>> 
>> We can do a couple of things with this data. It could be aggregated and
>> stored as change intervals in the persistence layer (as a feature of H
>> Metrics perhaps), and lose the individual data points. It can, at query time
>> for an interval, be aggregated into change intervals, and also maintain the
>> collection granularity.
>> 
>> Th decisions made here have a lot of impact on alerting, because at the
>> moment the basic avail alerting use cases are not actually covered. Take
>> Catherine's "basic" use-cases:
>> 
>> 
>>    1. As an administrator of a website, I would like to configure Hawkular
>>    so an alert is sent to me every time the system goes down.
>>    2. As an administrator of a website, I would like to configure Hawkular
>>    so an alert is only sent to me after the system is down for a certain
>>    length of time, so I'm not alerted if there is a very minor downtime
>>    event.
>> 
>> Case-1 is more subtle than it looks. This, I think, does not mean that the
>> admin wants to be alerted every time the system is *reported* down, but
>> rather when it goes down. This sort of alerting was easy in RHQ because we
>> were only notified of changes in availability. "Goes DOWN" as opposed to "Is
>> DOWN". In Hawkular we are likely talking about "Is DOWN", or possibly even
>> the lack of "Is UP" reports. It's unclear yet, but we may need to somehow
>> infer that something is down if it does not report "Is UP" for some period.
>> In a push-oriented feed (like a ping), if something goes physically down it
>> won't be able to report at all. Case-2 can't really be definitively solved
>> until case-1 is well-defined.
>> 
>> At the moment alerting can fire an alert on every "Goes DOWN" report, or
>> apply various dampening to those events. It can not guarantee a single alert
>> for a specific down event unless the feed itself reports only changes in
>> avail. Although, it can actually Having said that, we will shortly be
>> looking at how to replace the "recovery-alert" logic of RHQ.
>> 
>> [1] https://developer.jboss.org/message/915970?et=watches.email.thread#915970
>> 
>> 
>> On 2/16/2015 4:49 AM, Thomas Heute wrote:
>> 
>> 
>> 
>> On 02/13/2015 11:18 PM, Michael Burman wrote:
>> 
>> 
>> 
>> Hi,
>> 
>> I disagree, seeing this pattern first hand in resulting large penalty
>> payment on one case (inability to prove that monitoring reported up on
>> certain time when it wasn't responsive). If there's a need to monitor
>> availability, there must be recorded event flow, eg:
>> 
>> Up 11:00
>> Up 11:05
>> Up 11:10
>> Down 11:15
>> Down 11:20
>> Up 11:25
>> 
>> And why? If we only record:
>> 
>> Up 11:00 - 11:10
>> Down 11:15 - 11:20
>> Up 11:25 - ..
>> 
>> There's a difference. Did the monitoring system report 11:05 or was the
>> monitoring system down 11:05? In many cases a need to prove that system
>> was in certain state in certain times. Especially when there are SLA
>> disagreements. Even more importantly, what happened between 11:10 -
>> 11:15 and 11:20 - 11:25?
>> Recording all datapoints doesn't give you more information on what
>> happened between 2 recordings though.
>> 
>> But I get your point on the "inability to prove that monitoring reported
>> up on certain time when it wasn't responsive".
>> I didn't see availability recording as SLA proofs though.
>> 
>> 
>> 
>> The SLA behaviour requires that some system noticed something happening
>> at certain point of time. And if there's issues with system
>> responsibility say at 11:05, there needs to be a event showing that the
>> system really did report up.
>> You can't prove that system is up and running at a special point in
>> time, you can only prove over a period of time if you made enough checks
>> (interval lesser than the period of time of the SLA).
>> 
>> Thomas
>> 
>> 
>> 
>> - Micke
>> 
>> 
>> On 13.02.2015 14:01, Thomas Heute wrote:
>> 
>> 
>> 
>> Getting back to availability discussion...
>> 
>> To me availability is a set of periods, not so much "time series" and
>> we should just record change of status (closing the previous event and
>> opening a new one).
>> 
>>    - Server is up from 8:00am to 11:30am
>>    - Server is down from 11:30am to 11:32am
>>    - Server is unknown from 11:32am to 12:00pm (an agent running on a
>> machine can tell if a server is up or down, if the agent dies then we
>> don't know if the server is up or down)
>>    - Server is in erratic state from 12:00pm to 12:30pm (agent
>> reports down every few requests)
>> 
>> We were discussing the best way to represent availability over time in
>> a graph, representation in RHQ [1] is very decent IMO, can be extended
>> with more colors to reflect how often/long the website was down for
>> each "brick" (if the line represent a year with 52 blocks, 1 block can
>> be more or less red depending on how long it was done during the week).
>> 
>> But thinking of it more, availability graph is not that interesting by
>> itself IMO and more interesting in the context of other values.
>> I attached a mockup of what I meant, a red area is displayed on
>> response time graph, that means that the system is down, obviously
>> there is no response time reported anymore in that period. Earlier
>> there is an erratic area, seems related to higher response time ;)
>> Rest of the time the system is just up and running...
>> 
>> Additionally I would want to see reports of availability:
>>    - overall availability over a period of time (a day, a month, a
>> year...). "99.99% available in the past month"
>>    - lists of the down periods with start dates and duration for a
>> particular resource or set of resources (filtering options)
>> 
>> Thoughts ?
>> 
>> [1]
>> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
>> Thomas
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> _______________________________________________
> hawkular-dev mailing 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/20150216/01065984/attachment.html 

From mithomps at redhat.com  Mon Feb 16 23:16:56 2015
From: mithomps at redhat.com (mike thompson)
Date: Mon, 16 Feb 2015 20:16:56 -0800
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
Message-ID: <1B14BEE5-B0EB-4EFE-AAA6-0516521646C3@redhat.com>


> On 16 Feb 2015, at 12:48, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I will add the following to the discussion:
> 
> If past history with customers of JON/users of RHQ/salespeople is any indication, we will get requests to support collecting availability every second (if not every sub-second) even AFTER telling people, documenting, and shouting from the mountaintop that we are not a realtime profiler. So, do we have the throughput/infrastructure that can support one "UP" datapoint coming in every minute for N resources. Do we want to support this?
> 
> Resource #1: 11:00:01 UP
> Resource #1: 11:00:02 UP
> Resource #1: 11:00:03 UP
> Resource #1: 11:00:04 UP
> ...56 datapoints later....
> Resource #1: 11:01:00 UP
> Resource #1: 11:01:01 UP
> Resource #1: 11:01:02 UP
> ... and on ... and repeat for Resource #3, #5, etc (not every resource, but many of them).
> 
> Perhaps we store data like this, but only quickly aggregate them (say, every hour, aggregate this data into a tuple like "UP, 11:00:01, 11:01:02" where that is "avail state, begin time, end time").
> 
> I also find the pattern of the typical avail state of resources should be considered when designing the best storage schema for availability data (i.e. changes are very infrequent in between large amounts of time where the avail state is the same - "UP UP UP UP UP ... UP DOWN DOWN DOWN DOWN ..." - what's the best way to store that?). Storing just state changes has problems as we know (e.g. with alerts - we can only alert on state changes, like "Going UP" or "Going DOWN" not to mention what about admin states like "maintenance?.


As a UI (or any other client) we only want to know when the availability state changes. So why store redundant data. We have process it anyway (CPU cycles) to provide meaningful information from data. So for this first MVP (we can revisit this later) Why not skip the redundant data and just store the deltas. Let?s just work with what we need now.


> 
> ----- Original Message -----
>> 
>> I think this comes down more to what we *can* record. As we discussed a
>> little bit in the past [1], the Hawkular model is not the RHQ model, meaning
>> there is no heavy external agent performing scheduled avail checks and
>> maintaining avail state for all of the resources. There may optionally be a
>> lightweight agent checking a subset of resources for live-ness, the basic
>> approach will be a push model, with feeds sending avail info as they see
>> fit, for only the resources they see fit. And we have H Metrics doing the
>> storage, which means no updates of current state, instead, just write values
>> as they stream in. This results in Avail storage that will likely be more of
>> what Micke is talking about, a lot of data points (most likely a lot of UP),
>> very likely not just at the times of avail change.
>> 
>> We can do a couple of things with this data. It could be aggregated and
>> stored as change intervals in the persistence layer (as a feature of H
>> Metrics perhaps), and lose the individual data points. It can, at query time
>> for an interval, be aggregated into change intervals, and also maintain the
>> collection granularity.
>> 
>> Th decisions made here have a lot of impact on alerting, because at the
>> moment the basic avail alerting use cases are not actually covered. Take
>> Catherine's "basic" use-cases:
>> 
>> 
>>    1. As an administrator of a website, I would like to configure Hawkular
>>    so an alert is sent to me every time the system goes down.
>>    2. As an administrator of a website, I would like to configure Hawkular
>>    so an alert is only sent to me after the system is down for a certain
>>    length of time, so I'm not alerted if there is a very minor downtime
>>    event.
>> 
>> Case-1 is more subtle than it looks. This, I think, does not mean that the
>> admin wants to be alerted every time the system is *reported* down, but
>> rather when it goes down. This sort of alerting was easy in RHQ because we
>> were only notified of changes in availability. "Goes DOWN" as opposed to "Is
>> DOWN". In Hawkular we are likely talking about "Is DOWN", or possibly even
>> the lack of "Is UP" reports. It's unclear yet, but we may need to somehow
>> infer that something is down if it does not report "Is UP" for some period.
>> In a push-oriented feed (like a ping), if something goes physically down it
>> won't be able to report at all. Case-2 can't really be definitively solved
>> until case-1 is well-defined.
>> 
>> At the moment alerting can fire an alert on every "Goes DOWN" report, or
>> apply various dampening to those events. It can not guarantee a single alert
>> for a specific down event unless the feed itself reports only changes in
>> avail. Although, it can actually Having said that, we will shortly be
>> looking at how to replace the "recovery-alert" logic of RHQ.
>> 
>> [1] https://developer.jboss.org/message/915970?et=watches.email.thread#915970
>> 
>> 
>> On 2/16/2015 4:49 AM, Thomas Heute wrote:
>> 
>> 
>> 
>> On 02/13/2015 11:18 PM, Michael Burman wrote:
>> 
>> 
>> 
>> Hi,
>> 
>> I disagree, seeing this pattern first hand in resulting large penalty
>> payment on one case (inability to prove that monitoring reported up on
>> certain time when it wasn't responsive). If there's a need to monitor
>> availability, there must be recorded event flow, eg:
>> 
>> Up 11:00
>> Up 11:05
>> Up 11:10
>> Down 11:15
>> Down 11:20
>> Up 11:25
>> 
>> And why? If we only record:
>> 
>> Up 11:00 - 11:10
>> Down 11:15 - 11:20
>> Up 11:25 - ..
>> 
>> There's a difference. Did the monitoring system report 11:05 or was the
>> monitoring system down 11:05? In many cases a need to prove that system
>> was in certain state in certain times. Especially when there are SLA
>> disagreements. Even more importantly, what happened between 11:10 -
>> 11:15 and 11:20 - 11:25?
>> Recording all datapoints doesn't give you more information on what
>> happened between 2 recordings though.
>> 
>> But I get your point on the "inability to prove that monitoring reported
>> up on certain time when it wasn't responsive".
>> I didn't see availability recording as SLA proofs though.
>> 
>> 
>> 
>> The SLA behaviour requires that some system noticed something happening
>> at certain point of time. And if there's issues with system
>> responsibility say at 11:05, there needs to be a event showing that the
>> system really did report up.
>> You can't prove that system is up and running at a special point in
>> time, you can only prove over a period of time if you made enough checks
>> (interval lesser than the period of time of the SLA).
>> 
>> Thomas
>> 
>> 
>> 
>> - Micke
>> 
>> 
>> On 13.02.2015 14:01, Thomas Heute wrote:
>> 
>> 
>> 
>> Getting back to availability discussion...
>> 
>> To me availability is a set of periods, not so much "time series" and
>> we should just record change of status (closing the previous event and
>> opening a new one).
>> 
>>    - Server is up from 8:00am to 11:30am
>>    - Server is down from 11:30am to 11:32am
>>    - Server is unknown from 11:32am to 12:00pm (an agent running on a
>> machine can tell if a server is up or down, if the agent dies then we
>> don't know if the server is up or down)
>>    - Server is in erratic state from 12:00pm to 12:30pm (agent
>> reports down every few requests)
>> 
>> We were discussing the best way to represent availability over time in
>> a graph, representation in RHQ [1] is very decent IMO, can be extended
>> with more colors to reflect how often/long the website was down for
>> each "brick" (if the line represent a year with 52 blocks, 1 block can
>> be more or less red depending on how long it was done during the week).
>> 
>> But thinking of it more, availability graph is not that interesting by
>> itself IMO and more interesting in the context of other values.
>> I attached a mockup of what I meant, a red area is displayed on
>> response time graph, that means that the system is down, obviously
>> there is no response time reported anymore in that period. Earlier
>> there is an erratic area, seems related to higher response time ;)
>> Rest of the time the system is just up and running...
>> 
>> Additionally I would want to see reports of availability:
>>    - overall availability over a period of time (a day, a month, a
>> year...). "99.99% available in the past month"
>>    - lists of the down periods with start dates and duration for a
>> particular resource or set of resources (filtering options)
>> 
>> Thoughts ?
>> 
>> [1]
>> http://3.bp.blogspot.com/-0MsmG5h5i5E/TfjTMZlvx3I/AAAAAAAAABU/6PKDs0RlzuI/s1600/ProblemManagement-RHQ.png
>> Thomas
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> _______________________________________________
> hawkular-dev mailing 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/20150216/abe0675c/attachment-0001.html 

From jsanda at redhat.com  Tue Feb 17 00:06:20 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 17 Feb 2015 05:06:20 -0000
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <1B14BEE5-B0EB-4EFE-AAA6-0516521646C3@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
	<1B14BEE5-B0EB-4EFE-AAA6-0516521646C3@redhat.com>
Message-ID: <A81D89A7-5D5E-4A49-889D-DF57B2907BBA@redhat.com>


> On Feb 16, 2015, at 11:16 PM, mike thompson <mithomps at redhat.com> wrote:
> 
>> 
>> On 16 Feb 2015, at 12:48, John Mazzitelli <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>> 
>> I will add the following to the discussion:
>> 
>> If past history with customers of JON/users of RHQ/salespeople is any indication, we will get requests to support collecting availability every second (if not every sub-second) even AFTER telling people, documenting, and shouting from the mountaintop that we are not a realtime profiler. So, do we have the throughput/infrastructure that can support one "UP" datapoint coming in every minute for N resources. Do we want to support this?
>> 
>> Resource #1: 11:00:01 UP
>> Resource #1: 11:00:02 UP
>> Resource #1: 11:00:03 UP
>> Resource #1: 11:00:04 UP
>> ...56 datapoints later....
>> Resource #1: 11:01:00 UP
>> Resource #1: 11:01:01 UP
>> Resource #1: 11:01:02 UP
>> ... and on ... and repeat for Resource #3, #5, etc (not every resource, but many of them).
>> 
>> Perhaps we store data like this, but only quickly aggregate them (say, every hour, aggregate this data into a tuple like "UP, 11:00:01, 11:01:02" where that is "avail state, begin time, end time").
>> 
>> I also find the pattern of the typical avail state of resources should be considered when designing the best storage schema for availability data (i.e. changes are very infrequent in between large amounts of time where the avail state is the same - "UP UP UP UP UP ... UP DOWN DOWN DOWN DOWN ..." - what's the best way to store that?). Storing just state changes has problems as we know (e.g. with alerts - we can only alert on state changes, like "Going UP" or "Going DOWN" not to mention what about admin states like "maintenance?.
> 
> 
> As a UI (or any other client) we only want to know when the availability state changes. So why store redundant data. We have process it anyway (CPU cycles) to provide meaningful information from data. So for this first MVP (we can revisit this later) Why not skip the redundant data and just store the deltas. Let?s just work with what we need now.

It make sense to focus on what we need now especially since requirements are still being flushed out. With that said, the first and maybe easiest way I can think of to avoid storing redundant data is to implement a read-before-write pattern which is common and easy enough with the RDBMS.  The problem is that read before write does not scale, and I think scalability should be a primary consideration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/e7f3000b/attachment.html 

From fgiloux at redhat.com  Tue Feb 17 01:55:03 2015
From: fgiloux at redhat.com (Frederic Giloux)
Date: Tue, 17 Feb 2015 01:55:03 -0500 (EST)
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <A81D89A7-5D5E-4A49-889D-DF57B2907BBA@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
	<1B14BEE5-B0EB-4EFE-AAA6-0516521646C3@redhat.com>
	<A81D89A7-5D5E-4A49-889D-DF57B2907BBA@redhat.com>
Message-ID: <1058416100.19625875.1424156103968.JavaMail.zimbra@redhat.com>

Hi all,

I hope you don't mind an external input. In network performance reporting, which is usually done by other systems than the ones monitoring the network they use file stored time series. Cricket, an open source system uses RDD for instance: http://en.wikipedia.org/wiki/RRDtool
You may want to consider something similar?

Best Regards,

Fr?d?ric

Fr?d?ric Giloux 
Senior Middleware Consultant 

Red Hat GmbH 
MesseTurm, Friedrich-Ebert-Anlage 49, 60308 Frankfurt am Main 

Mobile: +49 (0) 174 1724661 
E-Mail: fgiloux at redhat.com , http://www.redhat.de/ 

Delivering value year after year 
Red Hat ranks # 1 in value among software vendors 
http://www.redhat.com/promo/vendor/ 

Freedom...Courage...Commitment...Accountability 
________________________________________________________________________ 
Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn, 
Handelsregister: Amtsgericht M?nchen, HRB 153243 
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters 

----- Original Message -----
From: "John Sanda" <jsanda at redhat.com>
To: "mike thompson" <mithomps at redhat.com>
Cc: hawkular-dev at lists.jboss.org
Sent: Thursday, January 22, 2015 11:19:02 PM
Subject: Re: [Hawkular-dev] Availability (Service and UI)





On Feb 16, 2015, at 11:16 PM, mike thompson < mithomps at redhat.com > wrote: 





On 16 Feb 2015, at 12:48, John Mazzitelli < mazz at redhat.com > wrote: 

I will add the following to the discussion: 

If past history with customers of JON/users of RHQ/salespeople is any indication, we will get requests to support collecting availability every second (if not every sub-second) even AFTER telling people, documenting, and shouting from the mountaintop that we are not a realtime profiler. So, do we have the throughput/infrastructure that can support one "UP" datapoint coming in every minute for N resources. Do we want to support this? 

Resource #1: 11:00:01 UP 
Resource #1: 11:00:02 UP 
Resource #1: 11:00:03 UP 
Resource #1: 11:00:04 UP 
...56 datapoints later.... 
Resource #1: 11:01:00 UP 
Resource #1: 11:01:01 UP 
Resource #1: 11:01:02 UP 
... and on ... and repeat for Resource #3, #5, etc (not every resource, but many of them). 

Perhaps we store data like this, but only quickly aggregate them (say, every hour, aggregate this data into a tuple like "UP, 11:00:01, 11:01:02" where that is "avail state, begin time, end time"). 

I also find the pattern of the typical avail state of resources should be considered when designing the best storage schema for availability data (i.e. changes are very infrequent in between large amounts of time where the avail state is the same - "UP UP UP UP UP ... UP DOWN DOWN DOWN DOWN ..." - what's the best way to store that?). Storing just state changes has problems as we know (e.g. with alerts - we can only alert on state changes, like "Going UP" or "Going DOWN" not to mention what about admin states like "maintenance?. 


As a UI (or any other client) we only want to know when the availability state changes. So why store redundant data. We have process it anyway (CPU cycles) to provide meaningful information from data. So for this first MVP (we can revisit this later) Why not skip the redundant data and just store the deltas. Let?s just work with what we need now. 

It make sense to focus on what we need now especially since requirements are still being flushed out. With that said, the first and maybe easiest way I can think of to avoid storing redundant data is to implement a read-before-write pattern which is common and easy enough with the RDBMS. The problem is that read before write does not scale, and I think scalability should be a primary consideration. 

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


From hrupp at redhat.com  Tue Feb 17 02:46:36 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 08:46:36 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54DE783D.4030002@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
Message-ID: <D949D884-CEBC-4890-BD66-9CFA13103A18@redhat.com>

Hi,

> The SLA behaviour requires that some system noticed something happening at certain point of time. And if there's issues with system responsibility say at 11:05, there needs to be a event showing that the system really did report up.

I think we may ned to look at two things

- determining availability
- storing/displaying it.

In RHQ/Jon, the plugin is doing periodic checks and reporting results.
If the agent/server connection is down we at some point in time recorded that
and did "backfill".
RHQ does not allow a resource to say "Hey, I am going down". Nor does it allow to have 
e.g. a 2nd agent to also check availability by e.g. pinging the resource.
Another drawback in RHQ are the sometimes very large reporting intervals
that trigger the uncertainty that you mention

In Hawkular we need to change the logic in a way that allows for multiple sources to
contribute to the overall picture (see for example diagram on https://developer.jboss.org/thread/251479 ).
And with those much better information and smaller check intervals, the uncertainty 
decreases.

The whole of availability recording and alerting on it only makes sense if our
system notifies the admin before the customer does.

I am still convinced that some sort of run length encoding for the stored data
< start time, end time (?), state > is the way to go. Especially when the system
is not going up and down every other second, but stable for long times.
In RHQ we made the error to have a triple
< start, end, state> where end was null for an ongoing interval, so we had to
not only insert a new <start, end, state> triple, but to also update the previous one
with the end time.
This is something we should do better this time. Question of getting the time range
still remains as even with only tuples of <start, state> for questions like "what was 
the state last midnight" or "how was availability at Dec 15th at noon". Or for computations
of "give me percentage of all availabilty states in the month of January".
Here having  many many points in time with state makes it easier at the expense of 
storage usage.

From hrupp at redhat.com  Tue Feb 17 02:56:59 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 08:56:59 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <54E257C0.4040008@redhat.com>
References: <54E1FD0E.8070407@redhat.com>
	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>
	<54E257C0.4040008@redhat.com>
Message-ID: <A29FFFA3-85E0-4776-ABD4-D80C059F6E2A@redhat.com>


> Am 16.02.2015 um 21:49 schrieb Peter Palaga <ppalaga at redhat.com>:
> Are you wanting to make the main hawkular project dependent on
> components's SNAPSHOTs?

*Named* snapshots.

The underlying issue is that we want on each push to a master branch in one
of the projects to build it with the available dependencies (and the deploy - the
latter is not yet there but being worked on).
To achieve this, we need to have a "cache" that is reachable from Travis or for
internal and community users with the latest dependencies. They should never
need to check out a sub-project they are not interested in to compile the component
they want to work on.
And for the moment the idea is/was to use the snapshots repo of Nexus as this cache.

Of course we could release (with all the expensive release procedure) a 1.x.0 release
of all the components after a successful build, but I think this is not how publishing
to Central is supposed to work and we also so not want to spam it with hundreds of 
versions of our stuff.



From tsegismo at redhat.com  Tue Feb 17 03:42:00 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 17 Feb 2015 09:42:00 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>
References: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>
Message-ID: <54E2FED8.2070404@redhat.com>

Thanks for your feedback Chris, that's also my experience with writing 
Puppet modules.

Le 13/02/2015 20:19, Chris Pitman a ?crit :
> Hey guys,
>
> I'm a bit late to the party, but here are my two cents as someone who has spent
> months integrating Puppet with EAP 6 (https://github.com/cpitman/puppet-jboss_admin).
>
>> >/  > 3) Why not try to have all our configuration set in standalone.xml? If we
> />/  />/  > are going to be deployed in Wildfly, it would be nice to have everything
> /> >/  > (not just our config, but the config for the wildfly subsystems too) in
> /> >/  > one place. This also allows us to piggyback on jboss-cli - we simply use
>>/>/  > the jboss-cli to have a cmdline interface to our configuration.
>>/>/
>>/>/  I'd rather keep our apps config out the Wildfly config.
> /
>> What is your reasoning for wanting to keep our apps config out of Wildfly config?
>> The reason why I say it would be nice to use standalone.xml for our config is:
>> 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).
>> 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems.
>
> The CLI is a painful way to automate deployment using declarative tools like Puppet.
> If the goal is to make it easy to configure and deploy, files are superior. Yes,
> standalone.xml is a file, but you can only edit it by shutting down the container
> first (and scripting doing this in Puppet is also non-fun).
>
> Not to say it impossible. The module I linked above could be used, but it is still
> vastly more complicated than a solution that just needs a templated config file.
>
>> 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.
>> 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.
>> The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.
>> But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs.
>
>
> Chris Pitman
> Architect, Red Hat Consulting
> DevOps Community of Practice Manager
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Tue Feb 17 04:01:27 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 17 Feb 2015 10:01:27 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <E95FF13C-3E08-431C-8D24-73DC78E012EE@redhat.com>
References: <54E1FD0E.8070407@redhat.com>	<1453545932.10815277.1424099335776.JavaMail.zimbra@redhat.com>	<54E257C0.4040008@redhat.com>	<1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
	<E95FF13C-3E08-431C-8D24-73DC78E012EE@redhat.com>
Message-ID: <54E30367.5090408@redhat.com>

I can understand the need.

The main issue with depending on SNAPSHOTs is the non-reproducibility of 
the builds - clearly, because a SNAPSHOT of an artifact A can be 
distinct at any two instants t1 and t2. This alone is a sufficient 
reason for not allowing SNAPSHOT dependencies in any durable public 
branches.

Please try to imagine how could you figure out what is the problem with 
a SNAPSHOT dependency. By default, there is zero revision info available 
in jars and poms.

= Building locally

My personal view (that I do not force to any one) is that it is quite 
normal to have to git-pull the components I depend on, build them 
locally and then, in my consuming project override the version props to 
the SNAPSHOTs (e.g. using a profile in my settings). All steps are 
perfectly scriptable and such a script can be written once and shared.

The advantage of this approach is that one always knows what git 
revision at which instant was used to build the snapshots. One has the 
history of all components at hand for the case that something goes 
wrong. It is easy to reset the broken component to the last "known as 
correct" state, rebuild and work on one's own stuff in the consuming 
project.


= CI

It is nice to know early that some change in upstream component has 
broken a consuming project. The CI can either use the script used 
locally (easy) or some kind of properly labeled nightly builds 
(complicated).

-- Peter


On 01/22/2015 09:11 PM, John Sanda wrote:
>
>> On Feb 16, 2015, at 4:05 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>
>>> Once again, you really want to introduce -SNAPSHOT deps master branches?
>>
>> For now, in my opinion (which may not be worth much in these discussions) the answer is "yes." We already saw the problem last week when no one could really build the integration server without having to manually build all the components themselves (alerts, inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this work is moving at a fast pace - we don't want to have to worry about, say, waiting for Jay/Lucas to bump up their alerts version #, and releasing it.
>>
>> BTW: we still can't build the integration server because the pinger and notifier/inventory stuff is in heiko's branches - so you still need to build those. But soon we should think about getting them in the hawkular repo - that might cause a heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the hospital visit. :}
>>
>> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual product out the door, but right now, we are moving so fast to try to get something out ASAP that we really need to support SNAPSHOT builds.
>
> +1 I think that trying to depend on non-snapshot versions right now would just create a lot of extra work since things are really fluid right now.
>
>>
>> Again, I am not advocating one way or the other - I'm just pointing out the pain point I had last week, and the fact that it was the inability to get SNAPSHOTs from the repos is what was the cause.
>> _______________________________________________
>> 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 Feb 17 04:21:40 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 17 Feb 2015 10:21:40 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>
References: <54DDE780.1050207@redhat.com>
	<54DE783D.4030002@redhat.com>	<54E1BD18.5010905@redhat.com>
	<54E20AEE.9000608@redhat.com>	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
	<F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>
Message-ID: <54E30824.3000409@redhat.com>


On 01/22/2015 07:48 PM, John Sanda wrote:
>
>> On Feb 16, 2015, at 3:48 PM, John Mazzitelli <mazz at redhat.com 
>> <mailto:mazz at redhat.com>> wrote:
>>
>> I will add the following to the discussion:
>>
>> If past history with customers of JON/users of RHQ/salespeople is any 
>> indication, we will get requests to support collecting availability 
>> every second (if not every sub-second) even AFTER telling people, 
>> documenting, and shouting from the mountaintop that we are not a 
>> realtime profiler. So, do we have the throughput/infrastructure that 
>> can support one "UP" datapoint coming in every minute for N 
>> resources. Do we want to support this?
>
> It seems like this should be a question of scale. Do we provide the 
> scalability both in terms of storage and in terms of processing data 
> to deal with those scenarios? Our strategy around scalability is a 
> topic in its own right, but I do think it is relevant to some of the 
> questions being raised in this thread.

It should be reasonable ;)
IMHO typically one would be happy with a check every 20s/30s or even a 
minute if the cost is "low", ie: the cost of the monitoring 
infrastructure is a small fraction of the infrastructure itself.

We need to scale horizontally for processing data and storage (adding 
Cassandra nodes ?), reaching 1s support won't come without additional 
infrastructure cost. For sub-second support, I would question the need 
to store that information, I don't think we should look into this now.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/387ff2ef/attachment.html 

From hrupp at redhat.com  Tue Feb 17 05:52:28 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 11:52:28 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54E30824.3000409@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
	<F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>
	<54E30824.3000409@redhat.com>
Message-ID: <04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>


> Am 17.02.2015 um 10:21 schrieb Thomas Heute <theute at redhat.com>:
> IMHO typically one would be happy with a check every 20s/30s or even a minute if the cost is "low", ie: the cost of the monitoring infrastructure is a small fraction of the infrastructure itself.

We need to consider this at different levels.

An agent may be able to determine process availability every second cheaply. This does not imply
that it needs to forward that information every second to the server. And even if it did, it does not
imply that we need to store a data point for every second.

One thing we did never really fit into classical RHQ is caching.
A Map<Long,Byte> for the last known state of a resource (*) can easily store the last known
availability state for a huge number of resources. This way we would not need to query the
database for each incoming point, but we'd look up the value in the cache and only store
when it differs.
Needs a bit more investigating + modelling to expire entries in the cache that do not get a 
data point every now and then and inform other subsystems (alerting) - that is not too heavy to implement.
The agent can do similar caching for its resources and only forwarding when the state changes.

This way we can scale to a lot of checks agent side without overwhelming server and data store.


*) Yes I know we are currently using string IDs in many places. We may reconsider that for resource ids.

From lkrejci at redhat.com  Tue Feb 17 05:42:42 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Feb 2015 11:42:42 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com> <54E257C0.4040008@redhat.com>
	<1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
Message-ID: <2336524.5EmVLX0ItN@localhost.localdomain>


> > Once again, you really want to introduce -SNAPSHOT deps master branches?

> 
> For now, in my opinion (which may not be worth much in these discussions)
> the answer is "yes." We already saw the problem last week when no one could
> really build the integration server without having to manually build all
> the components themselves (alerts, inventory, pinger, bus, etc). And we
> don't want them to be non-snapshots because this work is moving at a fast
> pace - we don't want to have to worry about, say, waiting for Jay/Lucas to
> bump up their alerts version #, and releasing it.
> 
> BTW: we still can't build the integration server because the pinger and
> notifier/inventory stuff is in heiko's branches - so you still need to
> build those. But soon we should think about getting them in the hawkular
> repo - that might cause a heart attack in Lukas K. but if we promise to
> redo it later, I think he'll survive the hospital visit. :}
> 

I merged the changes myself, so the notifier is in hawkular-inventory 
(https://github.com/hawkular/hawkular-inventory/pull/12). You know me well - 
my soul died a little doing it 


> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some
> actual product out the door, but right now, we are moving so fast to try to
> get something out ASAP that we really need to support SNAPSHOT builds.
> 

+1. I bit the bullet with actually depending on the bus in the component code 
(the horrors!), because of the same reason - we unfortunately need to move 
fast and can't afford to be purist ATM. 

That said, all these violations should be filed as release blockers 
(https://issues.jboss.org/browse/HWKINVENT-11) 


> Again, I am not advocating one way or the other - I'm just pointing out the
> pain point I had last week, and the fact that it was the inability to get
> SNAPSHOTs from the repos is what was the cause.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

From lkrejci at redhat.com  Mon Feb 16 19:22:11 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Feb 2015 01:22:11 +0100
Subject: [Hawkular-dev] Maven repositories in Hawkular Parent
In-Reply-To: <1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
References: <54E1FD0E.8070407@redhat.com> <54E257C0.4040008@redhat.com>
	<1485057079.12944557.1424120742593.JavaMail.zimbra@redhat.com>
Message-ID: <3453903.eJsSLP7A5W@localhost.localdomain>

On Monday, February 16, 2015 04:05:42 PM John Mazzitelli wrote:
> > Once again, you really want to introduce -SNAPSHOT deps master branches?
> 
> For now, in my opinion (which may not be worth much in these discussions)
> the answer is "yes." We already saw the problem last week when no one could
> really build the integration server without having to manually build all
> the components themselves (alerts, inventory, pinger, bus, etc). And we
> don't want them to be non-snapshots because this work is moving at a fast
> pace - we don't want to have to worry about, say, waiting for Jay/Lucas to
> bump up their alerts version #, and releasing it.
> 
> BTW: we still can't build the integration server because the pinger and
> notifier/inventory stuff is in heiko's branches - so you still need to
> build those. But soon we should think about getting them in the hawkular
> repo - that might cause a heart attack in Lukas K. but if we promise to
> redo it later, I think he'll survive the hospital visit. :}
> 

I merged the changes myself, so the notifier is in hawkular-inventory 
(https://github.com/hawkular/hawkular-inventory/pull/12). You know me well - 
my soul died a little doing it ;)

> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some
> actual product out the door, but right now, we are moving so fast to try to
> get something out ASAP that we really need to support SNAPSHOT builds.
> 

+1. I bit the bullet with actually depending on the bus in the component code 
(the horrors!), because of the same reason - we unfortunately need to move 
fast and can't afford to be purist ATM. 

That said, all these violations should be filed as release blockers 
(https://issues.jboss.org/browse/HWKINVENT-11) ;)

> Again, I am not advocating one way or the other - I'm just pointing out the
> pain point I had last week, and the fact that it was the inability to get
> SNAPSHOTs from the repos is what was the cause.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From lkrejci at redhat.com  Tue Feb 17 06:55:18 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 17 Feb 2015 12:55:18 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
References: <54DDE780.1050207@redhat.com> <54E30824.3000409@redhat.com>
	<04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
Message-ID: <12737189.TOzuU1guXf@localhost.localdomain>

On Tuesday, February 17, 2015 11:52:28 AM Heiko W.Rupp wrote:
> > Am 17.02.2015 um 10:21 schrieb Thomas Heute <theute at redhat.com>:
> 
> *) Yes I know we are currently using string IDs in many places. We may
> reconsider that for resource ids.

Do you envision these being generated on the feed-side or server-side?

Currently, all we plan to do is advise a scheme for getting unique resource 
ids on the feed-side (almost) without server intervention.

The feed only needs to remember its server-assigned ID. From there on, it can 
use the naming scheme of (something like):

feed://<feedId>/resource/<resourceId>

where resource ID is generated on the feed side (and can be numeric, name, 
whathever, we don't care).

(https://issues.jboss.org/browse/HWKINVENT-12)

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


From miburman at redhat.com  Tue Feb 17 07:16:06 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 17 Feb 2015 14:16:06 +0200
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
References: <54DDE780.1050207@redhat.com>
	<54DE783D.4030002@redhat.com>	<54E1BD18.5010905@redhat.com>
	<54E20AEE.9000608@redhat.com>	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>	<F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>	<54E30824.3000409@redhat.com>
	<04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
Message-ID: <54E33106.6080601@redhat.com>

Hi,

We already have dependency to Google's Guava, so there's a well tested 
cache implementation (with filling strategies and eviction strategies) 
already. No need to reinvent this one ;)

   - Micke

On 17.02.2015 12:52, Heiko W.Rupp wrote:
>> Am 17.02.2015 um 10:21 schrieb Thomas Heute <theute at redhat.com>:
>> IMHO typically one would be happy with a check every 20s/30s or even a minute if the cost is "low", ie: the cost of the monitoring infrastructure is a small fraction of the infrastructure itself.
> We need to consider this at different levels.
>
> An agent may be able to determine process availability every second cheaply. This does not imply
> that it needs to forward that information every second to the server. And even if it did, it does not
> imply that we need to store a data point for every second.
>
> One thing we did never really fit into classical RHQ is caching.
> A Map<Long,Byte> for the last known state of a resource (*) can easily store the last known
> availability state for a huge number of resources. This way we would not need to query the
> database for each incoming point, but we'd look up the value in the cache and only store
> when it differs.
> Needs a bit more investigating + modelling to expire entries in the cache that do not get a
> data point every now and then and inform other subsystems (alerting) - that is not too heavy to implement.
> The agent can do similar caching for its resources and only forwarding when the state changes.
>
> This way we can scale to a lot of checks agent side without overwhelming server and data store.
>
>
> *) Yes I know we are currently using string IDs in many places. We may reconsider that for resource ids.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Tue Feb 17 07:45:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 13:45:56 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <12737189.TOzuU1guXf@localhost.localdomain>
References: <54DDE780.1050207@redhat.com> <54E30824.3000409@redhat.com>
	<04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
	<12737189.TOzuU1guXf@localhost.localdomain>
Message-ID: <DEA199A0-25D6-4779-A90D-79B53C70A57E@redhat.com>


> Am 17.02.2015 um 12:55 schrieb Lukas Krejci <lkrejci at redhat.com>:
> 
> Do you envision these being generated on the feed-side or server-side?

No idea :)

Just because we have a 32char string that has a name of universally unique
does not guarantee that it is unique. Each client/feed could name its toplevel
resource "main....32" :-) so it may make sense to have some collision detection
in place if feeds send what they want.

I also did not imply we *have to* change to numbers.

Fact is though that in many places the randomly long ids waste space
and bandwidth. 
Especially when using a cache with those long ids as key and a payload
of a single byte. 




From hrupp at redhat.com  Tue Feb 17 07:47:07 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 13:47:07 +0100
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <54E33106.6080601@redhat.com>
References: <54DDE780.1050207@redhat.com> <54DE783D.4030002@redhat.com>
	<54E1BD18.5010905@redhat.com> <54E20AEE.9000608@redhat.com>
	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>
	<F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>
	<54E30824.3000409@redhat.com>
	<04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
	<54E33106.6080601@redhat.com>
Message-ID: <9B2BEEAB-B957-471F-98AF-BF72F1466B38@redhat.com>


> Am 17.02.2015 um 13:16 schrieb Michael Burman <miburman at redhat.com>:
> 
> Hi,
> 
> We already have dependency to Google's Guava, so there's a well tested 
> cache implementation (with filling strategies and eviction strategies) 
> already. No need to reinvent this one ;)

Evicting alone is not enough. We also need to forward that case to alerting
and other parties. That may or may not be possible with Guava - I have no idea.



From hrupp at redhat.com  Tue Feb 17 08:36:49 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 14:36:49 +0100
Subject: [Hawkular-dev] REST-api docs
Message-ID: <539428C0-694F-4EA9-B88A-A4DA3D9F7CF3@redhat.com>

Hey,

We should add the swagger annotations(*) to the rest-api to have
the documentation source where the rest-annotations live and not
in separate readme files, that get outdated pretty quickly.

The annotations are then processed by an annotation processor
and can be (via the one we have) be turned into xml , html, docbook.
In fact I can hack the processor to also emit AsciiDoc which then can
be easily added to the developer documentation.

RHQ has some pretty extensive usage of the swagger annotations - 
the result in the JON documentation can be browsed here

https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.3/html/Rest_API/index.html

  Heiko


*) Those are runtime annotations and do not require the servlet being
deployed or anything.

From vrockai at redhat.com  Tue Feb 17 08:44:53 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Tue, 17 Feb 2015 14:44:53 +0100
Subject: [Hawkular-dev] [Metrics] Python client and perspective from
 client developing..
In-Reply-To: <54E1EEF0.70604@redhat.com>
References: <54E1EEF0.70604@redhat.com>
Message-ID: <1424180693.22809.4.camel@vrockai-laptop>

Hi,

I'm replying so this thread is not forgotten. I've got similar troubles
when creating services for the UI. Readme files for our rest apis
(including how to build/start servers) are outdated. Is someone working
on that, do we need to create JIRAs, or we just don't care at this point
since the iron is still hot?

Thanks,

Viliam

On Mon, 2015-02-16 at 15:21 +0200, Michael Burman wrote:
> Hi,
> 
> As we need clients to actually push data to our system (and that way to 
> get users & community), I've written one for the Python. I've tried to 
> follow what a normal contributor would do and just read the 
> documentation that's available. Short story - there isn't enough 
> documentation.
> 
> I don't think we reached a consensus yet where to push the client source 
> codes, so I haven't created a pull request for this and for that reason 
> haven't renamed the repository either. It is available from 
> https://github.com/burmanm/rhq-metrics-python-client with documentation. 
> I'll gladly take ideas, my Python most likely looks like some other 
> language written in Python syntax - but it works.
> 
> There are tests that trigger against the real hawkular-metrics server 
> (0.30.0-SNAPSHOT). Usually the Python client developers target a mocked 
> endpoint, but I decided to go after the real server as I believe our API 
> might still change and the documentation isn't a reliable reference 
> point. I tried to follow the documentation on 
> https://github.com/hawkular/hawkular-metrics/tree/master/api/metrics-api-jaxrs 
> but I had to revert in some cases to reading the source code on what was 
> really wanted, especially after receiving 400 / 500 error codes while 
> doing the testing (when the json looked like in the examples). I also 
> only created abilities that are defined on that page, as I have no idea 
> if rest of the undocumented REST APIs are actually there to stay or to 
> be removed.
> 
> Which brings me to the question, what parts of the API are stable at the 
> moment? There's counters and such which are not documented at all. We 
> have huge selection of endpoints for any client developer to implement, 
> perhaps too many of them. I can try to improve documentation, but even 
> then I would want to know what's going on. I heard alerts is getting 
> swagger-annotations, which is nice.
> 
>    -  Micke
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From rhauch at redhat.com  Tue Feb 17 08:59:45 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Tue, 17 Feb 2015 07:59:45 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <54E1C085.2070702@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<54E1C085.2070702@redhat.com>
Message-ID: <6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>


> On Feb 16, 2015, at 4:03 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Le 13/02/2015 18:43, Randall Hauch a ?crit :
>> How will the work be split up across the cluster? Are the incoming
>> messages stored before they?re processed?
>> 
> 
> An Hawkular metrics server is web server (Wildfly) in front of a Cassandra cluster.
> 
> So you'd distribute the work with a load balancer.
> 
> I'm not sure I understand your second question.
> 

My question is simply this: is the raw incoming data persisted before any other computations or analyses are done? The answer dictates whether Hawkular has the potential to lose data in a crash. The only reason I bring this up is that monitoring (like data storage) is one of those use cases where you can?t really afford to drop or lose any data, since for monitoring that lost data might be the critical evidence you need to understand why something bad happened to your monitored system.

Let?s say that a collector sends some data that will ultimately be processed by Hawkular, including updating various windows (e.g., minutely, hourly, daily, etc.), before persisting. If Hawkular crashes before that data is completely processed, then that data will be lost forever. If Hawkular performs some of the work (e.g., just updating the minutely window) before crashing, then the data appears in only some of the generated/derived information. BTW, in this traditional approach, using a transaction will simply ensure that all of your derived/generated data is consistent; it doesn?t ensure that your data is processed.

If, however, Hawkular were to persist the collected data *before* processing anything, then as long as the incoming data were persisted then if Hawkular crashed and was restarted it might be able to just continue where it left off, without losing any data or computations. There are lots of ways of ensuring this, but it?s not likely they will all perform well.

The stream-oriented architectures make it possible to not lose any data, because every computation or bit of processing is done in services/jobs that read from and write to (usually persistent) streams. The architecture can ensure at-least-once (and sometimes an exactly-once) semantics for every bit of data passing thru each stream. Of course, this is done without transactions and often with partitioned streams to allow things to scale quite well and handle very large volumes of data.


>>> 
>>> Most collectors buffer data to be sent and operate in separate threads.
>>> So if the metrics ingestion rate decreases, they'll consume more memory.
>>> Other than that, it should have limited impact on your service.
>> 
>> Sounds good.
>> 
>>> 
>>>> 
>>>> Also, how do you plan to ensure that, no matter what happens to the
>>>> Hawkular system or anything it depends upon, no client information is
>>>> every lost or dropped?
>>> 
>>> Usually collectors will drop data once buffers are full. If you want to
>>> make sure no data is lost, then you need to build a custom sender.
>>> Hawkular metrics has an HTTP interface so the response code should tell
>>> you if a metric was successfully persisted.
>> 
>> So I understand that the collectors will drop any buffered data, since
>> that will be unsent if the monitored system (or external collectors)
>> crash. But what happens if Hawkular suffers a partial or total crash?
>> What data is lost? What happens to data that was in-process when the
>> crash occurred? Stream-based architectures are interesting because they
>> often can handle more load, partition it more effectively, and are more
>> durable.
> 
> If you lose Wildfly servers or Cassandra nodes then the rest of cluster should continue to work.
> 
> As a Hawkular metrics client, you can't say what happened to your data if you lose the connection before you get a response with a status code. When a Wildfly server crashes, your data may be still being unmarshaled, or might have reached the Cassandra driver, or have been written to the Cassandra logs.
> 
> We have no plan ATM to implement log-based event processors ourselves. In the beginning, we'll focus on existing and wide-spread collectors (generally buffer-based) and in-house collectors like the wildfly-monitor.
> 
>> 
>>> 
>>>> 
>>>> Finally, is the plan to make Hawkular embeddable (excluding the stuff
>>>> that has to be embedded in monitored clients/systems/services), or
>>>> only a separate turn-key (i.e., install-and-run-and-use) system?
>>> 
>>> Hawkular metrics comes in two forms:
>>> * a Java library (metrics-core)
>>> * a Java EE web application (built on top of the library)
>>> 
>>> metrics-core can be embedded in any sort of JVM application but it
>>> expects to find a Cassandra cluster somewhere.
>>> 
>>> 
>>> 
>>> I hope it helps. Feel free to ask for details.
>>> 
>>> And welcome to Hawkular!
>>> 
>>> Thomas
>>> _______________________________________________
>>> 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
>> 
> 



From hrupp at redhat.com  Tue Feb 17 09:15:52 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 15:15:52 +0100
Subject: [Hawkular-dev] Documentation writing
Message-ID: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>

Hey,

as we made some progress with hawkular.github.io, the question came up what should go there and if we can't just use something else instead.

I am very much in favor of using AsciiDoc + git for the documentation -- user and developer

Clear advantages that I see for this solution:

- versioning is easy as it is built into git. We can easily create branches for various versions of the Hawkular
without the complicated clone process that we had in the past
- offline possibility an author does not need to be online to write docs
- AsciiDoc is plain text. The pages may have a handful of specific header lines, but if you don't want to format any markup, then just don't
- Contributing is easy. People just git clone the repo, make their changes and submit a pull-request
- docs are directly rendered on GitHub
- AsciiDoc is already used in our README.adoc files
- With AsciiDoctor there is a good tool chain for creating good print, html, pdf, docbook output
- it is possible to write docs in vi/emacs/Notepad

Tooling may not yet be that perfect; the mvn jbake:inline mode is already quite well able to re-create 
the website locally though; with a browser extension like "live-reload", editing a text is as wysiwyg as on a wiki


There are other JBoss projects that follow the AsciiDoc+git approach with great success
like http://arquillian.org, http://hibernate.org, http://liveoak.io, http://torquebox.org(*)

Anyway I've started a doodle to get feedback and then proceed further - so please visit
http://doodle.com/a8ctk6wgwi3nh9f8
so that we can come to a documentation solution that we all use.

  Heiko

*) Actually uses Markdown as markup language




From hrupp at redhat.com  Tue Feb 17 09:25:32 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 15:25:32 +0100
Subject: [Hawkular-dev] About configuration
In-Reply-To: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>
References: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>
Message-ID: <5FBE74EE-FF63-49E0-87B2-9EE2447F1EB8@redhat.com>


> Am 13.02.2015 um 20:19 schrieb Chris Pitman <cpitman at redhat.com>:
> standalone.xml is a file, but you can only edit it by shutting down the container 
> first (and scripting doing this in Puppet is also non-fun).

So with umpteen components, we deliver umpteen config files, that
all need to be tweaked on top of standalone.xml to get something working?
That does not sound right either.



From hrupp at redhat.com  Tue Feb 17 10:51:31 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 17 Feb 2015 16:51:31 +0100
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
Message-ID: <CA4C86A0-A245-458B-AA50-1B9287A94AD5@redhat.com>

As promised to some here is a list of AsciiDoc(tor) resources

* Website that has a edit half and a live-preview  https://asciidoclive.com <https://asciidoclive.com/> (found by Lucas P)
* IntelliJ has an AsciiDoctor plugin that allows to basically do the same (see below)
* AD syntax http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#source-code <http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#source-code>
* AsciiDoctor home page http://asciidoctor.org <http://asciidoctor.org/>
* AsciiDoc writers guide http://asciidoctor.org/docs/asciidoc-writers-guide/ <http://asciidoctor.org/docs/asciidoc-writers-guide/>
* Editing AsciiDoc with Live Preview http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/ <http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/>
* (Start of a) Eclipse Asciidoctor plugin http://marketplace.eclipse.org/node/2162366 <http://marketplace.eclipse.org/node/2162366>
* Netbeans plugin https://blogs.oracle.com/geertjan/entry/asciidoctor_netbeans <https://blogs.oracle.com/geertjan/entry/asciidoctor_netbeans>


As Mike mentioned, you can go to GitHub, click on a .adoc page and then use the pencil icon



Directly edit + preview



And then commit / open a PR ( I think commit is only enabled for repo collaborators, everyone else gets PRs)




IJ AsciiDoctor plugin:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/28069f01/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-02-17 um 16.21.18.png
Type: image/png
Size: 7543 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/28069f01/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-02-17 um 16.21.32.png
Type: image/png
Size: 27100 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/28069f01/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-02-17 um 16.21.49.png
Type: image/png
Size: 49605 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/28069f01/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-02-17 um 16.04.31.png
Type: image/png
Size: 145466 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150217/28069f01/attachment-0007.png 

From cpitman at redhat.com  Tue Feb 17 10:53:23 2015
From: cpitman at redhat.com (Chris Pitman)
Date: Tue, 17 Feb 2015 10:53:23 -0500 (EST)
Subject: [Hawkular-dev] About configuration
In-Reply-To: <5FBE74EE-FF63-49E0-87B2-9EE2447F1EB8@redhat.com>
References: <1579541188.12364811.1423855143740.JavaMail.zimbra@redhat.com>
	<5FBE74EE-FF63-49E0-87B2-9EE2447F1EB8@redhat.com>
Message-ID: <1165275501.14398395.1424188403866.JavaMail.zimbra@redhat.com>

Honestly, once I am using a configuration management system (like Puppet) it doesn't really matter that it is another file, especially once someone has released a puppet module to do all the lifting. I recently deployed (on a side project)?collectd, graphite, grafana, and the ELK stack without touching any of their config files directly and specifying only a minimal set of values that differed from convention. 
? 
If the goal is to work well with tooling used by sys admins, like Puppet/Chef/etc, then we really should develop and release our own modules for whatever we want to support. If configuration is file based, this will take the developer maybe a couple hours for each supported toolset. 
? 
If the configuration is inside EAP, then it is still possible, just difficult. Don't expect the community to do it on their own. It requires integrating non-java languages with the management interfaces. You can see an example of what is required for doing this with Puppet in the module I linked before (and it can be used for configuring hawkular if its config is in container). Similar work would need to be done for whatever other config management chosen. Expect to spend several weeks for each variant going this way. 

----- Original Message -----

> > Am 13.02.2015 um 20:19 schrieb Chris Pitman <cpitman at redhat.com>:
> > standalone.xml is a file, but you can only edit it by shutting down the
> > container
> > first (and scripting doing this in Puppet is also non-fun).

> So with umpteen components, we deliver umpteen config files, that
> all need to be tweaked on top of standalone.xml to get something working?
> That does not sound right either.

> _______________________________________________
> 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/20150217/a94b1bfd/attachment.html 

From mazz at redhat.com  Tue Feb 17 13:45:38 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 17 Feb 2015 13:45:38 -0500 (EST)
Subject: [Hawkular-dev] integration assembly distro is ready
In-Reply-To: <1243872280.13724397.1424198430526.JavaMail.zimbra@redhat.com>
Message-ID: <475397288.13731903.1424198738534.JavaMail.zimbra@redhat.com>

OK, all the components for our test distro are on the nexus snapshot repo and we can build a test distribution by simply cloning the "mazz/integration-assembly" branch in the hawkular repo - found here:

https://github.com/hawkular/hawkular/tree/mazz/integration-assembly

"mvn clean install" will build the distro zip (if you build with -Pdev, it will unzip for you in the target/ dir).

Simply run wildfly*/bin/standalone.sh and you'll run the server with everything in it.

Does it do anything? I'll leave that up to the folks that wrote the individual components (alerts, metrics, inventory, etc) to tell us :)

But it does run and everything deploys.

Note: because they are snapshots, you don't have to build any of the components yourself. If anyone commits fixes to those components, github/travis will deploy those new snapshot builds to nexus and you can just rebuild your distro locally to pick up the change. So you really only need https://github.com/hawkular/hawkular/tree/mazz/integration-assembly git cloned locally.

Note that the assembly distro itself is NOT uploaded to nexus - so there is no download of the zip yet. If we want to consider doing this, it should be easy.

From tsegismo at redhat.com  Wed Feb 18 04:57:01 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 18 Feb 2015 10:57:01 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<54E1C085.2070702@redhat.com>
	<6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>
Message-ID: <54E461ED.8000700@redhat.com>

Le 17/02/2015 14:59, Randall Hauch a ?crit :
>>> How will the work be split up across the cluster? Are the incoming
>>> >>messages stored before they?re processed?
>>> >>
>> >
>> >An Hawkular metrics server is web server (Wildfly) in front of a Cassandra cluster.
>> >
>> >So you'd distribute the work with a load balancer.
>> >
>> >I'm not sure I understand your second question.
>> >
> My question is simply this: is the raw incoming data persisted before any other computations or analyses are done? The answer dictates whether Hawkular has the potential to lose data in a crash. The only reason I bring this up is that monitoring (like data storage) is one of those use cases where you can?t really afford to drop or lose any data, since for monitoring that lost data might be the critical evidence you need to understand why something bad happened to your monitored system.
>
> Let?s say that a collector sends some data that will ultimately be processed by Hawkular, including updating various windows (e.g., minutely, hourly, daily, etc.), before persisting. If Hawkular crashes before that data is completely processed, then that data will be lost forever. If Hawkular performs some of the work (e.g., just updating the minutely window) before crashing, then the data appears in only some of the generated/derived information. BTW, in this traditional approach, using a transaction will simply ensure that all of your derived/generated data is consistent; it doesn?t ensure that your data is processed.
>
> If, however, Hawkular were to persist the collected data*before*  processing anything, then as long as the incoming data were persisted then if Hawkular crashed and was restarted it might be able to just continue where it left off, without losing any data or computations. There are lots of ways of ensuring this, but it?s not likely they will all perform well.
>
> The stream-oriented architectures make it possible to not lose any data, because every computation or bit of processing is done in services/jobs that read from and write to (usually persistent) streams. The architecture can ensure at-least-once (and sometimes an exactly-once) semantics for every bit of data passing thru each stream. Of course, this is done without transactions and often with partitioned streams to allow things to scale quite well and handle very large volumes of data.
>
>

Yes, Hawkular metrics persists data first. Computations happen later.

From jsanda at redhat.com  Wed Feb 18 07:43:52 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 18 Feb 2015 07:43:52 -0500
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <54E461ED.8000700@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<54E1C085.2070702@redhat.com>
	<6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>
	<54E461ED.8000700@redhat.com>
Message-ID: <7B2E3A09-D654-48C6-8620-9B4BA317C914@redhat.com>


> On Feb 18, 2015, at 4:57 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Le 17/02/2015 14:59, Randall Hauch a ?crit :
>>>> How will the work be split up across the cluster? Are the incoming
>>>>>> messages stored before they?re processed?
>>>>>> 
>>>> 
>>>> An Hawkular metrics server is web server (Wildfly) in front of a Cassandra cluster.
>>>> 
>>>> So you'd distribute the work with a load balancer.
>>>> 
>>>> I'm not sure I understand your second question.
>>>> 
>> My question is simply this: is the raw incoming data persisted before any other computations or analyses are done? The answer dictates whether Hawkular has the potential to lose data in a crash. The only reason I bring this up is that monitoring (like data storage) is one of those use cases where you can?t really afford to drop or lose any data, since for monitoring that lost data might be the critical evidence you need to understand why something bad happened to your monitored system.
>> 
>> Let?s say that a collector sends some data that will ultimately be processed by Hawkular, including updating various windows (e.g., minutely, hourly, daily, etc.), before persisting. If Hawkular crashes before that data is completely processed, then that data will be lost forever. If Hawkular performs some of the work (e.g., just updating the minutely window) before crashing, then the data appears in only some of the generated/derived information. BTW, in this traditional approach, using a transaction will simply ensure that all of your derived/generated data is consistent; it doesn?t ensure that your data is processed.
>> 
>> If, however, Hawkular were to persist the collected data*before*  processing anything, then as long as the incoming data were persisted then if Hawkular crashed and was restarted it might be able to just continue where it left off, without losing any data or computations. There are lots of ways of ensuring this, but it?s not likely they will all perform well.
>> 
>> The stream-oriented architectures make it possible to not lose any data, because every computation or bit of processing is done in services/jobs that read from and write to (usually persistent) streams. The architecture can ensure at-least-once (and sometimes an exactly-once) semantics for every bit of data passing thru each stream. Of course, this is done without transactions and often with partitioned streams to allow things to scale quite well and handle very large volumes of data.
>> 
>> 
> 
> Yes, Hawkular metrics persists data first. Computations happen later.

I think that Spark's streaming API, particularly the window operations, could be an effective way to do computations in real time as data as ingested. The problem though with introducing something like Spark or Storm is that it increases the operational complexity of hawkular itself which I think we want to avoid if possible.

From ike.braun at googlemail.com  Wed Feb 18 07:50:44 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Wed, 18 Feb 2015 13:50:44 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <7B2E3A09-D654-48C6-8620-9B4BA317C914@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<54E1C085.2070702@redhat.com>
	<6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>
	<54E461ED.8000700@redhat.com>
	<7B2E3A09-D654-48C6-8620-9B4BA317C914@redhat.com>
Message-ID: <5864DCBD-3BB4-40BD-AC58-82BE34334F6E@googlemail.com>


> On 18 Feb 2015, at 13:43, John Sanda <jsanda at redhat.com> wrote:
> 
> I think that Spark's streaming API, particularly the window operations, could be an effective way to do computations in real time as data as ingested

+1

not only for processing the streams, but also for any kind of post processing needed. plus it would supply the abstractions to run computations across large number of nodes.


/heikoB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150218/c8096778/attachment.html 

From jpkroehling at redhat.com  Wed Feb 18 08:17:51 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 18 Feb 2015 14:17:51 +0100
Subject: [Hawkular-dev] Water cooler tomorrow - Hawkular Accounts
Message-ID: <54E490FF.1080106@redhat.com>

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

Team,

As mentioned in another thread, I've started a draft for another
Hawkular component that would take care of the permission checking,
based on the idea that we would not have tenants, but users and
organizations.

This is still an early draft (as most components, I assume), but I'd
like to get some feedback about it.

The backend code is here:
https://github.com/hawkular/hawkular-accounts

I started a draft for the UI as well, but it's not very interesting at
this point (I used it mostly to test the authentication):
https://github.com/jpkrohling/hawkular-ui-components/tree/JPK-AccountsUI

On the backend, there's a "sample" module, which shows how an external
component (ie: yours) can make use of the permission checker and of
the organization/user services.

I would like to have a water cooler discussion about it sometime this
week, hopefully tomorrow or Friday.

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

iQEcBAEBAgAGBQJU5JD/AAoJECKM1e+fkPrXCoAH/jYpyvR4ELGQeauR8zhdQ6PE
K3mdIYlOOn0LRVA288+XM5zETqTkc47KXf9MmRPkwXI4g/7GuDm/GY9+mu3HrpK2
DkyQo0urVKlpCAii4tYrTwMcsSyfMDSE0vFhtIRxC7mTpgd7gKOA59BRR64KSGfp
HZHpUxMpwHOBXneHoOmG5h8SY5Y0KUHFW4h13mrGaTk8Sf92M8Ng+LmLd1EB5hwy
GEegstGLtpPMQ6aLcHChiOzVB5unxKpPRB2IkZ7xOvHFxxc5zdUiUu+6809Ln9le
ntisWvlLgswjhWW16gxZktmU0hwxgrrvlT39qLpvIk6ONQyhrWeAVgVtQ/RaDJk=
=8UO+
-----END PGP SIGNATURE-----

From miburman at redhat.com  Wed Feb 18 09:05:54 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 18 Feb 2015 16:05:54 +0200
Subject: [Hawkular-dev] [metrics] Small agent to push metrics
Message-ID: <54E49C42.7090202@redhat.com>

Hi,

There was discussion on #hawkular at some point about providing real 
world metrics to get some understanding on how the system works in 
reality. Following the python-client, here's a small agent that will 
supply metric-information of cpu & memory to the Hawkular-metrics instance:

https://github.com/burmanm/gather_agent

The only external requirement is installing rhq-metrics-python-client 
(with the setup.py) and it should work fine (version 0.2.2 required, 
which is the current one). If you want to see those metrics in the 
hawkular-metrics-ui, remember to use correct tenant (test).

    - Micke

From rhauch at redhat.com  Wed Feb 18 10:17:11 2015
From: rhauch at redhat.com (Randall Hauch)
Date: Wed, 18 Feb 2015 09:17:11 -0600
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <5864DCBD-3BB4-40BD-AC58-82BE34334F6E@googlemail.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>
	<54DE2B20.7040801@redhat.com>
	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>
	<54E1C085.2070702@redhat.com>
	<6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>
	<54E461ED.8000700@redhat.com>
	<7B2E3A09-D654-48C6-8620-9B4BA317C914@redhat.com>
	<5864DCBD-3BB4-40BD-AC58-82BE34334F6E@googlemail.com>
Message-ID: <B3E0D082-5F7F-498D-A4AF-CA5399E5A987@redhat.com>


> On Feb 18, 2015, at 6:50 AM, Heiko Braun <ike.braun at googlemail.com> wrote:
> 
> 
>> On 18 Feb 2015, at 13:43, John Sanda <jsanda at redhat.com <mailto:jsanda at redhat.com>> wrote:
>> 
>> I think that Spark's streaming API, particularly the window operations, could be an effective way to do computations in real time as data as ingested
> 
> +1
> 
> not only for processing the streams, but also for any kind of post processing needed. plus it would supply the abstractions to run computations across large number of nodes.
> 

Exactly. Use Spark Streaming or even Storm would increase the installation and operational complexity but it would give you a lot of really easy management of your workflow. Each of the stream processors consume a stream and do one thing (e.g., aggregate the last 60 seconds of raw data, or aggregate the last 60 minutes of either the raw data or the 60-second windows, etc.). The different outputs can still get written to whatever storage you want; stream-oriented processing just changes *how* you process the incoming data.

An alternative approach is to use Apache Kafka directly. There are pros and cons, but the benefit is that the services that do the computations would be microservices (no, really - just really small, single-threaded processes that do a single thing) that could be easily deployed across the cluster. If anyone is interested this approach, ping me and I?ll point you to a prototype that does this (not for analytics).

BTW, a stream-processing approach does not limit you to live data. In fact, quite the opposite. Many people use stream processing for ingesting large volumes of live data, but lots of other people use it in ?big data? as an alternative to batch processing (often map-reduce).

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

From mithomps at redhat.com  Wed Feb 18 12:21:10 2015
From: mithomps at redhat.com (mike thompson)
Date: Wed, 18 Feb 2015 09:21:10 -0800
Subject: [Hawkular-dev] Top 10 most common Java performance problems from
	AppDynamics
Message-ID: <62FCF415-9400-483A-B3CF-CA3140059227@redhat.com>

A non-text attachment was scrubbed...
Name: Top-10-Java-Performance-Problems.pdf
Type: application/pdf
Size: 633005 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150218/1537207c/attachment-0001.pdf 
-------------- next part --------------


This paper should help us in identifying the hot spots that our users will be interested in, and areas Hawkular should provide insight into. Some are obvious, some not so much.


? Mike

From ppalaga at redhat.com  Wed Feb 18 16:59:55 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 18 Feb 2015 22:59:55 +0100
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <CA4C86A0-A245-458B-AA50-1B9287A94AD5@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
	<CA4C86A0-A245-458B-AA50-1B9287A94AD5@redhat.com>
Message-ID: <54E50B5B.7030304@redhat.com>

+1 for writing in asciidoc. Looks like Github is still on AsciidDoctor 
0.1.4 :(

Fabric8 uses GitBook to make a book out of md 
https://github.com/fabric8io/fabric8/blob/master/building.md#gitbook The 
result looks pretty nice http://fabric8.io/v2/getStartedOpenShift.html 
and GitBook page says it works also with adoc.

-- P

On 02/17/2015 04:51 PM, Heiko W.Rupp wrote:
> As promised to some here is a list of AsciiDoc(tor) resources
>
> * Website that has a edit half and a live-preview
> https://asciidoclive.com (found by Lucas P)
> * IntelliJ has an AsciiDoctor plugin that allows to basically do the
> same (see below)
> * AD syntax
> http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#source-code
> * AsciiDoctor home page http://asciidoctor.org
> * AsciiDoc writers guide http://asciidoctor.org/docs/asciidoc-writers-guide/
> * Editing AsciiDoc with Live Preview
> http://asciidoctor.org/docs/editing-asciidoc-with-live-preview/
> * (Start of a) Eclipse Asciidoctor plugin
> http://marketplace.eclipse.org/node/2162366
> * Netbeans plugin
> https://blogs.oracle.com/geertjan/entry/asciidoctor_netbeans
>
>
> As Mike mentioned, you can go to GitHub, click on a .adoc page and then
> use the pencil icon
>
>
> Directly edit + preview
>
>
> And then commit / open a PR ( I think commit is only enabled for repo
> collaborators, everyone else gets PRs)
>
>
>
> IJ AsciiDoctor plugin:
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From theute at redhat.com  Thu Feb 19 03:51:46 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 19 Feb 2015 09:51:46 +0100
Subject: [Hawkular-dev] Low-impact clients and never dropping any events
In-Reply-To: <B3E0D082-5F7F-498D-A4AF-CA5399E5A987@redhat.com>
References: <46B40D82-91A0-4783-A002-7683C98BD19C@redhat.com>	<54DE2B20.7040801@redhat.com>	<2824744A-1B71-4BB3-A2DE-164C75F012F6@redhat.com>	<54E1C085.2070702@redhat.com>	<6BD2D8F7-BB48-4F1F-82F9-F26461D6008C@redhat.com>	<54E461ED.8000700@redhat.com>	<7B2E3A09-D654-48C6-8620-9B4BA317C914@redhat.com>	<5864DCBD-3BB4-40BD-AC58-82BE34334F6E@googlemail.com>
	<B3E0D082-5F7F-498D-A4AF-CA5399E5A987@redhat.com>
Message-ID: <54E5A422.9020301@redhat.com>


On 02/18/2015 04:17 PM, Randall Hauch wrote:
>
>> On Feb 18, 2015, at 6:50 AM, Heiko Braun <ike.braun at googlemail.com 
>> <mailto:ike.braun at googlemail.com>> wrote:
>>
>>
>>> On 18 Feb 2015, at 13:43, John Sanda <jsanda at redhat.com 
>>> <mailto:jsanda at redhat.com>> wrote:
>>>
>>> I think that Spark's streaming API, particularly the window 
>>> operations, could be an effective way to do computations in real 
>>> time as data as ingested
>>
>> +1
>>
>> not only for processing the streams, but also for any kind of post 
>> processing needed. plus it would supply the abstractions to run 
>> computations across large number of nodes.
>>
>
> Exactly. Use Spark Streaming or even Storm would increase the 
> installation and operational complexity
We have a good experience of users being turned down by installation and 
operational complexity, so no matter the "but" part (even though that 
sounds interesting), we would need to find a proper solution to remove 
it / reduce it.

It needs to be easy to install in small environments and able to scale 
when needed/wanted. Scaling by adding homogeneous nodes would help.

I have no experience with Spark/Storm, what is the burden on 
installation and operational complexity ?

Thomas



> but it would give you a lot of really easy management of your 
> workflow. Each of the stream processors consume a stream and do one 
> thing (e.g., aggregate the last 60 seconds of raw data, or aggregate 
> the last 60 minutes of either the raw data or the 60-second windows, 
> etc.). The different outputs can still get written to whatever storage 
> you want; stream-oriented processing just changes *how* you process 
> the incoming data.
>
> An alternative approach is to use Apache Kafka directly. There are 
> pros and cons, but the benefit is that the services that do the 
> computations would be microservices (no, really - just really small, 
> single-threaded processes that do a single thing) that could be easily 
> deployed across the cluster. If anyone is interested this approach, 
> ping me and I?ll point you to a prototype that does this (not for 
> analytics).
>
> BTW, a stream-processing approach does not limit you to live data. In 
> fact, quite the opposite. Many people use stream processing for 
> ingesting large volumes of live data, but lots of other people use it 
> in ?big data? as an alternative to batch processing (often map-reduce).
>
>
>
> _______________________________________________
> 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/20150219/6e871e48/attachment.html 

From hrupp at redhat.com  Thu Feb 19 04:51:05 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 19 Feb 2015 10:51:05 +0100
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
Message-ID: <3F689D66-6FA5-4346-ACAA-526ADA787AD5@redhat.com>

Hey,

please add yourself to the Doodle at http://doodle.com/a8ctk6wgwi3nh9f8 
I will close that tomorrow SOB

 Heiko


> Am 17.02.2015 um 15:15 schrieb Heiko W.Rupp <hrupp at redhat.com>:
> 
> Hey,
> 
> as we made some progress with hawkular.github.io, the question came up what should go there and if we can't just use something else instead.
> 
> I am very much in favor of using AsciiDoc + git for the documentation -- user and developer
> 
> Clear advantages that I see for this solution:
> 
> - versioning is easy as it is built into git. We can easily create branches for various versions of the Hawkular
> without the complicated clone process that we had in the past
> - offline possibility an author does not need to be online to write docs
> - AsciiDoc is plain text. The pages may have a handful of specific header lines, but if you don't want to format any markup, then just don't
> - Contributing is easy. People just git clone the repo, make their changes and submit a pull-request
> - docs are directly rendered on GitHub
> - AsciiDoc is already used in our README.adoc files
> - With AsciiDoctor there is a good tool chain for creating good print, html, pdf, docbook output
> - it is possible to write docs in vi/emacs/Notepad
> 
> Tooling may not yet be that perfect; the mvn jbake:inline mode is already quite well able to re-create 
> the website locally though; with a browser extension like "live-reload", editing a text is as wysiwyg as on a wiki
> 
> 
> There are other JBoss projects that follow the AsciiDoc+git approach with great success
> like http://arquillian.org, http://hibernate.org, http://liveoak.io, http://torquebox.org(*)
> 
> Anyway I've started a doodle to get feedback and then proceed further - so please visit
> http://doodle.com/a8ctk6wgwi3nh9f8
> so that we can come to a documentation solution that we all use.
> 
>  Heiko
> 
> *) Actually uses Markdown as markup language
> 
> 
> 
> _______________________________________________
> 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 theute at redhat.com  Thu Feb 19 09:20:16 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 19 Feb 2015 15:20:16 +0100
Subject: [Hawkular-dev] Response time ?
Message-ID: <54E5F120.5070805@redhat.com>


What is a useful representation of a response time over a period of time ?

     - Average of all the samples ? *2.22s*
     - 90/95/99 percentile ? 99% of your requests took less than *2.45s*
     - Percentage of valid samples ? *94%* of your requests took less 
than your 3s acceptable time.
     - Apdex ? http://en.wikipedia.org/wiki/Apdex

Anything else ? (This is for a quick overview of the health of a system).

Thomas


From jsanda at redhat.com  Thu Feb 19 09:52:46 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 19 Feb 2015 09:52:46 -0500
Subject: [Hawkular-dev] Response time ?
In-Reply-To: <54E5F120.5070805@redhat.com>
References: <54E5F120.5070805@redhat.com>
Message-ID: <A5988FC7-72A2-4570-98EB-CDE62BDBA3AB@redhat.com>

I like percentiles. Here is a good article that explains why percentiles are effective and why they should be used for baselining.

http://apmblog.dynatrace.com/2012/11/14/why-averages-suck-and-percentiles-are-great/ <http://apmblog.dynatrace.com/2012/11/14/why-averages-suck-and-percentiles-are-great/>

> On Feb 19, 2015, at 9:20 AM, Thomas Heute <theute at redhat.com> wrote:
> 
> 
> What is a useful representation of a response time over a period of time ?
> 
>     - Average of all the samples ? *2.22s*
>     - 90/95/99 percentile ? 99% of your requests took less than *2.45s*
>     - Percentage of valid samples ? *94%* of your requests took less 
> than your 3s acceptable time.
>     - Apdex ? http://en.wikipedia.org/wiki/Apdex
> 
> Anything else ? (This is for a quick overview of the health of a system).
> 
> Thomas
> 
> _______________________________________________
> 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/20150219/e80418c4/attachment.html 

From crobson at redhat.com  Thu Feb 19 15:50:34 2015
From: crobson at redhat.com (Catherine Robson)
Date: Thu, 19 Feb 2015 15:50:34 -0500
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <3F689D66-6FA5-4346-ACAA-526ADA787AD5@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
	<3F689D66-6FA5-4346-ACAA-526ADA787AD5@redhat.com>
Message-ID: <54E64C9A.5070104@redhat.com>

Would we be able to take documentation written in Git with Asciidoc and 
dynamically place that into other UI outputs?  Two reasons of why this 
might be useful:

- Bring documentation into the Hawkular community website to describe 
certain capabilties
- Bring documentation into the web console as context sensitive help 
pop-ups/sidebars

My current understanding of Asciidoc tells me this would be possible - 
but wanted to ask!

- Catherine


> Heiko W.Rupp <mailto:hrupp at redhat.com>
> February 19, 2015 at 4:51 AM
> Hey,
>
> please add yourself to the Doodle at http://doodle.com/a8ctk6wgwi3nh9f8
> I will close that tomorrow SOB
>
> Heiko
>
>
>
> Heiko W.Rupp <mailto:hrupp at redhat.com>
> February 17, 2015 at 9:15 AM
> Hey,
>
> as we made some progress with hawkular.github.io, the question came up 
> what should go there and if we can't just use something else instead.
>
> I am very much in favor of using AsciiDoc + git for the documentation 
> -- user and developer
>
> Clear advantages that I see for this solution:
>
> - versioning is easy as it is built into git. We can easily create 
> branches for various versions of the Hawkular
> without the complicated clone process that we had in the past
> - offline possibility an author does not need to be online to write docs
> - AsciiDoc is plain text. The pages may have a handful of specific 
> header lines, but if you don't want to format any markup, then just don't
> - Contributing is easy. People just git clone the repo, make their 
> changes and submit a pull-request
> - docs are directly rendered on GitHub
> - AsciiDoc is already used in our README.adoc files
> - With AsciiDoctor there is a good tool chain for creating good print, 
> html, pdf, docbook output
> - it is possible to write docs in vi/emacs/Notepad
>
> Tooling may not yet be that perfect; the mvn jbake:inline mode is 
> already quite well able to re-create
> the website locally though; with a browser extension like 
> "live-reload", editing a text is as wysiwyg as on a wiki
>
>
> There are other JBoss projects that follow the AsciiDoc+git approach 
> with great success
> like http://arquillian.org, http://hibernate.org, http://liveoak.io, 
> http://torquebox.org(*)
>
> Anyway I've started a doodle to get feedback and then proceed further 
> - so please visit
> http://doodle.com/a8ctk6wgwi3nh9f8
> so that we can come to a documentation solution that we all use.
>
> Heiko
>
> *) Actually uses Markdown as markup language
>
>
>
> _______________________________________________
> 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/20150219/c78e3613/attachment-0001.html 
-------------- 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/20150219/c78e3613/attachment-0001.jpg 

From jshaughn at redhat.com  Thu Feb 19 15:54:00 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 19 Feb 2015 15:54:00 -0500
Subject: [Hawkular-dev] Availability (Service and UI)
In-Reply-To: <04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
References: <54DDE780.1050207@redhat.com>
	<54DE783D.4030002@redhat.com>	<54E1BD18.5010905@redhat.com>
	<54E20AEE.9000608@redhat.com>	<1532486063.12941369.1424119725407.JavaMail.zimbra@redhat.com>	<F057F4A0-E717-44BD-963C-C3FDC99E7D32@redhat.com>	<54E30824.3000409@redhat.com>
	<04806D41-CB9C-48D4-9245-FB4D28F69346@redhat.com>
Message-ID: <54E64D68.4070608@redhat.com>

There was a long IRC chat on this topic yesterday, for thread 
completeness I'm adding it here...

(11:53:43 AM) jshaughn: general question, for feeds sending various 
types of MetricData, let's say NumericData and Availability (the only 
two I know exist currently), can the data be mixed in a single push, or 
can we assume that it will arrive as two different requests, one for 
each type?
(11:54:15 AM) jshaughn: stefan_n, jsanda maybe you have an idea on that 
already?
(11:55:22 AM) jsanda: jshaughn: it's separate
(11:55:47 AM) jsanda: jshaughn: but we can certainly change that if it 
makes sense to do so
(11:56:56 AM) jshaughn: jsanda: no, I think it may be better to have it 
separate
(11:57:49 AM) jshaughn: it will be easier to parse out the json 
consistently if it's separate. also, it may require different 
processing. Given what we have been discussing in that avail thread
(11:58:37 AM) jshaughn: perhaps H metrics should (optionally) provide 
caching of avail data, such that it gets stored changes-only.
(11:58:58 AM) jshaughn: not sure if that should be at the metrics level 
or higher up
(11:59:48 AM) jshaughn: but if metrics is going to natively handle avail 
data, then perhaps that should be a metrics feature. But I'm not sure 
about the whole ability of a cluster-wide cache.
(12:00:01 PM) jshaughn: the other option is the idea of aggregates
(12:00:14 PM) jsanda: i would consider it more an implementation detail 
than a feature
(12:00:39 PM) jshaughn: I'm not sure, because users may or may not want 
changes-only storage
(12:01:02 PM) jsanda: your mention of a cluster-wide cache is timely 
considering i brought up spark earlier today on the mailing list
(12:01:08 PM) jshaughn: then again, we don't have to be that flexible, 
we could decide changes-only is the way it will be
(12:01:15 PM) jsanda: users could get changes only either way
(12:01:44 PM) jshaughn: right, the question is whether it's worthwhile 
to perform the storage of all the data points
(12:02:28 PM) jshaughn: when 99% of the avail data is UP, it seems kind 
of useless to store every DP
(12:02:44 PM) jsanda: data would be compressed on disk, which i think 
would make a substantial difference in terms of disk foot print
(12:02:56 PM) jsanda: i haven't thought enough about it either way
(12:03:02 PM) jshaughn: it's true what Micke said, about being able to 
prove the Up-ness was actually measured, but I'm not convinced it's 
necessary
(12:04:00 PM) jshaughn: jsanda: not sure it matters footprint wise, but 
it is potentially more processing, more fetch time, aggregation time, etc
(12:04:09 PM) jshaughn: time that could be spent doing other things
(12:04:48 PM) jsanda: only storing changes introduces its own complexity
(12:04:53 PM) jshaughn: fetch and store would be the other option
(12:05:05 PM) jsanda: i don'nt think so
(12:05:47 PM) jsanda: maybe if we are storing avail in postgres, but 
definitely not if it is being stored in C*
(12:06:08 PM) jshaughn: I didn't think so, either, I thought I actually 
saw you propose that in the thread
(12:06:46 PM) jsanda: it's also possible to do a combination
(12:06:52 PM) tsegismont: how do we model absence of value when storing 
changes only?
(12:06:56 PM) jsanda: we store the changes
(12:07:08 PM) jsanda: in addition to all the raw values
(12:07:19 PM) jsanda: which we could roll up
(12:07:54 PM) jsanda: and purge the raw as aggressively as we want
(12:08:42 PM) jshaughn: tsegismont: we don't really, I think. Unless we 
want to keep a counter of how many repeats we got in an interval (you 
lose the timestamps but could likely assume that in most cases they came 
in at regular intervals)
(12:09:03 PM) jsanda: tsegismont: one way might be for a job to run on 
the server side and performs the check for a value being reported within 
some window
(12:09:26 PM) tsegismont: jsanda which means giving intelligence to metrics
(12:09:38 PM) jshaughn: what exactly is the need?
(12:09:39 PM) jsanda: yes
(12:09:40 PM) tsegismont: which shouldn't take care of that, IMHO
(12:10:00 PM) jsanda: what do you mean by intelligence?
(12:10:15 PM) tsegismont: " a job to run on the server side and performs 
the check for a value being reported within some window"
(12:10:19 PM) jsanda: we already have use cases for different jobs that 
will have to run
(12:10:27 PM) jshaughn: aggregation could potentially keep the count of 
the raw metrics collected during an interval of unchanged avail
(12:10:53 PM) tsegismont: metrics itself does know how often a 
metric/avail should be reported
(12:11:06 PM) tsegismont: it takes timestamped-reports, that's it
(12:11:17 PM) jsanda: why can't it know?
(12:12:02 PM) jsanda: just like metrics needs to when data retention 
settings or when various rollups need to be computed
(12:12:29 PM) tsegismont: jsanda, is it stored in metadata?
(12:13:34 PM) jsanda: it isn't stored anywhere because we currently 
aren't doing anything with availability
(12:13:39 PM) jsanda: but it could be stored
(12:14:04 PM) tsegismont: Let's say you have an avail report looking like
(12:14:16 PM) tsegismont: 5:43:12 UP
(12:14:31 PM) tsegismont: 5:43:32 UP
(12:14:39 PM) tsegismont: 5:43:35 DOWN
(12:15:43 PM) tsegismont: Then you're able to say: it went DOWN at 
5:43:35, and last up report was 3 seconds before
(12:15:50 PM) tsegismont: now if you store only differences
(12:16:17 PM) tsegismont: and have a report like:
(12:16:32 PM) tsegismont: 3:43:12 UP
(12:16:33 PM) tsegismont: 5:43:35 DOWN
(12:17:01 PM) tsegismont: You can only say: it went DOWN at 5:43:35, and 
was up since 3:43:12
(12:17:51 PM) tsegismont: To make a long story short: if you store 
things like this, you lose information
(12:18:01 PM) tsegismont: but maybe it's not the intention?
(12:18:29 PM) jsanda: your example makes sense
(12:18:53 PM) jsanda: and i agree that there may be value in storing all 
values
(12:19:19 PM) jsanda: i haven't formed an opinion one way or the other 
though
(12:19:26 PM) jsanda: need to think about it more
(12:19:42 PM) jsanda: obviously pros/cons with each
(12:22:28 PM) jshaughn: if you stored 3:43:12 UP (N), 43:35 DOWN (2) 
You'd know that you had 1 UP in between. If there was some sort of 
aggregation of the raw data this may be feasible. You wouldn't know the 
exact times, but could likely assume the reports came in at regular 
intervals
(12:23:17 PM) mazz: what's the (N) and (2) mean?
(12:23:32 PM) mtho11: if for this first MVP we just store the changes I 
think it will make our lives easier to focus on other higher value 
things (not to mention we could change this in phase 2)
(12:24:02 PM) mtho11: we wouldnt even have do any aggregations on that 
data most likely
(12:24:13 PM) jshaughn: mazz, that would be the count of raw avails 
contributing the the rollup
(12:24:35 PM) jshaughn: probably a dumb idea, but an idea nonetheless
(12:25:01 PM) jsanda: i don't think storing only changes is necessarily 
easier
(12:25:08 PM) tsegismont: jsanda, +1
(12:25:10 PM) jsanda: in fact, i think it is harder
(12:25:12 PM) jsanda: a lot
(12:25:14 PM) jshaughn: so if you have 10000 UPs in a rown before it 
go's DOWN you'd have DOWN time (10000)
(12:25:35 PM) jsanda: because we need to introduces a caching/clustering 
layer, i.e., spark
(12:25:42 PM) jshaughn: storing changes-only is certainly harder.
(12:25:44 PM) jshaughn: As it stands right now I think we have to just 
go with storing all values, leaving it up to the consuming apps to do 
anything other than pass it through in raw form.
(12:26:08 PM) jsanda: and i also think it is fair to say it is an 
implementation detail
(12:26:21 PM) tsegismont: <jsanda> in fact, i think it is harder +1
(12:26:26 PM) mazz: right, the reason why today RHQ does it like it does 
it (changes only) is because we would have clobbered the DB with all 
those avail rows
(12:26:38 PM) mazz: with all basically the same UP value :)
(12:27:20 PM) mazz: but if C* has better performance for that type of 
data, then we don't need to worry about it
(12:28:13 PM) jshaughn: I still don't see it as an implementation detail
(12:28:45 PM) jsanda: i think the issue won't be so much about write 
performance as much about the disk foot print and the cpu needed to 
aggregate and purge the raw values
(12:28:50 PM) jshaughn: because queries will return different data given 
the different approaches.
(12:29:02 PM) mtho11: all long as you can provide the UI with just the 
changes that is all I care about :)
(12:29:10 PM) jsanda: with that said, there is additional overhead as 
well for implementing a solution to only store changes
(12:29:21 PM) jshaughn: mtho11: right, that is why it's not an impl 
detail, I think
(12:29:37 PM) mtho11: great
(12:29:51 PM) jsanda: jshaughn: why would the queries return different data?
(12:30:11 PM) jsanda: if we have all the values, we can return only the 
changes
(12:30:14 PM) jsanda: right?
(12:30:18 PM) jshaughn: if it's changes only raw data would return 
repeats (and likely a lot of them), if not, it wouldn't.
(12:30:39 PM) mazz: so don't return all the raw data
(12:30:43 PM) jsanda: right
(12:30:49 PM) jsanda: we filter the repeats out
(12:30:51 PM) jshaughn: then why store it?
(12:31:02 PM) jsanda: do the aggregation at query time
(12:31:02 PM) mazz: the storage is an impl detail because under the 
covers, we just filter out what the API returns
(12:31:08 PM) jsanda: yep
(12:31:10 PM) jsanda: easy peasy
(12:31:13 PM) mazz: why store it?
(12:31:19 PM) mazz: perhaps because it is faster?
(12:31:22 PM) mazz: I don't know
(12:31:25 PM) mazz: that would be a reason though
(12:31:33 PM) jshaughn: the argument above was that the details, the 
repeated values, were valuable
(12:31:34 PM) jsanda: because it is easier than only storing changes
(12:31:42 PM) mazz: if its faster to just take the data and store it 
rather than do some pre-filtering to see if we need to insert it or not
(12:31:51 PM) jsanda: and the example that tsegismont provided is a good one
(12:31:58 PM) jshaughn: I think Metrcs would need to have services to 
return raw and aggregated
(12:33:05 PM) jsanda: we have a stream of values like
(12:33:14 PM) jshaughn: tsegismont: and gaYak were saying the same 
thing. The question is whether it's worth the extra storage work. But 
it's moot if we don't have a good idea of how to distill raw avail to 
avail ranges
(12:33:30 PM) jshaughn: on the way in
(12:33:50 PM) jsanda: that extra storage work could be less work than 
only storing the changes
(12:33:59 PM) jshaughn: personally, I'm OK with storing it all, at least 
to start with
(12:34:22 PM) jsanda: maybe it won't be, but i think it will be more 
work, more resources, etc
(12:34:35 PM) jshaughn: well, if we had a global cache it wouldn't be 
hard to filter duplicates
(12:34:51 PM) tsegismont: We don't need to keep that level of details 
for years
(12:35:01 PM) jsanda: right
(12:35:17 PM) jsanda: as i said, i think we could purge the data pretty 
aggressively
(12:35:32 PM) jshaughn: so what is the Spark angle?
(12:36:14 PM) jsanda: distributed processing/caching that is fault 
tolerant and persistent
(12:36:45 PM) jsanda: this is a perfect use case
(12:37:26 PM) jsanda: i'm not sure that the benefits outweigh the added 
complexity though
(12:37:28 PM) mtho11: jsanda: doesnt purging the data aggressively cause 
Garbage Collection issues?
(12:37:54 PM) mtho11: availability could be on a massive scale
(12:38:15 PM) jsanda: not that i'm aware of
(12:39:08 PM) jsanda: we could consider using date tiered compaction 
which can drop an entire sstable at a time
(12:39:24 PM) jsanda: so the purging would be more coarse grained
(12:39:25 PM) mtho11: more records get purged than get saved
(12:39:29 PM) jshaughn: one side-note, I'm hoping that actually a lot of 
avail filtering is done by the feeds. Meaning, I think they should 
report avail only on critical resources, not *all* of them like in RHQ. 
That was pretty useless if you ask me.
(12:39:31 PM) jsanda: right
(12:39:57 PM) jsanda: jshaughn: +1 to more intelligent clients/feeds
(12:40:15 PM) jshaughn: Just servers, apps, stiff like that.
(12:40:29 PM) jshaughn: ok, I need food... good discussion

(2:18:04 PM) pilhuhn: [18:31:43] <mazz> if its faster to just take the 
data and store it rather than do some pre-filtering to see if we need to 
insert it or not
(2:18:17 PM) pilhuhn: What exactly is slow in getting a value of a local 
map?
(2:18:40 PM) pilhuhn: no, no avail in pinger (well, indirectly via 
status code)
(2:18:55 PM) pilhuhn: And we also did not talk about it in the way of MVP
(2:19:36 PM) mazz: (02:18:05 PM) pilhuhn: [18:31:43] <mazz> if its 
faster to just take the data and store it rather than do some 
pre-filtering to see if we need to insert it or not
(2:20:11 PM) mazz: what I meant was - today in RHQ we get raw avail and 
before it is inserted, we grab the latest avail data, and if it's the 
same state, we just update the "end time"
(2:20:20 PM) pilhuhn: yes, but that is broken
(2:20:24 PM) mazz: if the state changed, we know we have to update the 
end time and insert a new ros
(2:20:25 PM) mazz: row
(2:20:34 PM) jshaughn: pilhuhn: I don't think there is anything slow 
about a map access. But are we sure we'd have a usable cluster-wide map? 
And if so, who would own it, Hawkular or Metrics?
(2:20:40 PM) mazz: so that's the "pre-filtering" I was talking about
(2:20:54 PM) pilhuhn: it does not imply though that we just now store 
everything just because we can not come up with a better solution than 
in RHQ
(2:21:21 PM) mazz: I think we are trying to come up with a better 
solution :}
(2:21:36 PM) pilhuhn: But storing everything is not better
(2:22:04 PM) pilhuhn: jshaughn ispn exists ..
(2:22:42 PM) pilhuhn: wrt owner -- Hawkular can own it and can own avail 
(or have a separate component) that "just" uses C* for storage
(2:22:48 PM) jshaughn: My feeling is that we should probably store all 
avail data points for some period of time, and then aggregate to 
intervals. That gives us our usual high granularity for near term and 
lowere granularity for longer term
(2:23:29 PM) pilhuhn: What is the benefit of stroing 60 times "is up" 
for an hour as opposed to "was up that hour" ?
(2:24:32 PM) jshaughn: ask gaYak and tsegismont_afk, they in particular 
are thinking people may want to see the more granular data points.
(2:24:44 PM) pilhuhn: We can simulate them
(2:25:29 PM) pilhuhn: If I know a resources was up last hour, I can 
return 36000000 individual <time, UP> tuples so that they feel cozy
(2:25:37 PM) pilhuhn: Does not even consume storage :->
(2:26:04 PM) pilhuhn: I already see the advertisement "Hawkular has 
millisecond availability precision"
(2:26:06 PM) pilhuhn: :-)
(2:26:17 PM) pilhuhn: Sorry for being sarcastic
(2:26:20 PM) jshaughn: it;s a bit different than the actual proof that 
we confirmed UP or DOWN at certain points, but in general I agree that 
intervals are sufficient
(2:26:22 PM) ***pilhuhn should go back to the IDE
(2:27:18 PM) jshaughn: there is one subtle thing wrt Alerting.
(2:27:20 PM) jsanda: and we can still use/compute/store intervals even 
if we do initially store everything
(2:28:41 PM) jshaughn: it may be better to alert on raw avail than on 
change-only. I'm not sure. But we saw many times that users tried to use 
dampening on changes-only and got very confused.
(2:28:43 PM) mazz: here was tsegismont_afk use-case, which was a good point:
(2:28:43 PM) mazz: (12:14:06 PM) tsegismont: Let's say you have an avail 
report looking like
(2:28:43 PM) mazz: (12:14:17 PM) tsegismont: 5:43:12 UP
(2:28:43 PM) mazz: (12:14:32 PM) tsegismont: 5:43:32 UP
(2:28:43 PM) mazz: (12:14:41 PM) tsegismont: 5:43:35 DOWN
(2:28:43 PM) mazz: (12:15:44 PM) tsegismont: Then you're able to say: it 
went DOWN at 5:43:35, and last up report was 3 seconds before
(2:28:43 PM) mazz: (12:15:52 PM) tsegismont: now if you store only 
differences
(2:28:44 PM) mazz: (12:16:18 PM) tsegismont: and have a report like:
(2:28:44 PM) mazz: (12:16:34 PM) tsegismont: 3:43:12 UP
(2:28:45 PM) mazz: (12:16:34 PM) tsegismont: 5:43:35 DOWN
(2:28:45 PM) mazz: (12:17:03 PM) tsegismont: You can only say: it went 
DOWN at 5:43:35, and was up since 3:43:12
(2:28:46 PM) mazz: (12:17:52 PM) tsegismont: To make a long story short: 
if you store things like this, you lose information
(2:29:57 PM) gaYak: I tried to say the same thing on the ML ;)
(2:30:11 PM) jshaughn: yes, I gave you credit gaYak ;)
(2:30:12 PM) pilhuhn: What about then updating the end time on each UP 
and start a new interval on DOWN?
(2:30:33 PM) pilhuhn: Even with above data, we can no tell what happened 
between ::32 and ::35
(2:30:48 PM) gaYak: No, but the last UP should be stored
(2:30:59 PM) gaYak: As in, "it was shown to be up at time X"
(2:31:24 PM) gaYak: I'm not sure if the middle points are necessary, but 
those around the changes
(2:31:49 PM) pilhuhn: This is what I meant above - you have a triple 
<start, end , UP> where start stays as :12 and end is updated on each 
report , so last at :32>
(2:31:52 PM) jshaughn: what gaYak is saying is that we can prove that it 
was down no more than a certain amount
(2:32:26 PM) pilhuhn: I understand that.
(2:32:47 PM) pilhuhn: But that still does not warrant storing every 
single incoming availabilty point
(2:33:53 PM) gaYak: Yeah, the issue is that you don't actually know if 
it's going to be the last 'up'
(2:34:00 PM) gaYak: So you need to always store the point when it arrives
(2:34:13 PM) jshaughn: If the avail reporting interval is known then the 
interum points can pretty much be assumed.
(2:34:14 PM) gaYak: Sure, you can delete the older, but.. that's even 
worse for I/O
(2:34:40 PM) gaYak: jshaughn: But as our point was to use push towards 
rhq-metrics.. we might not know
(2:35:14 PM) jsanda: how can we guarantee the reporting interval?
(2:36:10 PM) gaYak: I don't think we can. Imagine if there's delayed 
reporting (like a mobile phone which might be out of connection for some 
time)
(2:36:15 PM) jshaughn: but pilhuhn yes, something like UP|startTime|lastTime
(2:37:05 PM) pilhuhn: we can't guarantee the reporting interval - never
(2:37:13 PM) pilhuhn: a) rest-feeds can do what they want
(2:37:25 PM) pilhuhn: b) classical agent can have a hicup that delays it
(2:37:45 PM) jsanda: right, so we can't assume data points at particular 
times
(2:37:48 PM) pilhuhn: no
(2:38:00 PM) jshaughn: if the cache held the last time that may be 
sufficient, only writing the lastTime on a change
(2:38:35 PM) gaYak: We'll lose cache if the thing goes down, so it needs 
to be written to Cass every time.
(2:38:44 PM) gaYak: And there update equals insert..
(2:38:50 PM) jshaughn: not sure it matters
(2:39:12 PM) jshaughn: if we lose lastTime on down
(2:39:27 PM) jshaughn: I mean on a crash
(2:39:42 PM) jshaughn: may be an acceptable loss
(2:39:53 PM) gaYak: Isn't that usually the point when you really need it? ;)
(2:40:08 PM) jshaughn: not a hawkular crash, no
(2:41:02 PM) gaYak: Cascading failure isn't that uncommon.. only needs 
one SAN to start behaving badly
(2:41:43 PM) gaYak: Also, if we have HA, then we must have our caches 
synced among every copy of hawkular?
(2:41:54 PM) gaYak: Otherwise the lastTime is requestable from only one 
node?
(2:42:45 PM) jshaughn: I think the trade-off of losing that timestamp 
ona hawkular failure as opposed to millions of unnecessary writes is 
likely worth it. Not to mention those feeds may be up and running and 
the cache will pick up where it left off on startup
(2:43:23 PM) jshaughn: that was an early question, regarding the nature 
of the cluster-wide (ispn) cache
(2:44:40 PM) jshaughn: but if a feed is likely feeding to the same 
server repeatedly then the cache sync is maybe less of an issue
(2:44:58 PM) jshaughn: i honestly don't know what ispn does across a 
clustered cache
(2:45:33 PM) pilhuhn: There are tons of replication strategies including 
fully transactional
(2:45:38 PM) jsanda: caches can be configured as fully replicated or 
distributed
(2:46:38 PM) jsanda: and if we are going to start talking about using a 
distributed cache, then we really need to include spark in the 
discussion as it fits a number of use cases above and beyond being a 
distributed cache
(2:47:22 PM) gaYak: jsanda: Most likely we can't avoid Spark or some 
other alternative in the long run
(2:47:30 PM) gaYak: It seems like such use-cases come up all the time ;)
(2:47:39 PM) jsanda: right
(2:47:50 PM) jsanda: it's not an all or nothing proposition
(2:48:16 PM) jsanda: i alluded to this earlier on the mailing list
(2:48:58 PM) jsanda: things like spark, storm, etc. are great fits for a 
number of different things but the cost of the added operational 
complexity may very well outweigh the benefits
(2:51:38 PM) jshaughn: OK, so where are we? It sounds so far like H 
Metrics just stores all avail data it receives, and leaves any filtering 
to a consuming app. It does not need to aggregate unless it wants to (or 
is potentially configured to do so). For Hawkular it would be 
unnecessary. Hawkular MVP will assume raw avail as well, for storage and 
alerting (if it even gets any). Moving forward Hawkular may inrtoduce 
cache/stream to limit the avail data written to metrics and possibly 
processed by alerts. Yes?
(2:52:15 PM) gaYak: jshaughn: Yeah, probably for MVP it won't matter if 
we store everything.
(2:53:27 PM) jshaughn: H metrics will still need to provide a service to 
return avail intervals for a requested period, for gui consumption.
(2:53:47 PM) jsanda: assuming filtering is what we typically want, i 
wouldn't have the consuming app do it. have metrics or whatever the 
service is do it
(2:54:49 PM) gaYak: jsanda: mm, I'm not sure if we want to filter it
(2:54:53 PM) gaYak: jsanda: From end-applications
(2:55:14 PM) gaYak: What if someone wants an alert "monitoring returns 
something every 1s, otherwise alert"
(2:55:19 PM) jshaughn: jsanda: it depends how data flows, for example, 
if metrics does it then alerts, for example, may not see that benefit
(2:55:46 PM) gaYak: jsanda: We might filter on our storage-gateway, but 
not necessarily from consuming apps (unless they only want availability 
changes)
(2:55:58 PM) gaYak: Which I think should be two different streams..
(2:56:18 PM) gaYak: (yeah, I know getting information about change might 
be sometimes impossible)
(2:56:27 PM) jsanda: i'm lost :)
(2:56:40 PM) jsanda: all i'm suggesting is
(2:56:50 PM) gaYak: jsanda: If you filter "unnecessary" information on 
metrics side, while alerting would need it, then that's going to be an issue
(2:57:10 PM) jsanda: the query operations provided by the avail service 
should provide an option to filter out dups
(2:57:16 PM) gaYak: Aah
(2:57:21 PM) gaYak: Right, we were talking about different things



On 2/17/2015 5:52 AM, Heiko W.Rupp wrote:
>> Am 17.02.2015 um 10:21 schrieb Thomas Heute <theute at redhat.com>:
>> IMHO typically one would be happy with a check every 20s/30s or even a minute if the cost is "low", ie: the cost of the monitoring infrastructure is a small fraction of the infrastructure itself.
> We need to consider this at different levels.
>
> An agent may be able to determine process availability every second cheaply. This does not imply
> that it needs to forward that information every second to the server. And even if it did, it does not
> imply that we need to store a data point for every second.
>
> One thing we did never really fit into classical RHQ is caching.
> A Map<Long,Byte> for the last known state of a resource (*) can easily store the last known
> availability state for a huge number of resources. This way we would not need to query the
> database for each incoming point, but we'd look up the value in the cache and only store
> when it differs.
> Needs a bit more investigating + modelling to expire entries in the cache that do not get a
> data point every now and then and inform other subsystems (alerting) - that is not too heavy to implement.
> The agent can do similar caching for its resources and only forwarding when the state changes.
>
> This way we can scale to a lot of checks agent side without overwhelming server and data store.
>
>
> *) Yes I know we are currently using string IDs in many places. We may reconsider that for resource ids.
> _______________________________________________
> 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/20150219/dc1fe779/attachment-0001.html 

From hrupp at redhat.com  Thu Feb 19 16:00:49 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 19 Feb 2015 22:00:49 +0100
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <54E64C9A.5070104@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>
	<3F689D66-6FA5-4346-ACAA-526ADA787AD5@redhat.com>
	<54E64C9A.5070104@redhat.com>
Message-ID: <E7457C0C-8A5E-45DA-8C88-13C7E01B88A9@redhat.com>


> Am 19.02.2015 um 21:50 schrieb Catherine Robson <crobson at redhat.com>:
> 
> Would we be able to take documentation written in Git with Asciidoc and dynamically place that into other UI outputs?  Two reasons of why this might be useful:
> 
> - Bring documentation into the Hawkular community website to describe certain capabilties

Actually this poll is about community web site - user and developer documentation.

> - Bring documentation into the web console as context sensitive help pop-ups/sidebars

Yes, that can be done in at least two ways:
- reference the AsciiDoc content and render it locally into e.g. html
- have the community site be rendered into html and reference and just display it locally

> My current understanding of Asciidoc tells me this would be possible - but wanted to ask!

Asciidoc is first and foremost a markup schema that is very human readable without additional processing tools.

For example this is a part of the rest-api documentation (generated from Swagger+Jax-RS annotations on the code)

-----------------------------snip--------------------------
= Rest-Api for Hawkular-Inventory

== Rest api for Hawkular Inventory

Implemented in: org.hawkular.inventory.rest.RestApi

Produces:

* application/json

=== GET //

[.lead]
Description: Just returns a string to verify reachability

Return type: org.hawkular.inventory.rest.StringWrapper


=== POST //{tenantId}/resources

[.lead]
Description: Add a new resource for the passed tenantId

Return type: javax.ws.rs.core.Response

.Parameters
|===
|Name|Required|Type|Allowed Values|Default Value|Description

|tenantId|true|PATH|all||Id of the tenant
||true|BODY|all||The Resource to add
|===

-----------------------------snip--------------------------

And like in html, anchors can be built in and referenced later.

For e.g. http://hawkular.github.io/community/join.html
the source code is here: https://raw.githubusercontent.com/hawkular/hawkular.github.io/pages/src/main/jbake/content/community/join.adoc

Hope that helps

    Heiko


> 



> - Catherine
> 
> 
>> 	Heiko W.Rupp	February 19, 2015 at 4:51 AM
>> Hey,
>> 
>> please add yourself to the Doodle at http://doodle.com/a8ctk6wgwi3nh9f8 
>> I will close that tomorrow SOB
>> 
>> Heiko
>> 
>> 
>> 
>> 	Heiko W.Rupp	February 17, 2015 at 9:15 AM
>> Hey,
>> 
>> as we made some progress with hawkular.github.io, the question came up what should go there and if we can't just use something else instead.
>> 
>> I am very much in favor of using AsciiDoc + git for the documentation -- user and developer
>> 
>> Clear advantages that I see for this solution:
>> 
>> - versioning is easy as it is built into git. We can easily create branches for various versions of the Hawkular
>> without the complicated clone process that we had in the past
>> - offline possibility an author does not need to be online to write docs
>> - AsciiDoc is plain text. The pages may have a handful of specific header lines, but if you don't want to format any markup, then just don't
>> - Contributing is easy. People just git clone the repo, make their changes and submit a pull-request
>> - docs are directly rendered on GitHub
>> - AsciiDoc is already used in our README.adoc files
>> - With AsciiDoctor there is a good tool chain for creating good print, html, pdf, docbook output
>> - it is possible to write docs in vi/emacs/Notepad
>> 
>> Tooling may not yet be that perfect; the mvn jbake:inline mode is already quite well able to re-create 
>> the website locally though; with a browser extension like "live-reload", editing a text is as wysiwyg as on a wiki
>> 
>> 
>> There are other JBoss projects that follow the AsciiDoc+git approach with great success
>> like http://arquillian.org, http://hibernate.org, http://liveoak.io, http://torquebox.org(*)
>> 
>> Anyway I've started a doodle to get feedback and then proceed further - so please visit
>> http://doodle.com/a8ctk6wgwi3nh9f8
>> so that we can come to a documentation solution that we all use.
>> 
>> Heiko
>> 
>> *) Actually uses Markdown as markup language
>> 
>> 
>> 
>> _______________________________________________
>> 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
> 

-- 
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

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

From hrupp at redhat.com  Thu Feb 19 16:25:26 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 19 Feb 2015 22:25:26 +0100
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <54E207B9.1090204@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
	<54E207B9.1090204@redhat.com>
Message-ID: <F10F251F-765E-4D1D-847E-1DF964C16C58@redhat.com>


> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com>:
> Second, the possibility to run in a non-WF-like container is still 
> somewhere in my consciousness. Importing wf BoM does not seem to be a 
> step in that direction.

Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 apis.
We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there by default, but
can be supplied by the application).
This does not imply that we have to develop on EAP 6.4 though.





From ike.braun at googlemail.com  Fri Feb 20 02:50:40 2015
From: ike.braun at googlemail.com (Heiko Braun)
Date: Fri, 20 Feb 2015 08:50:40 +0100
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <F10F251F-765E-4D1D-847E-1DF964C16C58@redhat.com>
References: <54E1F2A4.7010401@redhat.com> <54E1F313.9060406@redhat.com>
	<428528746.12642680.1424095931023.JavaMail.zimbra@redhat.com>
	<54E207B9.1090204@redhat.com>
	<F10F251F-765E-4D1D-847E-1DF964C16C58@redhat.com>
Message-ID: <DEBBEE77-3702-4FF8-83F1-FDE32381A4FD@googlemail.com>


> On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
>> 
>> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com <mailto:ppalaga at redhat.com>>:
>> Second, the possibility to run in a non-WF-like container is still 
>> somewhere in my consciousness. Importing wf BoM does not seem to be a 
>> step in that direction.
> 
> Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 apis.
> We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there by default, but
> can be supplied by the application).
> This does not imply that we have to develop on EAP 6.4 though.


These two statements are contradicting each other: running in a ?non WF-like? container and assuming EE6 API?s on the target platform are two worlds apart.

First of all, if you build on EE6, you don?t ?restrict? yourself. At least not in the way of ?limiting? the API dependencies. But limiting the API dependencies is a prerequisite to successfully integrate with other platforms (or containers), which is what Peter has in mind, if I am correct.

Hawkular want?s to provide a set of re-usable components. Re-usable in a sense, that other software project can integrate them easily. On the other hand there is the goal to build a Hawkular application, which itself is a consumer of the before mentioned components. 

I think the continuous mistake among the Hawkular contributors is that you don?t prioritise these two approaches. To do that, we need to acknowledge an intrinsic dependency of the Hawkular application onto the components. Furthermore, any decision of API and service dependencies of those components impacts the way in which they can be re-used. Dependencies would need to be carried over to any platform that want?s to leverage Hawkular components. Which, in a way, limits it?s reusability. 

My suggestion would be to prioritise on the component re-use. Even if that results in inconveniences  when building the Hawkular application: 

- Get rid of all EE6 dependencies. 
- Stop thinking in WAR and EAR deployments. 
- Support reusability by strictly limiting the API dependencies. 
- Come to an agreement about the priorities. 
- Document and communicate the outcome of this discussion 
- Make sure all contributors understand and respect these constraints.

Regards, Heiko B.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150220/6963da5a/attachment-0001.html 

From tsegismo at redhat.com  Fri Feb 20 04:19:24 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 Feb 2015 10:19:24 +0100
Subject: [Hawkular-dev] Response time ?
In-Reply-To: <A5988FC7-72A2-4570-98EB-CDE62BDBA3AB@redhat.com>
References: <54E5F120.5070805@redhat.com>
	<A5988FC7-72A2-4570-98EB-CDE62BDBA3AB@redhat.com>
Message-ID: <54E6FC1C.4090607@redhat.com>

Percentiles and standard deviation are needed in general.

Now on a *default* dashboard (this is what you're asking about, 
correct?) I personally like to see avg AND 90 percentile.


Le 19/02/2015 15:52, John Sanda a ?crit :
> I like percentiles. Here is a good article that explains why percentiles
> are effective and why they should be used for baselining.
>
> http://apmblog.dynatrace.com/2012/11/14/why-averages-suck-and-percentiles-are-great/
>
>> On Feb 19, 2015, at 9:20 AM, Thomas Heute <theute at redhat.com
>> <mailto:theute at redhat.com>> wrote:
>>
>>
>> What is a useful representation of a response time over a period of time ?
>>
>>     - Average of all the samples ? *2.22s*
>>     - 90/95/99 percentile ? 99% of your requests took less than *2.45s*
>>     - Percentage of valid samples ? *94%* of your requests took less
>> than your 3s acceptable time.
>>     - Apdex ? http://en.wikipedia.org/wiki/Apdex
>>
>> Anything else ? (This is for a quick overview of the health of a system).
>>
>> Thomas
>>
>> _______________________________________________
>> 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
>


From hrupp at redhat.com  Fri Feb 20 05:00:51 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 20 Feb 2015 11:00:51 +0100
Subject: [Hawkular-dev] Documentation - asciidoc + git it is
Message-ID: <62B71785-251D-45D3-82D3-AD3028DC683B@redhat.com>

Hey,

after closing the poll, there is a clear winner:

asciidoc+git on https://github.com/hawkular/hawkular.github.io

Remember, writing is done in the "pages" branch https://github.com/hawkular/hawkular.github.io/tree/pages

The web presence hawkular.github.io will then be rendered by Travis on push to the branch.

See http://doodle.com/a8ctk6wgwi3nh9f8


We may revisit the branch to push to / PR against later again.

  Heiko

From theute at redhat.com  Fri Feb 20 05:53:17 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 20 Feb 2015 11:53:17 +0100
Subject: [Hawkular-dev] Response time ?
In-Reply-To: <54E6FC1C.4090607@redhat.com>
References: <54E5F120.5070805@redhat.com>	<A5988FC7-72A2-4570-98EB-CDE62BDBA3AB@redhat.com>
	<54E6FC1C.4090607@redhat.com>
Message-ID: <54E7121D.3030708@redhat.com>



On 02/20/2015 10:19 AM, Thomas Segismont wrote:
> Percentiles and standard deviation are needed in general.
>
> Now on a *default* dashboard (this is what you're asking about,
> correct?) I personally like to see avg AND 90 percentile.

Yes, really as overview information. Somehow indicator of the health of 
the monitored resource. Ideally something we can link to a color 
(Green->Red) for quick summary.

Thomas

>
>
> Le 19/02/2015 15:52, John Sanda a ?crit :
>> I like percentiles. Here is a good article that explains why percentiles
>> are effective and why they should be used for baselining.
>>
>> http://apmblog.dynatrace.com/2012/11/14/why-averages-suck-and-percentiles-are-great/
>>
>>> On Feb 19, 2015, at 9:20 AM, Thomas Heute <theute at redhat.com
>>> <mailto:theute at redhat.com>> wrote:
>>>
>>>
>>> What is a useful representation of a response time over a period of time ?
>>>
>>>      - Average of all the samples ? *2.22s*
>>>      - 90/95/99 percentile ? 99% of your requests took less than *2.45s*
>>>      - Percentage of valid samples ? *94%* of your requests took less
>>> than your 3s acceptable time.
>>>      - Apdex ? http://en.wikipedia.org/wiki/Apdex
>>>
>>> Anything else ? (This is for a quick overview of the health of a system).
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From lkrejci at redhat.com  Fri Feb 20 06:03:11 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 20 Feb 2015 12:03:11 +0100
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <DEBBEE77-3702-4FF8-83F1-FDE32381A4FD@googlemail.com>
References: <54E1F2A4.7010401@redhat.com>
	<F10F251F-765E-4D1D-847E-1DF964C16C58@redhat.com>
	<DEBBEE77-3702-4FF8-83F1-FDE32381A4FD@googlemail.com>
Message-ID: <1583224.bNIt6pHX4Z@localhost.localdomain>

On Friday, February 20, 2015 08:50:40 Heiko Braun wrote:
> > On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
> >> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com
> >> <mailto:ppalaga at redhat.com>>: Second, the possibility to run in a
> >> non-WF-like container is still somewhere in my consciousness. Importing
> >> wf BoM does not seem to be a step in that direction.
> > 
> > Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 apis.
> > We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there
> > by default, but can be supplied by the application).
> > This does not imply that we have to develop on EAP 6.4 though.
> 
> These two statements are contradicting each other: running in a ?non
> WF-like? container and assuming EE6 API?s on the target platform are two
> worlds apart.
> 
> First of all, if you build on EE6, you don?t ?restrict? yourself. At least
> not in the way of ?limiting? the API dependencies. But limiting the API
> dependencies is a prerequisite to successfully integrate with other
> platforms (or containers), which is what Peter has in mind, if I am
> correct.
> 
> Hawkular want?s to provide a set of re-usable components. Re-usable in a
> sense, that other software project can integrate them easily. On the other
> hand there is the goal to build a Hawkular application, which itself is a
> consumer of the before mentioned components.
> 
> I think the continuous mistake among the Hawkular contributors is that you
> don?t prioritise these two approaches. To do that, we need to acknowledge
> an intrinsic dependency of the Hawkular application onto the components.
> Furthermore, any decision of API and service dependencies of those
> components impacts the way in which they can be re-used. Dependencies would
> need to be carried over to any platform that want?s to leverage Hawkular
> components. Which, in a way, limits it?s reusability.
> 

I guess the point the Heiko R. wanted to make is that by using jboss-javaee7 
BoM or whatever BoM that defines versions of dependencies that are used in our 
*primary* target container, all we are doing is that we limit ourselves in a 
choice of versions of *potential* dependencies. By importing a BoM you don't 
actually depend on anything - you merely predefine the versions of artifacts 
you might want to depend on. All it does is it makes our lives easier when 
composing the integrated solution together.

Otherwise everything you said resonates with me. The components themselves 
should be first of all embeddable as a library and therefore have only an 
absolutely necessary number of deps.

REST API then becomes a facade on top of that. If we ever want to expose the 
components as EJBs, those EJBs would again be facades using the library. Etc.

That's how I understood the outcome of our design discussions. While it may 
not look like it at the moment when we want to "rush" something (barely) 
consumable out to public, that outcome is definitely what we want to have in 
the "final" picture (or at least I sincerely hope so ;) ).

Of course, embeddable libraries are only a small beginning. The picture gets 
more interesting when you start to think about integrations between the 
components (i.e actually fire an alert when some value flows into metrics). I 
actually am not sure we cracked that architectural nut such that we all are 
satisfied with it. A message bus of sorts lends itself as a solution to 
loosely coupled communication between the components but components themselves 
I think should not depend on the bus by default - if for nothing else than for 
the "baggage" of dependencies any of the message bus solutions carry with it. 


> My suggestion would be to prioritise on the component re-use. Even if that
> results in inconveniences  when building the Hawkular application:
> 
> - Get rid of all EE6 dependencies.

+1

> - Stop thinking in WAR and EAR deployments.

+1 for components, -1 for their REST APIs and the integrated solution

> - Support reusability by strictly limiting the API dependencies.

+100

> - Come to an agreement about the priorities.

I think the prios are clear - rush something "dirty" out now, clean up to our 
hearts' content right after the first version is out.

> - Document and communicate the outcome of this discussion

+1, we (and most of all I) need to get better at this

> - Make sure all contributors understand and respect these constraints.
> 
> Regards, Heiko B.



From theute at redhat.com  Fri Feb 20 08:17:52 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 20 Feb 2015 14:17:52 +0100
Subject: [Hawkular-dev] Documentation writing
In-Reply-To: <E7457C0C-8A5E-45DA-8C88-13C7E01B88A9@redhat.com>
References: <F2DC8C43-C0DF-4CDF-9B0E-40F9F5C529ED@redhat.com>	<3F689D66-6FA5-4346-ACAA-526ADA787AD5@redhat.com>	<54E64C9A.5070104@redhat.com>
	<E7457C0C-8A5E-45DA-8C88-13C7E01B88A9@redhat.com>
Message-ID: <54E73400.2080604@redhat.com>

I added an article about the docs we intend to produce, how and where to 
publish:
https://developer.jboss.org/wiki/HawkularDocumentations

Feel free to comment

(Yes it's another source of documentation ;))

Thomas


On 02/19/2015 10:00 PM, Heiko W.Rupp wrote:
>
>> Am 19.02.2015 um 21:50 schrieb Catherine Robson <crobson at redhat.com
>> <mailto:crobson at redhat.com>>:
>>
>> Would we be able to take documentation written in Git with Asciidoc
>> and dynamically place that into other UI outputs?  Two reasons of why
>> this might be useful:
>>
>> - Bring documentation into the Hawkular community website to
>> describe certain capabilties
>
> Actually this poll is about community web site - user and developer
> documentation.
>
>> - Bring documentation into the web console as context sensitive
>> help pop-ups/sidebars
>
> Yes, that can be done in at least two ways:
> - reference the AsciiDoc content and render it locally into e.g. html
> - have the community site be rendered into html and reference and just
> display it locally
>
>> My current understanding of Asciidoc tells me this would be possible
>> - but wanted to ask!
>
> Asciidoc is first and foremost a markup schema that is very human
> readable without additional processing tools.
>
> For example this is a part of the rest-api documentation (generated from
> Swagger+Jax-RS annotations on the code)
>
> -----------------------------snip--------------------------
> = Rest-Api for Hawkular-Inventory
>
> == Rest api for Hawkular Inventory
>
> Implemented in: org.hawkular.inventory.rest.RestApi
>
> Produces:
>
> * application/json
>
> === GET //
>
> [.lead]
> Description: Just returns a string to verify reachability
>
> Return type: org.hawkular.inventory.rest.StringWrapper
>
>
> === POST //{tenantId}/resources
>
> [.lead]
> Description: Add a new resource for the passed tenantId
>
> Return type: javax.ws.rs.core.Response
>
> .Parameters
> |===
> |Name|Required|Type|Allowed Values|Default Value|Description
>
> |tenantId|true|PATH|all||Id of the tenant
> ||true|BODY|all||The Resource to add
> |===
>
> -----------------------------snip--------------------------
>
> And like in html, anchors can be built in and referenced later.
>
> For e.g. http://hawkular.github.io/community/join.html
> the source code is here:
> https://raw.githubusercontent.com/hawkular/hawkular.github.io/pages/src/main/jbake/content/community/join.adoc
>
> Hope that helps
>
>      Heiko
>
>
>>
>
>
>
>> - Catherine
>>
>>
>>> Heiko W.RuppFebruary 19, 2015 at 4:51 AM
>>> Hey,
>>>
>>> please add yourself to the Doodle at http://doodle.com/a8ctk6wgwi3nh9f8
>>> I will close that tomorrow SOB
>>>
>>> Heiko
>>>
>>>
>>>
>>> Heiko W.RuppFebruary 17, 2015 at 9:15 AM
>>> Hey,
>>>
>>> as we made some progress with hawkular.github.io, the question came
>>> up what should go there and if we can't just use something else instead.
>>>
>>> I am very much in favor of using AsciiDoc + git for the documentation
>>> -- user and developer
>>>
>>> Clear advantages that I see for this solution:
>>>
>>> - versioning is easy as it is built into git. We can easily
>>> create branches for various versions of the Hawkular
>>> without the complicated clone process that we had in the past
>>> - offline possibility an author does not need to be online to write docs
>>> - AsciiDoc is plain text. The pages may have a handful of specific
>>> header lines, but if you don't want to format any markup, then just don't
>>> - Contributing is easy. People just git clone the repo, make their
>>> changes and submit a pull-request
>>> - docs are directly rendered on GitHub
>>> - AsciiDoc is already used in our README.adoc files
>>> - With AsciiDoctor there is a good tool chain for creating good
>>> print, html, pdf, docbook output
>>> - it is possible to write docs in vi/emacs/Notepad
>>>
>>> Tooling may not yet be that perfect; the mvn jbake:inline mode is
>>> already quite well able to re-create
>>> the website locally though; with a browser extension like
>>> "live-reload", editing a text is as wysiwyg as on a wiki
>>>
>>>
>>> There are other JBoss projects that follow the AsciiDoc+git approach
>>> with great success
>>> like http://arquillian.org, http://hibernate.org, http://liveoak.io, http://torquebox.org(*)
>>>
>>> Anyway I've started a doodle to get feedback and then proceed further
>>> - so please visit
>>> http://doodle.com/a8ctk6wgwi3nh9f8
>>> so that we can come to a documentation solution that we all use.
>>>
>>> Heiko
>>>
>>> *) Actually uses Markdown as markup language
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> --
> 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
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From mazz at redhat.com  Fri Feb 20 09:26:12 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 20 Feb 2015 09:26:12 -0500 (EST)
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <1583224.bNIt6pHX4Z@localhost.localdomain>
References: <54E1F2A4.7010401@redhat.com>
	<F10F251F-765E-4D1D-847E-1DF964C16C58@redhat.com>
	<DEBBEE77-3702-4FF8-83F1-FDE32381A4FD@googlemail.com>
	<1583224.bNIt6pHX4Z@localhost.localdomain>
Message-ID: <2005242853.15901274.1424442372121.JavaMail.zimbra@redhat.com>

I don't understand the rush to get rid of EE6 and dependencies like that (especially when we are rushing to get something done quickly). We have at our disposal a nice EE API and deployment model that let's us "get work done". If we don't, for example, use MDBs, we have to handle all of what they do by ourselves. Same with the other types of constructs.

I can see this restriction for things like wildfly-monitor where we embed a collector of metrics that could go in Wildfly-Core. But for the integration components (like alerts), to take away EE would be detrimental to the development effort because think of all the infrastructure we'd have to "re-invent" before we could do the actual work of alerting.

What are the use-cases where we don't want EE? What components are we talking about that shouldn't use EE? Maybe I'm missing the big picture??

----- Original Message -----
> On Friday, February 20, 2015 08:50:40 Heiko Braun wrote:
> > > On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
> > >> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com
> > >> <mailto:ppalaga at redhat.com>>: Second, the possibility to run in a
> > >> non-WF-like container is still somewhere in my consciousness. Importing
> > >> wf BoM does not seem to be a step in that direction.
> > > 
> > > Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1
> > > apis.
> > > We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there
> > > by default, but can be supplied by the application).
> > > This does not imply that we have to develop on EAP 6.4 though.
> > 
> > These two statements are contradicting each other: running in a ?non
> > WF-like? container and assuming EE6 API?s on the target platform are two
> > worlds apart.
> > 
> > First of all, if you build on EE6, you don?t ?restrict? yourself. At least
> > not in the way of ?limiting? the API dependencies. But limiting the API
> > dependencies is a prerequisite to successfully integrate with other
> > platforms (or containers), which is what Peter has in mind, if I am
> > correct.
> > 
> > Hawkular want?s to provide a set of re-usable components. Re-usable in a
> > sense, that other software project can integrate them easily. On the other
> > hand there is the goal to build a Hawkular application, which itself is a
> > consumer of the before mentioned components.
> > 
> > I think the continuous mistake among the Hawkular contributors is that you
> > don?t prioritise these two approaches. To do that, we need to acknowledge
> > an intrinsic dependency of the Hawkular application onto the components.
> > Furthermore, any decision of API and service dependencies of those
> > components impacts the way in which they can be re-used. Dependencies would
> > need to be carried over to any platform that want?s to leverage Hawkular
> > components. Which, in a way, limits it?s reusability.
> > 
> 
> I guess the point the Heiko R. wanted to make is that by using jboss-javaee7
> BoM or whatever BoM that defines versions of dependencies that are used in
> our
> *primary* target container, all we are doing is that we limit ourselves in a
> choice of versions of *potential* dependencies. By importing a BoM you don't
> actually depend on anything - you merely predefine the versions of artifacts
> you might want to depend on. All it does is it makes our lives easier when
> composing the integrated solution together.
> 
> Otherwise everything you said resonates with me. The components themselves
> should be first of all embeddable as a library and therefore have only an
> absolutely necessary number of deps.
> 
> REST API then becomes a facade on top of that. If we ever want to expose the
> components as EJBs, those EJBs would again be facades using the library. Etc.
> 
> That's how I understood the outcome of our design discussions. While it may
> not look like it at the moment when we want to "rush" something (barely)
> consumable out to public, that outcome is definitely what we want to have in
> the "final" picture (or at least I sincerely hope so ;) ).
> 
> Of course, embeddable libraries are only a small beginning. The picture gets
> more interesting when you start to think about integrations between the
> components (i.e actually fire an alert when some value flows into metrics). I
> actually am not sure we cracked that architectural nut such that we all are
> satisfied with it. A message bus of sorts lends itself as a solution to
> loosely coupled communication between the components but components
> themselves
> I think should not depend on the bus by default - if for nothing else than
> for
> the "baggage" of dependencies any of the message bus solutions carry with it.
> 
> 
> > My suggestion would be to prioritise on the component re-use. Even if that
> > results in inconveniences  when building the Hawkular application:
> > 
> > - Get rid of all EE6 dependencies.
> 
> +1
> 
> > - Stop thinking in WAR and EAR deployments.
> 
> +1 for components, -1 for their REST APIs and the integrated solution
> 
> > - Support reusability by strictly limiting the API dependencies.
> 
> +100
> 
> > - Come to an agreement about the priorities.
> 
> I think the prios are clear - rush something "dirty" out now, clean up to our
> hearts' content right after the first version is out.
> 
> > - Document and communicate the outcome of this discussion
> 
> +1, we (and most of all I) need to get better at this
> 
> > - Make sure all contributors understand and respect these constraints.
> > 
> > Regards, Heiko B.
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From lkrejci at redhat.com  Fri Feb 20 12:52:55 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 20 Feb 2015 18:52:55 +0100
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <2005242853.15901274.1424442372121.JavaMail.zimbra@redhat.com>
References: <54E1F2A4.7010401@redhat.com>
	<1583224.bNIt6pHX4Z@localhost.localdomain>
	<2005242853.15901274.1424442372121.JavaMail.zimbra@redhat.com>
Message-ID: <13459601.L4crTI6OOI@localhost.localdomain>

Alerting is frankly the most complex part of the big picture which Jay or 
LucasP are be much more qualified to comment on.

But for example inventory is at its core just a simple CRUD interface. The 
only thing fancy about it is that it stores a graph with custom edges (and can 
do versioning, blah, blah). Inventory in and of itself doesn't interact with 
anything else. It could use JPA for example but that would unnecessarily tie 
it to RDBMs which it currently doesn't need (and uses a graph db instead).

Of course, that changes when you want to integrate other stuff with inventory 
and create the "big picture". But only then one should think about using EE 
(or camel for that matter) stuff to help with that.


Metrics is another example that could do without ee just fine imho. Again, 
only the integration layer really needs some of the EE features because of the 
bus and even then I think your bus works out of ee, too?

I think the question coul also be what we DO absolutely necessary need that is 
best provided by EE.

On Friday, February 20, 2015 09:26:12 John Mazzitelli wrote:
> I don't understand the rush to get rid of EE6 and dependencies like that
> (especially when we are rushing to get something done quickly). We have at
> our disposal a nice EE API and deployment model that let's us "get work
> done". If we don't, for example, use MDBs, we have to handle all of what
> they do by ourselves. Same with the other types of constructs.
> 
> I can see this restriction for things like wildfly-monitor where we embed a
> collector of metrics that could go in Wildfly-Core. But for the integration
> components (like alerts), to take away EE would be detrimental to the
> development effort because think of all the infrastructure we'd have to
> "re-invent" before we could do the actual work of alerting.
> 
> What are the use-cases where we don't want EE? What components are we
> talking about that shouldn't use EE? Maybe I'm missing the big picture??
> 
> ----- Original Message -----
> 
> > On Friday, February 20, 2015 08:50:40 Heiko Braun wrote:
> > > > On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
> > > >> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com
> > > >> <mailto:ppalaga at redhat.com>>: Second, the possibility to run in a
> > > >> non-WF-like container is still somewhere in my consciousness.
> > > >> Importing
> > > >> wf BoM does not seem to be a step in that direction.
> > > > 
> > > > Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1
> > > > apis.
> > > > We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in
> > > > there
> > > > by default, but can be supplied by the application).
> > > > This does not imply that we have to develop on EAP 6.4 though.
> > > 
> > > These two statements are contradicting each other: running in a ?non
> > > WF-like? container and assuming EE6 API?s on the target platform are two
> > > worlds apart.
> > > 
> > > First of all, if you build on EE6, you don?t ?restrict? yourself. At
> > > least
> > > not in the way of ?limiting? the API dependencies. But limiting the API
> > > dependencies is a prerequisite to successfully integrate with other
> > > platforms (or containers), which is what Peter has in mind, if I am
> > > correct.
> > > 
> > > Hawkular want?s to provide a set of re-usable components. Re-usable in a
> > > sense, that other software project can integrate them easily. On the
> > > other
> > > hand there is the goal to build a Hawkular application, which itself is
> > > a
> > > consumer of the before mentioned components.
> > > 
> > > I think the continuous mistake among the Hawkular contributors is that
> > > you
> > > don?t prioritise these two approaches. To do that, we need to
> > > acknowledge
> > > an intrinsic dependency of the Hawkular application onto the components.
> > > Furthermore, any decision of API and service dependencies of those
> > > components impacts the way in which they can be re-used. Dependencies
> > > would
> > > need to be carried over to any platform that want?s to leverage Hawkular
> > > components. Which, in a way, limits it?s reusability.
> > 
> > I guess the point the Heiko R. wanted to make is that by using
> > jboss-javaee7 BoM or whatever BoM that defines versions of dependencies
> > that are used in our
> > *primary* target container, all we are doing is that we limit ourselves in
> > a choice of versions of *potential* dependencies. By importing a BoM you
> > don't actually depend on anything - you merely predefine the versions of
> > artifacts you might want to depend on. All it does is it makes our lives
> > easier when composing the integrated solution together.
> > 
> > Otherwise everything you said resonates with me. The components themselves
> > should be first of all embeddable as a library and therefore have only an
> > absolutely necessary number of deps.
> > 
> > REST API then becomes a facade on top of that. If we ever want to expose
> > the components as EJBs, those EJBs would again be facades using the
> > library. Etc.
> > 
> > That's how I understood the outcome of our design discussions. While it
> > may
> > not look like it at the moment when we want to "rush" something (barely)
> > consumable out to public, that outcome is definitely what we want to have
> > in the "final" picture (or at least I sincerely hope so ;) ).
> > 
> > Of course, embeddable libraries are only a small beginning. The picture
> > gets more interesting when you start to think about integrations between
> > the components (i.e actually fire an alert when some value flows into
> > metrics). I actually am not sure we cracked that architectural nut such
> > that we all are satisfied with it. A message bus of sorts lends itself as
> > a solution to loosely coupled communication between the components but
> > components themselves
> > I think should not depend on the bus by default - if for nothing else than
> > for
> > the "baggage" of dependencies any of the message bus solutions carry with
> > it.> 
> > > My suggestion would be to prioritise on the component re-use. Even if
> > > that
> > > results in inconveniences  when building the Hawkular application:
> > > 
> > > - Get rid of all EE6 dependencies.
> > 
> > +1
> > 
> > > - Stop thinking in WAR and EAR deployments.
> > 
> > +1 for components, -1 for their REST APIs and the integrated solution
> > 
> > > - Support reusability by strictly limiting the API dependencies.
> > 
> > +100
> > 
> > > - Come to an agreement about the priorities.
> > 
> > I think the prios are clear - rush something "dirty" out now, clean up to
> > our hearts' content right after the first version is out.
> > 
> > > - Document and communicate the outcome of this discussion
> > 
> > +1, we (and most of all I) need to get better at this
> > 
> > > - Make sure all contributors understand and respect these constraints.
> > > 
> > > Regards, Heiko B.
> > 
> > _______________________________________________
> > 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  Fri Feb 20 17:34:07 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 20 Feb 2015 17:34:07 -0500 (EST)
Subject: [Hawkular-dev] xml processing in mvn
In-Reply-To: <960906243.16508577.1424471605237.JavaMail.zimbra@redhat.com>
Message-ID: <803224185.16508656.1424471647163.JavaMail.zimbra@redhat.com>

FYI: I just found this:

http://code.google.com/p/maven-config-processor-plugin/wiki/TransformationConfiguration

I think we can use this when tweaking our WildFly standalone.xml file in our maven builds.

I'll play with it and see how well it works.

From ppalaga at redhat.com  Sun Feb 22 16:19:02 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Sun, 22 Feb 2015 22:19:02 +0100
Subject: [Hawkular-dev] xml processing in mvn
In-Reply-To: <803224185.16508656.1424471647163.JavaMail.zimbra@redhat.com>
References: <803224185.16508656.1424471647163.JavaMail.zimbra@redhat.com>
Message-ID: <54EA47C6.8010609@redhat.com>

FWIW, we did something similar in the portal using an XSL transformation 
and xml-maven-plugin 
https://github.com/gatein/gatein-portal/blob/master/packaging/jboss/pkg/pom.xml#L308 
-- P

On 02/20/2015 11:34 PM, John Mazzitelli wrote:
> FYI: I just found this:
>
> http://code.google.com/p/maven-config-processor-plugin/wiki/TransformationConfiguration
>
> I think we can use this when tweaking our WildFly standalone.xml file in our maven builds.
>
> I'll play with it and see how well it works.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jsanda at redhat.com  Sun Feb 22 17:49:20 2015
From: jsanda at redhat.com (John Sanda)
Date: Sun, 22 Feb 2015 17:49:20 -0500
Subject: [Hawkular-dev] xml processing in mvn
In-Reply-To: <803224185.16508656.1424471647163.JavaMail.zimbra@redhat.com>
References: <803224185.16508656.1424471647163.JavaMail.zimbra@redhat.com>
Message-ID: <F7703D0A-511E-4582-B6C8-EB78638388F7@redhat.com>

Groovy has nice, intuitive support for updating xml documents[1]. You could use the gmaven plugin to execute a groovy script that performs the updates.
 
[1] http://groovy.codehaus.org/Updating+XML+with+XmlSlurper <http://groovy.codehaus.org/Updating+XML+with+XmlSlurper> 

> On Feb 20, 2015, at 5:34 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> FYI: I just found this:
> 
> http://code.google.com/p/maven-config-processor-plugin/wiki/TransformationConfiguration
> 
> I think we can use this when tweaking our WildFly standalone.xml file in our maven builds.
> 
> I'll play with it and see how well it works.
> _______________________________________________
> 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/20150222/7246467e/attachment.html 

From hrupp at redhat.com  Mon Feb 23 04:34:43 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 23 Feb 2015 10:34:43 +0100
Subject: [Hawkular-dev] Interesting read: nulling out references may harm GC
Message-ID: <24EB974C-CEA8-4E30-82C3-EAEE87BF16AB@redhat.com>

http://cr.openjdk.java.net/~shade/scratch/LocalCollect.java


-- 
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 jshaughn at redhat.com  Mon Feb 23 09:41:48 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 23 Feb 2015 09:41:48 -0500
Subject: [Hawkular-dev] Usage of other apis
In-Reply-To: <13459601.L4crTI6OOI@localhost.localdomain>
References: <54E1F2A4.7010401@redhat.com>	<1583224.bNIt6pHX4Z@localhost.localdomain>	<2005242853.15901274.1424442372121.JavaMail.zimbra@redhat.com>
	<13459601.L4crTI6OOI@localhost.localdomain>
Message-ID: <54EB3C2C.9000105@redhat.com>


As it stands Alerting is actually trying to deliver something 
embeddable, basically a CRUD interface as well, and also an engine that 
does not have J2EE deps.  For example, the actual engine is a small-ish 
core piece packaged as a Jar (*).  It can take in Trigger definitions, 
and data, and spit out Alerts, all (rest) API based outside of any J2EE 
needs.   But what we are not avoiding wrt Hawkular Kettle/MVP are J2EE 
and Hawkular Bus dependencies, specifically MDBs, for pulling H Metrics 
data, posting Alerts, and providing some level of Actions (like 
Notifications).   I don't see a reason to avoid this, in essence, H 
Kettle is a consuming app that uses J2EE, and that is is how we are 
treating it.  At the moment I don't see an issue including H Kettle 
artifacts within the H Alerts build although we may need to work on the 
repo organization a bit.

What we are struggling with is to figure out the best demarcation 
between H Alerts and the consuming apps, making consumption as easy as 
possible.  This is not super easy, as UI, Actions, etc all need to apply 
customization, but we want to make that customization as painless as 
possible.

(*) Actually, at the moment we may have a dependency on a Datasource for 
persistence, I know we are using H2 at the moment.  We may have to look 
at the persistence level.


On 2/20/2015 12:52 PM, Lukas Krejci wrote:
> Alerting is frankly the most complex part of the big picture which Jay or
> LucasP are be much more qualified to comment on.
>
> But for example inventory is at its core just a simple CRUD interface. The
> only thing fancy about it is that it stores a graph with custom edges (and can
> do versioning, blah, blah). Inventory in and of itself doesn't interact with
> anything else. It could use JPA for example but that would unnecessarily tie
> it to RDBMs which it currently doesn't need (and uses a graph db instead).
>
> Of course, that changes when you want to integrate other stuff with inventory
> and create the "big picture". But only then one should think about using EE
> (or camel for that matter) stuff to help with that.
>
>
> Metrics is another example that could do without ee just fine imho. Again,
> only the integration layer really needs some of the EE features because of the
> bus and even then I think your bus works out of ee, too?
>
> I think the question coul also be what we DO absolutely necessary need that is
> best provided by EE.
>
> On Friday, February 20, 2015 09:26:12 John Mazzitelli wrote:
>> I don't understand the rush to get rid of EE6 and dependencies like that
>> (especially when we are rushing to get something done quickly). We have at
>> our disposal a nice EE API and deployment model that let's us "get work
>> done". If we don't, for example, use MDBs, we have to handle all of what
>> they do by ourselves. Same with the other types of constructs.
>>
>> I can see this restriction for things like wildfly-monitor where we embed a
>> collector of metrics that could go in Wildfly-Core. But for the integration
>> components (like alerts), to take away EE would be detrimental to the
>> development effort because think of all the infrastructure we'd have to
>> "re-invent" before we could do the actual work of alerting.
>>
>> What are the use-cases where we don't want EE? What components are we
>> talking about that shouldn't use EE? Maybe I'm missing the big picture??
>>
>> ----- Original Message -----
>>
>>> On Friday, February 20, 2015 08:50:40 Heiko Braun wrote:
>>>>> On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>>>>> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com
>>>>>> <mailto:ppalaga at redhat.com>>: Second, the possibility to run in a
>>>>>> non-WF-like container is still somewhere in my consciousness.
>>>>>> Importing
>>>>>> wf BoM does not seem to be a step in that direction.
>>>>> Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1
>>>>> apis.
>>>>> We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in
>>>>> there
>>>>> by default, but can be supplied by the application).
>>>>> This does not imply that we have to develop on EAP 6.4 though.
>>>> These two statements are contradicting each other: running in a ?non
>>>> WF-like? container and assuming EE6 API?s on the target platform are two
>>>> worlds apart.
>>>>
>>>> First of all, if you build on EE6, you don?t ?restrict? yourself. At
>>>> least
>>>> not in the way of ?limiting? the API dependencies. But limiting the API
>>>> dependencies is a prerequisite to successfully integrate with other
>>>> platforms (or containers), which is what Peter has in mind, if I am
>>>> correct.
>>>>
>>>> Hawkular want?s to provide a set of re-usable components. Re-usable in a
>>>> sense, that other software project can integrate them easily. On the
>>>> other
>>>> hand there is the goal to build a Hawkular application, which itself is
>>>> a
>>>> consumer of the before mentioned components.
>>>>
>>>> I think the continuous mistake among the Hawkular contributors is that
>>>> you
>>>> don?t prioritise these two approaches. To do that, we need to
>>>> acknowledge
>>>> an intrinsic dependency of the Hawkular application onto the components.
>>>> Furthermore, any decision of API and service dependencies of those
>>>> components impacts the way in which they can be re-used. Dependencies
>>>> would
>>>> need to be carried over to any platform that want?s to leverage Hawkular
>>>> components. Which, in a way, limits it?s reusability.
>>> I guess the point the Heiko R. wanted to make is that by using
>>> jboss-javaee7 BoM or whatever BoM that defines versions of dependencies
>>> that are used in our
>>> *primary* target container, all we are doing is that we limit ourselves in
>>> a choice of versions of *potential* dependencies. By importing a BoM you
>>> don't actually depend on anything - you merely predefine the versions of
>>> artifacts you might want to depend on. All it does is it makes our lives
>>> easier when composing the integrated solution together.
>>>
>>> Otherwise everything you said resonates with me. The components themselves
>>> should be first of all embeddable as a library and therefore have only an
>>> absolutely necessary number of deps.
>>>
>>> REST API then becomes a facade on top of that. If we ever want to expose
>>> the components as EJBs, those EJBs would again be facades using the
>>> library. Etc.
>>>
>>> That's how I understood the outcome of our design discussions. While it
>>> may
>>> not look like it at the moment when we want to "rush" something (barely)
>>> consumable out to public, that outcome is definitely what we want to have
>>> in the "final" picture (or at least I sincerely hope so ;) ).
>>>
>>> Of course, embeddable libraries are only a small beginning. The picture
>>> gets more interesting when you start to think about integrations between
>>> the components (i.e actually fire an alert when some value flows into
>>> metrics). I actually am not sure we cracked that architectural nut such
>>> that we all are satisfied with it. A message bus of sorts lends itself as
>>> a solution to loosely coupled communication between the components but
>>> components themselves
>>> I think should not depend on the bus by default - if for nothing else than
>>> for
>>> the "baggage" of dependencies any of the message bus solutions carry with
>>> it.>
>>>> My suggestion would be to prioritise on the component re-use. Even if
>>>> that
>>>> results in inconveniences  when building the Hawkular application:
>>>>
>>>> - Get rid of all EE6 dependencies.
>>> +1
>>>
>>>> - Stop thinking in WAR and EAR deployments.
>>> +1 for components, -1 for their REST APIs and the integrated solution
>>>
>>>> - Support reusability by strictly limiting the API dependencies.
>>> +100
>>>
>>>> - Come to an agreement about the priorities.
>>> I think the prios are clear - rush something "dirty" out now, clean up to
>>> our hearts' content right after the first version is out.
>>>
>>>> - Document and communicate the outcome of this discussion
>>> +1, we (and most of all I) need to get better at this
>>>
>>>> - Make sure all contributors understand and respect these constraints.
>>>>
>>>> Regards, Heiko B.
>>> _______________________________________________
>>> 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 Feb 23 20:23:02 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 23 Feb 2015 20:23:02 -0500 (EST)
Subject: [Hawkular-dev] kettle build
In-Reply-To: <1548878425.17433345.1424740534451.JavaMail.zimbra@redhat.com>
Message-ID: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>

<tl;dr>
1. Nest/Kettle builds now use XSLT to tweak the standalone.sh, rather than us having to maintain a full version of it in git.
2. Kettle is now in master branch - just "mvn install" in hawkular repo and you'll get it.
3. Still getting a metrics error - see below for stack trace.
</tl;dr>

I refactored the way the nest distro and the kettle distro configures the wildfly server.

For those that are unaware, the "nest" is a wildfly build that includes the bus infrastructure and the nest deployer - its a "container" that we can deploy things into (like alerts, or inventory, or even agent components in the future - its meant to be clusterable in the future with the bus being the communications conduit between nests).

The "kettle" is that nest distribution with all of our hawkular integration components deployed inside - inventory, alerts, metrics, embedded C*, the UI console, etc.

It now uses XSLT (via the xml maven plugin) to tweak the out of box wildfly standalone.xml. So we no longer have our own full standalone.xml in git - we take the one that comes with wildfly and tweak it for our needs via XSLT.

Also, the kettle is now in the hawkular repo master branch. Everything should be in the nexus snapshot repo, so if you just git clone hawkular and "mvn install", you'll get the kettle distro in hawkular/kettle/target (its a zip file - just unzip it and run standalone.sh like any other wildfly).

There is still a metrics error when you run the kettle - nothing that I did, I don't think. Here's the exception - does someone know what this is?

20:18:16,273 WARN  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016006: Could not load portable extension class org.hawkular.metrics.restServlet.EagerExtension: java.lang.ClassNotFoundException: org.hawkular.metrics.restServlet.EagerExtension from [Module "deployment.hawkular-metrics-api-jaxrs-0.3.0-20150220.180642-17.war:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
	at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:131) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:117) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]

From hrupp at redhat.com  Tue Feb 24 05:01:28 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Feb 2015 11:01:28 +0100
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
Message-ID: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>

Hey,

we need to have an endpoint that accepts a list of

<name, timestamp , value>  triples.


The current 

@POST
@Path("/{tenantId}/metrics/numeric/data")
@Consumes(APPLICATION_JSON)
public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
    List<NumericDataParams> paramsList) {

does not work (not technically).

A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
a different id.

The other similarly challenged endpoint is

@POST
@Path("/{tenantId}/metrics/numeric/{id}/data")
@Consumes(APPLICATION_JSON)
public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
    @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {

The metric id is passed on the URL-Path and thus requires a new request per metric to report.

The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
to read mass data for one single id.
Reporting use cases are different.



From miburman at redhat.com  Tue Feb 24 06:21:31 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 24 Feb 2015 13:21:31 +0200
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
In-Reply-To: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>
References: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>
Message-ID: <54EC5EBB.4040205@redhat.com>

Hi,

The only issue I had with those methods was that I can't send anymore 
availability & numeric metrics in the same request. But not that I 
couldn't send many metrics in a same request. For example, this is what 
my gather_agent sends to the endpoint:

[
   {
     "data": [
       {
         "timestamp": 1424776542007,
         "value": 11989272.0
       }
     ],
     "name": "miranda.mem.memtotal"
   },
   {
     "data": [
       {
         "timestamp": 1424776542007,
         "value": 2423852.0
       }
     ],
     "name": "miranda.mem.memfree"
   },
... and so on. In a single request. I'm posting this to the 
http://{0}:{1}/rhq-metrics/{tenant_id}/metrics/numeric/data and it works 
fine? I could send several data values of course in a single request 
also. My python-client has tests for both of these scenarios, and they 
seem to work fine?

   -  Micke


On 24.02.2015 12:01, Heiko W.Rupp wrote:
> Hey,
>
> we need to have an endpoint that accepts a list of
>
> <name, timestamp , value>  triples.
>
>
> The current
>
> @POST
> @Path("/{tenantId}/metrics/numeric/data")
> @Consumes(APPLICATION_JSON)
> public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
>      List<NumericDataParams> paramsList) {
>
> does not work (not technically).
>
> A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
> Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
> a different id.
>
> The other similarly challenged endpoint is
>
> @POST
> @Path("/{tenantId}/metrics/numeric/{id}/data")
> @Consumes(APPLICATION_JSON)
> public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
>      @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
>
> The metric id is passed on the URL-Path and thus requires a new request per metric to report.
>
> The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
> to read mass data for one single id.
> Reporting use cases are different.
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Tue Feb 24 06:30:28 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Feb 2015 12:30:28 +0100
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
In-Reply-To: <54EC5EBB.4040205@redhat.com>
References: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>
	<54EC5EBB.4040205@redhat.com>
Message-ID: <CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>

Hi,

I seem to have missed wrapping stuff like that.

But why have <id, list <time,value>> when the most basic use case is a single <id, time, value> ?
I think that way, client writing gets a lot harder than it should be.

And no, having a java-json-serialization framework does not solve it for cases when the client
is not written in java


> Am 24.02.2015 um 12:21 schrieb Michael Burman <miburman at redhat.com>:
> 
> Hi,
> 
> The only issue I had with those methods was that I can't send anymore 
> availability & numeric metrics in the same request. But not that I 
> couldn't send many metrics in a same request. For example, this is what 
> my gather_agent sends to the endpoint:
> 
> [
>   {
>     "data": [
>       {
>         "timestamp": 1424776542007,
>         "value": 11989272.0
>       }
>     ],
>     "name": "miranda.mem.memtotal"
>   },
>   {
>     "data": [
>       {
>         "timestamp": 1424776542007,
>         "value": 2423852.0
>       }
>     ],
>     "name": "miranda.mem.memfree"
>   },
> ... and so on. In a single request. I'm posting this to the 
> http://{0}:{1}/rhq-metrics/{tenant_id}/metrics/numeric/data and it works 
> fine? I could send several data values of course in a single request 
> also. My python-client has tests for both of these scenarios, and they 
> seem to work fine?
> 
>   -  Micke
> 
> 
> On 24.02.2015 12:01, Heiko W.Rupp wrote:
>> Hey,
>> 
>> we need to have an endpoint that accepts a list of
>> 
>> <name, timestamp , value>  triples.
>> 
>> 
>> The current
>> 
>> @POST
>> @Path("/{tenantId}/metrics/numeric/data")
>> @Consumes(APPLICATION_JSON)
>> public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
>>     List<NumericDataParams> paramsList) {
>> 
>> does not work (not technically).
>> 
>> A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
>> Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
>> a different id.
>> 
>> The other similarly challenged endpoint is
>> 
>> @POST
>> @Path("/{tenantId}/metrics/numeric/{id}/data")
>> @Consumes(APPLICATION_JSON)
>> public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
>>     @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
>> 
>> The metric id is passed on the URL-Path and thus requires a new request per metric to report.
>> 
>> The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
>> to read mass data for one single id.
>> Reporting use cases are different.
>> 
>> 
>> _______________________________________________
>> 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

-- 
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 jsanda at redhat.com  Tue Feb 24 07:47:22 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 24 Feb 2015 07:47:22 -0500
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
In-Reply-To: <CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>
References: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>
	<54EC5EBB.4040205@redhat.com>
	<CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>
Message-ID: <C366B97C-0781-4D10-9B0B-8AE00B325E47@redhat.com>

I mapped id to the list of values so that the id does not have to be repeated if you are reporting multiple data points for a particular metric, e.g.,

[
  {
    "name": "appsrv1.request_time",
    "data": [
      {"timestamp": 1416857688195, "value": 2.1},
      {"timestamp": 1436857688195, "value": 2.2}
    ]
  },
  {
    "name": "appsrv1.response_time",
    "data": [
      {"timestamp": 1416857688195, "value": 2.1},
      {"timestamp": 1436857688195, "value": 2.2}
    ]
  }
]

> On Feb 24, 2015, at 6:30 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Hi,
> 
> I seem to have missed wrapping stuff like that.
> 
> But why have <id, list <time,value>> when the most basic use case is a single <id, time, value> ?
> I think that way, client writing gets a lot harder than it should be.
> 
> And no, having a java-json-serialization framework does not solve it for cases when the client
> is not written in java
> 
> 
>> Am 24.02.2015 um 12:21 schrieb Michael Burman <miburman at redhat.com>:
>> 
>> Hi,
>> 
>> The only issue I had with those methods was that I can't send anymore 
>> availability & numeric metrics in the same request. But not that I 
>> couldn't send many metrics in a same request. For example, this is what 
>> my gather_agent sends to the endpoint:
>> 
>> [
>>  {
>>    "data": [
>>      {
>>        "timestamp": 1424776542007,
>>        "value": 11989272.0
>>      }
>>    ],
>>    "name": "miranda.mem.memtotal"
>>  },
>>  {
>>    "data": [
>>      {
>>        "timestamp": 1424776542007,
>>        "value": 2423852.0
>>      }
>>    ],
>>    "name": "miranda.mem.memfree"
>>  },
>> ... and so on. In a single request. I'm posting this to the 
>> http://{0}:{1}/rhq-metrics/{tenant_id}/metrics/numeric/data and it works 
>> fine? I could send several data values of course in a single request 
>> also. My python-client has tests for both of these scenarios, and they 
>> seem to work fine?
>> 
>>  -  Micke
>> 
>> 
>> On 24.02.2015 12:01, Heiko W.Rupp wrote:
>>> Hey,
>>> 
>>> we need to have an endpoint that accepts a list of
>>> 
>>> <name, timestamp , value>  triples.
>>> 
>>> 
>>> The current
>>> 
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
>>>    List<NumericDataParams> paramsList) {
>>> 
>>> does not work (not technically).
>>> 
>>> A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
>>> Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
>>> a different id.
>>> 
>>> The other similarly challenged endpoint is
>>> 
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/{id}/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
>>>    @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
>>> 
>>> The metric id is passed on the URL-Path and thus requires a new request per metric to report.
>>> 
>>> The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
>>> to read mass data for one single id.
>>> Reporting use cases are different.
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> -- 
> 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
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From miburman at redhat.com  Tue Feb 24 07:52:47 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 24 Feb 2015 14:52:47 +0200
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
In-Reply-To: <CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>
References: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>	<54EC5EBB.4040205@redhat.com>
	<CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>
Message-ID: <54EC741F.4000708@redhat.com>

Hi,

There are actually many places where I think the API is too difficult 
and requires unnecessary lists, but I'm not favoring a large list of 
endpoints as convenience methods either, I think client libraries can 
take care of that issue, even if they look a bit silly. Otherwise using 
the API becomes too difficult "now which one should I choose for this 
behaviour, which one for this.."

I actually preferred the previous one which had all the metrics posted 
to a single place, instead of now dividing availability & numeric to 
different endpoints and I have to use different HTTP call for each 
metric type. Because in the end we're not talking about huge amount of 
extra code for client libraries even in this list case while adding just 
a single datapoint. For example, in Python this is simple:

data = [ { "data": .. } ]

In Golang it wouldn't be much more difficult either:

type Metric struct {
     Name string
     Data []*Datapoint
}

type Datapoint struct {
     Timestamp int64
     Value string
}

func main() {
     dpoint := &Datapoint{Timestamp: time.Now().Unix(), Value: "up"}
     metric := &Metric{Name: "hellometric", Data: []*Datapoint{dpoint}}
..

On reading path this is a bit more work, but still. Groovy was simple 
also. So I guess Java is the one with most work ;)

   - Micke


On 24.02.2015 13:30, Heiko W.Rupp wrote:
> Hi,
>
> I seem to have missed wrapping stuff like that.
>
> But why have <id, list <time,value>> when the most basic use case is a single <id, time, value> ?
> I think that way, client writing gets a lot harder than it should be.
>
> And no, having a java-json-serialization framework does not solve it for cases when the client
> is not written in java
>
>
>> Am 24.02.2015 um 12:21 schrieb Michael Burman <miburman at redhat.com>:
>>
>> Hi,
>>
>> The only issue I had with those methods was that I can't send anymore
>> availability & numeric metrics in the same request. But not that I
>> couldn't send many metrics in a same request. For example, this is what
>> my gather_agent sends to the endpoint:
>>
>> [
>>    {
>>      "data": [
>>        {
>>          "timestamp": 1424776542007,
>>          "value": 11989272.0
>>        }
>>      ],
>>      "name": "miranda.mem.memtotal"
>>    },
>>    {
>>      "data": [
>>        {
>>          "timestamp": 1424776542007,
>>          "value": 2423852.0
>>        }
>>      ],
>>      "name": "miranda.mem.memfree"
>>    },
>> ... and so on. In a single request. I'm posting this to the
>> http://{0}:{1}/rhq-metrics/{tenant_id}/metrics/numeric/data and it works
>> fine? I could send several data values of course in a single request
>> also. My python-client has tests for both of these scenarios, and they
>> seem to work fine?
>>
>>    -  Micke
>>
>>
>> On 24.02.2015 12:01, Heiko W.Rupp wrote:
>>> Hey,
>>>
>>> we need to have an endpoint that accepts a list of
>>>
>>> <name, timestamp , value>  triples.
>>>
>>>
>>> The current
>>>
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addNumericData(@Suspended final AsyncResponse asyncResponse, @PathParam("tenantId") String tenantId,
>>>      List<NumericDataParams> paramsList) {
>>>
>>> does not work (not technically).
>>>
>>> A client (think "agent") will not send a list of dozens of metric values for one metric id. And then in a next request for another.
>>> Especially not, when an agent is monitoring 10 resources and is then reporting their data. All reported metrics will have
>>> a different id.
>>>
>>> The other similarly challenged endpoint is
>>>
>>> @POST
>>> @Path("/{tenantId}/metrics/numeric/{id}/data")
>>> @Consumes(APPLICATION_JSON)
>>> public void addDataForMetric(@Suspended final AsyncResponse asyncResponse,
>>>      @PathParam("tenantId") final String tenantId, @PathParam("id") String id, List<NumericDataPoint> dataPoints) {
>>>
>>> The metric id is passed on the URL-Path and thus requires a new request per metric to report.
>>>
>>> The above 2 endpoints may be consistent with their respective GET endpoints, but here we have the use case that I want
>>> to read mass data for one single id.
>>> Reporting use cases are different.
>>>
>>>
>>> _______________________________________________
>>> 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  Tue Feb 24 07:53:07 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 Feb 2015 13:53:07 +0100
Subject: [Hawkular-dev] Metrics reporting into hawkular-metrics
In-Reply-To: <C366B97C-0781-4D10-9B0B-8AE00B325E47@redhat.com>
References: <8747ACCD-58AA-4A8D-B31D-5E08ADBEE133@redhat.com>
	<54EC5EBB.4040205@redhat.com>
	<CA698539-B5D2-4933-915F-51D3433BE739@redhat.com>
	<C366B97C-0781-4D10-9B0B-8AE00B325E47@redhat.com>
Message-ID: <009EEC1F-20CF-4910-AD34-30155023E95D@redhat.com>


> Am 24.02.2015 um 13:47 schrieb John Sanda <jsanda at redhat.com>:
> 
> I mapped id to the list of values so that the id does not have to be repeated if you are reporting multiple data points for a particular metric, e.g.,
> 

How often does that happen? If you recall the scenarios in RHQ, the agent was polling multiple metrics of multiple resources, reporting them, rinse and repeat. With a 30sec reporting interval and often 5-20 mins metric fetch interval, the likelihood of having
the same schedule id was basically zip.

I am not saying it can't happen differently, but I am saying this is not very likely.
  
  Heiko



From mazz at redhat.com  Tue Feb 24 11:41:50 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 24 Feb 2015 11:41:50 -0500 (EST)
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <257013118.17847865.1424795944630.JavaMail.zimbra@redhat.com>
Message-ID: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>

Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT and 1.0.0.Alpha1-SNAPSHOT.

We need to come to a consensus and be consistent.  From what I understand, people prefer:

   1.0.0-SNAPSHOT

I would like to go through all our components and change their versions to be that. It would be nice to have our first distro release at least be consistent in naming of versions.

In addition, its getting annoying with having to rely on release versions of parent pom. I'm again waiting on release 8 because I added a new maven plugin to the parent. We should move every pom over to use 8-SNAPSHOT so we can keep picking up changes. We are moving fast, and its slowing us down (well, me down for one) because we now have poms that need parent pom v6 and v7 and my stuff is waiting on 8. We can release when we get some kind of product out.

There is also discussion that lucas k brought up - why not have version string for parent pom follow the same convention as everything else (that is, why not make 8-SNAPSHOT to be 1.0.0-SNAPSHOT instead?) I'll let others decide that later. I agree we should at least be consistent in version format for everything.

From ppalaga at redhat.com  Tue Feb 24 12:40:41 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 24 Feb 2015 18:40:41 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
Message-ID: <54ECB799.9080806@redhat.com>

Hi *, inline...

On 02/24/2015 05:41 PM, John Mazzitelli wrote:
> Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
> and 1.0.0.Alpha1-SNAPSHOT.
>
> We need to come to a consensus and be consistent.  From what I
> understand, people prefer:
>
> 1.0.0-SNAPSHOT
>
> I would like to go through all our components and change their
> versions to be that. It would be nice to have our first distro
> release at least be consistent in naming of versions.

Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning

> In addition, its getting annoying with having to rely on release
> versions of parent pom. I'm again waiting on release 8 because I
> added a new maven plugin to the parent.

Please do not commit your own changes to the parent. 
https://github.com/hawkular/hawkular-parent-pom#how-to-contribute

> We should move every pom over
> to use 8-SNAPSHOT so we can keep picking up changes. We are moving
> fast, and its slowing us down (well, me down for one) because we now
> have poms that need parent pom v6 and v7 and my stuff is waiting on
> 8. We can release when we get some kind of product out.

Do not do that. Introducing SNAPSHOT dependencies makes builds 
irreproducible and unreliable. You never know which revision you get 
from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least 
mazz, mtho11 and stefan_n know what I am speaking about.

> There is also discussion that lucas k brought up - why not have
> version string for parent pom follow the same convention as
> everything else (that is, why not make 8-SNAPSHOT to be
> 1.0.0-SNAPSHOT instead?)

It would be quite hard to find the criteria for deciding when to 
increase major, minor or micro in parent.
As far as the parent contained just maven plugins, there was no 
backwards compatibility in game. I admit it is quite different now that 
we manage dependencies there. But I see no way how semantic versioning 
could work with the parent either.

-- Peter

> I'll let others decide that later. I agree
> we should at least be consistent in version format for everything.
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From mazz at redhat.com  Tue Feb 24 14:01:05 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 24 Feb 2015 14:01:05 -0500 (EST)
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <54ECB799.9080806@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<54ECB799.9080806@redhat.com>
Message-ID: <366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>

> > In addition, its getting annoying with having to rely on release
> > versions of parent pom. I'm again waiting on release 8 because I
> > added a new maven plugin to the parent.
> 
> Please do not commit your own changes to the parent.
> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute

Unless I misunderstand how this is supposed to work, this would mean I not only would have to wait for someone to peer review and merge my PR, but then I also have to wait for someone to take the time and push a release, and then wait for it to get into maven central because using it. And all I added was the xml maven plugin definition to the parent pom.

The reason why we had build problems this morning is because I screwed up the kettle build - and I was easily able to fix it by just committing stuff to the bus repo's master branch - travis and nexus picked up the snapshot builds easily and we were back running because everything else was picking up snapshots. I would have slit my wrists if I had to commit to the bus repo, wait for someone to merge it, up the version number, release it, then go to the kettle repo, up the version number of the bus artifacts, create PR/merge it, and release it. People would still be waiting for a good kettle build :)

From ppalaga at redhat.com  Tue Feb 24 15:45:45 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 24 Feb 2015 21:45:45 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>	<54ECB799.9080806@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
Message-ID: <54ECE2F9.7010508@redhat.com>

On 02/24/2015 08:01 PM, John Mazzitelli wrote:
>>> In addition, its getting annoying with having to rely on release
>>> versions of parent pom. I'm again waiting on release 8 because I
>>> added a new maven plugin to the parent.
>>
>> Please do not commit your own changes to the parent.
>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>
> Unless I misunderstand how this is supposed to work, this would mean
> I not only would have to wait for someone to peer review and merge my
> PR, but then I also have to wait for someone to take the time and
> push a release, and then wait for it to get into maven central
> because using it. And all I added was the xml maven plugin definition
> to the parent pom.

No, you would not necessarily have to wait for all of that. It is only 
public durable branches that should not depend on snapshots. Everybody 
is free to depend on snapshots in his working copy and/or topic branches.

If this fast dependency propagation is so important, we should setup 
some kind of CI that will release an integrate timestamp-qualified 
artifacts daily or even more often. With that, the builds would be 
deterministic.

> The reason why we had build problems this morning is because I
> screwed up the kettle build

Sorry, I may have misinterpreted today's symptoms.
-- P

> - and I was easily able to fix it by just
> committing stuff to the bus repo's master branch - travis and nexus
> picked up the snapshot builds easily and we were back running because
> everything else was picking up snapshots. I would have slit my wrists
> if I had to commit to the bus repo, wait for someone to merge it, up
> the version number, release it, then go to the kettle repo, up the
> version number of the bus artifacts, create PR/merge it, and release
> it. People would still be waiting for a good kettle build :)
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Wed Feb 25 06:40:02 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 25 Feb 2015 12:40:02 +0100
Subject: [Hawkular-dev] kettle build
In-Reply-To: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>
References: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>
Message-ID: <54EDB492.8090505@redhat.com>

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

On 02/24/2015 02:23 AM, John Mazzitelli wrote:
> For those that are unaware, the "nest" is a wildfly build that
> includes the bus infrastructure and the nest deployer - its a
> "container" that we can deploy things into (like alerts, or
> inventory, or even agent components in the future - its meant to be
> clusterable in the future with the bus being the communications
> conduit between nests).
> 
> The "kettle" is that nest distribution with all of our hawkular
> integration components deployed inside - inventory, alerts,
> metrics, embedded C*, the UI console, etc.

I'm still confused about what is kettle and nest. By looking at the
code, kettle seems to incorporate nest, adding the other modules there
as well (alerts, inventory, ...). Thus, it sounds to me that, in order
to integrate hawkular-accounts, I'd need to work on kettle and I could
ignore nest.

If that assumption is true, then I'd need to move the data source
definition to kettle, instead of nest. Is this a problem?

Side question: is there a reason to remove the ExampleDS from
standalone.xml? As a Wildfly user, I'd expect it to be there (at least
for dev builds).

> Also, the kettle is now in the hawkular repo master branch.
> Everything should be in the nexus snapshot repo, so if you just git
> clone hawkular and "mvn install", you'll get the kettle distro in
> hawkular/kettle/target (its a zip file - just unzip it and run
> standalone.sh like any other wildfly).

Could I also add a "dir" and "tar.gz" distribution to it? For
development, I find it easier to deal with the dir (no need to extract
anything).

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

iQEcBAEBAgAGBQJU7bSSAAoJECKM1e+fkPrXTgAH/j+oyQ+yxZ7Z4Zi4NiUGtVtA
cFQFeSjMW6+18ImmLtm2ru1gus3/c3sIIqyVrm5SMQCJaIcFqdxP5uE9NJ0Kg4zM
jW2BHw/VQAx4w1tnxgc8j0rc5VS1Os+t4rg4f0kuWolTyteb2zFS9z2RPcSb9d4C
MyY55qnWZAS0t02OdVwcxiQPp2gzaChfh7DqY0IyE8dOSCrBiMXAXZe8W/xp8+99
AznCdOz5hIqoruEQ+4HeZYFuxiRFF2dWPc2renTqnCr/CklVwrw6REVc+As82Cmg
RlwcztNhFTLNJeo+XVW/A0TiR/pHN1NstyopF/vODXRAGYNOu4I1lTokNkHdqb8=
=P3DJ
-----END PGP SIGNATURE-----

From mazz at redhat.com  Wed Feb 25 08:18:24 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 25 Feb 2015 08:18:24 -0500 (EST)
Subject: [Hawkular-dev] kettle build
In-Reply-To: <54EDB492.8090505@redhat.com>
References: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>
	<54EDB492.8090505@redhat.com>
Message-ID: <27875761.18531501.1424870304610.JavaMail.zimbra@redhat.com>

> > The "kettle" is that nest distribution with all of our hawkular
> > integration components deployed inside - inventory, alerts,
> > metrics, embedded C*, the UI console, etc.
> 
> I'm still confused about what is kettle and nest. By looking at the
> code, kettle seems to incorporate nest, adding the other modules there
> as well (alerts, inventory, ...). Thus, it sounds to me that, in order
> to integrate hawkular-accounts, I'd need to work on kettle and I could
> ignore nest.


The "nest" consists of the bus infrastructure and a "nest module extension" whose main purposes today is to provide the bus infrastructure and to deploy things it finds in its deployments directory (modules/.../org/hawkular/nest/main/deployments). This WAS going to be the "agent" until it was realized it could be used for both agent-side and server-side components - so it was renamed "nest".

In the future, I have a feeling the nest functionality will expand - but for now, that's what it is.

The kettle, you are right, is nothing more than an "integration build" for lack of a better term. It takes the nest, and deploys all of the hawkular integration components into the nest deployments directory. Running the kettle server means you get all the hawkular components in one single Wildfly container.

So it depends on what you want to do. If you only want to test a single component (say, alerts for example) you can take a nest build and just shove your alerts EAR into the nest deployments location and run it and you would have a running alerts component that has access to the bus infrastructure (which consists of an API and a broker itself).

If you want to test your stuff integrated with everything else, deploy it in the kettle and watch to see how it plays nice (or not :) with the rest of hawkular.


> 
> If that assumption is true, then I'd need to move the data source
> definition to kettle, instead of nest. Is this a problem?
>


We can add custom datasources that we need for all the integration components in the kettle, yes. We have now an XSLT transformation that takes the out of box wildfly standalone.xml and tweaks it for our use. This is not a problem - its how I think it should be done. The kettle is the integration platform for everything, so I think we should be adding things that the components need in there.

If you want to build your own server-side component that runs by itself, you would create your own "kettle-like" mvn module, build on top of the nest like the kettle does, but only deploy things that you would need and only tweak standalone.xml for your component.

But for now, we are building a witch's brew of anything and everything into the one kettle. So that's probably where you want to do it.


> Side question: is there a reason to remove the ExampleDS from
> standalone.xml? As a Wildfly user, I'd expect it to be there (at least
> for dev builds).

I don't think we want something called like "ExampleDS" in our production builds (which is likely what kettle will eventually become). We provide all hawkular integration components with a datasource that they are free to use - it is called HawkularDS. That's what hawkular devs will use.

We also provide java:/HawkularBusConnectionFactory to connect to the bus infrastructure (say, for use to inject via @Resource). You can use hawkular-bus-common and hawkular-bus-mdb jars for convienent API (the nest provides this for free - so long as your WAR/EAR/Whatever has a dependency on the nest module).


> > Also, the kettle is now in the hawkular repo master branch.
> > Everything should be in the nexus snapshot repo, so if you just git
> > clone hawkular and "mvn install", you'll get the kettle distro in
> > hawkular/kettle/target (its a zip file - just unzip it and run
> > standalone.sh like any other wildfly).
> 
> Could I also add a "dir" and "tar.gz" distribution to it? For
> development, I find it easier to deal with the dir (no need to extract
> anything).

You already can have a "dir" - if by that you mean the server exploded so you don't have to unzip it. Just build the kettle with "-Pdev" and in target it will already be exploded for you and no need to extract anything. If you want to add a tar.gz assembly, feel free to do so with a pull request.

Hope that helps.

From lkrejci at redhat.com  Wed Feb 25 08:29:23 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 25 Feb 2015 14:29:23 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <54ECB799.9080806@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<54ECB799.9080806@redhat.com>
Message-ID: <1798878.cKCtblEAiz@localhost.localdomain>

On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
> Hi *, inline...
> 
> On 02/24/2015 05:41 PM, John Mazzitelli wrote:
> > Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
> > and 1.0.0.Alpha1-SNAPSHOT.
> > 
> > We need to come to a consensus and be consistent.  From what I
> > understand, people prefer:
> > 
> > 1.0.0-SNAPSHOT
> > 
> > I would like to go through all our components and change their
> > versions to be that. It would be nice to have our first distro
> > release at least be consistent in naming of versions.
> 
> Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
> CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
> 
> > In addition, its getting annoying with having to rely on release
> > versions of parent pom. I'm again waiting on release 8 because I
> > added a new maven plugin to the parent.
> 
> Please do not commit your own changes to the parent.
> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
> 
> > We should move every pom over
> > to use 8-SNAPSHOT so we can keep picking up changes. We are moving
> > fast, and its slowing us down (well, me down for one) because we now
> > have poms that need parent pom v6 and v7 and my stuff is waiting on
> > 8. We can release when we get some kind of product out.
> 
> Do not do that. Introducing SNAPSHOT dependencies makes builds
> irreproducible and unreliable. You never know which revision you get
> from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
> mazz, mtho11 and stefan_n know what I am speaking about.
>

Personally, I don't care. This early in development we don't need 
reproducibility - we just need a good build with anyone's changes as quickly 
as possible.

I am all for introducing all you propose once we stabilize just a little bit.
I fully understand that I am trading correctness for my own laziness (i.e. I 
DO NOT want to locally rebuild all of our projects N-times a day just to be 
able to use stuff people committed recently) but personally I think staying 
correctly versioned at all times at this point in time is just not worth the 
effort.

> > There is also discussion that lucas k brought up - why not have
> > version string for parent pom follow the same convention as
> > everything else (that is, why not make 8-SNAPSHOT to be
> > 1.0.0-SNAPSHOT instead?)
> 
> It would be quite hard to find the criteria for deciding when to
> increase major, minor or micro in parent.
> As far as the parent contained just maven plugins, there was no
> backwards compatibility in game. I admit it is quite different now that
> we manage dependencies there. But I see no way how semantic versioning
> could work with the parent either.
> 

I understand your reasoning about only having a major version number for 
parent. Makes sense. But if we stuck with your strict versioning policy, we'd 
end up with parent-pom version 4739 before we reached Hawkular 1.0.0.Final. 
For me, that's silly. 

Yes, with your approach we keep the build reproducible and perfectly 
semantically correct at all times and people would be able to reliably build 
even pre-alpha versions of all of our components but frankly - who does that 
and what for? Devs want the absolutely latest and greatest - not something 
outdated. Users are not interested in pre-alpha partly non-functioning mess.

For community involvement, I think -SNAPSHOTs are better this early in 
development, because if anyone wants to start with us, we can tell them just 
to use SNAPSHOTs and with high probability, the stuff will work. It might not, 
true, but it will most of the times.

It think that is better dev experience than saying: "Your deps are outdated. 
In the 2 days you were working on your PR, we've moved parent from 29 to 42, 
inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156 to 
0.2.8.TIME824, etc, etc. Please update your PR."

As you know, I am a bit of a versioning and compatibility freak myself but we 
can do all that jazz once a first (stable) version is actually out in the 
wild. Before that, we're just tying our own hands, IMHO.

> -- Peter
> 
> > I'll let others decide that later. I agree
> > we should at least be consistent in version format for everything.
> > _______________________________________________ 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  Wed Feb 25 08:30:35 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 25 Feb 2015 14:30:35 +0100
Subject: [Hawkular-dev] kettle build
In-Reply-To: <27875761.18531501.1424870304610.JavaMail.zimbra@redhat.com>
References: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>
	<54EDB492.8090505@redhat.com>
	<27875761.18531501.1424870304610.JavaMail.zimbra@redhat.com>
Message-ID: <54EDCE7B.4040503@redhat.com>

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

On 02/25/2015 02:18 PM, John Mazzitelli wrote:
> The "nest" consists of the ...
> 
> The kettle, you are right, is nothing more than an "integration
> build" ...

Alright, that clarifies it! Thanks!

> If you want to test your stuff integrated with everything else,
> deploy it in the kettle and watch to see how it plays nice (or not
> :) with the rest of hawkular.

That's probably my goal then.

> We can add custom datasources that we need for all the integration
> components in the kettle, yes. We have now an XSLT transformation
> that takes the out of box wildfly standalone.xml and tweaks it for
> our use. This is not a problem - its how I think it should be done.
> The kettle is the integration platform for everything, so I think
> we should be adding things that the components need in there.

I actually meant the HawkularDS. It seems weird that my component
needs HawkularDS and to have it defined on the "nest", even though
none of them are directly linked (ie: accounts is not aware of "nest"
and vice-versa). But I don't have strong objections about it.

> I don't think we want something called like "ExampleDS" in our
> production builds (which is likely what kettle will eventually
> become). We provide all hawkular integration components with a
> datasource that they are free to use - it is called HawkularDS.
> That's what hawkular devs will use.

Ok, so, we don't expect people to deploy their own stuff on our
production builds, right? In the end, it's not a big deal, but I was
left wondering if there's a reason to deviate from Wildfly here.

> You already can have a "dir" - if by that you mean the server
> exploded so you don't have to unzip it. Just build the kettle with
> "-Pdev" and in target it will already be exploded for you and no
> need to extract anything. If you want to add a tar.gz assembly,
> feel free to do so with a pull request.

Yes, by "dir" I meant the "dir" assembly format, as defined on the
assembly descriptor, which is what the zip looks like before it gets
zipped. I can also live with the -Pdev, but I think the "dir" and
"tar.gz" could be defined directly on the assembly descriptor instead,
if there's no reason to keep it out of there. Again, it's not a big
deal, just convenience.

About the tar.gz: I'll send a PR for it.

- - Juca.

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

iQEcBAEBAgAGBQJU7c57AAoJECKM1e+fkPrXtbkIAJf0kadHbfy4GmiizlqFN0ux
XbPUijZwCAdC0GC8PRBswe5xuPOOeZeTzjwiYaX0C+8JK8GKgvDb1li6ynbL4SoT
xt+lPuIjSNzrs5HzTRztZUczeQwCXXJNFeDoljRxslQrXpkpnBgQQGp5fF/lQXIe
WWf8SBeMXomGw5ZCBhUknvkdaa5ktHLyEqggd4SV7QBBeETOjSSSO75RzcndqdnG
SOUkuKnbCnzwdGF+RUfqf0/X8gpGWB4PmKaXVFPx0h3WkYYf50qHvluxisM+q72g
Q1Or20xA1mO/PjCGAI59m5Mn6JlBzOEDze2VEfHisnX9TUtNSsCAJjVIlRy3sSg=
=Hy82
-----END PGP SIGNATURE-----

From lkrejci at redhat.com  Wed Feb 25 08:31:56 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 25 Feb 2015 14:31:56 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <54ECE2F9.7010508@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<54ECE2F9.7010508@redhat.com>
Message-ID: <1970122.UmUf1uzBqp@localhost.localdomain>

On Tuesday, February 24, 2015 21:45:45 Peter Palaga wrote:
> On 02/24/2015 08:01 PM, John Mazzitelli wrote:
> >>> In addition, its getting annoying with having to rely on release
> >>> versions of parent pom. I'm again waiting on release 8 because I
> >>> added a new maven plugin to the parent.
> >> 
> >> Please do not commit your own changes to the parent.
> >> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
> > 
> > Unless I misunderstand how this is supposed to work, this would mean
> > I not only would have to wait for someone to peer review and merge my
> > PR, but then I also have to wait for someone to take the time and
> > push a release, and then wait for it to get into maven central
> > because using it. And all I added was the xml maven plugin definition
> > to the parent pom.
> 
> No, you would not necessarily have to wait for all of that. It is only
> public durable branches that should not depend on snapshots.

Right there! We don't have public durable branches now, IMHO ;)

> Everybody
> is free to depend on snapshots in his working copy and/or topic branches.
> 
> If this fast dependency propagation is so important, we should setup
> some kind of CI that will release an integrate timestamp-qualified
> artifacts daily or even more often. With that, the builds would be
> deterministic.
> 
> > The reason why we had build problems this morning is because I
> > screwed up the kettle build
> 
> Sorry, I may have misinterpreted today's symptoms.
> -- P
> 
> > - and I was easily able to fix it by just
> > committing stuff to the bus repo's master branch - travis and nexus
> > picked up the snapshot builds easily and we were back running because
> > everything else was picking up snapshots. I would have slit my wrists
> > if I had to commit to the bus repo, wait for someone to merge it, up
> > the version number, release it, then go to the kettle repo, up the
> > version number of the bus artifacts, create PR/merge it, and release
> > it. People would still be waiting for a good kettle build :)
> > _______________________________________________ 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  Wed Feb 25 08:53:51 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 25 Feb 2015 14:53:51 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <1798878.cKCtblEAiz@localhost.localdomain>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<54ECB799.9080806@redhat.com>
	<1798878.cKCtblEAiz@localhost.localdomain>
Message-ID: <16570352.WDReiQaQuk@localhost.localdomain>

On Wednesday, February 25, 2015 14:29:23 Lukas Krejci wrote:
> On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
> > Hi *, inline...
> > 
> > On 02/24/2015 05:41 PM, John Mazzitelli wrote:
> > > Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
> > > and 1.0.0.Alpha1-SNAPSHOT.
> > > 
> > > We need to come to a consensus and be consistent.  From what I
> > > understand, people prefer:
> > > 
> > > 1.0.0-SNAPSHOT
> > > 
> > > I would like to go through all our components and change their
> > > versions to be that. It would be nice to have our first distro
> > > release at least be consistent in naming of versions.
> > 
> > Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
> > CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
> > 
> > > In addition, its getting annoying with having to rely on release
> > > versions of parent pom. I'm again waiting on release 8 because I
> > > added a new maven plugin to the parent.
> > 
> > Please do not commit your own changes to the parent.
> > https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
> > 
> > > We should move every pom over
> > > to use 8-SNAPSHOT so we can keep picking up changes. We are moving
> > > fast, and its slowing us down (well, me down for one) because we now
> > > have poms that need parent pom v6 and v7 and my stuff is waiting on
> > > 8. We can release when we get some kind of product out.
> > 
> > Do not do that. Introducing SNAPSHOT dependencies makes builds
> > irreproducible and unreliable. You never know which revision you get
> > from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
> > mazz, mtho11 and stefan_n know what I am speaking about.
> 
> Personally, I don't care. This early in development we don't need
> reproducibility - we just need a good build with anyone's changes as quickly
> as possible.
> 

Well, I think I finally got your point. There's a difference between making a 
bugfix that others need quickly and breaking changes.

Right now, everyone is fed up with waiting on bugfixes of which there are 
many.

Now if we were as frequently changing the APIs of the components, people would 
be equally fed up with having to adapt their own stuff to the changes made in 
other components.

-SNAPSHOTs are better for bugfixes, strict versioning for API changes.

Sooo, that's what the 0.x.y versions are for, aren't they? We can depend on 
snapshots for day to day (or rather hour to hour in our case at this point 
time) bugfixes, but components would also bump their versions each time they 
make a breaking change. 0. versions are not required to remain API compatible 
in semver so the major version doesn't have to change with a breaking change.

This would work for people "waiting for a bugfix" as well as for devs needing 
to move forward with breaking changes without affecting the rest of the flock 
until they're ready to move.

WDYT?

> I am all for introducing all you propose once we stabilize just a little
> bit. I fully understand that I am trading correctness for my own laziness
> (i.e. I DO NOT want to locally rebuild all of our projects N-times a day
> just to be able to use stuff people committed recently) but personally I
> think staying correctly versioned at all times at this point in time is
> just not worth the effort.
> 
> > > There is also discussion that lucas k brought up - why not have
> > > version string for parent pom follow the same convention as
> > > everything else (that is, why not make 8-SNAPSHOT to be
> > > 1.0.0-SNAPSHOT instead?)
> > 
> > It would be quite hard to find the criteria for deciding when to
> > increase major, minor or micro in parent.
> > As far as the parent contained just maven plugins, there was no
> > backwards compatibility in game. I admit it is quite different now that
> > we manage dependencies there. But I see no way how semantic versioning
> > could work with the parent either.
> 
> I understand your reasoning about only having a major version number for
> parent. Makes sense. But if we stuck with your strict versioning policy,
> we'd end up with parent-pom version 4739 before we reached Hawkular
> 1.0.0.Final. For me, that's silly.
> 
> Yes, with your approach we keep the build reproducible and perfectly
> semantically correct at all times and people would be able to reliably build
> even pre-alpha versions of all of our components but frankly - who does
> that and what for? Devs want the absolutely latest and greatest - not
> something outdated. Users are not interested in pre-alpha partly
> non-functioning mess.
> 
> For community involvement, I think -SNAPSHOTs are better this early in
> development, because if anyone wants to start with us, we can tell them just
> to use SNAPSHOTs and with high probability, the stuff will work. It might
> not, true, but it will most of the times.
> 
> It think that is better dev experience than saying: "Your deps are outdated.
> In the 2 days you were working on your PR, we've moved parent from 29 to
> 42, inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156
> to 0.2.8.TIME824, etc, etc. Please update your PR."
> 
> As you know, I am a bit of a versioning and compatibility freak myself but
> we can do all that jazz once a first (stable) version is actually out in
> the wild. Before that, we're just tying our own hands, IMHO.
> 
> > -- Peter
> > 
> > > I'll let others decide that later. I agree
> > > we should at least be consistent in version format for everything.
> > > _______________________________________________ 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  Wed Feb 25 09:20:12 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 25 Feb 2015 09:20:12 -0500 (EST)
Subject: [Hawkular-dev] kettle build
In-Reply-To: <54EDCE7B.4040503@redhat.com>
References: <486707020.17433818.1424740982831.JavaMail.zimbra@redhat.com>
	<54EDB492.8090505@redhat.com>
	<27875761.18531501.1424870304610.JavaMail.zimbra@redhat.com>
	<54EDCE7B.4040503@redhat.com>
Message-ID: <1310768185.18576894.1424874012759.JavaMail.zimbra@redhat.com>

> > I don't think we want something called like "ExampleDS" in our
> > production builds (which is likely what kettle will eventually
> > become). We provide all hawkular integration components with a
> > datasource that they are free to use - it is called HawkularDS.
> > That's what hawkular devs will use.
> 
> Ok, so, we don't expect people to deploy their own stuff on our
> production builds, right? In the end, it's not a big deal, but I was
> left wondering if there's a reason to deviate from Wildfly here.

I think that is right. I don't think people will be deploying their own stuff into our "kettle". But even if they do (say, they wrote their own hawkular component, whatever that might be), they will have to expect to "play nice" with our integration server or "the nest" and that would mean if they want to use our datasource, they would use our HawkularDS, just as if they want to hook into our bus they would use our connection factory HawkularBusConnectionFactory. Its just part of the infrastructure the Hawkular nest/kettle provides its hosted components.

I know we don't want to ship a product with something called "ExampleDS" - that just seems "wrong" :) Its not a demo or "example" datasource - it is the hawkular datasource! :)

Now, with all that said,

1) When all is said and done, I don't even know if Hawkular will even HAVE a JDBC datasource in the end! We still haven't decided. But for now, we are giving people an embedded H2 database to use. If we switch and go to, say, Postgres, it will still be HawkularDS but just pointing to something different. Or it could completely go away. Who knows? :)

2) I don't even know if this kettle itself is going to be a final product! This was just for the MVP - a prototype to put all our stuff together and see it run. It may be the kettle is just for development purposes. Again, who knows?

In other words, we still don't know how this is going to all end up :) Once more formalized design plans are fleshed out, we'll figure things out.

But let's just roll with it and see how it ends up. As Heiko says, "Just write something" :)

From mazz at redhat.com  Wed Feb 25 11:49:37 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 25 Feb 2015 11:49:37 -0500 (EST)
Subject: [Hawkular-dev] versions to 1.0.0-SNAPSHOT
In-Reply-To: <338490610.18749839.1424882638362.JavaMail.zimbra@redhat.com>
Message-ID: <1931666746.18758597.1424882977230.JavaMail.zimbra@redhat.com>

I created pull requests in four repos so all versions (except metrics) is moved to 1.0.0-SNAPSHOT.

The pull requests are:

https://github.com/hawkular/hawkular/pull/28
https://github.com/hawkular/hawkular-bus/pull/10
https://github.com/hawkular/hawkular-inventory/pull/25
https://github.com/hawkular/hawkular-alerts/pull/18

Once we merge all these, all hawkular components will be at version 1.0.0-SNAPSHOT (again, except metrics - since they are on their own versioning stream).

Notice also I didn't touch parent-pom. I think we should move everyone to parent-pom version 8-SNAPSHOT, but that's another discussion. I did, however, make sure everyone is on the latest "7" parent pom.

I can merge all the PRs at once, unless someone has a problem with this. Speak now or forever hold your peace.

(FWIW, I built offline all these components locally and ran the kettle, and everything builds and kettle runs - so i don't think this will break anything)

From theute at redhat.com  Wed Feb 25 11:59:40 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 25 Feb 2015 17:59:40 +0100
Subject: [Hawkular-dev] versions to 1.0.0-SNAPSHOT
In-Reply-To: <1931666746.18758597.1424882977230.JavaMail.zimbra@redhat.com>
References: <1931666746.18758597.1424882977230.JavaMail.zimbra@redhat.com>
Message-ID: <54EDFF7C.4010101@redhat.com>

+1

On 02/25/2015 05:49 PM, John Mazzitelli wrote:
> I created pull requests in four repos so all versions (except metrics) is moved to 1.0.0-SNAPSHOT.
>
> The pull requests are:
>
> https://github.com/hawkular/hawkular/pull/28
> https://github.com/hawkular/hawkular-bus/pull/10
> https://github.com/hawkular/hawkular-inventory/pull/25
> https://github.com/hawkular/hawkular-alerts/pull/18
>
> Once we merge all these, all hawkular components will be at version 1.0.0-SNAPSHOT (again, except metrics - since they are on their own versioning stream).
>
> Notice also I didn't touch parent-pom. I think we should move everyone to parent-pom version 8-SNAPSHOT, but that's another discussion. I did, however, make sure everyone is on the latest "7" parent pom.
>
> I can merge all the PRs at once, unless someone has a problem with this. Speak now or forever hold your peace.
>
> (FWIW, I built offline all these components locally and ran the kettle, and everything builds and kettle runs - so i don't think this will break anything)
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hwr at pilhuhn.de  Wed Feb 25 15:04:52 2015
From: hwr at pilhuhn.de (Heiko W. Rupp)
Date: Wed, 25 Feb 2015 21:04:52 +0100
Subject: [Hawkular-dev] Forecasting of bad things
Message-ID: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>

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
Blog: http://pilhuhn.blogspot.com   @pilhuhn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150225/cf9c9dd2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2015-02-25-14-25-14.png
Type: image/png
Size: 45444 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150225/cf9c9dd2/attachment-0001.png 

From mwringe at redhat.com  Wed Feb 25 16:23:49 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Wed, 25 Feb 2015 16:23:49 -0500
Subject: [Hawkular-dev] Forecasting of bad things
In-Reply-To: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>
References: <05979609-B281-41C3-A241-87A3C9F966F6@pilhuhn.de>
Message-ID: <54EE3D65.40704@redhat.com>

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:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150225/035ae370/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 45444 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150225/035ae370/attachment-0001.png 

From lkrejci at redhat.com  Wed Feb 25 17:15:16 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 25 Feb 2015 23:15:16 +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: <3147548.ZtEKCTtQJN@localhost.localdomain>

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

On Wednesday, February 25, 2015 16:23:49 Matt Wringe wrote:
> 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:
> > 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.
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev


From ppalaga at redhat.com  Thu Feb 26 08:11:23 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 26 Feb 2015 14:11:23 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <1970122.UmUf1uzBqp@localhost.localdomain>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>	<54ECE2F9.7010508@redhat.com>
	<1970122.UmUf1uzBqp@localhost.localdomain>
Message-ID: <54EF1B7B.4090604@redhat.com>

On 02/25/2015 02:31 PM, Lukas Krejci wrote:
> On Tuesday, February 24, 2015 21:45:45 Peter Palaga wrote:
>> On 02/24/2015 08:01 PM, John Mazzitelli wrote:
>>>>> In addition, its getting annoying with having to rely on release
>>>>> versions of parent pom. I'm again waiting on release 8 because I
>>>>> added a new maven plugin to the parent.
>>>>
>>>> Please do not commit your own changes to the parent.
>>>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>>>
>>> Unless I misunderstand how this is supposed to work, this would mean
>>> I not only would have to wait for someone to peer review and merge my
>>> PR, but then I also have to wait for someone to take the time and
>>> push a release, and then wait for it to get into maven central
>>> because using it. And all I added was the xml maven plugin definition
>>> to the parent pom.
>>
>> No, you would not necessarily have to wait for all of that. It is only
>> public durable branches that should not depend on snapshots.
>
> Right there! We don't have public durable branches now, IMHO ;)

You joker :D -- P

>> Everybody
>> is free to depend on snapshots in his working copy and/or topic branches.
>>
>> If this fast dependency propagation is so important, we should setup
>> some kind of CI that will release an integrate timestamp-qualified
>> artifacts daily or even more often. With that, the builds would be
>> deterministic.
>>
>>> The reason why we had build problems this morning is because I
>>> screwed up the kettle build
>>
>> Sorry, I may have misinterpreted today's symptoms.
>> -- P
>>
>>> - and I was easily able to fix it by just
>>> committing stuff to the bus repo's master branch - travis and nexus
>>> picked up the snapshot builds easily and we were back running because
>>> everything else was picking up snapshots. I would have slit my wrists
>>> if I had to commit to the bus repo, wait for someone to merge it, up
>>> the version number, release it, then go to the kettle repo, up the
>>> version number of the bus artifacts, create PR/merge it, and release
>>> it. People would still be waiting for a good kettle build :)
>>> _______________________________________________ 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 Feb 26 08:36:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 26 Feb 2015 14:36:56 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<54ECB799.9080806@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
Message-ID: <B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>


> Am 24.02.2015 um 20:01 schrieb John Mazzitelli <mazz at redhat.com>:
> to merge it, up the version number, release it, then go to the kettle repo, up the version number of the bus artifacts, create PR/merge it, and release it. People would still be waiting for a good kettle build :)

Actually this morning (MET) Travis did not have a good build, because a not-yet-built dependency was 
introduced and hawkular/kettle was not finding it.
This seems to finally build again after kicking all the individual CI builds in correct order.

Asking that we need to be able to apply duct tape all over the mistakes we made a few minutes ago
when not following the more strict rules that could have prevent havoc in the first place, may be a flawed argument.

I like the absolute freedom to be able to just commit what I want.
On the other hand  I make mistakes and it is good that peer review and CI can catch them before they hit master.

What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on metrics-M345 and inventory-M23 ?

Also with the idea of "release early, release often" and "make small customer visible changes", master and
the PRs should not diverge too much, but will allow PR-builds to depend on a defined set of dependencies.
Today when you say "depends on bla-SNAPSHOT", you don't know what version of bla-SNAPSHOT will
be used in CI (or later even in CD ).

Instead of using Milestones (Mxxx) we can also introduce/use timestamped snapshots.

And Lukas: Now suppose you change the inventory-implementation to the future branch, which has a different REST-api, different domain objects and a few other things. Once that hits master, every other component depending on Inventory (UI , Pinger, ??) will 
fail as they just pull the new snapshot and have compile or runtime failures. With some "luck" you only see that after someone assembles the Kettle and runs it.
Here allowing the UI / Pinger to still build/run against inventory-current will help to transition them over to the new api, as the Kettle will still build and work. And only if the Pinger dev explicitly says "Now I want inventory-future and have changed my code", that breakage is prevented. And yes, I know this still requires the 3 components being introduced in lock-step, which could be prevented by content-negotiation, which we need to introduce once the existing apis have stabilized.





From lkrejci at redhat.com  Thu Feb 26 08:47:49 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 26 Feb 2015 14:47:49 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
Message-ID: <1658779.xcqm2Volon@localhost.localdomain>

On Thursday, February 26, 2015 14:36:56 Heiko W.Rupp wrote:
> > Am 24.02.2015 um 20:01 schrieb John Mazzitelli <mazz at redhat.com>:
> > to merge it, up the version number, release it, then go to the kettle
> > repo, up the version number of the bus artifacts, create PR/merge it, and
> > release it. People would still be waiting for a good kettle build :)
> Actually this morning (MET) Travis did not have a good build, because a
> not-yet-built dependency was introduced and hawkular/kettle was not finding
> it.
> This seems to finally build again after kicking all the individual CI builds
> in correct order.
> 
> Asking that we need to be able to apply duct tape all over the mistakes we
> made a few minutes ago when not following the more strict rules that could
> have prevent havoc in the first place, may be a flawed argument.
> 
> I like the absolute freedom to be able to just commit what I want.
> On the other hand  I make mistakes and it is good that peer review and CI
> can catch them before they hit master.
> 
> What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
> Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on
> metrics-M345 and inventory-M23 ?
> 
> Also with the idea of "release early, release often" and "make small
> customer visible changes", master and the PRs should not diverge too much,
> but will allow PR-builds to depend on a defined set of dependencies. Today
> when you say "depends on bla-SNAPSHOT", you don't know what version of
> bla-SNAPSHOT will be used in CI (or later even in CD ).
> 
> Instead of using Milestones (Mxxx) we can also introduce/use timestamped
> snapshots.
> 
> And Lukas: Now suppose you change the inventory-implementation to the future
> branch, which has a different REST-api, different domain objects and a few
> other things. Once that hits master, every other component depending on
> Inventory (UI , Pinger, ??) will fail as they just pull the new snapshot
> and have compile or runtime failures. With some "luck" you only see that
> after someone assembles the Kettle and runs it. Here allowing the UI /
> Pinger to still build/run against inventory-current will help to transition
> them over to the new api, as the Kettle will still build and work. And only
> if the Pinger dev explicitly says "Now I want inventory-future and have
> changed my code", that breakage is prevented. And yes, I know this still
> requires the 3 components being introduced in lock-step, which could be
> prevented by content-negotiation, which we need to introduce once the
> existing apis have stabilized.
> 

Hence my proposal to go back to 0.y.z-SNAPSHOT versioning scheme and actually 
raise the version when making a breaking change. Semver (which I think would 
be a good thing to follow) allows for 0. versions to make breaking changes, 
because they are made before the first stable release - 1.0.0.

To recap - I find it to be a real issue that people have to wait for a new 
versioned build for potentially every bugfix we make in order to "align" the 
components (and this early in dev, we are misaligned all the time because of 
the pace of development on all fronts). At the same time, you are right about 
api-breaking changes causing havoc, of course.

So to solve "my" issue, I propose using snapshot builds. To solve "your" 
issue, I propose to actually increase the version on every breaking change.

But I guess depending on timed snapshots can achieve the same goal, only IMHO 
less elegantly, because with them you don't know if a breaking change was 
introduced or not.


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


From ppalaga at redhat.com  Thu Feb 26 09:03:06 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 26 Feb 2015 15:03:06 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <16570352.WDReiQaQuk@localhost.localdomain>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>	<54ECB799.9080806@redhat.com>	<1798878.cKCtblEAiz@localhost.localdomain>
	<16570352.WDReiQaQuk@localhost.localdomain>
Message-ID: <54EF279A.20903@redhat.com>

Ahoj Luk??, first of all, thanks for your patience to explain things! 
More inline...

On 02/25/2015 02:53 PM, Lukas Krejci wrote:
> On Wednesday, February 25, 2015 14:29:23 Lukas Krejci wrote:
>> On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
>>> Hi *, inline...
>>>
>>> On 02/24/2015 05:41 PM, John Mazzitelli wrote:
>>>> Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
>>>> and 1.0.0.Alpha1-SNAPSHOT.
>>>>
>>>> We need to come to a consensus and be consistent.  From what I
>>>> understand, people prefer:
>>>>
>>>> 1.0.0-SNAPSHOT
>>>>
>>>> I would like to go through all our components and change their
>>>> versions to be that. It would be nice to have our first distro
>>>> release at least be consistent in naming of versions.
>>>
>>> Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
>>> CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
>>>
>>>> In addition, its getting annoying with having to rely on release
>>>> versions of parent pom. I'm again waiting on release 8 because I
>>>> added a new maven plugin to the parent.
>>>
>>> Please do not commit your own changes to the parent.
>>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>>>
>>>> We should move every pom over
>>>> to use 8-SNAPSHOT so we can keep picking up changes. We are moving
>>>> fast, and its slowing us down (well, me down for one) because we now
>>>> have poms that need parent pom v6 and v7 and my stuff is waiting on
>>>> 8. We can release when we get some kind of product out.
>>>
>>> Do not do that. Introducing SNAPSHOT dependencies makes builds
>>> irreproducible and unreliable. You never know which revision you get
>>> from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
>>> mazz, mtho11 and stefan_n know what I am speaking about.
>>
>> Personally, I don't care. This early in development we don't need
>> reproducibility - we just need a good build with anyone's changes as quickly
>> as possible.
>>
>
> Well, I think I finally got your point. There's a difference between making a
> bugfix that others need quickly and breaking changes.
>
> Right now, everyone is fed up with waiting on bugfixes of which there are
> many.
>
> Now if we were as frequently changing the APIs of the components, people would
> be equally fed up with having to adapt their own stuff to the changes made in
> other components.
>
> -SNAPSHOTs are better for bugfixes, strict versioning for API changes.
>
> Sooo, that's what the 0.x.y versions are for, aren't they? We can depend on
> snapshots for day to day (or rather hour to hour in our case at this point
> time) bugfixes, but components would also bump their versions each time they
> make a breaking change. 0. versions are not required to remain API compatible
> in semver so the major version doesn't have to change with a breaking change.
>
> This would work for people "waiting for a bugfix" as well as for devs needing
> to move forward with breaking changes without affecting the rest of the flock
> until they're ready to move.
>
> WDYT?
>
>> I am all for introducing all you propose once we stabilize just a little
>> bit. I fully understand that I am trading correctness for my own laziness
>> (i.e. I DO NOT want to locally rebuild all of our projects N-times a day
>> just to be able to use stuff people committed recently) but personally I
>> think staying correctly versioned at all times at this point in time is
>> just not worth the effort.
>>
>>>> There is also discussion that lucas k brought up - why not have
>>>> version string for parent pom follow the same convention as
>>>> everything else (that is, why not make 8-SNAPSHOT to be
>>>> 1.0.0-SNAPSHOT instead?)
>>>
>>> It would be quite hard to find the criteria for deciding when to
>>> increase major, minor or micro in parent.
>>> As far as the parent contained just maven plugins, there was no
>>> backwards compatibility in game. I admit it is quite different now that
>>> we manage dependencies there. But I see no way how semantic versioning
>>> could work with the parent either.
>>
>> I understand your reasoning about only having a major version number for
>> parent. Makes sense. But if we stuck with your strict versioning policy,
>> we'd end up with parent-pom version 4739 before we reached Hawkular
>> 1.0.0.Final. For me, that's silly.

No, it is probably not going to be more than tens of versions till then, 
look at JBoss Parent. Even if it was 4739, it is still shorter than 1.0.0 :)

But regardless of the above, I am open for 1.2.3 naming schema for 
parent and build tools, please just propose how we are going to decide 
when to increment at which level of the version. I am in favor of just 
major because I do not know how it could work with 1.2.3.

Depending on SNAPSHOTs is another topic.

>> Yes, with your approach we keep the build reproducible and perfectly
>> semantically correct at all times and people would be able to reliably build
>> even pre-alpha versions of all of our components but frankly - who does
>> that and what for? Devs want the absolutely latest and greatest - not
>> something outdated. Users are not interested in pre-alpha partly
>> non-functioning mess.
 >>
>> For community involvement, I think -SNAPSHOTs are better this early in
>> development, because if anyone wants to start with us, we can tell them just
>> to use SNAPSHOTs and with high probability, the stuff will work. It might
>> not, true, but it will most of the times.

It is nice to see that you see the consequences (thanks again for 
enumerating them). Anyway, "most of the time" holds for master branches 
that are up to date. As you probably see too, going back to an older 
revision in a project that has SNAPSHOT deps will be less probable to 
build the further one goes back in the history.

I always thought that reliable and deterministic builds are important 
also during early development. Say, that in a month from now, we'll have 
to compare the performance between now and then. It will be hardly 
possible to build a version from today. (Is anybody asking who the hell 
would need that?)

I can clearly see the trade-off and SNAPSHOT deps are a reality now.

-- P

>> It think that is better dev experience than saying: "Your deps are outdated.
>> In the 2 days you were working on your PR, we've moved parent from 29 to
>> 42, inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156
>> to 0.2.8.TIME824, etc, etc. Please update your PR."
 >>
>> As you know, I am a bit of a versioning and compatibility freak myself but
>> we can do all that jazz once a first (stable) version is actually out in
>> the wild. Before that, we're just tying our own hands, IMHO.
>>
>>> -- Peter
>>>
>>>> I'll let others decide that later. I agree
>>>> we should at least be consistent in version format for everything.
>>>> _______________________________________________ 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 mazz at redhat.com  Thu Feb 26 09:43:29 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 Feb 2015 09:43:29 -0500 (EST)
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <1658779.xcqm2Volon@localhost.localdomain>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
	<1658779.xcqm2Volon@localhost.localdomain>
Message-ID: <1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>

> Hence my proposal to go back to 0.y.z-SNAPSHOT versioning scheme and actually
> raise the version when making a breaking change.

That's exactly how it should be done. SNAPSHOTSs until we hit breaking changes, then releases.

Of course, in our current stage of development, isn't everything a breaking change? :) Can you imagine what Jay and Heiko would have had to go through yesterday if they had to bump up version numbers to their maven modules and push a "release" for everything they did while trying to get that metric data JSON to flow correctly between their pinger and alerts components (and I think it involved inventory)? It would have been unbearable and useless.

Here's another example, and why I have a problem using release versions always - this is just to give another actual instance that happened. Yesterday, Libor published for me some enhancements and fixes to his nice Wildfly extension maven plugin. I bumped up the plugin version in the parent pom so I can use it. I didn't realize snapshots of the parent pom weren't yet published. So I completely foo-bared the builds. I was supposed to have created a PR to the parent pom, waited for that PR to be peer-reviewed and merged to master, waited for someone to bump up the parent-pom version number, do a mvn release on the parent pom, and once it was published, only then could I have gone back to my own pom, bump up its parent-pom version, THEN use Libor's new maven features.

All to be able to use a new version of a maven plugin.

Surely, that can't be what we want people to go through for such a trivial change.

Now, if some API changes (say, someone wants to bump up a <dependency> in parent pom to a new major or major.minor version that changes to incompatible API changes, OR someone changes a maven plugin to a version that isn't compatible with older versions) then ABSOLUTELY we need to go through that new version/release cycle for reasons that were brought up earlier.

But not for trivial changes that don't have such effects. That's where SNAPSHOT helps us move fast.

As for Travis, that's another issue :)

From hrupp at redhat.com  Thu Feb 26 09:47:43 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 26 Feb 2015 15:47:43 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
	<1658779.xcqm2Volon@localhost.localdomain>
	<1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>
Message-ID: <B811EAF4-9891-4B43-B39D-3F42E552415C@redhat.com>


> Am 26.02.2015 um 15:43 schrieb John Mazzitelli <mazz at redhat.com>:
> All to be able to use a new version of a maven plugin.

You could have used that new version in the kettle pom (where this plugin is actually needed?) and only release
this now. Then have the version added to the root-pom and when this is available removed in kettle.



From mazz at redhat.com  Thu Feb 26 09:54:04 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 Feb 2015 09:54:04 -0500 (EST)
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <B811EAF4-9891-4B43-B39D-3F42E552415C@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
	<1658779.xcqm2Volon@localhost.localdomain>
	<1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>
	<B811EAF4-9891-4B43-B39D-3F42E552415C@redhat.com>
Message-ID: <615438059.19417218.1424962444464.JavaMail.zimbra@redhat.com>

> You could have used that new version in the kettle pom (where this plugin is
> actually needed?) and only release
> this now. Then have the version added to the root-pom and when this is
> available removed in kettle.

It was actually in the nest distro module, not kettle.

But that is what I ended up doing! But you realize that now you are asking people to have to remember to go back and remove code when a release is available (where this code was just a temporary fix that I had to add to work around this annoying workflow - so you just made it more annoying to have to remember to go back and take out code I didn't want to add in the first place :). And will I remember to do that once the release is made??

And BTW it's against "convention" to use <versions> in our poms, no? We shouldn't be overriding <versions> - we should be just referring to <artifactId> and letting the parent pom decide what versions to use so we all use the same versions.

In any event, yes, that is what I ended up doing. Which reminds me, I don't think I did remove my temporary <version> fix - I think I need to go do that :)

From theute at redhat.com  Thu Feb 26 10:06:31 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 26 Feb 2015 16:06:31 +0100
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <615438059.19417218.1424962444464.JavaMail.zimbra@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>	<1658779.xcqm2Volon@localhost.localdomain>	<1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>	<B811EAF4-9891-4B43-B39D-3F42E552415C@redhat.com>
	<615438059.19417218.1424962444464.JavaMail.zimbra@redhat.com>
Message-ID: <54EF3677.4070505@redhat.com>


On 02/26/2015 03:54 PM, John Mazzitelli wrote:
>> You could have used that new version in the kettle pom (where this plugin is
>> actually needed?) and only release
>> this now. Then have the version added to the root-pom and when this is
>> available removed in kettle.
> It was actually in the nest distro module, not kettle.
>
> But that is what I ended up doing! But you realize that now you are asking people to have to remember to go back and remove code when a release is available (where this code was just a temporary fix that I had to add to work around this annoying workflow - so you just made it more annoying to have to remember to go back and take out code I didn't want to add in the first place :). And will I remember to do that once the release is made??
>
> And BTW it's against "convention" to use <versions> in our poms, no?
No, put them at the most top level of your project.
> We shouldn't be overriding <versions> - we should be just referring to <artifactId> and letting the parent pom decide what versions to use so we all use the same versions.
>
> In any event, yes, that is what I ended up doing. Which reminds me, I don't think I did remove my temporary <version> fix - I think I need to go do that :)
Don't put all versions in the POM/BOM for reasons I already explained a 
couple of times ;)

Thomas

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


From mazz at redhat.com  Thu Feb 26 10:12:59 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 Feb 2015 10:12:59 -0500 (EST)
Subject: [Hawkular-dev] maven stuff
In-Reply-To: <54EF3677.4070505@redhat.com>
References: <728852422.17849087.1424796110021.JavaMail.zimbra@redhat.com>
	<366874538.18036477.1424804465494.JavaMail.zimbra@redhat.com>
	<B94C54D0-AEFA-406C-AE6E-D551CF198EEE@redhat.com>
	<1658779.xcqm2Volon@localhost.localdomain>
	<1843506631.19405478.1424961809394.JavaMail.zimbra@redhat.com>
	<B811EAF4-9891-4B43-B39D-3F42E552415C@redhat.com>
	<615438059.19417218.1424962444464.JavaMail.zimbra@redhat.com>
	<54EF3677.4070505@redhat.com>
Message-ID: <850333973.19469691.1424963579142.JavaMail.zimbra@redhat.com>

> Don't put all versions in the POM/BOM for reasons I already explained a
> couple of times ;)

(just so I am clear, this isn't a BOM that people are importing - this is discussing the parent POM to our components).

But if we don't have a common parent pom, we can't ensure everyone uses the same version of dependencies and plugins (which is why Peter created the parent pom in the first place). Otherwise, it will end up some modules will be using version "1" but others using version "2" others version "3", etc. and then things get all out of sync as time moves forward and everyone wants to use their own versions and don't coordinate with everyone else.

We need a parent pom to ensure we all are on the same page and our builds all use the same dependencies/plugins across components (ESPECIALLY if we are to have an MVP where everything runs inside a single container (kettle)). 

From mazz at redhat.com  Thu Feb 26 14:47:06 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 Feb 2015 14:47:06 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <1155401677.19635484.1424979480600.JavaMail.zimbra@redhat.com>
Message-ID: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>

There is this really nice maven plugin that takes JSON schema and generates Java POJOs annotated with GSON annotations. I took this stuff and created a sample module in the bus repo and see how it works. It works very nicely and I think we can use this very easily in our stuff.

First, here is a site that discusses JSON schema if you aren't familiar (its essentially like XML Schema only for JSON):

http://json-schema.org/documentation.html

We can use this maven plugin to generate an API that our Java components can use to talk to each other. To see what the generated code looks like with any JSON schema, here's a play area where you can see it in realtime:

http://www.jsonschema2pojo.org/

Here's what my sample JSON schema looks like (you'll see it uses primitives as well as sets/lists and embedded types (see address type) and a set of embedded types (see phoneNumbers):

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/src/main/resources/schema/Person.jsonschema

Here is where my test code creates the message via the POJO API that was generated by the maven plugin:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/src/main/java/org/hawkular/bus/sample/client/Main.java#L84

If we use this stuff, we write the JSON schema which automatically provides documentation that non-Java clients can use to know what the clients need to send/consume, or they can use the schema themselves to generate their own client code. We use the schema internally to generate Java POJOs that we then use in our Java components (like what my sample code demonstrates).

Here is what the maven plugin usage looks like - its pretty simple:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/pom.xml#L48


From miburman at redhat.com  Thu Feb 26 16:16:00 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 26 Feb 2015 16:16:00 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
Message-ID: <859576494.28904739.1424985360674.JavaMail.zimbra@redhat.com>

Hi,

I'm all for strong typing the stuff we send out and receive. As for automatic generation, same can be applied by the swagger-codegen, which generates from our documented swagger-annotations the client-code. So it works in a  reversed way, from our Java-code to JSON, like the following:

    "MetricParams" : {
      "id" : "MetricParams",
      "description" : "Metric definition model",
      "properties" : {
        "name" : {
          "type" : "string"
        },
        "tags" : {
          "$ref" : "Map[string,string]"
        },
        "dataRetention" : {
          "type" : "integer",
          "format" : "int32",
          "description" : "Overrides the data retention setting at the tenant level"
        }
      }
    },

And swagger-codegen understands that.

  - Micke

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Thursday, 26 February, 2015 9:47:06 PM
Subject: [Hawkular-dev] generation of message POJOs via JSON schema

There is this really nice maven plugin that takes JSON schema and generates Java POJOs annotated with GSON annotations. I took this stuff and created a sample module in the bus repo and see how it works. It works very nicely and I think we can use this very easily in our stuff.

First, here is a site that discusses JSON schema if you aren't familiar (its essentially like XML Schema only for JSON):

http://json-schema.org/documentation.html

We can use this maven plugin to generate an API that our Java components can use to talk to each other. To see what the generated code looks like with any JSON schema, here's a play area where you can see it in realtime:

http://www.jsonschema2pojo.org/

Here's what my sample JSON schema looks like (you'll see it uses primitives as well as sets/lists and embedded types (see address type) and a set of embedded types (see phoneNumbers):

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/src/main/resources/schema/Person.jsonschema

Here is where my test code creates the message via the POJO API that was generated by the maven plugin:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/src/main/java/org/hawkular/bus/sample/client/Main.java#L84

If we use this stuff, we write the JSON schema which automatically provides documentation that non-Java clients can use to know what the clients need to send/consume, or they can use the schema themselves to generate their own client code. We use the schema internally to generate Java POJOs that we then use in our Java components (like what my sample code demonstrates).

Here is what the maven plugin usage looks like - its pretty simple:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples/hawkular-bus-sample-jsonschema/pom.xml#L48

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

From mazz at redhat.com  Thu Feb 26 16:35:52 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 Feb 2015 16:35:52 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
Message-ID: <2081603888.19682454.1424986552577.JavaMail.zimbra@redhat.com>

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.

From gbrown at redhat.com  Fri Feb 27 10:58:49 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 Feb 2015 10:58:49 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1155104078.19673502.1425051921908.JavaMail.zimbra@redhat.com>
Message-ID: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>

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?

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?

Regards
Gary

From lponce at redhat.com  Fri Feb 27 11:19:41 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 27 Feb 2015 11:19:41 -0500 (EST)
Subject: [Hawkular-dev] Notification messages
In-Reply-To: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
References: <1178155326.19681631.1425052729284.JavaMail.zimbra@redhat.com>
Message-ID: <1658550572.20272801.1425053981703.JavaMail.zimbra@redhat.com>

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  Fri Feb 27 11:28:25 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 Feb 2015 11:28:25 -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: <964814044.19704276.1425054505552.JavaMail.zimbra@redhat.com>

Ok thanks - I'll take a look and get back to you with any questions.

Have a good weekend.

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 snegrea at redhat.com  Fri Feb 27 13:28:25 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Fri, 27 Feb 2015 13:28:25 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <2081603888.19682454.1424986552577.JavaMail.zimbra@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
	<2081603888.19682454.1424986552577.JavaMail.zimbra@redhat.com>
Message-ID: <800729833.17117898.1425061705131.JavaMail.zimbra@redhat.com>

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
> 

From jshaughn at redhat.com  Fri Feb 27 13:46:05 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 27 Feb 2015 13:46:05 -0500
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: <54F0BB6D.2080804@redhat.com>



On 2/27/2015 1:28 PM, Stefan Negrea wrote:
> <clip>
>
> 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

No doubt the bus should be (and is) dumb plumbing.  What we are talking 
about are the apps using the bus, and what makes it easy for them to 
provide and consume messages.  It seems like we could do a little better 
than reading docs, screwing up, and retrying, at least for Java 
clients.  I would happily incorporate a Gson-ready pojo guaranteed to 
parse out the Json dropped on HawkularMetricsData topic.  I don't really 
care which client jar I need to get it, whether it was a kettle client 
jar or a metrics client jar.


From jsanda at redhat.com  Fri Feb 27 13:54:50 2015
From: jsanda at redhat.com (John Sanda)
Date: Fri, 27 Feb 2015 13:54:50 -0500
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: <2D39138B-A5AD-4162-8E2E-59379E7BECE4@redhat.com>

I also like the idea of using schema for documentation. I agree with Stefan that the individual subprojects/services should own the schemas if we want them to loosely coupled and be able to version them independently.

With respect to documentation, I think good API tests are really important, at least for developer docs. Tests that are expressive and self-documenting can be a form of executable documentation.

I came across an articular which said that Heroku has schema endpoints. With metrics for example, we might have a GET /hawkular/metrics/numeric/data/schema endpoint which returns the schema for the /hawkular/metrics/numeric/data endpoint. This might be pretty useful.

> On Feb 27, 2015, at 1:28 PM, Stefan Negrea <snegrea at redhat.com> wrote:
> 
> 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 mazz at redhat.com  Fri Feb 27 14:54:46 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 27 Feb 2015 14:54:46 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <2D39138B-A5AD-4162-8E2E-59379E7BECE4@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
	<2081603888.19682454.1424986552577.JavaMail.zimbra@redhat.com>
	<800729833.17117898.1425061705131.JavaMail.zimbra@redhat.com>
	<2D39138B-A5AD-4162-8E2E-59379E7BECE4@redhat.com>
Message-ID: <2098621835.20426540.1425066886651.JavaMail.zimbra@redhat.com>

I found writing the schema and generating the code to be fairly painless. But I'll look into the swagger stuff - does anyone have links for examples on how to use its maven plugin to take code and generate json schema from it? What annotations does it use?

----- Original Message -----
> I also like the idea of using schema for documentation. I agree with Stefan
> that the individual subprojects/services should own the schemas if we want
> them to loosely coupled and be able to version them independently.
> 
> With respect to documentation, I think good API tests are really important,
> at least for developer docs. Tests that are expressive and self-documenting
> can be a form of executable documentation.
> 
> I came across an articular which said that Heroku has schema endpoints. With
> metrics for example, we might have a GET
> /hawkular/metrics/numeric/data/schema endpoint which returns the schema for
> the /hawkular/metrics/numeric/data endpoint. This might be pretty useful.
> 
> > On Feb 27, 2015, at 1:28 PM, Stefan Negrea <snegrea at redhat.com> wrote:
> > 
> > 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 lkrejci at redhat.com  Fri Feb 27 16:40:10 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 27 Feb 2015 22:40:10 +0100
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <54F0BB6D.2080804@redhat.com>
References: <577163058.19644049.1424980026443.JavaMail.zimbra@redhat.com>
	<800729833.17117898.1425061705131.JavaMail.zimbra@redhat.com>
	<54F0BB6D.2080804@redhat.com>
Message-ID: <6670649.udP87ijNDa@localhost.localdomain>

On Friday, February 27, 2015 13:46:05 Jay Shaughnessy wrote:
> On 2/27/2015 1:28 PM, Stefan Negrea wrote:
> > <clip>
> > 
> > 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#SmartEndpointsAndDumb
> > Pipes
> No doubt the bus should be (and is) dumb plumbing.  What we are talking
> about are the apps using the bus, and what makes it easy for them to
> provide and consume messages.  It seems like we could do a little better
> than reading docs, screwing up, and retrying, at least for Java
> clients. 

+100

The schema, after all is a sort of documentation. If it is "functionally" tied 
with the implementation itself (i.e. one generated from the other) then it 
also never gets out of sync, unlike the written documentation.

> I would happily incorporate a Gson-ready pojo guaranteed to
> parse out the Json dropped on HawkularMetricsData topic.  I don't really
> care which client jar I need to get it, whether it was a kettle client
> jar or a metrics client jar.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From miburman at redhat.com  Sat Feb 28 08:12:25 2015
From: miburman at redhat.com (Michael Burman)
Date: Sat, 28 Feb 2015 08:12:25 -0500 (EST)
Subject: [Hawkular-dev] generation of message POJOs via JSON schema
In-Reply-To: <2098621835.20426540.1425066886651.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>
	<2D39138B-A5AD-4162-8E2E-59379E7BECE4@redhat.com>
	<2098621835.20426540.1425066886651.JavaMail.zimbra@redhat.com>
Message-ID: <2034010922.29922329.1425129145828.JavaMail.zimbra@redhat.com>

Hi,

My implemention for hawkular-metrics is waiting in:

https://github.com/hawkular/hawkular-metrics/pull/158

mvn compile -Pdocgen does the job (creates json-files to the generated/ directory as well as transforms from json to asciidoc with mustache).

  - Micke

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Friday, 27 February, 2015 9:54:46 PM
Subject: Re: [Hawkular-dev] generation of message POJOs via JSON schema

I found writing the schema and generating the code to be fairly painless. But I'll look into the swagger stuff - does anyone have links for examples on how to use its maven plugin to take code and generate json schema from it? What annotations does it use?

----- Original Message -----
> I also like the idea of using schema for documentation. I agree with Stefan
> that the individual subprojects/services should own the schemas if we want
> them to loosely coupled and be able to version them independently.
> 
> With respect to documentation, I think good API tests are really important,
> at least for developer docs. Tests that are expressive and self-documenting
> can be a form of executable documentation.
> 
> I came across an articular which said that Heroku has schema endpoints. With
> metrics for example, we might have a GET
> /hawkular/metrics/numeric/data/schema endpoint which returns the schema for
> the /hawkular/metrics/numeric/data endpoint. This might be pretty useful.
> 
> > On Feb 27, 2015, at 1:28 PM, Stefan Negrea <snegrea at redhat.com> wrote:
> > 
> > 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
> 
> 
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev