From gcardoso at redhat.com  Wed Jul  1 11:37:03 2015
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 1 Jul 2015 17:37:03 +0200
Subject: [Hawkular-dev] Apps list search
In-Reply-To: <5592C53D.6000401@redhat.com>
References: <16F1F8C9-1F63-42AF-88A8-3B683267FAB8@redhat.com>
	<2278420.AeTsadHi21@localhost.localdomain>
	<5592C53D.6000401@redhat.com>
Message-ID: <403340DE-939A-478A-B1B1-4B44DF026572@redhat.com>

Updated a JIRA with screenshots on how the search would look like.

Please comment at the JIRA: https://issues.jboss.org/browse/HAWKULAR-127 <https://issues.jboss.org/browse/HAWKULAR-127>

Thank you,
Gabriel


> On Jun 30, 2015, at 6:35 PM, Thomas Heute <theute at redhat.com> wrote:
> 
> For now we are looking for relatively simple filtering (rather than search).
> 
> On the app server list, I guess we would want to filter on status AND 
> hostname.
> 
> For instance, I may want to filter the whole list for all servers on 
> *.corp.redhat.com that are DOWN OR UNKNOWN
> 
> If we allow for a user "query language" should be easy to understand by 
> non hardcore developers, like in JIRA.
> 
> Thomas
> 
> On 06/30/2015 05:43 PM, Lukas Krejci wrote:
>> What kind of query language are we going to support here? How will it
>> represent (if at all) the graph nature of inventory entities (e.g. gimme all
>> resources of type EAP in the "test" environment which relate to data source DS
>> by relationship "uses")?
>> 
>> On Tuesday, June 30, 2015 16:34:55 Gabriel Cardoso wrote:
>>> Hello,
>>> 
>>> I was assigned to design the search/filter component for the applications
>>> list and would like to bring some questions. I already got some
>>> requirements from Liz/Thomas.
>>> 
>>> My proposal would be to present a behaviour similar to what JIRA does. They
>>> have ?dropdown? selectors to allow filtering + a search box (initially).
>>> 
>>> 
>>> 
>>> For our context, the dropdowns would be to filter State (Up, Down etc.) and
>>> Type (EAP, Wildfly etc.). We probably don?t need the find input in the
>>> beginning, when we have not many options.
>>> Thomas brought this comment:
>>>> The input text should still be editable to do more filtering such as:
>>>> "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com
>>>> <http://corp.redhat.com/>' " (To show all servers on *.corp.redhat.com
>>>> <http://corp.redhat.com/> that are down or unknown)
>>> JIRA also covers that, when clicking on Advanced, the dropdowns are hidden
>>> and everything goes inside the search input:
>>> 
>>> 
>>> 
>>> I like this approach because we offer something user-friendly and at the
>>> same time provide something more powerful for advanced users.
>>> 
>>> I would like to hear your feedback.
>>> @Inventory team, from what was presented, it is feasible to be implemented?
>>> 
>>> Thanks,
>>> Gabriel
>>> 
>>> Gabriel Cardoso
>>> UX designer @ Red Hat
>> 
>> 
>> _______________________________________________
>> 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

Gabriel Cardoso
UX designer @ Red Hat



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

From gcardoso at redhat.com  Wed Jul  1 13:28:07 2015
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Wed, 1 Jul 2015 19:28:07 +0200
Subject: [Hawkular-dev] Hawkular for Android
Message-ID: <191B6AFD-BB2C-486E-B7DD-3F5D05053287@redhat.com>

Hello,

Since we have an intern working on the Android version for Hawkular, it would be positive for the UXD team to sync with him and see how he is structuring the application.

Who is supervising his work? 

Thanks,
Gabriel

Gabriel Cardoso
UX designer @ Red Hat





From jshaughn at redhat.com  Wed Jul  1 13:51:48 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 1 Jul 2015 13:51:48 -0400
Subject: [Hawkular-dev] A Nice Overview of the Monitoring Landscape Scene
In-Reply-To: <F490E853-DC6C-4AA7-8DE9-EC9382CA8605@redhat.com>
References: <F490E853-DC6C-4AA7-8DE9-EC9382CA8605@redhat.com>
Message-ID: <559428B4.2060402@redhat.com>


And RHQ doesn't make the list :(

On 6/21/2015 9:37 PM, mike thompson wrote:
> This is a pretty complete overview of the Monitoring Landscape Tools:
> including:
>
>   * System Monitoring
>   * Time Series
>   * Event Processing
>   * Web Monitoring
>   * APM
>   * Log Management
>   * etc...
>
>
> https://bigpanda.io/monitoringscape/
>
> Should be good for some ideas ;)
>
> ? Mike
>
>
>
> _______________________________________________
> 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/20150701/d3242b99/attachment.html 

From hrupp at redhat.com  Wed Jul  1 14:19:18 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 01 Jul 2015 20:19:18 +0200
Subject: [Hawkular-dev] Hawkular for Android
In-Reply-To: <191B6AFD-BB2C-486E-B7DD-3F5D05053287@redhat.com>
References: <191B6AFD-BB2C-486E-B7DD-3F5D05053287@redhat.com>
Message-ID: <4BEFDAC6-643B-4368-91B0-53C6E043C3E1@redhat.com>

On 1 Jul 2015, at 19:28, Gabriel Cardoso wrote:
> Since we have an intern working on the Android version for Hawkular,

Arthur is a GSoC student doing his work with us and the Aerogear
team on a mobile client for Hawkular.
The source repository is here: 
https://github.com/hawkular/hawkular-android-client

> it would be positive for the UXD team to sync with him and see how he 
> is structuring the application.

This certainly would be very good.

> Who is supervising his work?

I am his Mentor from our side together
with Daniel Passos from Aerogear.
As this is an open source community project, everyone
can chime in when Arthur sends pull-requests, often
with screen shots.
Or do translations - e.g. to Portuguese, French, Czech and Spanish :)

Due to a change in the inventory api for Hawkular master,
the client does not work right now, but I am sure Arthur will
fix that soon.

   Heiko

From theute at redhat.com  Wed Jul  1 14:39:42 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 1 Jul 2015 20:39:42 +0200
Subject: [Hawkular-dev] Hawkular for Android
In-Reply-To: <4BEFDAC6-643B-4368-91B0-53C6E043C3E1@redhat.com>
References: <191B6AFD-BB2C-486E-B7DD-3F5D05053287@redhat.com>
	<4BEFDAC6-643B-4368-91B0-53C6E043C3E1@redhat.com>
Message-ID: <559433EE.2040509@redhat.com>



On 07/01/2015 08:19 PM, Heiko W.Rupp wrote:
> On 1 Jul 2015, at 19:28, Gabriel Cardoso wrote:
>> Since we have an intern working on the Android version for Hawkular,
>
> Arthur is a GSoC student doing his work with us and the Aerogear
> team on a mobile client for Hawkular.
> The source repository is here:
> https://github.com/hawkular/hawkular-android-client
>
>> it would be positive for the UXD team to sync with him and see how he
>> is structuring the application.
>
> This certainly would be very good.
>
>> Who is supervising his work?
>
> I am his Mentor from our side together
> with Daniel Passos from Aerogear.
> As this is an open source community project, everyone
> can chime in when Arthur sends pull-requests, often
> with screen shots.
> Or do translations - e.g. to Portuguese, French, Czech and Spanish :)
>
> Due to a change in the inventory api for Hawkular master,
> the client does not work right now, but I am sure Arthur will
> fix that soon.
>

If fixed by tomorrow, I am planning to demo it ;)
https://plus.google.com/b/100667078659222571663/events/cg6ni8apaq0j25vr1pb1jqki5ks

Thomas

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

From artur.dryomov at gmail.com  Wed Jul  1 16:51:45 2015
From: artur.dryomov at gmail.com (Artur Dryomov)
Date: Wed, 1 Jul 2015 23:51:45 +0300
Subject: [Hawkular-dev] Hawkular for Android
In-Reply-To: <559433EE.2040509@redhat.com>
References: <191B6AFD-BB2C-486E-B7DD-3F5D05053287@redhat.com>
	<4BEFDAC6-643B-4368-91B0-53C6E043C3E1@redhat.com>
	<559433EE.2040509@redhat.com>
Message-ID: <CAC6O=UW4q3c_px8AArAy4_fZrRAFY25oti+gE5B0t5+Uo6vJRA@mail.gmail.com>

Hey everyone,

I would like to point eyes to the Wiki section of the GitHub project [1].
It has some design thingies, including a mockup and current screenshots.
There is an instruction to run the server as well. The application works
just fine with the 1.0.0 Alpha 1 release of Hawkular. The relevant wiki
page describes it and the authorization screen of the application points at
it as well.

Artur.

[1]: https://github.com/hawkular/hawkular-android-client/wiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150701/58e5c0e2/attachment.html 

From hrupp at redhat.com  Thu Jul  2 03:13:17 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 02 Jul 2015 09:13:17 +0200
Subject: [Hawkular-dev] Master "open" again
Message-ID: <AF8C60F5-71B3-4117-9C6C-F2B957FAEEB6@redhat.com>

Hey,
alpha2 has been tagged, so post alpha2-changes can go in master now.
Remember to keep master in a releasable state nevertheless

 Heiko

From gbrown at redhat.com  Thu Jul  2 03:45:08 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 2 Jul 2015 03:45:08 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular-BTM 0.1.0.Final Released
In-Reply-To: <890075257.24919530.1435822835171.JavaMail.zimbra@redhat.com>
Message-ID: <1771713988.24923648.1435823108237.JavaMail.zimbra@redhat.com>

I am happy to announce release 0.1.0 of the Hawkular Business Transaction Management project. The main focus for this release has been on capturing as much structural information about a business transaction as possible, with the minimum of configuration on the part of the user.

Highlights of this release:

    * Definition of the Business Transaction model for exchanging trace fragments related to business transaction execution across multiple systems/environments

    * Basic in-memory REST service for reporting and querying business transaction fragments (REST API documentation)

    * Integration with Hawkular Accounts, to provide authorization and authentication

    * Embedded business transaction collector (agent), leveraging ByteMan to instrument technologies of interest

    * Provide instrumentation rule model and translation to ByteMan rules (text based)

    * Instrumentation agent tested in:

        Java standalone app (e.g. micro services)

        Wildfly

        Apache Tomcat

        Apache Karaf OSGi Container

    * Initial instrumentation rules for:

        Camel core

        HTTP clients (apache httpclient, java HttpURLConnection, RESTEasy JAX-RS client)

        JMS

        Servlet

        Restlet

        JDBC

        SwitchYard

Only basic information for each of these technologies is currently recorded, so future releases will enhance these rules, as well as add rules for other relevant technologies. If you have particular technologies you are interested in instrumenting, then please raise a feature request in our jira.

Download the release from here: https://github.com/hawkular/hawkular-btm/releases

Documentation can be found here: http://www.hawkular.org/docs/components/btm/index.html

The detailed release notes can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12316120&version=12327163

Feature requests and bugs should be reported in our project jira: https://issues.jboss.org/browse/HWKBTM

Thanks to Juraci Paix?o Kr?hling for his help on integrating with Hawkular Accounts and Peter Palaga for his help with the release.


From theute at redhat.com  Thu Jul  2 03:52:30 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 2 Jul 2015 09:52:30 +0200
Subject: [Hawkular-dev] Hawkular-BTM 0.1.0.Final Released
In-Reply-To: <1771713988.24923648.1435823108237.JavaMail.zimbra@redhat.com>
References: <1771713988.24923648.1435823108237.JavaMail.zimbra@redhat.com>
Message-ID: <5594EDBE.3070005@redhat.com>

Congrats !

On 07/02/2015 09:45 AM, Gary Brown wrote:
> I am happy to announce release 0.1.0 of the Hawkular Business Transaction Management project. The main focus for this release has been on capturing as much structural information about a business transaction as possible, with the minimum of configuration on the part of the user.
>
> Highlights of this release:
>
>      * Definition of the Business Transaction model for exchanging trace fragments related to business transaction execution across multiple systems/environments
>
>      * Basic in-memory REST service for reporting and querying business transaction fragments (REST API documentation)
>
>      * Integration with Hawkular Accounts, to provide authorization and authentication
>
>      * Embedded business transaction collector (agent), leveraging ByteMan to instrument technologies of interest
>
>      * Provide instrumentation rule model and translation to ByteMan rules (text based)
>
>      * Instrumentation agent tested in:
>
>          Java standalone app (e.g. micro services)
>
>          Wildfly
>
>          Apache Tomcat
>
>          Apache Karaf OSGi Container
>
>      * Initial instrumentation rules for:
>
>          Camel core
>
>          HTTP clients (apache httpclient, java HttpURLConnection, RESTEasy JAX-RS client)
>
>          JMS
>
>          Servlet
>
>          Restlet
>
>          JDBC
>
>          SwitchYard
>
> Only basic information for each of these technologies is currently recorded, so future releases will enhance these rules, as well as add rules for other relevant technologies. If you have particular technologies you are interested in instrumenting, then please raise a feature request in our jira.
>
> Download the release from here: https://github.com/hawkular/hawkular-btm/releases
>
> Documentation can be found here: http://www.hawkular.org/docs/components/btm/index.html
>
> The detailed release notes can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12316120&version=12327163
>
> Feature requests and bugs should be reported in our project jira: https://issues.jboss.org/browse/HWKBTM
>
> Thanks to Juraci Paix?o Kr?hling for his help on integrating with Hawkular Accounts and Peter Palaga for his help with the release.
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From tsegismo at redhat.com  Fri Jul  3 10:52:29 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 03 Jul 2015 16:52:29 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <5588192F.3030906@redhat.com>
References: <5588192F.3030906@redhat.com>
Message-ID: <5596A1AD.2040402@redhat.com>

I've just sent a PR "Upgrade to Wildfly 9.0.0.Final"

https://github.com/hawkular/hawkular-parent-pom/pull/33

Note that:
- the Wildfly BOM is no longer forced on every project
- the Wildfly Maven plugin is configured to use our Wildfly version by 
default, instead of the default version specified in the Maven plugin


Le 22/06/2015 16:18, Thomas Segismont a ?crit :
> Hi everyone,
>
> I've been working on the changes needed in Metrics for the parent POM
> upgrade to version 16 (those introducing Wildfly 9).
>
> There are three things I noticed which I believe are worth sharing.
>
> Firstly beware that the Wildfly guys have changed their philosophy about
> the BOM: now they force the "provided" scope in the BOM and exclude all
> the dependencies they think you shouldn't care about as a EE7
> application developer.
> On one hand it frees you from adding the provided scope declaration in
> your application POM. On the other hand, if you use one of the artifacts
> in tests then dependency resolution could suddenly be broken.
>
> Secondly our parent POM does not only declare the Wildfly POM in
> dependency management section, in also imports it. Which means that all
> our projects get forced versioning and scope, even if they are not
> Wildfly based.
>
> Thirdly, minor issue, the Wildfly Maven plugin does not configure a
> default Wildfly version which means that we are all forced to declare in
> components parent POMs. Like this in Metrics:
> https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
>
> Going forward, I propose that we no longer "import" the BOM in Hawkular
> parent, and let components do it where needed. And that we declare the
> Wildfly version to start with the Wildfly Maven plugin in the parent.
>
>
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From hrupp at redhat.com  Fri Jul  3 11:57:58 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 03 Jul 2015 17:57:58 +0200
Subject: [Hawkular-dev] Hawkular-BTM 0.1.0.Final Released
In-Reply-To: <1771713988.24923648.1435823108237.JavaMail.zimbra@redhat.com>
References: <1771713988.24923648.1435823108237.JavaMail.zimbra@redhat.com>
Message-ID: <50410C05-9441-4925-832D-20154322E598@redhat.com>

On 2 Jul 2015, at 9:45, Gary Brown wrote:

> I am happy to announce release 0.1.0 of the Hawkular Business 
> Transaction Management project. The main focus for this release has

Congrats Gary, that is huge!

From hrupp at redhat.com  Fri Jul  3 12:00:01 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 03 Jul 2015 18:00:01 +0200
Subject: [Hawkular-dev] Prototype of operations execution on the feed
In-Reply-To: <8081F870-0E18-482B-B9F4-DD9B0965F2F2@redhat.com>
References: <8081F870-0E18-482B-B9F4-DD9B0965F2F2@redhat.com>
Message-ID: <9F27DB95-F902-4DE8-9A85-8D0145D7F97F@redhat.com>

On 29 Jun 2015, at 13:46, Heiko W.Rupp wrote:

> I have prototyped the execution of operations on the feed (WF-server 
> for now).

This is now updated to also send execution results back to Hawkular and
into the UI

Currently this is shown as bubble  -- see attachment.

As the user that has started such an operation,
may or may not see the bubble, we need some sort
of notification center, where the results are kept.

Also as those operations may take some time, we probably
need an activity indicator next to each deployment with an
outstanding action.

   Heiko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-07-03 um 17.34.40.png
Type: image/png
Size: 167426 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150703/5fde25bc/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-07-03 um 17.35.21.png
Type: image/png
Size: 101558 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150703/5fde25bc/attachment-0003.png 

From aakaruce at iitr.ac.in  Fri Jul  3 12:21:21 2015
From: aakaruce at iitr.ac.in (Aakarsh Agarwal)
Date: Fri, 03 Jul 2015 21:51:21 +0530
Subject: [Hawkular-dev] Hawkular-pluggable data processors for metrics:
	Progress Report
In-Reply-To: <72f0fd4276a3.5596b60d@iitr.ac.in>
References: <7380d700d47.5596b0a3@iitr.ac.in>
	<7380eadf4359.5596b100@iitr.ac.in> <7380d0ed74b4.5596b1cf@iitr.ac.in>
	<7380bda14a7a.5596b21a@iitr.ac.in> <7380dfb66b67.5596b287@iitr.ac.in>
	<73a0d0b6510f.5596b2fc@iitr.ac.in> <73a089d17b2.5596b346@iitr.ac.in>
	<72f097385e8c.5596b38c@iitr.ac.in> <735088892df7.5596b40d@iitr.ac.in>
	<738094a15a19.5596b44d@iitr.ac.in> <73a08f8d22bc.5596b493@iitr.ac.in>
	<73a0edbf7850.5596b4d9@iitr.ac.in> <72f0fd4276a3.5596b60d@iitr.ac.in>
Message-ID: <72f0f0ac4e78.559703d9@iitr.ac.in>

Hi all,

I am currently working on the Hawkular Metrics repository as part of the Google Summer of Code 2015 program and this is to update the progress of my project.


As of now, the git repo on my github profile dedicated to implement a simple plugin interface using 5 basic statistical algorithms has been updated. 5?standard functions implemented here are?- 

	Minimum?of the entered data set.
	Maximum?of the entered data set.
	Average?of the entered data set.
	Mode?of the entered data set.
	Standard Deviation?of the entered data set.

The link to this git repo is - https://github.com/Akki5/hawkular_plugin



The work done since last update of the project includes - 

	This project now uses maven to build the project and works on several submodules. There exists individual submodule per plugin for each standard function. 
	The project makes use of PluginClassLoader.java to load all the classes implementing StatisticalAlgo.
	It asks the input from user as to which plugin is to be used. It then computes and displays the desired result.
	PluginDemoTest.java is the test class. This class tests all the plugins at once and also different plugins individually. This increases the reliability and accuracy of the test class.
	All the desired jar files get compiled and packaged at one place.


 Regards,
Aakarsh Agarwal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150703/ecdfa0aa/attachment.html 

From artur.dryomov at gmail.com  Mon Jul  6 02:05:46 2015
From: artur.dryomov at gmail.com (Artur Dryomov)
Date: Mon, 6 Jul 2015 09:05:46 +0300
Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #6
Message-ID: <CAC6O=UV1-QqzB4-5Jfs=bFwy2GQLFH-5wXWATssUgwf-K1Y8+g@mail.gmail.com>

Hi everyone,

This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.

I?ve spent the last week on the authorization process and updating the API
to the current Hawkular state.

This week wasn?t very productive actually :-(

I?ve proposed to add the deauthorization item to the navigation drawer [1],
but it caused a discussion about UX issues and I?m still awaiting for
feedback at this point. We also prepared the demo during an intense session
of adapting the client to the current Hawkular API state [2]. At this point
I have some work done on integrating these API-related changes in a
non-hacky way [3]. There are some changes on making alerts and the chart
more flexible internally as well.

After finishing what is planned, I?ll try to get to full-speed and think
about what is the next step. Applications, maybe? I don?t see any public
API documentation at this point though.

Have a nice week!
Artur.

[1]: https://github.com/hawkular/hawkular-android-client/pull/26
[2]:
http://www.hawkular.org/blog/2015/07/02/hawkular-1.0.0.Alpha2-released.html
[3]: https://github.com/ming13/hawkular-android-client/tree/api-update
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150706/9d621c96/attachment.html 

From hrupp at redhat.com  Mon Jul  6 02:56:22 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 06 Jul 2015 08:56:22 +0200
Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #6
In-Reply-To: <CAC6O=UV1-QqzB4-5Jfs=bFwy2GQLFH-5wXWATssUgwf-K1Y8+g@mail.gmail.com>
References: <CAC6O=UV1-QqzB4-5Jfs=bFwy2GQLFH-5wXWATssUgwf-K1Y8+g@mail.gmail.com>
Message-ID: <A85E7C0A-8E5E-4F0A-B459-5362DD7D7B59@redhat.com>

On 6 Jul 2015, at 8:05, Artur Dryomov wrote:
> about what is the next step. Applications, maybe? I don?t see any 
> public API documentation at this point though.

Applications use the same inventory api as the urls do.
Properties on them are different of course.

And there are the lists of servers (WF only at the moment).
The main difference is that they can have child resources
(deployments, jvm, ... (more to come)), so you sort of need
to "recursively" follow the links.
Lukas can tell you more.

From vnguyen at redhat.com  Mon Jul  6 12:20:56 2015
From: vnguyen at redhat.com (Viet Nguyen)
Date: Mon, 6 Jul 2015 12:20:56 -0400 (EDT)
Subject: [Hawkular-dev] How to create user/persona from Rest?
In-Reply-To: <AF8C60F5-71B3-4117-9C6C-F2B957FAEEB6@redhat.com>
References: <AF8C60F5-71B3-4117-9C6C-F2B957FAEEB6@redhat.com>
Message-ID: <380139761.24312118.1436199656595.JavaMail.zimbra@redhat.com>

Hello everyone,

To make it easier to run test automation I'm looking for a way to create new users possibly from REST Api.  Someone mentioned on IRC it is possible via Keycloak.  Please advise.

thanks, 

Viet

From brmeyer at redhat.com  Mon Jul  6 13:23:21 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 6 Jul 2015 13:23:21 -0400 (EDT)
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <1800568567.32814349.1436203099300.JavaMail.zimbra@redhat.com>
Message-ID: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>

Random question:

On the side, I maintain the web platforms for several nonprofits throughout the US.  Each platform runs on its own OpenShift Online instance (EWS).  There's also a content server running elsewhere (Apache on CentOS).  In the past, I've used http://www.montastic.com to monitor them all.  I typically setup regex for each platform's "About Us" page.  If the content shows up properly, both the platform server and content server are running.  Obviously, I don't *have* to use regex...

...but it's useful sometimes.  Can Hawkular monitor a web URL using regex on the HTML content?  Or is monitoring the app server and web server themselves the only option at this point?

Would love to help with Hawkular dogfooding.

From jpkroehling at redhat.com  Tue Jul  7 04:09:28 2015
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 7 Jul 2015 10:09:28 +0200
Subject: [Hawkular-dev] How to create user/persona from Rest?
In-Reply-To: <380139761.24312118.1436199656595.JavaMail.zimbra@redhat.com>
References: <AF8C60F5-71B3-4117-9C6C-F2B957FAEEB6@redhat.com>
	<380139761.24312118.1436199656595.JavaMail.zimbra@redhat.com>
Message-ID: <559B8938.8050709@redhat.com>

Viet,

Do you need to create an user or a persona?

If you need to create an user, you have two options:

1) Change the realm that we import during the boot to include the users 
you need. I think Alerts is doing something similar.

http://git.io/vqBY0

2) As we use Keycloak in the background, you can also create users using 
their API. You'd need to check their documentation on how to achieve 
that. http://keycloak.github.io/docs/

If all you need is a persona, it's easier:

$ curl -v \
-H 'Content-type: application/json' \
-H 'Accept: application/json' \
-d '{"name":"Acme, Inc"}' \
-X POST \
-u jdoe:password \
http://localhost:8080/hawkular-accounts/organizations

The ID returned for this organization can be then passed as 
'Hawkular-Persona' to the backend.

- Juca.


On 07/06/2015 06:20 PM, Viet Nguyen wrote:
> Hello everyone,
>
> To make it easier to run test automation I'm looking for a way to create new users possibly from REST Api.  Someone mentioned on IRC it is possible via Keycloak.  Please advise.
>
> thanks,
>
> Viet
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From jshaughn at redhat.com  Tue Jul  7 09:15:03 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 7 Jul 2015 09:15:03 -0400
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
References: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
Message-ID: <559BD0D7.9060200@redhat.com>


I'm fairly sure we don't have that capability yet.  I think pinger 
success is just based on response codes and not content.  Seems like it 
could be useful, though.  Thinking back, I'm not sure that even RHQ's 
netservice plugin had this feature.

On 7/6/2015 1:23 PM, Brett Meyer wrote:
> Random question:
>
> On the side, I maintain the web platforms for several nonprofits throughout the US.  Each platform runs on its own OpenShift Online instance (EWS).  There's also a content server running elsewhere (Apache on CentOS).  In the past, I've used http://www.montastic.com to monitor them all.  I typically setup regex for each platform's "About Us" page.  If the content shows up properly, both the platform server and content server are running.  Obviously, I don't *have* to use regex...
>
> ...but it's useful sometimes.  Can Hawkular monitor a web URL using regex on the HTML content?  Or is monitoring the app server and web server themselves the only option at this point?
>
> Would love to help with Hawkular dogfooding.
> _______________________________________________
> 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/20150707/e75fd3ea/attachment.html 

From vrockai at redhat.com  Tue Jul  7 09:53:18 2015
From: vrockai at redhat.com (Viliam Rockai)
Date: Tue, 07 Jul 2015 15:53:18 +0200
Subject: [Hawkular-dev] Hawkular console directory structure changes
Message-ID: <1436277198.2008.1.camel@vrockai-laptop>

Hey all,

With my recent PR there are some directory structure changes introduced
to the hawkular console by removing redundant directories:
1. The console is now directly in the ./hawkular/console (instead
of ./hawkular/ui/console)
2. In the plugins directories the redundant "plugins/foo/" was removed
so now, instead of going to
"./src/main/scripts/plugins/metrics/plugins/metrics" you go to
"./src/main/scripts/plugins/metrics"

The previous structure was inherited while moving hawkular-components
repository, where the plugins were created with hawt.io plugin
generator. It didn't make much sense in current hawkular console and I
hope this would make traversing the console files easier and less
confusing.

Viliam


From hrupp at redhat.com  Tue Jul  7 09:54:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 07 Jul 2015 15:54:13 +0200
Subject: [Hawkular-dev] Prototype of operations execution on the feed
In-Reply-To: <9F27DB95-F902-4DE8-9A85-8D0145D7F97F@redhat.com>
References: <8081F870-0E18-482B-B9F4-DD9B0965F2F2@redhat.com>
	<9F27DB95-F902-4DE8-9A85-8D0145D7F97F@redhat.com>
Message-ID: <341ED38B-F2A4-4AE8-A55B-EC4710E5C1F6@redhat.com>

Hey,

this has now been enhanced to use Http2 connections to talk to the 
OpsQueue handler.

To set up the server, have a look at
http://pilhuhn.blogspot.de/2015/07/running-okhttpclient-from-within.html
that talks about enabling http2 and what needed to be done inside the
agent to also be able to run http2 requests.

On the agent side, this requires additional fields for the 
<storage-adapter>:

<storage-adapter type="HAWKULAR" username="jdoe" password="password"
	useSSL="true"
        keystorePath="standalone/configuration/localhost.jks"
        keystorePassword="password"/>

It is also allowed to pass a httpsUrl (like the 'url' we have now), but 
not
required.

If useSSL == false (which is the default), the behavior is as before 
except that
the internal calls to the hawkular server are (partially) done 
asynchronously via
OkHttpClient's async feature.

Still everything is in my personal branches like indicated in the 1st 
email



From mithomps at redhat.com  Tue Jul  7 10:23:27 2015
From: mithomps at redhat.com (mike thompson)
Date: Tue, 7 Jul 2015 07:23:27 -0700
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
References: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
Message-ID: <6F9CE329-3245-486A-B4A3-3A6E4617C5C2@redhat.com>

Hey Brett,

Submit a PR for that. I know some guys that would love to add that ;)


> On 6 Jul 2015, at 10:23, Brett Meyer <brmeyer at redhat.com> wrote:
> 
> Random question:
> 
> On the side, I maintain the web platforms for several nonprofits throughout the US.  Each platform runs on its own OpenShift Online instance (EWS).  There's also a content server running elsewhere (Apache on CentOS).  In the past, I've used http://www.montastic.com to monitor them all.  I typically setup regex for each platform's "About Us" page.  If the content shows up properly, both the platform server and content server are running.  Obviously, I don't *have* to use regex...
> 
> ...but it's useful sometimes.  Can Hawkular monitor a web URL using regex on the HTML content?  Or is monitoring the app server and web server themselves the only option at this point?
> 
> Would love to help with Hawkular dogfooding.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From mithomps at redhat.com  Tue Jul  7 10:26:07 2015
From: mithomps at redhat.com (mike thompson)
Date: Tue, 7 Jul 2015 07:26:07 -0700
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <6F9CE329-3245-486A-B4A3-3A6E4617C5C2@redhat.com>
References: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
	<6F9CE329-3245-486A-B4A3-3A6E4617C5C2@redhat.com>
Message-ID: <0B327641-46E8-4BF4-8D8A-5F21511E211D@redhat.com>


> On 7 Jul 2015, at 07:23, mike thompson <mithomps at redhat.com> wrote:
> 
> Hey Brett,
> 
> Submit a PR for that. I know some guys that would love to add that ;)

Opps, I meant a Jira for that; not a PR. I know you have lots of other things to work on.


> 
> 
>> On 6 Jul 2015, at 10:23, Brett Meyer <brmeyer at redhat.com> wrote:
>> 
>> Random question:
>> 
>> On the side, I maintain the web platforms for several nonprofits throughout the US.  Each platform runs on its own OpenShift Online instance (EWS).  There's also a content server running elsewhere (Apache on CentOS).  In the past, I've used http://www.montastic.com to monitor them all.  I typically setup regex for each platform's "About Us" page.  If the content shows up properly, both the platform server and content server are running.  Obviously, I don't *have* to use regex...
>> 
>> ...but it's useful sometimes.  Can Hawkular monitor a web URL using regex on the HTML content?  Or is monitoring the app server and web server themselves the only option at this point?
>> 
>> Would love to help with Hawkular dogfooding.
>> _______________________________________________
>> 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 brmeyer at redhat.com  Tue Jul  7 10:56:34 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 7 Jul 2015 10:56:34 -0400 (EDT)
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <0B327641-46E8-4BF4-8D8A-5F21511E211D@redhat.com>
References: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
	<6F9CE329-3245-486A-B4A3-3A6E4617C5C2@redhat.com>
	<0B327641-46E8-4BF4-8D8A-5F21511E211D@redhat.com>
Message-ID: <578848256.33288125.1436280994326.JavaMail.zimbra@redhat.com>

Done.

----- Original Message -----
> From: "mike thompson" <mithomps at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 7, 2015 10:26:07 AM
> Subject: Re: [Hawkular-dev] monitor websites through regex
> 
> 
> > On 7 Jul 2015, at 07:23, mike thompson <mithomps at redhat.com> wrote:
> > 
> > Hey Brett,
> > 
> > Submit a PR for that. I know some guys that would love to add that ;)
> 
> Opps, I meant a Jira for that; not a PR. I know you have lots of other things
> to work on.
> 
> 
> > 
> > 
> >> On 6 Jul 2015, at 10:23, Brett Meyer <brmeyer at redhat.com> wrote:
> >> 
> >> Random question:
> >> 
> >> On the side, I maintain the web platforms for several nonprofits
> >> throughout the US.  Each platform runs on its own OpenShift Online
> >> instance (EWS).  There's also a content server running elsewhere (Apache
> >> on CentOS).  In the past, I've used http://www.montastic.com to monitor
> >> them all.  I typically setup regex for each platform's "About Us" page.
> >> If the content shows up properly, both the platform server and content
> >> server are running.  Obviously, I don't *have* to use regex...
> >> 
> >> ...but it's useful sometimes.  Can Hawkular monitor a web URL using regex
> >> on the HTML content?  Or is monitoring the app server and web server
> >> themselves the only option at this point?
> >> 
> >> Would love to help with Hawkular dogfooding.
> >> _______________________________________________
> >> 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 brmeyer at redhat.com  Tue Jul  7 10:57:49 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 7 Jul 2015 10:57:49 -0400 (EDT)
Subject: [Hawkular-dev] monitor websites through regex
In-Reply-To: <578848256.33288125.1436280994326.JavaMail.zimbra@redhat.com>
References: <399086752.32817595.1436203401118.JavaMail.zimbra@redhat.com>
	<6F9CE329-3245-486A-B4A3-3A6E4617C5C2@redhat.com>
	<0B327641-46E8-4BF4-8D8A-5F21511E211D@redhat.com>
	<578848256.33288125.1436280994326.JavaMail.zimbra@redhat.com>
Message-ID: <1090908670.33288849.1436281069629.JavaMail.zimbra@redhat.com>

Whoops, just accidentally discovered a keyboard shortcut for "Send" ;)

https://issues.jboss.org/browse/HAWKULAR-435

Also created one for monitoring databases through a JDBC "pinger".  It's a bit of a stretch, but would also be helpful: https://issues.jboss.org/browse/HAWKULAR-436

----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 7, 2015 10:56:34 AM
> Subject: Re: [Hawkular-dev] monitor websites through regex
> 
> Done.
> 
> ----- Original Message -----
> > From: "mike thompson" <mithomps at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Tuesday, July 7, 2015 10:26:07 AM
> > Subject: Re: [Hawkular-dev] monitor websites through regex
> > 
> > 
> > > On 7 Jul 2015, at 07:23, mike thompson <mithomps at redhat.com> wrote:
> > > 
> > > Hey Brett,
> > > 
> > > Submit a PR for that. I know some guys that would love to add that ;)
> > 
> > Opps, I meant a Jira for that; not a PR. I know you have lots of other
> > things
> > to work on.
> > 
> > 
> > > 
> > > 
> > >> On 6 Jul 2015, at 10:23, Brett Meyer <brmeyer at redhat.com> wrote:
> > >> 
> > >> Random question:
> > >> 
> > >> On the side, I maintain the web platforms for several nonprofits
> > >> throughout the US.  Each platform runs on its own OpenShift Online
> > >> instance (EWS).  There's also a content server running elsewhere (Apache
> > >> on CentOS).  In the past, I've used http://www.montastic.com to monitor
> > >> them all.  I typically setup regex for each platform's "About Us" page.
> > >> If the content shows up properly, both the platform server and content
> > >> server are running.  Obviously, I don't *have* to use regex...
> > >> 
> > >> ...but it's useful sometimes.  Can Hawkular monitor a web URL using
> > >> regex
> > >> on the HTML content?  Or is monitoring the app server and web server
> > >> themselves the only option at this point?
> > >> 
> > >> Would love to help with Hawkular dogfooding.
> > >> _______________________________________________
> > >> 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 fbrychta at redhat.com  Tue Jul  7 11:14:07 2015
From: fbrychta at redhat.com (Filip Brychta)
Date: Tue, 7 Jul 2015 11:14:07 -0400 (EDT)
Subject: [Hawkular-dev] The latest hawkular-dist is now availbale in BC at
 http://last-hawkular.bc.jonqe.lab.eng.bos.redhat.com:8080
In-Reply-To: <810889728.24665437.1436280997224.JavaMail.zimbra@redhat.com>
Message-ID: <624065206.24670354.1436282047008.JavaMail.zimbra@redhat.com>

Hello,
The latest (currently 1.0.0.Alpha3-SNAPSHOT) instance of hawkular-dist is available at http://last-hawkular.bc.jonqe.lab.eng.bos.redhat.com:8080
It's re-deployed nightly and it uses hawkular-realm-for-dev.json so the jdoe user is available.

Filip

From brmeyer at redhat.com  Wed Jul  8 10:09:26 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 8 Jul 2015 10:09:26 -0400 (EDT)
Subject: [Hawkular-dev] Fwd: Artificer 1.0.0.Final
In-Reply-To: <1268516558.33971452.1436364542603.JavaMail.zimbra@redhat.com>
References: <1268516558.33971452.1436364542603.JavaMail.zimbra@redhat.com>
Message-ID: <601995316.33971649.1436364566977.JavaMail.zimbra@redhat.com>

Artificer is finally...final!  Deets: https://developer.jboss.org/en/artificer/blog/2015/07/07/artificer-100final-released

From tsegismo at redhat.com  Wed Jul  8 10:25:14 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 08 Jul 2015 16:25:14 +0200
Subject: [Hawkular-dev] Fwd: Artificer 1.0.0.Final
In-Reply-To: <601995316.33971649.1436364566977.JavaMail.zimbra@redhat.com>
References: <1268516558.33971452.1436364542603.JavaMail.zimbra@redhat.com>
	<601995316.33971649.1436364566977.JavaMail.zimbra@redhat.com>
Message-ID: <559D32CA.7010000@redhat.com>

Congrats!

Le 08/07/2015 16:09, Brett Meyer a ?crit :
> Artificer is finally...final!  Deets: https://developer.jboss.org/en/artificer/blog/2015/07/07/artificer-100final-released
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From artur.dryomov at gmail.com  Wed Jul  8 14:00:45 2015
From: artur.dryomov at gmail.com (Artur Dryomov)
Date: Wed, 8 Jul 2015 21:00:45 +0300
Subject: [Hawkular-dev] Prototype of operations execution on the feed
In-Reply-To: <341ED38B-F2A4-4AE8-A55B-EC4710E5C1F6@redhat.com>
References: <8081F870-0E18-482B-B9F4-DD9B0965F2F2@redhat.com>
	<9F27DB95-F902-4DE8-9A85-8D0145D7F97F@redhat.com>
	<341ED38B-F2A4-4AE8-A55B-EC4710E5C1F6@redhat.com>
Message-ID: <2B9A1928-3354-429B-AD01-5BBBCF61555F@gmail.com>

I guess it is a good time to poke AeroGear guys about custom HTTP clients to have an ability to implement the one for OkHttp :-)


From vnguyen at redhat.com  Thu Jul  9 04:02:50 2015
From: vnguyen at redhat.com (Viet Nguyen)
Date: Thu, 9 Jul 2015 04:02:50 -0400 (EDT)
Subject: [Hawkular-dev] How to create user/persona from Rest?
In-Reply-To: <559B8938.8050709@redhat.com>
References: <AF8C60F5-71B3-4117-9C6C-F2B957FAEEB6@redhat.com>
	<380139761.24312118.1436199656595.JavaMail.zimbra@redhat.com>
	<559B8938.8050709@redhat.com>
Message-ID: <1208661569.25244794.1436428970236.JavaMail.zimbra@redhat.com>

"User" is what I wanted.

Thanks for the tips.  I got it to work by starting Hawkular with the dev realm:

./standalone.sh -Dkeycloak.import=\${jboss.home.dir}/standalone/configuration/hawkular-realm-for-dev.json ...



Viet




----- Original Message -----
From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Tuesday, July 7, 2015 5:09:28 PM
Subject: Re: [Hawkular-dev] How to create user/persona from Rest?

Viet,

Do you need to create an user or a persona?

If you need to create an user, you have two options:

1) Change the realm that we import during the boot to include the users 
you need. I think Alerts is doing something similar.

http://git.io/vqBY0

2) As we use Keycloak in the background, you can also create users using 
their API. You'd need to check their documentation on how to achieve 
that. http://keycloak.github.io/docs/

If all you need is a persona, it's easier:

$ curl -v \
-H 'Content-type: application/json' \
-H 'Accept: application/json' \
-d '{"name":"Acme, Inc"}' \
-X POST \
-u jdoe:password \
http://localhost:8080/hawkular-accounts/organizations

The ID returned for this organization can be then passed as 
'Hawkular-Persona' to the backend.

- Juca.


On 07/06/2015 06:20 PM, Viet Nguyen wrote:
> Hello everyone,
>
> To make it easier to run test automation I'm looking for a way to create new users possibly from REST Api.  Someone mentioned on IRC it is possible via Keycloak.  Please advise.
>
> thanks,
>
> Viet
> _______________________________________________
> 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 Jul 10 04:03:32 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 10 Jul 2015 10:03:32 +0200
Subject: [Hawkular-dev] Web-security-talk
Message-ID: <DC03F62D-FAEB-4737-A23A-3FAF807D4D34@redhat.com>

Hey,

yesterday at Java Forum Stuttgart there was a pretty good
talk about Java-Web-Security

http://files.dominikschadow.de/event_jfs2015.pdf

I think there is certainly some content in there that
may be interesting for hawkular as well.

From mazz at redhat.com  Fri Jul 10 13:13:26 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 10 Jul 2015 13:13:26 -0400 (EDT)
Subject: [Hawkular-dev] gson->jackson
In-Reply-To: <1691102011.15716659.1436548296911.JavaMail.zimbra@redhat.com>
Message-ID: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>

Lucas,

https://github.com/hawkular/hawkular-agent/pull/21

Can you look at that? I'm confused how you got the bus stuff to work because:

a) I do not see you adding any additional dependencies to the bus WildFly extension module.xml
b) I do not see any additional jackson jars added.

The agent has:

 <module name="org.codehaus.jackson.jackson-core-asl"/>

but that still fails:

Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.JsonProcessingException

I see the org.codehaus.jackson modules in WildFly, but all of them have Java packages of org.codehaus, not org.fasterxml...

So, I'm not sure what magic I'm missing. I should have all the code in there now, I just need to know what runtime dependencies the agent needs to have to get those classes.

From mazz at redhat.com  Fri Jul 10 13:47:37 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 10 Jul 2015 13:47:37 -0400 (EDT)
Subject: [Hawkular-dev] gson->jackson
In-Reply-To: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
References: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
Message-ID: <1337192939.15734568.1436550457002.JavaMail.zimbra@redhat.com>

I just commited a second commit so it now includes jackson inside the agent module itself. This should let us work in WF-Core so I'll probably leave it like this, unless there is some problems folks would know would occur if I keep it like this.

Still curious to know how the bus changes worked :)

----- Original Message -----
> Lucas,
> 
> https://github.com/hawkular/hawkular-agent/pull/21
> 
> Can you look at that? I'm confused how you got the bus stuff to work because:
> 
> a) I do not see you adding any additional dependencies to the bus WildFly
> extension module.xml
> b) I do not see any additional jackson jars added.
> 
> The agent has:
> 
>  <module name="org.codehaus.jackson.jackson-core-asl"/>
> 
> but that still fails:
> 
> Caused by: java.lang.ClassNotFoundException:
> com.fasterxml.jackson.core.JsonProcessingException
> 
> I see the org.codehaus.jackson modules in WildFly, but all of them have Java
> packages of org.codehaus, not org.fasterxml...
> 
> So, I'm not sure what magic I'm missing. I should have all the code in there
> now, I just need to know what runtime dependencies the agent needs to have
> to get those classes.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Mon Jul 13 03:13:14 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 13 Jul 2015 03:13:14 -0400 (EDT)
Subject: [Hawkular-dev] gson->jackson
In-Reply-To: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
References: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
Message-ID: <1572997261.29970752.1436771594341.JavaMail.zimbra@redhat.com>

Hi John

For the later versions of jackson, you would need to use the modules "com.fasterxml.jackson.core.jackson-core/annotations/databind".

Regards
Gary

----- Original Message -----
> Lucas,
> 
> https://github.com/hawkular/hawkular-agent/pull/21
> 
> Can you look at that? I'm confused how you got the bus stuff to work because:
> 
> a) I do not see you adding any additional dependencies to the bus WildFly
> extension module.xml
> b) I do not see any additional jackson jars added.
> 
> The agent has:
> 
>  <module name="org.codehaus.jackson.jackson-core-asl"/>
> 
> but that still fails:
> 
> Caused by: java.lang.ClassNotFoundException:
> com.fasterxml.jackson.core.JsonProcessingException
> 
> I see the org.codehaus.jackson modules in WildFly, but all of them have Java
> packages of org.codehaus, not org.fasterxml...
> 
> So, I'm not sure what magic I'm missing. I should have all the code in there
> now, I just need to know what runtime dependencies the agent needs to have
> to get those classes.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lponce at redhat.com  Mon Jul 13 03:55:25 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 13 Jul 2015 03:55:25 -0400 (EDT)
Subject: [Hawkular-dev] gson->jackson
In-Reply-To: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
References: <1472221753.15717063.1436548406353.JavaMail.zimbra@redhat.com>
Message-ID: <1132890690.16192061.1436774124995.JavaMail.zimbra@redhat.com>

You are right John,

There is a missing dependency on the bus as well.

I'm going to fix it and send a PR ASAP.

Thanks,
Lucas

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Lucas Ponce" <lponce at redhat.com>
> Cc: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, July 10, 2015 7:13:26 PM
> Subject: gson->jackson
> 
> Lucas,
> 
> https://github.com/hawkular/hawkular-agent/pull/21
> 
> Can you look at that? I'm confused how you got the bus stuff to work because:
> 
> a) I do not see you adding any additional dependencies to the bus WildFly
> extension module.xml
> b) I do not see any additional jackson jars added.
> 
> The agent has:
> 
>  <module name="org.codehaus.jackson.jackson-core-asl"/>
> 
> but that still fails:
> 
> Caused by: java.lang.ClassNotFoundException:
> com.fasterxml.jackson.core.JsonProcessingException
> 
> I see the org.codehaus.jackson modules in WildFly, but all of them have Java
> packages of org.codehaus, not org.fasterxml...
> 
> So, I'm not sure what magic I'm missing. I should have all the code in there
> now, I just need to know what runtime dependencies the agent needs to have
> to get those classes.
> 

From artur.dryomov at gmail.com  Mon Jul 13 04:58:01 2015
From: artur.dryomov at gmail.com (Artur Dryomov)
Date: Mon, 13 Jul 2015 11:58:01 +0300
Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #7
Message-ID: <CAC6O=UVbvG0sFgTLLGToMHFHuO2QRSCCDquX151aL6sDXFkKbA@mail.gmail.com>

Hi everyone,

This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.

This morning Heiko had merged two pull requests. The first one is important
and is related to the API update, hopefully you can use the latest Hawkular
version with the application at this point?well, at least the 1.0.0 Alpha 2
[1]. The second one is more minor, but helpful?you can now filter alerts by
time periods, just like the web UI [2].

I wanted to discuss future plans?mostly because the application itself is
working and all basic features are available. Most of all I would like to
receive some feedback regarding the direction of the future development.
And I totally understand that Hawkular itself is evolving and there are
more changes to come.

Major.

   - Accounts. I need to investigate if it is possible at all, but multiple
   accounts handling would be nice. If it is not, at least logging out should
   be supported. There is some work done about that, but the discussion
   suddenly calmed down [3].
   - Navigation. I am not entirely sure that the current navigation handles
   everything properly. For example, at the moment all alerts are shown when
   browsing alerts. There should be some categorization based on resources,
   but at moment there are no proper API calls supporting it. The only thing
   we have is filtering via trigger IDs. Web UI solution is mostly a hack from
   my perspective [4].
   - Applications. This is a big one. I need to try to configure it and
   play with the API to understand how it works and how can I adapt the
   application to handle it.

Minor.

   - Chart. Distinguish availability and threshold ones. Not sure if it is
   possible in a flexible way, because Inventory at this point doesn?t show a
   type in the Metric model.
   - Chart. Make it more like the web one. I?m kind of limited by the used
   chart library, plus it is tricky to handle large sets of data, especially
   for months and years. Trying to dig through the TypeScript source code to
   understand how the web UI works.
   - Lists. Maybe add pull-to-refresh support. Purely cosmetic and utility
   change, not sure if it will be useful actually.

Most likely I should restructure these points into GitHub issues and work
on them, but I wanted to receive some feedback if it is possible. What do
you want to see in the application? What do you think should be primary
goals at this point?

Thanks and have a nice week!
Artur.

[1]: https://github.com/hawkular/hawkular-android-client/pull/28
[2]: https://github.com/hawkular/hawkular-android-client/pull/29
[3]: https://github.com/hawkular/hawkular-android-client/pull/26
[4]:
https://github.com/hawkular/hawkular/blob/b61fc571bfff88a08621b088c79f3a21471987bc/console/src/main/scripts/plugins/metrics/ts/alertsManager.ts#L261
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150713/41e58aaf/attachment.html 

From hrupp at redhat.com  Mon Jul 13 08:36:56 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 13 Jul 2015 14:36:56 +0200
Subject: [Hawkular-dev] Availability revisited
Message-ID: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>

Hey,

we did talk about Availability and computed state in the past

Now triggered by https://issues.jboss.org/browse/HAWKULAR-401
and also https://issues.jboss.org/browse/HAWKULAR-407
we need to revisit this and finally start including it in the code base.

In -407 we have the issue that the server can currently not detect that
a feed is down. For the WF-agent, this is likely to be solved with the 
new
feed-comm system, that can see disconnect messages [1] and act 
accordingly
(i.E. server side add a synthetic "down" event into the availability 
data stream.
Of course other feeds can also use that mechanism.

A generic feed though, that is sending availability records from time to 
time
is most probably not sending a "down" event in the case that it is going
down or crashing. So we need to have a periodic job looking for feeds
that did not talk to us for a longer period of time.
This also implies that at least the in-memory state for feed 
availability
needs to be updated with a last-seen record, as Micke described some 
time
ago ( that last seen record should probably be flushed to C* from time 
to
time).
Also we would need to require "generic" feeds to do some heartbeats by
sending their availability once per minute at least.

Now for -401, which is trickier. If e.g. a WildFly is in state 
'reload-needed',
it is technically up, but its configuration has pending changes.

So we would need "up" availability, and then another (sub) state 
indicating
the pending change.
And then we may have state like "maintenance mode", where a resource
may be up or down without impacting e.g. alerting or any SLA 
computation.

 From those raw input variables we would then compute the resource
state
http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html

While this could be up/down/unknown/(mixed for groups), it will also 
mean
that we need to convey the other information to the user. If e.g. a 
resource
is in maintenance mode, the user should be informed why alerts on the
resource do not fire.
Likewise for reload-needed: the user needs to know why the recent 
changes
he or she made did not change the way the appserver works.
Treating reload-needed as just "down" is wrong, as the server continues 
to
work and serve requests.

The above of course has an impact on storage. Right now we only store
up/down/unknown (as text) for availability, but we certainly would need
to also store sub-state.
For the maintenance-mode, this is orthogonal to all the above and should
probably a "flag" on a graph of resources.

   Heiko

[1] @OnClose is called with a code of 1006 on client crash/abnormal 
termination.
See http://tools.ietf.org/html/rfc6455#section-7.4

From hrupp at redhat.com  Mon Jul 13 09:15:13 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 13 Jul 2015 15:15:13 +0200
Subject: [Hawkular-dev] Article: Continuous integration is contrary Feature
	Branches!
Message-ID: <B02AFE2F-F19B-4B97-9989-766039C4B2E9@redhat.com>

Interesting read:

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.heise.de%2Fdeveloper%2Fartikel%2FContinuous-Integration-widerspricht-Feature-Branches-2736487.html&edit-text=&act=url

It is a google-translation of the German article, so perhaps sometimes 
the translation is a bit rough


From jshaughn at redhat.com  Mon Jul 13 10:58:20 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 13 Jul 2015 10:58:20 -0400
Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #7
In-Reply-To: <CAC6O=UVbvG0sFgTLLGToMHFHuO2QRSCCDquX151aL6sDXFkKbA@mail.gmail.com>
References: <CAC6O=UVbvG0sFgTLLGToMHFHuO2QRSCCDquX151aL6sDXFkKbA@mail.gmail.com>
Message-ID: <55A3D20C.7070102@redhat.com>


Hi Artur,
At the alerting level the main ability to categorize, outside of playing 
games with trigger names and things like that, is provided by Tags.  
Tags can be applied to Triggers and are basically [category],name.  You 
can then query Triggers via tags, and also query alerts via the tags on 
their owning triggers.

Because alerts have no inventory context, meaning it does not know about 
resources, higher level API for tying together Resources/Triggers/Alerts 
would need to be provided at the Hawkular level.  And that is fine, I 
think.  So the questions become, "what would a helpful API look like" 
and "where do we keep the relationships, in alert tags, resource 
relationships,. etc"?

Open to ideas.   Also, there is [HWKALERTS-62: Allow any data to store 
contextual information] which could also come into play.

On 7/13/2015 4:58 AM, Artur Dryomov wrote:
>
>   * Navigation. I am not entirely sure that the current navigation
>     handles everything properly. For example, at the moment all alerts
>     are shown when browsing alerts. There should be some
>     categorization based on resources, but at moment there are no
>     proper API calls supporting it. The only thing we have is
>     filtering via trigger IDs. Web UI solution is mostly a hack from
>     my perspective [4].
>

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

From hrupp at redhat.com  Mon Jul 13 14:16:59 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 13 Jul 2015 20:16:59 +0200
Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #7
In-Reply-To: <CAC6O=UVbvG0sFgTLLGToMHFHuO2QRSCCDquX151aL6sDXFkKbA@mail.gmail.com>
References: <CAC6O=UVbvG0sFgTLLGToMHFHuO2QRSCCDquX151aL6sDXFkKbA@mail.gmail.com>
Message-ID: <8BE7E6F2-4611-48B5-AE35-A96CCD049CFC@redhat.com>

Hey Artur,

> - Accounts. I need to investigate if it is possible at all, but multiple
> accounts handling would be nice. If it is not, at least logging out should
> be supported. There is some work done about that, but the discussion
> suddenly calmed down [3].

But that was mostly a "how do I do it in the UI" thing? 
Logging out and logging in at different user and/or even switch
to a different server are not questioned as far as I am concerned.

> - Applications. This is a big one. I need to try to configure it and
> play with the API to understand how it works and how can I adapt the
> application to handle it.

Well, what you see right now are not even really (what we mean with) 
applications, but deployments with different aspects of them.

> - Lists. Maybe add pull-to-refresh support. Purely cosmetic and utility
> change, not sure if it will be useful actually.

Or just a square reload button? But it seems that the pull to reload
pattern is pretty common these days.

> What do
> you want to see in the application? What do you think should be primary
> goals at this point?

Certainly more inventory types.
And the navigation from resource -> metric names -> chart
could be different for me with the metric names being a dropdown
on top of the page. That would save one touch to see the
default metric for a resource.

Also (and I think you were talking about that earlier) it could be
pretty cool to have some swiping to be able to select the chart
display time (and some two finger spread to select the duration
shown to zoom in / out ).

  Heiko


From lkrejci at redhat.com  Mon Jul 13 19:11:03 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 14 Jul 2015 01:11:03 +0200
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
Message-ID: <3558605.42pKLLLTHY@localhost.localdomain>

Hi all,

I plan to release inventory 0.2.0.Alpha1 soonish because it would be good for 
it to take some soak time in Hawkular prior to the next milestone. The main 
reason being the move to Titan and Cassandra as inventory's backend.

The other big(gish) feature is the support for resource hierarchy (at last!) a 
move to using canonical paths to entities on many places, etc.

In another words, there will be breakage.

I've opened the integration branch in my own fork of Hawkular:

https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1

I already made it pass the integration tests. There will need to be changes 
for Pinger and agent (and possibly for the UI, too) which I am seeking for 
help with.

I've started working on the agent updates for that branch (which triggered 
quite a lot of changes on the inventory side to make the transition (and 
future changes) smoother) but nothing is committed yet for that.

Cheers,

Lukas


From mazz at redhat.com  Mon Jul 13 19:57:22 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 13 Jul 2015 19:57:22 -0400 (EDT)
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <3558605.42pKLLLTHY@localhost.localdomain>
References: <3558605.42pKLLLTHY@localhost.localdomain>
Message-ID: <1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>

FYI: There are lots of changes going in the agent wrt server-agent comm right now. You'll need to let me know what needs to change in the agent - I'm afraid we're going to have some bad conflicts if we aren't careful.

----- Original Message -----
> Hi all,
> 
> I plan to release inventory 0.2.0.Alpha1 soonish because it would be good for
> it to take some soak time in Hawkular prior to the next milestone. The main
> reason being the move to Titan and Cassandra as inventory's backend.
> 
> The other big(gish) feature is the support for resource hierarchy (at last!)
> a
> move to using canonical paths to entities on many places, etc.
> 
> In another words, there will be breakage.
> 
> I've opened the integration branch in my own fork of Hawkular:
> 
> https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
> 
> I already made it pass the integration tests. There will need to be changes
> for Pinger and agent (and possibly for the UI, too) which I am seeking for
> help with.
> 
> I've started working on the agent updates for that branch (which triggered
> quite a lot of changes on the inventory side to make the transition (and
> future changes) smoother) but nothing is committed yet for that.
> 
> Cheers,
> 
> Lukas
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Mon Jul 13 22:43:35 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 13 Jul 2015 22:43:35 -0400 (EDT)
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
In-Reply-To: <47739350.16942186.1436841597287.JavaMail.zimbra@redhat.com>
Message-ID: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>

This is more for Lucas P, but wanted to put it out to the wider audience.

I'm playing with JSON stuff, and now that we are not using gson, we have to decide what jackson version we are going to use, because i just saw some oddities on stuff I'm building because of the two different impls that are available.

Are we going to use the restasy jackson2 or the fasterxml jackson artifacts? I think we need to consolidate on one (I mean, after all, we just got rid of gson - so we are trying to consolidate on one JSON impl). And they are technically two different impls because they are in two totally different Java packages and so look like two different impls. This can bite us if we aren't careful.

I'm using fasterxml right now. I don't know if i'm going down the exact same path that I did with gson (that is, using something no one else is). But my problem is I believe the resteasy modules are NOT in WildFly Core, so that's why I'm just pulling in the fasterxml artifacts directly rather than depending on the resteasy module.

From miburman at redhat.com  Tue Jul 14 02:47:20 2015
From: miburman at redhat.com (Michael Burman)
Date: Tue, 14 Jul 2015 02:47:20 -0400 (EDT)
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
In-Reply-To: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>
References: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>
Message-ID: <781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>

Hi,

They're basically the same software. org.fasterxml is just a newer version of Jackson. I'm surprised it's visible nearly anywhere.. resteasy-jackson2 should use org.fasterxml?

http://wiki.fasterxml.com/JacksonRelease20

The change was done in 2012, org.codehaus stuff is from Jackson <2.0 and isn't maintained (only the 2.x is maintained). And since Wildfly ships with Jackson 2.4.1, I guess this is the version to go (and so does RESTeasy? https://issues.jboss.org/browse/RESTEASY-1100)

  - Micke

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Tuesday, July 14, 2015 5:43:35 AM
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?

This is more for Lucas P, but wanted to put it out to the wider audience.

I'm playing with JSON stuff, and now that we are not using gson, we have to decide what jackson version we are going to use, because i just saw some oddities on stuff I'm building because of the two different impls that are available.

Are we going to use the restasy jackson2 or the fasterxml jackson artifacts? I think we need to consolidate on one (I mean, after all, we just got rid of gson - so we are trying to consolidate on one JSON impl). And they are technically two different impls because they are in two totally different Java packages and so look like two different impls. This can bite us if we aren't careful.

I'm using fasterxml right now. I don't know if i'm going down the exact same path that I did with gson (that is, using something no one else is). But my problem is I believe the resteasy modules are NOT in WildFly Core, so that's why I'm just pulling in the fasterxml artifacts directly rather than depending on the resteasy module.
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

From lponce at redhat.com  Tue Jul 14 04:01:03 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Tue, 14 Jul 2015 04:01:03 -0400 (EDT)
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
In-Reply-To: <781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>
References: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>
	<781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>
Message-ID: <52598728.17016193.1436860863246.JavaMail.zimbra@redhat.com>

I have never used the org.codehaus.jackson packages.

I always used the com.fasterxml.jackson.core ones in the context where I need to use directly the json library.

Wildfly 9 we have the 2.5.1 version there.

I tend to prefer the com.fasterxml and I remember to see that packages also in other components (that's main reason I used it).


----- Original Message -----
> From: "Michael Burman" <miburman at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 14, 2015 8:47:20 AM
> Subject: Re: [Hawkular-dev] resteasy jackson or fasterxml jackson?
> 
> Hi,
> 
> They're basically the same software. org.fasterxml is just a newer version of
> Jackson. I'm surprised it's visible nearly anywhere.. resteasy-jackson2
> should use org.fasterxml?
> 
> http://wiki.fasterxml.com/JacksonRelease20
> 
> The change was done in 2012, org.codehaus stuff is from Jackson <2.0 and
> isn't maintained (only the 2.x is maintained). And since Wildfly ships with
> Jackson 2.4.1, I guess this is the version to go (and so does RESTeasy?
> https://issues.jboss.org/browse/RESTEASY-1100)
> 
>   - Micke
> 
> ----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 14, 2015 5:43:35 AM
> Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
> 
> This is more for Lucas P, but wanted to put it out to the wider audience.
> 
> I'm playing with JSON stuff, and now that we are not using gson, we have to
> decide what jackson version we are going to use, because i just saw some
> oddities on stuff I'm building because of the two different impls that are
> available.
> 
> Are we going to use the restasy jackson2 or the fasterxml jackson artifacts?
> I think we need to consolidate on one (I mean, after all, we just got rid of
> gson - so we are trying to consolidate on one JSON impl). And they are
> technically two different impls because they are in two totally different
> Java packages and so look like two different impls. This can bite us if we
> aren't careful.
> 
> I'm using fasterxml right now. I don't know if i'm going down the exact same
> path that I did with gson (that is, using something no one else is). But my
> problem is I believe the resteasy modules are NOT in WildFly Core, so that's
> why I'm just pulling in the fasterxml artifacts directly rather than
> depending on the resteasy module.
> _______________________________________________
> 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 Jul 14 07:06:17 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 14 Jul 2015 13:06:17 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <5596A1AD.2040402@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
Message-ID: <55A4ED29.2020109@redhat.com>

Hi Thomas,

As I noted in your PR 
https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove 
<scope>import</scope> from the WF BoM dependency, all artifacts declared 
in the WF BoM will effectivelly become invisible in Hawkular projects. 
The WF BoM dependency here in parent would thus become completely 
useless (and can thus be removed completely), would it not?

As far as I can see your main motivation for this change was to stop 
forcing Wildfly BOM on projects that do not need it. The way how we 
should depend on WildFly BoM is a complicated topic. To build my own 
position, I tried to figure out,

   (1) which projects depend on artifacts from WF BoM and
   (2) and which artifacts from WF BoM are those that any of the HK
       projects depends on.

I did it only manually, using my eyes and IDE search - hence my findings 
are rather sketchy.

My findings are as follows:

(i) WF BoM manages JBoss Logging. We manage it too [1] in the parent, 
but that comes from pre-WF-BoM times and I'd personally found it better 
not to have the logging deps in our parent and rather to rely on 
versions imported from WF BoM (note that our logging versions got out of 
date compared to WF9 BoM). The number of HK projects using JBoss logging 
is pretty high: HK main, Accounts, Agent, Alerts, BTM, Bus and Inventory

(ii) WF BoM manages RESTeasy The number of HK projects using JBoss 
logging is pretty high too: HK main, Accounts, Alerts, BTM, Bus, 
Inventory and Metrics.

(iii) Then there is a substantial group of EE7 dependencies, like ejb, 
javax.annotation, servlet, transaction, xml.rpc, jms, ... that are used 
by HK main, Accounts, Bus, Commons (Embedded C*), Metrics and Inventory

Union of HK projects named in (i), (ii) and (iii) answers the question 
(1) - the set of projects that depend on something managed in WF BoM:

   HK main, Accounts, Agent, Alerts, BTM, Bus, Commons (Embedded C*),
   Metrics and Inventory

Note that this pretty much equal to the list of projects that have 
hawkular-parent as their parent. hawkular-android-client is not there, 
but that is a special case that does not need to be considered.

So what happens if we remove the WF BoM import from the HK Parent? - I 
see two options:

   (a) we'd have to add the very same WF BoM import in every child of HK
       Parent

or

   (b) we'd have to manage the artifacts we need from WF BoM ourselves
       in HK parent

I see no advantage in going with (a).

I used to prefer (b) earlier when I thought that Hawkular should target 
other containers than those from the WF/EAP family. Apparently, we do 
not target anything outside WF/EAP and (b) makes no sense to me anymore.

Based on the above, I'd say that we should keep the WF BoM import as is 
in HK Parent.

Best,

Peter

[1] 
https://github.com/hawkular/hawkular-parent-pom/blob/68227696f6fc9e102c81e2e50aa99022660bcdb7/pom.xml#L242-L256

On 03/07/15 16:52, Thomas Segismont wrote:
> I've just sent a PR "Upgrade to Wildfly 9.0.0.Final"
>
> https://github.com/hawkular/hawkular-parent-pom/pull/33
>
> Note that:
> - the Wildfly BOM is no longer forced on every project
> - the Wildfly Maven plugin is configured to use our Wildfly version by
> default, instead of the default version specified in the Maven plugin
>
>
> Le 22/06/2015 16:18, Thomas Segismont a ?crit :
>> Hi everyone,
>>
>> I've been working on the changes needed in Metrics for the parent POM
>> upgrade to version 16 (those introducing Wildfly 9).
>>
>> There are three things I noticed which I believe are worth sharing.
>>
>> Firstly beware that the Wildfly guys have changed their philosophy about
>> the BOM: now they force the "provided" scope in the BOM and exclude all
>> the dependencies they think you shouldn't care about as a EE7
>> application developer.
>> On one hand it frees you from adding the provided scope declaration in
>> your application POM. On the other hand, if you use one of the artifacts
>> in tests then dependency resolution could suddenly be broken.
>>
>> Secondly our parent POM does not only declare the Wildfly POM in
>> dependency management section, in also imports it. Which means that all
>> our projects get forced versioning and scope, even if they are not
>> Wildfly based.
>>
>> Thirdly, minor issue, the Wildfly Maven plugin does not configure a
>> default Wildfly version which means that we are all forced to declare in
>> components parent POMs. Like this in Metrics:
>> https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
>>
>> Going forward, I propose that we no longer "import" the BOM in Hawkular
>> parent, and let components do it where needed. And that we declare the
>> Wildfly version to start with the Wildfly Maven plugin in the parent.
>>
>>
>> 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 ppalaga at redhat.com  Tue Jul 14 07:55:18 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 14 Jul 2015 13:55:18 +0200
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
In-Reply-To: <52598728.17016193.1436860863246.JavaMail.zimbra@redhat.com>
References: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>
	<781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>
	<52598728.17016193.1436860863246.JavaMail.zimbra@redhat.com>
Message-ID: <55A4F8A6.1040203@redhat.com>

It sounds like the artifacts from com.fasterxml.jackson.core group 
should be managed im Hawkular parent?

And that <version.com.google.code.gson> should be removed from parent?

Could please somebody send a PR?

-- P

On 14/07/15 10:01, Lucas Ponce wrote:
> I have never used the org.codehaus.jackson packages.
>
> I always used the com.fasterxml.jackson.core ones in the context where I need to use directly the json library.
>
> Wildfly 9 we have the 2.5.1 version there.
>
> I tend to prefer the com.fasterxml and I remember to see that packages also in other components (that's main reason I used it).
>
>
> ----- Original Message -----
>> From: "Michael Burman" <miburman at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Tuesday, July 14, 2015 8:47:20 AM
>> Subject: Re: [Hawkular-dev] resteasy jackson or fasterxml jackson?
>>
>> Hi,
>>
>> They're basically the same software. org.fasterxml is just a newer version of
>> Jackson. I'm surprised it's visible nearly anywhere.. resteasy-jackson2
>> should use org.fasterxml?
>>
>> http://wiki.fasterxml.com/JacksonRelease20
>>
>> The change was done in 2012, org.codehaus stuff is from Jackson <2.0 and
>> isn't maintained (only the 2.x is maintained). And since Wildfly ships with
>> Jackson 2.4.1, I guess this is the version to go (and so does RESTeasy?
>> https://issues.jboss.org/browse/RESTEASY-1100)
>>
>>    - Micke
>>
>> ----- Original Message -----
>> From: "John Mazzitelli" <mazz at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Tuesday, July 14, 2015 5:43:35 AM
>> Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
>>
>> This is more for Lucas P, but wanted to put it out to the wider audience.
>>
>> I'm playing with JSON stuff, and now that we are not using gson, we have to
>> decide what jackson version we are going to use, because i just saw some
>> oddities on stuff I'm building because of the two different impls that are
>> available.
>>
>> Are we going to use the restasy jackson2 or the fasterxml jackson artifacts?
>> I think we need to consolidate on one (I mean, after all, we just got rid of
>> gson - so we are trying to consolidate on one JSON impl). And they are
>> technically two different impls because they are in two totally different
>> Java packages and so look like two different impls. This can bite us if we
>> aren't careful.
>>
>> I'm using fasterxml right now. I don't know if i'm going down the exact same
>> path that I did with gson (that is, using something no one else is). But my
>> problem is I believe the resteasy modules are NOT in WildFly Core, so that's
>> why I'm just pulling in the fasterxml artifacts directly rather than
>> depending on the resteasy module.
>> _______________________________________________
>> 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  Tue Jul 14 08:25:26 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 14 Jul 2015 08:25:26 -0400 (EDT)
Subject: [Hawkular-dev] resteasy jackson or fasterxml jackson?
In-Reply-To: <781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>
References: <11986665.16942794.1436841815990.JavaMail.zimbra@redhat.com>
	<781036895.45246914.1436856440851.JavaMail.zimbra@redhat.com>
Message-ID: <1460125589.17244620.1436876726001.JavaMail.zimbra@redhat.com>

Ahh.. OK... I see something I didn't notice before.

If you look in kettle's modules:

   system/layers/base/com/fasterxml/jackson/core/

There's the com.fasterxml ones. I just thought they are different than the resteasy ones. But I just looked in:

   system/layers/base/org/jboss/resteasy/resteasy-jackson2-provider/

and its main.xml exports those com.fasterxml modules. So if you have a dependency on resteasy-jackson2-provider, that does give you the com.fasterxml ones.

I swear I saw those older jackson jars in here somewhere.

OK, so depending on resteasy-jackson2-provider should be good. Never mind :)

From ppalaga at redhat.com  Tue Jul 14 09:13:16 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 14 Jul 2015 15:13:16 +0200
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
References: <3558605.42pKLLLTHY@localhost.localdomain>
	<1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
Message-ID: <55A50AEC.5060208@redhat.com>

I guess, it is still worth to finish the integration of Inventory 
0.1.0.Final that did not catch the Hawkular M2 train? I renamed the 
integration branch from dev/inventory-0.1.0.Alpha3 to 
dev/inventory-0.1.0.Final and rebased on current master: 
https://github.com/hawkular/hawkular/tree/dev/inventory-0.1.0.Final

Assuming nobody fixed the UI while I was away, I am going to try to fix 
it myself.

-- P

On 14/07/15 01:57, John Mazzitelli wrote:
> FYI: There are lots of changes going in the agent wrt server-agent comm right now. You'll need to let me know what needs to change in the agent - I'm afraid we're going to have some bad conflicts if we aren't careful.
>
> ----- Original Message -----
>> Hi all,
>>
>> I plan to release inventory 0.2.0.Alpha1 soonish because it would be good for
>> it to take some soak time in Hawkular prior to the next milestone. The main
>> reason being the move to Titan and Cassandra as inventory's backend.
>>
>> The other big(gish) feature is the support for resource hierarchy (at last!)
>> a
>> move to using canonical paths to entities on many places, etc.
>>
>> In another words, there will be breakage.
>>
>> I've opened the integration branch in my own fork of Hawkular:
>>
>> https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
>>
>> I already made it pass the integration tests. There will need to be changes
>> for Pinger and agent (and possibly for the UI, too) which I am seeking for
>> help with.
>>
>> I've started working on the agent updates for that branch (which triggered
>> quite a lot of changes on the inventory side to make the transition (and
>> future changes) smoother) but nothing is committed yet for that.
>>
>> Cheers,
>>
>> Lukas
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lkrejci at redhat.com  Tue Jul 14 15:28:34 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 14 Jul 2015 21:28:34 +0200
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <55A50AEC.5060208@redhat.com>
References: <3558605.42pKLLLTHY@localhost.localdomain>
	<1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
	<55A50AEC.5060208@redhat.com>
Message-ID: <3640989.3NlJtYpcAs@localhost.localdomain>

That branch is also merged into the 0.2.0.Alpha1 if that makes any difference.

On Tuesday, July 14, 2015 15:13:16 Peter Palaga wrote:
> I guess, it is still worth to finish the integration of Inventory
> 0.1.0.Final that did not catch the Hawkular M2 train? I renamed the
> integration branch from dev/inventory-0.1.0.Alpha3 to
> dev/inventory-0.1.0.Final and rebased on current master:
> https://github.com/hawkular/hawkular/tree/dev/inventory-0.1.0.Final
> 
> Assuming nobody fixed the UI while I was away, I am going to try to fix
> it myself.
> 
> -- P
> 
> On 14/07/15 01:57, John Mazzitelli wrote:
> > FYI: There are lots of changes going in the agent wrt server-agent comm
> > right now. You'll need to let me know what needs to change in the agent -
> > I'm afraid we're going to have some bad conflicts if we aren't careful.
> > 
> > ----- Original Message -----
> > 
> >> Hi all,
> >> 
> >> I plan to release inventory 0.2.0.Alpha1 soonish because it would be good
> >> for it to take some soak time in Hawkular prior to the next milestone.
> >> The main reason being the move to Titan and Cassandra as inventory's
> >> backend.
> >> 
> >> The other big(gish) feature is the support for resource hierarchy (at
> >> last!) a
> >> move to using canonical paths to entities on many places, etc.
> >> 
> >> In another words, there will be breakage.
> >> 
> >> I've opened the integration branch in my own fork of Hawkular:
> >> 
> >> https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
> >> 
> >> I already made it pass the integration tests. There will need to be
> >> changes
> >> for Pinger and agent (and possibly for the UI, too) which I am seeking
> >> for
> >> help with.
> >> 
> >> I've started working on the agent updates for that branch (which
> >> triggered
> >> quite a lot of changes on the inventory side to make the transition (and
> >> future changes) smoother) but nothing is committed yet for that.
> >> 
> >> Cheers,
> >> 
> >> Lukas
> >> 
> >> _______________________________________________
> >> 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  Wed Jul 15 05:23:43 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 15 Jul 2015 11:23:43 +0200
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <3640989.3NlJtYpcAs@localhost.localdomain>
References: <3558605.42pKLLLTHY@localhost.localdomain>
	<1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
	<55A50AEC.5060208@redhat.com>
	<3640989.3NlJtYpcAs@localhost.localdomain>
Message-ID: <55A6269F.8030703@redhat.com>

Just FYI, dev/inventory-0.1.0.Final was merged to master and after that 
that, I deleted dev/inventory-0.1.0.Final. -- P

On 14/07/15 21:28, Lukas Krejci wrote:
> That branch is also merged into the 0.2.0.Alpha1 if that makes any difference.
>
> On Tuesday, July 14, 2015 15:13:16 Peter Palaga wrote:
>> I guess, it is still worth to finish the integration of Inventory
>> 0.1.0.Final that did not catch the Hawkular M2 train? I renamed the
>> integration branch from dev/inventory-0.1.0.Alpha3 to
>> dev/inventory-0.1.0.Final and rebased on current master:
>> https://github.com/hawkular/hawkular/tree/dev/inventory-0.1.0.Final
>>
>> Assuming nobody fixed the UI while I was away, I am going to try to fix
>> it myself.
>>
>> -- P
>>
>> On 14/07/15 01:57, John Mazzitelli wrote:
>>> FYI: There are lots of changes going in the agent wrt server-agent comm
>>> right now. You'll need to let me know what needs to change in the agent -
>>> I'm afraid we're going to have some bad conflicts if we aren't careful.
>>>
>>> ----- Original Message -----
>>>
>>>> Hi all,
>>>>
>>>> I plan to release inventory 0.2.0.Alpha1 soonish because it would be good
>>>> for it to take some soak time in Hawkular prior to the next milestone.
>>>> The main reason being the move to Titan and Cassandra as inventory's
>>>> backend.
>>>>
>>>> The other big(gish) feature is the support for resource hierarchy (at
>>>> last!) a
>>>> move to using canonical paths to entities on many places, etc.
>>>>
>>>> In another words, there will be breakage.
>>>>
>>>> I've opened the integration branch in my own fork of Hawkular:
>>>>
>>>> https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
>>>>
>>>> I already made it pass the integration tests. There will need to be
>>>> changes
>>>> for Pinger and agent (and possibly for the UI, too) which I am seeking
>>>> for
>>>> help with.
>>>>
>>>> I've started working on the agent updates for that branch (which
>>>> triggered
>>>> quite a lot of changes on the inventory side to make the transition (and
>>>> future changes) smoother) but nothing is committed yet for that.
>>>>
>>>> Cheers,
>>>>
>>>> Lukas
>>>>
>>>> _______________________________________________
>>>> 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 jsanda at redhat.com  Wed Jul 15 21:45:42 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 15 Jul 2015 21:45:42 -0400
Subject: [Hawkular-dev] Availability revisited
In-Reply-To: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
References: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
Message-ID: <9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>


> On Jul 13, 2015, at 8:36 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Hey,
> 
> we did talk about Availability and computed state in the past
> 
> Now triggered by https://issues.jboss.org/browse/HAWKULAR-401
> and also https://issues.jboss.org/browse/HAWKULAR-407
> we need to revisit this and finally start including it in the code base.
> 
> In -407 we have the issue that the server can currently not detect that
> a feed is down. For the WF-agent, this is likely to be solved with the 
> new
> feed-comm system, that can see disconnect messages [1] and act 
> accordingly

Are there any docs, notes, etc. on the feed-comm system? I am not familiar with this.

> (i.E. server side add a synthetic "down" event into the availability 
> data stream.
> Of course other feeds can also use that mechanism.
> 
> A generic feed though, that is sending availability records from time to 
> time
> is most probably not sending a "down" event in the case that it is going
> down or crashing. So we need to have a periodic job looking for feeds
> that did not talk to us for a longer period of time.
> This also implies that at least the in-memory state for feed 
> availability
> needs to be updated with a last-seen record, as Micke described some 
> time
> ago ( that last seen record should probably be flushed to C* from time 
> to
> time).

Why do we need to store the last seen availability in memory?

> Also we would need to require "generic" feeds to do some heartbeats by
> sending their availability once per minute at least.
> 
> Now for -401, which is trickier. If e.g. a WildFly is in state 
> 'reload-needed',
> it is technically up, but its configuration has pending changes.
> 
> So we would need "up" availability, and then another (sub) state 
> indicating
> the pending change.
> And then we may have state like "maintenance mode", where a resource
> may be up or down without impacting e.g. alerting or any SLA 
> computation.
> 
> From those raw input variables we would then compute the resource
> state
> http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html
> 
> While this could be up/down/unknown/(mixed for groups), it will also 
> mean
> that we need to convey the other information to the user. If e.g. a 
> resource
> is in maintenance mode, the user should be informed why alerts on the
> resource do not fire.
> Likewise for reload-needed: the user needs to know why the recent 
> changes
> he or she made did not change the way the appserver works.
> Treating reload-needed as just "down" is wrong, as the server continues 
> to
> work and serve requests.

If you talking about correlation, then I am +1. When I think about RHQ, the user could easily see availability state change, but he would have to go hunting around to see what precipitated it.

> 
> The above of course has an impact on storage. Right now we only store
> up/down/unknown (as text) for availability, but we certainly would need
> to also store sub-state.
> For the maintenance-mode, this is orthogonal to all the above and should
> probably a "flag" on a graph of resources.
> 
>   Heiko
> 
> [1] @OnClose is called with a code of 1006 on client crash/abnormal 
> termination.
> See http://tools.ietf.org/html/rfc6455#section-7.4
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From mazz at redhat.com  Thu Jul 16 23:21:30 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 16 Jul 2015 23:21:30 -0400 (EDT)
Subject: [Hawkular-dev] tomorrow
In-Reply-To: <253981785.18902031.1437102953164.JavaMail.zimbra@redhat.com>
Message-ID: <1062147090.18903050.1437103290172.JavaMail.zimbra@redhat.com>

Tomorrow morning I would like to talk about something Heiko prototyped, which I then took and built out. It is related to server-feed communications and is also going to relate to pushing realtime information to the UI as well. Now that this stuff is in a place that is demoable (its hacked up, but it shows what I want it to show), I figure let everyone know what's going on, and what it is Heiko has been dreaming up (see how I subtly threw him under the bus there? :) Seriously, its a pretty cool idea and I have something working that I can show. If anyone is interested, I'll do this maybe during or after the status call. I realize its last minute, but I wanted to bring it up now before the end of week because I don't know if we want this infrastructure to go in the release next week or not.

From ppalaga at redhat.com  Fri Jul 17 05:58:16 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 17 Jul 2015 11:58:16 +0200
Subject: [Hawkular-dev] New or noteworthy in hawkular-parent 18
Message-ID: <55A8D1B8.3000709@redhat.com>

Hi *,

New or noteworthy in hawkular-parent 18 [1]:

* WF BoM upgraded to 9.0.0.Final
* WF Plugin configured to use our WF version
* Added gatling-maven-plugin
* Added Jackson Core
* Removed JBoss Logging, EJB and Servlet APIs from Parent dep
   management because they are managed in WF BoM. Note that WF BoM
   manages these as provided thus making them non-transitive and as a
   consequence of that, they need to be added explicitly on some places.

I have sent PRs with an upgrade to parent 18 to all consuming repos. 
Note that in HK main, I sent it to dev/inventory-0.2.0.Alpha1 branch.

Best,

Peter

[1] https://github.com/hawkular/hawkular-parent-pom/commits/18

From ppalaga at redhat.com  Fri Jul 17 11:24:20 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 17 Jul 2015 17:24:20 +0200
Subject: [Hawkular-dev] Fwd: Writing good pull requests (Fwd: [wildfly-dev]
 How to contribute pull requests to WildFly)
In-Reply-To: <55A82272.3020701@redhat.com>
References: <55A82272.3020701@redhat.com>
Message-ID: <55A91E24.3050906@redhat.com>

Things to consider. Forwarded from thecore -- P


-------- Forwarded Message --------
Subject: Writing good pull requests (Fwd: [wildfly-dev] How to 
contribute pull requests to WildFly)
Date: Thu, 16 Jul 2015 16:30:26 -0500
From: David M. Lloyd <david.lloyd at redhat.com>
To: The Core <thecore at redhat.com>

I recently sent this to wildfly-dev.  I think however that these
guidelines are probably applicable to many, if not all, of our git-based
OSS projects, so if any of you are interested in this topic, here you go.

-------- Forwarded Message --------
Subject: [wildfly-dev] How to contribute pull requests to WildFly
Date: Thu, 16 Jul 2015 16:08:08 -0500
From: David M. Lloyd <david.lloyd at redhat.com>
To: WildFly Dev <wildfly-dev at lists.jboss.org>

Since migrating to git, and a review-oriented contribution structure,
we've seen a massive improvement in the quality and quantity of
community contribution in both WildFly itself and its affiliated
projects.  However, while we have lots of documents about how to get the
WildFly code, hack on it, use git to make a branch, submit a pull
request, etc., one thing rarely (if ever) talked about is any kind of
standards as to how to actually build and structure your pull requests,
so I'm going to establish that right now.

I have a few reasons for doing this.  First, the reviewers are stretched
thin - very thin.  This has several bad effects, including (but not
limited to):

* Pull requests sitting in the queue for extended periods of time
* Giant pull requests getting less review than small pull requests
* Pull requests receiving highly variable quality-of-review

Secondly, we see problematic pull requests in a wide variety of shapes
and sizes, from the single-unreviewable-mega-commit PR to the
thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as
well as some stealthier cases like the build-is-broken-between-commits PR.

Thirdly, the project has reached a size and scope where we really need
to have more eyes on every change - as many as possible in fact.

To that effect, and borrowing some concepts heavily from the Linux
Kernel project's documentation [1], I offer this.  You're welcome.

(For background on how to get started with contribution, the hacking
guide [2] is still the best place to start; after any initial
discussion, I'll probably throw this up alongside that.)

WildFly Contribution and Pull Request Standards
-----------------------------------------------
While a complete git tutorial is far, far out of scope of this guide,
there are a few important rules and guidelines to adhere to when
creating a pull request for WildFly or one of its constituent or related
sub-projects.

1) Describe the pull request adequately.

The description *should* include a JIRA number directly from the project
in question, whose corresponding JIRA issue will in turn have been
linked to the pull request you are just now creating.  The description
*should* also include a decent, human-readable summary of what is
changing.  Proper spelling and grammar is a plus!

2) Make sure it builds and tests pass *first*.

It is highly annoying to reviewers when they find they've spent a great
deal of time reviewing some code only to discover that it doesn't even
compile.  In particular, it's common for a patch to trip CheckStyle if
it hadn't been previously compile-tested at the least.

While it is tempting to rely on the automated CI/GitHub integration to
do our build and test for us (and I'm guilty of having done this too),
it generally just causes trouble, so please don't do it!

3) Separate your changes - but not *too* much.

This comes directly from [1], and I agree with it 100%:

"Separate each _logical change_ into a separate patch.

"For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
or more patches.  If your changes include an API update, and a new
driver which uses that new API, separate those into two patches.

"On the other hand, if you make a single change to numerous files,
group those changes into a single patch.  Thus a single logical change
is contained within a single patch.

"The point to remember is that each patch should make an easily understood
change that can be verified by reviewers.  Each patch should be justifiable
on its own merits.

"If one patch depends on another patch in order for a change to be
complete, that is OK.  Simply note "this patch depends on patch X"
in your patch description.

"When dividing your change into a series of patches, take special care to
ensure that [WildFly] builds and runs properly after each patch in the
series.  Developers using "git bisect" to track down a problem can end up
splitting your patch series at any point; they will not thank you if you
introduce bugs in the middle.

"If you cannot condense your patch set into a smaller set of patches,
then only post say 15 or so at a time and wait for review and integration."

I also want to emphasize how important it is to separate *functional*
and *non-functional* changes.  The latter category includes reformatting
(which generally should *not* be done without a strong justification).

4) Avoid massive and/or "stream of consciousness" branches

We all know that development can sometimes be an iterative process, and
we learn as we go.  Nonetheless, we do not need or want a complete
record of all the highs and lows in the history of every change (for
example, an "add foobar" commit followed later by a "remove foobar"
commit in the same PR) - particularly for large changes or in large
projects (like WildFly proper).  It is good practice for such change
authors to go back and rearrange and/or restructure the commits of a
pull request such that they incrementally introduce the change in a
logical manner, as one single conceptual change per PR.

If a PR consists of dozens or hundreds of nontrivial commits, you will
want to strongly consider dividing it up into multiple PRs, as PRs of
this size simply cannot be effectively reviewed.  They will either be
merged without adequate review, or outright ignored or closed.  Which
one is worse, I leave to your imagination.

5) Pay attention and respond to review comments

While in general it is my experience that WildFly contributors are good
about this, I'm going to quote this passage from [1] regardless:

"Your patch will almost certainly get comments from reviewers on ways in
which the patch can be improved.  You must respond to those comments;
ignoring reviewers is a good way to get ignored in return.  [...]

"Be sure to tell the reviewers what changes you are making and to thank them
for their time.  Code review is a tiring and time-consuming process, and
reviewers sometimes get grumpy.  Even in that case, though, respond
politely and address the problems they have pointed out."

In addition, when something needs to be changed, the proper manner to do
so is generally to modify the original commit, not to add more commits
to the chain to fix issues as they're reported.  See (4).

6) Don't get discouraged

It may come to pass that you have to iterate on your pull request many
times before it is considered acceptable.  Don't be discouraged by this
- instead, consider that to be a sign that the reviewers care highly
about the quality of the code base.  At the same time though, consider
that it is frustrating for reviewers to have to say the same things over
and over again, so please do take care to provide as high-quality
submissions as possible, and see (5)!

7) You can review code too!

You don't have to be an official reviewer in order to review a pull
request.  If you see a pull request dealing with an area you are
familiar with, feel free to examine it and comment as needed.  In
addition, *all* pull requests need to be reviewed for basic
(non-machine-verifiable) correctness, including noticing bad code, NPE
risks, and anti-patterns as well as "boring stuff" like spelling and
grammar and documentation.

8) On major refactorings

When doing major and/or long-term refactors, while rare, it is possible
that the above constraints become impractical, especially with regard to
grouping changes.  In this case, you can use a work branch on a (GitHub)
fork of WildFly, applying the above rules in micro-scale to just that
branch.  In this case you could possibly ask a reviewer to also review
some or all of the pull requests to that branch.  Merge commits would
then be used to periodically synchronize with upstream.

In this way, when the long-term branch is ready to "come home" to the
main branch, the reviewers may have a good idea that the (potentially
quite numerous) changes in the work branch have been reviewed already.

[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
[2] https://developer.jboss.org/wiki/HackingOnWildFly

-- 
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
- DML





From mazz at redhat.com  Fri Jul 17 15:11:42 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 17 Jul 2015 15:11:42 -0400 (EDT)
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a resource
	ID?
In-Reply-To: <1043906176.19179881.1437160263600.JavaMail.zimbra@redhat.com>
Message-ID: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>

To the inventory folks: is there an API that gives me a feed ID if all I know is a resource ID? If there is no API, can I get one? :)

We'll need a way to determine what feed is responsible for managing what parts of the inventory. So, given that clients like the UI will only know about things like resource ID, that's all they will be able to give the kettle - but the server-side components will need to take that resource ID and get its associated feed ID so it can pass messages to the feed that is managing that resource.

From lkrejci at redhat.com  Mon Jul 20 04:02:04 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 20 Jul 2015 10:02:04 +0200
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a
	resource ID?
In-Reply-To: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
References: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
Message-ID: <2417221.uLVapvDglr@localhost.localdomain>

In Inventory 0.2.0.Alpha1 which I am about to release today if no breakage was 
discovered during my absence:

If you have the resource java object, which I think you have in agent, you 
simply do:

resourceObject.getPath().ids().getFeedId();

Long version:

All inventory entities now store a "canonical path" which is a path going down 
from tenant do the entity in question following the "contains" relationships.

The above call will take the resource object's path analyze it using the 
"ids()" call and will return the feed id, if the resource is contained within 
a feed or null, if the resource lives directly under an environment.

Also if you just store the resource ID, remember that that is only "locally 
unique" within your feed, so to reliably get the correct resource, you only 
can search for it within the feed:

inventory.tenants().getAll("asdf").environments().get("asf").feeds("myfeed")
.resources().get("resource-id");

If you also store the canonical path of the resource, you could do:

inventory.inspect(CanonicalPath.fromString("resource-path"), 
Resources.Single.class);

which would return to you the same access object as the above call.

So when you create your resource, you supply locally unique id, and can use 
the access object returned from the create method to get the newly created 
resource which will contain its full canonical path and all the other details.

On Friday, July 17, 2015 15:11:42 John Mazzitelli wrote:
> To the inventory folks: is there an API that gives me a feed ID if all I
> know is a resource ID? If there is no API, can I get one? :)
> 
> We'll need a way to determine what feed is responsible for managing what
> parts of the inventory. So, given that clients like the UI will only know
> about things like resource ID, that's all they will be able to give the
> kettle - but the server-side components will need to take that resource ID
> and get its associated feed ID so it can pass messages to the feed that is
> managing that resource. _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From tsegismo at redhat.com  Mon Jul 20 04:49:09 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 20 Jul 2015 10:49:09 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55A4ED29.2020109@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com>
Message-ID: <55ACB605.5070501@redhat.com>

Le 14/07/2015 13:06, Peter Palaga a ?crit :
> Hi Thomas,
>
> As I noted in your PR
> https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove
> <scope>import</scope> from the WF BoM dependency, all artifacts declared
> in the WF BoM will effectivelly become invisible in Hawkular projects.

Yes, that's intended.

> The WF BoM dependency here in parent would thus become completely
> useless (and can thus be removed completely), would it not?

No it wouldn't, as Wildfly-based projects should all be using the same 
BOM version.

>
> As far as I can see your main motivation for this change was to stop
> forcing Wildfly BOM on projects that do not need it. The way how we
> should depend on WildFly BoM is a complicated topic. To build my own
> position, I tried to figure out,

It's not important to me if 80, 90 or 99% of our projects our Wildfly 
based. Importing the BOM in the parent POM gives the 1% projects no way 
to escape.

If Hawkular projects want the BOM imported for all their submodules then 
it's a matter of adding this in the component parent POM:

----
<dependency>
  <groupId>org.wildfly.bom</groupId>
  <artifactId>jboss-javaee-7.0-wildfly</artifactId>
  <scope>import</scope>
</dependency>
----

Not too much to add (and that could have been included in the various PR 
sent to upgrade to parent POM 18).

When this thread was started a month ago, we've agreed not forcing 
scopes in dependency management sections. Then we've started discussions 
with the Wildfly team and, thanks them, we got a Wildfly BOM version 9 
without the forced scopes. Now we're doing the opposite in our own parent...

From hrupp at redhat.com  Mon Jul 20 05:13:45 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 20 Jul 2015 11:13:45 +0200
Subject: [Hawkular-dev] Availability revisited
In-Reply-To: <9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>
References: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
	<9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>
Message-ID: <B3BF799F-9E56-4A76-BA28-FA8BF0AD3DC4@redhat.com>

On 16 Jul 2015, at 3:45, John Sanda wrote:
> Are there any docs, notes, etc. on the feed-comm system? I am not 
> familiar with this.

Mazz should have /will talk about it. But at the end this has only 
little
to do with this topic, as any sort of availability should work with
"normal" REST-based-feeds too.

>
> Why do we need to store the last seen availability in memory?

Because we can? :-)
Seriously: in RHQ we had huge issues with all the availability records
that were never cached, so everything working with "current 
availability)
had to go to the database with its latencies and costs.
Availability is by nature something run-length encoded. Unlike
counter or gauge metrics.
We could of course store each incoming new availability record, so that
its (start) timestamp would reflect the last seen time, but querying for
"since when was it up" would result in a pretty heavy backtracking query
(with some luck we have a limit like "in the last hour/day", but what if
we want an absolute date or over the last year.

This is why I am thinking about keeping the RLE with start/stop/state,
but augmented by "last seen" for the in-memory version.

Keeping last seen in memory prevents all the expensive backend-hits
(either getting the same value over and over again, or doing in-place 
updates)
and still allows jobs to check if the last-seen is e.g. within the last 
minute
and react accordingly (RHQ-term: "backfill").

> If you talking about correlation, then I am +1. When I think about 
> RHQ, the user could easily see availability state change, but he would 
> have to go hunting around to see what precipitated it.

This is certainly another aspect of this "root cause analysis".

   Heiko

From jkremser at redhat.com  Mon Jul 20 06:18:08 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Mon, 20 Jul 2015 06:18:08 -0400 (EDT)
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <207726985.257405.1437386377259.JavaMail.zimbra@redhat.com>
Message-ID: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>

Hello,
  if you don't know the ifttt, it's simple site where you can define a trigger condition and then some action if the condition is met. It's a closed source software (no need to pay though), but the number of possible actions is enormous. I'd say it's industrial standard for this kind of problems. They provide a way to trigger the action manually by sending http POST to their api. 

It's described here:

https://ifttt.com/maker


The post request looks like this: 

`curl -X POST -H "Content-Type: application/json" -d '{"value1":"1","value2":"2","value3":"foo"}' https://maker.ifttt.com/trigger/sdf/with/key/aabbccddeeffgghh`

where sdf is the name of the event (must be defined via their website), aabbcc.. is the secret token for the user and valueN:n in the json is the arbitrary data you can then use inside the actions. For instance in the subject of the email or whatever the action allows.

So, if we add a new alert notification that can do such a post request we can get for free all these actions:

https://ifttt.com/recipes/do

Again, the if-condition-then-action rule must be defined via their website (if condition is called 'maker' in this case), the actions use the oauth so it asks for permission if needed. For instance I use it for pushbullet notifications so It asked pushbulet "auth api" 

wdyt?

jk

From ppalaga at redhat.com  Mon Jul 20 06:40:39 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 20 Jul 2015 12:40:39 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55ACB605.5070501@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com> <55ACB605.5070501@redhat.com>
Message-ID: <55ACD027.2010504@redhat.com>

Hi Thomas, inline...

On 2015-07-20 10:49, Thomas Segismont wrote:
> Le 14/07/2015 13:06, Peter Palaga a ?crit :
>> Hi Thomas,
>>
>> As I noted in your PR
>> https://github.com/hawkular/hawkular-parent-pom/pull/33 if we remove
>> <scope>import</scope> from the WF BoM dependency, all artifacts declared
>> in the WF BoM will effectivelly become invisible in Hawkular projects.
>
> Yes, that's intended.
>
>> The WF BoM dependency here in parent would thus become completely
>> useless (and can thus be removed completely), would it not?
>
> No it wouldn't, as Wildfly-based projects should all be using the same
> BOM version.

OK, I can see now how you meant it.

>> As far as I can see your main motivation for this change was to stop
>> forcing Wildfly BOM on projects that do not need it. The way how we
>> should depend on WildFly BoM is a complicated topic. To build my own
>> position, I tried to figure out,
>
> It's not important to me if 80, 90 or 99% of our projects our Wildfly
> based. Importing the BOM in the parent POM gives the 1% projects no way
> to escape.

In my last message I claim to have shown that it is effectivelly 100% of 
components. Which specific project "needs to escape" from your point of 
view?

> If Hawkular projects want the BOM imported for all their submodules then
> it's a matter of adding this in the component parent POM:
>
> ----
> <dependency>
>    <groupId>org.wildfly.bom</groupId>
>    <artifactId>jboss-javaee-7.0-wildfly</artifactId>
>    <scope>import</scope>
> </dependency>
> ----
>
> Not too much to add (and that could have been included in the various PR
> sent to upgrade to parent POM 18).
>
> When this thread was started a month ago, we've agreed not forcing
> scopes in dependency management sections. Then we've started discussions
> with the Wildfly team and, thanks them, we got a Wildfly BOM version 9
> without the forced scopes.

Sorry, I must have overseen that you were asking WF team to remove the 
scopes from their management. From your mails understood rather the 
opposite, namely, that they added provided scope, that we need to adapt to.

Is this where they did what you asked for? 
https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389ebcc019 
- because that's where they removed provided from resteasy but all the 
rest stood provided.

And sorry, that I started to think about the real consequences only when 
I saw your PR.

Thanks,

Peter

> Now we're doing the opposite in our own parent...
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lponce at redhat.com  Mon Jul 20 07:01:49 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 20 Jul 2015 07:01:49 -0400 (EDT)
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
References: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
Message-ID: <1230711123.626881.1437390109017.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jiri Kremser" <jkremser at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, July 20, 2015 12:18:08 PM
> Subject: [Hawkular-dev] IFTTT alert notifications
> 
> Hello,
>   if you don't know the ifttt, it's simple site where you can define a
>   trigger condition and then some action if the condition is met. It's a
>   closed source software (no need to pay though), but the number of possible
>   actions is enormous. I'd say it's industrial standard for this kind of
>   problems. They provide a way to trigger the action manually by sending
>   http POST to their api.
> 
> It's described here:
> 
> https://ifttt.com/maker
> 
> 
> The post request looks like this:
> 
> `curl -X POST -H "Content-Type: application/json" -d
> '{"value1":"1","value2":"2","value3":"foo"}'
> https://maker.ifttt.com/trigger/sdf/with/key/aabbccddeeffgghh`
> 
> where sdf is the name of the event (must be defined via their website),
> aabbcc.. is the secret token for the user and valueN:n in the json is the
> arbitrary data you can then use inside the actions. For instance in the
> subject of the email or whatever the action allows.
> 
> So, if we add a new alert notification that can do such a post request we can
> get for free all these actions:
> 
> https://ifttt.com/recipes/do
> 
> Again, the if-condition-then-action rule must be defined via their website
> (if condition is called 'maker' in this case), the actions use the oauth so
> it asks for permission if needed. For instance I use it for pushbullet
> notifications so It asked pushbulet "auth api"
> 
> wdyt?
> 

It could be interesting to take a look to take ideas.

Perhaps the most logical step is to put in the long term roadmap to add an action plugin to have some kind of integration in the future.



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

From jkremser at redhat.com  Mon Jul 20 07:37:18 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Mon, 20 Jul 2015 07:37:18 -0400 (EDT)
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
References: <3558605.42pKLLLTHY@localhost.localdomain>
	<1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
Message-ID: <767233477.272810.1437392238096.JavaMail.zimbra@redhat.com>

Hi,
  the changes to the ui are done in the integration branch here https://github.com/hawkular/hawkular/tree/dev/inventory-0.2.0.Alpha1
..and the changes to the agent are done in here https://github.com/hawkular/hawkular-agent/pull/23 (travis fails because of the nonexistant feedcomm module). There is also an integration for the agent on hawkular/hawkular so I suggest create just one branch for both inventory.next and agent.next to simplify it. I have the common branch in my private fork here https://github.com/Jiri-Kremser/hawkular/tree/agent-0.3.1-with-inventory-0.2.0 and I can make it public in hawkular/hawkular, what do you think?

Oh, and there is another topic, agent-0.3.1 depends on metrics 0.5.0-SNAPSHOT, so I guess we should sync also with 0.5.0 metrics release.

jk

----- Original Message -----
| From: "John Mazzitelli" <mazz at redhat.com>
| To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
| Sent: Tuesday, 14 July, 2015 1:57:22 AM
| Subject: Re: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
| 
| FYI: There are lots of changes going in the agent wrt server-agent comm right
| now. You'll need to let me know what needs to change in the agent - I'm
| afraid we're going to have some bad conflicts if we aren't careful.
| 
| ----- Original Message -----
| > Hi all,
| > 
| > I plan to release inventory 0.2.0.Alpha1 soonish because it would be good
| > for
| > it to take some soak time in Hawkular prior to the next milestone. The main
| > reason being the move to Titan and Cassandra as inventory's backend.
| > 
| > The other big(gish) feature is the support for resource hierarchy (at
| > last!)
| > a
| > move to using canonical paths to entities on many places, etc.
| > 
| > In another words, there will be breakage.
| > 
| > I've opened the integration branch in my own fork of Hawkular:
| > 
| > https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
| > 
| > I already made it pass the integration tests. There will need to be changes
| > for Pinger and agent (and possibly for the UI, too) which I am seeking for
| > help with.
| > 
| > I've started working on the agent updates for that branch (which triggered
| > quite a lot of changes on the inventory side to make the transition (and
| > future changes) smoother) but nothing is committed yet for that.
| > 
| > Cheers,
| > 
| > Lukas
| > 
| > _______________________________________________
| > 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 Jul 20 08:08:37 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 20 Jul 2015 14:08:37 +0200
Subject: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
In-Reply-To: <767233477.272810.1437392238096.JavaMail.zimbra@redhat.com>
References: <3558605.42pKLLLTHY@localhost.localdomain>
	<1068791987.16917413.1436831842108.JavaMail.zimbra@redhat.com>
	<767233477.272810.1437392238096.JavaMail.zimbra@redhat.com>
Message-ID: <55ACE4C5.3070906@redhat.com>

Jirko, I released Inventory 0.2.0.Alpha1 a couple of hours ago, now 
writing the release notes.

 > agent-0.3.1 depends on metrics 0.5.0-SNAPSHOT

That is unfortunate. How deep is that dependence? I'd prefer to get 
Inventory 0.2.0.Alpha1 and agent-0.3.1 to hk master ASAP, without 
needing to wait for the release of Metrics 0.5.0.

-- P

On 2015-07-20 13:37, Jiri Kremser wrote:
> Hi,
>    the changes to the ui are done in the integration branch here https://github.com/hawkular/hawkular/tree/dev/inventory-0.2.0.Alpha1
> ..and the changes to the agent are done in here https://github.com/hawkular/hawkular-agent/pull/23 (travis fails because of the nonexistant feedcomm module). There is also an integration for the agent on hawkular/hawkular so I suggest create just one branch for both inventory.next and agent.next to simplify it. I have the common branch in my private fork here https://github.com/Jiri-Kremser/hawkular/tree/agent-0.3.1-with-inventory-0.2.0 and I can make it public in hawkular/hawkular, what do you think?
>
> Oh, and there is another topic, agent-0.3.1 depends on metrics 0.5.0-SNAPSHOT, so I guess we should sync also with 0.5.0 metrics release.
>
> jk
>
> ----- Original Message -----
> | From: "John Mazzitelli" <mazz at redhat.com>
> | To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> | Sent: Tuesday, 14 July, 2015 1:57:22 AM
> | Subject: Re: [Hawkular-dev] Integration branch for Inventory 0.2.0.Alpha1
> |
> | FYI: There are lots of changes going in the agent wrt server-agent comm right
> | now. You'll need to let me know what needs to change in the agent - I'm
> | afraid we're going to have some bad conflicts if we aren't careful.
> |
> | ----- Original Message -----
> | > Hi all,
> | >
> | > I plan to release inventory 0.2.0.Alpha1 soonish because it would be good
> | > for
> | > it to take some soak time in Hawkular prior to the next milestone. The main
> | > reason being the move to Titan and Cassandra as inventory's backend.
> | >
> | > The other big(gish) feature is the support for resource hierarchy (at
> | > last!)
> | > a
> | > move to using canonical paths to entities on many places, etc.
> | >
> | > In another words, there will be breakage.
> | >
> | > I've opened the integration branch in my own fork of Hawkular:
> | >
> | > https://github.com/metlos/hawkular/tree/dev/inventory-0.2.0.Alpha1
> | >
> | > I already made it pass the integration tests. There will need to be changes
> | > for Pinger and agent (and possibly for the UI, too) which I am seeking for
> | > help with.
> | >
> | > I've started working on the agent updates for that branch (which triggered
> | > quite a lot of changes on the inventory side to make the transition (and
> | > future changes) smoother) but nothing is committed yet for that.
> | >
> | > Cheers,
> | >
> | > Lukas
> | >
> | > _______________________________________________
> | > 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  Mon Jul 20 08:36:27 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 20 Jul 2015 14:36:27 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55ACD027.2010504@redhat.com>
References: <5588192F.3030906@redhat.com>
	<5596A1AD.2040402@redhat.com>	<55A4ED29.2020109@redhat.com>
	<55ACB605.5070501@redhat.com> <55ACD027.2010504@redhat.com>
Message-ID: <55ACEB4B.4020509@redhat.com>

Le 20/07/2015 12:40, Peter Palaga a ?crit :
> In my last message I claim to have shown that it is effectivelly 100% of
> components. Which specific project "needs to escape" from your point of
> view?

100% of components have at least one module to be deployed in Hawkular. 
But then there are modules meant to run out of Hawkular (ptrans in 
Metrics) or relevant to development only (rest-tests, load-testing, 
Openshift v3 tests).

> Sorry, I must have overseen that you were asking WF team to remove the
> scopes from their management. From your mails understood rather the
> opposite, namely, that they added provided scope, that we need to adapt to.

Not sure how that could have been made easier to read, my original email 
ends with "Going forward, I propose that we no longer "import" the BOM 
in Hawkular parent".

> Is this where they did what you asked for?
> https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389ebcc019
> - because that's where they removed provided from resteasy but all the
> rest stood provided.

Yes. There was an agreement that the changes made to the Resteasy 
section were wrong. They didn't change the rest because (I'm 
paraphrasing) the BOM is meant to be imported by WAR/JAR/EAR modules to 
be deployed to Wildfly.

> And sorry, that I started to think about the real consequences only when
> I saw your PR.

OK. What's next? Are you going to reopen a PR in parent POM to remove 
the import scope?

From mazz at redhat.com  Mon Jul 20 09:16:23 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 20 Jul 2015 09:16:23 -0400 (EDT)
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a
 resource ID?
In-Reply-To: <2417221.uLVapvDglr@localhost.localdomain>
References: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
	<2417221.uLVapvDglr@localhost.localdomain>
Message-ID: <1189861876.744129.1437398183220.JavaMail.zimbra@redhat.com>

This is important to know from a UI perspective. Right now, I store the resource ID under the tenant ID.

The UI (IIRC) only has the resource ID. From what you just said Lukas, that doesn't seem like its unique enough.

This might be an issue with the UI.

----- Original Message -----
> In Inventory 0.2.0.Alpha1 which I am about to release today if no breakage
> was
> discovered during my absence:
> 
> If you have the resource java object, which I think you have in agent, you
> simply do:
> 
> resourceObject.getPath().ids().getFeedId();
> 
> Long version:
> 
> All inventory entities now store a "canonical path" which is a path going
> down
> from tenant do the entity in question following the "contains" relationships.
> 
> The above call will take the resource object's path analyze it using the
> "ids()" call and will return the feed id, if the resource is contained within
> a feed or null, if the resource lives directly under an environment.
> 
> Also if you just store the resource ID, remember that that is only "locally
> unique" within your feed, so to reliably get the correct resource, you only
> can search for it within the feed:
> 
> inventory.tenants().getAll("asdf").environments().get("asf").feeds("myfeed")
> .resources().get("resource-id");
> 
> If you also store the canonical path of the resource, you could do:
> 
> inventory.inspect(CanonicalPath.fromString("resource-path"),
> Resources.Single.class);
> 
> which would return to you the same access object as the above call.
> 
> So when you create your resource, you supply locally unique id, and can use
> the access object returned from the create method to get the newly created
> resource which will contain its full canonical path and all the other
> details.
> 
> On Friday, July 17, 2015 15:11:42 John Mazzitelli wrote:
> > To the inventory folks: is there an API that gives me a feed ID if all I
> > know is a resource ID? If there is no API, can I get one? :)
> > 
> > We'll need a way to determine what feed is responsible for managing what
> > parts of the inventory. So, given that clients like the UI will only know
> > about things like resource ID, that's all they will be able to give the
> > kettle - but the server-side components will need to take that resource ID
> > and get its associated feed ID so it can pass messages to the feed that is
> > managing that resource. _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 

From mazz at redhat.com  Mon Jul 20 09:37:36 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 20 Jul 2015 09:37:36 -0400 (EDT)
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a
 resource ID?
In-Reply-To: <3688423.scuZhSToMU@localhost.localdomain>
References: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
	<2417221.uLVapvDglr@localhost.localdomain>
	<1189861876.744129.1437398183220.JavaMail.zimbra@redhat.com>
	<3688423.scuZhSToMU@localhost.localdomain>
Message-ID: <1588317766.775109.1437399456050.JavaMail.zimbra@redhat.com>

I'm not sure how the UI knows the feed ID to use. I'll defer to the UI guys how they do it. I wonder how they get the feed ID to use with the resource ID?

The agent is easy - I know my feed ID :) For the UI, I'm not sure how they know what the agent's feed ID is when talking about my agent's resources (versus the pinger's resources, let's say - or another agent).

----- Original Message -----
> The REST URLs always resembled what is now formalized in the "canonical path"
> of the entities.
> 
> If you accessed resource with ID "a", you never did that just by using that
> "a". You had to mention the tenantID (deduced from the auth info), the
> environmentID (part of the URL) and feedID (if the resource lived under a
> feed). That is precisely what the canonical path contains, too.
> 
> So from the user of the REST interface nothing really changed apart from the
> fact that 0.2.0.Alpha1 supports resource hierarchy (which is expressed as a
> URL path, too).
> 
> On Monday, July 20, 2015 09:16:23 John Mazzitelli wrote:
> > This is important to know from a UI perspective. Right now, I store the
> > resource ID under the tenant ID.
> > 
> > The UI (IIRC) only has the resource ID. From what you just said Lukas, that
> > doesn't seem like its unique enough.
> > 
> > This might be an issue with the UI.
> > 
> > ----- Original Message -----
> > 
> > > In Inventory 0.2.0.Alpha1 which I am about to release today if no
> > > breakage
> > > was
> > > discovered during my absence:
> > > 
> > > If you have the resource java object, which I think you have in agent,
> > > you
> > > simply do:
> > > 
> > > resourceObject.getPath().ids().getFeedId();
> > > 
> > > Long version:
> > > 
> > > All inventory entities now store a "canonical path" which is a path going
> > > down
> > > from tenant do the entity in question following the "contains"
> > > relationships.
> > > 
> > > The above call will take the resource object's path analyze it using the
> > > "ids()" call and will return the feed id, if the resource is contained
> > > within a feed or null, if the resource lives directly under an
> > > environment.
> > > 
> > > Also if you just store the resource ID, remember that that is only
> > > "locally
> > > unique" within your feed, so to reliably get the correct resource, you
> > > only
> > > can search for it within the feed:
> > > 
> > > inventory.tenants().getAll("asdf").environments().get("asf").feeds("myfeed
> > > ") .resources().get("resource-id");
> > > 
> > > If you also store the canonical path of the resource, you could do:
> > > 
> > > inventory.inspect(CanonicalPath.fromString("resource-path"),
> > > Resources.Single.class);
> > > 
> > > which would return to you the same access object as the above call.
> > > 
> > > So when you create your resource, you supply locally unique id, and can
> > > use
> > > the access object returned from the create method to get the newly
> > > created
> > > resource which will contain its full canonical path and all the other
> > > details.
> > > 
> > > On Friday, July 17, 2015 15:11:42 John Mazzitelli wrote:
> > > > To the inventory folks: is there an API that gives me a feed ID if all
> > > > I
> > > > know is a resource ID? If there is no API, can I get one? :)
> > > > 
> > > > We'll need a way to determine what feed is responsible for managing
> > > > what
> > > > parts of the inventory. So, given that clients like the UI will only
> > > > know
> > > > about things like resource ID, that's all they will be able to give the
> > > > kettle - but the server-side components will need to take that resource
> > > > ID
> > > > and get its associated feed ID so it can pass messages to the feed that
> > > > is
> > > > managing that resource. _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 

From hrupp at redhat.com  Mon Jul 20 09:46:58 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 20 Jul 2015 15:46:58 +0200
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a
 resource ID?
In-Reply-To: <1588317766.775109.1437399456050.JavaMail.zimbra@redhat.com>
References: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
	<2417221.uLVapvDglr@localhost.localdomain>
	<1189861876.744129.1437398183220.JavaMail.zimbra@redhat.com>
	<3688423.scuZhSToMU@localhost.localdomain>
	<1588317766.775109.1437399456050.JavaMail.zimbra@redhat.com>
Message-ID: <B4B2E5C6-16A6-4394-A528-7A2CA11B1104@redhat.com>

On 20 Jul 2015, at 15:37, John Mazzitelli wrote:

> I'm not sure how the UI knows the feed ID to use. I'll defer to the UI 
> guys how they do it. I wonder how they get the feed ID to use with the 
> resource ID?

we need a unique resource id and can then inside the server find the
feed id.
IIrc, the resource list inside the UI had the feed
attached but perhaps I remember it wrong.


> The agent is easy - I know my feed ID :) For the UI, I'm not sure how 
> they know what the agent's feed ID is when talking about my agent's 
> resources (versus the pinger's resources, let's say - or another 
> agent).

As the UI never directly talks to any agent, it should not matter too 
much?

From lkrejci at redhat.com  Mon Jul 20 09:58:19 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 20 Jul 2015 15:58:19 +0200
Subject: [Hawkular-dev] inventory API: can I get a feed ID from a
	resource ID?
In-Reply-To: <B4B2E5C6-16A6-4394-A528-7A2CA11B1104@redhat.com>
References: <1544465274.19179924.1437160302907.JavaMail.zimbra@redhat.com>
	<1588317766.775109.1437399456050.JavaMail.zimbra@redhat.com>
	<B4B2E5C6-16A6-4394-A528-7A2CA11B1104@redhat.com>
Message-ID: <1534642.hIBWvHyyXy@localhost.localdomain>

On Monday, July 20, 2015 15:46:58 Heiko W.Rupp wrote:
> On 20 Jul 2015, at 15:37, John Mazzitelli wrote:
> > I'm not sure how the UI knows the feed ID to use. I'll defer to the UI
> > guys how they do it. I wonder how they get the feed ID to use with the
> > resource ID?
> 
> we need a unique resource id and can then inside the server find the
> feed id.
> IIrc, the resource list inside the UI had the feed
> attached but perhaps I remember it wrong.
> 

The canonical path is the unique ID. it has the feed ID encoded in it so no 
need to call server for that.

http://www.hawkular.org/docs/components/inventory/index.html#basic-principles

Also, there is a new REST endpoint:

/hawkular/inventory/path/{canonicalPath}

to which you can directly pass the canonical IDs as part of the URL to 
retrieve the info about any type of entity. No need to extract the environment 
or feed id from the canonical path and then construct the "traditional" REST 
URL from it.

> > The agent is easy - I know my feed ID :) For the UI, I'm not sure how
> > they know what the agent's feed ID is when talking about my agent's
> > resources (versus the pinger's resources, let's say - or another
> > agent).
> 
> As the UI never directly talks to any agent, it should not matter too
> much?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From ppalaga at redhat.com  Mon Jul 20 10:15:17 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 20 Jul 2015 16:15:17 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55ACEB4B.4020509@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com> <55ACB605.5070501@redhat.com>
	<55ACD027.2010504@redhat.com> <55ACEB4B.4020509@redhat.com>
Message-ID: <55AD0275.6@redhat.com>

On 2015-07-20 14:36, Thomas Segismont wrote:
> Le 20/07/2015 12:40, Peter Palaga a ?crit :
>> In my last message I claim to have shown that it is effectivelly 100% of
>> components. Which specific project "needs to escape" from your point of
>> view?
>
> 100% of components have at least one module to be deployed in Hawkular.
> But then there are modules meant to run out of Hawkular (ptrans in
> Metrics) or relevant to development only (rest-tests, load-testing,
> Openshift v3 tests).

Yes, I agree there exist maven modules inside HK componets projects that 
do not consume anything from WF BoM. ptrans is a good example of such 
one. But I am still failing to see what your proposal is going to 
improve in ptrans. WF BoM, regardless if it is imported in parent or 
not, has no influence on ptrans as long as you do not add a dependency 
on something from the WF BoM. ptrans does not depend on anything managed 
in WF BoM, hence there is no impact. The compile class path of ptrans 
and the resulting jar stay the same regardless if WF BoM is imported in 
HK parent or not. I see no impact at all.

I think I understand now how your proposal is supposed to work, but I 
fail to see why it is better than the present state.

Thanks,

-- P

>> Sorry, I must have overseen that you were asking WF team to remove the
>> scopes from their management. From your mails understood rather the
>> opposite, namely, that they added provided scope, that we need to adapt to.
>
> Not sure how that could have been made easier to read, my original email
> ends with "Going forward, I propose that we no longer "import" the BOM
> in Hawkular parent".
>
>> Is this where they did what you asked for?
>> https://github.com/wildfly/boms/commit/9e568fe4eb41d978c3181a90b5bb4d389ebcc019
>> - because that's where they removed provided from resteasy but all the
>> rest stood provided.
>
> Yes. There was an agreement that the changes made to the Resteasy
> section were wrong. They didn't change the rest because (I'm
> paraphrasing) the BOM is meant to be imported by WAR/JAR/EAR modules to
> be deployed to Wildfly.
>
>> And sorry, that I started to think about the real consequences only when
>> I saw your PR.
>
> OK. What's next? Are you going to reopen a PR in parent POM to remove
> the import scope?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Mon Jul 20 10:16:34 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 20 Jul 2015 16:16:34 +0200
Subject: [Hawkular-dev] Inventory 0.2.0.Alpha1 released
Message-ID: <55AD02C2.5000804@redhat.com>

Hi *,

Most important changes:
  * Titan graph DB backend instead of Tinkergraph
  * "Canonical path" which is a path going down from tenant do the
    entity in question following the "contains" relationships. Canonical
    paths are guaranteed to be unique per inventory installation.

Full list of resolved Jiras: 
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315923&version=12327453

We hope that Inventory 0.2.0.Alpha1 reaches Hawkular master soon. The 
changes needed in Hawkular main are ready in dev/inventory-0.2.0.Alpha1 
branch and the ones for Agent should be accepted soon 
https://github.com/hawkular/hawkular-agent/pull/23 The last unsolved 
blocker is that the relevant Agent branch depends on Metrics 
0.5.0-SNAPSHOT and we have no info when it is going to be released.

It was me this time, who released Inventory, just for the sake of making 
sure that the Bus Factor for performing Inventory releases is higher than 1.

Best,

Peter

From tsegismo at redhat.com  Mon Jul 20 11:06:28 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 20 Jul 2015 17:06:28 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AD0275.6@redhat.com>
References: <5588192F.3030906@redhat.com>
	<5596A1AD.2040402@redhat.com>	<55A4ED29.2020109@redhat.com>
	<55ACB605.5070501@redhat.com>	<55ACD027.2010504@redhat.com>
	<55ACEB4B.4020509@redhat.com> <55AD0275.6@redhat.com>
Message-ID: <55AD0E74.9000405@redhat.com>

Le 20/07/2015 16:15, Peter Palaga a ?crit :
> Yes, I agree there exist maven modules inside HK componets projects that
> do not consume anything from WF BoM. ptrans is a good example of such
> one. But I am still failing to see what your proposal is going to
> improve in ptrans. WF BoM, regardless if it is imported in parent or
> not, has no influence on ptrans as long as you do not add a dependency
> on something from the WF BoM. ptrans does not depend on anything managed

"as long as" is the key. When we upgraded from Wildfly BOM version 8 to 
9.CR1, I spent half a day getting down to a build issue in Metrics, 
where the rest-tests module suddenly stopped working, just because the 
new BOM broke dependency resolution.

> in WF BoM, hence there is no impact. The compile class path of ptrans
> and the resulting jar stay the same regardless if WF BoM is imported in
> HK parent or not. I see no impact at all.
>
> I think I understand now how your proposal is supposed to work, but I
> fail to see why it is better than the present state.

It boils down to control of dependency management. With the BOM auto 
imported by the parent, we have to adapt to the Wildfly BOM choices. It 
should not be like this.

From snegrea at redhat.com  Mon Jul 20 11:24:17 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 20 Jul 2015 11:24:17 -0400 (EDT)
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AD0E74.9000405@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com> <55ACB605.5070501@redhat.com>
	<55ACD027.2010504@redhat.com> <55ACEB4B.4020509@redhat.com>
	<55AD0275.6@redhat.com> <55AD0E74.9000405@redhat.com>
Message-ID: <2014447928.650459.1437405857040.JavaMail.zimbra@redhat.com>

Hello,

I agree and support ThomasS proposal primarily because of Hawkular Metrics integration requirements. He has very valid points that fit perfectly in the requirements for the project. I would like to see the proposal implemented as soon as possible. 


Thank you,
Stefan 

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, July 20, 2015 10:06:28 AM
> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
> 
> Le 20/07/2015 16:15, Peter Palaga a ?crit :
> > Yes, I agree there exist maven modules inside HK componets projects that
> > do not consume anything from WF BoM. ptrans is a good example of such
> > one. But I am still failing to see what your proposal is going to
> > improve in ptrans. WF BoM, regardless if it is imported in parent or
> > not, has no influence on ptrans as long as you do not add a dependency
> > on something from the WF BoM. ptrans does not depend on anything managed
> 
> "as long as" is the key. When we upgraded from Wildfly BOM version 8 to
> 9.CR1, I spent half a day getting down to a build issue in Metrics,
> where the rest-tests module suddenly stopped working, just because the
> new BOM broke dependency resolution.
> 
> > in WF BoM, hence there is no impact. The compile class path of ptrans
> > and the resulting jar stay the same regardless if WF BoM is imported in
> > HK parent or not. I see no impact at all.
> >
> > I think I understand now how your proposal is supposed to work, but I
> > fail to see why it is better than the present state.
> 
> It boils down to control of dependency management. With the BOM auto
> imported by the parent, we have to adapt to the Wildfly BOM choices. It
> should not be like this.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From ppalaga at redhat.com  Mon Jul 20 12:50:31 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 20 Jul 2015 18:50:31 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AD0E74.9000405@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com> <55ACB605.5070501@redhat.com>
	<55ACD027.2010504@redhat.com> <55ACEB4B.4020509@redhat.com>
	<55AD0275.6@redhat.com> <55AD0E74.9000405@redhat.com>
Message-ID: <55AD26D7.20202@redhat.com>

On 2015-07-20 17:06, Thomas Segismont wrote:
> Le 20/07/2015 16:15, Peter Palaga a ?crit :
>> Yes, I agree there exist maven modules inside HK componets projects that
>> do not consume anything from WF BoM. ptrans is a good example of such
>> one. But I am still failing to see what your proposal is going to
>> improve in ptrans. WF BoM, regardless if it is imported in parent or
>> not, has no influence on ptrans as long as you do not add a dependency
>> on something from the WF BoM. ptrans does not depend on anything managed
>
> "as long as" is the key. When we upgraded from Wildfly BOM version 8 to
> 9.CR1, I spent half a day getting down to a build issue in Metrics,
> where the rest-tests module suddenly stopped working, just because the
> new BOM broke dependency resolution.

I can follow how hard it was to resolve the issue caused by WF BoM. But 
anyway, even if WF BoM was not imported in HK parent, are you not going 
to keep using the resteasy managed by WF BoM in rest-tests through 
keeping it imported somewhere in the rest-tests pom hierarchy?

You maybe prefer to manage the resteasy client version yourself? - 
because otherwise, I do not see how not having WF BoM imported in HK 
parent would improve something important for you.

>> in WF BoM, hence there is no impact. The compile class path of ptrans
>> and the resulting jar stay the same regardless if WF BoM is imported in
>> HK parent or not. I see no impact at all.
>>
>> I think I understand now how your proposal is supposed to work, but I
>> fail to see why it is better than the present state.
>
> It boils down to control of dependency management. With the BOM auto
> imported by the parent, we have to adapt to the Wildfly BOM choices.

Yes, that's true that we loose some control but the gain is that we do 
not need to manage the versions of artifacts they manage.

You claim that there are modules where it is harmful. But which ones? In 
ptrans, it is harmless, IMO (no dependency -> no problem). In 
rest-tests, you probably keep WF BoM included anyway, so removing the WF 
BoM include from HK Parent does not change anything. Is there any other 
module where the WF BoM include in Parent causes a problem?

Thanks,

-- P

> It
> should not be like this.



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


From jshaughn at redhat.com  Mon Jul 20 17:34:09 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 20 Jul 2015 17:34:09 -0400
Subject: [Hawkular-dev] 0.3.0.Final of Hawkular Alerts
Message-ID: <55AD6951.9050403@redhat.com>


We're happy to announce 0.3.0.Final of Hawkular Alerts.   A bunch of 
good stuff this time around, here are the relevant Jiras and a few 
highlight blurbs:

** Enhancement
     * [HWKALERTS-17] - Refactor to eliminate EE dependencies of EJB3

     Now packaged as a WAR as opposed to an EAR, for easier consumption 
in another EAR.

     * [HWKALERTS-50] - Integrate with Hawkular Metrics

     A value-add External Alerter deployment (WAR)  that adds more 
alerting power when integrated with Hawkular Metrics.  Thanks to John 
Sanda for his help.

     * [HWKALERTS-52] - Hooks for external alerts

     A mechanism for integrating External Alerters into Hawkular 
Alerts.  Allows external clients to leverage the Hawkular Alerts Trigger 
and Action infrastructure.

     * [HWKALERTS-57] - Improve the way actions plugins access 
information related to an alert

     Now Actions and Notifiers have full access (via JSON) to the Alert 
details.

     * [HWKALERTS-59] - Review if 204 return code can be changed to an 
empty list

     API CHANGE! Get Alerts now returns and empty list as opposed to 204 
when the criteria results in in no alerts.

     * [HWKALERTS-60] - Review end point for alert resolution

     New REST endpoints for Ack or Resolve of a single alert.

     * [HWKALERTS-62] - Allow any data to store contextual information

     Optionally Store a Map of context data with any datum sent into 
alerts for evaluation.  Then use that context info in your actions.

     * [HWKALERTS-65] - Adapt email plugin to support multiple 
conditions and multiple states

     Big enhancements in e-mail notifier for rich messages at different 
life-cycle points.

     * [HWKALERTS-67] - Update gson dependencies with jackson

     Remove use of GSON, now depends on fasterxml provided by Wildfly.

** Feature Request
     * [HWKALERTS-64] - Enable trigger on alert resolution

     - Now can AutoEnable an [Auto]Disabled Trigger when its alerts are 
resolved.
     - Now automatically returns an AutoResolve Trigger  to firing mode 
when its alerts are manually resolved.


Please contact us with any questions, comments or contributions!

Jay Shaughnessy  (jshaughn at redhat.com)
Lucas Ponce (lponce at redhat.com)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150720/4e19f082/attachment-0001.html 

From snegrea at redhat.com  Tue Jul 21 01:48:26 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 21 Jul 2015 01:48:26 -0400 (EDT)
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AD26D7.20202@redhat.com>
References: <5588192F.3030906@redhat.com> <55A4ED29.2020109@redhat.com>
	<55ACB605.5070501@redhat.com> <55ACD027.2010504@redhat.com>
	<55ACEB4B.4020509@redhat.com> <55AD0275.6@redhat.com>
	<55AD0E74.9000405@redhat.com> <55AD26D7.20202@redhat.com>
Message-ID: <1778312223.1085878.1437457706091.JavaMail.zimbra@redhat.com>

Peter, 

What would be a good argument to implement the removal of <scope>import</scope> as proposed by Thomas?


Thank you,
Stefan


----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, July 20, 2015 11:50:31 AM
> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
> 
> On 2015-07-20 17:06, Thomas Segismont wrote:
> > Le 20/07/2015 16:15, Peter Palaga a ?crit :
> >> Yes, I agree there exist maven modules inside HK componets projects that
> >> do not consume anything from WF BoM. ptrans is a good example of such
> >> one. But I am still failing to see what your proposal is going to
> >> improve in ptrans. WF BoM, regardless if it is imported in parent or
> >> not, has no influence on ptrans as long as you do not add a dependency
> >> on something from the WF BoM. ptrans does not depend on anything managed
> >
> > "as long as" is the key. When we upgraded from Wildfly BOM version 8 to
> > 9.CR1, I spent half a day getting down to a build issue in Metrics,
> > where the rest-tests module suddenly stopped working, just because the
> > new BOM broke dependency resolution.
> 
> I can follow how hard it was to resolve the issue caused by WF BoM. But
> anyway, even if WF BoM was not imported in HK parent, are you not going
> to keep using the resteasy managed by WF BoM in rest-tests through
> keeping it imported somewhere in the rest-tests pom hierarchy?
> 
> You maybe prefer to manage the resteasy client version yourself? -
> because otherwise, I do not see how not having WF BoM imported in HK
> parent would improve something important for you.
> 
> >> in WF BoM, hence there is no impact. The compile class path of ptrans
> >> and the resulting jar stay the same regardless if WF BoM is imported in
> >> HK parent or not. I see no impact at all.
> >>
> >> I think I understand now how your proposal is supposed to work, but I
> >> fail to see why it is better than the present state.
> >
> > It boils down to control of dependency management. With the BOM auto
> > imported by the parent, we have to adapt to the Wildfly BOM choices.
> 
> Yes, that's true that we loose some control but the gain is that we do
> not need to manage the versions of artifacts they manage.
> 
> You claim that there are modules where it is harmful. But which ones? In
> ptrans, it is harmless, IMO (no dependency -> no problem). In
> rest-tests, you probably keep WF BoM included anyway, so removing the WF
> BoM include from HK Parent does not change anything. Is there any other
> module where the WF BoM include in Parent causes a problem?
> 
> Thanks,
> 
> -- P
> 
> > It
> > should not be like this.
> 
> 
> 
> > _______________________________________________
> > 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  Tue Jul 21 02:35:33 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 21 Jul 2015 08:35:33 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AD26D7.20202@redhat.com>
References: <5588192F.3030906@redhat.com> <5596A1AD.2040402@redhat.com>
	<55A4ED29.2020109@redhat.com> <55ACB605.5070501@redhat.com>
	<55ACD027.2010504@redhat.com> <55ACEB4B.4020509@redhat.com>
	<55AD0275.6@redhat.com> <55AD0E74.9000405@redhat.com>
	<55AD26D7.20202@redhat.com>
Message-ID: <55ADE835.8090903@redhat.com>

Le 20/07/2015 18:50, Peter Palaga a ?crit :
> On 2015-07-20 17:06, Thomas Segismont wrote:
> I can follow how hard it was to resolve the issue caused by WF BoM. But
> anyway, even if WF BoM was not imported in HK parent, are you not going
> to keep using the resteasy managed by WF BoM in rest-tests through
> keeping it imported somewhere in the rest-tests pom hierarchy?
>
> You maybe prefer to manage the resteasy client version yourself? -
> because otherwise, I do not see how not having WF BoM imported in HK
> parent would improve something important for you.

Exactly, managing it manually, because we just want to consume RESTEasy 
client in a pure itest module.

> Yes, that's true that we loose some control but the gain is that we do
> not need to manage the versions of artifacts they manage.

Have I ever minimized the gain for WAR/EAR modules?

> You claim that there are modules where it is harmful. But which ones? In

I've told you already: it *has been* harmful in rest-tests module. Now 
of course we haven't stopped working because master was failing and we 
did what was required to fix the issue.

> ptrans, it is harmless, IMO (no dependency -> no problem). In
> rest-tests, you probably keep WF BoM included anyway, so removing the WF
> BoM include from HK Parent does not change anything. Is there any other
> module where the WF BoM include in Parent causes a problem?

Peter, I've been explaining the issue multiple times, and you're asking 
me the same question again.

So maybe you don't read your emails with enough attention. Or you just 
don't feel like something discussed here, on IRC and in meetings can be 
merged in the parent POM.

From hrupp at redhat.com  Tue Jul 21 05:38:58 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 21 Jul 2015 11:38:58 +0200
Subject: [Hawkular-dev] Release cadence
Message-ID: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>

Hey

I have observed that our current Hawkular cadence of 4 weeks
with similar cadences of components makes us end up with 
long living integration branches and a larger rush near the
end to integrate them, get them for the first time tested in CI
and even for the first time tested in real world.

In one of the last releases there was a changed implementation 
in one component, that basically turned out as a no-op and 
still returned a "200 OK" code, so clients thought everything is
happy, but it was not. We found the issue (through ppl looking
at the UI) and solved it, but it was in a rush.

This certainly goes against all the ideas of "release early, release 
often", "cut small slices", "changes go into CI/CD and go live quickly".
Remember the coin flipping ?

Ideally we would always be able to integrate changes from 
components into Hawkular (main), but I understand that with the
way maven and its release process to central works, it is also not 
ideal to release many versions per day.

With all of the above in mind, I propose that we move to a 
"at least once per week" model, where we do a component release
at least once per week(*), which then in the four week stream form
a new Alpha release. The smaller releases do not need release notes,
I don't care if we use the micro number or a .AlphaY designator on
them, but they should be a release, that is not a (named) snapshot.
This will allow us to still have less efforts to do releases, but 
keep being (more) agile and have earlier integrations and thus 
less long living integration branches.

On top of that, we need to provide new and/or changed apis(**)
early on in the 4 weeks cadence so that other components can 
already start calling them, even if they are not yet functionally
complete.

*) Of course only if a change to the component has been made.
**) Ideally with changed apis, we keep the old version around for
  a bit and offer the new version on top. Remember, that especially
  with non-compiletime bindings, we can not know which client is
  at what api version.

From tsegismo at redhat.com  Tue Jul 21 05:43:54 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 21 Jul 2015 11:43:54 +0200
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next steps
Message-ID: <55AE145A.4000008@redhat.com>

Hi,

I have looked at Aakarsh's repo:
https://github.com/Akki5/hawkular_plugin/

It's a good start with an interface describing a doubles to double 
function, a classloader for implementation loading and a set of initial 
implementations.

In order to integrate this work into Metrics, I think we should follow 
the following steps:

=====
#1 Change the contract

Doubles to double works great for avg/min/max/... functions on gauge 
metrics. But we need to consider other metric types.

Also, the interface should not only accept data point values, but whole 
data points. Because some functions need the timestamp to compute the 
result. % of up availability is a good example.

And functions may return different types: Double, Long, AvailabilityType.

#2 Update configuration options to let the user set a plugins directory

Metrics doc needs will have to be updated.

#3 Create a function repository for each metric type

We can build on JDK's service loader + Aakarsh's classloader implementation.

#4 Add builtin aggregate functions

Extract existing Metrics code (min, max, avg, % of up avail, downtime 
duration) into builtin functions.

#5 Document the process of implementing a pluggable function

We need to think about function naming as well. Should we use a prefix 
to identify a builtin function?
=====

I will start another thread to discuss REST and Core API data query changes.

Thoughts?

Thanks,
Thomas

From lkrejci at redhat.com  Tue Jul 21 08:26:21 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 21 Jul 2015 14:26:21 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55ADE835.8090903@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
Message-ID: <1972038.7lySs3RSGz@localhost.localdomain>

So wait a minute.

The changed dependency "suddenly" broke your rest tests.

IMHO, that is good in a sense that you now know something new about being 
deployed in another runtime environment (namely WF9) which metrics WILL BE 
deployed into.

Can it be painful? Yes, we've all been through such things. Is it avoidable? I 
don't think so.

The versions of the modules coming from the Hawkular parent are what Hawkular 
as whole standardizes on. You should not care about where they actually come 
from (and the fact that they come from WF bom is a good thing, btw).

If you open the door for individual modules having non-standard versions of 
dependencies, you know where we're going to end up.

I feel your pain, but please - standardization is more important that 
occasional troubles of a single component.

On Tuesday, July 21, 2015 08:35:33 Thomas Segismont wrote:
> Le 20/07/2015 18:50, Peter Palaga a ?crit :
> > On 2015-07-20 17:06, Thomas Segismont wrote:
> > I can follow how hard it was to resolve the issue caused by WF BoM. But
> > anyway, even if WF BoM was not imported in HK parent, are you not going
> > to keep using the resteasy managed by WF BoM in rest-tests through
> > keeping it imported somewhere in the rest-tests pom hierarchy?
> > 
> > You maybe prefer to manage the resteasy client version yourself? -
> > because otherwise, I do not see how not having WF BoM imported in HK
> > parent would improve something important for you.
> 
> Exactly, managing it manually, because we just want to consume RESTEasy
> client in a pure itest module.
> 
> > Yes, that's true that we loose some control but the gain is that we do
> > not need to manage the versions of artifacts they manage.
> 
> Have I ever minimized the gain for WAR/EAR modules?
> 
> > You claim that there are modules where it is harmful. But which ones? In
> 
> I've told you already: it *has been* harmful in rest-tests module. Now
> of course we haven't stopped working because master was failing and we
> did what was required to fix the issue.
> 
> > ptrans, it is harmless, IMO (no dependency -> no problem). In
> > rest-tests, you probably keep WF BoM included anyway, so removing the WF
> > BoM include from HK Parent does not change anything. Is there any other
> > module where the WF BoM include in Parent causes a problem?
> 
> Peter, I've been explaining the issue multiple times, and you're asking
> me the same question again.
> 
> So maybe you don't read your emails with enough attention. Or you just
> don't feel like something discussed here, on IRC and in meetings can be
> merged in the parent POM.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From hrupp at redhat.com  Tue Jul 21 08:44:33 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 21 Jul 2015 14:44:33 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <1972038.7lySs3RSGz@localhost.localdomain>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
Message-ID: <D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>

On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
> I feel your pain, but please - standardization is more important that
> occasional troubles of a single component.

+5

From jshaughn at redhat.com  Tue Jul 21 09:12:23 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 21 Jul 2015 09:12:23 -0400
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
Message-ID: <55AE4537.8090000@redhat.com>


Too much snark in this thread.

Is there a way that it can remain in the parent pom yet be 
overridden/excluded as desired/required by metrics?  Maven typically 
prefers the locally decl over an inherited decl.


On 7/21/2015 8:44 AM, Heiko W.Rupp wrote:
> On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
>> I feel your pain, but please - standardization is more important that
>> occasional troubles of a single component.
> +5
> _______________________________________________
> 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/20150721/33fca90a/attachment.html 

From jshaughn at redhat.com  Tue Jul 21 09:24:31 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 21 Jul 2015 09:24:31 -0400
Subject: [Hawkular-dev] Inventory 0.2.0.Alpha1 released
In-Reply-To: <55AD02C2.5000804@redhat.com>
References: <55AD02C2.5000804@redhat.com>
Message-ID: <55AE480F.4090500@redhat.com>



On 7/20/2015 10:16 AM, Peter Palaga wrote:
> https://github.com/hawkular/hawkular-agent/pull/23 The last unsolved
> blocker is that the relevant Agent branch depends on Metrics
> 0.5.0-SNAPSHOT and we have no info when it is going to be released.
>
This has been shared many times, but the metrics team posts the 
scheduled next release date in their versions list on Jira: 
https://issues.jboss.org/browse/HWKMETRICS/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel.

Having said that, we may want to look at the metrics release schedule 
wrt the hawkular release schedule.  Because it's not helpful to have a 
component release scheduled 2 days before the project release.  We need 
to be looking at component releases with a 7-10 day lead time, as we 
discussed in the Hawkular M1 retro.  Of course, given that our master 
branches should be releasable at any time, as needed any component 
should be able to provide a release as needed to ensure Hawkular stays 
on target.


From snegrea at redhat.com  Tue Jul 21 09:50:36 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 21 Jul 2015 09:50:36 -0400 (EDT)
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
Message-ID: <40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>

Hello,

There are two issues that get interlaced here and should not be. One is to release individual components on a schedule, and second is making sure that all the components integrate nicely. Your proposal with "at least one release per week" is trying to fix a fix of a fix of previous decision. And in this mix, the two concepts of release and integration get so interlocked that we cannot make heads and tail.

Here is the progression of things:

Problem 1: monolithic code is bad, we need to componentize everything. Solution: create single purpose repositories, which resulted in about 20 repositories. 

Problem 2: how do we integrate all those components? Solution: create a Hawkular repository that depends on all the other repositories.

Problem 3: integrated project idea works, but how do we really really integrate the code? Solution: publish changes in subcomponents as soon as possible.

Problem 4: publishing changes in components takes a long time, can we expedite the process and get changes even faster to integrated project? Solution: automate SNAPSHOT publication so you have freshly build binaries on almost every change.

Problem 5: We need consistent builds for the integrated project. Solution: master branch in the integrated project only depends on released version of components, feature branches are short lived.

Problem 6: It is almost impossible to align all the release of components and give enough runaway for the integrated project to ingest all the release subcomponets, especially since there inter-dependencies on the sub-projects themselves. Solution: publish sub-components officially at least once per week.

Problem 7: There are major changes that are needed right-away in the integrated project. Solution: officially publish components more often than once per week. Publish as soon as the features makes it in. In fact, let's publish Alphas (Alphaxx) with every single change.

Problem 8: Too many releases, it takes too much time to administer the process of releasing. Solution: Automate the release dependency management, emulate the SNAPSHOT injection concept but with Alpha "moniker".

Problem 9: It is a nightmare to maintain on which version to depend on the integrate project or components that depend on other components. Solution: ??

Problem 10: It is almost impossible to trace back the code that code that goes into the integrated project because there are so many Alphas. Solution: ???


We are at level 5; from 6 forward I see them coming, just as I saw the rest of 5. At what point do we stop and say "wait a second! what we doing here? can we simplify all this??" From my perspective, we are arbitrarily setting requirements just to complicate things. There is always a happy medium and there is always ways to simplify. I would much rather think for 2 months on how to simplify things and do it once, then stack problems that make our lives harder for no reason. 


That being said, I am not against implementing your proposed solution in Hawkular Metrics. But I see two possible paths. One, escalate and resolve problems 6, and 7 at the same time with automation. That is primarily because we are so thin on resources and so stretched that we do not have time to not automate this. Two, get a release engineer (or another engineer) allocated to the team that will take care of these releases. If we are to proceed with your current proposal please let us know which one of these paths do you want Hawkular Metrics to take.


At the same time, we can take the reversed path; rather than escalate problems, remove them from that stack. Why not look to simplify everything, revert a few problems and try to improve our productivity. We can revert to the use of SNAPSHOTS. In what capacity? Let's find the path that gives us the most benefits with the least amount of work.


Thank you,
Stefan

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 21, 2015 4:38:58 AM
> Subject: [Hawkular-dev] Release cadence
> 
> Hey
> 
> I have observed that our current Hawkular cadence of 4 weeks
> with similar cadences of components makes us end up with
> long living integration branches and a larger rush near the
> end to integrate them, get them for the first time tested in CI
> and even for the first time tested in real world.
> 
> In one of the last releases there was a changed implementation
> in one component, that basically turned out as a no-op and
> still returned a "200 OK" code, so clients thought everything is
> happy, but it was not. We found the issue (through ppl looking
> at the UI) and solved it, but it was in a rush.
> 
> This certainly goes against all the ideas of "release early, release
> often", "cut small slices", "changes go into CI/CD and go live quickly".
> Remember the coin flipping ?
> 
> Ideally we would always be able to integrate changes from
> components into Hawkular (main), but I understand that with the
> way maven and its release process to central works, it is also not
> ideal to release many versions per day.
> 
> With all of the above in mind, I propose that we move to a
> "at least once per week" model, where we do a component release
> at least once per week(*), which then in the four week stream form
> a new Alpha release. The smaller releases do not need release notes,
> I don't care if we use the micro number or a .AlphaY designator on
> them, but they should be a release, that is not a (named) snapshot.
> This will allow us to still have less efforts to do releases, but
> keep being (more) agile and have earlier integrations and thus
> less long living integration branches.
> 
> On top of that, we need to provide new and/or changed apis(**)
> early on in the 4 weeks cadence so that other components can
> already start calling them, even if they are not yet functionally
> complete.
> 
> *) Of course only if a change to the component has been made.
> **) Ideally with changed apis, we keep the old version around for
>   a bit and offer the new version on top. Remember, that especially
>   with non-compiletime bindings, we can not know which client is
>   at what api version.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Tue Jul 21 10:06:27 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 21 Jul 2015 10:06:27 -0400 (EDT)
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
	<40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
Message-ID: <2010022920.1561404.1437487587243.JavaMail.zimbra@redhat.com>

Each repo needs to have a "dev/latest" branch. Should the component need them, the pom.xml files in those dev/latest branches can refer to the latest-n-greatest snapshot versions of components (we can have travis publish the snapshot builds from these dev/latest branches). Therefore, if you want the latest-n-greatest to test integration, switch to dev/latest branches and build them locally.

If you want a released version that never changes go to the master branch (which is the latest release) or go to one of the release tags and build from that.

Once we are getting ready to prepare for a release, we create PRs to merge dev/latest to master, changing the poms to the release versions that are needed.

How long between merging dev/latest to master and release? I dunno. If we do this right, we won't need a quick 1-week turnaround time. Every 2-weeks? 3-weeks? keep it a month? I don't know. Make something up. I vote every 17 days - only because its just as arbitrary as any other time period we might pick :)

----- Original Message -----
> Hello,
> 
> There are two issues that get interlaced here and should not be. One is to
> release individual components on a schedule, and second is making sure that
> all the components integrate nicely. Your proposal with "at least one
> release per week" is trying to fix a fix of a fix of previous decision. And
> in this mix, the two concepts of release and integration get so interlocked
> that we cannot make heads and tail.
> 
> Here is the progression of things:
> 
> Problem 1: monolithic code is bad, we need to componentize everything.
> Solution: create single purpose repositories, which resulted in about 20
> repositories.
> 
> Problem 2: how do we integrate all those components? Solution: create a
> Hawkular repository that depends on all the other repositories.
> 
> Problem 3: integrated project idea works, but how do we really really
> integrate the code? Solution: publish changes in subcomponents as soon as
> possible.
> 
> Problem 4: publishing changes in components takes a long time, can we
> expedite the process and get changes even faster to integrated project?
> Solution: automate SNAPSHOT publication so you have freshly build binaries
> on almost every change.
> 
> Problem 5: We need consistent builds for the integrated project. Solution:
> master branch in the integrated project only depends on released version of
> components, feature branches are short lived.
> 
> Problem 6: It is almost impossible to align all the release of components and
> give enough runaway for the integrated project to ingest all the release
> subcomponets, especially since there inter-dependencies on the sub-projects
> themselves. Solution: publish sub-components officially at least once per
> week.
> 
> Problem 7: There are major changes that are needed right-away in the
> integrated project. Solution: officially publish components more often than
> once per week. Publish as soon as the features makes it in. In fact, let's
> publish Alphas (Alphaxx) with every single change.
> 
> Problem 8: Too many releases, it takes too much time to administer the
> process of releasing. Solution: Automate the release dependency management,
> emulate the SNAPSHOT injection concept but with Alpha "moniker".
> 
> Problem 9: It is a nightmare to maintain on which version to depend on the
> integrate project or components that depend on other components. Solution:
> ??
> 
> Problem 10: It is almost impossible to trace back the code that code that
> goes into the integrated project because there are so many Alphas. Solution:
> ???
> 
> 
> We are at level 5; from 6 forward I see them coming, just as I saw the rest
> of 5. At what point do we stop and say "wait a second! what we doing here?
> can we simplify all this??" From my perspective, we are arbitrarily setting
> requirements just to complicate things. There is always a happy medium and
> there is always ways to simplify. I would much rather think for 2 months on
> how to simplify things and do it once, then stack problems that make our
> lives harder for no reason.
> 
> 
> That being said, I am not against implementing your proposed solution in
> Hawkular Metrics. But I see two possible paths. One, escalate and resolve
> problems 6, and 7 at the same time with automation. That is primarily
> because we are so thin on resources and so stretched that we do not have
> time to not automate this. Two, get a release engineer (or another engineer)
> allocated to the team that will take care of these releases. If we are to
> proceed with your current proposal please let us know which one of these
> paths do you want Hawkular Metrics to take.
> 
> 
> At the same time, we can take the reversed path; rather than escalate
> problems, remove them from that stack. Why not look to simplify everything,
> revert a few problems and try to improve our productivity. We can revert to
> the use of SNAPSHOTS. In what capacity? Let's find the path that gives us
> the most benefits with the least amount of work.
> 
> 
> Thank you,
> Stefan
> 
> ----- Original Message -----
> > From: "Heiko W.Rupp" <hrupp at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Tuesday, July 21, 2015 4:38:58 AM
> > Subject: [Hawkular-dev] Release cadence
> > 
> > Hey
> > 
> > I have observed that our current Hawkular cadence of 4 weeks
> > with similar cadences of components makes us end up with
> > long living integration branches and a larger rush near the
> > end to integrate them, get them for the first time tested in CI
> > and even for the first time tested in real world.
> > 
> > In one of the last releases there was a changed implementation
> > in one component, that basically turned out as a no-op and
> > still returned a "200 OK" code, so clients thought everything is
> > happy, but it was not. We found the issue (through ppl looking
> > at the UI) and solved it, but it was in a rush.
> > 
> > This certainly goes against all the ideas of "release early, release
> > often", "cut small slices", "changes go into CI/CD and go live quickly".
> > Remember the coin flipping ?
> > 
> > Ideally we would always be able to integrate changes from
> > components into Hawkular (main), but I understand that with the
> > way maven and its release process to central works, it is also not
> > ideal to release many versions per day.
> > 
> > With all of the above in mind, I propose that we move to a
> > "at least once per week" model, where we do a component release
> > at least once per week(*), which then in the four week stream form
> > a new Alpha release. The smaller releases do not need release notes,
> > I don't care if we use the micro number or a .AlphaY designator on
> > them, but they should be a release, that is not a (named) snapshot.
> > This will allow us to still have less efforts to do releases, but
> > keep being (more) agile and have earlier integrations and thus
> > less long living integration branches.
> > 
> > On top of that, we need to provide new and/or changed apis(**)
> > early on in the 4 weeks cadence so that other components can
> > already start calling them, even if they are not yet functionally
> > complete.
> > 
> > *) Of course only if a change to the component has been made.
> > **) Ideally with changed apis, we keep the old version around for
> >   a bit and offer the new version on top. Remember, that especially
> >   with non-compiletime bindings, we can not know which client is
> >   at what api version.
> > _______________________________________________
> > 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  Tue Jul 21 10:31:38 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 21 Jul 2015 16:31:38 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <1972038.7lySs3RSGz@localhost.localdomain>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
Message-ID: <55AE57CA.80109@redhat.com>

Le 21/07/2015 14:26, Lukas Krejci a ?crit :
> So wait a minute.
>
> The changed dependency "suddenly" broke your rest tests.
>
> IMHO, that is good in a sense that you now know something new about being
> deployed in another runtime environment (namely WF9) which metrics WILL BE
> deployed into.
>

rest-tests module will never be deployed into Wildfly.

> Can it be painful? Yes, we've all been through such things. Is it avoidable? I
> don't think so.

Yes *it is* avoidable. Don't force dependency versions and scopes for 
non WAR/EAR modules. Simply declare the BOM version in the parent, and 
import the BOM in WAR/EAR modules to be deployed to Hawkular.

>
> The versions of the modules coming from the Hawkular parent are what Hawkular
> as whole standardizes on. You should not care about where they actually come
> from (and the fact that they come from WF bom is a good thing, btw).
>
> If you open the door for individual modules having non-standard versions of
> dependencies, you know where we're going to end up.
 >
 > I feel your pain, but please - standardization is more important that
 > occasional troubles of a single component.

I've *never* suggested to drop usage of the BOM for WAR/EAR modules to 
be deployed to Hawkular (that is, to Wildfly).

In fact, if you look at git history, you'll notice *I* removed the 
manual dependency declarations in the metrics WAR project in order to 
use the Wildfly BOM.
It was quite some time ago, when there was no Hawkular org and Metrics 
was called rhq-metrics. Then it was later factored out to the parent, 
which is a good thing, with respect to BOM version enforcement.

From jsanda at redhat.com  Tue Jul 21 10:43:49 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 21 Jul 2015 10:43:49 -0400
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
	steps
In-Reply-To: <55AE145A.4000008@redhat.com>
References: <55AE145A.4000008@redhat.com>
Message-ID: <B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>

Keep the following in mind. Since the core metrics API is now built on RxJava, function params and return types should probably be rx.Observable. Some of the work described below may already be covered by the work Jay did for HWKMETRICS-144 which involved adding min/max/avg functions. To be honest, I think functions like min/max/avg are poor candidates for some of the changes being discussed because they are so simple. Here is our avg function,

    Func1<Observable<DataPoint<Double>>, Observable<Double>> Average = data ->
            MathObservable.averageDouble(data.map(DataPoint::getValue));

For other, more involved functions, I think we should look first at the core operators in Rx.Observable and then maybe consider custom operators[1].

[1] https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators <https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators>

> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi,
> 
> I have looked at Aakarsh's repo:
> https://github.com/Akki5/hawkular_plugin/
> 
> It's a good start with an interface describing a doubles to double 
> function, a classloader for implementation loading and a set of initial 
> implementations.
> 
> In order to integrate this work into Metrics, I think we should follow 
> the following steps:
> 
> =====
> #1 Change the contract
> 
> Doubles to double works great for avg/min/max/... functions on gauge 
> metrics. But we need to consider other metric types.
> 
> Also, the interface should not only accept data point values, but whole 
> data points. Because some functions need the timestamp to compute the 
> result. % of up availability is a good example.
> 
> And functions may return different types: Double, Long, AvailabilityType.
> 
> #2 Update configuration options to let the user set a plugins directory
> 
> Metrics doc needs will have to be updated.
> 
> #3 Create a function repository for each metric type
> 
> We can build on JDK's service loader + Aakarsh's classloader implementation.
> 
> #4 Add builtin aggregate functions
> 
> Extract existing Metrics code (min, max, avg, % of up avail, downtime 
> duration) into builtin functions.
> 
> #5 Document the process of implementing a pluggable function
> 
> We need to think about function naming as well. Should we use a prefix 
> to identify a builtin function?
> =====
> 
> I will start another thread to discuss REST and Core API data query changes.
> 
> Thoughts?
> 
> Thanks,
> 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/20150721/2171a2cd/attachment-0001.html 

From tsegismo at redhat.com  Tue Jul 21 11:35:21 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 21 Jul 2015 17:35:21 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
Message-ID: <55AE66B9.50206@redhat.com>

Le 21/07/2015 14:44, Heiko W.Rupp a ?crit :
> On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
>> I feel your pain, but please - standardization is more important that
>> occasional troubles of a single component.
>
> +5

I haven't asked for "de-standardization", I've asked for not forcing 
Wildfly BOM artifacts versions and scopes in every single module we work 
on, even unrelated to Wildfly. Epic fail.

I have put too much into this. Probably because *I talked about this 
change a month ago*, sent a PR in the meantime. The PR was not merged 
and back from a week of PTO, the PR closed, and a new parent POM 
released. After taking the time to work with Wildfly team and clarify 
with the them the intended usage of the BOM, I was quite upset. I'll get 
over it.

From tsegismo at redhat.com  Tue Jul 21 11:40:31 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 21 Jul 2015 17:40:31 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AE4537.8090000@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com>
Message-ID: <55AE67EF.7080006@redhat.com>

Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
>
> Too much snark in this thread.
>
> Is there a way that it can remain in the parent pom yet be
> overridden/excluded as desired/required by metrics?  Maven typically
> prefers the locally decl over an inherited decl.

The only way you can "ignore" a BOM import is to re-declare it in your 
component parent POM with a scope != import. Works until Maven team 
decides "type=pom" + "scope=<yourchoice>" means something.

I was not inclined to do this given that the proper solution is easy to 
implement.


From mazz at redhat.com  Tue Jul 21 12:12:28 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 21 Jul 2015 12:12:28 -0400 (EDT)
Subject: [Hawkular-dev] metric data type
In-Reply-To: <1315633486.1647661.1437494871880.JavaMail.zimbra@redhat.com>
Message-ID: <18589909.1648774.1437495148814.JavaMail.zimbra@redhat.com>

OK, folks... how do we solve the following?

There are now two independent enums to define metric data type - one in inventory and one in metrics.

org.hawkular.inventory.api.model.MetricDataType

org.hawkular.metrics.client.common.MetricType

>From an agent or feed perspective, I now have to decide which one I want. Pretty annoying, but OK I can translate between the two if I need to (if the agent is talking to inventory, it will use their enum; if talking to metrics, use their enum). In the agent configuration, <metric-dmr> will need to use the common values between the two in order to support both. But this leads to a more difficult problem to come to grips with - inventory and metric enums for metric type have different values!

Inventory has GAUGE, AVAILABILITY, COUNTER, COUNTER_RATE.

Metrics API has GAUGE, COUNTER, TIMING, SIMPLE.

Right now, the wildfly agent only supports gauge and counter (and inventory availability).

From mazz at redhat.com  Tue Jul 21 12:42:06 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 21 Jul 2015 12:42:06 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <2038389130.1658799.1437496734933.JavaMail.zimbra@redhat.com>
Message-ID: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>

We have a fairly annoying problem with our current glue code location.

Right now, we have the "glue code" that is known as "feed-comm" inside the hawkular repo - there is specifically the "feed-comm-api" artifact that contains some Java code that is required for use by Java-based feeds in order to talk to the server (also includes some JSON schemas for non-Java feeds to use).

But since this is in hawkular repo, my agent needs a hawkular release in order to pull in the feed-comm-api artifact! Well, obviously, that's what we are moving toward for next week - a alpha hawkualr release. But until that happens, I can't release the agent.

But, interestingly enough, because hawkular (kettle) contains the agent, hawkular can't be released until it has an agent release to pull in.

Round and round we go.

I really hate saying we need yet another repo, but how else can we get glue code that is common between server and feeds/agents that isn't dependent upon a hawkular release being made?

From jsanda at redhat.com  Tue Jul 21 13:15:30 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 21 Jul 2015 13:15:30 -0400
Subject: [Hawkular-dev] metric data type
In-Reply-To: <18589909.1648774.1437495148814.JavaMail.zimbra@redhat.com>
References: <18589909.1648774.1437495148814.JavaMail.zimbra@redhat.com>
Message-ID: <534F3C33-A3C6-481F-A12A-21C710399EFF@redhat.com>


> On Jul 21, 2015, at 12:12 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> OK, folks... how do we solve the following?
> 
> There are now two independent enums to define metric data type - one in inventory and one in metrics.
> 
> org.hawkular.inventory.api.model.MetricDataType
> 
> org.hawkular.metrics.client.common.MetricType
> 
>> From an agent or feed perspective, I now have to decide which one I want. Pretty annoying, but OK I can translate between the two if I need to (if the agent is talking to inventory, it will use their enum; if talking to metrics, use their enum). In the agent configuration, <metric-dmr> will need to use the common values between the two in order to support both. But this leads to a more difficult problem to come to grips with - inventory and metric enums for metric type have different values!
> 
> Inventory has GAUGE, AVAILABILITY, COUNTER, COUNTER_RATE.
> 
> Metrics API has GAUGE, COUNTER, TIMING, SIMPLE.
> Right now, the wildfly agent only supports gauge and counter (and inventory availability).


I do not know what TIMING and SIMPLE are. The metrics-core-api module has the class org.hawkular.metrics.api.MetricType whose values are the same as those in the Inventory enum. In this particular case, I think Inventory should reuse org.hawkular.metrics.api.MetricType since that is what ultimately defines the recognized and supported types. 

From lkrejci at redhat.com  Tue Jul 21 13:59:31 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 21 Jul 2015 19:59:31 +0200
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
Message-ID: <359396981.vn8CYJ6Dft@localhost.localdomain>

I am not sure weekly or even daily releases will help us get work done.

The main reason for this is that we are spread very thin - 1 or 2 people per 
component (with the exception of metrics that has whopping 4 devs).

The devs need to split their time between developing new stuff, integrating 
with the changes in other components their components depend on and integrate 
their changes into hawkular proper and/or any glue component (agent for 
example) (and yes, component owners should be doing that, because we develop 
Hawkular, not the individual components).

I don't share Stefan's need for a "release engineer" - release takes up to 1 
minute on commandline + a minute in Nexus + maybe 5mins on writing release 
notes. I am willing to do that twice a week no problem.

But I don't think it will help much.

The dev/inventory-0.2.0.Alpha1 branch has been open for I think 2 weeks now 
but that is not because there were so many little changes to accommodate. It 
was rather that agent + UI + pinger need to accommodate to 1 huge refactoring 
that has taken place in inventory.

The problem with inventory (and I am not sure about the rest of the 
components) is that such refactorings are quite common nowadays exactly 
because of the release early release often paradigm - we introduce new 
features while we KNOW they will need to be refactored in the future when 
another feature catches up and requires that change to happen.

This happens with the agent, too. Because it usually waits for features in inv 
and metrics, it just starts to use what's available at given moment to get a 
job done, while we know it will have to be reworked once the rest of the 
components catch up - think resource hierarchy, operations, etc.

I can't say I have a recipe to help with that situation.

The only thing I think can at least partially work is to allow enough time for 
the integration to happen - i.e. the version of the component to be included 
in the next milestone needs to be released at least 2 week before the 
milestone release.

But that has the problem of interdependent components making breaking changes 
and trying to go forward in a lockstep - how can one component be sure the 
other component will be released in time so that they both can go into the 
next milestone? Beats me, I just can't say.

The release-per-week is akin to the agile "release-train" approach, IMHO, 
which implies varying scope of the releases - something I agree with in 
Stefan's email - the arbitrary features being required of the milestones are, 
well, arbitrary and generally cannot be fulfilled with a time-bound release 
policy (we work towards them but there cannot be a guarantee they will be 
finished in time).

All in all, I think the struggle we are currently going through is just the 
process of finding the balance between agility and stability. I am not sure it 
can be simplified in a world of distributed semi-independent components - it 
just has to be found ;)

We can try weekly releases, we can try giving the milestone integration two 
weeks to settle, we can try release per commit. 

We will either find the balance or find that balance itself is a moving target  
;)

On Tuesday, July 21, 2015 11:38:58 Heiko W.Rupp wrote:
> Hey
> 
> I have observed that our current Hawkular cadence of 4 weeks
> with similar cadences of components makes us end up with
> long living integration branches and a larger rush near the
> end to integrate them, get them for the first time tested in CI
> and even for the first time tested in real world.
> 
> In one of the last releases there was a changed implementation
> in one component, that basically turned out as a no-op and
> still returned a "200 OK" code, so clients thought everything is
> happy, but it was not. We found the issue (through ppl looking
> at the UI) and solved it, but it was in a rush.
> 
> This certainly goes against all the ideas of "release early, release
> often", "cut small slices", "changes go into CI/CD and go live quickly".
> Remember the coin flipping ?
> 
> Ideally we would always be able to integrate changes from
> components into Hawkular (main), but I understand that with the
> way maven and its release process to central works, it is also not
> ideal to release many versions per day.
> 
> With all of the above in mind, I propose that we move to a
> "at least once per week" model, where we do a component release
> at least once per week(*), which then in the four week stream form
> a new Alpha release. The smaller releases do not need release notes,
> I don't care if we use the micro number or a .AlphaY designator on
> them, but they should be a release, that is not a (named) snapshot.
> This will allow us to still have less efforts to do releases, but
> keep being (more) agile and have earlier integrations and thus
> less long living integration branches.
> 
> On top of that, we need to provide new and/or changed apis(**)
> early on in the 4 weeks cadence so that other components can
> already start calling them, even if they are not yet functionally
> complete.
> 
> *) Of course only if a change to the component has been made.
> **) Ideally with changed apis, we keep the old version around for
>   a bit and offer the new version on top. Remember, that especially
>   with non-compiletime bindings, we can not know which client is
>   at what api version.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From lkrejci at redhat.com  Tue Jul 21 14:03:08 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 21 Jul 2015 20:03:08 +0200
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <2010022920.1561404.1437487587243.JavaMail.zimbra@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
	<40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
	<2010022920.1561404.1437487587243.JavaMail.zimbra@redhat.com>
Message-ID: <1923046.IANzvUWbUr@localhost.localdomain>

git-flow?

On Tuesday, July 21, 2015 10:06:27 John Mazzitelli wrote:
> Each repo needs to have a "dev/latest" branch. Should the component need
> them, the pom.xml files in those dev/latest branches can refer to the
> latest-n-greatest snapshot versions of components (we can have travis
> publish the snapshot builds from these dev/latest branches). Therefore, if
> you want the latest-n-greatest to test integration, switch to dev/latest
> branches and build them locally.
> 
> If you want a released version that never changes go to the master branch
> (which is the latest release) or go to one of the release tags and build
> from that.
> 
> Once we are getting ready to prepare for a release, we create PRs to merge
> dev/latest to master, changing the poms to the release versions that are
> needed.
> 
> How long between merging dev/latest to master and release? I dunno. If we do
> this right, we won't need a quick 1-week turnaround time. Every 2-weeks?
> 3-weeks? keep it a month? I don't know. Make something up. I vote every 17
> days - only because its just as arbitrary as any other time period we might
> pick :)
> 
> ----- Original Message -----
> 
> > Hello,
> > 
> > There are two issues that get interlaced here and should not be. One is to
> > release individual components on a schedule, and second is making sure
> > that
> > all the components integrate nicely. Your proposal with "at least one
> > release per week" is trying to fix a fix of a fix of previous decision.
> > And
> > in this mix, the two concepts of release and integration get so
> > interlocked
> > that we cannot make heads and tail.
> > 
> > Here is the progression of things:
> > 
> > Problem 1: monolithic code is bad, we need to componentize everything.
> > Solution: create single purpose repositories, which resulted in about 20
> > repositories.
> > 
> > Problem 2: how do we integrate all those components? Solution: create a
> > Hawkular repository that depends on all the other repositories.
> > 
> > Problem 3: integrated project idea works, but how do we really really
> > integrate the code? Solution: publish changes in subcomponents as soon as
> > possible.
> > 
> > Problem 4: publishing changes in components takes a long time, can we
> > expedite the process and get changes even faster to integrated project?
> > Solution: automate SNAPSHOT publication so you have freshly build binaries
> > on almost every change.
> > 
> > Problem 5: We need consistent builds for the integrated project. Solution:
> > master branch in the integrated project only depends on released version
> > of
> > components, feature branches are short lived.
> > 
> > Problem 6: It is almost impossible to align all the release of components
> > and give enough runaway for the integrated project to ingest all the
> > release subcomponets, especially since there inter-dependencies on the
> > sub-projects themselves. Solution: publish sub-components officially at
> > least once per week.
> > 
> > Problem 7: There are major changes that are needed right-away in the
> > integrated project. Solution: officially publish components more often
> > than
> > once per week. Publish as soon as the features makes it in. In fact, let's
> > publish Alphas (Alphaxx) with every single change.
> > 
> > Problem 8: Too many releases, it takes too much time to administer the
> > process of releasing. Solution: Automate the release dependency
> > management,
> > emulate the SNAPSHOT injection concept but with Alpha "moniker".
> > 
> > Problem 9: It is a nightmare to maintain on which version to depend on the
> > integrate project or components that depend on other components. Solution:
> > ??
> > 
> > Problem 10: It is almost impossible to trace back the code that code that
> > goes into the integrated project because there are so many Alphas.
> > Solution: ???
> > 
> > 
> > We are at level 5; from 6 forward I see them coming, just as I saw the
> > rest
> > of 5. At what point do we stop and say "wait a second! what we doing here?
> > can we simplify all this??" From my perspective, we are arbitrarily
> > setting
> > requirements just to complicate things. There is always a happy medium and
> > there is always ways to simplify. I would much rather think for 2 months
> > on
> > how to simplify things and do it once, then stack problems that make our
> > lives harder for no reason.
> > 
> > 
> > That being said, I am not against implementing your proposed solution in
> > Hawkular Metrics. But I see two possible paths. One, escalate and resolve
> > problems 6, and 7 at the same time with automation. That is primarily
> > because we are so thin on resources and so stretched that we do not have
> > time to not automate this. Two, get a release engineer (or another
> > engineer) allocated to the team that will take care of these releases. If
> > we are to proceed with your current proposal please let us know which one
> > of these paths do you want Hawkular Metrics to take.
> > 
> > 
> > At the same time, we can take the reversed path; rather than escalate
> > problems, remove them from that stack. Why not look to simplify
> > everything,
> > revert a few problems and try to improve our productivity. We can revert
> > to
> > the use of SNAPSHOTS. In what capacity? Let's find the path that gives us
> > the most benefits with the least amount of work.
> > 
> > 
> > Thank you,
> > Stefan
> > 
> > ----- Original Message -----
> > 
> > > From: "Heiko W.Rupp" <hrupp at redhat.com>
> > > To: "Discussions around Hawkular development"
> > > <hawkular-dev at lists.jboss.org>
> > > Sent: Tuesday, July 21, 2015 4:38:58 AM
> > > Subject: [Hawkular-dev] Release cadence
> > > 
> > > Hey
> > > 
> > > I have observed that our current Hawkular cadence of 4 weeks
> > > with similar cadences of components makes us end up with
> > > long living integration branches and a larger rush near the
> > > end to integrate them, get them for the first time tested in CI
> > > and even for the first time tested in real world.
> > > 
> > > In one of the last releases there was a changed implementation
> > > in one component, that basically turned out as a no-op and
> > > still returned a "200 OK" code, so clients thought everything is
> > > happy, but it was not. We found the issue (through ppl looking
> > > at the UI) and solved it, but it was in a rush.
> > > 
> > > This certainly goes against all the ideas of "release early, release
> > > often", "cut small slices", "changes go into CI/CD and go live quickly".
> > > Remember the coin flipping ?
> > > 
> > > Ideally we would always be able to integrate changes from
> > > components into Hawkular (main), but I understand that with the
> > > way maven and its release process to central works, it is also not
> > > ideal to release many versions per day.
> > > 
> > > With all of the above in mind, I propose that we move to a
> > > "at least once per week" model, where we do a component release
> > > at least once per week(*), which then in the four week stream form
> > > a new Alpha release. The smaller releases do not need release notes,
> > > I don't care if we use the micro number or a .AlphaY designator on
> > > them, but they should be a release, that is not a (named) snapshot.
> > > This will allow us to still have less efforts to do releases, but
> > > keep being (more) agile and have earlier integrations and thus
> > > less long living integration branches.
> > > 
> > > On top of that, we need to provide new and/or changed apis(**)
> > > early on in the 4 weeks cadence so that other components can
> > > already start calling them, even if they are not yet functionally
> > > complete.
> > > 
> > > *) Of course only if a change to the component has been made.
> > > **) Ideally with changed apis, we keep the old version around for
> > > 
> > >   a bit and offer the new version on top. Remember, that especially
> > >   with non-compiletime bindings, we can not know which client is
> > >   at what api version.
> > > 
> > > _______________________________________________
> > > 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  Tue Jul 21 15:28:54 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 21 Jul 2015 15:28:54 -0400
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <1923046.IANzvUWbUr@localhost.localdomain>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
	<40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
	<2010022920.1561404.1437487587243.JavaMail.zimbra@redhat.com>
	<1923046.IANzvUWbUr@localhost.localdomain>
Message-ID: <55AE9D76.5030908@redhat.com>


OK, so I think everyone has valid points and mostly I agree with Lukas, 
our issues are mainly the result of many quickly-iterating moving 
parts.  But we do have room to improve.  We need to remember that the 
reason we are running with all of these components is so that Hawkular 
master can be releasable both at any-time (stability) and at scheduled 
dates meeting certain feature goals (progress). With that in mind it's 
quite important for the [component] developers to have a clear picture 
or what is needed from them for the next Hawkular feature release.  
Given that knowledge the component should have a release available as 
far in advance as possible with the needed feature support.  As Lukas 
mentions, 2 weeks is a very good goal.  It could be that a Hawkular 
release doesn't even require a new component release.  Releasing 
daily/weekly/etc really doesn't make much difference, I think, instead 
it is important that there is a release early enough in the Hawkular 
release cycle that supports the next release of Hawkular. This then sets 
us up to quickly respond with a follow-up release to address issues or 
things we missed.  The components must strive to be out in front of the 
console.

As for Mazz's suggestion of a dev/latest branch for each component. I'm 
not convinced that that is necessary.  I think a component's master 
branch should be free to have commits towards their next release.  And 
note, they should be ready to release a new feature release at any 
time.  And that means no snapshot dependencies.   So, if your component 
is currently dependent on a snapshot of another component, you will 
obviously need to be working in an integration branch.  This is when 
Heiko's release-often approach is most critical.  If someone is 
depending on your snapshot I think your highest priority should then be 
to release to get them off of that dependency.  And consumers, help them 
do that as well.  This is the coin-flip exercise.

As for Versioning, we're getting closer to a standard but I think we 
could maybe do a little better.  My take on the recent discussions is 
this.  We know we can't release with snapshot dependencies so, as 
described above, we need to minimize the windows that a snapshot dep is 
in use by a consuming component.   We are all using Major.Minor.Micro 
versioning. That is good.  And most of us are following the RH guideline 
of the suffix, like ".Final".  We are, I think, all using the following 
guidelines:

  * Breaking change releases minimally require a Minor version increment
  * Backward compatible minimally require a Micro version increment
  * Pure fix/patch releases should only increment the Micro version.

I would further suggest that all releases at this time use the ".Final" 
suffix.  Using ".AlphaX" does nothing more than create controversy.  It 
has no meaning wrt quality or usability at this point in time.   Anytime 
a feature or fix release goes out, the Major.Minor.Micro version change 
should be sufficient.  Release often [enough], increment the version and 
tack on ".Final".  No "Alpha", no "Snapshot", no timed "Snapshot".

I think we should take to heart Heiko's intentions and release often.  
But I hope we can avoid fabricated release schedules for the components 
and instead have us focus on releasing based on the overall needs of 
Hawkular (2 weeks early!) and consuming components (kill snapshot deps 
ASAP!).


On 7/21/2015 2:03 PM, Lukas Krejci wrote:
> git-flow?
>
> On Tuesday, July 21, 2015 10:06:27 John Mazzitelli wrote:
>> Each repo needs to have a "dev/latest" branch. Should the component need
>> them, the pom.xml files in those dev/latest branches can refer to the
>> latest-n-greatest snapshot versions of components (we can have travis
>> publish the snapshot builds from these dev/latest branches). Therefore, if
>> you want the latest-n-greatest to test integration, switch to dev/latest
>> branches and build them locally.
>>
>> If you want a released version that never changes go to the master branch
>> (which is the latest release) or go to one of the release tags and build
>> from that.
>>
>> Once we are getting ready to prepare for a release, we create PRs to merge
>> dev/latest to master, changing the poms to the release versions that are
>> needed.
>>
>> How long between merging dev/latest to master and release? I dunno. If we do
>> this right, we won't need a quick 1-week turnaround time. Every 2-weeks?
>> 3-weeks? keep it a month? I don't know. Make something up. I vote every 17
>> days - only because its just as arbitrary as any other time period we might
>> pick :)
>>
>> ----- Original Message -----
>>
>>> Hello,
>>>
>>> There are two issues that get interlaced here and should not be. One is to
>>> release individual components on a schedule, and second is making sure
>>> that
>>> all the components integrate nicely. Your proposal with "at least one
>>> release per week" is trying to fix a fix of a fix of previous decision.
>>> And
>>> in this mix, the two concepts of release and integration get so
>>> interlocked
>>> that we cannot make heads and tail.
>>>
>>> Here is the progression of things:
>>>
>>> Problem 1: monolithic code is bad, we need to componentize everything.
>>> Solution: create single purpose repositories, which resulted in about 20
>>> repositories.
>>>
>>> Problem 2: how do we integrate all those components? Solution: create a
>>> Hawkular repository that depends on all the other repositories.
>>>
>>> Problem 3: integrated project idea works, but how do we really really
>>> integrate the code? Solution: publish changes in subcomponents as soon as
>>> possible.
>>>
>>> Problem 4: publishing changes in components takes a long time, can we
>>> expedite the process and get changes even faster to integrated project?
>>> Solution: automate SNAPSHOT publication so you have freshly build binaries
>>> on almost every change.
>>>
>>> Problem 5: We need consistent builds for the integrated project. Solution:
>>> master branch in the integrated project only depends on released version
>>> of
>>> components, feature branches are short lived.
>>>
>>> Problem 6: It is almost impossible to align all the release of components
>>> and give enough runaway for the integrated project to ingest all the
>>> release subcomponets, especially since there inter-dependencies on the
>>> sub-projects themselves. Solution: publish sub-components officially at
>>> least once per week.
>>>
>>> Problem 7: There are major changes that are needed right-away in the
>>> integrated project. Solution: officially publish components more often
>>> than
>>> once per week. Publish as soon as the features makes it in. In fact, let's
>>> publish Alphas (Alphaxx) with every single change.
>>>
>>> Problem 8: Too many releases, it takes too much time to administer the
>>> process of releasing. Solution: Automate the release dependency
>>> management,
>>> emulate the SNAPSHOT injection concept but with Alpha "moniker".
>>>
>>> Problem 9: It is a nightmare to maintain on which version to depend on the
>>> integrate project or components that depend on other components. Solution:
>>> ??
>>>
>>> Problem 10: It is almost impossible to trace back the code that code that
>>> goes into the integrated project because there are so many Alphas.
>>> Solution: ???
>>>
>>>
>>> We are at level 5; from 6 forward I see them coming, just as I saw the
>>> rest
>>> of 5. At what point do we stop and say "wait a second! what we doing here?
>>> can we simplify all this??" From my perspective, we are arbitrarily
>>> setting
>>> requirements just to complicate things. There is always a happy medium and
>>> there is always ways to simplify. I would much rather think for 2 months
>>> on
>>> how to simplify things and do it once, then stack problems that make our
>>> lives harder for no reason.
>>>
>>>
>>> That being said, I am not against implementing your proposed solution in
>>> Hawkular Metrics. But I see two possible paths. One, escalate and resolve
>>> problems 6, and 7 at the same time with automation. That is primarily
>>> because we are so thin on resources and so stretched that we do not have
>>> time to not automate this. Two, get a release engineer (or another
>>> engineer) allocated to the team that will take care of these releases. If
>>> we are to proceed with your current proposal please let us know which one
>>> of these paths do you want Hawkular Metrics to take.
>>>
>>>
>>> At the same time, we can take the reversed path; rather than escalate
>>> problems, remove them from that stack. Why not look to simplify
>>> everything,
>>> revert a few problems and try to improve our productivity. We can revert
>>> to
>>> the use of SNAPSHOTS. In what capacity? Let's find the path that gives us
>>> the most benefits with the least amount of work.
>>>
>>>
>>> Thank you,
>>> Stefan
>>>
>>> ----- Original Message -----
>>>
>>>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>>>> To: "Discussions around Hawkular development"
>>>> <hawkular-dev at lists.jboss.org>
>>>> Sent: Tuesday, July 21, 2015 4:38:58 AM
>>>> Subject: [Hawkular-dev] Release cadence
>>>>
>>>> Hey
>>>>
>>>> I have observed that our current Hawkular cadence of 4 weeks
>>>> with similar cadences of components makes us end up with
>>>> long living integration branches and a larger rush near the
>>>> end to integrate them, get them for the first time tested in CI
>>>> and even for the first time tested in real world.
>>>>
>>>> In one of the last releases there was a changed implementation
>>>> in one component, that basically turned out as a no-op and
>>>> still returned a "200 OK" code, so clients thought everything is
>>>> happy, but it was not. We found the issue (through ppl looking
>>>> at the UI) and solved it, but it was in a rush.
>>>>
>>>> This certainly goes against all the ideas of "release early, release
>>>> often", "cut small slices", "changes go into CI/CD and go live quickly".
>>>> Remember the coin flipping ?
>>>>
>>>> Ideally we would always be able to integrate changes from
>>>> components into Hawkular (main), but I understand that with the
>>>> way maven and its release process to central works, it is also not
>>>> ideal to release many versions per day.
>>>>
>>>> With all of the above in mind, I propose that we move to a
>>>> "at least once per week" model, where we do a component release
>>>> at least once per week(*), which then in the four week stream form
>>>> a new Alpha release. The smaller releases do not need release notes,
>>>> I don't care if we use the micro number or a .AlphaY designator on
>>>> them, but they should be a release, that is not a (named) snapshot.
>>>> This will allow us to still have less efforts to do releases, but
>>>> keep being (more) agile and have earlier integrations and thus
>>>> less long living integration branches.
>>>>
>>>> On top of that, we need to provide new and/or changed apis(**)
>>>> early on in the 4 weeks cadence so that other components can
>>>> already start calling them, even if they are not yet functionally
>>>> complete.
>>>>
>>>> *) Of course only if a change to the component has been made.
>>>> **) Ideally with changed apis, we keep the old version around for
>>>>
>>>>    a bit and offer the new version on top. Remember, that especially
>>>>    with non-compiletime bindings, we can not know which client is
>>>>    at what api version.
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

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

From jshaughn at redhat.com  Tue Jul 21 15:57:17 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 21 Jul 2015 15:57:17 -0400
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AE67EF.7080006@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
Message-ID: <55AEA41D.5090008@redhat.com>


I'm inclined to support Thomas's suggestion. Because we typically deploy 
to Wildfly I can understand why it was natural to suck the BOM up to 
parent.  But to give components some flexibility to control their own 
imports without having to override the parent or possibly add 
exclusions, it doesn't seem too bad to get the version of the BOM from 
the parent and then import at the component level.  And certainly it 
makes sense if the BOM is just not needed by the Hawkular component.  
Thomas has done the homework here.  If someone is is absolutely 100% 
against the change then we'll have to put it to a vote (or a flat out 
decision from above), but I suggest we make the change and move 
forward.  If we learn downstream that it was better the other way then 
I'm sure there will be enough groundswell to change it back.

Although, I think we can wait until after the next Hawkular release and 
then a PR should be sent for all affected components that may need to 
add the BOM dependency.


On 7/21/2015 11:40 AM, Thomas Segismont wrote:
> Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
>> Too much snark in this thread.
>>
>> Is there a way that it can remain in the parent pom yet be
>> overridden/excluded as desired/required by metrics?  Maven typically
>> prefers the locally decl over an inherited decl.
> The only way you can "ignore" a BOM import is to re-declare it in your
> component parent POM with a scope != import. Works until Maven team
> decides "type=pom" + "scope=<yourchoice>" means something.
>
> I was not inclined to do this given that the proper solution is easy to
> implement.
>
> _______________________________________________
> 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/20150721/ea201831/attachment-0001.html 

From jshaughn at redhat.com  Tue Jul 21 17:27:40 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 21 Jul 2015 17:27:40 -0400
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
Message-ID: <55AEB94C.4040508@redhat.com>


Right, you may find what you need is already in place, or you may find 
that you can spend time on higher-level functions.  In particular, see:

MetricsService:
<T> Observable<T> findGaugeData(String tenantId, MetricId id, Long 
start, Long end,Func1<Observable<DataPoint<Double>>, Observable<T>>... 
funcs);

Aggregate:
predefined functions.

Here is an example snippen from 
org.hawkular.alerts.external.metrics.Manager to gather multiple 
aggregates in one call and determine the range:

                     case range: {
                         Iterator<Double> iterator = 
metrics.findGaugeData(tenantId, metricId, start, end,
                                 Aggregate.Min, Aggregate.Max)
.toBlocking().toIterable().iterator();
                         Double min = iterator.next();
                         Double max = iterator.next();
                         value = max - min;
                         break;
                     }


-Jay

On 7/21/2015 10:43 AM, John Sanda wrote:
> Keep the following in mind. Since the core metrics API is now built on 
> RxJava, function params and return types should probably be 
> rx.Observable. Some of the work described below may already be covered 
> by the work Jay did for HWKMETRICS-144 which involved adding 
> min/max/avg functions. To be honest, I think functions like 
> min/max/avg are poor candidates for some of the changes being 
> discussed because they are so simple. Here is our avg function,
>
> Func1<Observable<DataPoint<Double>>, Observable<Double>> Average = 
> data ->
> MathObservable.averageDouble(data.map(DataPoint::getValue));
>
> For other, more involved functions, I think we should look first at 
> the core operators in Rx.Observable and then maybe consider custom 
> operators[1].
>
> [1] 
> https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators
>
>> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com 
>> <mailto:tsegismo at redhat.com>> wrote:
>>
>> Hi,
>>
>> I have looked at Aakarsh's repo:
>> https://github.com/Akki5/hawkular_plugin/
>>
>> It's a good start with an interface describing a doubles to double
>> function, a classloader for implementation loading and a set of initial
>> implementations.
>>
>> In order to integrate this work into Metrics, I think we should follow
>> the following steps:
>>
>> =====
>> #1 Change the contract
>>
>> Doubles to double works great for avg/min/max/... functions on gauge
>> metrics. But we need to consider other metric types.
>>
>> Also, the interface should not only accept data point values, but whole
>> data points. Because some functions need the timestamp to compute the
>> result. % of up availability is a good example.
>>
>> And functions may return different types: Double, Long, AvailabilityType.
>>
>> #2 Update configuration options to let the user set a plugins directory
>>
>> Metrics doc needs will have to be updated.
>>
>> #3 Create a function repository for each metric type
>>
>> We can build on JDK's service loader + Aakarsh's classloader 
>> implementation.
>>
>> #4 Add builtin aggregate functions
>>
>> Extract existing Metrics code (min, max, avg, % of up avail, downtime
>> duration) into builtin functions.
>>
>> #5 Document the process of implementing a pluggable function
>>
>> We need to think about function naming as well. Should we use a prefix
>> to identify a builtin function?
>> =====
>>
>> I will start another thread to discuss REST and Core API data query 
>> changes.
>>
>> Thoughts?
>>
>> Thanks,
>> 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

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

From snegrea at redhat.com  Tue Jul 21 17:37:33 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 21 Jul 2015 17:37:33 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
Message-ID: <2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>

Hello,

We have this repository that is now used only for the embedded Cassandra distribution. Do you think it would a good place for this kind of comm code?


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


Thank you,
Stefan

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, July 21, 2015 11:42:06 AM
> Subject: [Hawkular-dev] glue code - where does it go?
> 
> We have a fairly annoying problem with our current glue code location.
> 
> Right now, we have the "glue code" that is known as "feed-comm" inside the
> hawkular repo - there is specifically the "feed-comm-api" artifact that
> contains some Java code that is required for use by Java-based feeds in
> order to talk to the server (also includes some JSON schemas for non-Java
> feeds to use).
> 
> But since this is in hawkular repo, my agent needs a hawkular release in
> order to pull in the feed-comm-api artifact! Well, obviously, that's what we
> are moving toward for next week - a alpha hawkualr release. But until that
> happens, I can't release the agent.
> 
> But, interestingly enough, because hawkular (kettle) contains the agent,
> hawkular can't be released until it has an agent release to pull in.
> 
> Round and round we go.
> 
> I really hate saying we need yet another repo, but how else can we get glue
> code that is common between server and feeds/agents that isn't dependent
> upon a hawkular release being made?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Tue Jul 21 18:59:44 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 21 Jul 2015 18:59:44 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
	<2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
Message-ID: <587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>

hawkular-commons seems like a good place for glue code that is shared across hawkular components.

I could put this stuff in hawkular-bus since it is "comm" related (though it is comm between clients and server, not just comm between server-side components)

This will need to be solved - because I can't release the agent right now. Agent needs the feed-comm API which is in hawkular, but hawkular needs the agent before it can be released.

So this:

https://github.com/hawkular/hawkular/tree/integration-latest-of-everything/modules/feed-comm

needs to be moved to some location other than the hawkular build.


----- Original Message -----
> Hello,
> 
> We have this repository that is now used only for the embedded Cassandra
> distribution. Do you think it would a good place for this kind of comm code?
> 
> 
> https://github.com/hawkular/hawkular-commons
> 
> 
> Thank you,
> Stefan
> 
> ----- Original Message -----
> > From: "John Mazzitelli" <mazz at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Tuesday, July 21, 2015 11:42:06 AM
> > Subject: [Hawkular-dev] glue code - where does it go?
> > 
> > We have a fairly annoying problem with our current glue code location.
> > 
> > Right now, we have the "glue code" that is known as "feed-comm" inside the
> > hawkular repo - there is specifically the "feed-comm-api" artifact that
> > contains some Java code that is required for use by Java-based feeds in
> > order to talk to the server (also includes some JSON schemas for non-Java
> > feeds to use).
> > 
> > But since this is in hawkular repo, my agent needs a hawkular release in
> > order to pull in the feed-comm-api artifact! Well, obviously, that's what
> > we
> > are moving toward for next week - a alpha hawkualr release. But until that
> > happens, I can't release the agent.
> > 
> > But, interestingly enough, because hawkular (kettle) contains the agent,
> > hawkular can't be released until it has an agent release to pull in.
> > 
> > Round and round we go.
> > 
> > I really hate saying we need yet another repo, but how else can we get glue
> > code that is common between server and feeds/agents that isn't dependent
> > upon a hawkular release being made?
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> 

From theute at redhat.com  Wed Jul 22 02:52:12 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 22 Jul 2015 08:52:12 +0200
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
	<40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
Message-ID: <55AF3D9C.8000204@redhat.com>



On 07/21/2015 03:50 PM, Stefan Negrea wrote:
> Hello,
>
> There are two issues that get interlaced here and should not be. One is to release individual components on a schedule, and second is making sure that all the components integrate nicely. Your proposal with "at least one release per week" is trying to fix a fix of a fix of previous decision. And in this mix, the two concepts of release and integration get so interlocked that we cannot make heads and tail.
>
> Here is the progression of things:
>
> Problem 1: monolithic code is bad, we need to componentize everything. Solution: create single purpose repositories, which resulted in about 20 repositories.
>
> Problem 2: how do we integrate all those components? Solution: create a Hawkular repository that depends on all the other repositories.
>
> Problem 3: integrated project idea works, but how do we really really integrate the code? Solution: publish changes in subcomponents as soon as possible.


The original idea of splitting the code was to separate the concerns of 
some parts of the code, split the relatively large team/project and 
provide public APIs that can be consumed by the Hawkular repository. 
Those components were supposed to be *libraries*. Splitting the code 
like this adds a *little* extra in release but adds benefits in quality 
and separation of concerns.

With splitted repositories you should force yourself about thinking well 
about the API and (usually) less subject to pick from private APIs, 
(Accidental) dependencies between various parts of the code are also 
more obvious.

This is where the problem raised...

So there are various mistakes IMO in the current organization:
	- Components as libraries suddenly became servers on their own
	- Components depends too much on each other, while Hawkular should be 
where most of the dependencies happen. (Your Pb6)
	- Most efforts after that (branching, SNAPSHOT...) are done toward 
recreating the RHQ single-repo experience.

Now we pay the extra without the benefits.

Again, my wish is that components are really independent and all the 
glue happens in Hawkular. (I would consider putting the bus in there)

And for the release cadence, I agree that we are in fast-changing mode 
so it's a bit more challenging. It will need to change soon as the API 
will need to remain stable and need less new features.

So it is important that as soon as a new API or API change is ready to 
be consumed or simply asked by someone who consumes a component there is 
a release done (name doesn't matter or original component cadence neither).

And to be clear again, SNAPSHOT is not the solution, SNAPSHOT are made 
to go back to single-repo style, if we need to get back to single-repo 
style, then let's have a single repo and not fake otherwise.

Same if we have some integration branch with SNAPSHOTs that we rush 
merged at the last minute in master, it just cheats the process...


Thomas





>
> Problem 4: publishing changes in components takes a long time, can we expedite the process and get changes even faster to integrated project? Solution: automate SNAPSHOT publication so you have freshly build binaries on almost every change.
>
> Problem 5: We need consistent builds for the integrated project. Solution: master branch in the integrated project only depends on released version of components, feature branches are short lived.
>
> Problem 6: It is almost impossible to align all the release of components and give enough runaway for the integrated project to ingest all the release subcomponets, especially since there inter-dependencies on the sub-projects themselves. Solution: publish sub-components officially at least once per week.
>
> Problem 7: There are major changes that are needed right-away in the integrated project. Solution: officially publish components more often than once per week. Publish as soon as the features makes it in. In fact, let's publish Alphas (Alphaxx) with every single change.
>
> Problem 8: Too many releases, it takes too much time to administer the process of releasing. Solution: Automate the release dependency management, emulate the SNAPSHOT injection concept but with Alpha "moniker".
>
> Problem 9: It is a nightmare to maintain on which version to depend on the integrate project or components that depend on other components. Solution: ??
>
> Problem 10: It is almost impossible to trace back the code that code that goes into the integrated project because there are so many Alphas. Solution: ???
>
>
> We are at level 5; from 6 forward I see them coming, just as I saw the rest of 5. At what point do we stop and say "wait a second! what we doing here? can we simplify all this??" From my perspective, we are arbitrarily setting requirements just to complicate things. There is always a happy medium and there is always ways to simplify. I would much rather think for 2 months on how to simplify things and do it once, then stack problems that make our lives harder for no reason.
>
>
> That being said, I am not against implementing your proposed solution in Hawkular Metrics. But I see two possible paths. One, escalate and resolve problems 6, and 7 at the same time with automation. That is primarily because we are so thin on resources and so stretched that we do not have time to not automate this. Two, get a release engineer (or another engineer) allocated to the team that will take care of these releases. If we are to proceed with your current proposal please let us know which one of these paths do you want Hawkular Metrics to take.
>
>
> At the same time, we can take the reversed path; rather than escalate problems, remove them from that stack. Why not look to simplify everything, revert a few problems and try to improve our productivity. We can revert to the use of SNAPSHOTS. In what capacity? Let's find the path that gives us the most benefits with the least amount of work.
>
>
> Thank you,
> Stefan
>
> ----- Original Message -----
>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Tuesday, July 21, 2015 4:38:58 AM
>> Subject: [Hawkular-dev] Release cadence
>>
>> Hey
>>
>> I have observed that our current Hawkular cadence of 4 weeks
>> with similar cadences of components makes us end up with
>> long living integration branches and a larger rush near the
>> end to integrate them, get them for the first time tested in CI
>> and even for the first time tested in real world.
>>
>> In one of the last releases there was a changed implementation
>> in one component, that basically turned out as a no-op and
>> still returned a "200 OK" code, so clients thought everything is
>> happy, but it was not. We found the issue (through ppl looking
>> at the UI) and solved it, but it was in a rush.
>>
>> This certainly goes against all the ideas of "release early, release
>> often", "cut small slices", "changes go into CI/CD and go live quickly".
>> Remember the coin flipping ?
>>
>> Ideally we would always be able to integrate changes from
>> components into Hawkular (main), but I understand that with the
>> way maven and its release process to central works, it is also not
>> ideal to release many versions per day.
>>
>> With all of the above in mind, I propose that we move to a
>> "at least once per week" model, where we do a component release
>> at least once per week(*), which then in the four week stream form
>> a new Alpha release. The smaller releases do not need release notes,
>> I don't care if we use the micro number or a .AlphaY designator on
>> them, but they should be a release, that is not a (named) snapshot.
>> This will allow us to still have less efforts to do releases, but
>> keep being (more) agile and have earlier integrations and thus
>> less long living integration branches.
>>
>> On top of that, we need to provide new and/or changed apis(**)
>> early on in the 4 weeks cadence so that other components can
>> already start calling them, even if they are not yet functionally
>> complete.
>>
>> *) Of course only if a change to the component has been made.
>> **) Ideally with changed apis, we keep the old version around for
>>    a bit and offer the new version on top. Remember, that especially
>>    with non-compiletime bindings, we can not know which client is
>>    at what api version.
>> _______________________________________________
>> 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 Jul 22 03:16:40 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 22 Jul 2015 09:16:40 +0200
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
Message-ID: <7EF09C2B-917C-4FFB-8881-246CCAFA8BB5@redhat.com>

On 21 Jul 2015, at 16:43, John Sanda wrote:

> For other, more involved functions, I think we should look first at 
> the core operators in Rx.Observable and then maybe consider custom 
> operators[1].

And still in this case you need a way to supply them at runtime as 
opposed
to compile them in.
And this is what this work is about.

From gbrown at redhat.com  Wed Jul 22 03:17:07 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 22 Jul 2015 03:17:07 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular BTM 0.2.0.Final released
In-Reply-To: <626622523.2093166.1437549118781.JavaMail.zimbra@redhat.com>
Message-ID: <1914230502.2094212.1437549427492.JavaMail.zimbra@redhat.com>

Hi all

I'm pleased to announce the release of version 0.2.0.Final of Hawkular BTM. The main focus for this release has been on enhancing the business transaction collection capabilities.

A quick demo of this version, showing monitoring of two Vertx applications, can be found here: https://youtu.be/TtAXiYhqTSk

Highlights of this release:

    * URI inclusion/exclusion support, allowing business transactions to be filtered based on initial URIs of interest.

    * Propagate business transaction name, identified based on inclusion URI, through subsequent fragments for the same business transaction instance.

    * Child node suppression - provide a mechanism for ignoring child nodes where they add no value. The specific case that prompted this mechanism was when instrumenting JDBC prepared statements.

    * Provide mechanism for capturing header values from different message types, for use where a simple map is not available

    * Define instrumentation rules for Vertx (HTTP and EventBus).

    * Administration REST service, responsible for providing the collector configuration. This means that the configuration no longer needs to be defined in the client (execution) environment.

    * Batch reporting of business transactions to the server.

    * Configuration switch to determine if only named business transactions should be reported. Default is false, to enable discovery of business transaction (fragments) available from the execution environment(s) being monitored, but when in a production environment, we would only want the fragments of interest to be reported.

    * Instrumentation rule versioning mechanism. This will enable rules that are only applicable up until a certain version of a technology to be superseded by newer versions of the rule.

The release can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.2.0.Final

The detailed release notes can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12316120&version=12327550

Feature requests and bugs should be reported in our project jira: https://issues.jboss.org/browse/HWKBTM


Regards
Gary

From hrupp at redhat.com  Wed Jul 22 03:22:19 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 22 Jul 2015 09:22:19 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AE66B9.50206@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE66B9.50206@redhat.com>
Message-ID: <A41E5644-7BD4-420B-9F32-9003814E6F15@redhat.com>

On 21 Jul 2015, at 17:35, Thomas Segismont wrote:

> Le 21/07/2015 14:44, Heiko W.Rupp a ?crit :
>> On 21 Jul 2015, at 14:26, Lukas Krejci wrote:
>>> I feel your pain, but please - standardization is more important that
>>> occasional troubles of a single component.
>>
>> +5
> with the them the intended usage of the BOM, I was quite upset. I'll 

I did not want to upset you. What I wanted to convey with that quite
sparse "+5" comment is that we should all over Hawkular use the 
same versions of stuff as it will lessen the maintenance burden.


From theute at redhat.com  Wed Jul 22 04:46:04 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 22 Jul 2015 10:46:04 +0200
Subject: [Hawkular-dev] Hawkular BTM 0.2.0.Final released
In-Reply-To: <1914230502.2094212.1437549427492.JavaMail.zimbra@redhat.com>
References: <1914230502.2094212.1437549427492.JavaMail.zimbra@redhat.com>
Message-ID: <55AF584C.6080600@redhat.com>

Congrats and nice video !

Thomas

On 07/22/2015 09:17 AM, Gary Brown wrote:
> Hi all
>
> I'm pleased to announce the release of version 0.2.0.Final of Hawkular BTM. The main focus for this release has been on enhancing the business transaction collection capabilities.
>
> A quick demo of this version, showing monitoring of two Vertx applications, can be found here: https://youtu.be/TtAXiYhqTSk
>
> Highlights of this release:
>
>      * URI inclusion/exclusion support, allowing business transactions to be filtered based on initial URIs of interest.
>
>      * Propagate business transaction name, identified based on inclusion URI, through subsequent fragments for the same business transaction instance.
>
>      * Child node suppression - provide a mechanism for ignoring child nodes where they add no value. The specific case that prompted this mechanism was when instrumenting JDBC prepared statements.
>
>      * Provide mechanism for capturing header values from different message types, for use where a simple map is not available
>
>      * Define instrumentation rules for Vertx (HTTP and EventBus).
>
>      * Administration REST service, responsible for providing the collector configuration. This means that the configuration no longer needs to be defined in the client (execution) environment.
>
>      * Batch reporting of business transactions to the server.
>
>      * Configuration switch to determine if only named business transactions should be reported. Default is false, to enable discovery of business transaction (fragments) available from the execution environment(s) being monitored, but when in a production environment, we would only want the fragments of interest to be reported.
>
>      * Instrumentation rule versioning mechanism. This will enable rules that are only applicable up until a certain version of a technology to be superseded by newer versions of the rule.
>
> The release can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.2.0.Final
>
> The detailed release notes can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12316120&version=12327550
>
> Feature requests and bugs should be reported in our project jira: https://issues.jboss.org/browse/HWKBTM
>
>
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From tsegismo at redhat.com  Wed Jul 22 04:55:20 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 22 Jul 2015 10:55:20 +0200
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
Message-ID: <55AF5A78.1060307@redhat.com>

The goal of Aakarsh's work is not to implement min/max/avg, of course. 
It's to let users plug in custom functions.

I've talked about min/max/avg because at some point we'll need to be 
able to call builtin functions as well as user defined function, and it 
would be nice to do it seamlessly.

Thank you for talking about RxJava. It makes me think we'll need to 
consider which classes should be visible to user defined functions and 
which shouldn't.

Le 21/07/2015 16:43, John Sanda a ?crit :
> Keep the following in mind. Since the core metrics API is now built on
> RxJava, function params and return types should probably be
> rx.Observable. Some of the work described below may already be covered
> by the work Jay did for HWKMETRICS-144 which involved adding min/max/avg
> functions. To be honest, I think functions like min/max/avg are poor
> candidates for some of the changes being discussed because they are so
> simple. Here is our avg function,
>
>      Func1<Observable<DataPoint<Double>>, Observable<Double>> Average =
> data ->
>              MathObservable.averageDouble(data.map(DataPoint::getValue));
>
> For other, more involved functions, I think we should look first at the
> core operators in Rx.Observable and then maybe consider custom operators[1].
>
> [1] https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators
>
>> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com
>> <mailto:tsegismo at redhat.com>> wrote:
>>
>> Hi,
>>
>> I have looked at Aakarsh's repo:
>> https://github.com/Akki5/hawkular_plugin/
>>
>> It's a good start with an interface describing a doubles to double
>> function, a classloader for implementation loading and a set of initial
>> implementations.
>>
>> In order to integrate this work into Metrics, I think we should follow
>> the following steps:
>>
>> =====
>> #1 Change the contract
>>
>> Doubles to double works great for avg/min/max/... functions on gauge
>> metrics. But we need to consider other metric types.
>>
>> Also, the interface should not only accept data point values, but whole
>> data points. Because some functions need the timestamp to compute the
>> result. % of up availability is a good example.
>>
>> And functions may return different types: Double, Long, AvailabilityType.
>>
>> #2 Update configuration options to let the user set a plugins directory
>>
>> Metrics doc needs will have to be updated.
>>
>> #3 Create a function repository for each metric type
>>
>> We can build on JDK's service loader + Aakarsh's classloader
>> implementation.
>>
>> #4 Add builtin aggregate functions
>>
>> Extract existing Metrics code (min, max, avg, % of up avail, downtime
>> duration) into builtin functions.
>>
>> #5 Document the process of implementing a pluggable function
>>
>> We need to think about function naming as well. Should we use a prefix
>> to identify a builtin function?
>> =====
>>
>> I will start another thread to discuss REST and Core API data query
>> changes.
>>
>> Thoughts?
>>
>> Thanks,
>> 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  Wed Jul 22 05:02:05 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 22 Jul 2015 11:02:05 +0200
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <55AEB94C.4040508@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
	<55AEB94C.4040508@redhat.com>
Message-ID: <55AF5C0D.50707@redhat.com>

Thanks for the pointers, we'll have a look.

Le 21/07/2015 23:27, Jay Shaughnessy a ?crit :
>
> Right, you may find what you need is already in place, or you may find
> that you can spend time on higher-level functions.  In particular, see:
>
> MetricsService:
> <T> Observable<T> findGaugeData(String tenantId, MetricId id, Long
> start, Long end,Func1<Observable<DataPoint<Double>>, Observable<T>>...
> funcs);
>
> Aggregate:
> predefined functions.
>
> Here is an example snippen from
> org.hawkular.alerts.external.metrics.Manager to gather multiple
> aggregates in one call and determine the range:
>
>                      case range: {
>                          Iterator<Double> iterator =
> metrics.findGaugeData(tenantId, metricId, start, end,
>                                  Aggregate.Min, Aggregate.Max)
> .toBlocking().toIterable().iterator();
>                          Double min = iterator.next();
>                          Double max = iterator.next();
>                          value = max - min;
>                          break;
>                      }
>
>
> -Jay
>
> On 7/21/2015 10:43 AM, John Sanda wrote:
>> Keep the following in mind. Since the core metrics API is now built on
>> RxJava, function params and return types should probably be
>> rx.Observable. Some of the work described below may already be covered
>> by the work Jay did for HWKMETRICS-144 which involved adding
>> min/max/avg functions. To be honest, I think functions like
>> min/max/avg are poor candidates for some of the changes being
>> discussed because they are so simple. Here is our avg function,
>>
>> Func1<Observable<DataPoint<Double>>, Observable<Double>> Average =
>> data ->
>> MathObservable.averageDouble(data.map(DataPoint::getValue));
>>
>> For other, more involved functions, I think we should look first at
>> the core operators in Rx.Observable and then maybe consider custom
>> operators[1].
>>
>> [1]
>> https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators
>>
>>> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com
>>> <mailto:tsegismo at redhat.com>> wrote:
>>>
>>> Hi,
>>>
>>> I have looked at Aakarsh's repo:
>>> https://github.com/Akki5/hawkular_plugin/
>>>
>>> It's a good start with an interface describing a doubles to double
>>> function, a classloader for implementation loading and a set of initial
>>> implementations.
>>>
>>> In order to integrate this work into Metrics, I think we should follow
>>> the following steps:
>>>
>>> =====
>>> #1 Change the contract
>>>
>>> Doubles to double works great for avg/min/max/... functions on gauge
>>> metrics. But we need to consider other metric types.
>>>
>>> Also, the interface should not only accept data point values, but whole
>>> data points. Because some functions need the timestamp to compute the
>>> result. % of up availability is a good example.
>>>
>>> And functions may return different types: Double, Long, AvailabilityType.
>>>
>>> #2 Update configuration options to let the user set a plugins directory
>>>
>>> Metrics doc needs will have to be updated.
>>>
>>> #3 Create a function repository for each metric type
>>>
>>> We can build on JDK's service loader + Aakarsh's classloader
>>> implementation.
>>>
>>> #4 Add builtin aggregate functions
>>>
>>> Extract existing Metrics code (min, max, avg, % of up avail, downtime
>>> duration) into builtin functions.
>>>
>>> #5 Document the process of implementing a pluggable function
>>>
>>> We need to think about function naming as well. Should we use a prefix
>>> to identify a builtin function?
>>> =====
>>>
>>> I will start another thread to discuss REST and Core API data query
>>> changes.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> 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 tsegismo at redhat.com  Wed Jul 22 05:02:31 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 22 Jul 2015 11:02:31 +0200
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <7EF09C2B-917C-4FFB-8881-246CCAFA8BB5@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
	<7EF09C2B-917C-4FFB-8881-246CCAFA8BB5@redhat.com>
Message-ID: <55AF5C27.8060701@redhat.com>

Le 22/07/2015 09:16, Heiko W.Rupp a ?crit :
> And still in this case you need a way to supply them at runtime as
> opposed
> to compile them in.
> And this is what this work is about.

Exactly

From jkremser at redhat.com  Wed Jul 22 06:05:17 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Wed, 22 Jul 2015 06:05:17 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
	<2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
	<587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>
Message-ID: <677783888.1359651.1437559517987.JavaMail.zimbra@redhat.com>

Hi,
  thinking about it, it could probably even stay as it is, but it would require the "feed-comm" mvn module to have it's own release cycle independent on hawkular (not share the ${project.version} as it is right now). Also, I think, the feed-comm can't depend back on the root pom via <parent><relativePath>, then it should be possible to release the feed-comm independently of hawkular and break the 'dependency deadlock'.

However, if we want our Travis to do all the mvn deploy fun, then this won't work, so I am +1 on moving it to bus repo (or hawkular-commons, but to me it logically fits more into the hawkular-bus because of the communication nature and their release cycle will be more likely similar than the release cycle of web socket mechanism + embedded C*)

jk


----- Original Message -----
| From: "John Mazzitelli" <mazz at redhat.com>
| To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
| Sent: Wednesday, 22 July, 2015 12:59:44 AM
| Subject: Re: [Hawkular-dev] glue code - where does it go?
| 
| hawkular-commons seems like a good place for glue code that is shared across
| hawkular components.
| 
| I could put this stuff in hawkular-bus since it is "comm" related (though it
| is comm between clients and server, not just comm between server-side
| components)
| 
| This will need to be solved - because I can't release the agent right now.
| Agent needs the feed-comm API which is in hawkular, but hawkular needs the
| agent before it can be released.
| 
| So this:
| 
| https://github.com/hawkular/hawkular/tree/integration-latest-of-everything/modules/feed-comm
| 
| needs to be moved to some location other than the hawkular build.
| 
| 
| ----- Original Message -----
| > Hello,
| > 
| > We have this repository that is now used only for the embedded Cassandra
| > distribution. Do you think it would a good place for this kind of comm
| > code?
| > 
| > 
| > https://github.com/hawkular/hawkular-commons
| > 
| > 
| > Thank you,
| > Stefan
| > 
| > ----- Original Message -----
| > > From: "John Mazzitelli" <mazz at redhat.com>
| > > To: "Discussions around Hawkular development"
| > > <hawkular-dev at lists.jboss.org>
| > > Sent: Tuesday, July 21, 2015 11:42:06 AM
| > > Subject: [Hawkular-dev] glue code - where does it go?
| > > 
| > > We have a fairly annoying problem with our current glue code location.
| > > 
| > > Right now, we have the "glue code" that is known as "feed-comm" inside
| > > the
| > > hawkular repo - there is specifically the "feed-comm-api" artifact that
| > > contains some Java code that is required for use by Java-based feeds in
| > > order to talk to the server (also includes some JSON schemas for non-Java
| > > feeds to use).
| > > 
| > > But since this is in hawkular repo, my agent needs a hawkular release in
| > > order to pull in the feed-comm-api artifact! Well, obviously, that's what
| > > we
| > > are moving toward for next week - a alpha hawkualr release. But until
| > > that
| > > happens, I can't release the agent.
| > > 
| > > But, interestingly enough, because hawkular (kettle) contains the agent,
| > > hawkular can't be released until it has an agent release to pull in.
| > > 
| > > Round and round we go.
| > > 
| > > I really hate saying we need yet another repo, but how else can we get
| > > glue
| > > code that is common between server and feeds/agents that isn't dependent
| > > upon a hawkular release being made?
| > > _______________________________________________
| > > 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 Jul 22 08:51:58 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 22 Jul 2015 08:51:58 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <677783888.1359651.1437559517987.JavaMail.zimbra@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
	<2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
	<587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>
	<677783888.1359651.1437559517987.JavaMail.zimbra@redhat.com>
Message-ID: <212574305.2291772.1437569518634.JavaMail.zimbra@redhat.com>

Yes, I am going to move it to bus. I think its a good place. Doing that now.

----- Original Message -----
> Hi,
>   thinking about it, it could probably even stay as it is, but it would
>   require the "feed-comm" mvn module to have it's own release cycle
>   independent on hawkular (not share the ${project.version} as it is right
>   now). Also, I think, the feed-comm can't depend back on the root pom via
>   <parent><relativePath>, then it should be possible to release the
>   feed-comm independently of hawkular and break the 'dependency deadlock'.
> 
> However, if we want our Travis to do all the mvn deploy fun, then this won't
> work, so I am +1 on moving it to bus repo (or hawkular-commons, but to me it
> logically fits more into the hawkular-bus because of the communication
> nature and their release cycle will be more likely similar than the release
> cycle of web socket mechanism + embedded C*)
> 
> jk
> 
> 
> ----- Original Message -----
> | From: "John Mazzitelli" <mazz at redhat.com>
> | To: "Discussions around Hawkular development"
> | <hawkular-dev at lists.jboss.org>
> | Sent: Wednesday, 22 July, 2015 12:59:44 AM
> | Subject: Re: [Hawkular-dev] glue code - where does it go?
> | 
> | hawkular-commons seems like a good place for glue code that is shared
> | across
> | hawkular components.
> | 
> | I could put this stuff in hawkular-bus since it is "comm" related (though
> | it
> | is comm between clients and server, not just comm between server-side
> | components)
> | 
> | This will need to be solved - because I can't release the agent right now.
> | Agent needs the feed-comm API which is in hawkular, but hawkular needs the
> | agent before it can be released.
> | 
> | So this:
> | 
> | https://github.com/hawkular/hawkular/tree/integration-latest-of-everything/modules/feed-comm
> | 
> | needs to be moved to some location other than the hawkular build.
> | 
> | 
> | ----- Original Message -----
> | > Hello,
> | > 
> | > We have this repository that is now used only for the embedded Cassandra
> | > distribution. Do you think it would a good place for this kind of comm
> | > code?
> | > 
> | > 
> | > https://github.com/hawkular/hawkular-commons
> | > 
> | > 
> | > Thank you,
> | > Stefan
> | > 
> | > ----- Original Message -----
> | > > From: "John Mazzitelli" <mazz at redhat.com>
> | > > To: "Discussions around Hawkular development"
> | > > <hawkular-dev at lists.jboss.org>
> | > > Sent: Tuesday, July 21, 2015 11:42:06 AM
> | > > Subject: [Hawkular-dev] glue code - where does it go?
> | > > 
> | > > We have a fairly annoying problem with our current glue code location.
> | > > 
> | > > Right now, we have the "glue code" that is known as "feed-comm" inside
> | > > the
> | > > hawkular repo - there is specifically the "feed-comm-api" artifact that
> | > > contains some Java code that is required for use by Java-based feeds in
> | > > order to talk to the server (also includes some JSON schemas for
> | > > non-Java
> | > > feeds to use).
> | > > 
> | > > But since this is in hawkular repo, my agent needs a hawkular release
> | > > in
> | > > order to pull in the feed-comm-api artifact! Well, obviously, that's
> | > > what
> | > > we
> | > > are moving toward for next week - a alpha hawkualr release. But until
> | > > that
> | > > happens, I can't release the agent.
> | > > 
> | > > But, interestingly enough, because hawkular (kettle) contains the
> | > > agent,
> | > > hawkular can't be released until it has an agent release to pull in.
> | > > 
> | > > Round and round we go.
> | > > 
> | > > I really hate saying we need yet another repo, but how else can we get
> | > > glue
> | > > code that is common between server and feeds/agents that isn't
> | > > dependent
> | > > upon a hawkular release being made?
> | > > _______________________________________________
> | > > 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 Jul 22 09:17:48 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 22 Jul 2015 15:17:48 +0200
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
Message-ID: <48F39174-D258-4F36-A899-625F8D4859A7@redhat.com>

Hey,

I did not yet go though all the emails, but want to add another point 
here, that could be a potential alternative:

The underlying issue is that a g:a:xyz-SNAPSHOT is a moving target and 
not necessarily the same for 2 developers looking at the same thingy, 
which is pretty bad.

Now, for every push from Travis to the Nexus, a named snapshot is 
created, where -SNAPSHOT is basically an alias for the latest.

This allows us to use *during* the 4 week cadence those named snapshots 
as dependencies, which are pointing to the same bits for every 
developer.

For a (real) *release* of Hawkular or any component, such dependencies 
are not allowed for the simple reason that those named snapshots still 
do not show up on Central.

This way we will not have the non-reproducibility of -SNAPSHOT, but can 
still move ahead with too many releases of components.

The other aspects of "release early, release often", "cut small slices", 
"changes go into CI/CD and go live quickly" all still apply.

   Heiko

From jshaughn at redhat.com  Wed Jul 22 09:41:07 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 22 Jul 2015 09:41:07 -0400
Subject: [Hawkular-dev] [Metrics] Pluggable aggregation functions: next
 steps
In-Reply-To: <55AF5C0D.50707@redhat.com>
References: <55AE145A.4000008@redhat.com>
	<B78A0D31-20D3-446F-8DE9-B538D76819A6@redhat.com>
	<55AEB94C.4040508@redhat.com> <55AF5C0D.50707@redhat.com>
Message-ID: <55AF9D73.9030605@redhat.com>


Sure, sorry to have missed the point.  This is interesting though, it 
may pave the way for being to alert on values generated by a plugin 
specifically for the purpose of that alert use case.

On 7/22/2015 5:02 AM, Thomas Segismont wrote:
> Thanks for the pointers, we'll have a look.
>
> Le 21/07/2015 23:27, Jay Shaughnessy a ?crit :
>> Right, you may find what you need is already in place, or you may find
>> that you can spend time on higher-level functions.  In particular, see:
>>
>> MetricsService:
>> <T> Observable<T> findGaugeData(String tenantId, MetricId id, Long
>> start, Long end,Func1<Observable<DataPoint<Double>>, Observable<T>>...
>> funcs);
>>
>> Aggregate:
>> predefined functions.
>>
>> Here is an example snippen from
>> org.hawkular.alerts.external.metrics.Manager to gather multiple
>> aggregates in one call and determine the range:
>>
>>                       case range: {
>>                           Iterator<Double> iterator =
>> metrics.findGaugeData(tenantId, metricId, start, end,
>>                                   Aggregate.Min, Aggregate.Max)
>> .toBlocking().toIterable().iterator();
>>                           Double min = iterator.next();
>>                           Double max = iterator.next();
>>                           value = max - min;
>>                           break;
>>                       }
>>
>>
>> -Jay
>>
>> On 7/21/2015 10:43 AM, John Sanda wrote:
>>> Keep the following in mind. Since the core metrics API is now built on
>>> RxJava, function params and return types should probably be
>>> rx.Observable. Some of the work described below may already be covered
>>> by the work Jay did for HWKMETRICS-144 which involved adding
>>> min/max/avg functions. To be honest, I think functions like
>>> min/max/avg are poor candidates for some of the changes being
>>> discussed because they are so simple. Here is our avg function,
>>>
>>> Func1<Observable<DataPoint<Double>>, Observable<Double>> Average =
>>> data ->
>>> MathObservable.averageDouble(data.map(DataPoint::getValue));
>>>
>>> For other, more involved functions, I think we should look first at
>>> the core operators in Rx.Observable and then maybe consider custom
>>> operators[1].
>>>
>>> [1]
>>> https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators
>>>
>>>> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com
>>>> <mailto:tsegismo at redhat.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have looked at Aakarsh's repo:
>>>> https://github.com/Akki5/hawkular_plugin/
>>>>
>>>> It's a good start with an interface describing a doubles to double
>>>> function, a classloader for implementation loading and a set of initial
>>>> implementations.
>>>>
>>>> In order to integrate this work into Metrics, I think we should follow
>>>> the following steps:
>>>>
>>>> =====
>>>> #1 Change the contract
>>>>
>>>> Doubles to double works great for avg/min/max/... functions on gauge
>>>> metrics. But we need to consider other metric types.
>>>>
>>>> Also, the interface should not only accept data point values, but whole
>>>> data points. Because some functions need the timestamp to compute the
>>>> result. % of up availability is a good example.
>>>>
>>>> And functions may return different types: Double, Long, AvailabilityType.
>>>>
>>>> #2 Update configuration options to let the user set a plugins directory
>>>>
>>>> Metrics doc needs will have to be updated.
>>>>
>>>> #3 Create a function repository for each metric type
>>>>
>>>> We can build on JDK's service loader + Aakarsh's classloader
>>>> implementation.
>>>>
>>>> #4 Add builtin aggregate functions
>>>>
>>>> Extract existing Metrics code (min, max, avg, % of up avail, downtime
>>>> duration) into builtin functions.
>>>>
>>>> #5 Document the process of implementing a pluggable function
>>>>
>>>> We need to think about function naming as well. Should we use a prefix
>>>> to identify a builtin function?
>>>> =====
>>>>
>>>> I will start another thread to discuss REST and Core API data query
>>>> changes.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> 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
>

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

From tsegismo at redhat.com  Wed Jul 22 10:13:14 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 22 Jul 2015 16:13:14 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
Message-ID: <55AFA4FA.7080306@redhat.com>

Hi everyone,

Right now, when you query data in Metrics, you can, given a time range:
- get raw data
- get raw data having some tags
- get a "bucketed" view of raw data with on-the fly aggregates
- get periods for which a condition on the value holds true

But you can't mix these capabilities.

For example, you can't ask for periods where the avg of a gauge, 
computed over 1 min buckets, is greater than a threshold.

It's not possible either to express AND/OR in tags or condition queries.

Searching by tags is useful, but users have to tag data manually (unless 
the collector adds some predefined tags). It would be useful to be able 
to operate on data coming from different metrics having similar names: 
like tell me the average cpu usage over all my web hosts, provided the 
metrics are _webhost*.cpu.usage_

When aggregating data, users should able to provide the name of the 
function, be it a builtin or user defined function.

Last but not least, when rollups will be implemented, users should 
probably not have to care about where the data is stored,if they ask for 
the 1-month average of a metric over the past year, or the 30-seconds 
average over the past five minutes (think about the UI zooming graphs).

The examples are not completely fabricated, it's feedback I got while 
presenting Hawkular. I understood Stefan heard similar comments during 
Summit.

I'm starting this thread to gather inputs so that we can build a 
powerful, unified query API. Feel free to provide more use cases and/or 
ideas for implementation.

Thanks!
Thomas

From jsanda at redhat.com  Wed Jul 22 10:38:28 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 22 Jul 2015 10:38:28 -0400
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <55AFA4FA.7080306@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
Message-ID: <B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>


> On Jul 22, 2015, at 10:13 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi everyone,
> 
> Right now, when you query data in Metrics, you can, given a time range:
> - get raw data
> - get raw data having some tags
> - get a "bucketed" view of raw data with on-the fly aggregates
> - get periods for which a condition on the value holds true
> 
> But you can't mix these capabilities.
> 
> For example, you can't ask for periods where the avg of a gauge, 
> computed over 1 min buckets, is greater than a threshold.
> 
> It's not possible either to express AND/OR in tags or condition queries.

gayak has already added support for OR and is working on support for AND in HWKMETRICS-180. He is also looking into a mini query language for tag filtering as part of this work.

> 
> Searching by tags is useful, but users have to tag data manually (unless 
> the collector adds some predefined tags). It would be useful to be able 
> to operate on data coming from different metrics having similar names: 
> like tell me the average cpu usage over all my web hosts, provided the 
> metrics are _webhost*.cpu.usage_

We added support for tagging data very early on in the project, but I am becoming more of the mindset that we do not want this. Tagging metrics/time series and subsequently searching for metric data data based on those tags are common use cases. It might be worth thinking about events in place of tagging individual data points. 

> 
> When aggregating data, users should able to provide the name of the 
> function, be it a builtin or user defined function.

I think user defined functions sound nice but not that critical. I think that we can cover most use cases with built-in functions. 

> 
> Last but not least, when rollups will be implemented, users should 
> probably not have to care about where the data is stored,if they ask for 
> the 1-month average of a metric over the past year, or the 30-seconds 
> average over the past five minutes (think about the UI zooming graphs).

Agreed. The fact that we might be generating and storing multiple time series for a metric is in large part an implementation detail to make querying more efficient and to reduce storage footprint on disk. In RHQ we never exposed the generated time series. The date range in request determined which time series we queried.

Whether we generate aggregated metrics in an ad hoc fashion at query time or they are pre-computed, we are still dealing with the same data types/structures. There should not be two separate APIs. 

> 
> The examples are not completely fabricated, it's feedback I got while 
> presenting Hawkular. I understood Stefan heard similar comments during 
> Summit.
> 
> I'm starting this thread to gather inputs so that we can build a 
> powerful, unified query API. Feel free to provide more use cases and/or 
> ideas for implementation.
> 
> Thanks!
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From snegrea at redhat.com  Wed Jul 22 10:41:18 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 22 Jul 2015 10:41:18 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.5.0 - Release
In-Reply-To: <481943187.17547774.1435014788401.JavaMail.zimbra@redhat.com>
Message-ID: <749554132.1906260.1437576078649.JavaMail.zimbra@redhat.com>

Hello Everybody,

I am happy to announce release 0.5.0 of Hawkular Metrics. This is a shoulder release that is delivered ahead of the proposed schedule to accommodate the upcoming release of Hawkular - Alpha 3. The release contains mainly bug fixes and small REST API enhancements. Major changes planned (such as Hawkular Bus integration and gauge metrics aggregation) for this release have been postponed for future releases.

For a complete list of changes please follow the JIRA release link below; artifacts are available in both Github and JBoss Nexus maven repository.

Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327548

Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.5.0

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


A  big "Thank you" goes to John Sanda, Thomas Segismont, Matt Wringe, Michael Burman, and Mike Thompson for their project contributions.


Thank you,
Stefan Negrea

Software Engineer


From theute at redhat.com  Wed Jul 22 10:45:01 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 22 Jul 2015 16:45:01 +0200
Subject: [Hawkular-dev] Hawkular Metrics 0.5.0 - Release
In-Reply-To: <749554132.1906260.1437576078649.JavaMail.zimbra@redhat.com>
References: <481943187.17547774.1435014788401.JavaMail.zimbra@redhat.com>
	<749554132.1906260.1437576078649.JavaMail.zimbra@redhat.com>
Message-ID: <55AFAC6D.1040701@redhat.com>

Congrats !

On 07/22/2015 04:41 PM, Stefan Negrea wrote:
> Hello Everybody,
>
> I am happy to announce release 0.5.0 of Hawkular Metrics. This is a shoulder release that is delivered ahead of the proposed schedule to accommodate the upcoming release of Hawkular - Alpha 3. The release contains mainly bug fixes and small REST API enhancements. Major changes planned (such as Hawkular Bus integration and gauge metrics aggregation) for this release have been postponed for future releases.
>
> For a complete list of changes please follow the JIRA release link below; artifacts are available in both Github and JBoss Nexus maven repository.
>
> Jira release tracker:
> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327548
>
> Github Release:
> https://github.com/hawkular/hawkular-metrics/releases/tag/0.5.0
>
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
>
>
> A  big "Thank you" goes to John Sanda, Thomas Segismont, Matt Wringe, Michael Burman, and Mike Thompson for their project contributions.
>
>
> 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 jkremser at redhat.com  Wed Jul 22 15:10:00 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Wed, 22 Jul 2015 15:10:00 -0400 (EDT)
Subject: [Hawkular-dev] faster dev build of hawkular
In-Reply-To: <170970370.1515824.1437591983715.JavaMail.zimbra@redhat.com>
Message-ID: <377520456.1516491.1437592200193.JavaMail.zimbra@redhat.com>

Hello there,
  there is a PR hanging https://github.com/hawkular/hawkular/pull/342

that will change the way the -Pdev profile works. Currently, it creates the zip and gz archive, but most of us don't use it during the development. The directory is pretty much ok. So it won't be created anymore, if you need the zip/gz with precreated jdoe:password, use -Pdozip.

I am sending this not to break anyones automated workflow. I asked Filip and it seems QE don't depend on it.

Perhaps the dozip profile can go away completely, then.

jk

From mazz at redhat.com  Wed Jul 22 15:25:30 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 22 Jul 2015 15:25:30 -0400 (EDT)
Subject: [Hawkular-dev] faster dev build of hawkular
In-Reply-To: <377520456.1516491.1437592200193.JavaMail.zimbra@redhat.com>
References: <377520456.1516491.1437592200193.JavaMail.zimbra@redhat.com>
Message-ID: <1700458370.2741496.1437593130878.JavaMail.zimbra@redhat.com>

I like this. I hate waiting for those archives to be built when I am just going to run straight out of target/hawkular-1.x.x.x/.. directory.

I think its fine leaving -Pdozip - in case we want to package up our dev build and send to someone to try for whatever reason.

----- Original Message -----
> Hello there,
>   there is a PR hanging https://github.com/hawkular/hawkular/pull/342
> 
> that will change the way the -Pdev profile works. Currently, it creates the
> zip and gz archive, but most of us don't use it during the development. The
> directory is pretty much ok. So it won't be created anymore, if you need the
> zip/gz with precreated jdoe:password, use -Pdozip.
> 
> I am sending this not to break anyones automated workflow. I asked Filip and
> it seems QE don't depend on it.
> 
> Perhaps the dozip profile can go away completely, then.
> 
> jk
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jsanda at redhat.com  Wed Jul 22 23:55:22 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 22 Jul 2015 23:55:22 -0400
Subject: [Hawkular-dev] Availability revisited
In-Reply-To: <B3BF799F-9E56-4A76-BA28-FA8BF0AD3DC4@redhat.com>
References: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
	<9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>
	<B3BF799F-9E56-4A76-BA28-FA8BF0AD3DC4@redhat.com>
Message-ID: <37F21922-7006-441F-8692-03E134F63164@redhat.com>


> On Jul 20, 2015, at 5:13 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 16 Jul 2015, at 3:45, John Sanda wrote:
>> Are there any docs, notes, etc. on the feed-comm system? I am not 
>> familiar with this.
> 
> Mazz should have /will talk about it. But at the end this has only 
> little
> to do with this topic, as any sort of availability should work with
> "normal" REST-based-feeds too.
> 
>> 
>> Why do we need to store the last seen availability in memory?
> 
> Because we can? :-)
> Seriously: in RHQ we had huge issues with all the availability records
> that were never cached, so everything working with "current 
> availability)
> had to go to the database with its latencies and costs.

It is premature to say that we need to cache availability while we have only implemented simple read/write operations without any extensive performance/stress testing. I am aware that we had issues with availability in RHQ, but we stored availability in the RDBMS. I think we should wait and see how a Cassandra based implementation looks, do some performance testing, and then make a more informed decision about whether or not caching is needed.

> Availability is by nature something run-length encoded. Unlike
> counter or gauge metrics.
> We could of course store each incoming new availability record, so that
> its (start) timestamp would reflect the last seen time, but querying for
> "since when was it up" would result in a pretty heavy backtracking query
> (with some luck we have a limit like "in the last hour/day", but what if
> we want an absolute date or over the last year.

The better we understand the queries we need to support, then we can better design the schema to optimize for those queries. Suppose we store availability as follows

CREATE TABLE availability (
    tenant text,
    id text,
    bucket timestamp,
    time timestamp,
    value text,    // stored here as text for simplicity
    PRIMARY KEY ((tenant, id, bucket), time)
) WITH CLUSTERING ORDER BY (time DESC);

The bucket column is for date partitioning to ensure partitions do not grow too large. If we do not collect availability more frequently than say every minute, we might be fine with using bucket sizes of 6 hrs, 12 hrs, or even 24 hrs.

We will introduce an additional table to help us answer ?since when it was up?,

CREATE TABLE avail_state_change (
    tenant text,
    avail_id text,
    value text,
    time timestamp,
    PRIMARY KEY ((tenant, avail_id), value)
);

The schema will actually allow us to answer the more general question, ?the avail state was X since when.? The avail_state_change table will store at most one row for each recorded availability state for a particular resource. When availability is reported, we write to both tables. To answer our query we can execute the following queries in parallel,

SELECT value, timestamp FROM availability WHERE tenant = ? AND id = ? and bucket = ? LIMIT 1;

SELECT value, time FROM avail_state_change WHERE tenant_id = ? and avail_id = ?;

If the value returned from the availability table query is UP, then we compare its timestamp against the timestamp of the DOWN row returned from the avail_state_change query.

We need to play around with schema changes like this to see if it will satisfy query performance requirements. And then if it doesn?t, we should look at tweaking the key cache, and then look at the row cache, and then finally look at a separate caching tier.

We can implement background aggregation jobs to store run-length encoded values that will allow to efficiently answer similar queries for the more distant past.

> 
> This is why I am thinking about keeping the RLE with start/stop/state,
> but augmented by "last seen" for the in-memory version.
> 
> Keeping last seen in memory prevents all the expensive backend-hits
> (either getting the same value over and over again, or doing in-place 
> updates)
> and still allows jobs to check if the last-seen is e.g. within the last 
> minute
> and react accordingly (RHQ-term: "backfill?).

Again, I think that the schema that I have described above allows us to handle this efficiently.

> 
>> If you talking about correlation, then I am +1. When I think about 
>> RHQ, the user could easily see availability state change, but he would 
>> have to go hunting around to see what precipitated it.
> 
> This is certainly another aspect of this "root cause analysis".
> 
>   Heiko
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From hrupp at redhat.com  Thu Jul 23 05:50:55 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 23 Jul 2015 11:50:55 +0200
Subject: [Hawkular-dev] Availability revisited
In-Reply-To: <37F21922-7006-441F-8692-03E134F63164@redhat.com>
References: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
	<9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>
	<B3BF799F-9E56-4A76-BA28-FA8BF0AD3DC4@redhat.com>
	<37F21922-7006-441F-8692-03E134F63164@redhat.com>
Message-ID: <885430D5-813E-4391-A65D-B2B4EC590025@redhat.com>

On 23 Jul 2015, at 5:55, John Sanda wrote:
> extensive performance/stress testing. I am aware that we had issues 
> with availability in RHQ, but we stored availability in the RDBMS. I

One thing that is certainly not different between RDBMS and C* is the
fact that they are (in a normal scenario) remote and thus there is some
latency of network access.

> think we should wait and see how a Cassandra based implementation 
> looks, do some performance testing, and then make a more informed 
> decision about whether or not caching is needed.

Agreed.

Ok, so that addresses one part of my original email.

We still need to consider sub-states ( "up, but reload needed" ).

How do we tackle this?

What values for availability will we allow?

From hrupp at redhat.com  Thu Jul 23 07:23:14 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 23 Jul 2015 13:23:14 +0200
Subject: [Hawkular-dev] "Generated UI" ?
Message-ID: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>

hey,

for upcoming tasks like 

"define and manage jdbc driver"
"define and manage data source"
and others

I wonder if we could speed up the UI development a bit by 
creating some skeletons for html , and also ts-code
by running some scripts over the resource type
definitions we have.

This is not meant to be the 100% UI, but rather a start where
the UI folks can improve on, but which could give us a (working)
head start.

Does that make any sense?

  Heiko

From miburman at redhat.com  Thu Jul 23 08:09:47 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 23 Jul 2015 08:09:47 -0400 (EDT)
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
	<B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
Message-ID: <198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>

Hi,

Right, the PR HWKMETRICS-180 currently implements the following query language (as inspired by OpenTSDB/Prometheus):

tags=tagName:tagValue,tagName2,tagValue2 etc like previously in the REST-API query, splitted at the ",". All of these given names and values are considered as "AND", so it is read like:

tagName:tagValue AND tagName2:tagValue2 (both must match)

There are some identifiers which allow modifications to the query, namely at this point:

"*" as the value and "|" in the value:

tagName:*,tagName2:tagValue2|tagValue3

That one would be read as:

tagName:ANY AND (tagName2:tagValue2 OR tagName2:tagValue3)

ANY means that the tag must exists for the metric definition, but the value can be anything. The query against metrics_tags_idx is done with values for these OR operations and exact matches, and against only the clustering column tname in case of "*" query. Now, one feature that both of those systems mentioned earlier do also is regexp-querying, the Prometheus syntax for that would be:

tagName:~regexpValue

The implementation for that one is relatively simple, we discard the tvalue fetching and just get those values as with tagName and then apply the given regexp filtering. However, what sort of features do we want from this query language and how should this query language look like? At the moment it was designed to be useable from the REST-API (and to mimick those two systems as some might be familiar with them already).

  - Micke

PS. The IRC nickname is "Yak", but someone registered on Freenode so I can't use it there unlike in every other major IRC-network. So I'm using a name of one of my pre-historic bots there.

----- Original Message -----
From: "John Sanda" <jsanda at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Wednesday, July 22, 2015 5:38:28 PM
Subject: Re: [Hawkular-dev] [Metrics] Unified query support brainstorming


> On Jul 22, 2015, at 10:13 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi everyone,
> 
> Right now, when you query data in Metrics, you can, given a time range:
> - get raw data
> - get raw data having some tags
> - get a "bucketed" view of raw data with on-the fly aggregates
> - get periods for which a condition on the value holds true
> 
> But you can't mix these capabilities.
> 
> For example, you can't ask for periods where the avg of a gauge, 
> computed over 1 min buckets, is greater than a threshold.
> 
> It's not possible either to express AND/OR in tags or condition queries.

gayak has already added support for OR and is working on support for AND in HWKMETRICS-180. He is also looking into a mini query language for tag filtering as part of this work.

> 
> Searching by tags is useful, but users have to tag data manually (unless 
> the collector adds some predefined tags). It would be useful to be able 
> to operate on data coming from different metrics having similar names: 
> like tell me the average cpu usage over all my web hosts, provided the 
> metrics are _webhost*.cpu.usage_

We added support for tagging data very early on in the project, but I am becoming more of the mindset that we do not want this. Tagging metrics/time series and subsequently searching for metric data data based on those tags are common use cases. It might be worth thinking about events in place of tagging individual data points. 

> 
> When aggregating data, users should able to provide the name of the 
> function, be it a builtin or user defined function.

I think user defined functions sound nice but not that critical. I think that we can cover most use cases with built-in functions. 

> 
> Last but not least, when rollups will be implemented, users should 
> probably not have to care about where the data is stored,if they ask for 
> the 1-month average of a metric over the past year, or the 30-seconds 
> average over the past five minutes (think about the UI zooming graphs).

Agreed. The fact that we might be generating and storing multiple time series for a metric is in large part an implementation detail to make querying more efficient and to reduce storage footprint on disk. In RHQ we never exposed the generated time series. The date range in request determined which time series we queried.

Whether we generate aggregated metrics in an ad hoc fashion at query time or they are pre-computed, we are still dealing with the same data types/structures. There should not be two separate APIs. 

> 
> The examples are not completely fabricated, it's feedback I got while 
> presenting Hawkular. I understood Stefan heard similar comments during 
> Summit.
> 
> I'm starting this thread to gather inputs so that we can build a 
> powerful, unified query API. Feel free to provide more use cases and/or 
> ideas for implementation.
> 
> Thanks!
> 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 mwringe at redhat.com  Thu Jul 23 09:42:25 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 23 Jul 2015 09:42:25 -0400
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
Message-ID: <55B0EF41.8030605@redhat.com>



On 23/07/15 07:23 AM, Heiko W.Rupp wrote:
> hey,
>
> for upcoming tasks like
>
> "define and manage jdbc driver"
> "define and manage data source"
> and others
>
> I wonder if we could speed up the UI development a bit by
> creating some skeletons for html , and also ts-code
> by running some scripts over the resource type
> definitions we have.
>
> This is not meant to be the 100% UI, but rather a start where
> the UI folks can improve on, but which could give us a (working)
> head start.
>
> Does that make any sense?

Is the plan that the backend developer create a rough UI, then the UX 
team comes in to properly design it and give the designs to the UI 
developers to actually implement it?

The problem I have with this is that even though the rough UI made by 
developers is meant to be temporary, it has a habit of becoming more 
permanent. Usually due to time and priority constraints. Everyone only 
has so much time to put into things, and something ugly and awkward but 
functional is usually less priority than something which needs to be 
done and is not up and running yet.

The other thing is that UX is can be really hard, and it might be 
tempting to just make the developer created awkward UI look better 
rather than solving the real UX problems.

[Note: I am not saying that a developer cannot create a really good 
awesome UI/UX here, I am speaking more from my own experiences and what 
I have seen in the past on projects. There is a reason we have UX people 
on the team handling things :)]

But I guess all we would need to do is make sure that the rough UI is 
handled somewhere other than the main branch so that it doesn't 
interfere with the actual console.

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


From stlewis at redhat.com  Thu Jul 23 09:47:31 2015
From: stlewis at redhat.com (Stan Lewis)
Date: Thu, 23 Jul 2015 09:47:31 -0400 (EDT)
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
Message-ID: <576614376.3446926.1437659251937.JavaMail.zimbra@redhat.com>

Is this all form work?  Might want to consider using hawtio's form plugins perhaps, all you need to come up with then is a json schema, live examples at -> http://forms.hawt.io

----- Original Message -----
> hey,
> 
> for upcoming tasks like
> 
> "define and manage jdbc driver"
> "define and manage data source"
> and others
> 
> I wonder if we could speed up the UI development a bit by
> creating some skeletons for html , and also ts-code
> by running some scripts over the resource type
> definitions we have.
> 
> This is not meant to be the 100% UI, but rather a start where
> the UI folks can improve on, but which could give us a (working)
> head start.
> 
> Does that make any sense?
> 
>   Heiko
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mithomps at redhat.com  Thu Jul 23 10:00:20 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 23 Jul 2015 07:00:20 -0700
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
Message-ID: <71C6919F-6714-4094-A41B-9DFB8E98C133@redhat.com>


> On 23 Jul 2015, at 04:23, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> hey,
> 
> for upcoming tasks like 
> 
> "define and manage jdbc driver"
> "define and manage data source"
> and others
> 
> I wonder if we could speed up the UI development a bit by 
> creating some skeletons for html , and also ts-code
> by running some scripts over the resource type
> definitions we have.
> 
> This is not meant to be the 100% UI, but rather a start where
> the UI folks can improve on, but which could give us a (working)
> head start.
> 
> Does that make any sense?

Honestly, I don?t really think this would help. The pages(html/css) are pretty easy to find something similar and cut/paste (especially with UXD help) and the controllers are also dead simple. Most time is spent integrating with the APIs.

? Mike


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



From hrupp at redhat.com  Thu Jul 23 10:45:34 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 23 Jul 2015 16:45:34 +0200
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <71C6919F-6714-4094-A41B-9DFB8E98C133@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
	<71C6919F-6714-4094-A41B-9DFB8E98C133@redhat.com>
Message-ID: <6BE31239-04A0-4115-8209-91DB93E41038@redhat.com>

On 23 Jul 2015, at 16:00, mike thompson wrote:

> Honestly, I don?t really think this would help. The pages(html/css) 
> are pretty easy to find something similar and cut/paste (especially 
> with UXD help) and the controllers are also dead simple.

Ok, fine then :)


From mithomps at redhat.com  Thu Jul 23 18:11:55 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 23 Jul 2015 15:11:55 -0700
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <576614376.3446926.1437659251937.JavaMail.zimbra@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
	<576614376.3446926.1437659251937.JavaMail.zimbra@redhat.com>
Message-ID: <967F0959-E8E7-486A-AE65-2B67E80221EB@redhat.com>


> On 23 Jul 2015, at 06:47, Stan Lewis <stlewis at redhat.com> wrote:
> 
> Is this all form work?  Might want to consider using hawtio's form plugins perhaps, all you need to come up with then is a json schema, live examples at -> http://forms.hawt.io <http://forms.hawt.io/>

Stan, thanks for the tips. Much of this is forms work, and I really like the declarative nature of hawt.io forms (reminds me of Angular Formly (http://angular-formly.com/ <http://angular-formly.com/>) . One of the difficulties we face with form libraries in general, is their PatternFly compliance. We work closely with our UXD counterparts and they usually provide the html/css (using PatternFly). We take those designs (the view) after lengthy discussions between the teams and integrate them with our front-end/backend. So as developers we are not the only ones working with the html/view.

I see two hurdles with Hawt.io forms:

1) Hawt.io form PatternFly compliance
2) Get our UXD folks to use Hawt.io forms for their designs

I definitely like the idea.

? Mike

P.S. I know there is a current effort in PatternFly to create angular wrappers around their components. Perhaps this is great area of overlap to participate in?


> 
> ----- Original Message -----
>> hey,
>> 
>> for upcoming tasks like
>> 
>> "define and manage jdbc driver"
>> "define and manage data source"
>> and others
>> 
>> I wonder if we could speed up the UI development a bit by
>> creating some skeletons for html , and also ts-code
>> by running some scripts over the resource type
>> definitions we have.
>> 
>> This is not meant to be the 100% UI, but rather a start where
>> the UI folks can improve on, but which could give us a (working)
>> head start.
>> 
>> Does that make any sense?
>> 
>>  Heiko
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

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

From stlewis at redhat.com  Thu Jul 23 19:48:41 2015
From: stlewis at redhat.com (Stan Lewis)
Date: Thu, 23 Jul 2015 19:48:41 -0400 (EDT)
Subject: [Hawkular-dev] "Generated UI" ?
In-Reply-To: <967F0959-E8E7-486A-AE65-2B67E80221EB@redhat.com>
References: <8A40050B-9D95-4B6A-9CF9-413287C40655@redhat.com>
	<576614376.3446926.1437659251937.JavaMail.zimbra@redhat.com>
	<967F0959-E8E7-486A-AE65-2B67E80221EB@redhat.com>
Message-ID: <289562304.3744156.1437695321473.JavaMail.zimbra@redhat.com>

hawtio-forms does actually import patternfly's css already, though I'm sure tweaks could be necessary here and there.  Actually all of the hawtio projects already at least work with patternfly and bring in the CSS definitions, though I'm sure we've a few widgets in hawtio that don't have patternfly rules as they're custom controls etc.

----- Original Message -----
> 
> 
> Stan, thanks for the tips. Much of this is forms work, and I really like the
> declarative nature of hawt.io forms (reminds me of Angular Formly (
> http://angular-formly.com/ ) . One of the difficulties we face with form
> libraries in general, is their PatternFly compliance. We work closely with
> our UXD counterparts and they usually provide the html/css (using
> PatternFly). We take those designs (the view) after lengthy discussions
> between the teams and integrate them with our front-end/backend. So as
> developers we are not the only ones working with the html/view.
> 
> I see two hurdles with Hawt.io forms:
> 
> 1) Hawt.io form PatternFly compliance
> 2) Get our UXD folks to use Hawt.io forms for their designs
> 
> I definitely like the idea.
> 
> ? Mike
> 
> P.S. I know there is a current effort in PatternFly to create angular
> wrappers around their components. Perhaps this is great area of overlap to
> participate in?
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From ppalaga at redhat.com  Fri Jul 24 04:49:29 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 10:49:29 +0200
Subject: [Hawkular-dev] faster dev build of hawkular
In-Reply-To: <1700458370.2741496.1437593130878.JavaMail.zimbra@redhat.com>
References: <377520456.1516491.1437592200193.JavaMail.zimbra@redhat.com>
	<1700458370.2741496.1437593130878.JavaMail.zimbra@redhat.com>
Message-ID: <55B1FC19.3000300@redhat.com>

Good idea, thanks for doing it, Jirko.

BTW, -Pdev,cache does not work properly ATM:
https://issues.jboss.org/browse/HAWKULAR-476

-- P

On 2015-07-22 21:25, John Mazzitelli wrote:
> I like this. I hate waiting for those archives to be built when I am just going to run straight out of target/hawkular-1.x.x.x/.. directory.
>
> I think its fine leaving -Pdozip - in case we want to package up our dev build and send to someone to try for whatever reason.
>
> ----- Original Message -----
>> Hello there,
>>    there is a PR hanging https://github.com/hawkular/hawkular/pull/342
>>
>> that will change the way the -Pdev profile works. Currently, it creates the
>> zip and gz archive, but most of us don't use it during the development. The
>> directory is pretty much ok. So it won't be created anymore, if you need the
>> zip/gz with precreated jdoe:password, use -Pdozip.
>>
>> I am sending this not to break anyones automated workflow. I asked Filip and
>> it seems QE don't depend on it.
>>
>> Perhaps the dozip profile can go away completely, then.
>>
>> jk
>> _______________________________________________
>> 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  Fri Jul 24 06:55:22 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 12:55:22 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
	<B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
	<198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>
Message-ID: <55B2199A.2010502@redhat.com>

Hi *,

we started a very similar effort in inventory couple of weeks ago. We 
have chosen the very same simple key1:value1,key2:value2 format for 
filtering URL parameters:
* We have a parser that supports escaping of the delimiters, see:
   http://git.io/vYWa5 and its tests http://git.io/vYWVt
* We have no support for OR, everything being ANDed implicitly.
* Also we have no support for operators other than equals, wildcard
   matching being the one most wanted by UI.

We see this as an initial step towards a more flexible query syntax with 
(), AND, OR (and perhaps also NOT), and several common comparison operators.

We have not investigated about any ready-to-use generic solution, but a 
quick googling shows RSQL https://github.com/jirutka/rsql-parser (MIT 
License) as quite a promising match for our needs. Anybody else happens 
to know something suitable?

Thanks,

Peter

On 2015-07-23 14:09, Michael Burman wrote:
> Hi,
>
> Right, the PR HWKMETRICS-180 currently implements the following query language (as inspired by OpenTSDB/Prometheus):
>
> tags=tagName:tagValue,tagName2,tagValue2 etc like previously in the REST-API query, splitted at the ",". All of these given names and values are considered as "AND", so it is read like:
>
> tagName:tagValue AND tagName2:tagValue2 (both must match)
>
> There are some identifiers which allow modifications to the query, namely at this point:
>
> "*" as the value and "|" in the value:
>
> tagName:*,tagName2:tagValue2|tagValue3
>
> That one would be read as:
>
> tagName:ANY AND (tagName2:tagValue2 OR tagName2:tagValue3)
>
> ANY means that the tag must exists for the metric definition, but the value can be anything. The query against metrics_tags_idx is done with values for these OR operations and exact matches, and against only the clustering column tname in case of "*" query. Now, one feature that both of those systems mentioned earlier do also is regexp-querying, the Prometheus syntax for that would be:
>
> tagName:~regexpValue
>
> The implementation for that one is relatively simple, we discard the tvalue fetching and just get those values as with tagName and then apply the given regexp filtering. However, what sort of features do we want from this query language and how should this query language look like? At the moment it was designed to be useable from the REST-API (and to mimick those two systems as some might be familiar with them already).
>
>    - Micke
>
> PS. The IRC nickname is "Yak", but someone registered on Freenode so I can't use it there unlike in every other major IRC-network. So I'm using a name of one of my pre-historic bots there.
>
> ----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, July 22, 2015 5:38:28 PM
> Subject: Re: [Hawkular-dev] [Metrics] Unified query support brainstorming
>
>
>> On Jul 22, 2015, at 10:13 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>
>> Hi everyone,
>>
>> Right now, when you query data in Metrics, you can, given a time range:
>> - get raw data
>> - get raw data having some tags
>> - get a "bucketed" view of raw data with on-the fly aggregates
>> - get periods for which a condition on the value holds true
>>
>> But you can't mix these capabilities.
>>
>> For example, you can't ask for periods where the avg of a gauge,
>> computed over 1 min buckets, is greater than a threshold.
>>
>> It's not possible either to express AND/OR in tags or condition queries.
>
> gayak has already added support for OR and is working on support for AND in HWKMETRICS-180. He is also looking into a mini query language for tag filtering as part of this work.
>
>>
>> Searching by tags is useful, but users have to tag data manually (unless
>> the collector adds some predefined tags). It would be useful to be able
>> to operate on data coming from different metrics having similar names:
>> like tell me the average cpu usage over all my web hosts, provided the
>> metrics are _webhost*.cpu.usage_
>
> We added support for tagging data very early on in the project, but I am becoming more of the mindset that we do not want this. Tagging metrics/time series and subsequently searching for metric data data based on those tags are common use cases. It might be worth thinking about events in place of tagging individual data points.
>
>>
>> When aggregating data, users should able to provide the name of the
>> function, be it a builtin or user defined function.
>
> I think user defined functions sound nice but not that critical. I think that we can cover most use cases with built-in functions.
>
>>
>> Last but not least, when rollups will be implemented, users should
>> probably not have to care about where the data is stored,if they ask for
>> the 1-month average of a metric over the past year, or the 30-seconds
>> average over the past five minutes (think about the UI zooming graphs).
>
> Agreed. The fact that we might be generating and storing multiple time series for a metric is in large part an implementation detail to make querying more efficient and to reduce storage footprint on disk. In RHQ we never exposed the generated time series. The date range in request determined which time series we queried.
>
> Whether we generate aggregated metrics in an ad hoc fashion at query time or they are pre-computed, we are still dealing with the same data types/structures. There should not be two separate APIs.
>
>>
>> The examples are not completely fabricated, it's feedback I got while
>> presenting Hawkular. I understood Stefan heard similar comments during
>> Summit.
>>
>> I'm starting this thread to gather inputs so that we can build a
>> powerful, unified query API. Feel free to provide more use cases and/or
>> ideas for implementation.
>>
>> Thanks!
>> 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 hrupp at redhat.com  Fri Jul 24 07:29:35 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 24 Jul 2015 13:29:35 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <55B2199A.2010502@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
	<B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
	<198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>
	<55B2199A.2010502@redhat.com>
Message-ID: <9FE932C5-9DD1-4CDB-B6B6-B103A7042139@redhat.com>

On 24 Jul 2015, at 12:55, Peter Palaga wrote:

> quick googling shows RSQL https://github.com/jirutka/rsql-parser (MIT
> License) as quite a promising match for our needs. Anybody else 

I started an email about this, but yours made me cancel it :)
The above - be it RSQL or any other - is what I would propose
too. Filtering by tags is clearly cool, but only a first step.
We certainly would need some more free form language that also
allows to find metrics that are e.g. above a certain value (both
finding the name of such a metric, and finding time ranges in
a given (set of) metrics that match the constraint should work.

Having a query language that follows some already known
syntax/semantic will be a plus in adoption. I also believe
that explicitly writing 'and' and 'or' instead of ';' and ':' will
help users similar for comparators as in

name=="Kill Bill" and year>2003
as opposed to 
name=="Kill Bill";year=gt=2003

I wonder though if being even "more SQL-like" would even be
better for the adoption.

 Heiko

From tsegismo at redhat.com  Fri Jul 24 08:41:39 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 24 Jul 2015 14:41:39 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <55B2199A.2010502@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
	<B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
	<198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>
	<55B2199A.2010502@redhat.com>
Message-ID: <55B23283.6060104@redhat.com>

Good one, it certainly makes sense to use similar patterns across 
components.

Le 24/07/2015 12:55, Peter Palaga a ?crit :
> Hi *,
>
> we started a very similar effort in inventory couple of weeks ago. We
> have chosen the very same simple key1:value1,key2:value2 format for
> filtering URL parameters:
> * We have a parser that supports escaping of the delimiters, see:
>     http://git.io/vYWa5 and its tests http://git.io/vYWVt
> * We have no support for OR, everything being ANDed implicitly.
> * Also we have no support for operators other than equals, wildcard
>     matching being the one most wanted by UI.
>
> We see this as an initial step towards a more flexible query syntax with
> (), AND, OR (and perhaps also NOT), and several common comparison operators.
>
> We have not investigated about any ready-to-use generic solution, but a
> quick googling shows RSQL https://github.com/jirutka/rsql-parser (MIT
> License) as quite a promising match for our needs. Anybody else happens
> to know something suitable?
>
> Thanks,
>
> Peter
>
> On 2015-07-23 14:09, Michael Burman wrote:
>> Hi,
>>
>> Right, the PR HWKMETRICS-180 currently implements the following query language (as inspired by OpenTSDB/Prometheus):
>>
>> tags=tagName:tagValue,tagName2,tagValue2 etc like previously in the REST-API query, splitted at the ",". All of these given names and values are considered as "AND", so it is read like:
>>
>> tagName:tagValue AND tagName2:tagValue2 (both must match)
>>
>> There are some identifiers which allow modifications to the query, namely at this point:
>>
>> "*" as the value and "|" in the value:
>>
>> tagName:*,tagName2:tagValue2|tagValue3
>>
>> That one would be read as:
>>
>> tagName:ANY AND (tagName2:tagValue2 OR tagName2:tagValue3)
>>
>> ANY means that the tag must exists for the metric definition, but the value can be anything. The query against metrics_tags_idx is done with values for these OR operations and exact matches, and against only the clustering column tname in case of "*" query. Now, one feature that both of those systems mentioned earlier do also is regexp-querying, the Prometheus syntax for that would be:
>>
>> tagName:~regexpValue
>>
>> The implementation for that one is relatively simple, we discard the tvalue fetching and just get those values as with tagName and then apply the given regexp filtering. However, what sort of features do we want from this query language and how should this query language look like? At the moment it was designed to be useable from the REST-API (and to mimick those two systems as some might be familiar with them already).
>>
>>     - Micke
>>
>> PS. The IRC nickname is "Yak", but someone registered on Freenode so I can't use it there unlike in every other major IRC-network. So I'm using a name of one of my pre-historic bots there.
>>
>> ----- Original Message -----
>> From: "John Sanda" <jsanda at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Wednesday, July 22, 2015 5:38:28 PM
>> Subject: Re: [Hawkular-dev] [Metrics] Unified query support brainstorming
>>
>>
>>> On Jul 22, 2015, at 10:13 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
>>>
>>> Hi everyone,
>>>
>>> Right now, when you query data in Metrics, you can, given a time range:
>>> - get raw data
>>> - get raw data having some tags
>>> - get a "bucketed" view of raw data with on-the fly aggregates
>>> - get periods for which a condition on the value holds true
>>>
>>> But you can't mix these capabilities.
>>>
>>> For example, you can't ask for periods where the avg of a gauge,
>>> computed over 1 min buckets, is greater than a threshold.
>>>
>>> It's not possible either to express AND/OR in tags or condition queries.
>>
>> gayak has already added support for OR and is working on support for AND in HWKMETRICS-180. He is also looking into a mini query language for tag filtering as part of this work.
>>
>>>
>>> Searching by tags is useful, but users have to tag data manually (unless
>>> the collector adds some predefined tags). It would be useful to be able
>>> to operate on data coming from different metrics having similar names:
>>> like tell me the average cpu usage over all my web hosts, provided the
>>> metrics are _webhost*.cpu.usage_
>>
>> We added support for tagging data very early on in the project, but I am becoming more of the mindset that we do not want this. Tagging metrics/time series and subsequently searching for metric data data based on those tags are common use cases. It might be worth thinking about events in place of tagging individual data points.
>>
>>>
>>> When aggregating data, users should able to provide the name of the
>>> function, be it a builtin or user defined function.
>>
>> I think user defined functions sound nice but not that critical. I think that we can cover most use cases with built-in functions.
>>
>>>
>>> Last but not least, when rollups will be implemented, users should
>>> probably not have to care about where the data is stored,if they ask for
>>> the 1-month average of a metric over the past year, or the 30-seconds
>>> average over the past five minutes (think about the UI zooming graphs).
>>
>> Agreed. The fact that we might be generating and storing multiple time series for a metric is in large part an implementation detail to make querying more efficient and to reduce storage footprint on disk. In RHQ we never exposed the generated time series. The date range in request determined which time series we queried.
>>
>> Whether we generate aggregated metrics in an ad hoc fashion at query time or they are pre-computed, we are still dealing with the same data types/structures. There should not be two separate APIs.
>>
>>>
>>> The examples are not completely fabricated, it's feedback I got while
>>> presenting Hawkular. I understood Stefan heard similar comments during
>>> Summit.
>>>
>>> I'm starting this thread to gather inputs so that we can build a
>>> powerful, unified query API. Feel free to provide more use cases and/or
>>> ideas for implementation.
>>>
>>> Thanks!
>>> 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  Fri Jul 24 09:19:09 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 15:19:09 +0200
Subject: [Hawkular-dev] Release cadence
In-Reply-To: <55AE9D76.5030908@redhat.com>
References: <6089CEE7-0223-4BAB-A0A9-594518D296AE@redhat.com>
	<40496335.1271157.1437486636728.JavaMail.zimbra@redhat.com>
	<2010022920.1561404.1437487587243.JavaMail.zimbra@redhat.com>
	<1923046.IANzvUWbUr@localhost.localdomain>
	<55AE9D76.5030908@redhat.com>
Message-ID: <55B23B4D.1060301@redhat.com>

Hi *,

I second those ones saying that imposing weekly releases on components 
is not necessary, as far as

(1) the given component's team not only plans in advance which component 
features will reach which HK milestone, but also

(2) component's team should have a clear idea who takes care for the 
integration into the consuming components (aka downstream) and how much 
time is needed for that.

The approach taken in Inventory is that the team creates (and announces) 
dev/ prefixed integration branches in downstream (HK main, Agent) ASAP 
after there appears a change in Inventory that requires some integration 
work. Initially, the integration branches depend on Inventory SNAPSHOTs. 
The release of Inventory is usually performed just after the integration 
work has been finished in downstream integration branches. With release 
of Inventory, the integration branches are ready to be merged to master 
- but this holds only from Inventory's PoV, because usually, Agent's 
integration branch is waiting for a Metrics release that is not easy to get.

Most of components probably do it roughly like this and my impression is 
that Metrics do not. Metrics have their own rigid schedule that does not 
care for its downstream. Dear Metrics fellow developers, please, not 
only plan your release dates with an eye on your downstream, but also 
take care that for every change that needs integration, there is 
somebody who feels responsible for its integration. The success of 
Hawkular is our common goal.

Thanks,

Peter


On 2015-07-21 21:28, Jay Shaughnessy wrote:
>
> OK, so I think everyone has valid points and mostly I agree with Lukas,
> our issues are mainly the result of many quickly-iterating moving
> parts.  But we do have room to improve.  We need to remember that the
> reason we are running with all of these components is so that Hawkular
> master can be releasable both at any-time (stability) and at scheduled
> dates meeting certain feature goals (progress). With that in mind it's
> quite important for the [component] developers to have a clear picture
> or what is needed from them for the next Hawkular feature release.
> Given that knowledge the component should have a release available as
> far in advance as possible with the needed feature support.  As Lukas
> mentions, 2 weeks is a very good goal.  It could be that a Hawkular
> release doesn't even require a new component release.  Releasing
> daily/weekly/etc really doesn't make much difference, I think, instead
> it is important that there is a release early enough in the Hawkular
> release cycle that supports the next release of Hawkular. This then sets
> us up to quickly respond with a follow-up release to address issues or
> things we missed.  The components must strive to be out in front of the
> console.
>
> As for Mazz's suggestion of a dev/latest branch for each component. I'm
> not convinced that that is necessary.  I think a component's master
> branch should be free to have commits towards their next release.  And
> note, they should be ready to release a new feature release at any
> time.  And that means no snapshot dependencies.   So, if your component
> is currently dependent on a snapshot of another component, you will
> obviously need to be working in an integration branch.  This is when
> Heiko's release-often approach is most critical.  If someone is
> depending on your snapshot I think your highest priority should then be
> to release to get them off of that dependency.  And consumers, help them
> do that as well.  This is the coin-flip exercise.
>
> As for Versioning, we're getting closer to a standard but I think we
> could maybe do a little better.  My take on the recent discussions is
> this.  We know we can't release with snapshot dependencies so, as
> described above, we need to minimize the windows that a snapshot dep is
> in use by a consuming component.   We are all using Major.Minor.Micro
> versioning. That is good.  And most of us are following the RH guideline
> of the suffix, like ".Final".  We are, I think, all using the following
> guidelines:
>
>   * Breaking change releases minimally require a Minor version increment
>   * Backward compatible minimally require a Micro version increment
>   * Pure fix/patch releases should only increment the Micro version.
>
> I would further suggest that all releases at this time use the ".Final"
> suffix.  Using ".AlphaX" does nothing more than create controversy.  It
> has no meaning wrt quality or usability at this point in time.   Anytime
> a feature or fix release goes out, the Major.Minor.Micro version change
> should be sufficient.  Release often [enough], increment the version and
> tack on ".Final".  No "Alpha", no "Snapshot", no timed "Snapshot".
>
> I think we should take to heart Heiko's intentions and release often.
> But I hope we can avoid fabricated release schedules for the components
> and instead have us focus on releasing based on the overall needs of
> Hawkular (2 weeks early!) and consuming components (kill snapshot deps
> ASAP!).
>
>
> On 7/21/2015 2:03 PM, Lukas Krejci wrote:
>> git-flow?
>>
>> On Tuesday, July 21, 2015 10:06:27 John Mazzitelli wrote:
>>> Each repo needs to have a "dev/latest" branch. Should the component need
>>> them, the pom.xml files in those dev/latest branches can refer to the
>>> latest-n-greatest snapshot versions of components (we can have travis
>>> publish the snapshot builds from these dev/latest branches). Therefore, if
>>> you want the latest-n-greatest to test integration, switch to dev/latest
>>> branches and build them locally.
>>>
>>> If you want a released version that never changes go to the master branch
>>> (which is the latest release) or go to one of the release tags and build
>>> from that.
>>>
>>> Once we are getting ready to prepare for a release, we create PRs to merge
>>> dev/latest to master, changing the poms to the release versions that are
>>> needed.
>>>
>>> How long between merging dev/latest to master and release? I dunno. If we do
>>> this right, we won't need a quick 1-week turnaround time. Every 2-weeks?
>>> 3-weeks? keep it a month? I don't know. Make something up. I vote every 17
>>> days - only because its just as arbitrary as any other time period we might
>>> pick :)
>>>
>>> ----- Original Message -----
>>>
>>>> Hello,
>>>>
>>>> There are two issues that get interlaced here and should not be. One is to
>>>> release individual components on a schedule, and second is making sure
>>>> that
>>>> all the components integrate nicely. Your proposal with "at least one
>>>> release per week" is trying to fix a fix of a fix of previous decision.
>>>> And
>>>> in this mix, the two concepts of release and integration get so
>>>> interlocked
>>>> that we cannot make heads and tail.
>>>>
>>>> Here is the progression of things:
>>>>
>>>> Problem 1: monolithic code is bad, we need to componentize everything.
>>>> Solution: create single purpose repositories, which resulted in about 20
>>>> repositories.
>>>>
>>>> Problem 2: how do we integrate all those components? Solution: create a
>>>> Hawkular repository that depends on all the other repositories.
>>>>
>>>> Problem 3: integrated project idea works, but how do we really really
>>>> integrate the code? Solution: publish changes in subcomponents as soon as
>>>> possible.
>>>>
>>>> Problem 4: publishing changes in components takes a long time, can we
>>>> expedite the process and get changes even faster to integrated project?
>>>> Solution: automate SNAPSHOT publication so you have freshly build binaries
>>>> on almost every change.
>>>>
>>>> Problem 5: We need consistent builds for the integrated project. Solution:
>>>> master branch in the integrated project only depends on released version
>>>> of
>>>> components, feature branches are short lived.
>>>>
>>>> Problem 6: It is almost impossible to align all the release of components
>>>> and give enough runaway for the integrated project to ingest all the
>>>> release subcomponets, especially since there inter-dependencies on the
>>>> sub-projects themselves. Solution: publish sub-components officially at
>>>> least once per week.
>>>>
>>>> Problem 7: There are major changes that are needed right-away in the
>>>> integrated project. Solution: officially publish components more often
>>>> than
>>>> once per week. Publish as soon as the features makes it in. In fact, let's
>>>> publish Alphas (Alphaxx) with every single change.
>>>>
>>>> Problem 8: Too many releases, it takes too much time to administer the
>>>> process of releasing. Solution: Automate the release dependency
>>>> management,
>>>> emulate the SNAPSHOT injection concept but with Alpha "moniker".
>>>>
>>>> Problem 9: It is a nightmare to maintain on which version to depend on the
>>>> integrate project or components that depend on other components. Solution:
>>>> ??
>>>>
>>>> Problem 10: It is almost impossible to trace back the code that code that
>>>> goes into the integrated project because there are so many Alphas.
>>>> Solution: ???
>>>>
>>>>
>>>> We are at level 5; from 6 forward I see them coming, just as I saw the
>>>> rest
>>>> of 5. At what point do we stop and say "wait a second! what we doing here?
>>>> can we simplify all this??" From my perspective, we are arbitrarily
>>>> setting
>>>> requirements just to complicate things. There is always a happy medium and
>>>> there is always ways to simplify. I would much rather think for 2 months
>>>> on
>>>> how to simplify things and do it once, then stack problems that make our
>>>> lives harder for no reason.
>>>>
>>>>
>>>> That being said, I am not against implementing your proposed solution in
>>>> Hawkular Metrics. But I see two possible paths. One, escalate and resolve
>>>> problems 6, and 7 at the same time with automation. That is primarily
>>>> because we are so thin on resources and so stretched that we do not have
>>>> time to not automate this. Two, get a release engineer (or another
>>>> engineer) allocated to the team that will take care of these releases. If
>>>> we are to proceed with your current proposal please let us know which one
>>>> of these paths do you want Hawkular Metrics to take.
>>>>
>>>>
>>>> At the same time, we can take the reversed path; rather than escalate
>>>> problems, remove them from that stack. Why not look to simplify
>>>> everything,
>>>> revert a few problems and try to improve our productivity. We can revert
>>>> to
>>>> the use of SNAPSHOTS. In what capacity? Let's find the path that gives us
>>>> the most benefits with the least amount of work.
>>>>
>>>>
>>>> Thank you,
>>>> Stefan
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Heiko W.Rupp"<hrupp at redhat.com>
>>>>> To: "Discussions around Hawkular development"
>>>>> <hawkular-dev at lists.jboss.org>
>>>>> Sent: Tuesday, July 21, 2015 4:38:58 AM
>>>>> Subject: [Hawkular-dev] Release cadence
>>>>>
>>>>> Hey
>>>>>
>>>>> I have observed that our current Hawkular cadence of 4 weeks
>>>>> with similar cadences of components makes us end up with
>>>>> long living integration branches and a larger rush near the
>>>>> end to integrate them, get them for the first time tested in CI
>>>>> and even for the first time tested in real world.
>>>>>
>>>>> In one of the last releases there was a changed implementation
>>>>> in one component, that basically turned out as a no-op and
>>>>> still returned a "200 OK" code, so clients thought everything is
>>>>> happy, but it was not. We found the issue (through ppl looking
>>>>> at the UI) and solved it, but it was in a rush.
>>>>>
>>>>> This certainly goes against all the ideas of "release early, release
>>>>> often", "cut small slices", "changes go into CI/CD and go live quickly".
>>>>> Remember the coin flipping ?
>>>>>
>>>>> Ideally we would always be able to integrate changes from
>>>>> components into Hawkular (main), but I understand that with the
>>>>> way maven and its release process to central works, it is also not
>>>>> ideal to release many versions per day.
>>>>>
>>>>> With all of the above in mind, I propose that we move to a
>>>>> "at least once per week" model, where we do a component release
>>>>> at least once per week(*), which then in the four week stream form
>>>>> a new Alpha release. The smaller releases do not need release notes,
>>>>> I don't care if we use the micro number or a .AlphaY designator on
>>>>> them, but they should be a release, that is not a (named) snapshot.
>>>>> This will allow us to still have less efforts to do releases, but
>>>>> keep being (more) agile and have earlier integrations and thus
>>>>> less long living integration branches.
>>>>>
>>>>> On top of that, we need to provide new and/or changed apis(**)
>>>>> early on in the 4 weeks cadence so that other components can
>>>>> already start calling them, even if they are not yet functionally
>>>>> complete.
>>>>>
>>>>> *) Of course only if a change to the component has been made.
>>>>> **) Ideally with changed apis, we keep the old version around for
>>>>>
>>>>>    a bit and offer the new version on top. Remember, that especially
>>>>>    with non-compiletime bindings, we can not know which client is
>>>>>    at what api version.
>>>>>
>>>>> _______________________________________________
>>>>> 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 tsegismo at redhat.com  Fri Jul 24 08:37:22 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 24 Jul 2015 14:37:22 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <55AFA4FA.7080306@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
Message-ID: <55B23182.1050500@redhat.com>

Many thanks to those who replied already - or will do :)

I'm off next week but keep the discussions going. In the following weeks 
I'll write up the ideas in a doc and schedule a meeting to present it.

Le 22/07/2015 16:13, Thomas Segismont a ?crit :
> Hi everyone,
>
> Right now, when you query data in Metrics, you can, given a time range:
> - get raw data
> - get raw data having some tags
> - get a "bucketed" view of raw data with on-the fly aggregates
> - get periods for which a condition on the value holds true
>
> But you can't mix these capabilities.
>
> For example, you can't ask for periods where the avg of a gauge,
> computed over 1 min buckets, is greater than a threshold.
>
> It's not possible either to express AND/OR in tags or condition queries.
>
> Searching by tags is useful, but users have to tag data manually (unless
> the collector adds some predefined tags). It would be useful to be able
> to operate on data coming from different metrics having similar names:
> like tell me the average cpu usage over all my web hosts, provided the
> metrics are _webhost*.cpu.usage_
>
> When aggregating data, users should able to provide the name of the
> function, be it a builtin or user defined function.
>
> Last but not least, when rollups will be implemented, users should
> probably not have to care about where the data is stored,if they ask for
> the 1-month average of a metric over the past year, or the 30-seconds
> average over the past five minutes (think about the UI zooming graphs).
>
> The examples are not completely fabricated, it's feedback I got while
> presenting Hawkular. I understood Stefan heard similar comments during
> Summit.
>
> I'm starting this thread to gather inputs so that we can build a
> powerful, unified query API. Feel free to provide more use cases and/or
> ideas for implementation.
>
> Thanks!
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Fri Jul 24 10:50:10 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 16:50:10 +0200
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <212574305.2291772.1437569518634.JavaMail.zimbra@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
	<2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
	<587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>
	<677783888.1359651.1437559517987.JavaMail.zimbra@redhat.com>
	<212574305.2291772.1437569518634.JavaMail.zimbra@redhat.com>
Message-ID: <55B250A2.10601@redhat.com>

I see that feed-comm is part of bus now, sharing the release cycle with 
it, although there is no interdependence between the two.
Hm... what is actually the argument against a new separate git repo for 
feed-comm?

-- P

On 2015-07-22 14:51, John Mazzitelli wrote:
> Yes, I am going to move it to bus. I think its a good place. Doing that now.
>
> ----- Original Message -----
>> Hi,
>>    thinking about it, it could probably even stay as it is, but it would
>>    require the "feed-comm" mvn module to have it's own release cycle
>>    independent on hawkular (not share the ${project.version} as it is right
>>    now). Also, I think, the feed-comm can't depend back on the root pom via
>>    <parent><relativePath>, then it should be possible to release the
>>    feed-comm independently of hawkular and break the 'dependency deadlock'.
>>
>> However, if we want our Travis to do all the mvn deploy fun, then this won't
>> work, so I am +1 on moving it to bus repo (or hawkular-commons, but to me it
>> logically fits more into the hawkular-bus because of the communication
>> nature and their release cycle will be more likely similar than the release
>> cycle of web socket mechanism + embedded C*)
>>
>> jk
>>
>>
>> ----- Original Message -----
>> | From: "John Mazzitelli" <mazz at redhat.com>
>> | To: "Discussions around Hawkular development"
>> | <hawkular-dev at lists.jboss.org>
>> | Sent: Wednesday, 22 July, 2015 12:59:44 AM
>> | Subject: Re: [Hawkular-dev] glue code - where does it go?
>> |
>> | hawkular-commons seems like a good place for glue code that is shared
>> | across
>> | hawkular components.
>> |
>> | I could put this stuff in hawkular-bus since it is "comm" related (though
>> | it
>> | is comm between clients and server, not just comm between server-side
>> | components)
>> |
>> | This will need to be solved - because I can't release the agent right now.
>> | Agent needs the feed-comm API which is in hawkular, but hawkular needs the
>> | agent before it can be released.
>> |
>> | So this:
>> |
>> | https://github.com/hawkular/hawkular/tree/integration-latest-of-everything/modules/feed-comm
>> |
>> | needs to be moved to some location other than the hawkular build.
>> |
>> |
>> | ----- Original Message -----
>> | > Hello,
>> | >
>> | > We have this repository that is now used only for the embedded Cassandra
>> | > distribution. Do you think it would a good place for this kind of comm
>> | > code?
>> | >
>> | >
>> | > https://github.com/hawkular/hawkular-commons
>> | >
>> | >
>> | > Thank you,
>> | > Stefan
>> | >
>> | > ----- Original Message -----
>> | > > From: "John Mazzitelli" <mazz at redhat.com>
>> | > > To: "Discussions around Hawkular development"
>> | > > <hawkular-dev at lists.jboss.org>
>> | > > Sent: Tuesday, July 21, 2015 11:42:06 AM
>> | > > Subject: [Hawkular-dev] glue code - where does it go?
>> | > >
>> | > > We have a fairly annoying problem with our current glue code location.
>> | > >
>> | > > Right now, we have the "glue code" that is known as "feed-comm" inside
>> | > > the
>> | > > hawkular repo - there is specifically the "feed-comm-api" artifact that
>> | > > contains some Java code that is required for use by Java-based feeds in
>> | > > order to talk to the server (also includes some JSON schemas for
>> | > > non-Java
>> | > > feeds to use).
>> | > >
>> | > > But since this is in hawkular repo, my agent needs a hawkular release
>> | > > in
>> | > > order to pull in the feed-comm-api artifact! Well, obviously, that's
>> | > > what
>> | > > we
>> | > > are moving toward for next week - a alpha hawkualr release. But until
>> | > > that
>> | > > happens, I can't release the agent.
>> | > >
>> | > > But, interestingly enough, because hawkular (kettle) contains the
>> | > > agent,
>> | > > hawkular can't be released until it has an agent release to pull in.
>> | > >
>> | > > Round and round we go.
>> | > >
>> | > > I really hate saying we need yet another repo, but how else can we get
>> | > > glue
>> | > > code that is common between server and feeds/agents that isn't
>> | > > dependent
>> | > > upon a hawkular release being made?
>> | > > _______________________________________________
>> | > > 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  Fri Jul 24 11:09:42 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 24 Jul 2015 11:09:42 -0400 (EDT)
Subject: [Hawkular-dev] glue code - where does it go?
In-Reply-To: <55B250A2.10601@redhat.com>
References: <1588252444.1659294.1437496926337.JavaMail.zimbra@redhat.com>
	<2005556970.1557814.1437514653462.JavaMail.zimbra@redhat.com>
	<587133551.1785423.1437519584471.JavaMail.zimbra@redhat.com>
	<677783888.1359651.1437559517987.JavaMail.zimbra@redhat.com>
	<212574305.2291772.1437569518634.JavaMail.zimbra@redhat.com>
	<55B250A2.10601@redhat.com>
Message-ID: <1428868718.4069215.1437750582063.JavaMail.zimbra@redhat.com>

> I see that feed-comm is part of bus now, sharing the release cycle with
> it, although there is no interdependence between the two.
> Hm... what is actually the argument against a new separate git repo for
> feed-comm?

There is no argument really. It could go in some new repo (but do we REALLY want yet ANOTHER repo to manage?), or it could go in that commons repo where only embedded C* stuff is now, or in the bus repo (since, as Jiri mentioned, it is comm-y related).

I put it in bus repo because a) its already there, b) was easy to put the new comm stuff, c) kinda made sense, d) didn't require we add yet another repo.

But it can go whereever we want - existing repo, new repo, whatever. So - back to my original question in this thread (see the subject line) - where does our glue code go? This is more than just "where should this new comm module go" - that's just one piece of glue code - we have and will have more.

From tsegismo at redhat.com  Fri Jul 24 11:20:52 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 24 Jul 2015 17:20:52 +0200
Subject: [Hawkular-dev] [Metrics] Unified query support brainstorming
In-Reply-To: <9FE932C5-9DD1-4CDB-B6B6-B103A7042139@redhat.com>
References: <55AFA4FA.7080306@redhat.com>
	<B15D63FE-5A2E-41D3-8434-3F2A7AB04704@redhat.com>
	<198054166.3436298.1437653387642.JavaMail.zimbra@redhat.com>
	<55B2199A.2010502@redhat.com>
	<9FE932C5-9DD1-4CDB-B6B6-B103A7042139@redhat.com>
Message-ID: <55B257D4.8000109@redhat.com>

Le 24/07/2015 13:29, Heiko W.Rupp a ?crit :
> I started an email about this, but yours made me cancel it:)

That's fun, because I wanted to talk about SQL-like at some point. So we 
owe nothing to each other :D

>
> I wonder though if being even "more SQL-like" would even be
> better for the adoption.

A SQL like language could solve the "unified" problem. We could use 
different statements to retrieve different kind of results, but still 
offer a single method in the core API or a single HTTP endpoint.

From jshaughn at redhat.com  Fri Jul 24 11:44:11 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 24 Jul 2015 11:44:11 -0400
Subject: [Hawkular-dev] Availability revisited
In-Reply-To: <37F21922-7006-441F-8692-03E134F63164@redhat.com>
References: <DAC0FEB4-505D-4A4E-B9C6-F948338688FD@redhat.com>
	<9600E62C-2A6A-40BE-AA45-111CE546BE1F@redhat.com>
	<B3BF799F-9E56-4A76-BA28-FA8BF0AD3DC4@redhat.com>
	<37F21922-7006-441F-8692-03E134F63164@redhat.com>
Message-ID: <55B25D4B.1090101@redhat.com>


_Part 1) Avail Storage_
There are issues no matter which way we go.  Keeping current-avail 
in-memory means having a global, distributed cache that in a worst case 
would have an entry replicated for every resource on every server.  But, 
it would allow us to keep only a RLE avail in cassandra and a current 
avail could be accessed in memory.

We can avoid a global, distributed cache by keeping avail in cassandra.  
Possibly rooted in the schema suggested by John below. That combines a 
verbose non-RLE table and another table that can provide the current 
avail as well as the most recent avail change. We can then have a 
server-side aggregator to migrate data to RLE. John and I discussed some 
of the challenges and John has some ideas around how the aggregation 
could work.

Either approach will come with some challenges.  We give up some control 
with the ispn cache and potentially would need to migrate to a 
standalone cache in the future.  Although getting started with an 
embedded cache may save effort over additional coding for aggregation to 
RLE.

_Part 2) Avail Sub-State_
We currently have the basic Availability states of Up, Down, and 
Unknown.  We also have the notion of "Degraded" and possibly "Mixed" 
(for groups).   Additionally,  we have ideas around additional modifiers 
like Missing, Disabled, MaintenanceWindow and RestartRequired.  I say 
"modifiers" instead of "sub-states" because maybe multiple modifiers 
could be in effect at a given time.

Going back to Availability, I wonder if maybe we should a consider a 
numeric (integer) value for Availability.  This could integrate 
Degraded/Mixed into a single Availability value.  Perhaps -1=Uknown, 
0=Down, [1..9] =Degraded/Mixed, 10=Up.   We don't want too many values 
or the 'avail_state_change' table could end up with too many rows per 
resource.  If we don't want to quantify the value then I think we could 
probably live with Up, Down, Unknown, Mixed.  And then have everything 
else be a modifier.  If we want to limit to a single modifier it may 
make sense to have a large set of Avail values, e.g. Up, Up_Degraded, 
Down, Down_Missing, etc...

Otherwise, I guess the Modifiers could be a verbose, comma separated 
string value.  Or it could be a compact bit mask.   It doesn't strike me 
as a field that needs to be searched/filtered on at the db level, more 
likely could be used for client-side filtering.  The question that needs 
to be answered is whether it's important for a historical RLE view, or 
if its important only for the current state.  If looking at a RLE for a 
resource's avail, and you see a Down period last week, do we need to be 
able to drill down and say it was Down and Missing?  Or Up with 
RestartRequired?  Or is that relevant only for the current avail state.  
I honestly don't know (but if we have a verbose list of avail values 
it's easy).   My inclination is to say that histyorical RLE is not 
decorated with modifiers.  In that case I think only the  
'avail_state_change' table would need an additional, non-PK field for 
the modifiers.

I'll stop rambling now and see what people have to say...


On 7/22/2015 11:55 PM, John Sanda wrote:
>> On Jul 20, 2015, at 5:13 AM, Heiko W.Rupp<hrupp at redhat.com>  wrote:
>>
>> On 16 Jul 2015, at 3:45, John Sanda wrote:
>>> Are there any docs, notes, etc. on the feed-comm system? I am not
>>> familiar with this.
>> Mazz should have /will talk about it. But at the end this has only
>> little
>> to do with this topic, as any sort of availability should work with
>> "normal" REST-based-feeds too.
>>
>>> Why do we need to store the last seen availability in memory?
>> Because we can? :-)
>> Seriously: in RHQ we had huge issues with all the availability records
>> that were never cached, so everything working with "current
>> availability)
>> had to go to the database with its latencies and costs.
> It is premature to say that we need to cache availability while we have only implemented simple read/write operations without any extensive performance/stress testing. I am aware that we had issues with availability in RHQ, but we stored availability in the RDBMS. I think we should wait and see how a Cassandra based implementation looks, do some performance testing, and then make a more informed decision about whether or not caching is needed.
>
>> Availability is by nature something run-length encoded. Unlike
>> counter or gauge metrics.
>> We could of course store each incoming new availability record, so that
>> its (start) timestamp would reflect the last seen time, but querying for
>> "since when was it up" would result in a pretty heavy backtracking query
>> (with some luck we have a limit like "in the last hour/day", but what if
>> we want an absolute date or over the last year.
> The better we understand the queries we need to support, then we can better design the schema to optimize for those queries. Suppose we store availability as follows
>
> CREATE TABLE availability (
>      tenant text,
>      id text,
>      bucket timestamp,
>      time timestamp,
>      value text,    // stored here as text for simplicity
>      PRIMARY KEY ((tenant, id, bucket), time)
> ) WITH CLUSTERING ORDER BY (time DESC);
>
> The bucket column is for date partitioning to ensure partitions do not grow too large. If we do not collect availability more frequently than say every minute, we might be fine with using bucket sizes of 6 hrs, 12 hrs, or even 24 hrs.
>
> We will introduce an additional table to help us answer ?since when it was up?,
>
> CREATE TABLE avail_state_change (
>      tenant text,
>      avail_id text,
>      value text,
>      time timestamp,
>      PRIMARY KEY ((tenant, avail_id), value)
> );
>
> The schema will actually allow us to answer the more general question, ?the avail state was X since when.? The avail_state_change table will store at most one row for each recorded availability state for a particular resource. When availability is reported, we write to both tables. To answer our query we can execute the following queries in parallel,
>
> SELECT value, timestamp FROM availability WHERE tenant = ? AND id = ? and bucket = ? LIMIT 1;
>
> SELECT value, time FROM avail_state_change WHERE tenant_id = ? and avail_id = ?;
>
> If the value returned from the availability table query is UP, then we compare its timestamp against the timestamp of the DOWN row returned from the avail_state_change query.
>
> We need to play around with schema changes like this to see if it will satisfy query performance requirements. And then if it doesn?t, we should look at tweaking the key cache, and then look at the row cache, and then finally look at a separate caching tier.
>
> We can implement background aggregation jobs to store run-length encoded values that will allow to efficiently answer similar queries for the more distant past.
>
>> This is why I am thinking about keeping the RLE with start/stop/state,
>> but augmented by "last seen" for the in-memory version.
>>
>> Keeping last seen in memory prevents all the expensive backend-hits
>> (either getting the same value over and over again, or doing in-place
>> updates)
>> and still allows jobs to check if the last-seen is e.g. within the last
>> minute
>> and react accordingly (RHQ-term: "backfill?).
> Again, I think that the schema that I have described above allows us to handle this efficiently.
>
>>> If you talking about correlation, then I am +1. When I think about
>>> RHQ, the user could easily see availability state change, but he would
>>> have to go hunting around to see what precipitated it.
>> This is certainly another aspect of this "root cause analysis".
>>
>>    Heiko
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150724/9c57280f/attachment-0001.html 

From ppalaga at redhat.com  Fri Jul 24 12:37:11 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 18:37:11 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55AEA41D.5090008@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com>
Message-ID: <55B269B7.2010909@redhat.com>

Hi Thomas,

I was quite undecided about this change, but because it impacts all 
consumers of Hawkular Parent (and implies some work in all consumers) I 
hoped to hear about some specific module where the change is inevitable, 
because the current state is dysfunctional due to the import of WF BoM. 
You have not seem to have provided such one.

I am making my best to understand the background of your proposal. So to 
paraphrase your position, the WF BoM import in Parent is not causing 
anything bad directly, you just do not find it good that in non-WF 
related modules (ptrans, REST tests) one may easily overlook that one 
actually makes use of a version managed in WF BoM. When one is aware of 
the fact that the given artifact is managed in WF BoM and one does not 
want that, one is free to put one's own explicit version on the 
dependency and the problem is solved (at least at the physical class 
path level).

I agree that this "possibility to overlook" really exists, but I do not 
think it is harmful enough to remove the WF BoM import from our Parent 
BoM, mainly because the vast majority of our modules do target WF.

I agree that your proposal is in some sense cleaner, than what we have 
now, but I do not think it is worth of the effort.

To name a situation where removing the WF BoM import would make sense 
to me (Stefan asked about that): E.g. if we decided to target additional 
platforms that support APIs conflicting with those of WF.

I prefer not to adopt this proposal, but I am far from being strongly 
against it. Is there anybody else who wants to veto?

Thanks,

Peter


On 2015-07-21 21:57, Jay Shaughnessy wrote:
>
> I'm inclined to support Thomas's suggestion. Because we typically deploy
> to Wildfly I can understand why it was natural to suck the BOM up to
> parent.  But to give components some flexibility to control their own
> imports without having to override the parent or possibly add
> exclusions, it doesn't seem too bad to get the version of the BOM from
> the parent and then import at the component level.  And certainly it
> makes sense if the BOM is just not needed by the Hawkular component.
> Thomas has done the homework here.  If someone is is absolutely 100%
> against the change then we'll have to put it to a vote (or a flat out
> decision from above), but I suggest we make the change and move
> forward.  If we learn downstream that it was better the other way then
> I'm sure there will be enough groundswell to change it back.
>
> Although, I think we can wait until after the next Hawkular release and
> then a PR should be sent for all affected components that may need to
> add the BOM dependency.
>
>
> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
>> Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
>>> Too much snark in this thread.
>>>
>>> Is there a way that it can remain in the parent pom yet be
>>> overridden/excluded as desired/required by metrics?  Maven typically
>>> prefers the locally decl over an inherited decl.
>> The only way you can "ignore" a BOM import is to re-declare it in your
>> component parent POM with a scope != import. Works until Maven team
>> decides "type=pom" + "scope=<yourchoice>" means something.
>>
>> I was not inclined to do this given that the proper solution is easy to
>> implement.
>>
>> _______________________________________________
>> 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  Fri Jul 24 12:51:11 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Fri, 24 Jul 2015 12:51:11 -0400 (EDT)
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55B269B7.2010909@redhat.com>
References: <5588192F.3030906@redhat.com> <55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com> <55B269B7.2010909@redhat.com>
Message-ID: <1111207322.3298533.1437756671271.JavaMail.zimbra@redhat.com>

Hello Peter,

Hawkular Metrics needs this change as soon as possible (yesterday) since the project will have two REST implementations targeting two different containers/standards. Work already started so this change is late.


Thank you,
Stefan 

----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, July 24, 2015 11:37:11 AM
> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
> 
> Hi Thomas,
> 
> I was quite undecided about this change, but because it impacts all
> consumers of Hawkular Parent (and implies some work in all consumers) I
> hoped to hear about some specific module where the change is inevitable,
> because the current state is dysfunctional due to the import of WF BoM.
> You have not seem to have provided such one.
> 
> I am making my best to understand the background of your proposal. So to
> paraphrase your position, the WF BoM import in Parent is not causing
> anything bad directly, you just do not find it good that in non-WF
> related modules (ptrans, REST tests) one may easily overlook that one
> actually makes use of a version managed in WF BoM. When one is aware of
> the fact that the given artifact is managed in WF BoM and one does not
> want that, one is free to put one's own explicit version on the
> dependency and the problem is solved (at least at the physical class
> path level).
> 
> I agree that this "possibility to overlook" really exists, but I do not
> think it is harmful enough to remove the WF BoM import from our Parent
> BoM, mainly because the vast majority of our modules do target WF.
> 
> I agree that your proposal is in some sense cleaner, than what we have
> now, but I do not think it is worth of the effort.
> 
> To name a situation where removing the WF BoM import would make sense
> to me (Stefan asked about that): E.g. if we decided to target additional
> platforms that support APIs conflicting with those of WF.
> 
> I prefer not to adopt this proposal, but I am far from being strongly
> against it. Is there anybody else who wants to veto?
> 
> Thanks,
> 
> Peter
> 
> 
> On 2015-07-21 21:57, Jay Shaughnessy wrote:
> >
> > I'm inclined to support Thomas's suggestion. Because we typically deploy
> > to Wildfly I can understand why it was natural to suck the BOM up to
> > parent.  But to give components some flexibility to control their own
> > imports without having to override the parent or possibly add
> > exclusions, it doesn't seem too bad to get the version of the BOM from
> > the parent and then import at the component level.  And certainly it
> > makes sense if the BOM is just not needed by the Hawkular component.
> > Thomas has done the homework here.  If someone is is absolutely 100%
> > against the change then we'll have to put it to a vote (or a flat out
> > decision from above), but I suggest we make the change and move
> > forward.  If we learn downstream that it was better the other way then
> > I'm sure there will be enough groundswell to change it back.
> >
> > Although, I think we can wait until after the next Hawkular release and
> > then a PR should be sent for all affected components that may need to
> > add the BOM dependency.
> >
> >
> > On 7/21/2015 11:40 AM, Thomas Segismont wrote:
> >> Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
> >>> Too much snark in this thread.
> >>>
> >>> Is there a way that it can remain in the parent pom yet be
> >>> overridden/excluded as desired/required by metrics?  Maven typically
> >>> prefers the locally decl over an inherited decl.
> >> The only way you can "ignore" a BOM import is to re-declare it in your
> >> component parent POM with a scope != import. Works until Maven team
> >> decides "type=pom" + "scope=<yourchoice>" means something.
> >>
> >> I was not inclined to do this given that the proper solution is easy to
> >> implement.
> >>
> >> _______________________________________________
> >> 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  Fri Jul 24 12:57:45 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 24 Jul 2015 18:57:45 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <1111207322.3298533.1437756671271.JavaMail.zimbra@redhat.com>
References: <5588192F.3030906@redhat.com> <55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com> <55B269B7.2010909@redhat.com>
	<1111207322.3298533.1437756671271.JavaMail.zimbra@redhat.com>
Message-ID: <55B26E89.104@redhat.com>

Oh, why was that so complicated to hear a real reason :) Where can I see 
the code if I may ask? -- P

On 2015-07-24 18:51, Stefan Negrea wrote:
> Hello Peter,
>
> Hawkular Metrics needs this change as soon as possible (yesterday) since the project will have two REST implementations targeting two different containers/standards. Work already started so this change is late.
>
>
> Thank you,
> Stefan
>
> ----- Original Message -----
>> From: "Peter Palaga" <ppalaga at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Friday, July 24, 2015 11:37:11 AM
>> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
>>
>> Hi Thomas,
>>
>> I was quite undecided about this change, but because it impacts all
>> consumers of Hawkular Parent (and implies some work in all consumers) I
>> hoped to hear about some specific module where the change is inevitable,
>> because the current state is dysfunctional due to the import of WF BoM.
>> You have not seem to have provided such one.
>>
>> I am making my best to understand the background of your proposal. So to
>> paraphrase your position, the WF BoM import in Parent is not causing
>> anything bad directly, you just do not find it good that in non-WF
>> related modules (ptrans, REST tests) one may easily overlook that one
>> actually makes use of a version managed in WF BoM. When one is aware of
>> the fact that the given artifact is managed in WF BoM and one does not
>> want that, one is free to put one's own explicit version on the
>> dependency and the problem is solved (at least at the physical class
>> path level).
>>
>> I agree that this "possibility to overlook" really exists, but I do not
>> think it is harmful enough to remove the WF BoM import from our Parent
>> BoM, mainly because the vast majority of our modules do target WF.
>>
>> I agree that your proposal is in some sense cleaner, than what we have
>> now, but I do not think it is worth of the effort.
>>
>> To name a situation where removing the WF BoM import would make sense
>> to me (Stefan asked about that): E.g. if we decided to target additional
>> platforms that support APIs conflicting with those of WF.
>>
>> I prefer not to adopt this proposal, but I am far from being strongly
>> against it. Is there anybody else who wants to veto?
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On 2015-07-21 21:57, Jay Shaughnessy wrote:
>>>
>>> I'm inclined to support Thomas's suggestion. Because we typically deploy
>>> to Wildfly I can understand why it was natural to suck the BOM up to
>>> parent.  But to give components some flexibility to control their own
>>> imports without having to override the parent or possibly add
>>> exclusions, it doesn't seem too bad to get the version of the BOM from
>>> the parent and then import at the component level.  And certainly it
>>> makes sense if the BOM is just not needed by the Hawkular component.
>>> Thomas has done the homework here.  If someone is is absolutely 100%
>>> against the change then we'll have to put it to a vote (or a flat out
>>> decision from above), but I suggest we make the change and move
>>> forward.  If we learn downstream that it was better the other way then
>>> I'm sure there will be enough groundswell to change it back.
>>>
>>> Although, I think we can wait until after the next Hawkular release and
>>> then a PR should be sent for all affected components that may need to
>>> add the BOM dependency.
>>>
>>>
>>> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
>>>> Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
>>>>> Too much snark in this thread.
>>>>>
>>>>> Is there a way that it can remain in the parent pom yet be
>>>>> overridden/excluded as desired/required by metrics?  Maven typically
>>>>> prefers the locally decl over an inherited decl.
>>>> The only way you can "ignore" a BOM import is to re-declare it in your
>>>> component parent POM with a scope != import. Works until Maven team
>>>> decides "type=pom" + "scope=<yourchoice>" means something.
>>>>
>>>> I was not inclined to do this given that the proper solution is easy to
>>>> implement.
>>>>
>>>> _______________________________________________
>>>> 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 tsegismo at redhat.com  Fri Jul 24 12:59:50 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 24 Jul 2015 18:59:50 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55B269B7.2010909@redhat.com>
References: <5588192F.3030906@redhat.com> <55AD26D7.20202@redhat.com>
	<55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com> <55B269B7.2010909@redhat.com>
Message-ID: <55B26F06.3020205@redhat.com>

Le 24/07/2015 18:37, Peter Palaga a ?crit :
> I was quite undecided about this change, but because it impacts all
> consumers of Hawkular Parent (and implies some work in all consumers) I
> hoped to hear about some specific module where the change is inevitable,
> because the current state is dysfunctional due to the import of WF BoM.
> You have not seem to have provided such one.

I told you already where the forced scopes were harmful.

Note that we could have vetoed the upgrade to parent version 16 because 
applying it was breaking our build. See your PR, which I couldn't merge:
https://github.com/hawkular/hawkular-metrics/pull/260

But to keep things going, we've fixed the issue as we could, see my PR:
https://github.com/hawkular/hawkular-metrics/pull/268

I'll think about vetoing next time.

>
> I am making my best to understand the background of your proposal. So to
> paraphrase your position, the WF BoM import in Parent is not causing
> anything bad directly, you just do not find it good that in non-WF
> related modules (ptrans, REST tests) one may easily overlook that one
> actually makes use of a version managed in WF BoM. When one is aware of
> the fact that the given artifact is managed in WF BoM and one does not
> want that, one is free to put one's own explicit version on the
> dependency and the problem is solved (at least at the physical class
> path level).

Already answered that. My position is I don't want to do this again.

> I agree that your proposal is in some sense cleaner, than what we have
> now, but I do not think it is worth of the effort.

The effort is a few lines removed in the parent and re-added in the 
components where relevant. We should be able to manage.


> To name a situation where removing the WF BoM import would make sense
> to me (Stefan asked about that): E.g. if we decided to target additional
> platforms that support APIs conflicting with those of WF.

Yes we'll soon need to do this in Metrics, for an EAP6.4 deployment. 
Funny how the situation came up so quickly.

>
> I prefer not to adopt this proposal, but I am far from being strongly
> against it. Is there anybody else who wants to veto?

Read this sentence again. Then facepalm or ROFL.

From snegrea at redhat.com  Fri Jul 24 13:07:28 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Fri, 24 Jul 2015 13:07:28 -0400 (EDT)
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55B26E89.104@redhat.com>
References: <5588192F.3030906@redhat.com>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com> <55B269B7.2010909@redhat.com>
	<1111207322.3298533.1437756671271.JavaMail.zimbra@redhat.com>
	<55B26E89.104@redhat.com>
Message-ID: <1506673038.3307219.1437757648382.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, July 24, 2015 11:57:45 AM
> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
> 
> Oh, why was that so complicated to hear a real reason :) Where can I see
> the code if I may ask? -- P


This is a developing story but here is the relevant main JIRA ticket: https://issues.jboss.org/browse/HWKMETRICS-185


Thank you,
Stefan 

> 
> On 2015-07-24 18:51, Stefan Negrea wrote:
> > Hello Peter,
> >
> > Hawkular Metrics needs this change as soon as possible (yesterday) since
> > the project will have two REST implementations targeting two different
> > containers/standards. Work already started so this change is late.
> >
> >
> > Thank you,
> > Stefan
> >
> > ----- Original Message -----
> >> From: "Peter Palaga" <ppalaga at redhat.com>
> >> To: "Discussions around Hawkular development"
> >> <hawkular-dev at lists.jboss.org>
> >> Sent: Friday, July 24, 2015 11:37:11 AM
> >> Subject: Re: [Hawkular-dev] Parent POM and Wildfly BOM
> >>
> >> Hi Thomas,
> >>
> >> I was quite undecided about this change, but because it impacts all
> >> consumers of Hawkular Parent (and implies some work in all consumers) I
> >> hoped to hear about some specific module where the change is inevitable,
> >> because the current state is dysfunctional due to the import of WF BoM.
> >> You have not seem to have provided such one.
> >>
> >> I am making my best to understand the background of your proposal. So to
> >> paraphrase your position, the WF BoM import in Parent is not causing
> >> anything bad directly, you just do not find it good that in non-WF
> >> related modules (ptrans, REST tests) one may easily overlook that one
> >> actually makes use of a version managed in WF BoM. When one is aware of
> >> the fact that the given artifact is managed in WF BoM and one does not
> >> want that, one is free to put one's own explicit version on the
> >> dependency and the problem is solved (at least at the physical class
> >> path level).
> >>
> >> I agree that this "possibility to overlook" really exists, but I do not
> >> think it is harmful enough to remove the WF BoM import from our Parent
> >> BoM, mainly because the vast majority of our modules do target WF.
> >>
> >> I agree that your proposal is in some sense cleaner, than what we have
> >> now, but I do not think it is worth of the effort.
> >>
> >> To name a situation where removing the WF BoM import would make sense
> >> to me (Stefan asked about that): E.g. if we decided to target additional
> >> platforms that support APIs conflicting with those of WF.
> >>
> >> I prefer not to adopt this proposal, but I am far from being strongly
> >> against it. Is there anybody else who wants to veto?
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >>
> >> On 2015-07-21 21:57, Jay Shaughnessy wrote:
> >>>
> >>> I'm inclined to support Thomas's suggestion. Because we typically deploy
> >>> to Wildfly I can understand why it was natural to suck the BOM up to
> >>> parent.  But to give components some flexibility to control their own
> >>> imports without having to override the parent or possibly add
> >>> exclusions, it doesn't seem too bad to get the version of the BOM from
> >>> the parent and then import at the component level.  And certainly it
> >>> makes sense if the BOM is just not needed by the Hawkular component.
> >>> Thomas has done the homework here.  If someone is is absolutely 100%
> >>> against the change then we'll have to put it to a vote (or a flat out
> >>> decision from above), but I suggest we make the change and move
> >>> forward.  If we learn downstream that it was better the other way then
> >>> I'm sure there will be enough groundswell to change it back.
> >>>
> >>> Although, I think we can wait until after the next Hawkular release and
> >>> then a PR should be sent for all affected components that may need to
> >>> add the BOM dependency.
> >>>
> >>>
> >>> On 7/21/2015 11:40 AM, Thomas Segismont wrote:
> >>>> Le 21/07/2015 15:12, Jay Shaughnessy a ?crit :
> >>>>> Too much snark in this thread.
> >>>>>
> >>>>> Is there a way that it can remain in the parent pom yet be
> >>>>> overridden/excluded as desired/required by metrics?  Maven typically
> >>>>> prefers the locally decl over an inherited decl.
> >>>> The only way you can "ignore" a BOM import is to re-declare it in your
> >>>> component parent POM with a scope != import. Works until Maven team
> >>>> decides "type=pom" + "scope=<yourchoice>" means something.
> >>>>
> >>>> I was not inclined to do this given that the proper solution is easy to
> >>>> implement.
> >>>>
> >>>> _______________________________________________
> >>>> 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 tsegismo at redhat.com  Fri Jul 24 13:11:50 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 24 Jul 2015 19:11:50 +0200
Subject: [Hawkular-dev] Parent POM and Wildfly BOM
In-Reply-To: <55B26E89.104@redhat.com>
References: <5588192F.3030906@redhat.com> <55ADE835.8090903@redhat.com>
	<1972038.7lySs3RSGz@localhost.localdomain>
	<D9DCF3BE-F0DB-441C-A101-EFD5887A543D@redhat.com>
	<55AE4537.8090000@redhat.com> <55AE67EF.7080006@redhat.com>
	<55AEA41D.5090008@redhat.com> <55B269B7.2010909@redhat.com>
	<1111207322.3298533.1437756671271.JavaMail.zimbra@redhat.com>
	<55B26E89.104@redhat.com>
Message-ID: <55B271D6.4030306@redhat.com>

Le 24/07/2015 18:57, Peter Palaga a ?crit :
> Oh, why was that so complicated to hear a real reason

Yes, it looks awfully complicated to be heard, not to be said. From a 
previous reply:
===
100% of components have at least one module to be deployed in Hawkular. 
But then there are modules meant to run out of Hawkular
===

From mazz at redhat.com  Fri Jul 24 16:45:12 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 24 Jul 2015 16:45:12 -0400 (EDT)
Subject: [Hawkular-dev] execute op
In-Reply-To: <957562321.4263856.1437770185630.JavaMail.zimbra@redhat.com>
Message-ID: <2088007378.4264881.1437770712807.JavaMail.zimbra@redhat.com>

As part of the new UI-server-feed comm work, the following now works.

In our agent config, if a resource-type has an operation defined, you can execute that operation from end-to-end. I don't have the UI coded up - I mock out the UI with a simulated websocket client.

These are the log messages I got in the logs to show it working:

1) The UI sends in the request over websocket - the content of the request looks like this:

    ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor", "operationName":"Status"}

2) The server receives it over the websocket. Log message:

   Received message from UI client [AjEP4Q3X0ViCalHvAsodkve92mshxsCxJTy9PQ9r]

3) And then puts it on the bus. Whatever server is currently connected to that feed will have a bus listener for this particular command for that particular feed and picks it up. Log message from the bus listener:

   Asking feed [mazztower] to execute operation [Status] on resource ID [mazztower~Local~/subsystem=hawkular-monitor]

4) That bus listener does what it needs to do - in this case, forwards the message to the appropriate feed/agent. Log message:

    Attempting to send async message to [1] clients: [ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor","operationName":"Status"}]

5) The agent gets the message from its websocket. Log messages:

    Received message from server
    Received request to execute operation [Status] on resource [mazztower~Local~/subsystem=hawkular-monitor]

6) Once the operation is executed, the results are sent back to the server - these are logs back on the server again:

    Received message from feed [mazztower]
    Operation execution completed. Resource=[mazztower~Local~/subsystem=hawkular-monitor], Operation=[Status], Status=[OK], Message=["STOPPED"]

So you can see the server was told that the operation succeeded and what the results were in Message.

Lots more to do. But the end-to-end is working. Need to support parameters, next. Then have to figure out how to do resource configuration using this same comm mechanism.

From ppalaga at redhat.com  Mon Jul 27 04:59:27 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 27 Jul 2015 10:59:27 +0200
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have to
 be a WARN with a stack trace?
Message-ID: <55B5F2EF.1070903@redhat.com>

Hi *,

There are several occurrences of this in every Hawkular start log:

WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle] 
(metricsservice-lifecycle-thread) Could not connect to Cassandra cluster 
- assuming its not up yet: 
com.datastax.driver.core.exceptions.NoHostAvailableException: All 
host(s) tried for query failed (tried: /127.0.0.1:9042 
(com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot 
connect))

plus the stack trace.

So given that this happens during every HK startup, could we not 
classify it as normal and change it to INFO without the stack trace?

I am ready to prepare a PR unless somebody raises a hand against that.

Thanks,

Peter

From gbrown at redhat.com  Mon Jul 27 05:03:31 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 27 Jul 2015 05:03:31 -0400 (EDT)
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <55B5F2EF.1070903@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
Message-ID: <1774527890.227009.1437987811366.JavaMail.zimbra@redhat.com>

Could it be changed to generate INFO until the first connection is made, and after that if the same issue occurs, then raise a WARN?

Regards
Gary

----- Original Message -----
> Hi *,
> 
> There are several occurrences of this in every Hawkular start log:
> 
> WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle]
> (metricsservice-lifecycle-thread) Could not connect to Cassandra cluster
> - assuming its not up yet:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All
> host(s) tried for query failed (tried: /127.0.0.1:9042
> (com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot
> connect))
> 
> plus the stack trace.
> 
> So given that this happens during every HK startup, could we not
> classify it as normal and change it to INFO without the stack trace?
> 
> I am ready to prepare a PR unless somebody raises a hand against that.
> 
> Thanks,
> 
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From miburman at redhat.com  Mon Jul 27 05:11:05 2015
From: miburman at redhat.com (Michael Burman)
Date: Mon, 27 Jul 2015 05:11:05 -0400 (EDT)
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <55B5F2EF.1070903@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
Message-ID: <259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>

Hi,

And how would you distinguish between real warning and incorrect one? This message is not printed when Hawkular-Metrics starts standalone andshould not be removed. This is a container issue in Hawkular and should be fixed there (so that no such error happens) instead of breaking the logging in metrics. Most likely this happens with embedded-cassandra I guess? 

  - Micke

----- Original Message -----
From: "Peter Palaga" <ppalaga at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Monday, July 27, 2015 11:59:27 AM
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have to be a WARN with a stack trace?

Hi *,

There are several occurrences of this in every Hawkular start log:

WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle] 
(metricsservice-lifecycle-thread) Could not connect to Cassandra cluster 
- assuming its not up yet: 
com.datastax.driver.core.exceptions.NoHostAvailableException: All 
host(s) tried for query failed (tried: /127.0.0.1:9042 
(com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot 
connect))

plus the stack trace.

So given that this happens during every HK startup, could we not 
classify it as normal and change it to INFO without the stack trace?

I am ready to prepare a PR unless somebody raises a hand against that.

Thanks,

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

From theute at redhat.com  Mon Jul 27 05:42:04 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 27 Jul 2015 11:42:04 +0200
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
	<259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
Message-ID: <55B5FCEC.70705@redhat.com>

Glad I am not the only one that finds those messages annoying :)

Indeed, this is an Hawkular issue with embedded Cassandra.
We should fix it by properly defining the startup dependencies, we may also think of keeping "embedded Cassandra" as a separate process.

The idea of "embedding Cassandra" is that we don't need to ask users to go download it, "install it" and run it.
But we could consider having a Cassandra in a different process (configured for our needs such as the data location, port and other settings) that is required to be started prior to run Hawkular (Hawkular would need to fail quickly and clearly if the user "forgot" to start Cassandra).

PS: I am not advocating for one or the other solution as I don't know the advantages/drawbacks of both solutions

Thomas





On 07/27/2015 11:11 AM, Michael Burman wrote:
> Hi,
>
> And how would you distinguish between real warning and incorrect one? This message is not printed when Hawkular-Metrics starts standalone andshould not be removed. This is a container issue in Hawkular and should be fixed there (so that no such error happens) instead of breaking the logging in metrics. Most likely this happens with embedded-cassandra I guess?
>
>    - Micke
>
> ----- Original Message -----
> From: "Peter Palaga" <ppalaga at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, July 27, 2015 11:59:27 AM
> Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have to be a WARN with a stack trace?
>
> Hi *,
>
> There are several occurrences of this in every Hawkular start log:
>
> WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle]
> (metricsservice-lifecycle-thread) Could not connect to Cassandra cluster
> - assuming its not up yet:
> com.datastax.driver.core.exceptions.NoHostAvailableException: All
> host(s) tried for query failed (tried: /127.0.0.1:9042
> (com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot
> connect))
>
> plus the stack trace.
>
> So given that this happens during every HK startup, could we not
> classify it as normal and change it to INFO without the stack trace?
>
> I am ready to prepare a PR unless somebody raises a hand against that.
>
> Thanks,
>
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From hrupp at redhat.com  Mon Jul 27 05:53:55 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 27 Jul 2015 11:53:55 +0200
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <55B5FCEC.70705@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
	<259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
	<55B5FCEC.70705@redhat.com>
Message-ID: <C6FA33C9-4122-44DE-A0E9-B10580DEA9B8@redhat.com>

On 27 Jul 2015, at 11:42, Thomas Heute wrote:

> Indeed, this is an Hawkular issue with embedded Cassandra.
> We should fix it by properly defining the startup dependencies, we may 
> also think of keeping "embedded Cassandra" as a separate process.

Yes, as this is very much related to 
https://issues.jboss.org/browse/HAWKULAR-432
> PS: I am not advocating for one or the other solution as I don't know 
> the advantages/drawbacks of both solutions

The current solution certainly has the charm, that the user only needs 
one
command to start Hawkular.
Perhaps we should consider printing a large warning at the start
to say that this is only for first time demo usage and that the user
should otherwise run a separate C* process.
Which may even be the one that is supplied with Hawkular, but as
as separate process.
-------------- next part --------------
An embedded message was scrubbed...
From: "Heiko Rupp (JIRA)" <issues at jboss.org>
Subject: [JBoss JIRA] (HAWKULAR-432) Hawkular terminated due to Cass
 exception
Date: Mon, 27 Jul 2015 04:50:06 -0400 (EDT)
Size: 3523
Url: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150727/5a902f63/attachment-0002.eml 
-------------- next part --------------
An embedded message was scrubbed...
From: "Heiko Rupp (JIRA)" <issues at jboss.org>
Subject: [JBoss JIRA] (HAWKULAR-432) Hawkular terminated due to Cass
 exception
Date: Mon, 27 Jul 2015 04:50:06 -0400 (EDT)
Size: 3523
Url: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150727/5a902f63/attachment-0003.eml 

From lponce at redhat.com  Mon Jul 27 05:55:01 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 27 Jul 2015 05:55:01 -0400 (EDT)
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <55B5FCEC.70705@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
	<259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
	<55B5FCEC.70705@redhat.com>
Message-ID: <721555553.426352.1437990901204.JavaMail.zimbra@redhat.com>

+1

The WARNING message is correct as the component cannot connect to Cassandra, so, I don't remove those messages.

But as TH says, it's a matter of how to define the embedded cassandra in this scenario to be up and running before that the components.

Lucas

----- Original Message -----
> From: "Thomas Heute" <theute at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, July 27, 2015 11:42:04 AM
> Subject: Re: [Hawkular-dev] Could not connect to Cassandra ... - does it have to be a WARN with a stack trace?
> 
> Glad I am not the only one that finds those messages annoying :)
> 
> Indeed, this is an Hawkular issue with embedded Cassandra.
> We should fix it by properly defining the startup dependencies, we may also
> think of keeping "embedded Cassandra" as a separate process.
> 
> The idea of "embedding Cassandra" is that we don't need to ask users to go
> download it, "install it" and run it.
> But we could consider having a Cassandra in a different process (configured
> for our needs such as the data location, port and other settings) that is
> required to be started prior to run Hawkular (Hawkular would need to fail
> quickly and clearly if the user "forgot" to start Cassandra).
> 
> PS: I am not advocating for one or the other solution as I don't know the
> advantages/drawbacks of both solutions
> 
> Thomas
> 
> 
> 
> 
> 
> On 07/27/2015 11:11 AM, Michael Burman wrote:
> > Hi,
> >
> > And how would you distinguish between real warning and incorrect one? This
> > message is not printed when Hawkular-Metrics starts standalone andshould
> > not be removed. This is a container issue in Hawkular and should be fixed
> > there (so that no such error happens) instead of breaking the logging in
> > metrics. Most likely this happens with embedded-cassandra I guess?
> >
> >    - Micke
> >
> > ----- Original Message -----
> > From: "Peter Palaga" <ppalaga at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Monday, July 27, 2015 11:59:27 AM
> > Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have
> > to be a WARN with a stack trace?
> >
> > Hi *,
> >
> > There are several occurrences of this in every Hawkular start log:
> >
> > WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle]
> > (metricsservice-lifecycle-thread) Could not connect to Cassandra cluster
> > - assuming its not up yet:
> > com.datastax.driver.core.exceptions.NoHostAvailableException: All
> > host(s) tried for query failed (tried: /127.0.0.1:9042
> > (com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot
> > connect))
> >
> > plus the stack trace.
> >
> > So given that this happens during every HK startup, could we not
> > classify it as normal and change it to INFO without the stack trace?
> >
> > I am ready to prepare a PR unless somebody raises a hand against that.
> >
> > Thanks,
> >
> > Peter
> > _______________________________________________
> > 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  Mon Jul 27 06:27:05 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 27 Jul 2015 12:27:05 +0200
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
References: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
Message-ID: <55B60779.1090506@redhat.com>

BTW there was not a lot of activity on this threads, but I like the idea 
:) (I like IFTTT in general, so I am biased)

Thomas

On 07/20/2015 12:18 PM, Jiri Kremser wrote:
> Hello,
>    if you don't know the ifttt, it's simple site where you can define a trigger condition and then some action if the condition is met. It's a closed source software (no need to pay though), but the number of possible actions is enormous. I'd say it's industrial standard for this kind of problems. They provide a way to trigger the action manually by sending http POST to their api.
>
> It's described here:
>
> https://ifttt.com/maker
>
>
> The post request looks like this:
>
> `curl -X POST -H "Content-Type: application/json" -d '{"value1":"1","value2":"2","value3":"foo"}' https://maker.ifttt.com/trigger/sdf/with/key/aabbccddeeffgghh`
>
> where sdf is the name of the event (must be defined via their website), aabbcc.. is the secret token for the user and valueN:n in the json is the arbitrary data you can then use inside the actions. For instance in the subject of the email or whatever the action allows.
>
> So, if we add a new alert notification that can do such a post request we can get for free all these actions:
>
> https://ifttt.com/recipes/do
>
> Again, the if-condition-then-action rule must be defined via their website (if condition is called 'maker' in this case), the actions use the oauth so it asks for permission if needed. For instance I use it for pushbullet notifications so It asked pushbulet "auth api"
>
> wdyt?
>
> jk
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From hrupp at redhat.com  Mon Jul 27 07:58:15 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 27 Jul 2015 13:58:15 +0200
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <55B60779.1090506@redhat.com>
References: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
	<55B60779.1090506@redhat.com>
Message-ID: <67DF8ED3-75F6-48BF-8219-0A400A794EE4@redhat.com>

On 27 Jul 2015, at 12:27, Thomas Heute wrote:

> BTW there was not a lot of activity on this threads, but I like the idea
> :) (I like IFTTT in general, so I am biased)

Isn't that a perfect task for someone looking for some
coding task in Hawkular-land?

From theute at redhat.com  Mon Jul 27 08:12:15 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 27 Jul 2015 14:12:15 +0200
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <67DF8ED3-75F6-48BF-8219-0A400A794EE4@redhat.com>
References: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
	<55B60779.1090506@redhat.com>
	<67DF8ED3-75F6-48BF-8219-0A400A794EE4@redhat.com>
Message-ID: <55B6201F.9020500@redhat.com>

We could propose it on Thursday demo call

On 07/27/2015 01:58 PM, Heiko W.Rupp wrote:
> On 27 Jul 2015, at 12:27, Thomas Heute wrote:
>
> > BTW there was not a lot of activity on this threads, but I like the idea
> > :) (I like IFTTT in general, so I am biased)
>
> Isn't that a perfect task for someone looking for some
> coding task in Hawkular-land?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lponce at redhat.com  Mon Jul 27 08:39:41 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 27 Jul 2015 08:39:41 -0400 (EDT)
Subject: [Hawkular-dev] IFTTT alert notifications
In-Reply-To: <55B6201F.9020500@redhat.com>
References: <1694988688.259693.1437387488733.JavaMail.zimbra@redhat.com>
	<55B60779.1090506@redhat.com>
	<67DF8ED3-75F6-48BF-8219-0A400A794EE4@redhat.com>
	<55B6201F.9020500@redhat.com>
Message-ID: <1918526047.582150.1438000781175.JavaMail.zimbra@redhat.com>

Hi,

Just a side note, we are improving the actions-plugins architecture to make more easier to develop new plugins for notifications.

If no delays it will be ready for thursday (I hope), just in case if it is going to talk about it, it could be interesting to point them into the new one (will be in alerts component in 0.4.0.Final).

Thanks,
Lucas


----- Original Message -----
> From: "Thomas Heute" <theute at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, July 27, 2015 2:12:15 PM
> Subject: Re: [Hawkular-dev] IFTTT alert notifications
> 
> We could propose it on Thursday demo call
> 
> On 07/27/2015 01:58 PM, Heiko W.Rupp wrote:
> > On 27 Jul 2015, at 12:27, Thomas Heute wrote:
> >
> > > BTW there was not a lot of activity on this threads, but I like the idea
> > > :) (I like IFTTT in general, so I am biased)
> >
> > Isn't that a perfect task for someone looking for some
> > coding task in Hawkular-land?
> > _______________________________________________
> > 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 mwringe at redhat.com  Mon Jul 27 09:53:37 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Mon, 27 Jul 2015 09:53:37 -0400
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <721555553.426352.1437990901204.JavaMail.zimbra@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
	<259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
	<55B5FCEC.70705@redhat.com>
	<721555553.426352.1437990901204.JavaMail.zimbra@redhat.com>
Message-ID: <55B637E1.3020409@redhat.com>

There are a couple of things here.

One is the embedded Cassandra. I don't know if its a dependency issue in 
that we are not defining the embedded Cassandra as a dependency properly 
or if its something along the lines of that the dependency is started, 
but not yet able to accept connections yet. Either way, it looks like we 
need to figure that out and handle the warning in the logs better (which 
could be fixing the dependency management, or making it info level for 
the first couple of failures).

The other issue is when we are using an external Cassandra and its not 
yet available to take connections when Hawkular is started. In Hawkular 
Metrics anyways, it will start and throw the warning messages in the 
logs until Cassandra is fully running. This is done so that we can start 
Hawkular Metrics and Cassandra at the same time and not have to worry 
about the order of things. This is really handy if Cassandra and 
Hawkular Metrics are configured as services to start when the machine is 
rebooted, and also when dealing with containers (especially since 
containers don't have the same concept of dependencies).

But maybe these should be changed to 'info' level for the first while 
and only then transformed into 'warnings'. Or handled in some other 
manner. Its a bit weird since when starting containers at the same time, 
the initial failures are expected, but if they persist, it usually means 
the Cassandra container was not started or failed to startup properly.

On 27/07/15 05:55 AM, Lucas Ponce wrote:
> +1
>
> The WARNING message is correct as the component cannot connect to Cassandra, so, I don't remove those messages.
>
> But as TH says, it's a matter of how to define the embedded cassandra in this scenario to be up and running before that the components.
>
> Lucas
>
> ----- Original Message -----
>> From: "Thomas Heute" <theute at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Monday, July 27, 2015 11:42:04 AM
>> Subject: Re: [Hawkular-dev] Could not connect to Cassandra ... - does it have to be a WARN with a stack trace?
>>
>> Glad I am not the only one that finds those messages annoying :)
>>
>> Indeed, this is an Hawkular issue with embedded Cassandra.
>> We should fix it by properly defining the startup dependencies, we may also
>> think of keeping "embedded Cassandra" as a separate process.
>>
>> The idea of "embedding Cassandra" is that we don't need to ask users to go
>> download it, "install it" and run it.
>> But we could consider having a Cassandra in a different process (configured
>> for our needs such as the data location, port and other settings) that is
>> required to be started prior to run Hawkular (Hawkular would need to fail
>> quickly and clearly if the user "forgot" to start Cassandra).
>>
>> PS: I am not advocating for one or the other solution as I don't know the
>> advantages/drawbacks of both solutions
>>
>> Thomas
>>
>>
>>
>>
>>
>> On 07/27/2015 11:11 AM, Michael Burman wrote:
>>> Hi,
>>>
>>> And how would you distinguish between real warning and incorrect one? This
>>> message is not printed when Hawkular-Metrics starts standalone andshould
>>> not be removed. This is a container issue in Hawkular and should be fixed
>>> there (so that no such error happens) instead of breaking the logging in
>>> metrics. Most likely this happens with embedded-cassandra I guess?
>>>
>>>     - Micke
>>>
>>> ----- Original Message -----
>>> From: "Peter Palaga" <ppalaga at redhat.com>
>>> To: "Discussions around Hawkular development"
>>> <hawkular-dev at lists.jboss.org>
>>> Sent: Monday, July 27, 2015 11:59:27 AM
>>> Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have
>>> to be a WARN with a stack trace?
>>>
>>> Hi *,
>>>
>>> There are several occurrences of this in every Hawkular start log:
>>>
>>> WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle]
>>> (metricsservice-lifecycle-thread) Could not connect to Cassandra cluster
>>> - assuming its not up yet:
>>> com.datastax.driver.core.exceptions.NoHostAvailableException: All
>>> host(s) tried for query failed (tried: /127.0.0.1:9042
>>> (com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot
>>> connect))
>>>
>>> plus the stack trace.
>>>
>>> So given that this happens during every HK startup, could we not
>>> classify it as normal and change it to INFO without the stack trace?
>>>
>>> I am ready to prepare a PR unless somebody raises a hand against that.
>>>
>>> Thanks,
>>>
>>> Peter
>>> _______________________________________________
>>> 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  Mon Jul 27 10:28:25 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 27 Jul 2015 10:28:25 -0400
Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it
 have to be a WARN with a stack trace?
In-Reply-To: <55B637E1.3020409@redhat.com>
References: <55B5F2EF.1070903@redhat.com>
	<259029089.407573.1437988265776.JavaMail.zimbra@redhat.com>
	<55B5FCEC.70705@redhat.com>
	<721555553.426352.1437990901204.JavaMail.zimbra@redhat.com>
	<55B637E1.3020409@redhat.com>
Message-ID: <55B64009.4030604@redhat.com>



On 7/27/2015 9:53 AM, Matt Wringe wrote:
> There are a couple of things here.
>
> One is the embedded Cassandra. I don't know if its a dependency issue in
> that we are not defining the embedded Cassandra as a dependency properly
> or if its something along the lines of that the dependency is started,
> but not yet able to accept connections yet. Either way, it looks like we
> need to figure that out and handle the warning in the logs better (which
> could be fixing the dependency management, or making it info level for
> the first couple of failures).

I don't think It's feasible to add a dependency on embedded cassandra 
because we want to support embedded or remote and jboss-all.xml does not 
support optional deployment dependencies (afaik).  So, I think the best 
you can do with the nest deployment is what hawkular-alerts-metrics.war 
does, it depends on hawkular-metrics-api-jaxrs.war.  But it may be the 
case that you don't want your deployment to know it's part of hawkular 
at all. In that case adding a jboss-all.xml means you need to build 
specifically for hawkular.

If we want to suppress the messages the for some fairly large period 
either don't log or log info/debug.

>
> The other issue is when we are using an external Cassandra and its not
> yet available to take connections when Hawkular is started. In Hawkular
> Metrics anyways, it will start and throw the warning messages in the
> logs until Cassandra is fully running. This is done so that we can start
> Hawkular Metrics and Cassandra at the same time and not have to worry
> about the order of things. This is really handy if Cassandra and
> Hawkular Metrics are configured as services to start when the machine is
> rebooted, and also when dealing with containers (especially since
> containers don't have the same concept of dependencies).
>
> But maybe these should be changed to 'info' level for the first while
> and only then transformed into 'warnings'. Or handled in some other
> manner. Its a bit weird since when starting containers at the same time,
> the initial failures are expected, but if they persist, it usually means
> the Cassandra container was not started or failed to startup properly.

+1, same sort of thing.

>
> On 27/07/15 05:55 AM, Lucas Ponce wrote:
>> +1
>>
>> The WARNING message is correct as the component cannot connect to Cassandra, so, I don't remove those messages.
>>
>> But as TH says, it's a matter of how to define the embedded cassandra in this scenario to be up and running before that the components.
>>
>> Lucas
>>
>> ----- Original Message -----
>>> From: "Thomas Heute" <theute at redhat.com>
>>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>>> Sent: Monday, July 27, 2015 11:42:04 AM
>>> Subject: Re: [Hawkular-dev] Could not connect to Cassandra ... - does it have to be a WARN with a stack trace?
>>>
>>> Glad I am not the only one that finds those messages annoying :)
>>>
>>> Indeed, this is an Hawkular issue with embedded Cassandra.
>>> We should fix it by properly defining the startup dependencies, we may also
>>> think of keeping "embedded Cassandra" as a separate process.
>>>
>>> The idea of "embedding Cassandra" is that we don't need to ask users to go
>>> download it, "install it" and run it.
>>> But we could consider having a Cassandra in a different process (configured
>>> for our needs such as the data location, port and other settings) that is
>>> required to be started prior to run Hawkular (Hawkular would need to fail
>>> quickly and clearly if the user "forgot" to start Cassandra).
>>>
>>> PS: I am not advocating for one or the other solution as I don't know the
>>> advantages/drawbacks of both solutions
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>> On 07/27/2015 11:11 AM, Michael Burman wrote:
>>>> Hi,
>>>>
>>>> And how would you distinguish between real warning and incorrect one? This
>>>> message is not printed when Hawkular-Metrics starts standalone andshould
>>>> not be removed. This is a container issue in Hawkular and should be fixed
>>>> there (so that no such error happens) instead of breaking the logging in
>>>> metrics. Most likely this happens with embedded-cassandra I guess?
>>>>
>>>>      - Micke
>>>>
>>>> ----- Original Message -----
>>>> From: "Peter Palaga" <ppalaga at redhat.com>
>>>> To: "Discussions around Hawkular development"
>>>> <hawkular-dev at lists.jboss.org>
>>>> Sent: Monday, July 27, 2015 11:59:27 AM
>>>> Subject: [Hawkular-dev] Could not connect to Cassandra ... - does it have
>>>> to be a WARN with a stack trace?
>>>>
>>>> Hi *,
>>>>
>>>> There are several occurrences of this in every Hawkular start log:
>>>>
>>>> WARN  [org.hawkular.metrics.api.jaxrs.MetricsServiceLifecycle]
>>>> (metricsservice-lifecycle-thread) Could not connect to Cassandra cluster
>>>> - assuming its not up yet:
>>>> com.datastax.driver.core.exceptions.NoHostAvailableException: All
>>>> host(s) tried for query failed (tried: /127.0.0.1:9042
>>>> (com.datastax.driver.core.TransportException: [/127.0.0.1:9042] Cannot
>>>> connect))
>>>>
>>>> plus the stack trace.
>>>>
>>>> So given that this happens during every HK startup, could we not
>>>> classify it as normal and change it to INFO without the stack trace?
>>>>
>>>> I am ready to prepare a PR unless somebody raises a hand against that.
>>>>
>>>> Thanks,
>>>>
>>>> Peter
>>>> _______________________________________________
>>>> 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 mazz at redhat.com  Mon Jul 27 16:30:48 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 27 Jul 2015 16:30:48 -0400 (EDT)
Subject: [Hawkular-dev] sequencing of feed-comm
In-Reply-To: <1840117064.937166.1438028692032.JavaMail.zimbra@redhat.com>
Message-ID: <745644060.938136.1438029048350.JavaMail.zimbra@redhat.com>

Just sending this to document it :) Can we put these plantuml documents somewhere so they can render? github or someplace? 

Anyway, this is the current impl - the responses coming back from the agent will pass through directly from the server to the UI websocket - this will not work long term -- see below 


This will not work because the UI that submitted the request may not be connected to the same server that the feed is connected to - so we need to put a message on the bus that is the incoming response from the feed and a UI listener will be listening on the bus and send all messages to its UI. This may be difficult to do since UIs do not have an identifier like feeds do (feed ID) - there are session IDs but they change for each websocket connection. I'll figure something out :) Anyway, this is how it should work: 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150727/0457afa0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: direct-to-ui.png
Type: image/png
Size: 51732 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150727/0457afa0/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus-to-ui.png
Type: image/png
Size: 58785 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150727/0457afa0/attachment-0003.png 

From lkrejci at redhat.com  Mon Jul 27 20:00:47 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 27 Jul 2015 20:00:47 -0400 (EDT)
Subject: [Hawkular-dev] execute op
In-Reply-To: <2088007378.4264881.1437770712807.JavaMail.zimbra@redhat.com>
References: <2088007378.4264881.1437770712807.JavaMail.zimbra@redhat.com>
Message-ID: <1252366865.1403527.1438041647656.JavaMail.zimbra@redhat.com>

I'm currently working HWKINVENT-62 - aka resource configuration.

I imagine this could be done by a listener on a bus that would listen to (as
of now imaginary -  https://issues.jboss.org/browse/HWKINVENT-104)
"config changed" events and react accordingly - connecting to the agent and
let it do its magic.

Once the agent is done, a "config applied" could be emitted so that interested
parties could react on that (UI, inventory once it supports history, ...).

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, 24 July, 2015 10:45:12 PM
> Subject: [Hawkular-dev] execute op
> 
> As part of the new UI-server-feed comm work, the following now works.
> 
> In our agent config, if a resource-type has an operation defined, you can
> execute that operation from end-to-end. I don't have the UI coded up - I
> mock out the UI with a simulated websocket client.
> 
> These are the log messages I got in the logs to show it working:
> 
> 1) The UI sends in the request over websocket - the content of the request
> looks like this:
> 
>     ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor",
>     "operationName":"Status"}
> 
> 2) The server receives it over the websocket. Log message:
> 
>    Received message from UI client [AjEP4Q3X0ViCalHvAsodkve92mshxsCxJTy9PQ9r]
> 
> 3) And then puts it on the bus. Whatever server is currently connected to
> that feed will have a bus listener for this particular command for that
> particular feed and picks it up. Log message from the bus listener:
> 
>    Asking feed [mazztower] to execute operation [Status] on resource ID
>    [mazztower~Local~/subsystem=hawkular-monitor]
> 
> 4) That bus listener does what it needs to do - in this case, forwards the
> message to the appropriate feed/agent. Log message:
> 
>     Attempting to send async message to [1] clients:
>     [ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor","operationName":"Status"}]
> 
> 5) The agent gets the message from its websocket. Log messages:
> 
>     Received message from server
>     Received request to execute operation [Status] on resource
>     [mazztower~Local~/subsystem=hawkular-monitor]
> 
> 6) Once the operation is executed, the results are sent back to the server -
> these are logs back on the server again:
> 
>     Received message from feed [mazztower]
>     Operation execution completed.
>     Resource=[mazztower~Local~/subsystem=hawkular-monitor],
>     Operation=[Status], Status=[OK], Message=["STOPPED"]
> 
> So you can see the server was told that the operation succeeded and what the
> results were in Message.
> 
> Lots more to do. But the end-to-end is working. Need to support parameters,
> next. Then have to figure out how to do resource configuration using this
> same comm mechanism.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From fbrychta at redhat.com  Thu Jul 30 05:40:08 2015
From: fbrychta at redhat.com (Filip Brychta)
Date: Thu, 30 Jul 2015 05:40:08 -0400 (EDT)
Subject: [Hawkular-dev] What is the best way to build hawkular with the
 latest hawkular-metrics?
In-Reply-To: <716887028.598782.1438247907729.JavaMail.zimbra@redhat.com>
Message-ID: <675713897.601988.1438249208987.JavaMail.zimbra@redhat.com>

Hello,
I have following goal:
1 - build each hawkular-metrics PR
2 - build hawkular-dist using artifact from step 1
3 - run some tests

What could be the best and most reliable way to do this?

a) just build hawkular dist with hawkular-metrics snapshot from step 1
  - I tried this and it was working for a while but then it stopped working (I guess when those intergration branches were introduced)
  - is there any chance that this approach will ever be reliable?
b) build hawkular dist using the latest snapshots for all components
  - is this reliable?
c) any other option?

Or the only reliable way is to build hawkular-metrics and deploy it to a wildfly manually as a single component and test it this way?

Thank you,

Filip

From ppalaga at redhat.com  Thu Jul 30 07:38:03 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 30 Jul 2015 13:38:03 +0200
Subject: [Hawkular-dev] What is the best way to build hawkular with the
 latest hawkular-metrics?
In-Reply-To: <675713897.601988.1438249208987.JavaMail.zimbra@redhat.com>
References: <675713897.601988.1438249208987.JavaMail.zimbra@redhat.com>
Message-ID: <55BA0C9B.2070000@redhat.com>

Ahoj Filip, inline...

On 2015-07-30 11:40, Filip Brychta wrote:
> Hello,
> I have following goal:
> 1 - build each hawkular-metrics PR
> 2 - build hawkular-dist using artifact from step 1

This is might not be enough, depending on whether WF agent is within 
your test scope. If you also want to test the agent, you need to build 
Agent with the Metrics snapshot too, and then use that Agent snapshot 
and Metrics snapshot in the HK main build. But generally, there is no 
guarantee that new Metrics or Agent PRs will not break their downstream.

-- P

> 3 - run some tests
> What could be the best and most reliable way to do this?
>
> a) just build hawkular dist with hawkular-metrics snapshot from step 1
>    - I tried this and it was working for a while but then it stopped working (I guess when those intergration branches were introduced)
>    - is there any chance that this approach will ever be reliable?
> b) build hawkular dist using the latest snapshots for all components
>    - is this reliable?
> c) any other option?
>
> Or the only reliable way is to build hawkular-metrics and deploy it to a wildfly manually as a single component and test it this way?
>
> Thank you,
>
> Filip
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lzoubek at redhat.com  Thu Jul 30 08:11:55 2015
From: lzoubek at redhat.com (Libor Zoubek)
Date: Thu, 30 Jul 2015 14:11:55 +0200
Subject: [Hawkular-dev] Hawkular ruby client
Message-ID: <op.x2k5h5z2yqhume@localhost.localdomain>

Hello,

I'd like to announce hawkular client written in ruby. It can only talk to Hakwular Metrics at this point, but covers almost whole API (almost = I might have missed something). Feel free to try it out.

github:        https://github.com/hawkular/hawkular-client-ruby
documentation: http://www.hawkular.org/hawkular-client-ruby/

Cheers,

-- 
Libor Zoubek

From hrupp at redhat.com  Thu Jul 30 09:27:45 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 30 Jul 2015 15:27:45 +0200
Subject: [Hawkular-dev] Revisit resource naming + resource types for Alpha4
Message-ID: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>

Hey,

we currently have a pretty ad-hoc resource naming scheme,
that involves magic constants like "MI~R" or "AI~R"
and also sometimes square brackets '[' and ']', which are
even invalid characters (if not escaped) inside a URL [1].

A recent switch from resource naming with [] to one without
[] created a bit of a mess, as the metric names still expect
the [] and probably other clients that are not part of the
github.com/hawkular repositories  


We need to revisit and fix the resource types
(e.g. supply WildFly base data from within the Hawkular server)
and the resources using those including names of
metric definitions , operation definitions etc in Alpha4
before too much code relies on it.

Similar I believe that resource info should not contain
the full type information every time - only if explicitly
requested. Clients should be able to get the type info
by following a link that is supplied in the resource info.

On top of that we need to publish how client writers 
can get the data they need. 


[1] https://issues.jboss.org/browse/HAWKULAR-491

From mazz at redhat.com  Thu Jul 30 10:07:35 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 30 Jul 2015 10:07:35 -0400 (EDT)
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
Message-ID: <863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>

To explain that those MI~R and AI~R things are. Its simple, and done for a reason (I do do things for actual reasons - I didn't just arbitrarily throw letters together :) - but it is not necessary these IDs stay this way (the reason was for easier debugging and reading the logs).

First, realize these are ONLY identifiers for metric instances (that is, metric instance definitions assigned to resources). They are not resource IDs, or metric type IDs. Only metric instance IDs.

The syntax is:

MI~R~[%1]~MT~%2

or

AI~R~[%1]~AT~%2

Where "MI" refers to "MeasurementInstance" and "AI" means "AvailInstance" - that's a distinction made only in the agent. These have two parts - a resource and a type.

The ~R~ just means "the next thing coming is the resource ID."

And that next thing is [%1] where %1 is the resource ID that is associated with this metric instance. (I wrap in brackets so its easy to pick out when debugging or reading the logs - I think the UI might even use a hack to expect that to wrap the ID, even though it shouldn't be doing that - these IDs should be opaque).

The next is either ~MT~ (MT meaning "Metric Type") or ~AT~ (meaning "Avail Type" - again, a distinction only in the agent - they are all "metric types" in inventory) which just means "the next thing coming is the metric type ID.

%2 is the metric type ID

I will say all that extra stuff is helpful when reading them in the logs, which is the sole reason why I did it  - when I see "AI~R~[blah]~AT~[boo]" in the log I know exactly what it is referencing ("an availability metric on resource blah whose type is boo") - no need to guess or root through the logs and inventory storage to find out what those are. Very easy to debug.

All that said (now that I've defended my reasons for the magic constants :), we can change this to whatever we want SO LONG AS it is unique, obviously. I can get rid of all that extra stuff. We can definitely get rid of the "[" "]" - those where just to make it easy to pick out the resource ID (unless the UI expects those too). We can change the "~" to something else or remove them. We can remove the "AI", "MI", "AT", "MT", and "R" if its too verbose. In fact, none of this ID is "necessary" internally other than it needs to be unique (it is "nice" for debugging and reading logs, that is all).

The resource ID, however, has three parts itself and those are separated by a required "~" but that is only due to a hack we needed to get that "execute operations" feature to work in the latest alpha (the server assumes the resource ID's first part is the feed ID, and the feed ID is separated from the rest with "~" - but once we get rid of that hack, the resource ID can again be changed to whatever syntax we want so long as it is unique.

--John Mazz

----- Original Message -----
> Hey,
> 
> we currently have a pretty ad-hoc resource naming scheme,
> that involves magic constants like "MI~R" or "AI~R"
> and also sometimes square brackets '[' and ']', which are
> even invalid characters (if not escaped) inside a URL [1].
> 
> A recent switch from resource naming with [] to one without
> [] created a bit of a mess, as the metric names still expect
> the [] and probably other clients that are not part of the
> github.com/hawkular repositories
> 
> 
> We need to revisit and fix the resource types
> (e.g. supply WildFly base data from within the Hawkular server)
> and the resources using those including names of
> metric definitions , operation definitions etc in Alpha4
> before too much code relies on it.
> 
> Similar I believe that resource info should not contain
> the full type information every time - only if explicitly
> requested. Clients should be able to get the type info
> by following a link that is supplied in the resource info.
> 
> On top of that we need to publish how client writers
> can get the data they need.
> 
> 
> [1] https://issues.jboss.org/browse/HAWKULAR-491
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mwringe at redhat.com  Thu Jul 30 10:36:37 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 30 Jul 2015 10:36:37 -0400
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
Message-ID: <55BA3675.30603@redhat.com>



On 30/07/15 10:07 AM, John Mazzitelli wrote:
> To explain that those MI~R and AI~R things are. Its simple, and done for a reason (I do do things for actual reasons - I didn't just arbitrarily throw letters together :) - but it is not necessary these IDs stay this way (the reason was for easier debugging and reading the logs).
>
> First, realize these are ONLY identifiers for metric instances (that is, metric instance definitions assigned to resources). They are not resource IDs, or metric type IDs. Only metric instance IDs.
>
> The syntax is:
>
> MI~R~[%1]~MT~%2
>
> or
>
> AI~R~[%1]~AT~%2
>
> Where "MI" refers to "MeasurementInstance" and "AI" means "AvailInstance" - that's a distinction made only in the agent. These have two parts - a resource and a type.
>
> The ~R~ just means "the next thing coming is the resource ID."
>
> And that next thing is [%1] where %1 is the resource ID that is associated with this metric instance. (I wrap in brackets so its easy to pick out when debugging or reading the logs - I think the UI might even use a hack to expect that to wrap the ID, even though it shouldn't be doing that - these IDs should be opaque).
>
> The next is either ~MT~ (MT meaning "Metric Type") or ~AT~ (meaning "Avail Type" - again, a distinction only in the agent - they are all "metric types" in inventory) which just means "the next thing coming is the metric type ID.
>
> %2 is the metric type ID
>
> I will say all that extra stuff is helpful when reading them in the logs, which is the sole reason why I did it  - when I see "AI~R~[blah]~AT~[boo]" in the log I know exactly what it is referencing ("an availability metric on resource blah whose type is boo") - no need to guess or root through the logs and inventory storage to find out what those are. Very easy to debug.
>
> All that said (now that I've defended my reasons for the magic constants :), we can change this to whatever we want SO LONG AS it is unique, obviously. I can get rid of all that extra stuff. We can definitely get rid of the "[" "]" - those where just to make it easy to pick out the resource ID (unless the UI expects those too). We can change the "~" to something else or remove them. We can remove the "AI", "MI", "AT", "MT", and "R" if its too verbose. In fact, none of this ID is "necessary" internally other than it needs to be unique (it is "nice" for debugging and reading logs, that is all).
>
> The resource ID, however, has three parts itself and those are separated by a required "~" but that is only due to a hack we needed to get that "execute operations" feature to work in the latest alpha (the server assumes the resource ID's first part is the feed ID, and the feed ID is separated from the rest with "~" - but once we get rid of that hack, the resource ID can again be changed to whatever syntax we want so long as it is unique.

 From a metrics perspective, the id should be any string that a client 
wants to use. Since it can be any string, then any tools which do a call 
to a URL just needs to url encode the metrics id part.

It can be frustrating to a user if ids become policed to be url safe. 
All this is going to do is force the client developer to url encode the 
metric id themselves, especially if part of the metric id contains some 
user generated value (say the name of a container, which is allowed to 
have url unsafe characters).

But, the metric id should really just be an identifier. Encoding data 
into the id and then parsing it out doesn't seem right. Maybe that other 
data could be added as a 'tag' or maybe we need some other mechanism to 
store this information.

>
> --John Mazz
>
> ----- Original Message -----
>> Hey,
>>
>> we currently have a pretty ad-hoc resource naming scheme,
>> that involves magic constants like "MI~R" or "AI~R"
>> and also sometimes square brackets '[' and ']', which are
>> even invalid characters (if not escaped) inside a URL [1].
>>
>> A recent switch from resource naming with [] to one without
>> [] created a bit of a mess, as the metric names still expect
>> the [] and probably other clients that are not part of the
>> github.com/hawkular repositories
>>
>>
>> We need to revisit and fix the resource types
>> (e.g. supply WildFly base data from within the Hawkular server)
>> and the resources using those including names of
>> metric definitions , operation definitions etc in Alpha4
>> before too much code relies on it.
>>
>> Similar I believe that resource info should not contain
>> the full type information every time - only if explicitly
>> requested. Clients should be able to get the type info
>> by following a link that is supplied in the resource info.
>>
>> On top of that we need to publish how client writers
>> can get the data they need.
>>
>>
>> [1] https://issues.jboss.org/browse/HAWKULAR-491
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jsanda at redhat.com  Thu Jul 30 10:55:30 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 30 Jul 2015 10:55:30 -0400
Subject: [Hawkular-dev] Revisit resource naming + resource types for
	Alpha4
In-Reply-To: <55BA3675.30603@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
Message-ID: <C39EFD6D-9CF7-45A3-8A8D-C0A78F3A84A0@redhat.com>


> On Jul 30, 2015, at 10:36 AM, Matt Wringe <mwringe at redhat.com> wrote:
> 
> 
> 
> On 30/07/15 10:07 AM, John Mazzitelli wrote:
>> To explain that those MI~R and AI~R things are. Its simple, and done for a reason (I do do things for actual reasons - I didn't just arbitrarily throw letters together :) - but it is not necessary these IDs stay this way (the reason was for easier debugging and reading the logs).
>> 
>> First, realize these are ONLY identifiers for metric instances (that is, metric instance definitions assigned to resources). They are not resource IDs, or metric type IDs. Only metric instance IDs.
>> 
>> The syntax is:
>> 
>> MI~R~[%1]~MT~%2
>> 
>> or
>> 
>> AI~R~[%1]~AT~%2
>> 
>> Where "MI" refers to "MeasurementInstance" and "AI" means "AvailInstance" - that's a distinction made only in the agent. These have two parts - a resource and a type.
>> 
>> The ~R~ just means "the next thing coming is the resource ID."
>> 
>> And that next thing is [%1] where %1 is the resource ID that is associated with this metric instance. (I wrap in brackets so its easy to pick out when debugging or reading the logs - I think the UI might even use a hack to expect that to wrap the ID, even though it shouldn't be doing that - these IDs should be opaque).
>> 
>> The next is either ~MT~ (MT meaning "Metric Type") or ~AT~ (meaning "Avail Type" - again, a distinction only in the agent - they are all "metric types" in inventory) which just means "the next thing coming is the metric type ID.
>> 
>> %2 is the metric type ID
>> 
>> I will say all that extra stuff is helpful when reading them in the logs, which is the sole reason why I did it - when I see "AI~R~[blah]~AT~[boo]" in the log I know exactly what it is referencing ("an availability metric on resource blah whose type is boo") - no need to guess or root through the logs and inventory storage to find out what those are. Very easy to debug.
>> 
>> All that said (now that I've defended my reasons for the magic constants :), we can change this to whatever we want SO LONG AS it is unique, obviously. I can get rid of all that extra stuff. We can definitely get rid of the "[" "]" - those where just to make it easy to pick out the resource ID (unless the UI expects those too). We can change the "~" to something else or remove them. We can remove the "AI", "MI", "AT", "MT", and "R" if its too verbose. In fact, none of this ID is "necessary" internally other than it needs to be unique (it is "nice" for debugging and reading logs, that is all).
>> 
>> The resource ID, however, has three parts itself and those are separated by a required "~" but that is only due to a hack we needed to get that "execute operations" feature to work in the latest alpha (the server assumes the resource ID's first part is the feed ID, and the feed ID is separated from the rest with "~" - but once we get rid of that hack, the resource ID can again be changed to whatever syntax we want so long as it is unique.
> 
> From a metrics perspective, the id should be any string that a client 
> wants to use. Since it can be any string, then any tools which do a call 
> to a URL just needs to url encode the metrics id part.

This might be somewhat of a separate issue, but we need to introduce some reserved characters that users are not allowed to use for metric ids and tag names. I haven?t yet written up a ticket with the details, but the reason is because we will be generating metrics/time series and use some ?internal? tags. We need at least one reserved character to make sure we avoid naming conflicts between user ids/names and system generated ones.

> 
> It can be frustrating to a user if ids become policed to be url safe. 
> All this is going to do is force the client developer to url encode the 
> metric id themselves, especially if part of the metric id contains some 
> user generated value (say the name of a container, which is allowed to 
> have url unsafe characters).
> 
> But, the metric id should really just be an identifier. Encoding data 
> into the id and then parsing it out doesn't seem right. Maybe that other 
> data could be added as a 'tag' or maybe we need some other mechanism to 
> store this information.
> 
>> 
>> --John Mazz
>> 
>> ----- Original Message -----
>>> Hey,
>>> 
>>> we currently have a pretty ad-hoc resource naming scheme,
>>> that involves magic constants like "MI~R" or "AI~R"
>>> and also sometimes square brackets '[' and ']', which are
>>> even invalid characters (if not escaped) inside a URL [1].
>>> 
>>> A recent switch from resource naming with [] to one without
>>> [] created a bit of a mess, as the metric names still expect
>>> the [] and probably other clients that are not part of the
>>> github.com/hawkular repositories
>>> 
>>> 
>>> We need to revisit and fix the resource types
>>> (e.g. supply WildFly base data from within the Hawkular server)
>>> and the resources using those including names of
>>> metric definitions , operation definitions etc in Alpha4
>>> before too much code relies on it.
>>> 
>>> Similar I believe that resource info should not contain
>>> the full type information every time - only if explicitly
>>> requested. Clients should be able to get the type info
>>> by following a link that is supplied in the resource info.
>>> 
>>> On top of that we need to publish how client writers
>>> can get the data they need.
>>> 
>>> 
>>> [1] https://issues.jboss.org/browse/HAWKULAR-491
>>> _______________________________________________
>>> 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/20150730/0e34b300/attachment-0001.html 

From hrupp at redhat.com  Thu Jul 30 11:43:09 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 30 Jul 2015 17:43:09 +0200
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <55BA3675.30603@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
Message-ID: <D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>

On 30 Jul 2015, at 16:36, Matt Wringe wrote:
> to a URL just needs to url encode the metrics id part.
>
> It can be frustrating to a user if ids become policed to be url safe.

Not sure I understand this.
The 2nd sentence says that the proposal of the 1st sentence
is frustrating. 

And take the / as an example - if you don't encode it, then
the Jax-rs mechanisms for 

GET /bla/{id}/foo

will not work if id has a literal / in it. => you need to make
it url-safe.


From miburman at redhat.com  Thu Jul 30 12:38:42 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 30 Jul 2015 12:38:42 -0400 (EDT)
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
	<D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
Message-ID: <2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>

Hi,

Why are we fighting encoding in 2015? Mainframes had these things solved in 1963. Resource identifier and resource separator are different things and JAX-RS has no issues with encoded URLs, it will automatically parse them and decode.

  - Micke

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, July 30, 2015 6:43:09 PM
Subject: Re: [Hawkular-dev] Revisit resource naming + resource types for Alpha4

On 30 Jul 2015, at 16:36, Matt Wringe wrote:
> to a URL just needs to url encode the metrics id part.
>
> It can be frustrating to a user if ids become policed to be url safe.

Not sure I understand this.
The 2nd sentence says that the proposal of the 1st sentence
is frustrating. 

And take the / as an example - if you don't encode it, then
the Jax-rs mechanisms for 

GET /bla/{id}/foo

will not work if id has a literal / in it. => you need to make
it url-safe.

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

From hrupp at redhat.com  Thu Jul 30 14:03:41 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 30 Jul 2015 20:03:41 +0200
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
	<D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
	<2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>
Message-ID: <3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>

On 30 Jul 2015, at 18:38, Michael Burman wrote:

> Why are we fighting encoding in 2015? Mainframes had these things 

Because: 
a) the recent change of resource id format has broken code in several
places where the semantics were not really known and/or implicitly applied
Metrics are stored with a [id] while the inventory now only has id and no
longer [id]. That must not happen again

b) not all consumers/clients are machines. We need to make it easy to 
consume our services

c) the current format of specifying resource data + resource type information
may not be what we want going forward.

d) we need to ensure that if e.g. ':tag' all of a sudden gets a special 
meaning in a metric id, clients do not send that as part of a normal id,
as metrics or any other part of Hawkular may behave in ways that are
not obvious.

If we keep what we have fine. But then we need to document it and
stick to it in a consistent way all over the place, so that ids or partial
urls are/become predictable. 


From mazz at redhat.com  Thu Jul 30 14:32:47 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 30 Jul 2015 14:32:47 -0400 (EDT)
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
	<D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
	<2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>
	<3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>
Message-ID: <2008839385.1382941.1438281167351.JavaMail.zimbra@redhat.com>

IMO, resource IDs need to be opaque - the fact that it went from [id] to id should not have mattered. clients should never care about a format or syntax of an ID. Now, of course, I say that knowing that I myself just hacked up the server through my knowledge that IDs have the feed ID in it :-) but I have a big TODO in the code to change that soon.

----- Original Message -----
> On 30 Jul 2015, at 18:38, Michael Burman wrote:
> 
> > Why are we fighting encoding in 2015? Mainframes had these things
> 
> Because:
> a) the recent change of resource id format has broken code in several
> places where the semantics were not really known and/or implicitly applied
> Metrics are stored with a [id] while the inventory now only has id and no
> longer [id]. That must not happen again
> 
> b) not all consumers/clients are machines. We need to make it easy to
> consume our services
> 
> c) the current format of specifying resource data + resource type information
> may not be what we want going forward.
> 
> d) we need to ensure that if e.g. ':tag' all of a sudden gets a special
> meaning in a metric id, clients do not send that as part of a normal id,
> as metrics or any other part of Hawkular may behave in ways that are
> not obvious.
> 
> If we keep what we have fine. But then we need to document it and
> stick to it in a consistent way all over the place, so that ids or partial
> urls are/become predictable.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From miburman at redhat.com  Thu Jul 30 14:54:25 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 30 Jul 2015 14:54:25 -0400 (EDT)
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
	<D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
	<2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>
	<3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>
Message-ID: <625682924.1740892.1438282465898.JavaMail.zimbra@redhat.com>

Hi,

But this [id] or id has nothing to do with encoding. It could have just as well been 'hawkular.id' or 'id' and be an issue. This is more to do with namespacing issue than limiting what characters we could use in the metrics ids. Hawkular-Metrics still returned the exact same name as was written to it. For namespacing (if we want to have such) of the feedIds, metricIds, etc yes we should have some sort of guidelines inside Hawkular (if there's some sort of meaning in that namespace that's not passed around, but in my opinion we should always pass around the full metricId and that would be it). But to limit the id characters on components because of namespacing issue? That's not a good reason.

Not to mention the normal browser usage. If the user wants to use easily remembered ids, he should not use generated ones (who could remember uuids if they can't remember encoding rules?). If this is a question of some certain agent then it's still not a global issue. 

  - Micke

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, July 30, 2015 9:03:41 PM
Subject: Re: [Hawkular-dev] Revisit resource naming + resource types for Alpha4

On 30 Jul 2015, at 18:38, Michael Burman wrote:

> Why are we fighting encoding in 2015? Mainframes had these things 

Because: 
a) the recent change of resource id format has broken code in several
places where the semantics were not really known and/or implicitly applied
Metrics are stored with a [id] while the inventory now only has id and no
longer [id]. That must not happen again

b) not all consumers/clients are machines. We need to make it easy to 
consume our services

c) the current format of specifying resource data + resource type information
may not be what we want going forward.

d) we need to ensure that if e.g. ':tag' all of a sudden gets a special 
meaning in a metric id, clients do not send that as part of a normal id,
as metrics or any other part of Hawkular may behave in ways that are
not obvious.

If we keep what we have fine. But then we need to document it and
stick to it in a consistent way all over the place, so that ids or partial
urls are/become predictable. 

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

From hrupp at redhat.com  Fri Jul 31 02:50:27 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 31 Jul 2015 08:50:27 +0200
Subject: [Hawkular-dev] Revisit resource naming + resource types for
 Alpha4
In-Reply-To: <625682924.1740892.1438282465898.JavaMail.zimbra@redhat.com>
References: <2E0E2E70-E4B5-4CF6-8EBF-63D3C22D90D5@redhat.com>
	<863067971.1196476.1438265255332.JavaMail.zimbra@redhat.com>
	<55BA3675.30603@redhat.com>
	<D21CBD49-11E2-477E-93D4-D0F5203B9B33@redhat.com>
	<2033351011.1574301.1438274322399.JavaMail.zimbra@redhat.com>
	<3FC83453-35F2-44D5-B17A-958552392DB8@redhat.com>
	<625682924.1740892.1438282465898.JavaMail.zimbra@redhat.com>
Message-ID: <6E2466AF-B142-4FF8-A48E-7E99FB4E466C@redhat.com>

On 30 Jul 2015, at 20:54, Michael Burman wrote:

> But this [id] or id has nothing to do with encoding. It could have 
> just as well been 'hawkular.id' or 'id' and be an issue. This is more

You are right, it has nothing to do with encoding.
It is rather a mis-understanding of semantics where some parts/parties
were thinking the [] belong to the id while others don't.
We need to define those semantics going forward.

> to do with namespacing issue than limiting what characters we could 
> use in the metrics ids. Hawkular-Metrics still returned the exact same 
> name as was written to it. For namespacing (if we want to have

This is nice, but not enough for Hawkular overall.
Also if John says he needs a special character for some tags, then
we need to make sure that this special character does not show up
in a resource id, when the resource id is part of the metric name,
as otherwise it could be misinterpreted by Hawkular-Metrics.

> Not to mention the normal browser usage. If the user wants to use 
> easily remembered ids, he should not use generated ones (who could 
> remember uuids if they can't remember encoding rules?). If this is a 
> question of some certain agent then it's still not a global issue.

I am not proposing UUIDs.
But for humans to remember a sequence of %5D%20%2F%20%5B, it is
as readable as a UUID.

From hrupp at redhat.com  Fri Jul 31 05:05:08 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 31 Jul 2015 11:05:08 +0200
Subject: [Hawkular-dev] Hawkular ruby client
In-Reply-To: <op.x2k5h5z2yqhume@localhost.localdomain>
References: <op.x2k5h5z2yqhume@localhost.localdomain>
Message-ID: <9F8011B2-F4D3-4D52-80B6-31343EF089F3@redhat.com>

On 30 Jul 2015, at 14:11, Libor Zoubek wrote:

> I'd like to announce hawkular client written in ruby. It can only 

Cool!

From fbrychta at redhat.com  Fri Jul 31 11:25:40 2015
From: fbrychta at redhat.com (Filip Brychta)
Date: Fri, 31 Jul 2015 11:25:40 -0400 (EDT)
Subject: [Hawkular-dev] Each hawkular-metrics PR is now checked for
	performance regression
In-Reply-To: <936330517.1061608.1438349413295.JavaMail.zimbra@redhat.com>
Message-ID: <853188647.1100318.1438356340639.JavaMail.zimbra@redhat.com>

Hello,
Please be aware that second check (first is continuous-integration/travis-ci/pr) on each hawkular-metrics PR now finally does something useful.

Following build (http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/haw-perf-stability-test/) is launched for each PR which will:
1 - build the PR
2 - build hawkular-dist using snapshot artifact from step 1
3 - deploy hawkular-dist
4 - start perf test which will
  - generate as high load as the hawkular is able to server. Right now from 300 threads where each thread is using unique tenantId.
  - measure average throughput (one request == POST one data point to http://${server.host}:${server.port}/hawkular/metrics/gauges/test/data and wait for response)
  - check % diff with previous build
  - if the % diff is < -2, it will fail the build. Right now it's still not 100% stable because of shared network, this problem should be fixed soon. Expected instability is now +/- 2 % so anything bigger than 2% should be considered as regression
5 - report status back to the PR


So please from now on pay attention to result of that check and ping me if it fails.
Consider this just as first step, there will be more next week since we have more time now (JON 3.3.3 is out).

It would be nice if anybody could create a PR which would test this (just include some tiny sleep into request processing)

Thanks,

Filip