From theute at redhat.com  Fri May  1 09:17:16 2015
From: theute at redhat.com (Thomas Heute)
Date: Fri, 01 May 2015 15:17:16 +0200
Subject: [Hawkular-dev] Public Hawkular Instances - Feedback Please
In-Reply-To: <739646864.10670849.1430426009913.JavaMail.zimbra@redhat.com>
References: <739646864.10670849.1430426009913.JavaMail.zimbra@redhat.com>
Message-ID: <55437CDC.1020602@redhat.com>

I sometimes use 18080 to quickly check progress and/or verify something 
quick, it's been helpful.

I haven't used 18090.

It seems that the availability of that service has not been great but 
improved, if it's on 99% of the time then we should keep one of them.

In parallel we need to work on hawkular.io which would be SaaS-like, 
with data persisted and easy to upgrade when we want to. I have the 
infrastructure (CPU/memory/disk) ready on public OS1 since last week, we 
still need to deploy Hawkular and make Hawkular support tenants.

Thomas

On 04/30/2015 10:33 PM, Matthew Mahoney wrote:
> Hawkular Community,
>
> The JON QE team is querying feedback regarding the availability &
> usefulness of the Public Hawkular Instances:
>
> http://209.132.178.218:18080   (Try it out - "kick the tires
> <http://en.wiktionary.org/wiki/kick_the_tires>")
> http://209.132.178.218:18090   (On-demand build for Development /
> Integration usage)
>
>   * Are either of these instances being used, and if so for what purpose?
>
>   * What can we do to make these instances more usable / useful?
>
>
> Thanks!
>
> Matt
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From mithomps at redhat.com  Sat May  2 20:35:41 2015
From: mithomps at redhat.com (mike thompson)
Date: Sat, 2 May 2015 17:35:41 -0700
Subject: [Hawkular-dev] Top 5 Java Performance Metrics to Capture in
	Enterprise Applications
Message-ID: <590E8423-98CA-468B-A8C1-D1DC38A327B7@redhat.com>

I?m sure others have might have seen this but I thought this article pretty relevant to Hawkular:

http://java.dzone.com/articles/top-5-java-performance-metrics <http://java.dzone.com/articles/top-5-java-performance-metrics>

? Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150502/9550cb8f/attachment.html 

From miburman at redhat.com  Sun May  3 04:37:49 2015
From: miburman at redhat.com (Michael Burman)
Date: Sun, 3 May 2015 04:37:49 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
In-Reply-To: <563346197.10140584.1430432894081.JavaMail.zimbra@redhat.com>
References: <563346197.10140584.1430432894081.JavaMail.zimbra@redhat.com>
Message-ID: <907568993.11417768.1430642269828.JavaMail.zimbra@redhat.com>

Hi,

My wish for version numbering in the future - this should have been called 0.4.0 because of extensive external API-changes. 0.3.3 would have been fine if the changes were just internal, but we should follow some sort of logic in the version numbering.

  - Micke

----- Original Message -----
From: "Stefan Negrea" <snegrea at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Friday, May 1, 2015 1:28:14 AM
Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond

Hello Everybody,

I am happy to announce release 0.3.3 of Hawkular Metrics. The release is anchored by three major and notable changes: REST API reorganization, tenant id changes, and Docker + Kubernetes work.


1) REST API reoganization

- The API has been reorganized to follow a more traditional REST structure. 
- The numeric metrics have been renamed to Gauage. Going forward the term number will be used for an overarching category of metrics (gauge, counter, histograms, etc.). 
- The root of the project has been updated to be consistent with the rest of the Hawkular projects. The new root is http://host:port/hawkular/metrics

The attached pdf document has the comparison for the API changes between 0.3.1 and 0.3.3.


2) Tenant Id

The tenant id has been removed from the URL to either a header parameter or a query  parameter. The query parameter can be used in cases (such as curl)  where setting a header is not possible, difficult, or inconvenient. 

The concept of tenant will be an integral part of the project going forward. But we wanted more flexibility in the way the tenant id for a request is derived. So removing the tenant id from the URL will give us permanent &  consistent resource addresses (metrics and metric data points); and will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id. If the same user later decides to use the tenant id header, the URL of the resources accessed with the user/pass combo would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret) in the long run anyway.

Here is an example of the change:

Existing URL:
/{tenantId}/gauge/{metricId}/data

New URL:
/gauge/{metricId}/data

Tenant id set via:
1) header - tenantId
2) query parameter - tenantId

There are two exceptions to this rule, /tenants and /db/{tenantid}/series.  The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not  belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.

The attached pdf document includes the removal of the tenant id from the URL.


3) Docker and Kubernetes

Thanks to the amazing work done by Matt Wringe, we now have a subproject in Hawkular Metrics that can be used to create components to be run on Openshift/Fabric8 (https://github.com/hawkular/hawkular-metrics/tree/master/containers).

This includes:

a) A customized Cassandra docker image which uses a seed provider to automatically detect other nodes running behind the same service.

b) A standalone dockerized Hawkular Metrics image. This will startup a hawkular metrics instance which will automatically detect and connect to the Cassandra service.

c) A kubernetes application for a single step install into OpenShift or Fabric8. The zip can even be deployed via the drag-n-drop mechanism in the Fabric8 console!

This is the foundation for later integrations that would require the project package in the form of containers.


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

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

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




Hawkular Metrics 0.3.4 and Beyond

Here is a list of features and enhancements that we planned for 0.3.4 and beyond. 
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. The design has been already presented and discussed during 0.3.3 release cycle. The task queue work has already been started by John. We expect at least an initial implementation to land in 0.3.4.
3) Go client - will help with integrating with third party metrics  collection framework. This work is the foundation for a Heapster sink.
4) Public Java API - following the work done in 0.3.1 for the core, the  goal is to separate the implementation from a public API and make that  available to clients
5) Update REST testing - while the current set of tests is a good gauge  for regressions, the overall coverage is still low. The plan for 0.3.2  is to increase coverage.
6) Improved docker and kubernetes support



A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, and Heiko Rupp for their  project contributions. Special mentions go to Jeeva Kandasamy, Jirka  Kremser, and Michael Burman for their project help.



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 theute at redhat.com  Mon May  4 02:43:09 2015
From: theute at redhat.com (Thomas Heute)
Date: Mon, 04 May 2015 08:43:09 +0200
Subject: [Hawkular-dev] Top 5 Java Performance Metrics to Capture in
 Enterprise Applications
In-Reply-To: <590E8423-98CA-468B-A8C1-D1DC38A327B7@redhat.com>
References: <590E8423-98CA-468B-A8C1-D1DC38A327B7@redhat.com>
Message-ID: <554714FD.1060201@redhat.com>

Good one, thanks for sharing

On 05/03/2015 02:35 AM, mike thompson wrote:
> I?m sure others have might have seen this but I thought this article
> pretty relevant to Hawkular:
>
> http://java.dzone.com/articles/top-5-java-performance-metrics
>
> ? Mike
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From hrupp at redhat.com  Mon May  4 03:00:00 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 04 May 2015 09:00:00 +0200
Subject: [Hawkular-dev] Properties store?
Message-ID: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>

Hey,

in RHQ we had several ways to record properties of things
* traits
* resource configuration
* plugin configuration
* ... 

I think we need something similar in Hawkular.

Having said that, we probably should avoid the above situation
and find out what is really needed.

I can imagine that for stuff that are in reality changing attributes of
a resource (e.g. version, #of cpus, ip address, ....) - basically stuff
that is not changing like a metric, some key-value pairs on the
resource in inventory may be the best place.



From lponce at redhat.com  Mon May  4 06:45:33 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 4 May 2015 06:45:33 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
In-Reply-To: <907568993.11417768.1430642269828.JavaMail.zimbra@redhat.com>
References: <563346197.10140584.1430432894081.JavaMail.zimbra@redhat.com>
	<907568993.11417768.1430642269828.JavaMail.zimbra@redhat.com>
Message-ID: <938214971.10269313.1430736333869.JavaMail.zimbra@redhat.com>

+1

I like the logic to change the minor one only for bug fixing, and as Micke suggest, to use a 0.4.0 if there is some change in the Java/REST API.

Also for other components as well.

But I guess this is something to normalize at some point.

Thanks,
Lucas

----- Original Message -----
> From: "Michael Burman" <miburman at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Sunday, May 3, 2015 10:37:49 AM
> Subject: Re: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
> 
> Hi,
> 
> My wish for version numbering in the future - this should have been called
> 0.4.0 because of extensive external API-changes. 0.3.3 would have been fine
> if the changes were just internal, but we should follow some sort of logic
> in the version numbering.
> 
>   - Micke
> 
> ----- Original Message -----
> From: "Stefan Negrea" <snegrea at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, May 1, 2015 1:28:14 AM
> Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
> 
> Hello Everybody,
> 
> I am happy to announce release 0.3.3 of Hawkular Metrics. The release is
> anchored by three major and notable changes: REST API reorganization, tenant
> id changes, and Docker + Kubernetes work.
> 
> 
> 1) REST API reoganization
> 
> - The API has been reorganized to follow a more traditional REST structure.
> - The numeric metrics have been renamed to Gauage. Going forward the term
> number will be used for an overarching category of metrics (gauge, counter,
> histograms, etc.).
> - The root of the project has been updated to be consistent with the rest of
> the Hawkular projects. The new root is http://host:port/hawkular/metrics
> 
> The attached pdf document has the comparison for the API changes between
> 0.3.1 and 0.3.3.
> 
> 
> 2) Tenant Id
> 
> The tenant id has been removed from the URL to either a header parameter or a
> query  parameter. The query parameter can be used in cases (such as curl)
> where setting a header is not possible, difficult, or inconvenient.
> 
> The concept of tenant will be an integral part of the project going forward.
> But we wanted more flexibility in the way the tenant id for a request is
> derived. So removing the tenant id from the URL will give us permanent &
> consistent resource addresses (metrics and metric data points); and will
> gain a lot of flexibility on the security side. In the future, users could
> authenticate with a user/pass combo and the backend would transform that
> into a tenant id. If the same user later decides to use the tenant id
> header, the URL of the resources accessed with the user/pass combo would not
> change. Another expectation is that tenant id is not sufficient, it is
> typically a combo of id + secret; so we would have resorted to a header or
> query param for the second piece of information (the secret) in the long run
> anyway.
> 
> Here is an example of the change:
> 
> Existing URL:
> /{tenantId}/gauge/{metricId}/data
> 
> New URL:
> /gauge/{metricId}/data
> 
> Tenant id set via:
> 1) header - tenantId
> 2) query parameter - tenantId
> 
> There are two exceptions to this rule, /tenants and /db/{tenantid}/series.
> The /tenants end-point will be changed into something different in the
> upcoming releases since it is mostly a management type API that does not
> belong in the same place with the regular metrics endpoint. And
> /db/{tenantid}/series end-point is needed in this exact format for
> compatibility with Influxdb compatible services.
> 
> The attached pdf document includes the removal of the tenant id from the URL.
> 
> 
> 3) Docker and Kubernetes
> 
> Thanks to the amazing work done by Matt Wringe, we now have a subproject in
> Hawkular Metrics that can be used to create components to be run on
> Openshift/Fabric8
> (https://github.com/hawkular/hawkular-metrics/tree/master/containers).
> 
> This includes:
> 
> a) A customized Cassandra docker image which uses a seed provider to
> automatically detect other nodes running behind the same service.
> 
> b) A standalone dockerized Hawkular Metrics image. This will startup a
> hawkular metrics instance which will automatically detect and connect to the
> Cassandra service.
> 
> c) A kubernetes application for a single step install into OpenShift or
> Fabric8. The zip can even be deployed via the drag-n-drop mechanism in the
> Fabric8 console!
> 
> This is the foundation for later integrations that would require the project
> package in the form of containers.
> 
> 
> Github Release:
> https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.3
> 
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
> 
> Jira release tracker:
> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12326937
> 
> 
> 
> 
> Hawkular Metrics 0.3.4 and Beyond
> 
> Here is a list of features and enhancements that we planned for 0.3.4 and
> beyond.
> 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of
> losing some fidelity. The design has been already presented and discussed
> during 0.3.3 release cycle. The task queue work has already been started by
> John. We expect at least an initial implementation to land in 0.3.4.
> 3) Go client - will help with integrating with third party metrics
> collection framework. This work is the foundation for a Heapster sink.
> 4) Public Java API - following the work done in 0.3.1 for the core, the  goal
> is to separate the implementation from a public API and make that  available
> to clients
> 5) Update REST testing - while the current set of tests is a good gauge  for
> regressions, the overall coverage is still low. The plan for 0.3.2  is to
> increase coverage.
> 6) Improved docker and kubernetes support
> 
> 
> 
> A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt
> Wringe, and Heiko Rupp for their  project contributions. Special mentions go
> to Jeeva Kandasamy, Jirka  Kremser, and Michael Burman for their project
> help.
> 
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lkrejci at redhat.com  Mon May  4 08:03:15 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 4 May 2015 08:03:15 -0400 (EDT)
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
Message-ID: <706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>

In my mind almost anything "is changing like a metric", because everything
changes over time.

Also IMHO  "key-value pairs" are just JSON. I think that the structured data
support for configs and operation params served us well in RHQ.

So IMHO we need a time-series store for structured data. I am not sure inventory
is that -  it is good for storing relationships among entities but I am not
sure if it is well suited for storing (versioned) structured data.

The reason for that is that such support would require somehow translating the
JSON-like format of the structured data into a graph of nodes in the underlying
graph database to enable any visibility of the constituent parts of the data
structure.

Alternatively, with Titan, it might be possible to achieve the same result
if we employed ElasticSearch as additional backend for it and configured it
to analyze the JSON. I have not yet looked into the possibilities, pros nor
cons of that approach.

Or just use ElasticSearch as a "properties store" straight away - both
inventory and IMHO metrics could benefit from having ES as part of the Hawkular
cluster for their own purposes but IMHO a dedicated properties store should
be geared towards storing, analyzing and querying structured data - which is 
the exact sales pitch of ES ;)

Now I'm not saying that I know anything more about ES than I just said - maybe
it's completely different and I'm blabbering nonsense here, but I guess the 
point I wanted to make is that inventory is not designed to store, query
or analyze structured data in and of itself.

Lukas

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, 4 May, 2015 9:00:00 AM
> Subject: [Hawkular-dev] Properties store?
> 
> Hey,
> 
> in RHQ we had several ways to record properties of things
> * traits
> * resource configuration
> * plugin configuration
> * ...
> 
> I think we need something similar in Hawkular.
> 
> Having said that, we probably should avoid the above situation
> and find out what is really needed.
> 
> I can imagine that for stuff that are in reality changing attributes of
> a resource (e.g. version, #of cpus, ip address, ....) - basically stuff
> that is not changing like a metric, some key-value pairs on the
> resource in inventory may be the best place.
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From brmeyer at redhat.com  Mon May  4 09:54:31 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 4 May 2015 09:54:31 -0400 (EDT)
Subject: [Hawkular-dev] Artificer logos
In-Reply-To: <2055791076.12228134.1430747658255.JavaMail.zimbra@redhat.com>
Message-ID: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>

We're in the 2nd round of logo designs for Artificer, and I can't bloody decide on what looks better.  Votes?

http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png
http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png
http://design.jboss.org/artificer/logo/images/artificer_logo_r2v3.png
http://design.jboss.org/artificer/logo/images/artificer_logo_r2v4.png

From brmeyer at redhat.com  Mon May  4 10:46:52 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 4 May 2015 10:46:52 -0400 (EDT)
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
Message-ID: <269814482.12274194.1430750812337.JavaMail.zimbra@redhat.com>

I know I yell "Artificer!" a lot ;), but this is another central use case.  Store 1 logical, metadata-only artifact per resource, then add in the key/value properties.

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, May 4, 2015 3:00:00 AM
> Subject: [Hawkular-dev] Properties store?
> 
> Hey,
> 
> in RHQ we had several ways to record properties of things
> * traits
> * resource configuration
> * plugin configuration
> * ...
> 
> I think we need something similar in Hawkular.
> 
> Having said that, we probably should avoid the above situation
> and find out what is really needed.
> 
> I can imagine that for stuff that are in reality changing attributes of
> a resource (e.g. version, #of cpus, ip address, ....) - basically stuff
> that is not changing like a metric, some key-value pairs on the
> resource in inventory may be the best place.
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Mon May  4 13:33:08 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 4 May 2015 13:33:08 -0400 (EDT)
Subject: [Hawkular-dev] Top 5 Java Performance Metrics to Capture in
 Enterprise Applications
In-Reply-To: <554714FD.1060201@redhat.com>
References: <590E8423-98CA-468B-A8C1-D1DC38A327B7@redhat.com>
	<554714FD.1060201@redhat.com>
Message-ID: <1713307048.12048860.1430760788350.JavaMail.zimbra@redhat.com>

Yes, good article.

Once we have a BTM solution in place to provide the business transaction baseline information, triggering alerts, combined with container metrics, we could start to address thecore thread "Open-source predictive infrastructure?" :)


----- Original Message -----
> Good one, thanks for sharing
> 
> On 05/03/2015 02:35 AM, mike thompson wrote:
> > I?m sure others have might have seen this but I thought this article
> > pretty relevant to Hawkular:
> >
> > http://java.dzone.com/articles/top-5-java-performance-metrics
> >
> > ? Mike
> >
> >
> > _______________________________________________
> > 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  Tue May  5 06:56:14 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 5 May 2015 06:56:14 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
In-Reply-To: <938214971.10269313.1430736333869.JavaMail.zimbra@redhat.com>
References: <563346197.10140584.1430432894081.JavaMail.zimbra@redhat.com>
	<907568993.11417768.1430642269828.JavaMail.zimbra@redhat.com>
	<938214971.10269313.1430736333869.JavaMail.zimbra@redhat.com>
Message-ID: <902092441.11610693.1430823374973.JavaMail.zimbra@redhat.com>

Hello,

Good suggestions and advice that we will follow for future releases. 


However, only REST API changes were introduced in 0.3.3. Very little changes were made in functionality, data format, and features. So in my opinion it did not warrant a minor increment.



Thank you,
Stefan 


----- Original Message -----
> From: "Lucas Ponce" <lponce at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, May 4, 2015 5:45:33 AM
> Subject: Re: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
> 
> +1
> 
> I like the logic to change the minor one only for bug fixing, and as Micke
> suggest, to use a 0.4.0 if there is some change in the Java/REST API.
> 
> Also for other components as well.
> 
> But I guess this is something to normalize at some point.
> 
> Thanks,
> Lucas
> 
> ----- Original Message -----
> > From: "Michael Burman" <miburman at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Sunday, May 3, 2015 10:37:49 AM
> > Subject: Re: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
> > 
> > Hi,
> > 
> > My wish for version numbering in the future - this should have been called
> > 0.4.0 because of extensive external API-changes. 0.3.3 would have been fine
> > if the changes were just internal, but we should follow some sort of logic
> > in the version numbering.
> > 
> >   - Micke
> > 
> > ----- Original Message -----
> > From: "Stefan Negrea" <snegrea at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Friday, May 1, 2015 1:28:14 AM
> > Subject: [Hawkular-dev] Hawkular Metrics 0.3.3 - Release & Beyond
> > 
> > Hello Everybody,
> > 
> > I am happy to announce release 0.3.3 of Hawkular Metrics. The release is
> > anchored by three major and notable changes: REST API reorganization,
> > tenant
> > id changes, and Docker + Kubernetes work.
> > 
> > 
> > 1) REST API reoganization
> > 
> > - The API has been reorganized to follow a more traditional REST structure.
> > - The numeric metrics have been renamed to Gauage. Going forward the term
> > number will be used for an overarching category of metrics (gauge, counter,
> > histograms, etc.).
> > - The root of the project has been updated to be consistent with the rest
> > of
> > the Hawkular projects. The new root is http://host:port/hawkular/metrics
> > 
> > The attached pdf document has the comparison for the API changes between
> > 0.3.1 and 0.3.3.
> > 
> > 
> > 2) Tenant Id
> > 
> > The tenant id has been removed from the URL to either a header parameter or
> > a
> > query  parameter. The query parameter can be used in cases (such as curl)
> > where setting a header is not possible, difficult, or inconvenient.
> > 
> > The concept of tenant will be an integral part of the project going
> > forward.
> > But we wanted more flexibility in the way the tenant id for a request is
> > derived. So removing the tenant id from the URL will give us permanent &
> > consistent resource addresses (metrics and metric data points); and will
> > gain a lot of flexibility on the security side. In the future, users could
> > authenticate with a user/pass combo and the backend would transform that
> > into a tenant id. If the same user later decides to use the tenant id
> > header, the URL of the resources accessed with the user/pass combo would
> > not
> > change. Another expectation is that tenant id is not sufficient, it is
> > typically a combo of id + secret; so we would have resorted to a header or
> > query param for the second piece of information (the secret) in the long
> > run
> > anyway.
> > 
> > Here is an example of the change:
> > 
> > Existing URL:
> > /{tenantId}/gauge/{metricId}/data
> > 
> > New URL:
> > /gauge/{metricId}/data
> > 
> > Tenant id set via:
> > 1) header - tenantId
> > 2) query parameter - tenantId
> > 
> > There are two exceptions to this rule, /tenants and /db/{tenantid}/series.
> > The /tenants end-point will be changed into something different in the
> > upcoming releases since it is mostly a management type API that does not
> > belong in the same place with the regular metrics endpoint. And
> > /db/{tenantid}/series end-point is needed in this exact format for
> > compatibility with Influxdb compatible services.
> > 
> > The attached pdf document includes the removal of the tenant id from the
> > URL.
> > 
> > 
> > 3) Docker and Kubernetes
> > 
> > Thanks to the amazing work done by Matt Wringe, we now have a subproject in
> > Hawkular Metrics that can be used to create components to be run on
> > Openshift/Fabric8
> > (https://github.com/hawkular/hawkular-metrics/tree/master/containers).
> > 
> > This includes:
> > 
> > a) A customized Cassandra docker image which uses a seed provider to
> > automatically detect other nodes running behind the same service.
> > 
> > b) A standalone dockerized Hawkular Metrics image. This will startup a
> > hawkular metrics instance which will automatically detect and connect to
> > the
> > Cassandra service.
> > 
> > c) A kubernetes application for a single step install into OpenShift or
> > Fabric8. The zip can even be deployed via the drag-n-drop mechanism in the
> > Fabric8 console!
> > 
> > This is the foundation for later integrations that would require the
> > project
> > package in the form of containers.
> > 
> > 
> > Github Release:
> > https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.3
> > 
> > JBoss Nexus Maven artifacts:
> > http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
> > 
> > Jira release tracker:
> > https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12326937
> > 
> > 
> > 
> > 
> > Hawkular Metrics 0.3.4 and Beyond
> > 
> > Here is a list of features and enhancements that we planned for 0.3.4 and
> > beyond.
> > 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense
> > of
> > losing some fidelity. The design has been already presented and discussed
> > during 0.3.3 release cycle. The task queue work has already been started by
> > John. We expect at least an initial implementation to land in 0.3.4.
> > 3) Go client - will help with integrating with third party metrics
> > collection framework. This work is the foundation for a Heapster sink.
> > 4) Public Java API - following the work done in 0.3.1 for the core, the
> > goal
> > is to separate the implementation from a public API and make that
> > available
> > to clients
> > 5) Update REST testing - while the current set of tests is a good gauge
> > for
> > regressions, the overall coverage is still low. The plan for 0.3.2  is to
> > increase coverage.
> > 6) Improved docker and kubernetes support
> > 
> > 
> > 
> > A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt
> > Wringe, and Heiko Rupp for their  project contributions. Special mentions
> > go
> > to Jeeva Kandasamy, Jirka  Kremser, and Michael Burman for their project
> > help.
> > 
> > 
> > 
> > Thank you,
> > Stefan Negrea
> > 
> > Software Engineer
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From tsegismo at redhat.com  Wed May  6 06:55:16 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 06 May 2015 12:55:16 +0200
Subject: [Hawkular-dev] Artificer logos
In-Reply-To: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
References: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
Message-ID: <5549F314.4000106@redhat.com>

Hi Brett,

Le 04/05/2015 15:54, Brett Meyer a ?crit :
> We're in the 2nd round of logo designs for Artificer, and I can't bloody decide on what looks better.  Votes?
>
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png

^^ this one is my favorite

> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png

There's an error in the link, it should be:
http://design.jboss.org/artificer/logo/images/artificer_logo_r2v2.png

> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v3.png
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v4.png

Regards,
Thomas


From theute at redhat.com  Wed May  6 06:55:15 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 06 May 2015 12:55:15 +0200
Subject: [Hawkular-dev] Artificer logos
In-Reply-To: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
References: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
Message-ID: <5549F313.6040106@redhat.com>

First one seems simple and efficient, my favorite

Thomas

On 05/04/2015 03:54 PM, Brett Meyer wrote:
> We're in the 2nd round of logo designs for Artificer, and I can't bloody decide on what looks better.  Votes?
>
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v1.png
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v3.png
> http://design.jboss.org/artificer/logo/images/artificer_logo_r2v4.png
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From hrupp at redhat.com  Wed May  6 09:28:42 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 06 May 2015 15:28:42 +0200
Subject: [Hawkular-dev] Artificer logos
In-Reply-To: <5549F313.6040106@redhat.com>
References: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
	<5549F313.6040106@redhat.com>
Message-ID: <AE9C6B13-0FE7-4959-B74E-80B63A78BE7F@redhat.com>

On 6 May 2015, at 12:55, Thomas Heute wrote:

> First one seems simple and efficient, my favorite

Mine as well.

v3 and v4 also look too close to the geocaching.com logo for me.

From brmeyer at redhat.com  Wed May  6 11:12:21 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 6 May 2015 11:12:21 -0400 (EDT)
Subject: [Hawkular-dev] Artificer logos
In-Reply-To: <AE9C6B13-0FE7-4959-B74E-80B63A78BE7F@redhat.com>
References: <548251830.12228272.1430747671671.JavaMail.zimbra@redhat.com>
	<5549F313.6040106@redhat.com>
	<AE9C6B13-0FE7-4959-B74E-80B63A78BE7F@redhat.com>
Message-ID: <778031334.13989502.1430925140995.JavaMail.zimbra@redhat.com>

Thanks guys.  Although I like #1, I think I'm having them continue on with #2.  It seemed a bit more legible and flexible, but maybe that's me.  Definitely agree on #3 and #4.  Liked the concept, but it's a bit of a stretch and wouldn't work as well as a standalone logo.

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 6, 2015 9:28:42 AM
> Subject: Re: [Hawkular-dev] Artificer logos
> 
> On 6 May 2015, at 12:55, Thomas Heute wrote:
> 
> > First one seems simple and efficient, my favorite
> 
> Mine as well.
> 
> v3 and v4 also look too close to the geocaching.com logo for me.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Fri May  8 04:57:52 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 8 May 2015 04:57:52 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <754132543.14050518.1431074510908.JavaMail.zimbra@redhat.com>
Message-ID: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>

Hi

As discussed yesterday, we need a general event store that can persist relevant events off the bus. However we didn't decide where this functionality should reside, whether in an existing component or in a new component.

Although it could be provided as a separate component, I am not sure we have any use cases where it would be used independent of the bus, so think it is probably best to include it as additional functionality within the Bus component.

Agree/disagree?

The other issues are:

- how to determine which events should be persisted, as we may want some events to trigger further processing by subscribers on the bus, but not necessarily be stored for historic analysis.

- for the event store we will need to know the type of the event being stored

So one possible solution to both these issues is, if the 'type' of the event is provided (possibly as a header value), then it will be persisted?

Then within Elasticsearch, we can use the tenant/persona as the Index (to truly segment the data) and the event type to ensure different information types are partitioned/indexed appropriately.

Thoughts?

Regards
Gary


From lponce at redhat.com  Fri May  8 05:08:50 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 8 May 2015 05:08:50 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
Message-ID: <1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, May 8, 2015 10:57:52 AM
> Subject: [Hawkular-dev] Event Store
> 
> Hi
> 
> As discussed yesterday, we need a general event store that can persist
> relevant events off the bus. However we didn't decide where this
> functionality should reside, whether in an existing component or in a new
> component.
> 
> Although it could be provided as a separate component, I am not sure we have
> any use cases where it would be used independent of the bus, so think it is
> probably best to include it as additional functionality within the Bus
> component.
> 
> Agree/disagree?
> 

In terms of archicture I would suggest to follow a similar architecture discussed for metrics/alerts/inventory.

A main component with this persistence/Java API dependencies and then to a Listener/CDI/TBD (glue) project that integrate the component with the Bus, so then if needed, component could work without Bus dependencies.
Perhaps we don't have an isolated use case without kettle/bus but I think that in that way we can unify the picture.


> The other issues are:
> 
> - how to determine which events should be persisted, as we may want some
> events to trigger further processing by subscribers on the bus, but not
> necessarily be stored for historic analysis.
> 
> - for the event store we will need to know the type of the event being stored
> 
> So one possible solution to both these issues is, if the 'type' of the event
> is provided (possibly as a header value), then it will be persisted?
> 
> Then within Elasticsearch, we can use the tenant/persona as the Index (to
> truly segment the data) and the event type to ensure different information
> types are partitioned/indexed appropriately.
> 
> Thoughts?
> 


In the meeting there was introduced ElasticSearch product/project but I would like to focus first in the requirements, in what we need, I know that metrics have their own querying requeriments, and also alerts and inventory.
So, before to introduce the product, I would like to get more info about what kind of filtering do we need (perhaps we can use elastic search in other areas) so, it could be interesting to discuss first, to see pros/cons also from architecture/dependencies and also to share with the other components how we are resolving today these aspects.

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

From jpkroehling at redhat.com  Fri May  8 05:14:17 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 08 May 2015 11:14:17 +0200
Subject: [Hawkular-dev] Event Store
In-Reply-To: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
Message-ID: <554C7E69.7080805@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/08/2015 10:57 AM, Gary Brown wrote:
> Hi
> 
> As discussed yesterday, we need a general event store that can
> persist relevant events off the bus. However we didn't decide where
> this functionality should reside, whether in an existing component
> or in a new component.
> 
> Although it could be provided as a separate component, I am not
> sure we have any use cases where it would be used independent of
> the bus, so think it is probably best to include it as additional
> functionality within the Bus component.
> 
> Agree/disagree?

With the micro-services approach in mind, I'd vote for a separate
component for the event-store. Such component has a potential to grow
in scope on the long term.

> The other issues are:
> 
> - how to determine which events should be persisted, as we may want
> some events to trigger further processing by subscribers on the
> bus, but not necessarily be stored for historic analysis. - for the
> event store we will need to know the type of the event being
> stored
> 
> So one possible solution to both these issues is, if the 'type' of
> the event is provided (possibly as a header value), then it will be
> persisted?

Could you give some examples of what "type" would be? I remember
hearing "deployment" as one of the possible types, but would be
interesting to think of some other cases.

I think there could also be a "group" or "category". This way, it
would be possible to easily switch the persist/discard flag for a
given set of types, depending on the current needs. For instance,
"store all events for category 'application'" might be useful during
an outage.

> Then within Elasticsearch, we can use the tenant/persona as the
> Index (to truly segment the data) and the event type to ensure
> different information types are partitioned/indexed appropriately.

+1

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

iQEcBAEBCAAGBQJVTH5pAAoJECKM1e+fkPrXFWEH+gP8tc0TmBk4ZBwuB890Y2pk
2/rZ6T/BPvtypT6WtgGd4p7/kWfkFmP9C2OPAA9lb3arv/QG18MDky79vVwNJ1ZO
992e5otXCCb8CSJ27XFnItOM/PCBrOk/mi1K0orWm5t1ykKffu5iSN3ftzym/CQ7
orlAfjqXN4iSfQGzHrIwkgQGbLBRkTNvtAkvd35s8p1vKBpNE1c68q+DteXgy8lq
an17X5mOvmqnZaoJZfn7mN6eFZmCxa8YPWAICYVUFKx2yzZI37e1G4yc/ckgObw1
AnS+SmhOO52T3wq6lqoOzhTz3Tvu/GjLYYR52HiMDzu2ru133eN1sHeEm/7jCXo=
=suCy
-----END PGP SIGNATURE-----

From gbrown at redhat.com  Fri May  8 05:25:46 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 8 May 2015 05:25:46 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <554C7E69.7080805@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<554C7E69.7080805@redhat.com>
Message-ID: <138414421.14074500.1431077146941.JavaMail.zimbra@redhat.com>



----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/08/2015 10:57 AM, Gary Brown wrote:
> > Hi
> > 
> > As discussed yesterday, we need a general event store that can
> > persist relevant events off the bus. However we didn't decide where
> > this functionality should reside, whether in an existing component
> > or in a new component.
> > 
> > Although it could be provided as a separate component, I am not
> > sure we have any use cases where it would be used independent of
> > the bus, so think it is probably best to include it as additional
> > functionality within the Bus component.
> > 
> > Agree/disagree?
> 
> With the micro-services approach in mind, I'd vote for a separate
> component for the event-store. Such component has a potential to grow
> in scope on the long term.
> 
> > The other issues are:
> > 
> > - how to determine which events should be persisted, as we may want
> > some events to trigger further processing by subscribers on the
> > bus, but not necessarily be stored for historic analysis. - for the
> > event store we will need to know the type of the event being
> > stored
> > 
> > So one possible solution to both these issues is, if the 'type' of
> > the event is provided (possibly as a header value), then it will be
> > persisted?
> 
> Could you give some examples of what "type" would be? I remember
> hearing "deployment" as one of the possible types, but would be
> interesting to think of some other cases.

Type could be anything, so a logical label such as "Log entry", "Alert", "BTMFragment", etc - just so that from an Elasticsearch perspective we could define a basic schema to identify how it should index the information for that type. Elasticsearch can dynamically create a schema based on the information it receives, but there are cases where you need to control how it processes the data (e.g. UUIDs) where you don't want it to analyse the field further.

> 
> I think there could also be a "group" or "category". This way, it
> would be possible to easily switch the persist/discard flag for a
> given set of types, depending on the current needs. For instance,
> "store all events for category 'application'" might be useful during
> an outage.
> 

Yes this may be useful.

It may be possible to simply identify certain topics that should be stored, so all events on that topic are persisted, and the topic essentially becomes the type name (or maps onto a type name). We may need further information about how the components are using the Bus to understand what is the best approach.


> > Then within Elasticsearch, we can use the tenant/persona as the
> > Index (to truly segment the data) and the event type to ensure
> > different information types are partitioned/indexed appropriately.
> 
> +1
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVTH5pAAoJECKM1e+fkPrXFWEH+gP8tc0TmBk4ZBwuB890Y2pk
> 2/rZ6T/BPvtypT6WtgGd4p7/kWfkFmP9C2OPAA9lb3arv/QG18MDky79vVwNJ1ZO
> 992e5otXCCb8CSJ27XFnItOM/PCBrOk/mi1K0orWm5t1ykKffu5iSN3ftzym/CQ7
> orlAfjqXN4iSfQGzHrIwkgQGbLBRkTNvtAkvd35s8p1vKBpNE1c68q+DteXgy8lq
> an17X5mOvmqnZaoJZfn7mN6eFZmCxa8YPWAICYVUFKx2yzZI37e1G4yc/ckgObw1
> AnS+SmhOO52T3wq6lqoOzhTz3Tvu/GjLYYR52HiMDzu2ru133eN1sHeEm/7jCXo=
> =suCy
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Fri May  8 05:35:01 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 08 May 2015 11:35:01 +0200
Subject: [Hawkular-dev] Event Store
In-Reply-To: <138414421.14074500.1431077146941.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<554C7E69.7080805@redhat.com>
	<138414421.14074500.1431077146941.JavaMail.zimbra@redhat.com>
Message-ID: <554C8345.9060909@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/08/2015 11:25 AM, Gary Brown wrote:
> Could you give some examples of what "type" would be? I remember 
> hearing "deployment" as one of the possible types, but would be 
> interesting to think of some other cases.
> 
>> Type could be anything, so a logical label such as "Log entry",
>> "Alert", "BTMFragment", etc - just so that from an Elasticsearch
>> perspective we could define a basic schema to identify how it
>> should index the information for that type. Elasticsearch can
>> dynamically create a schema based on the information it receives,
>> but there are cases where you need to control how it processes
>> the data (e.g. UUIDs) where you don't want it to analyse the
>> field further.

Then there could also be a "category" property, similar to the logging
approach. For instance, BTM could send 50 events for a single BTM
transaction, some with the FINEST category, some with CRITICAL, or
even ERROR, and only a small portion of them (say, > INFO) would be
persisted by default. In case of problems, it this could be changed to
log all events.

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

iQEcBAEBCAAGBQJVTINFAAoJECKM1e+fkPrXpMMH+gJqDoFL5XxHYH70KLR3AnLr
AawP7vwtYpIGWfZDijIezLJ5LS2Pyw3jBPq/NAWUHGdwiAdsOWC0r5ScQ1FMI3sl
FvxltcbnpdaRiPQzcOEhL0oNVyfiyDeAYCVGwp7ED1cvWFGGZouPYw7xs/1wVaep
cA8xICI8onjL51RNJWVg6LSyVXZwKVRzA0XhqQxyzUzv8zsM19k5F5XocxxHcau2
uzJ6+iO0uLZ5U7aUdpMzV82MP+p6HoGIf2vbIiaX11FehSfOreHn7W0NvVYhmOQf
n3NSdd48LscoeVEtpyFX3dft5/daU0m3YoraqF2F2UViW7stIo8Llkx55/Xf/so=
=vIg9
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Fri May  8 05:36:14 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 08 May 2015 11:36:14 +0200
Subject: [Hawkular-dev] Event Store
In-Reply-To: <554C8345.9060909@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>	<554C7E69.7080805@redhat.com>	<138414421.14074500.1431077146941.JavaMail.zimbra@redhat.com>
	<554C8345.9060909@redhat.com>
Message-ID: <554C838E.9010003@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Wait, nevermind... What I suggested is exactly what logging is
supposed to do:-) So, I think what I'm suggesting is a new logging
framework/tool, which makes absolutely no sense.

- - Juca.

On 05/08/2015 11:35 AM, Juraci Paix?o Kr?hling wrote:
> On 05/08/2015 11:25 AM, Gary Brown wrote:
>> Could you give some examples of what "type" would be? I remember
>>  hearing "deployment" as one of the possible types, but would be
>>  interesting to think of some other cases.
> 
>>> Type could be anything, so a logical label such as "Log
>>> entry", "Alert", "BTMFragment", etc - just so that from an
>>> Elasticsearch perspective we could define a basic schema to
>>> identify how it should index the information for that type.
>>> Elasticsearch can dynamically create a schema based on the
>>> information it receives, but there are cases where you need to
>>> control how it processes the data (e.g. UUIDs) where you don't
>>> want it to analyse the field further.
> 
> Then there could also be a "category" property, similar to the
> logging approach. For instance, BTM could send 50 events for a
> single BTM transaction, some with the FINEST category, some with
> CRITICAL, or even ERROR, and only a small portion of them (say, >
> INFO) would be persisted by default. In case of problems, it this
> could be changed to log all events.
> 
> - Juca. _______________________________________________ 
> hawkular-dev mailing list hawkular-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVTIOOAAoJECKM1e+fkPrXEnIIAJly6SWoPvr5IK+R8aeGO3YL
QZU3ckbepRya1zWhlxoSqKi0V9qR0wIesQ5isK7R+iJvBX5xptdndBAfn2Odfc3X
xeuhlUFHpZMpEdjGXtp0ozo7rIeGgWzunAK8oEEKEe+ydcVQNdKUPjvqzvO6TXlU
MBEF3vvhFik0XqlmgXs9ZTg6nXTf46M7mbK1YzajPxOe5FmEtYdbb5WO4AHzRUD7
MGFQTZK4DKyGJVxj3+//FHmNOnhS2x99ae12e+Yw020NhTwFvEj+2HUn7M+Di6kp
BOecMFxPw7klpdB6jKjwztvGFn86qWdh3c8AbDOum2dzBzFPVaag/HIGi+fKn0E=
=J1zm
-----END PGP SIGNATURE-----

From gbrown at redhat.com  Fri May  8 05:48:17 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 8 May 2015 05:48:17 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <554C838E.9010003@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<554C7E69.7080805@redhat.com>
	<138414421.14074500.1431077146941.JavaMail.zimbra@redhat.com>
	<554C8345.9060909@redhat.com> <554C838E.9010003@redhat.com>
Message-ID: <1968771626.14087998.1431078497048.JavaMail.zimbra@redhat.com>

No problem :) although having some high level grouping concept (across types/topics) to aid filtering what is persisted may still be valid (as I think you mentioned in your initial email). Just depends what those groupings would represent, and how they fit with use cases.

Regards
Gary


----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Wait, nevermind... What I suggested is exactly what logging is
> supposed to do:-) So, I think what I'm suggesting is a new logging
> framework/tool, which makes absolutely no sense.
> 
> - - Juca.
> 
> On 05/08/2015 11:35 AM, Juraci Paix?o Kr?hling wrote:
> > On 05/08/2015 11:25 AM, Gary Brown wrote:
> >> Could you give some examples of what "type" would be? I remember
> >>  hearing "deployment" as one of the possible types, but would be
> >>  interesting to think of some other cases.
> > 
> >>> Type could be anything, so a logical label such as "Log
> >>> entry", "Alert", "BTMFragment", etc - just so that from an
> >>> Elasticsearch perspective we could define a basic schema to
> >>> identify how it should index the information for that type.
> >>> Elasticsearch can dynamically create a schema based on the
> >>> information it receives, but there are cases where you need to
> >>> control how it processes the data (e.g. UUIDs) where you don't
> >>> want it to analyse the field further.
> > 
> > Then there could also be a "category" property, similar to the
> > logging approach. For instance, BTM could send 50 events for a
> > single BTM transaction, some with the FINEST category, some with
> > CRITICAL, or even ERROR, and only a small portion of them (say, >
> > INFO) would be persisted by default. In case of problems, it this
> > could be changed to log all events.
> > 
> > - Juca. _______________________________________________
> > hawkular-dev mailing list hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVTIOOAAoJECKM1e+fkPrXEnIIAJly6SWoPvr5IK+R8aeGO3YL
> QZU3ckbepRya1zWhlxoSqKi0V9qR0wIesQ5isK7R+iJvBX5xptdndBAfn2Odfc3X
> xeuhlUFHpZMpEdjGXtp0ozo7rIeGgWzunAK8oEEKEe+ydcVQNdKUPjvqzvO6TXlU
> MBEF3vvhFik0XqlmgXs9ZTg6nXTf46M7mbK1YzajPxOe5FmEtYdbb5WO4AHzRUD7
> MGFQTZK4DKyGJVxj3+//FHmNOnhS2x99ae12e+Yw020NhTwFvEj+2HUn7M+Di6kp
> BOecMFxPw7klpdB6jKjwztvGFn86qWdh3c8AbDOum2dzBzFPVaag/HIGi+fKn0E=
> =J1zm
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From gbrown at redhat.com  Fri May  8 06:30:37 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 8 May 2015 06:30:37 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
Message-ID: <1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>

Hi Lucas

----- Original Message -----
> > Although it could be provided as a separate component, I am not sure we
> > have
> > any use cases where it would be used independent of the bus, so think it is
> > probably best to include it as additional functionality within the Bus
> > component.
> > 
> > Agree/disagree?
> > 
> 
> In terms of archicture I would suggest to follow a similar architecture
> discussed for metrics/alerts/inventory.
> 
> A main component with this persistence/Java API dependencies and then to a
> Listener/CDI/TBD (glue) project that integrate the component with the Bus,
> so then if needed, component could work without Bus dependencies.
> Perhaps we don't have an isolated use case without kettle/bus but I think
> that in that way we can unify the picture.
> 

That sounds reasonable - although it is slightly different to how the events/alerts discussion went (I believe) where I think the suggestion was that events were persisted off the bus, including Alerts being published and stored, rather than locally storing - possibly my misunderstanding.

However on reflection that would make the components more dependent upon the bus, so probably better to have a shared 'persistence' component, as you suggest, which could be used by all of the other components to persist information directly, and then use the bus to publish the data for further processing.

In terms of Elasticsearch - this 'persistence' component could initially simply wrap Cassandra and then as we understand the query requirements, add (possibly optional) support for Elasticsearch to do the advanced queries.

Only component I am not sure about how it may use this shared 'persistence' component is Inventory, as it uses Cassandra via Titan?

Regards
Gary

From lponce at redhat.com  Fri May  8 07:18:26 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 8 May 2015 07:18:26 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
Message-ID: <424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>

Hi,

> 
> Hi Lucas
> 
> ----- Original Message -----
> > > Although it could be provided as a separate component, I am not sure we
> > > have
> > > any use cases where it would be used independent of the bus, so think it
> > > is
> > > probably best to include it as additional functionality within the Bus
> > > component.
> > > 
> > > Agree/disagree?
> > > 
> > 
> > In terms of archicture I would suggest to follow a similar architecture
> > discussed for metrics/alerts/inventory.
> > 
> > A main component with this persistence/Java API dependencies and then to a
> > Listener/CDI/TBD (glue) project that integrate the component with the Bus,
> > so then if needed, component could work without Bus dependencies.
> > Perhaps we don't have an isolated use case without kettle/bus but I think
> > that in that way we can unify the picture.
> > 
> 
> That sounds reasonable - although it is slightly different to how the
> events/alerts discussion went (I believe) where I think the suggestion was
> that events were persisted off the bus, including Alerts being published and
> stored, rather than locally storing - possibly my misunderstanding.
> 
> However on reflection that would make the components more dependent upon the
> bus, so probably better to have a shared 'persistence' component, as you
> suggest, which could be used by all of the other components to persist
> information directly, and then use the bus to publish the data for further
> processing.
> 
> In terms of Elasticsearch - this 'persistence' component could initially
> simply wrap Cassandra and then as we understand the query requirements, add
> (possibly optional) support for Elasticsearch to do the advanced queries.
> 
> Only component I am not sure about how it may use this shared 'persistence'
> component is Inventory, as it uses Cassandra via Titan?
> 

my points are two discuss perhaps in two layers:

- the business aspect, to map better what an Event needs to be (what not) to identify the business implications in terms of lifecycle, where/when is generated, how interacts with alerts/metrics/possible inventory as well. It was an interesting meeting, as I think that the Event can be also mapped with log entries/audit/other messages, etc. But on this layer I would like to get the busines concept.

- In the architecture aspect, I guess you are right, perhaps I didn't detail better my previous email, for example, in alerts, the architecture is to have a main engine that have a dependency with the cassandra cluster that can be shared (or not, this could be a future discussion) with metrics or other components, but the engine itself it has not a direct dependency with the bus, we add the bus dependency in an additional project, so we can have both alternatives: a use case where we can use the component in a standalone way or with the bus scenario, so it's a configuration/packaging option. My suggestion is that would be also interesting for EventsStore. Also, perhaps the ElasticSearch service can be shared as well for other components in the future.

Regards,
Lucas


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

From aakaruce at iitr.ac.in  Fri May  8 07:51:39 2015
From: aakaruce at iitr.ac.in (Aakarsh Agarwal)
Date: Fri, 08 May 2015 17:21:39 +0530
Subject: [Hawkular-dev] GSoC 2015 - Hawkular - pluggable data processors for
	metrics
In-Reply-To: <72d0ba89d02.554ca32f@iitr.ac.in>
References: <72d0ba89d02.554ca32f@iitr.ac.in>
Message-ID: <72d0f24f753a.554cf0a3@iitr.ac.in>

Hi folks,


First of all sorry for the delay in this introductory mail from my side.


My name is Aakarsh Agarwal, currently a student at Indian Institute of Engineering, Roorkee, India.


I have been selected for GSoC 2015 with JBoss, to do a project on "Hawkular - pluggable data processors for metrics". This project is aimed to develop interface for plugins that improve the performance of Hawkular-Metrics making it more dependable, dynamic and extending the scope of its usage in operating with data sets.


To add, I hangout on irc channel with username - "akki_007" and my blog will be coming soon which will be updated regularly about my progress on this project. Looking forward to start with the work asap.


Hopefully, it will be a great Summer of Code!


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

From gbrown at redhat.com  Fri May  8 08:40:33 2015
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 8 May 2015 08:40:33 -0400 (EDT)
Subject: [Hawkular-dev] GSoC 2015 - Hawkular - pluggable data processors
 for	metrics
In-Reply-To: <72d0f24f753a.554cf0a3@iitr.ac.in>
References: <72d0ba89d02.554ca32f@iitr.ac.in>
	<72d0f24f753a.554cf0a3@iitr.ac.in>
Message-ID: <874497181.14173853.1431088833051.JavaMail.zimbra@redhat.com>

Welcome Aakarsh - look forward to hearing more about the work.

Regards
Gary

----- Original Message -----
> Hi folks,
> 
> First of all sorry for the delay in this introductory mail from my side.
> 
> My name is Aakarsh Agarwal, currently a student at Indian Institute of
> Engineering, Roorkee, India.
> 
> I have been selected for GSoC 2015 with JBoss, to do a project on "Hawkular -
> pluggable data processors for metrics". This project is aimed to develop
> interface for plugins that improve the performance of Hawkular-Metrics
> making it more dependable, dynamic and extending the scope of its usage in
> operating with data sets.
> 
> To add, I hangout on irc channel with username - "akki_007" and my blog will
> be coming soon which will be updated regularly about my progress on this
> project. Looking forward to start with the work asap.
> 
> Hopefully, it will be a great Summer of Code!
> 
> Regards
> Aakarsh Agarwal
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Sat May  9 12:33:26 2015
From: gbrown at redhat.com (Gary Brown)
Date: Sat, 9 May 2015 12:33:26 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
Message-ID: <577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>

Hi Lucas

I think we probably need to revisit the use cases for the event store - possibly Thomas can outline his use case again and we start from there.

Unfortunately I wasn't in the architecture session, as I wanted to hear about the testing strategy, but sounds like treating each component standalone with the ability to publish relevant information of interest to other components via the bus (in certain configurations) is a good way to go.

Regards
Gary


----- Original Message -----
> Hi,
> 
> > 
> > Hi Lucas
> > 
> > ----- Original Message -----
> > > > Although it could be provided as a separate component, I am not sure we
> > > > have
> > > > any use cases where it would be used independent of the bus, so think
> > > > it
> > > > is
> > > > probably best to include it as additional functionality within the Bus
> > > > component.
> > > > 
> > > > Agree/disagree?
> > > > 
> > > 
> > > In terms of archicture I would suggest to follow a similar architecture
> > > discussed for metrics/alerts/inventory.
> > > 
> > > A main component with this persistence/Java API dependencies and then to
> > > a
> > > Listener/CDI/TBD (glue) project that integrate the component with the
> > > Bus,
> > > so then if needed, component could work without Bus dependencies.
> > > Perhaps we don't have an isolated use case without kettle/bus but I think
> > > that in that way we can unify the picture.
> > > 
> > 
> > That sounds reasonable - although it is slightly different to how the
> > events/alerts discussion went (I believe) where I think the suggestion was
> > that events were persisted off the bus, including Alerts being published
> > and
> > stored, rather than locally storing - possibly my misunderstanding.
> > 
> > However on reflection that would make the components more dependent upon
> > the
> > bus, so probably better to have a shared 'persistence' component, as you
> > suggest, which could be used by all of the other components to persist
> > information directly, and then use the bus to publish the data for further
> > processing.
> > 
> > In terms of Elasticsearch - this 'persistence' component could initially
> > simply wrap Cassandra and then as we understand the query requirements, add
> > (possibly optional) support for Elasticsearch to do the advanced queries.
> > 
> > Only component I am not sure about how it may use this shared 'persistence'
> > component is Inventory, as it uses Cassandra via Titan?
> > 
> 
> my points are two discuss perhaps in two layers:
> 
> - the business aspect, to map better what an Event needs to be (what not) to
> identify the business implications in terms of lifecycle, where/when is
> generated, how interacts with alerts/metrics/possible inventory as well. It
> was an interesting meeting, as I think that the Event can be also mapped
> with log entries/audit/other messages, etc. But on this layer I would like
> to get the busines concept.
> 
> - In the architecture aspect, I guess you are right, perhaps I didn't detail
> better my previous email, for example, in alerts, the architecture is to
> have a main engine that have a dependency with the cassandra cluster that
> can be shared (or not, this could be a future discussion) with metrics or
> other components, but the engine itself it has not a direct dependency with
> the bus, we add the bus dependency in an additional project, so we can have
> both alternatives: a use case where we can use the component in a standalone
> way or with the bus scenario, so it's a configuration/packaging option. My
> suggestion is that would be also interesting for EventsStore. Also, perhaps
> the ElasticSearch service can be shared as well for other components in the
> future.
> 
> Regards,
> Lucas
> 
> 
> > Regards
> > Gary
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Sun May 10 19:24:56 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sun, 10 May 2015 19:24:56 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
Message-ID: <1703191441.14263784.1431300296371.JavaMail.zimbra@redhat.com>

I briefly mentioned this in the F2F - a couple months ago I wrote an "audit" subsystem component prototype that basically does what we mentioned we want. The idea for this was it is a generic audit log - all other components would use it to log audit events (like "user failed to log in due to bad password" or "metric exceeded SLA" or whatever). We can obviously extend this to be ANY event, not just audit trails.

For sure this is gonna miss some things we need, but essentially, this "audit" subsystem is simply a way to store "events" in a backend data store. It is what you guys have been talking about in this thread (I think, unless I didn't understand).

Here's the code:

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

Just replace the word "Audit" with the word "Event" :)  Here's what it does:

1) listens to a topic - anyone can send an "Audit Record" which consists of a timestamp (when it happened), a subsystem (who it happened to), a message string (what happened), and a Map<String, String> of details (more details on what happened).

Think of a Subsystem as "Business Transaction Manager" or "Metrics" or "Alerts" or whatever we want. The Map can be anything - say, keyed on "transactionId" with the value the actual tx id. That's just an idea. We will probably extend that data structure to include more things if the above isn't enough. The point is, the "Audit Record" fully describes the event. 

Here's the AuditRecord (it is a JSON-encoded POJO): https://github.com/jmazzitelli/hawkular-audit/blob/master/hawkular-audit-api/src/main/java/org/hawkular/audit/common/AuditRecord.java

2) once the message is received, it is stored using a storage mechanism. Right now, it supports storing it in a log file (org.jboss.logging) or a RDBMS (when I was testing, I was using H2). We'll want a Cassandra implementation.

That's it. It is a very small component. It doesn't have a REST endpoint today, but we'll just add that like all our other components. It also has no notion of tenant Id, we'll need to add that too. Since this probably isn't going to be a component that must live standalone (like metrics) we won't have to play games with building two assemblies. We'll just always have a bus dependency on this component.

I was going to slap a REST endpoint on here, and rename it from "audit" to "event" but I think I'm getting sick and jetlag is killing me :) I'll try to do something this week. Unless someone wants to take what I have and run with it. 

John Mazz

From gbrown at redhat.com  Mon May 11 03:31:50 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 11 May 2015 03:31:50 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <1703191441.14263784.1431300296371.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<1703191441.14263784.1431300296371.JavaMail.zimbra@redhat.com>
Message-ID: <1641910793.14563915.1431329510284.JavaMail.zimbra@redhat.com>

Hi John

Thanks for the information - at the moment I am unclear on the requirements, so I think we need to revisit them. However if an audit approach is required this sounds like a good start.

Possibly everyone has a different understanding of what was discussed at the F2F, but my interpretation at the time was we wanted an event store for storing source and derived events, removing the need for each component to worry about storing its own. However after the discussion on this thread with Lucas and Juraci, about decisions taken in the architecture session, it seems like each component would need to maintain its own information - to allow it to be used standalone independent of the bus.

So before doing too much work on this audit component of yours, I think we need to clarify the use case.

One possibility is that this new 'audit' component could be used to persist derived events that are not retained by their source components. So for example, inventory generates notifications when changes occur.

However, metrics and alerts (I believe) persist all of their own 'derived' events - i.e. computed metrics are stored along side raw metrics, and the alerts engine will persist the generated alerts? So not sure these components will require any further events recorded.

Regards
Gary


----- Original Message -----
> I briefly mentioned this in the F2F - a couple months ago I wrote an "audit"
> subsystem component prototype that basically does what we mentioned we want.
> The idea for this was it is a generic audit log - all other components would
> use it to log audit events (like "user failed to log in due to bad password"
> or "metric exceeded SLA" or whatever). We can obviously extend this to be
> ANY event, not just audit trails.
> 
> For sure this is gonna miss some things we need, but essentially, this
> "audit" subsystem is simply a way to store "events" in a backend data store.
> It is what you guys have been talking about in this thread (I think, unless
> I didn't understand).
> 
> Here's the code:
> 
> https://github.com/jmazzitelli/hawkular-audit
> 
> Just replace the word "Audit" with the word "Event" :)  Here's what it does:
> 
> 1) listens to a topic - anyone can send an "Audit Record" which consists of a
> timestamp (when it happened), a subsystem (who it happened to), a message
> string (what happened), and a Map<String, String> of details (more details
> on what happened).
> 
> Think of a Subsystem as "Business Transaction Manager" or "Metrics" or
> "Alerts" or whatever we want. The Map can be anything - say, keyed on
> "transactionId" with the value the actual tx id. That's just an idea. We
> will probably extend that data structure to include more things if the above
> isn't enough. The point is, the "Audit Record" fully describes the event.
> 
> Here's the AuditRecord (it is a JSON-encoded POJO):
> https://github.com/jmazzitelli/hawkular-audit/blob/master/hawkular-audit-api/src/main/java/org/hawkular/audit/common/AuditRecord.java
> 
> 2) once the message is received, it is stored using a storage mechanism.
> Right now, it supports storing it in a log file (org.jboss.logging) or a
> RDBMS (when I was testing, I was using H2). We'll want a Cassandra
> implementation.
> 
> That's it. It is a very small component. It doesn't have a REST endpoint
> today, but we'll just add that like all our other components. It also has no
> notion of tenant Id, we'll need to add that too. Since this probably isn't
> going to be a component that must live standalone (like metrics) we won't
> have to play games with building two assemblies. We'll just always have a
> bus dependency on this component.
> 
> I was going to slap a REST endpoint on here, and rename it from "audit" to
> "event" but I think I'm getting sick and jetlag is killing me :) I'll try to
> do something this week. Unless someone wants to take what I have and run
> with it.
> 
> John Mazz
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From tsegismo at redhat.com  Mon May 11 04:31:19 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 11 May 2015 10:31:19 +0200
Subject: [Hawkular-dev] Event Store
In-Reply-To: <554C7E69.7080805@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<554C7E69.7080805@redhat.com>
Message-ID: <555068D7.3000901@redhat.com>

Le 08/05/2015 11:14, Juraci Paix?o Kr?hling a ?crit :
>> Although it could be provided as a separate component, I am not
>> sure we have any use cases where it would be used independent of
>> the bus, so think it is probably best to include it as additional
>> functionality within the Bus component.
>>
>> Agree/disagree?
>
> With the micro-services approach in mind, I'd vote for a separate
> component for the event-store. Such component has a potential to grow
> in scope on the long term.

+1

From ppalaga at redhat.com  Mon May 11 04:44:43 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 11 May 2015 10:44:43 +0200
Subject: [Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve
	traceability
Message-ID: <55506BFB.5050005@redhat.com>

Hi *,

citing from https://issues.jboss.org/browse/HAWKULAR-176 :

== Motivation

The proposed changes should improve the traceability of the components 
delivered with kettle. Because we use SNAPSHOTs to build kettle ATM, 
there is no way to find out which state of the individual component's 
git repos underlie the given kettle distribution.

In a situation when Luk?? has a working kettle distro and Thomas H. 
cannot succeed to build one, they can go through the SHA1 hashes listed 
in the manifest.mf files of the kettle components to find out where is 
the difference.

This proposal is not a proper solution of the problem that kettle builds 
are not reproducible. It just picks some low hanging fruits to soften 
the possible negative impact of our irreproducible builds.

== Changes

Maven should be configured in such a way that .jar, .war and *.ear files 
will have the following new entries added to their manifest.mf files:
Built-From-Git-SHA1 - the last git commit's hash
Built-On - the time when the build has started
Built-From-Git-Branch - the git branch being built from

Further, when the release profile is active, the build should fail, in 
case there are uncommitted local changes.

See https://github.com/hawkular/hawkular-parent-pom/pull/21


Best,

Peter

From hrupp at redhat.com  Mon May 11 05:39:23 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 11 May 2015 11:39:23 +0200
Subject: [Hawkular-dev] Automagic Jira state transitioning (for HAWKULAR-* )
References: <JIRA.12571119.1431098144000.18519.1431098806526@Atlassian.JIRA>
Message-ID: <46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>

Last week we were talking about auto-actions in Jira.

This has now been implemented for HAWKULAR-* on all github.com/hawkular 
repos.

See below for a transition that happened when a PR was sent.

I think for this to work, the JIRA state has to be in "Coding in 
progress" already.

   Heiko


Forwarded message:

> From: Anonymous (JIRA) <issues at jboss.org>
> To: hrupp at redhat.com
> Subject: [JBoss JIRA] (HAWKULAR-175) Include bus sample using ActiveMQ 
> virtual topics
> Date: Fri, 8 May 2015 11:26:46 -0400 (EDT)
>
>
>   [ 
> https://issues.jboss.org/browse/HAWKULAR-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
> ]
>
> Issue was automatically transitioned when Gary Brown created pull 
> request #17 in GitHub
> ---------------------------------------------------------------------------------------
>  Status: Pull Request Sent  (was: Open)
>
>
>> Include bus sample using ActiveMQ virtual topics
>> ------------------------------------------------
>>
>>              Key: HAWKULAR-175
>>              URL: https://issues.jboss.org/browse/HAWKULAR-175
>>          Project: Hawkular
>>       Issue Type: Task
>>       Components: Bus
>>         Reporter: Gary Brown
>>         Assignee: Gary Brown
>>
>> In standard JMS, for a consuming application to operate in a cluster 
>> to support load balancing and fail over it needs to consume from a 
>> queue.
>> However in some situations, the information being published to that 
>> queue would also be of use for other applications. In this scenario, 
>> it would either be necessary for the producer to know about the 
>> number of consuming apps, and send the message to an individual queue 
>> per app (which makes it difficult to dynamically add further 
>> consuming apps), or switch to using a topic, so the publisher is 
>> independent of the number of consumers (which loses the benefit of 
>> load balanced consumers, as each clustered instance of the app would 
>> perform duplicate processing of the messages).
>> ActiveMQ provides a solution using "virtual topics" where producers 
>> simply publish to a topic (and therefore don't care about the number 
>> of consumers), but the consumers use queues scoped to the application 
>> name - and therefore multiple independent apps can receive the same 
>> message, and also have multiple load balanced instances of the app on 
>> different servers in a cluster.
>> A modified version of the simple MDB sample should be provided to 
>> demonstrate use of this "virtual topic" capability using the standard 
>> JMS APIs.
>> See http://activemq.apache.org/virtual-destinations.html for further 
>> details.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)


From tsegismo at redhat.com  Mon May 11 05:51:01 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 11 May 2015 11:51:01 +0200
Subject: [Hawkular-dev] Automagic Jira state transitioning (for
 HAWKULAR-* )
In-Reply-To: <46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
References: <JIRA.12571119.1431098144000.18519.1431098806526@Atlassian.JIRA>
	<46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
Message-ID: <55507B85.1080407@redhat.com>

On the flip side: when you create the PR with a comment "not ready for 
merging" to start the discussion on Git Hub, you JIRA will go straight 
to "Coding done". Or did I miss something ?

Le 11/05/2015 11:39, Heiko W.Rupp a ?crit :
> Last week we were talking about auto-actions in Jira.
>
> This has now been implemented for HAWKULAR-* on all github.com/hawkular
> repos.
>
> See below for a transition that happened when a PR was sent.
>
> I think for this to work, the JIRA state has to be in "Coding in
> progress" already.
>
>     Heiko
>
>
> Forwarded message:
>
>> From: Anonymous (JIRA) <issues at jboss.org>
>> To: hrupp at redhat.com
>> Subject: [JBoss JIRA] (HAWKULAR-175) Include bus sample using ActiveMQ
>> virtual topics
>> Date: Fri, 8 May 2015 11:26:46 -0400 (EDT)
>>
>>
>>    [
>> https://issues.jboss.org/browse/HAWKULAR-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Issue was automatically transitioned when Gary Brown created pull
>> request #17 in GitHub
>> ---------------------------------------------------------------------------------------
>>   Status: Pull Request Sent  (was: Open)
>>
>>
>>> Include bus sample using ActiveMQ virtual topics
>>> ------------------------------------------------
>>>
>>>               Key: HAWKULAR-175
>>>               URL: https://issues.jboss.org/browse/HAWKULAR-175
>>>           Project: Hawkular
>>>        Issue Type: Task
>>>        Components: Bus
>>>          Reporter: Gary Brown
>>>          Assignee: Gary Brown
>>>
>>> In standard JMS, for a consuming application to operate in a cluster
>>> to support load balancing and fail over it needs to consume from a
>>> queue.
>>> However in some situations, the information being published to that
>>> queue would also be of use for other applications. In this scenario,
>>> it would either be necessary for the producer to know about the
>>> number of consuming apps, and send the message to an individual queue
>>> per app (which makes it difficult to dynamically add further
>>> consuming apps), or switch to using a topic, so the publisher is
>>> independent of the number of consumers (which loses the benefit of
>>> load balanced consumers, as each clustered instance of the app would
>>> perform duplicate processing of the messages).
>>> ActiveMQ provides a solution using "virtual topics" where producers
>>> simply publish to a topic (and therefore don't care about the number
>>> of consumers), but the consumers use queues scoped to the application
>>> name - and therefore multiple independent apps can receive the same
>>> message, and also have multiple load balanced instances of the app on
>>> different servers in a cluster.
>>> A modified version of the simple MDB sample should be provided to
>>> demonstrate use of this "virtual topic" capability using the standard
>>> JMS APIs.
>>> See http://activemq.apache.org/virtual-destinations.html for further
>>> details.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.15#6346)
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From gbrown at redhat.com  Mon May 11 05:59:07 2015
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 11 May 2015 05:59:07 -0400 (EDT)
Subject: [Hawkular-dev] Automagic Jira state transitioning (for
 HAWKULAR-* )
In-Reply-To: <46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
References: <JIRA.12571119.1431098144000.18519.1431098806526@Atlassian.JIRA>
	<46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
Message-ID: <284861839.14615349.1431338347208.JavaMail.zimbra@redhat.com>

Hi Heiko

With this particular PR, it was in Open state and transitioned to PR sent - so looks like it will skip Coding in Progress if necessary.

Regards
Gary

----- Original Message -----
> Last week we were talking about auto-actions in Jira.
> 
> This has now been implemented for HAWKULAR-* on all github.com/hawkular
> repos.
> 
> See below for a transition that happened when a PR was sent.
> 
> I think for this to work, the JIRA state has to be in "Coding in
> progress" already.
> 
>    Heiko
> 
> 
> Forwarded message:
> 
> > From: Anonymous (JIRA) <issues at jboss.org>
> > To: hrupp at redhat.com
> > Subject: [JBoss JIRA] (HAWKULAR-175) Include bus sample using ActiveMQ
> > virtual topics
> > Date: Fri, 8 May 2015 11:26:46 -0400 (EDT)
> >
> >
> >   [
> > https://issues.jboss.org/browse/HAWKULAR-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > ]
> >
> > Issue was automatically transitioned when Gary Brown created pull
> > request #17 in GitHub
> > ---------------------------------------------------------------------------------------
> >  Status: Pull Request Sent  (was: Open)
> >
> >
> >> Include bus sample using ActiveMQ virtual topics
> >> ------------------------------------------------
> >>
> >>              Key: HAWKULAR-175
> >>              URL: https://issues.jboss.org/browse/HAWKULAR-175
> >>          Project: Hawkular
> >>       Issue Type: Task
> >>       Components: Bus
> >>         Reporter: Gary Brown
> >>         Assignee: Gary Brown
> >>
> >> In standard JMS, for a consuming application to operate in a cluster
> >> to support load balancing and fail over it needs to consume from a
> >> queue.
> >> However in some situations, the information being published to that
> >> queue would also be of use for other applications. In this scenario,
> >> it would either be necessary for the producer to know about the
> >> number of consuming apps, and send the message to an individual queue
> >> per app (which makes it difficult to dynamically add further
> >> consuming apps), or switch to using a topic, so the publisher is
> >> independent of the number of consumers (which loses the benefit of
> >> load balanced consumers, as each clustered instance of the app would
> >> perform duplicate processing of the messages).
> >> ActiveMQ provides a solution using "virtual topics" where producers
> >> simply publish to a topic (and therefore don't care about the number
> >> of consumers), but the consumers use queues scoped to the application
> >> name - and therefore multiple independent apps can receive the same
> >> message, and also have multiple load balanced instances of the app on
> >> different servers in a cluster.
> >> A modified version of the simple MDB sample should be provided to
> >> demonstrate use of this "virtual topic" capability using the standard
> >> JMS APIs.
> >> See http://activemq.apache.org/virtual-destinations.html for further
> >> details.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Mon May 11 06:03:52 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 11 May 2015 12:03:52 +0200
Subject: [Hawkular-dev] Automagic Jira state transitioning (for
 HAWKULAR-* )
In-Reply-To: <55507B85.1080407@redhat.com>
References: <JIRA.12571119.1431098144000.18519.1431098806526@Atlassian.JIRA>
	<46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
	<55507B85.1080407@redhat.com>
Message-ID: <A71CD7AC-63ED-41FA-B165-BE8AB024C5CC@redhat.com>

On 11 May 2015, at 11:51, Thomas Segismont wrote:

> On the flip side: when you create the PR with a comment "not ready for
> merging" to start the discussion on Git Hub, you JIRA will go straight
> to "Coding done". Or did I miss something ?

This may be the current state of affairs. 
We may be able to get the magic tuned to avoid the transition with 
such a magic word.

Flip side of the flip side: if we do not to the magic, everyone
needs to manually update jira (in a timely fashion).

From hrupp at redhat.com  Mon May 11 06:31:12 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 11 May 2015 12:31:12 +0200
Subject: [Hawkular-dev] Automagic Jira state transitioning (for
 HAWKULAR-* )
In-Reply-To: <284861839.14615349.1431338347208.JavaMail.zimbra@redhat.com>
References: <JIRA.12571119.1431098144000.18519.1431098806526@Atlassian.JIRA>
	<46E7D739-5263-4B6A-BC2B-EC5218578B81@redhat.com>
	<284861839.14615349.1431338347208.JavaMail.zimbra@redhat.com>
Message-ID: <BEDB8BC4-ED3B-4DD0-A669-7F3D14B05384@redhat.com>

Gary,

On 11 May 2015, at 11:59, Gary Brown wrote:
> With this particular PR, it was in Open state and transitioned to PR 
> sent - so looks like it will skip Coding in Progress if necessary.

Good catch.
I want to nevertheless ask everyone to use the "Start progress" workflow
action when you pick an item to work on.


>>> Issue was automatically transitioned when Gary Brown created pull
>>> request #17 in GitHub
>>> ---------------------------------------------------------------------------------------
>>> Status: Pull Request Sent  (was: Open)


From tsegismo at redhat.com  Mon May 11 06:56:13 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 11 May 2015 12:56:13 +0200
Subject: [Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve
 traceability
In-Reply-To: <55506BFB.5050005@redhat.com>
References: <55506BFB.5050005@redhat.com>
Message-ID: <55508ACD.8090704@redhat.com>

Hi Peter,

I suppose the last part of the PR is not related to the recent Kettle 
issues.
To me failing the build if local changes are present sounds like a good 
idea. But we must make sure that no plugin generates files outside of 
the "target" directory. Until recently the Swagger Maven plugin was 
writing doc files to the REST project base directory, for example.

If this is true then the PR looks good to me and it can be merged.

Cheers,
Thomas

Le 11/05/2015 10:44, Peter Palaga a ?crit :
> Hi *,
>
> citing from https://issues.jboss.org/browse/HAWKULAR-176 :
>
> == Motivation
>
> The proposed changes should improve the traceability of the components
> delivered with kettle. Because we use SNAPSHOTs to build kettle ATM,
> there is no way to find out which state of the individual component's
> git repos underlie the given kettle distribution.
>
> In a situation when Luk?? has a working kettle distro and Thomas H.
> cannot succeed to build one, they can go through the SHA1 hashes listed
> in the manifest.mf files of the kettle components to find out where is
> the difference.
>
> This proposal is not a proper solution of the problem that kettle builds
> are not reproducible. It just picks some low hanging fruits to soften
> the possible negative impact of our irreproducible builds.
>
> == Changes
>
> Maven should be configured in such a way that .jar, .war and *.ear files
> will have the following new entries added to their manifest.mf files:
> Built-From-Git-SHA1 - the last git commit's hash
> Built-On - the time when the build has started
> Built-From-Git-Branch - the git branch being built from
>
> Further, when the release profile is active, the build should fail, in
> case there are uncommitted local changes.
>
> See https://github.com/hawkular/hawkular-parent-pom/pull/21
>
>
> Best,
>
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Mon May 11 08:56:20 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 11 May 2015 14:56:20 +0200
Subject: [Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve
 traceability
In-Reply-To: <55508ACD.8090704@redhat.com>
References: <55506BFB.5050005@redhat.com> <55508ACD.8090704@redhat.com>
Message-ID: <5550A6F4.8000009@redhat.com>

Hi Thomas, inline...

On 2015-05-11 12:56, Thomas Segismont wrote:
> Hi Peter,
>
> I suppose the last part of the PR is not related to the recent Kettle
> issues.
> To me failing the build if local changes are present sounds like a good
> idea.
> But we must make sure that no plugin generates files outside of
> the "target" directory. Until recently the Swagger Maven plugin was
> writing doc files to the REST project base directory, for example.

Ah, it is a good idea to check this in all hk projects. I only added 
that so that we can be sure that the sha1 in manifest mirrors 100% of 
the current project's state.

> If this is true then the PR looks good to me and it can be merged.

Thanks,

Peter

> Cheers,
> Thomas
>
> Le 11/05/2015 10:44, Peter Palaga a ?crit :
>> Hi *,
>>
>> citing from https://issues.jboss.org/browse/HAWKULAR-176 :
>>
>> == Motivation
>>
>> The proposed changes should improve the traceability of the components
>> delivered with kettle. Because we use SNAPSHOTs to build kettle ATM,
>> there is no way to find out which state of the individual component's
>> git repos underlie the given kettle distribution.
>>
>> In a situation when Luk?? has a working kettle distro and Thomas H.
>> cannot succeed to build one, they can go through the SHA1 hashes listed
>> in the manifest.mf files of the kettle components to find out where is
>> the difference.
>>
>> This proposal is not a proper solution of the problem that kettle builds
>> are not reproducible. It just picks some low hanging fruits to soften
>> the possible negative impact of our irreproducible builds.
>>
>> == Changes
>>
>> Maven should be configured in such a way that .jar, .war and *.ear files
>> will have the following new entries added to their manifest.mf files:
>> Built-From-Git-SHA1 - the last git commit's hash
>> Built-On - the time when the build has started
>> Built-From-Git-Branch - the git branch being built from
>>
>> Further, when the release profile is active, the build should fail, in
>> case there are uncommitted local changes.
>>
>> See https://github.com/hawkular/hawkular-parent-pom/pull/21
>>
>>
>> Best,
>>
>> 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 lkrejci at redhat.com  Mon May 11 13:49:29 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 11 May 2015 19:49:29 +0200
Subject: [Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve
	traceability
In-Reply-To: <55506BFB.5050005@redhat.com>
References: <55506BFB.5050005@redhat.com>
Message-ID: <6405474.OzPeGDzOkb@localhost.localdomain>

I'm not sure adding git sha's to manifests helps the situation much.

For future evidence, I agree with Thomas H. that we need reproducible builds 
and strongly versioned components.

The only disagreement we had was when to introduce them. Thomas' point for 
introducing strong versioning now is Kettle. Being the sum of the moving 
parts, it can break at random points with no traceability when using SNAPSHOTs 
of the components.

My point for not introducing strong versioning YET is that the parts are so in 
flux that introducing such formal workflow would slow the development down 
with little added benefit (the benefit being no unpredictable unrelated 
breakages in Kettle at random points in time coming from the components that 
messed up).

Of course there is a couple of questions here: 

1) is the interdependence of the individual components so great that we really 
would have to release every other day?

2) is the UI willing to work in branches for long time to track unreleased 
progress in individual components? UI, really, is the biggest concern for me, 
because it usually needs the cutting edge functionality from the components.

3) can the release process be somehow sped up so that stuff appears in some 
public maven repos soon after the release is cut? (i.e. NOT 12-24 hrs)

4) is Kettle of big interest to the community? Currently it does much LESS 
than the individual components are capable of doing. Pinger really only 
scrapes the surface in the terms of the functionality being developed across 
the board.

For me, the real question is whether we can afford 2) or solve 3). I am not 
100% convinced 1) is that big of a problem anymore (despite claiming that 
during our f2f discussions - I've thought about it more since).

Lukas

On Monday, May 11, 2015 10:44:43 Peter Palaga wrote:
> Hi *,
> 
> citing from https://issues.jboss.org/browse/HAWKULAR-176 :
> 
> == Motivation
> 
> The proposed changes should improve the traceability of the components
> delivered with kettle. Because we use SNAPSHOTs to build kettle ATM,
> there is no way to find out which state of the individual component's
> git repos underlie the given kettle distribution.
> 
> In a situation when Luk?? has a working kettle distro and Thomas H.
> cannot succeed to build one, they can go through the SHA1 hashes listed
> in the manifest.mf files of the kettle components to find out where is
> the difference.
> 
> This proposal is not a proper solution of the problem that kettle builds
> are not reproducible. It just picks some low hanging fruits to soften
> the possible negative impact of our irreproducible builds.
> 
> == Changes
> 
> Maven should be configured in such a way that .jar, .war and *.ear files
> will have the following new entries added to their manifest.mf files:
> Built-From-Git-SHA1 - the last git commit's hash
> Built-On - the time when the build has started
> Built-From-Git-Branch - the git branch being built from
> 
> Further, when the release profile is active, the build should fail, in
> case there are uncommitted local changes.
> 
> See https://github.com/hawkular/hawkular-parent-pom/pull/21
> 
> 
> Best,
> 
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From ppalaga at redhat.com  Mon May 11 16:24:40 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 11 May 2015 22:24:40 +0200
Subject: [Hawkular-dev] Adding git SHA1 & Co. to manifest.mf to improve
 traceability
In-Reply-To: <6405474.OzPeGDzOkb@localhost.localdomain>
References: <55506BFB.5050005@redhat.com>
	<6405474.OzPeGDzOkb@localhost.localdomain>
Message-ID: <55511008.10604@redhat.com>

Yes, sha1s do not solve reproducibility, they just enable basic 
traceability (what is inside of a SNAPSHOT based kettle build). They are 
fast and easy to add. That is all. -- P

On 2015-05-11 19:49, Lukas Krejci wrote:
> I'm not sure adding git sha's to manifests helps the situation much.
>
> For future evidence, I agree with Thomas H. that we need reproducible builds
> and strongly versioned components.
>
> The only disagreement we had was when to introduce them. Thomas' point for
> introducing strong versioning now is Kettle. Being the sum of the moving
> parts, it can break at random points with no traceability when using SNAPSHOTs
> of the components.
>
> My point for not introducing strong versioning YET is that the parts are so in
> flux that introducing such formal workflow would slow the development down
> with little added benefit (the benefit being no unpredictable unrelated
> breakages in Kettle at random points in time coming from the components that
> messed up).
>
> Of course there is a couple of questions here:
>
> 1) is the interdependence of the individual components so great that we really
> would have to release every other day?
>
> 2) is the UI willing to work in branches for long time to track unreleased
> progress in individual components? UI, really, is the biggest concern for me,
> because it usually needs the cutting edge functionality from the components.
>
> 3) can the release process be somehow sped up so that stuff appears in some
> public maven repos soon after the release is cut? (i.e. NOT 12-24 hrs)
>
> 4) is Kettle of big interest to the community? Currently it does much LESS
> than the individual components are capable of doing. Pinger really only
> scrapes the surface in the terms of the functionality being developed across
> the board.
>
> For me, the real question is whether we can afford 2) or solve 3). I am not
> 100% convinced 1) is that big of a problem anymore (despite claiming that
> during our f2f discussions - I've thought about it more since).
>
> Lukas
>
> On Monday, May 11, 2015 10:44:43 Peter Palaga wrote:
>> Hi *,
>>
>> citing from https://issues.jboss.org/browse/HAWKULAR-176 :
>>
>> == Motivation
>>
>> The proposed changes should improve the traceability of the components
>> delivered with kettle. Because we use SNAPSHOTs to build kettle ATM,
>> there is no way to find out which state of the individual component's
>> git repos underlie the given kettle distribution.
>>
>> In a situation when Luk?? has a working kettle distro and Thomas H.
>> cannot succeed to build one, they can go through the SHA1 hashes listed
>> in the manifest.mf files of the kettle components to find out where is
>> the difference.
>>
>> This proposal is not a proper solution of the problem that kettle builds
>> are not reproducible. It just picks some low hanging fruits to soften
>> the possible negative impact of our irreproducible builds.
>>
>> == Changes
>>
>> Maven should be configured in such a way that .jar, .war and *.ear files
>> will have the following new entries added to their manifest.mf files:
>> Built-From-Git-SHA1 - the last git commit's hash
>> Built-On - the time when the build has started
>> Built-From-Git-Branch - the git branch being built from
>>
>> Further, when the release profile is active, the build should fail, in
>> case there are uncommitted local changes.
>>
>> See https://github.com/hawkular/hawkular-parent-pom/pull/21
>>
>>
>> Best,
>>
>> 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 lkrejci at redhat.com  Mon May 11 19:14:41 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 12 May 2015 01:14:41 +0200
Subject: [Hawkular-dev] Inventory authz workflows in Hawkular SaaS
Message-ID: <2111178.yhDH2zvQbq@localhost.localdomain>

I've been scratching my head for the most part of today to come up with the 
following workflows. While there already is an implementation of the inventory 
integrated with accounts, following the f2f discussions it needs to see some 
changes.

Before implementing them though, I'd like to run the below workflows and 
assumptions through Juca in particular to correct any of the misconceptions 
about accounts that I still might have ;)

Account resources:
Each entity in inventory is represented as a "resource" in accounts. The word 
"resource" is something different here than what it is inside inventory.

Operations:
* update-tenant - checked on the actual tenant
* delete-tenant - checked on the actual tenant
* create-environment - checked on the tenant the environment should belong to
* update-environment - checked on the actual environment
* delete-environment - checked on the actual environment
* create-feed - checked on the environment the feed should belong to
* update-feed - checked on the actual feed entity
* delete-feed - checked on the actual feed entity
* ... etc. for all the rest of the inventory entity types
* relate - checked on the source inventory entity of a relationship to be 
created

Notice the absence of "read-*" privileges which are implied - each persona can 
only read its tenant and everything underneath it.

Also notice the lack of "create-tenant" - that operation doesn't make sense 
actually because each persona IS a tenant. The tenant is created by the 
inventory on the fly if needed (and yes, tenantId is going to move to the 
headers or query params in the inventory REST the same way as it did in 
metrics ;) ).

Now to the workflows:

* New user registration:
1) user created in KC
3) a tenant is created with the same ID as the user with the user set as its 
owner
4) Step 3) implies the user has the "Super User" role on the tenant

* New org registration:
1) User is registered normally
2) User creates a new organization
3) The user is set as owner of the org, having SU perms on it, the user is 
also a member of the org. This is all done implicitly by accounts.
4) New tenant with the same ID as org is created with org as its owner 
5) The above means that both the org and the user that created it have SU on 
the new tenant

* Adding org2 under org1:
1) Orgs registered normally
2) org2 added under org1 (using some accounts mechanism)
3) The above means that org1 is now the owner of org2
4) Roles are assigned on the tenant of org1 to the org2
5) The above means that org2 might NOT be SU on org1's tenant
6) Steps 4) and 5) might be repeated for any entity in the tenant of org1.
7) Note that this is entirely doable using accounts mechanisms.
8) Might require "translation" from the ID of an accounts resource to an URL 
of the "real" entity in the component's REST or in the UI.

* Adding user to an org:
1) User is registered normally
2) Org is registered normally
3) User is added to the org (using some accounts mechanism)
4) This means the user has SU on the tenant of the org (because org is SU on 
the tenant)
5) This also means that the user might not be SU on any of the org's sub-orgs.

* Assigning operations to roles:
1) This is entirely in accounts. Each component defines a set of operations 
that can be invoked. The operations then can be added to roles. This also puts 
constraints on the possible names of the operations (i.e. they should probably 
be prefixed by the component name).

* Listing tenants:
1) No-one has the "full picture"
2) Listing tenants is equivalent to listing the user along with the orgs 
they're member of (singular "they" to be politically correct - don't you love 
English? ;) ).
3) Operations on the individual tenants depend on the roles the user has on 
the corresponding orgs.

K, to not make this email even longer, I'll stop here. Does the above sound 
reasonable? What can be simplified or staged to later versions? What is/is not 
supported in the current accounts impl and UI?

Cheers,

Lukas


From tsegismo at redhat.com  Tue May 12 03:41:54 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 12 May 2015 09:41:54 +0200
Subject: [Hawkular-dev] Hawkular, individual components and snapshots
In-Reply-To: <6405474.OzPeGDzOkb@localhost.localdomain>
References: <55506BFB.5050005@redhat.com>
	<6405474.OzPeGDzOkb@localhost.localdomain>
Message-ID: <5551AEC2.3060707@redhat.com>

Peter has answered in the original thread about the goal of his PR so 
I'll focus on your questions.

Le 11/05/2015 19:49, Lukas Krejci a ?crit :
> 1) is the interdependence of the individual components so great that we really
> would have to release every other day?
>

There's no Hawkular without the individual components. So when new 
capabilities are added to Hawkular, there are good chances that a good 
part should be implemented in Metrics/Alerts/Inventory first.

Then why is it a problem to release every day? Aren't we talking about 
continuous delivery all the time? If it's difficult to release an 
individual component in a few minutes then there's an issue, and it 
should be fixed.

> 2) is the UI willing to work in branches for long time to track unreleased
> progress in individual components? UI, really, is the biggest concern for me,
> because it usually needs the cutting edge functionality from the components.
>

UI isn't an individual component. It's part (the most humanly visible 
one!) of Hawkular. And Hawkular relies on the individual components, so 
yes, very often enhancing Hawkular implies enhancing the individual 
components.

Being agile does not mean zero planning. I can't see why we couldn't, as 
an example, select a few Metrics JIRA needed for the coming Hawkular 
developments(UI or not) and plan a micro release.

> 3) can the release process be somehow sped up so that stuff appears in some
> public maven repos soon after the release is cut? (i.e. NOT 12-24 hrs)
>

The JBoss releases repo is public. Artifacts can be downloaded from 
there after the release process completes.

> 4) is Kettle of big interest to the community? Currently it does much LESS
> than the individual components are capable of doing. Pinger really only
> scrapes the surface in the terms of the functionality being developed across
> the board.

The Kettle *IS* Hawkular. I believe the naming does not help to see that 
it shouldn't be just a container where we throw in all the individual 
components. It's our primary project.

The Pinger implements the goals we've assigned to the first milestones. 
It could very well disappear tomorrow (to reborn in a new or existing 
module of course).

Metrics, Alerts and Inventory are not RHQ's successor. Hawkular is.

>
> For me, the real question is whether we can afford 2) or solve 3). I am not
> 100% convinced 1) is that big of a problem anymore (despite claiming that
> during our f2f discussions - I've thought about it more since).

From theute at redhat.com  Tue May 12 04:23:40 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 10:23:40 +0200
Subject: [Hawkular-dev] Hawkular, individual components and snapshots
In-Reply-To: <5551AEC2.3060707@redhat.com>
References: <55506BFB.5050005@redhat.com>	<6405474.OzPeGDzOkb@localhost.localdomain>
	<5551AEC2.3060707@redhat.com>
Message-ID: <5551B88C.2020803@redhat.com>



On 05/12/2015 09:41 AM, Thomas Segismont wrote:

>
>> 4) is Kettle of big interest to the community? Currently it does much LESS
>> than the individual components are capable of doing. Pinger really only
>> scrapes the surface in the terms of the functionality being developed across
>> the board.
>
> The Kettle *IS* Hawkular. I believe the naming does not help to see that
> it shouldn't be just a container where we throw in all the individual
> components. It's our primary project.

+gazillion

Thomas

From hrupp at redhat.com  Tue May 12 04:48:50 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 12 May 2015 10:48:50 +0200
Subject: [Hawkular-dev] Hawkular, individual components and snapshots
In-Reply-To: <5551AEC2.3060707@redhat.com>
References: <55506BFB.5050005@redhat.com>
	<6405474.OzPeGDzOkb@localhost.localdomain>
	<5551AEC2.3060707@redhat.com>
Message-ID: <13476E89-5AFB-4666-8953-0CFA563CE789@redhat.com>

On 12 May 2015, at 9:41, Thomas Segismont wrote:

> continuous delivery all the time? If it's difficult to release an
> individual component in a few minutes then there's an issue, and it
> should be fixed.

I am currently investigating it. And it seems like the 
Nexus + Nexus team can help us there. Stay tuned :)

From lkrejci at redhat.com  Tue May 12 05:31:06 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 12 May 2015 11:31:06 +0200
Subject: [Hawkular-dev] Hawkular, individual components and snapshots
In-Reply-To: <13476E89-5AFB-4666-8953-0CFA563CE789@redhat.com>
References: <55506BFB.5050005@redhat.com> <5551AEC2.3060707@redhat.com>
	<13476E89-5AFB-4666-8953-0CFA563CE789@redhat.com>
Message-ID: <1744216.CCMrb3a9FM@localhost.localdomain>

On Tuesday, May 12, 2015 10:48:50 Heiko W.Rupp wrote:
> On 12 May 2015, at 9:41, Thomas Segismont wrote:
> > continuous delivery all the time? If it's difficult to release an
> > individual component in a few minutes then there's an issue, and it
> > should be fixed.
> 
> I am currently investigating it. And it seems like the
> Nexus + Nexus team can help us there. Stay tuned :)

As I said in my orig email - if we can release quickly, I think we actually 
should :)

I have seen JBoss Nexus taking the 12-24hrs I mentioned in my original email 
to publish the artifacts, which I think is a show-stopper for CD and inter-
component coordination by releases, so I am really looking forward to what 
Heiko comes back with.

Remember that we went from the original 1.0.0-SNAPSHOT to 0.0.1-SNAPSHOT 
because the problems of components breaking Kettle are real and having 
versioned snapshots helps in that regard, it just does not provide 
traceability of the builds, which leaves the Kettle still "vulnerable".

If we can publish releases as quickly as publish SNAPSHOTs I'm all for doing 
them. We would get rid of the untraceable builds, which would be great.

So I think we're in a violent agreement with Thomas S ;)

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


From jpkroehling at redhat.com  Tue May 12 05:34:21 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 12 May 2015 11:34:21 +0200
Subject: [Hawkular-dev] Inventory authz workflows in Hawkular SaaS
In-Reply-To: <2111178.yhDH2zvQbq@localhost.localdomain>
References: <2111178.yhDH2zvQbq@localhost.localdomain>
Message-ID: <5551C91D.7030303@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/12/2015 01:14 AM, Lukas Krejci wrote:
> Account resources: Each entity in inventory is represented as a
> "resource" in accounts. The word "resource" is something different
> here than what it is inside inventory.

Correct. If the name is not appropriate, I'm accepting suggestions :-)

> * New org registration: 1) User is registered normally 2) User
> creates a new organization 3) The user is set as owner of the org,
> having SU perms on it, the user is also a member of the org. This
> is all done implicitly by accounts. 4) New tenant with the same ID
> as org is created with org as its owner

I assume you mean a tenant on the inventory side.

> 5) The above means that both the org and the user that created it
> have SU on the new tenant

Same as above. But correct, if you mean "tenant" on the inventory side.

> * Adding org2 under org1:

On the F2F, we agreed on removing this capability from the UI on a
first step, to avoid unnecessary complexity. I'd suggest to also not
support such scenario *now* on inventory. Let's see where it leads us
and refactor appropriately once we have this actual need, instead of
spending a lot of time implementing a feature that would benefit only
a limited number of cases.

> * Adding user to an org: 1) User is registered normally 2) Org is
> registered normally 3) User is added to the org (using some
> accounts mechanism) 4) This means the user has SU on the tenant of
> the org (because org is SU on the tenant)

If I understand this flow correctly, you mean that an existing user
account is added to an existing organization, which is owned by a
third user. If so, your assumption is then incorrect.

Case: jdoe creates an org called "Acme, Inc" and invites user jsmith
to the organization. During this invitation process, jdoe assigns the
role "Monitor" to jsmith.

> 5) This also means that the user might not be SU on any of the
> org's sub-orgs.

Invalid, as we are removing sub-orgs.

> * Assigning operations to roles: 1) This is entirely in accounts.
> Each component defines a set of operations that can be invoked. The
> operations then can be added to roles. This also puts constraints
> on the possible names of the operations (i.e. they should probably
>  be prefixed by the component name).

Sort of. This is done by the component, using Account's API.
Basically, you have to tell accounts what are your operations and
which roles are allowed for each operation. More details here:

https://github.com/hawkular/hawkular-accounts#operations-and-roles

Sample code:

http://git.io/vUzub

*How* you implement this is up to you, but I'd suggest to do it as a
ServletContextListener , so that we can control the order of the
initializers on Kettle via web.xml.

> * Listing tenants: 1) No-one has the "full picture"

I assume you mean: "list of all tenants". If so, you are right.

> 2) Listing tenants is equivalent to listing the user along with the
> orgs they're member of (singular "they" to be politically correct -
> don't you love English? ;) ).

Correct.

> 3) Operations on the individual tenants depend on the roles the
> user has on the corresponding orgs.

Correct.

> K, to not make this email even longer, I'll stop here. Does the
> above sound reasonable? What can be simplified or staged to later
> versions? What is/is not supported in the current accounts impl and
> UI?

Pretty much all of the above is already implemented in the current
accounts code. On the UI, it's very limited, as we need some UXD love.

I tried to document as much as I could at several levels: a bigger
picture can be read on both the readme files and on the website. The
specific "contracts" can be checked on the javadocs. And future
features/existing bugs are in JIRA :)

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

iQEcBAEBCAAGBQJVUckdAAoJECKM1e+fkPrXt8wH/0n+XOgvKltpRYXCNnjbvqFh
V/0CUmQYG4fSIYElMNth0m3ktPJI19Kxh6SZj1Pw7JKs6wD6ZvjuikeUy1ALpDS7
94zstCO7AmzAdrUgUw8/T3svP/lWmuOUR3xiCsOW+3pKHAgnX3YInFclKSZnNlF1
TI47zFlSSdJ6neuyt+nn41nNqVfwkeRD9/oMbK+R2b5f0w4IHYpZu9iKRAnbG0Ks
GwPCWj0ICkgTL0MZUd4vjC6RTJ2xjlvtgqS2cLtM6YHRwoivoZTYHvX+JGg5zwQI
r7wFEXIh0zZyiJ2Liccb7DJVNElFln9zyZqyfQro7couKNWhtOwzJ2zHdQBKS2g=
=KDmX
-----END PGP SIGNATURE-----

From hrupp at redhat.com  Tue May 12 05:51:49 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 12 May 2015 11:51:49 +0200
Subject: [Hawkular-dev] Event Store
In-Reply-To: <577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
Message-ID: <C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>

On 9 May 2015, at 18:33, Gary Brown wrote:
> I think we probably need to revisit the use cases for the event store

Yes, please start with this. A good number of the previous messages 
dealt with
implementation details of a sub use case.

We may have several types of the (abstract) "Event" like
- Audit record
- Fired Alert
- BTM call results
- remote syslog
- ...

that all have their specific details. With a header field in the Bus 
messages
we can differentiate them later for further processing.

We need some degree of separation here, as e.g. Audit records are 
append-only.
The user should not be able via normal means to delete (individual) 
records, while
for other types, we may care less.
Also for Audit records I see a need to persist them to some external 
storage before
expiring them, which may not be true for other types.

Within the Hawkular family of projects, I also think, this should be a 
new separate
(logical) component, that may even use the common C* store as Inventory, 
Metrics and
Alerts already do.
We should nevertheless not merge it into the others, as the requirements 
are much
different.

From lkrejci at redhat.com  Tue May 12 05:53:25 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 12 May 2015 11:53:25 +0200
Subject: [Hawkular-dev] Hawkular, individual components and snapshots
In-Reply-To: <5551B88C.2020803@redhat.com>
References: <55506BFB.5050005@redhat.com> <5551AEC2.3060707@redhat.com>
	<5551B88C.2020803@redhat.com>
Message-ID: <55070229.ToJMunQS9J@localhost.localdomain>

On Tuesday, May 12, 2015 10:23:40 Thomas Heute wrote:
> On 05/12/2015 09:41 AM, Thomas Segismont wrote:
> >> 4) is Kettle of big interest to the community? Currently it does much
> >> LESS
> >> than the individual components are capable of doing. Pinger really only
> >> scrapes the surface in the terms of the functionality being developed
> >> across the board.
> > 
> > The Kettle *IS* Hawkular. I believe the naming does not help to see that
> > it shouldn't be just a container where we throw in all the individual
> > components. It's our primary project.
> 
> +gazillion
> 

Hawkular is our ONLY project actually ;)

I think I phrased the question wrongly - IMHO, Kettle or Hawkular as a whole 
might not be of that much of an interest to the community NOW simply because 
of the fact that it is not much more than a codified hand-waving *at the 
moment*. UI is actually being done to last but the integration "layer" and 
pinger certainly aren't (again, this is the situation *at the moment* - we're 
working hard to change that).

If I was an external contributor wanting to contribute in the Hawkular I'd run 
away if I needed to update the pinger or the way the components are integrated 
at this moment. It is all a hack right now (again, we're working hard to 
change that - we're just not there yet).

But if I was an external contributor trying to make sure one of the Hawkular 
components did what I wanted, I can do that now - those things are now at a 
much more stable place already.

So that's what I meant by community being currently maybe more interested in 
the components than Hawkular itself. It's not that Hawkular is somehow less 
important, it's just that it requires large foundations that are not yet there 
to even start to resemble its true form.

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


From theute at redhat.com  Tue May 12 07:26:41 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 13:26:41 +0200
Subject: [Hawkular-dev] Packaging
Message-ID: <5551E371.7070107@redhat.com>



	I would prefer if the whole WF packaging/layering would happen in 
Hawkular rather than with multiple layers of packaging as it is today.

	So far I have done 2 things:
		1 - Basically renamed Kettle to Hawkular (+ few extras). kettle 
directory is now 'dist' which should be more intuitive.
	 
https://github.com/theute/hawkular/commit/e2b937b467e4ed8c184b51add5af7b50175bd549 

		2 - Bring the nest distro build from Bus to Hawkular:
	 
https://github.com/theute/hawkular/commit/84ed6f505a5db73ecf9264c1bc8dea3d314649e0
		I understand that there could still be need for the nest (I think 
Alert uses it for testing) but I find the double customization of WF 
quite complex.

My next items unless I am stopped:
		- Fix the docker build as I guess I broke it
		- do more proper WF layering (not use 'modules/base')
		- understand "hawkular-nest-wf-extension" ;)
		- upgrade to WF9
		- update the docs

Thomas


From gbrown at redhat.com  Tue May 12 07:33:41 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 12 May 2015 07:33:41 -0400 (EDT)
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E371.7070107@redhat.com>
References: <5551E371.7070107@redhat.com>
Message-ID: <625469178.15307345.1431430421617.JavaMail.zimbra@redhat.com>

Hi

At present I'm looking to layer BTM on top of Kettle, as it is a client of the components but not currently going to be bundled as part of Kettle as I currently understand.

So BTM will have its own distribution that repackages Kettle+BTM. Is that ok?

Regards
Gary

----- Original Message -----
> 
> 
> 	I would prefer if the whole WF packaging/layering would happen in
> Hawkular rather than with multiple layers of packaging as it is today.
> 
> 	So far I have done 2 things:
> 		1 - Basically renamed Kettle to Hawkular (+ few extras). kettle
> directory is now 'dist' which should be more intuitive.
> 	 
> https://github.com/theute/hawkular/commit/e2b937b467e4ed8c184b51add5af7b50175bd549
> 
> 		2 - Bring the nest distro build from Bus to Hawkular:
> 	 
> https://github.com/theute/hawkular/commit/84ed6f505a5db73ecf9264c1bc8dea3d314649e0
> 		I understand that there could still be need for the nest (I think
> Alert uses it for testing) but I find the double customization of WF
> quite complex.
> 
> My next items unless I am stopped:
> 		- Fix the docker build as I guess I broke it
> 		- do more proper WF layering (not use 'modules/base')
> 		- understand "hawkular-nest-wf-extension" ;)
> 		- upgrade to WF9
> 		- update the docs
> 
> Thomas
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Tue May 12 07:48:30 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 12 May 2015 13:48:30 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E371.7070107@redhat.com>
References: <5551E371.7070107@redhat.com>
Message-ID: <5551E88E.4020400@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/12/2015 01:26 PM, Thomas Heute wrote:
> - upgrade to WF9

Can you assign this specific one to me? I have to update Keycloak to
CR1 so that our themes work and I'm not sure it's compatible with WF 9
yet. If it's not, it should be fixed very soon, as I think WF9 is a
target for them too.

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVUeiOAAoJECKM1e+fkPrXs3UH/RwBbeHK6jXc8m3ap3P3rk+b
WsFgoYiqgy52ZBYeUe+Cse/DaDBPtIlqdORWZ/ICuWenDtLZNdWIan7hGwur2iqd
9Nzu6Kt28c8mSorngIPUlAKzQBzrc7lNCTAZ5TMBh+5h6VhE1rC1uxg0ohQN8+0Q
2TrzvxJZn/DF3L/2G6DIqNCY8O+Q3gxEkTSisCEpoWUNoyJily1SRzzRRXSXxXVN
YiZ4XfsQ1F/VrN+laHpFyJCz8SqyYRbSF2LuG0va3+idYZVO3By2w5HlHfQvfBob
eT3ZJHRS7twNVneegirXmg28QSTSYCVAM/oV/Mastttf04BGUwdQ1MI5KsCHj3c=
=IZhw
-----END PGP SIGNATURE-----

From theute at redhat.com  Tue May 12 07:48:37 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 13:48:37 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <625469178.15307345.1431430421617.JavaMail.zimbra@redhat.com>
References: <5551E371.7070107@redhat.com>
	<625469178.15307345.1431430421617.JavaMail.zimbra@redhat.com>
Message-ID: <5551E895.1080802@redhat.com>



On 05/12/2015 01:33 PM, Gary Brown wrote:
> Hi
>
> At present I'm looking to layer BTM on top of Kettle, as it is a client of the components but not currently going to be bundled as part of Kettle as I currently understand.
> So BTM will have its own distribution that repackages Kettle+BTM. Is that ok?

I think BTM should be part of Hawkular (/Kettle)

Thomas

>
> Regards
> Gary
>
> ----- Original Message -----
>>
>>
>> 	I would prefer if the whole WF packaging/layering would happen in
>> Hawkular rather than with multiple layers of packaging as it is today.
>>
>> 	So far I have done 2 things:
>> 		1 - Basically renamed Kettle to Hawkular (+ few extras). kettle
>> directory is now 'dist' which should be more intuitive.
>> 	
>> https://github.com/theute/hawkular/commit/e2b937b467e4ed8c184b51add5af7b50175bd549
>>
>> 		2 - Bring the nest distro build from Bus to Hawkular:
>> 	
>> https://github.com/theute/hawkular/commit/84ed6f505a5db73ecf9264c1bc8dea3d314649e0
>> 		I understand that there could still be need for the nest (I think
>> Alert uses it for testing) but I find the double customization of WF
>> quite complex.
>>
>> My next items unless I am stopped:
>> 		- Fix the docker build as I guess I broke it
>> 		- do more proper WF layering (not use 'modules/base')
>> 		- understand "hawkular-nest-wf-extension" ;)
>> 		- upgrade to WF9
>> 		- update the docs
>>
>> 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 gbrown at redhat.com  Tue May 12 08:00:19 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 12 May 2015 08:00:19 -0400 (EDT)
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E895.1080802@redhat.com>
References: <5551E371.7070107@redhat.com>
	<625469178.15307345.1431430421617.JavaMail.zimbra@redhat.com>
	<5551E895.1080802@redhat.com>
Message-ID: <1755692444.15313350.1431432019332.JavaMail.zimbra@redhat.com>

Result of follow-up conversation on IRC - BTM will become part of Kettle once it has a reasonable level of functionality, but until then will built a local distro that simply layers BTM on top of kettle. This should make it simple to integrate BTM into Kettle at the appropriate time.

Regards
Gary

----- Original Message -----
> 
> 
> On 05/12/2015 01:33 PM, Gary Brown wrote:
> > Hi
> >
> > At present I'm looking to layer BTM on top of Kettle, as it is a client of
> > the components but not currently going to be bundled as part of Kettle as
> > I currently understand.
> > So BTM will have its own distribution that repackages Kettle+BTM. Is that
> > ok?
> 
> I think BTM should be part of Hawkular (/Kettle)
> 
> Thomas
> 
> >
> > Regards
> > Gary
> >
> > ----- Original Message -----
> >>
> >>
> >> 	I would prefer if the whole WF packaging/layering would happen in
> >> Hawkular rather than with multiple layers of packaging as it is today.
> >>
> >> 	So far I have done 2 things:
> >> 		1 - Basically renamed Kettle to Hawkular (+ few extras). kettle
> >> directory is now 'dist' which should be more intuitive.
> >> 	
> >> https://github.com/theute/hawkular/commit/e2b937b467e4ed8c184b51add5af7b50175bd549
> >>
> >> 		2 - Bring the nest distro build from Bus to Hawkular:
> >> 	
> >> https://github.com/theute/hawkular/commit/84ed6f505a5db73ecf9264c1bc8dea3d314649e0
> >> 		I understand that there could still be need for the nest (I think
> >> Alert uses it for testing) but I find the double customization of WF
> >> quite complex.
> >>
> >> My next items unless I am stopped:
> >> 		- Fix the docker build as I guess I broke it
> >> 		- do more proper WF layering (not use 'modules/base')
> >> 		- understand "hawkular-nest-wf-extension" ;)
> >> 		- upgrade to WF9
> >> 		- update the docs
> >>
> >> 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 theute at redhat.com  Tue May 12 08:31:31 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 14:31:31 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E371.7070107@redhat.com>
References: <5551E371.7070107@redhat.com>
Message-ID: <5551F2A3.6060707@redhat.com>



On 05/12/2015 01:26 PM, Thomas Heute wrote:
> 		- do more proper WF layering (not use 'modules/base')

Until someone understand WF layering (seems different from AS7), I moved 
our customization to modules rather than modules/system/layers/base

Hawkular is a layered project but doesn't really call for further 
customization so using "modules" may be just fine (unlike GateIn or SOA-P)

Thomas

From theute at redhat.com  Tue May 12 08:34:09 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 14:34:09 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E88E.4020400@redhat.com>
References: <5551E371.7070107@redhat.com> <5551E88E.4020400@redhat.com>
Message-ID: <5551F341.8080005@redhat.com>



On 05/12/2015 01:48 PM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/12/2015 01:26 PM, Thomas Heute wrote:
>> - upgrade to WF9
>
> Can you assign this specific one to me? I have to update Keycloak to
> CR1 so that our themes work and I'm not sure it's compatible with WF 9
> yet. If it's not, it should be fixed very soon, as I think WF9 is a
> target for them too.

Ok, indeed last time I tried KC was a problem on WF9.

I expect my proposal to be somehow controversial ;) (it duplicates nest 
so it's not perfect). Let's see if we agree on that change, but 
upgrading hawkular to WF9 (and keeping this updated) would be easier if 
all the customization happen in a single repo.

Thomas


>
> - - Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVUeiOAAoJECKM1e+fkPrXs3UH/RwBbeHK6jXc8m3ap3P3rk+b
> WsFgoYiqgy52ZBYeUe+Cse/DaDBPtIlqdORWZ/ICuWenDtLZNdWIan7hGwur2iqd
> 9Nzu6Kt28c8mSorngIPUlAKzQBzrc7lNCTAZ5TMBh+5h6VhE1rC1uxg0ohQN8+0Q
> 2TrzvxJZn/DF3L/2G6DIqNCY8O+Q3gxEkTSisCEpoWUNoyJily1SRzzRRXSXxXVN
> YiZ4XfsQ1F/VrN+laHpFyJCz8SqyYRbSF2LuG0va3+idYZVO3By2w5HlHfQvfBob
> eT3ZJHRS7twNVneegirXmg28QSTSYCVAM/oV/Mastttf04BGUwdQ1MI5KsCHj3c=
> =IZhw
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From theute at redhat.com  Tue May 12 08:34:32 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 14:34:32 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551F2A3.6060707@redhat.com>
References: <5551E371.7070107@redhat.com> <5551F2A3.6060707@redhat.com>
Message-ID: <5551F358.7020604@redhat.com>



On 05/12/2015 02:31 PM, Thomas Heute wrote:
>
>
> On 05/12/2015 01:26 PM, Thomas Heute wrote:
>> 		- do more proper WF layering (not use 'modules/base')
>
> Until someone understand WF layering (seems different from AS7), I moved
> our customization to modules rather than modules/system/layers/base

https://github.com/theute/hawkular/commit/943932a9d224e6706abc1f015ac31e33efb49139


> Hawkular is a layered project but doesn't really call for further
> customization so using "modules" may be just fine (unlike GateIn or SOA-P)
>
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From tsegismo at redhat.com  Tue May 12 08:36:56 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 12 May 2015 14:36:56 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
Message-ID: <5551F3E8.9020507@redhat.com>

 From IETF:
===
3.  Recommendations for Creators of New Parameters

    Creators of new parameters to be used in the context of application
    protocols:

    1.  SHOULD assume that all parameters they create might become
        standardized, public, commonly deployed, or usable across
        multiple implementations.

    2.  SHOULD employ meaningful parameter names that they have reason to
        believe are currently unused.

    3.  SHOULD NOT prefix their parameter names with "X-" or similar
        constructs.

    Note: If the relevant parameter name space has conventions about
    associating parameter names with those who create them, a parameter
    name could incorporate the organization's name or primary domain name
    (see Appendix B for examples).
===
http://tools.ietf.org/html/rfc6648#section-3

So the header should be something like "Hawkular-Tenant". And shared 
across the individual components.

I'll file a Metrics JIRA unless someone has a strong objection or better 
name.

Le 28/04/2015 17:44, Stefan Negrea a ?crit :
> Hello Everybody,
>
> I've been working on a PR for the upcoming Hawkular Metrics release that will remove the tenant id from the end-point URLs. The tenant id will be moved to either a header parameter or a query parameter. The query parameter is in place for cases (such as curl) where setting a header is not possible, difficult, or inconvenient.
>
> Here is an example of the change:
>
> Existing URL:
> /{tenantId}/gauge/{metricId}/data
>
> New URL:
> /gauge/{metricId}/data
>
> Tenant id set via:
> 1) header - tenantId
> 2) query parameter - tenantId
>
>
> There are two exceptions to this rule, /tenants and /db/{tenantid}/series. The /tenants end-point will be changed into something different in the upcoming releases since it is mostly a management type API that does not belong in the same place with the regular metrics endpoint. And /db/{tenantid}/series end-point is needed in this exact format for compatibility with Influxdb compatible services.
>
>
> Now, to the merits of this change. The tenant id is volatile, can change any time, and changes to it should be expected; but the rest of the URL is fixed. The second issue is that the tenant id is a security concern. So we were limited in design choices since a security concern was leaking as part of the URL.
>
> So removing the tenant id from the URL will give us permanent & consistent addresses for resources (metrics and metric data points). And we will gain a lot of flexibility on the security side. In the future, users could authenticate with a user/pass combo and the backend would transform that into a tenant id to be used on the request. If the same user later decides to use a tenant id to pass along the request, the URL of the resources would not change. Another expectation is that tenant id is not sufficient, it is typically a combo of id + secret; so we would have resorted to a header or query param for the second piece of information (the secret).
>
> This change will give us the flexibility to adjust the security model (the meaning of tenant ids and ways to validate them) without compromising the URL structure. This will help Hawkular Metrics as it gets integrated into more and more projects and products.
>
> Here are the links to the JIRA and the PR for this change:
> https://github.com/hawkular/hawkular-metrics/pull/202
> https://issues.jboss.org/browse/HWKMETRICS-68
>
>
>
> Thank you,
> Stefan Negrea
>
> Software Engineer
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From hrupp at redhat.com  Tue May 12 09:02:14 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 12 May 2015 15:02:14 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5551F3E8.9020507@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
Message-ID: <727399A5-7090-4CE4-994B-49C921477C2C@redhat.com>

> So the header should be something like "Hawkular-Tenant". And shared
> across the individual components.

+2

From jpkroehling at redhat.com  Tue May 12 09:04:32 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 12 May 2015 15:04:32 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5551F3E8.9020507@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
Message-ID: <5551FA60.7080906@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/12/2015 02:36 PM, Thomas Segismont wrote:
> http://tools.ietf.org/html/rfc6648#section-3
> 
> So the header should be something like "Hawkular-Tenant". And
> shared across the individual components.

Thanks for bringing this up! I have a similar X-Hawkular-Persona for
usage inside accounts and it seems I should also remove the X prefix.

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

iQEcBAEBCAAGBQJVUfpgAAoJECKM1e+fkPrXoz8IAIwaW5x9SgFawUkJCiHbREIt
EWNMdZguMg1eItfTpUNNfEis8HBnTJ/e1cUhk8ORuSUdH70thUJM7iZBk6fYrTEe
dPsspOuacky16x/EEiWORWVwIfT5watsHJjEtI/2c+du4iJ5cJ/hG7uB+PVzONTd
UfyjBpgeLO+eOS93HWlr/EvtyWLE0TONyBf2x7mMJ/w3HzPGW/AyX/AN2FSUTIJa
Khm9pB8lqRDRGpqVWrJPAZj0F7tcRNisRQM+itgVG1cFC6wtFslYFxdhMz2HJdhZ
OV8wqT75K/BDTYHT8+4ktY3BENLAgiLbVurBQLDLjH1+PKeDFi/11sDWoB5zANc=
=WIAd
-----END PGP SIGNATURE-----

From snegrea at redhat.com  Tue May 12 09:05:30 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 12 May 2015 09:05:30 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5551F3E8.9020507@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
Message-ID: <99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>


Good proposal, just make sure it is carried over to the query parameter alternative too.


----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, May 12, 2015 7:36:56 AM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> From IETF:
> ===
> 3.  Recommendations for Creators of New Parameters
> 
>     Creators of new parameters to be used in the context of application
>     protocols:
> 
>     1.  SHOULD assume that all parameters they create might become
>         standardized, public, commonly deployed, or usable across
>         multiple implementations.
> 
>     2.  SHOULD employ meaningful parameter names that they have reason to
>         believe are currently unused.
> 
>     3.  SHOULD NOT prefix their parameter names with "X-" or similar
>         constructs.
> 
>     Note: If the relevant parameter name space has conventions about
>     associating parameter names with those who create them, a parameter
>     name could incorporate the organization's name or primary domain name
>     (see Appendix B for examples).
> ===
> http://tools.ietf.org/html/rfc6648#section-3
> 
> So the header should be something like "Hawkular-Tenant". And shared
> across the individual components.
> 
> I'll file a Metrics JIRA unless someone has a strong objection or better
> name.
> 
> Le 28/04/2015 17:44, Stefan Negrea a ?crit :
> > Hello Everybody,
> >
> > I've been working on a PR for the upcoming Hawkular Metrics release that
> > will remove the tenant id from the end-point URLs. The tenant id will be
> > moved to either a header parameter or a query parameter. The query
> > parameter is in place for cases (such as curl) where setting a header is
> > not possible, difficult, or inconvenient.
> >
> > Here is an example of the change:
> >
> > Existing URL:
> > /{tenantId}/gauge/{metricId}/data
> >
> > New URL:
> > /gauge/{metricId}/data
> >
> > Tenant id set via:
> > 1) header - tenantId
> > 2) query parameter - tenantId
> >
> >
> > There are two exceptions to this rule, /tenants and /db/{tenantid}/series.
> > The /tenants end-point will be changed into something different in the
> > upcoming releases since it is mostly a management type API that does not
> > belong in the same place with the regular metrics endpoint. And
> > /db/{tenantid}/series end-point is needed in this exact format for
> > compatibility with Influxdb compatible services.
> >
> >
> > Now, to the merits of this change. The tenant id is volatile, can change
> > any time, and changes to it should be expected; but the rest of the URL is
> > fixed. The second issue is that the tenant id is a security concern. So we
> > were limited in design choices since a security concern was leaking as
> > part of the URL.
> >
> > So removing the tenant id from the URL will give us permanent & consistent
> > addresses for resources (metrics and metric data points). And we will gain
> > a lot of flexibility on the security side. In the future, users could
> > authenticate with a user/pass combo and the backend would transform that
> > into a tenant id to be used on the request. If the same user later decides
> > to use a tenant id to pass along the request, the URL of the resources
> > would not change. Another expectation is that tenant id is not sufficient,
> > it is typically a combo of id + secret; so we would have resorted to a
> > header or query param for the second piece of information (the secret).
> >
> > This change will give us the flexibility to adjust the security model (the
> > meaning of tenant ids and ways to validate them) without compromising the
> > URL structure. This will help Hawkular Metrics as it gets integrated into
> > more and more projects and products.
> >
> > Here are the links to the JIRA and the PR for this change:
> > https://github.com/hawkular/hawkular-metrics/pull/202
> > https://issues.jboss.org/browse/HWKMETRICS-68
> >
> >
> >
> > Thank you,
> > Stefan Negrea
> >
> > Software Engineer
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From mazz at redhat.com  Tue May 12 09:07:40 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 12 May 2015 09:07:40 -0400 (EDT)
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551E371.7070107@redhat.com>
References: <5551E371.7070107@redhat.com>
Message-ID: <1975205884.15417452.1431436060588.JavaMail.zimbra@redhat.com>

> 		2 - Bring the nest distro build from Bus to Hawkular:

IIRC, I left some stuff in the mvn  poms for the nest so it should be easy to move it. I had envisioned we would eventually move that out of the bus repo. That's what this comment is trying to convey:

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-nest/pom.xml#L81L86

From tsegismo at redhat.com  Tue May 12 09:08:36 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 12 May 2015 15:08:36 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>
	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
Message-ID: <5551FB54.7000408@redhat.com>

You mean use _hawkularTenant_ instead of the _tenant_ query param? That 
makes less sense to me.

Le 12/05/2015 15:05, Stefan Negrea a ?crit :
>
> Good proposal, just make sure it is carried over to the query parameter alternative too.
>
>
> ----- Original Message -----
>> From: "Thomas Segismont" <tsegismo at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Tuesday, May 12, 2015 7:36:56 AM
>> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
>>
>>  From IETF:
>> ===
>> 3.  Recommendations for Creators of New Parameters
>>
>>      Creators of new parameters to be used in the context of application
>>      protocols:
>>
>>      1.  SHOULD assume that all parameters they create might become
>>          standardized, public, commonly deployed, or usable across
>>          multiple implementations.
>>
>>      2.  SHOULD employ meaningful parameter names that they have reason to
>>          believe are currently unused.
>>
>>      3.  SHOULD NOT prefix their parameter names with "X-" or similar
>>          constructs.
>>
>>      Note: If the relevant parameter name space has conventions about
>>      associating parameter names with those who create them, a parameter
>>      name could incorporate the organization's name or primary domain name
>>      (see Appendix B for examples).
>> ===
>> http://tools.ietf.org/html/rfc6648#section-3
>>
>> So the header should be something like "Hawkular-Tenant". And shared
>> across the individual components.
>>
>> I'll file a Metrics JIRA unless someone has a strong objection or better
>> name.
>>
>> Le 28/04/2015 17:44, Stefan Negrea a ?crit :
>>> Hello Everybody,
>>>
>>> I've been working on a PR for the upcoming Hawkular Metrics release that
>>> will remove the tenant id from the end-point URLs. The tenant id will be
>>> moved to either a header parameter or a query parameter. The query
>>> parameter is in place for cases (such as curl) where setting a header is
>>> not possible, difficult, or inconvenient.
>>>
>>> Here is an example of the change:
>>>
>>> Existing URL:
>>> /{tenantId}/gauge/{metricId}/data
>>>
>>> New URL:
>>> /gauge/{metricId}/data
>>>
>>> Tenant id set via:
>>> 1) header - tenantId
>>> 2) query parameter - tenantId
>>>
>>>
>>> There are two exceptions to this rule, /tenants and /db/{tenantid}/series.
>>> The /tenants end-point will be changed into something different in the
>>> upcoming releases since it is mostly a management type API that does not
>>> belong in the same place with the regular metrics endpoint. And
>>> /db/{tenantid}/series end-point is needed in this exact format for
>>> compatibility with Influxdb compatible services.
>>>
>>>
>>> Now, to the merits of this change. The tenant id is volatile, can change
>>> any time, and changes to it should be expected; but the rest of the URL is
>>> fixed. The second issue is that the tenant id is a security concern. So we
>>> were limited in design choices since a security concern was leaking as
>>> part of the URL.
>>>
>>> So removing the tenant id from the URL will give us permanent & consistent
>>> addresses for resources (metrics and metric data points). And we will gain
>>> a lot of flexibility on the security side. In the future, users could
>>> authenticate with a user/pass combo and the backend would transform that
>>> into a tenant id to be used on the request. If the same user later decides
>>> to use a tenant id to pass along the request, the URL of the resources
>>> would not change. Another expectation is that tenant id is not sufficient,
>>> it is typically a combo of id + secret; so we would have resorted to a
>>> header or query param for the second piece of information (the secret).
>>>
>>> This change will give us the flexibility to adjust the security model (the
>>> meaning of tenant ids and ways to validate them) without compromising the
>>> URL structure. This will help Hawkular Metrics as it gets integrated into
>>> more and more projects and products.
>>>
>>> Here are the links to the JIRA and the PR for this change:
>>> https://github.com/hawkular/hawkular-metrics/pull/202
>>> https://issues.jboss.org/browse/HWKMETRICS-68
>>>
>>>
>>>
>>> Thank you,
>>> Stefan Negrea
>>>
>>> Software Engineer
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From snegrea at redhat.com  Tue May 12 09:17:34 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Tue, 12 May 2015 09:17:34 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5551FB54.7000408@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
	<5551FB54.7000408@redhat.com>
Message-ID: <501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, May 12, 2015 8:08:36 AM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> You mean use _hawkularTenant_ instead of the _tenant_ query param? That
> makes less sense to me.

I would use an identical query parameter so consumers that do not want/have the option to use headers can just append an identical query parameter. The hyphen is not reserved, therefore it can be used as part of the query parameter name or value without encoding. Correct me if I am wrong about the hyphen.

http://tools.ietf.org/html/rfc3986#section-2.3


> 
> Le 12/05/2015 15:05, Stefan Negrea a ?crit :
> >
> > Good proposal, just make sure it is carried over to the query parameter
> > alternative too.
> >
> >
> > ----- Original Message -----
> >> From: "Thomas Segismont" <tsegismo at redhat.com>
> >> To: hawkular-dev at lists.jboss.org
> >> Sent: Tuesday, May 12, 2015 7:36:56 AM
> >> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> >>
> >>  From IETF:
> >> ===
> >> 3.  Recommendations for Creators of New Parameters
> >>
> >>      Creators of new parameters to be used in the context of application
> >>      protocols:
> >>
> >>      1.  SHOULD assume that all parameters they create might become
> >>          standardized, public, commonly deployed, or usable across
> >>          multiple implementations.
> >>
> >>      2.  SHOULD employ meaningful parameter names that they have reason to
> >>          believe are currently unused.
> >>
> >>      3.  SHOULD NOT prefix their parameter names with "X-" or similar
> >>          constructs.
> >>
> >>      Note: If the relevant parameter name space has conventions about
> >>      associating parameter names with those who create them, a parameter
> >>      name could incorporate the organization's name or primary domain name
> >>      (see Appendix B for examples).
> >> ===
> >> http://tools.ietf.org/html/rfc6648#section-3
> >>
> >> So the header should be something like "Hawkular-Tenant". And shared
> >> across the individual components.
> >>
> >> I'll file a Metrics JIRA unless someone has a strong objection or better
> >> name.
> >>
> >> Le 28/04/2015 17:44, Stefan Negrea a ?crit :
> >>> Hello Everybody,
> >>>
> >>> I've been working on a PR for the upcoming Hawkular Metrics release that
> >>> will remove the tenant id from the end-point URLs. The tenant id will be
> >>> moved to either a header parameter or a query parameter. The query
> >>> parameter is in place for cases (such as curl) where setting a header is
> >>> not possible, difficult, or inconvenient.
> >>>
> >>> Here is an example of the change:
> >>>
> >>> Existing URL:
> >>> /{tenantId}/gauge/{metricId}/data
> >>>
> >>> New URL:
> >>> /gauge/{metricId}/data
> >>>
> >>> Tenant id set via:
> >>> 1) header - tenantId
> >>> 2) query parameter - tenantId
> >>>
> >>>
> >>> There are two exceptions to this rule, /tenants and
> >>> /db/{tenantid}/series.
> >>> The /tenants end-point will be changed into something different in the
> >>> upcoming releases since it is mostly a management type API that does not
> >>> belong in the same place with the regular metrics endpoint. And
> >>> /db/{tenantid}/series end-point is needed in this exact format for
> >>> compatibility with Influxdb compatible services.
> >>>
> >>>
> >>> Now, to the merits of this change. The tenant id is volatile, can change
> >>> any time, and changes to it should be expected; but the rest of the URL
> >>> is
> >>> fixed. The second issue is that the tenant id is a security concern. So
> >>> we
> >>> were limited in design choices since a security concern was leaking as
> >>> part of the URL.
> >>>
> >>> So removing the tenant id from the URL will give us permanent &
> >>> consistent
> >>> addresses for resources (metrics and metric data points). And we will
> >>> gain
> >>> a lot of flexibility on the security side. In the future, users could
> >>> authenticate with a user/pass combo and the backend would transform that
> >>> into a tenant id to be used on the request. If the same user later
> >>> decides
> >>> to use a tenant id to pass along the request, the URL of the resources
> >>> would not change. Another expectation is that tenant id is not
> >>> sufficient,
> >>> it is typically a combo of id + secret; so we would have resorted to a
> >>> header or query param for the second piece of information (the secret).
> >>>
> >>> This change will give us the flexibility to adjust the security model
> >>> (the
> >>> meaning of tenant ids and ways to validate them) without compromising the
> >>> URL structure. This will help Hawkular Metrics as it gets integrated into
> >>> more and more projects and products.
> >>>
> >>> Here are the links to the JIRA and the PR for this change:
> >>> https://github.com/hawkular/hawkular-metrics/pull/202
> >>> https://issues.jboss.org/browse/HWKMETRICS-68
> >>>
> >>>
> >>>
> >>> Thank you,
> >>> Stefan Negrea
> >>>
> >>> Software Engineer
> >>>
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>
> >>
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From hrupp at redhat.com  Tue May 12 09:49:24 2015
From: hrupp at redhat.com (hrupp at redhat.com)
Date: Tue, 12 May 2015 13:49:24 +0000
Subject: [Hawkular-dev] =?iso-8859-1?q?Aktualisierte_Einladung=3A_Hawkular?=
	=?iso-8859-1?q?-Team_Update_-_W=F6chentlich_von_3=3A30PM_bis_4PM_a?=
	=?iso-8859-1?q?m_Dienstag_=28hrupp=40redhat=2Ecom=29?=
Message-ID: <001a11c2f70e292b500515e2c3f9@google.com>

Dieser Termin wurde ge?ndert.

Titel: Hawkular-Team Update
This is a all-Hawkular team meeting to give updates where we are and so on.

This is *open to the public*.

Location:
on bluejeans:  https://redhat.bluejeans.com/hrupp/

or alternatively teleconference Reservationless+ , passcode 204 2160 481

You can find Dial-In telephone numbers here:  
https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481

RedHat internal short dial numbers are 16666 and 15555 (and probably  
others, depends on your location) (ge?ndert)
Wann: W?chentlich von 3:30PM bis 4PM am Dienstag Berlin (ge?ndert)
Wo: pc 204 2160 481
Kalender: hrupp at redhat.com
Wer
     * Heiko Rupp - Organisator
     * miburman at redhat.com
     * tsegismo at redhat.com
     * hawkular-dev at lists.jboss.org
     * gbrown at redhat.com
     * lkrejci at redhat.com
     * snegrea at redhat.com
     * jcosta at redhat.com
     * theute at redhat.com
     * amendonc at redhat.com

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

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

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

Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem  
Termin zu erhalten. Sie k?nnen auch unter https://www.google.com/calendar/  
ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen f?r  
Ihren gesamten Kalender steuern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/51f9cb09/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 3245 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/51f9cb09/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 3317 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/51f9cb09/attachment-0003.bin 

From hrupp at redhat.com  Tue May 12 09:49:24 2015
From: hrupp at redhat.com (hrupp at redhat.com)
Date: Tue, 12 May 2015 13:49:24 +0000
Subject: [Hawkular-dev] =?iso-8859-1?q?Aktualisierte_Einladung=3A_Hawkular?=
	=?iso-8859-1?q?-Team_Update_-_W=F6chentlich_von_3=3A30PM_bis_4PM_a?=
	=?iso-8859-1?q?m_Dienstag_=28hrupp=40redhat=2Ecom=29?=
Message-ID: <047d7b3a989e29bd950515e2c32e@google.com>

Dieser Termin wurde ge?ndert.

Titel: Hawkular-Team Update
This is a all-Hawkular team meeting to give updates where we are and so on.

This is *open to the public*.

Location: teleconference Reservationless+ , passcode 204 2160 481

You can find Dial-In telephone numbers here:  
https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481

RedHat internal short dial numbers are 16666 and 15555 (and probably  
others, depends on your location)
Wann: W?chentlich von 3:30PM bis 4PM am Dienstag Berlin
Wo: pc 204 2160 481
Kalender: hrupp at redhat.com
Wer
     * Heiko Rupp - Organisator
     * miburman at redhat.com
     * tsegismo at redhat.com
     * hawkular-dev at lists.jboss.org
     * gbrown at redhat.com
     * lkrejci at redhat.com
     * snegrea at redhat.com
     * jcosta at redhat.com
     * theute at redhat.com
     * amendonc at redhat.com

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

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

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

Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem  
Termin zu erhalten. Sie k?nnen auch unter https://www.google.com/calendar/  
ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen f?r  
Ihren gesamten Kalender steuern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/0cd0e246/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 3116 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/0cd0e246/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 3185 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/0cd0e246/attachment-0001.bin 

From gbrown at redhat.com  Tue May 12 09:56:55 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 12 May 2015 09:56:55 -0400 (EDT)
Subject: [Hawkular-dev] Event Store - triggering alerts
In-Reply-To: <C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
	<C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>
Message-ID: <1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>

First item I wanted to discuss: regardless of the event types we are capturing and storing, we will want to use some of them purely for audit/historical analysis purposes but others will need to be applied to the alerts engine to detect situations of interest.

I believe currently the alerts engine does not subscribe to the bus for events, so events need to be supplied to the alerts engine explicitly?

Do we want the alerts engine to have that capability? i.e. as part of the trigger definition, we offer the ability to define a bus topic/queue/selector to feed the alert engine?

Or should the "event store" allow a listener to be defined (in the glue) that could supply events to the alert engine - but then this slightly separates the alert definition into two parts - the bit bridging the event store and alert engine, and the trigger definition on how the event should be processed.

Thoughts?

Regards
Gary

From theute at redhat.com  Tue May 12 10:25:58 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 12 May 2015 16:25:58 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <5551F341.8080005@redhat.com>
References: <5551E371.7070107@redhat.com> <5551E88E.4020400@redhat.com>
	<5551F341.8080005@redhat.com>
Message-ID: <55520D76.9050808@redhat.com>

By the way, Hawkular Bus and Agent will need an update as well, they 
don't work with WF9

Thomas

On 05/12/2015 02:34 PM, Thomas Heute wrote:
>
>
> On 05/12/2015 01:48 PM, Juraci Paix?o Kr?hling wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 05/12/2015 01:26 PM, Thomas Heute wrote:
>>> - upgrade to WF9
>>
>> Can you assign this specific one to me? I have to update Keycloak to
>> CR1 so that our themes work and I'm not sure it's compatible with WF 9
>> yet. If it's not, it should be fixed very soon, as I think WF9 is a
>> target for them too.
>
> Ok, indeed last time I tried KC was a problem on WF9.
>
> I expect my proposal to be somehow controversial ;) (it duplicates nest
> so it's not perfect). Let's see if we agree on that change, but
> upgrading hawkular to WF9 (and keeping this updated) would be easier if
> all the customization happen in a single repo.
>
> Thomas
>
>
>>
>> - - Juca.
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJVUeiOAAoJECKM1e+fkPrXs3UH/RwBbeHK6jXc8m3ap3P3rk+b
>> WsFgoYiqgy52ZBYeUe+Cse/DaDBPtIlqdORWZ/ICuWenDtLZNdWIan7hGwur2iqd
>> 9Nzu6Kt28c8mSorngIPUlAKzQBzrc7lNCTAZ5TMBh+5h6VhE1rC1uxg0ohQN8+0Q
>> 2TrzvxJZn/DF3L/2G6DIqNCY8O+Q3gxEkTSisCEpoWUNoyJily1SRzzRRXSXxXVN
>> YiZ4XfsQ1F/VrN+laHpFyJCz8SqyYRbSF2LuG0va3+idYZVO3By2w5HlHfQvfBob
>> eT3ZJHRS7twNVneegirXmg28QSTSYCVAM/oV/Mastttf04BGUwdQ1MI5KsCHj3c=
>> =IZhw
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From lponce at redhat.com  Tue May 12 11:43:50 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Tue, 12 May 2015 11:43:50 -0400 (EDT)
Subject: [Hawkular-dev] Event Store - triggering alerts
In-Reply-To: <1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
	<C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>
	<1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>
Message-ID: <2139220321.15582752.1431445430408.JavaMail.zimbra@redhat.com>

Hi Gary,

> 
> I believe currently the alerts engine does not subscribe to the bus for
> events, so events need to be supplied to the alerts engine explicitly?
> 

Today, alerts component listens from the bus for data alerts.

Also, these data is "filtered" from metrics, in the meaning that not "all" data coming from metrics is insteresting for alerts, so in the "glue" we have a component to filter from one topic and put the data that is consumed for alerts.

I guess that for Events we can do a similar approach.


> Do we want the alerts engine to have that capability? i.e. as part of the
> trigger definition, we offer the ability to define a bus
> topic/queue/selector to feed the alert engine?
> 

The trigger definition is more generic, it doesn't matter from alerts domain from which "source" a data is provided.

The data model that alerts engine is expecting is here:

https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data  

Perhaps, we can add more data types if needed for inference processes.

> Or should the "event store" allow a listener to be defined (in the glue) that
> could supply events to the alert engine - but then this slightly separates
> the alert definition into two parts - the bit bridging the event store and
> alert engine, and the trigger definition on how the event should be
> processed.
> 

I'm +1 to separate the bus integration layer aspect from the pure alerts inference.

Today, we have the same separation and the "glue" code lives here:

https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus

As we identified a "filtering" preliminar tasks that is not part of inference itself. 

In the other hand, having this separation we can maintain or goal to have an scenario with metrics+alerts and without bus dependencies.

Regards,
Lucas

From gbrown at redhat.com  Tue May 12 11:50:26 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 12 May 2015 11:50:26 -0400 (EDT)
Subject: [Hawkular-dev] Event Store - triggering alerts
In-Reply-To: <2139220321.15582752.1431445430408.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
	<C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>
	<1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>
	<2139220321.15582752.1431445430408.JavaMail.zimbra@redhat.com>
Message-ID: <1566057092.15482762.1431445826980.JavaMail.zimbra@redhat.com>

Hi Lucas

I'd just started looking at hawkular-alerts-bus :)

Just wondering how complex the configuration may become in the glue, if it is used to wire up the components but also potentially has to apply filters - but we can see what is possible.

Regards
Gary

----- Original Message -----
> Hi Gary,
> 
> > 
> > I believe currently the alerts engine does not subscribe to the bus for
> > events, so events need to be supplied to the alerts engine explicitly?
> > 
> 
> Today, alerts component listens from the bus for data alerts.
> 
> Also, these data is "filtered" from metrics, in the meaning that not "all"
> data coming from metrics is insteresting for alerts, so in the "glue" we
> have a component to filter from one topic and put the data that is consumed
> for alerts.
> 
> I guess that for Events we can do a similar approach.
> 
> 
> > Do we want the alerts engine to have that capability? i.e. as part of the
> > trigger definition, we offer the ability to define a bus
> > topic/queue/selector to feed the alert engine?
> > 
> 
> The trigger definition is more generic, it doesn't matter from alerts domain
> from which "source" a data is provided.
> 
> The data model that alerts engine is expecting is here:
> 
> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data
> 
> Perhaps, we can add more data types if needed for inference processes.
> 
> > Or should the "event store" allow a listener to be defined (in the glue)
> > that
> > could supply events to the alert engine - but then this slightly separates
> > the alert definition into two parts - the bit bridging the event store and
> > alert engine, and the trigger definition on how the event should be
> > processed.
> > 
> 
> I'm +1 to separate the bus integration layer aspect from the pure alerts
> inference.
> 
> Today, we have the same separation and the "glue" code lives here:
> 
> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus
> 
> As we identified a "filtering" preliminar tasks that is not part of inference
> itself.
> 
> In the other hand, having this separation we can maintain or goal to have an
> scenario with metrics+alerts and without bus dependencies.
> 
> Regards,
> Lucas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From tsegismo at redhat.com  Tue May 12 13:45:38 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 12 May 2015 19:45:38 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>
	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
Message-ID: <55523C42.6010607@redhat.com>

Le 12/05/2015 15:17, Stefan Negrea a ?crit :
>
> ----- Original Message -----
>> >From: "Thomas Segismont"<tsegismo at redhat.com>
>> >To:hawkular-dev at lists.jboss.org
>> >Sent: Tuesday, May 12, 2015 8:08:36 AM
>> >Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
>> >
>> >You mean use_hawkularTenant_  instead of the_tenant_  query param? That
>> >makes less sense to me.
> I would use an identical query parameter so consumers that do not want/have the option to use headers can just append an identical query parameter. The hyphen is not reserved, therefore it can be used as part of the query parameter name or value without encoding. Correct me if I am wrong about the hyphen.
>
> http://tools.ietf.org/html/rfc3986#section-2.3
>
>

Please do not switch from top to bottom posting, or I might start to get 
sick :p

Yes, "Hawkular-Tenant" is valid, but I'd prefer to pick something short 
("tenant") for the query parameter fallback.

In fact, I'd prefer to have short names for all out-of-band query 
parameters, like "pretty" to get a formatted JSON output.

From jshaughn at redhat.com  Tue May 12 14:43:56 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 12 May 2015 14:43:56 -0400
Subject: [Hawkular-dev] Branch Kettle?
Message-ID: <555249EC.8050508@redhat.com>


Related to the "Adding git SHA1 & Co. to manifest.mf to improve 
traceability" thread...

In the interim between now and when we move to strong versioning could 
we perhaps just create a "stable" branch for kettle?  Note the term 
"stable" as opposed to "release" or something like that.  This idea was 
kicked around at the F2F as a possible solution.

The stable branch would have poms updated with non-snapshot versions of 
the components and so would be reproducible.  It could be used for demos 
without fear of snapshot regression.  It could be used by QE for 
test-case development and [non-release] qualification. Kettle itself 
could be versioned, bumping it's version whenever a consumed component 
version was updated.

Components would be required to make at least an initial release to get 
things going, and then should make subsequent releases at relatively 
short intervals, maybe every few weeks.

Will this work and be helpful?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150512/2be61329/attachment.html 

From mazz at redhat.com  Tue May 12 15:20:16 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 12 May 2015 15:20:16 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
Message-ID: <1065702806.15703034.1431458416794.JavaMail.zimbra@redhat.com>

As per the watercooler call today, I renamed my prototype to "Events" ... take a look. Consider this a proposal for a starting point for an events component.

Git clone this:

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

and "mvn clean install" from the top (the default branch is "events" - that's the one you want, not master)

Go to hawkular-events-distro/target, unzip the distro, and run wildfly*/bin/standalone.sh

At this point, the events component is running as a standalone component in wildfly (remember this was a prototype written a while ago - its essentially a mini-kettle with just the bus and events components).

Read the README for how you can send test events and look them up:

https://github.com/jmazzitelli/hawkular-events/blob/events/README.adoc

You'll notice the API jar is a separate artifact. All our other components that get deployed in the kettle can use the hawkular-events-api jar to send events. That API jar has this: https://github.com/jmazzitelli/hawkular-events/tree/events/hawkular-events-api/src/main/java/org/hawkular/events/common ... EventRecord is the domain object that you send (it is based on the bus framework, so its got full JSON support and can be used in the bus framework's listener APIs - which is why my MDBs are so small) - you send via the EventRecordProcessor (or a subclass if you wish to enhance it). Here's a couple of lines of code as an example that sends events (this is how the events test servlet sends events - essentially its how any component would do it) : https://github.com/jmazzitelli/hawkular-events/blob/events/hawkular-events-war/src/main/java/org/hawkular/events/EventsInsertServlet.java#L98L100

The events war just has some MDBs (aka bus listeners) and servlets (servlets are there mainly to test with). But the idea is that we have bus listeners for potentially different kinds of events, or listening to events over different queues (which is what I do here - LogOnlyEventsMDB takes events and logs them only - EventsMDB stores them in the backend datasource, currently just H2).

Note that there is no REST interface (as I understand it, the events component is only for internal consumption - only kettle components will be using it - feeds will not be sending in events - so no need for REST AFAICS).

Note the backend storage is RDBMS (H2) - we'd just have to implement a listener that stores to C*. Essentially do what this does: https://github.com/jmazzitelli/hawkular-events/blob/events/hawkular-events-api/src/main/java/org/hawkular/events/consumer/DataSourceConsumer.java

So, its a standalone component. It utilizes the hawkular bus framework. It provides an independent API jar that other kettle components can use in order to send events to the events component via the bus.


From jshaughn at redhat.com  Tue May 12 16:10:56 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 12 May 2015 16:10:56 -0400
Subject: [Hawkular-dev] Event Store - triggering alerts
In-Reply-To: <1566057092.15482762.1431445826980.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>	<C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>	<1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>	<2139220321.15582752.1431445430408.JavaMail.zimbra@redhat.com>
	<1566057092.15482762.1431445826980.JavaMail.zimbra@redhat.com>
Message-ID: <55525E50.4010002@redhat.com>


Hi Gary,

Probably restating much of the below...  Alerts does integrate with the 
bus and listens on three topics.  Two of which are specific to 
integrating with Hawkular Metrics, and one is relevant only to bus 
integration.  Hawkular feeds will supply numeric and availability 
metrics and those will be published to the HawkularMetricData and 
HawkularAvailabilityData topics.  H Alerts subscribes to them both. 
Because only a small subset of data persisted in metrics will be 
relevant to alerting (only those involved in defined trigger 
conditions), alerts filters out the irrelevant data in the listener 
code.  It then translates the filtered metric data into the format 
suitable to alerts and forwards it for alert evaluation (via the Java 
API).  Additionally, data can be published to the bus HawkularAlertData 
topic, and that data goes straight into alert processing, currently 
without filtering, although that may change.

So, Events data could be published and picked up via the bus today by 
sending to the HawkularAlertData topic.   Of course there is also a rest 
endpoint for sending in data.  Alerting currently supports 3 types of 
"primitive" data: numeric, availability and string, which are used in 
the various condition types.

But more likely we'd want something like you suggest, something 
analogous to the listener we have on HawkularMetricData, add a listener 
for published events, filter them as needed, and forward relevant events 
for evaluation.  One question, I guess, is whether alerting on events 
requires a dedicated type, and dedicated condition types in alerting, or 
whether the current "primitives" are sufficient.

For example, in RHQ, alerting on logging events could involve match on 
log level, the logfile path, and/or the actual log entry text. We don't 
have support for that kind of condition evaluation today in alerting.  
We'd rather have to distill it down to a single string datum and a regex 
test, for example.

 >  Do we want the alerts engine to have that capability? i.e. as part 
of the trigger definition, we offer the ability to define a bus 
topic/queue/selector to feed the alert engine?

So, I don't think we want to incorporate data sources/streams into our 
trigger definitions but rather, as Lucas says, insulate the engine and 
keep it cleanly separated from the bus.  Keeping the 
reception/filtering/translating of event data in the hawkular (i.e. 
glue) code.

Regards,
Jay


On 5/12/2015 11:50 AM, Gary Brown wrote:
> Hi Lucas
>
> I'd just started looking at hawkular-alerts-bus :)
>
> Just wondering how complex the configuration may become in the glue, if it is used to wire up the components but also potentially has to apply filters - but we can see what is possible.
>
> Regards
> Gary
>
> ----- Original Message -----
>> Hi Gary,
>>
>>> I believe currently the alerts engine does not subscribe to the bus for
>>> events, so events need to be supplied to the alerts engine explicitly?
>>>
>> Today, alerts component listens from the bus for data alerts.
>>
>> Also, these data is "filtered" from metrics, in the meaning that not "all"
>> data coming from metrics is insteresting for alerts, so in the "glue" we
>> have a component to filter from one topic and put the data that is consumed
>> for alerts.
>>
>> I guess that for Events we can do a similar approach.
>>
>>
>>> Do we want the alerts engine to have that capability? i.e. as part of the
>>> trigger definition, we offer the ability to define a bus
>>> topic/queue/selector to feed the alert engine?
>>>
>> The trigger definition is more generic, it doesn't matter from alerts domain
>> from which "source" a data is provided.
>>
>> The data model that alerts engine is expecting is here:
>>
>> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data
>>
>> Perhaps, we can add more data types if needed for inference processes.
>>
>>> Or should the "event store" allow a listener to be defined (in the glue)
>>> that
>>> could supply events to the alert engine - but then this slightly separates
>>> the alert definition into two parts - the bit bridging the event store and
>>> alert engine, and the trigger definition on how the event should be
>>> processed.
>>>
>> I'm +1 to separate the bus integration layer aspect from the pure alerts
>> inference.
>>
>> Today, we have the same separation and the "glue" code lives here:
>>
>> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus
>>
>> As we identified a "filtering" preliminar tasks that is not part of inference
>> itself.
>>
>> In the other hand, having this separation we can maintain or goal to have an
>> scenario with metrics+alerts and without bus dependencies.
>>
>> Regards,
>> Lucas
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>



From gbrown at redhat.com  Wed May 13 03:33:04 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 03:33:04 -0400 (EDT)
Subject: [Hawkular-dev] Event Store
In-Reply-To: <1065702806.15703034.1431458416794.JavaMail.zimbra@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<1627554616.13423613.1431076130413.JavaMail.zimbra@redhat.com>
	<1820831922.14104433.1431081037586.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<1065702806.15703034.1431458416794.JavaMail.zimbra@redhat.com>
Message-ID: <236149420.15800533.1431502384317.JavaMail.zimbra@redhat.com>

Hi Mazz

This looks like a very good start. I need to delve into the code before commenting in detail, but

- I guess the only other backend mdb (other than log-only and events) would be one that passes the events to alerts engine

- Will all events of a particular type (e.g. log records) be presented to the Alerts engine, or would we need some configurable filter that determines what events should be passed on?

- Capturing logs is one of the categories I believe we are interested in (possibly via Logstash etc) - so wouldn't this be done via a feed, probably from the agent? So a REST API may be required


Regards
Gary

----- Original Message -----
> As per the watercooler call today, I renamed my prototype to "Events" ...
> take a look. Consider this a proposal for a starting point for an events
> component.
> 
> Git clone this:
> 
> https://github.com/jmazzitelli/hawkular-events
> 
> and "mvn clean install" from the top (the default branch is "events" - that's
> the one you want, not master)
> 
> Go to hawkular-events-distro/target, unzip the distro, and run
> wildfly*/bin/standalone.sh
> 
> At this point, the events component is running as a standalone component in
> wildfly (remember this was a prototype written a while ago - its essentially
> a mini-kettle with just the bus and events components).
> 
> Read the README for how you can send test events and look them up:
> 
> https://github.com/jmazzitelli/hawkular-events/blob/events/README.adoc
> 
> You'll notice the API jar is a separate artifact. All our other components
> that get deployed in the kettle can use the hawkular-events-api jar to send
> events. That API jar has this:
> https://github.com/jmazzitelli/hawkular-events/tree/events/hawkular-events-api/src/main/java/org/hawkular/events/common
> ... EventRecord is the domain object that you send (it is based on the bus
> framework, so its got full JSON support and can be used in the bus
> framework's listener APIs - which is why my MDBs are so small) - you send
> via the EventRecordProcessor (or a subclass if you wish to enhance it).
> Here's a couple of lines of code as an example that sends events (this is
> how the events test servlet sends events - essentially its how any component
> would do it) :
> https://github.com/jmazzitelli/hawkular-events/blob/events/hawkular-events-war/src/main/java/org/hawkular/events/EventsInsertServlet.java#L98L100
> 
> The events war just has some MDBs (aka bus listeners) and servlets (servlets
> are there mainly to test with). But the idea is that we have bus listeners
> for potentially different kinds of events, or listening to events over
> different queues (which is what I do here - LogOnlyEventsMDB takes events
> and logs them only - EventsMDB stores them in the backend datasource,
> currently just H2).
> 
> Note that there is no REST interface (as I understand it, the events
> component is only for internal consumption - only kettle components will be
> using it - feeds will not be sending in events - so no need for REST
> AFAICS).
> 
> Note the backend storage is RDBMS (H2) - we'd just have to implement a
> listener that stores to C*. Essentially do what this does:
> https://github.com/jmazzitelli/hawkular-events/blob/events/hawkular-events-api/src/main/java/org/hawkular/events/consumer/DataSourceConsumer.java
> 
> So, its a standalone component. It utilizes the hawkular bus framework. It
> provides an independent API jar that other kettle components can use in
> order to send events to the events component via the bus.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Wed May 13 03:40:17 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 03:40:17 -0400 (EDT)
Subject: [Hawkular-dev] Event Store - triggering alerts
In-Reply-To: <55525E50.4010002@redhat.com>
References: <536710904.14058710.1431075472224.JavaMail.zimbra@redhat.com>
	<424941717.13455837.1431083906890.JavaMail.zimbra@redhat.com>
	<577432616.14451200.1431189206370.JavaMail.zimbra@redhat.com>
	<C39FD768-C1B3-474E-8FF2-B4018ADD3946@redhat.com>
	<1930949717.15376819.1431439015278.JavaMail.zimbra@redhat.com>
	<2139220321.15582752.1431445430408.JavaMail.zimbra@redhat.com>
	<1566057092.15482762.1431445826980.JavaMail.zimbra@redhat.com>
	<55525E50.4010002@redhat.com>
Message-ID: <1242927249.15802122.1431502817323.JavaMail.zimbra@redhat.com>

Hi Jay

Thanks for the detailed explanation.

>From a BTM perspective, we will mainly be dealing with json on the bus, so its likely users would want to evaluate individual fields within the json structure. So string evaluation is ok for now, but I think we should plan for supporting more complex condition evaluation in the future.

Regards
Gary

----- Original Message -----
> 
> Hi Gary,
> 
> Probably restating much of the below...  Alerts does integrate with the
> bus and listens on three topics.  Two of which are specific to
> integrating with Hawkular Metrics, and one is relevant only to bus
> integration.  Hawkular feeds will supply numeric and availability
> metrics and those will be published to the HawkularMetricData and
> HawkularAvailabilityData topics.  H Alerts subscribes to them both.
> Because only a small subset of data persisted in metrics will be
> relevant to alerting (only those involved in defined trigger
> conditions), alerts filters out the irrelevant data in the listener
> code.  It then translates the filtered metric data into the format
> suitable to alerts and forwards it for alert evaluation (via the Java
> API).  Additionally, data can be published to the bus HawkularAlertData
> topic, and that data goes straight into alert processing, currently
> without filtering, although that may change.
> 
> So, Events data could be published and picked up via the bus today by
> sending to the HawkularAlertData topic.   Of course there is also a rest
> endpoint for sending in data.  Alerting currently supports 3 types of
> "primitive" data: numeric, availability and string, which are used in
> the various condition types.
> 
> But more likely we'd want something like you suggest, something
> analogous to the listener we have on HawkularMetricData, add a listener
> for published events, filter them as needed, and forward relevant events
> for evaluation.  One question, I guess, is whether alerting on events
> requires a dedicated type, and dedicated condition types in alerting, or
> whether the current "primitives" are sufficient.
> 
> For example, in RHQ, alerting on logging events could involve match on
> log level, the logfile path, and/or the actual log entry text. We don't
> have support for that kind of condition evaluation today in alerting.
> We'd rather have to distill it down to a single string datum and a regex
> test, for example.
> 
>  >  Do we want the alerts engine to have that capability? i.e. as part
> of the trigger definition, we offer the ability to define a bus
> topic/queue/selector to feed the alert engine?
> 
> So, I don't think we want to incorporate data sources/streams into our
> trigger definitions but rather, as Lucas says, insulate the engine and
> keep it cleanly separated from the bus.  Keeping the
> reception/filtering/translating of event data in the hawkular (i.e.
> glue) code.
> 
> Regards,
> Jay
> 
> 
> On 5/12/2015 11:50 AM, Gary Brown wrote:
> > Hi Lucas
> >
> > I'd just started looking at hawkular-alerts-bus :)
> >
> > Just wondering how complex the configuration may become in the glue, if it
> > is used to wire up the components but also potentially has to apply
> > filters - but we can see what is possible.
> >
> > Regards
> > Gary
> >
> > ----- Original Message -----
> >> Hi Gary,
> >>
> >>> I believe currently the alerts engine does not subscribe to the bus for
> >>> events, so events need to be supplied to the alerts engine explicitly?
> >>>
> >> Today, alerts component listens from the bus for data alerts.
> >>
> >> Also, these data is "filtered" from metrics, in the meaning that not "all"
> >> data coming from metrics is insteresting for alerts, so in the "glue" we
> >> have a component to filter from one topic and put the data that is
> >> consumed
> >> for alerts.
> >>
> >> I guess that for Events we can do a similar approach.
> >>
> >>
> >>> Do we want the alerts engine to have that capability? i.e. as part of the
> >>> trigger definition, we offer the ability to define a bus
> >>> topic/queue/selector to feed the alert engine?
> >>>
> >> The trigger definition is more generic, it doesn't matter from alerts
> >> domain
> >> from which "source" a data is provided.
> >>
> >> The data model that alerts engine is expecting is here:
> >>
> >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data
> >>
> >> Perhaps, we can add more data types if needed for inference processes.
> >>
> >>> Or should the "event store" allow a listener to be defined (in the glue)
> >>> that
> >>> could supply events to the alert engine - but then this slightly
> >>> separates
> >>> the alert definition into two parts - the bit bridging the event store
> >>> and
> >>> alert engine, and the trigger definition on how the event should be
> >>> processed.
> >>>
> >> I'm +1 to separate the bus integration layer aspect from the pure alerts
> >> inference.
> >>
> >> Today, we have the same separation and the "glue" code lives here:
> >>
> >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus
> >>
> >> As we identified a "filtering" preliminar tasks that is not part of
> >> inference
> >> itself.
> >>
> >> In the other hand, having this separation we can maintain or goal to have
> >> an
> >> scenario with metrics+alerts and without bus dependencies.
> >>
> >> Regards,
> >> Lucas
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Wed May 13 04:02:31 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 04:02:31 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1568256296.15803642.1431503124311.JavaMail.zimbra@redhat.com>
Message-ID: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>

Hi

On yesterday's watercooler discussion the main topic was about how to package the individual components, with the "glue" code, within kettle.

There seems to be a general idea to move all bus integration code into Hawkular/Kettle repo. Although I agree that the kettle is the right place to bring together the components and glue, not sure whether the actual code for the glue should reside in that single repo.

My preference would be for all component related code, including that component's integration with the bus, to be located in that component repo - that way there is a clear owner of the code, and any changes to the core APIs are locally dealt across all integration points that may be supported.

Then the kettle repo can be responsible for selecting the relevant artifacts to build what it requires.

In terms of how the 'core' artifacts from each component should be enhanced with the glue - may be the simplest way would be as one person suggested - use an overlay to build upon the 'core' war artifact to add the glue artifacts (which in general will probably just be bus integration). So each component only needs to produce a single 'core' war, but also manages the integration artifacts locally.

I think I would prefer this approach over a single ear, as it still retains the individual component boundaries but enhances them with whatever they need to communicate in the kettle.

It would be even more ideal if jboss modules allowed exploded wars, so that we didn't need to use overlays, but I don't believe this is the case.

Regards
Gary


From lponce at redhat.com  Wed May 13 04:10:47 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 13 May 2015 04:10:47 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
Message-ID: <2033104511.16000212.1431504647408.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 10:02:31 AM
> Subject: [Hawkular-dev] The components, glue and kettle
> 
> Hi
> 
> On yesterday's watercooler discussion the main topic was about how to package
> the individual components, with the "glue" code, within kettle.
> 
> There seems to be a general idea to move all bus integration code into
> Hawkular/Kettle repo. Although I agree that the kettle is the right place to
> bring together the components and glue, not sure whether the actual code for
> the glue should reside in that single repo.
> 
> My preference would be for all component related code, including that
> component's integration with the bus, to be located in that component repo -
> that way there is a clear owner of the code, and any changes to the core
> APIs are locally dealt across all integration points that may be supported.
> 
> Then the kettle repo can be responsible for selecting the relevant artifacts
> to build what it requires.
> 

+1 

> In terms of how the 'core' artifacts from each component should be enhanced
> with the glue - may be the simplest way would be as one person suggested -
> use an overlay to build upon the 'core' war artifact to add the glue
> artifacts (which in general will probably just be bus integration). So each
> component only needs to produce a single 'core' war, but also manages the
> integration artifacts locally.
> 
> I think I would prefer this approach over a single ear, as it still retains
> the individual component boundaries but enhances them with whatever they
> need to communicate in the kettle.
> 
> It would be even more ideal if jboss modules allowed exploded wars, so that
> we didn't need to use overlays, but I don't believe this is the case.
> 

My only open question about packaging is about which one is better for integration testing.

I like the idea to have in the component integration tests beyond simple junits, it can help to test REST/Accounts/Bus integration as well as other minor regressions before to put a component in hawkular (the artist known as kettle).

But the integration tests perhaps it can be discussed in future threads :-).

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

From gbrown at redhat.com  Wed May 13 04:16:07 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 04:16:07 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <2033104511.16000212.1431504647408.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<2033104511.16000212.1431504647408.JavaMail.zimbra@redhat.com>
Message-ID: <188620774.15813584.1431504967269.JavaMail.zimbra@redhat.com>

+1 to integration tests (for bus and REST) being local within the component repo as well.

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Gary Brown" <gbrown at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Wednesday, May 13, 2015 10:02:31 AM
> > Subject: [Hawkular-dev] The components, glue and kettle
> > 
> > Hi
> > 
> > On yesterday's watercooler discussion the main topic was about how to
> > package
> > the individual components, with the "glue" code, within kettle.
> > 
> > There seems to be a general idea to move all bus integration code into
> > Hawkular/Kettle repo. Although I agree that the kettle is the right place
> > to
> > bring together the components and glue, not sure whether the actual code
> > for
> > the glue should reside in that single repo.
> > 
> > My preference would be for all component related code, including that
> > component's integration with the bus, to be located in that component repo
> > -
> > that way there is a clear owner of the code, and any changes to the core
> > APIs are locally dealt across all integration points that may be supported.
> > 
> > Then the kettle repo can be responsible for selecting the relevant
> > artifacts
> > to build what it requires.
> > 
> 
> +1
> 
> > In terms of how the 'core' artifacts from each component should be enhanced
> > with the glue - may be the simplest way would be as one person suggested -
> > use an overlay to build upon the 'core' war artifact to add the glue
> > artifacts (which in general will probably just be bus integration). So each
> > component only needs to produce a single 'core' war, but also manages the
> > integration artifacts locally.
> > 
> > I think I would prefer this approach over a single ear, as it still retains
> > the individual component boundaries but enhances them with whatever they
> > need to communicate in the kettle.
> > 
> > It would be even more ideal if jboss modules allowed exploded wars, so that
> > we didn't need to use overlays, but I don't believe this is the case.
> > 
> 
> My only open question about packaging is about which one is better for
> integration testing.
> 
> I like the idea to have in the component integration tests beyond simple
> junits, it can help to test REST/Accounts/Bus integration as well as other
> minor regressions before to put a component in hawkular (the artist known as
> kettle).
> 
> But the integration tests perhaps it can be discussed in future threads :-).
> 
> > Regards
> > Gary
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Wed May 13 05:20:26 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 13 May 2015 11:20:26 +0200
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
Message-ID: <5553175A.8080701@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/13/2015 10:02 AM, Gary Brown wrote:
> My preference would be for all component related code, including
> that component's integration with the bus, to be located in that
> component repo - that way there is a clear owner of the code, and
> any changes to the core APIs are locally dealt across all
> integration points that may be supported.
> 
> Then the kettle repo can be responsible for selecting the relevant
> artifacts to build what it requires.

+1

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVUxdaAAoJECKM1e+fkPrXg5sH/A+e1z+SVtFmZ2F+T1afFu9s
HF+UIKdXc0GEY7QvjsBTlhEs7+62mahQLPe3VbKQ78MmcILTSK6bG2CHQaLdKR9i
I7Re11shGfXeRyUboAii8CnwQZ3phq6waCmfRMtW7cofCGxgJiOaGhTR8ZuQkJpa
qJtVhAD/dfXR7PR5/4jjHvI7Jkn4+M7gHuwLxRJHgomr+TKADWoWWlKTlysg21t2
PLX9zfP9PAmDqb/vvy6NFtv33yXmDV6Kg1mTNNLIiuQ3LUl+ACQTLA31YRIYt1dG
6xxq1Mvg27c7Xjfmi3wk/fATG3VUYtMFu0vWfcjlvfnGI+bt5Z1DbooodINVFw8=
=zoUE
-----END PGP SIGNATURE-----

From miburman at redhat.com  Wed May 13 05:53:14 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 13 May 2015 05:53:14 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
Message-ID: <1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>

Hi,

I disagree with the fact where the actual bus-integration component should reside. The components themselves should have the capabilities of allowing another component to connect to their internal "feeds" but the actual component -> bus  connector should be in the Kettle-repository. Why? The bus-connector is highly dependent on the actual bus implementation. If we would change the bus in any way in terms of implementation or API, it would require changes to every Hawkular component (thus, they wouldn't be decoupled by design) instead of only changing the implementation at the bus-component. 

   - Micke

----- Original Message -----
From: "Gary Brown" <gbrown at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Wednesday, May 13, 2015 11:02:31 AM
Subject: [Hawkular-dev] The components, glue and kettle

Hi

On yesterday's watercooler discussion the main topic was about how to package the individual components, with the "glue" code, within kettle.

There seems to be a general idea to move all bus integration code into Hawkular/Kettle repo. Although I agree that the kettle is the right place to bring together the components and glue, not sure whether the actual code for the glue should reside in that single repo.

My preference would be for all component related code, including that component's integration with the bus, to be located in that component repo - that way there is a clear owner of the code, and any changes to the core APIs are locally dealt across all integration points that may be supported.

Then the kettle repo can be responsible for selecting the relevant artifacts to build what it requires.

In terms of how the 'core' artifacts from each component should be enhanced with the glue - may be the simplest way would be as one person suggested - use an overlay to build upon the 'core' war artifact to add the glue artifacts (which in general will probably just be bus integration). So each component only needs to produce a single 'core' war, but also manages the integration artifacts locally.

I think I would prefer this approach over a single ear, as it still retains the individual component boundaries but enhances them with whatever they need to communicate in the kettle.

It would be even more ideal if jboss modules allowed exploded wars, so that we didn't need to use overlays, but I don't believe this is the case.

Regards
Gary

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

From gbrown at redhat.com  Wed May 13 06:01:12 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 06:01:12 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
Message-ID: <1743689550.15834829.1431511272102.JavaMail.zimbra@redhat.com>

Hi Micke

Its a valid point - but I don't believe the bus API is going to change that often, and therefore I think the benefits of bus integration code in the component repos outweighs the potential impact of such a change to the bus API.

Regards
Gary

----- Original Message -----
> Hi,
> 
> I disagree with the fact where the actual bus-integration component should
> reside. The components themselves should have the capabilities of allowing
> another component to connect to their internal "feeds" but the actual
> component -> bus  connector should be in the Kettle-repository. Why? The
> bus-connector is highly dependent on the actual bus implementation. If we
> would change the bus in any way in terms of implementation or API, it would
> require changes to every Hawkular component (thus, they wouldn't be
> decoupled by design) instead of only changing the implementation at the
> bus-component.
> 
>    - Micke
> 
> ----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 11:02:31 AM
> Subject: [Hawkular-dev] The components, glue and kettle
> 
> Hi
> 
> On yesterday's watercooler discussion the main topic was about how to package
> the individual components, with the "glue" code, within kettle.
> 
> There seems to be a general idea to move all bus integration code into
> Hawkular/Kettle repo. Although I agree that the kettle is the right place to
> bring together the components and glue, not sure whether the actual code for
> the glue should reside in that single repo.
> 
> My preference would be for all component related code, including that
> component's integration with the bus, to be located in that component repo -
> that way there is a clear owner of the code, and any changes to the core
> APIs are locally dealt across all integration points that may be supported.
> 
> Then the kettle repo can be responsible for selecting the relevant artifacts
> to build what it requires.
> 
> In terms of how the 'core' artifacts from each component should be enhanced
> with the glue - may be the simplest way would be as one person suggested -
> use an overlay to build upon the 'core' war artifact to add the glue
> artifacts (which in general will probably just be bus integration). So each
> component only needs to produce a single 'core' war, but also manages the
> integration artifacts locally.
> 
> I think I would prefer this approach over a single ear, as it still retains
> the individual component boundaries but enhances them with whatever they
> need to communicate in the kettle.
> 
> It would be even more ideal if jboss modules allowed exploded wars, so that
> we didn't need to use overlays, but I don't believe this is the case.
> 
> Regards
> Gary
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Wed May 13 06:03:13 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 13 May 2015 12:03:13 +0200
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
Message-ID: <55532161.70208@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/13/2015 11:53 AM, Michael Burman wrote:
> I disagree with the fact where the actual bus-integration component
> should reside. The components themselves should have the
> capabilities of allowing another component to connect to their
> internal "feeds" but the actual component -> bus  connector should
> be in the Kettle-repository. Why? The bus-connector is highly
> dependent on the actual bus implementation. If we would change the
> bus in any way in terms of implementation or API, it would require
> changes to every Hawkular component (thus, they wouldn't be
> decoupled by design) instead of only changing the implementation at
> the bus-component.

I haven't worked with the bus yet, but isn't "the bus" just a synonym
for "a distributed JMS topic" ?

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

iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
/LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
=+U0e
-----END PGP SIGNATURE-----

From theute at redhat.com  Wed May 13 06:22:54 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 13 May 2015 12:22:54 +0200
Subject: [Hawkular-dev] Branch Kettle?
In-Reply-To: <555249EC.8050508@redhat.com>
References: <555249EC.8050508@redhat.com>
Message-ID: <555325FE.1020804@redhat.com>

On 05/12/2015 08:43 PM, Jay Shaughnessy wrote:
>
> Related to the "Adding git SHA1 & Co. to manifest.mf to improve
> traceability" thread...

First I think we should decouple the 2 :) Adding SHA1 was a cheap 
addition without additional steps for developers that can be useful in 
last resort for corner cases but doesn't significantly help the main issue.

> In the interim between now and when we move to strong versioning could
> we perhaps just create a "stable" branch for kettle?  Note the term
> "stable" as opposed to "release" or something like that.  This idea was
> kicked around at the F2F as a possible solution.
>
> The stable branch would have poms updated with non-snapshot versions of
> the components and so would be reproducible.  It could be used for demos
> without fear of snapshot regression.  It could be used by QE for
> test-case development and [non-release] qualification. Kettle itself
> could be versioned, bumping it's version whenever a consumed component
> version was updated.

I think the idea was worth mentioning, but I really doubt that 
maintaining several branches (and make sure they are update and really 
work) without someone in charge would work.

> Components would be required to make at least an initial release to get
> things going, and then should make subsequent releases at relatively
> short intervals, maybe every few weeks.

I would rather see "master" using tagged version and if someone working 
on Kettle needs a more recent version of a SNAPSHOT work in a branch 
(that he "maintains") where he would only change the version of 
components he needs then merge in master when the component is released 
(and delete the branch). Lifetime of the branch should be 2-3 weeks.

Thomas


>
> Will this work and be helpful?
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From theute at redhat.com  Wed May 13 06:24:23 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 13 May 2015 12:24:23 +0200
Subject: [Hawkular-dev] Packaging
In-Reply-To: <1975205884.15417452.1431436060588.JavaMail.zimbra@redhat.com>
References: <5551E371.7070107@redhat.com>
	<1975205884.15417452.1431436060588.JavaMail.zimbra@redhat.com>
Message-ID: <55532657.20306@redhat.com>

Ok so I guess there is no objection to bring the "kettle" composition 
fully in 'hawkular'. (I won't remove the nest as it may still be needed 
by Alerts component for testing)

Thomas

On 05/12/2015 03:07 PM, John Mazzitelli wrote:
>> 		2 - Bring the nest distro build from Bus to Hawkular:
>
> IIRC, I left some stuff in the mvn  poms for the nest so it should be easy to move it. I had envisioned we would eventually move that out of the bus repo. That's what this comment is trying to convey:
>
> https://github.com/hawkular/hawkular-bus/blob/master/hawkular-nest/pom.xml#L81L86
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From theute at redhat.com  Wed May 13 06:25:54 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 13 May 2015 12:25:54 +0200
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
Message-ID: <555326B2.8090406@redhat.com>

+1

On 05/13/2015 11:53 AM, Michael Burman wrote:
> Hi,
>
> I disagree with the fact where the actual bus-integration component should reside. The components themselves should have the capabilities of allowing another component to connect to their internal "feeds" but the actual component -> bus  connector should be in the Kettle-repository. Why? The bus-connector is highly dependent on the actual bus implementation. If we would change the bus in any way in terms of implementation or API, it would require changes to every Hawkular component (thus, they wouldn't be decoupled by design) instead of only changing the implementation at the bus-component.
>
>     - Micke
>
> ----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 11:02:31 AM
> Subject: [Hawkular-dev] The components, glue and kettle
>
> Hi
>
> On yesterday's watercooler discussion the main topic was about how to package the individual components, with the "glue" code, within kettle.
>
> There seems to be a general idea to move all bus integration code into Hawkular/Kettle repo. Although I agree that the kettle is the right place to bring together the components and glue, not sure whether the actual code for the glue should reside in that single repo.
>
> My preference would be for all component related code, including that component's integration with the bus, to be located in that component repo - that way there is a clear owner of the code, and any changes to the core APIs are locally dealt across all integration points that may be supported.
>
> Then the kettle repo can be responsible for selecting the relevant artifacts to build what it requires.
>
> In terms of how the 'core' artifacts from each component should be enhanced with the glue - may be the simplest way would be as one person suggested - use an overlay to build upon the 'core' war artifact to add the glue artifacts (which in general will probably just be bus integration). So each component only needs to produce a single 'core' war, but also manages the integration artifacts locally.
>
> I think I would prefer this approach over a single ear, as it still retains the individual component boundaries but enhances them with whatever they need to communicate in the kettle.
>
> It would be even more ideal if jboss modules allowed exploded wars, so that we didn't need to use overlays, but I don't believe this is the case.
>
> Regards
> Gary
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From theute at redhat.com  Wed May 13 06:35:20 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 13 May 2015 12:35:20 +0200
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <555326B2.8090406@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<555326B2.8090406@redhat.com>
Message-ID: <555328E8.5010708@redhat.com>

To add to this.

I think we are trying to put too much into the components, defeating the 
whole purpose of the componentization that I was advocating for in the 
2014 f2f.

The components need to do minimum things and do them well. They should 
go to maintenance relatively early, after that all the specifics need to 
be in Hawkular.

One example, today we have calculation of 95 percentile within Metrics 
[1], IMO this should be in hawkular (and Metrics need to provide a way 
to add that functionality which I think was one thing discussed at f2f). 
If I need 97 or 98 or 99 or 99.99 percentile, I should be able to do 
that without another release of metrics.

Hawkular (the kettle) should be in charge of "deciding" who (which 
components) receive what information based on Hawkular configuration.

[1] I understand that this was a shortcut. No finger pointing

Thomas





On 05/13/2015 12:25 PM, Thomas Heute wrote:
> +1
>
> On 05/13/2015 11:53 AM, Michael Burman wrote:
>> Hi,
>>
>> I disagree with the fact where the actual bus-integration component
>> should reside. The components themselves should have the capabilities
>> of allowing another component to connect to their internal "feeds" but
>> the actual component -> bus  connector should be in the
>> Kettle-repository. Why? The bus-connector is highly dependent on the
>> actual bus implementation. If we would change the bus in any way in
>> terms of implementation or API, it would require changes to every
>> Hawkular component (thus, they wouldn't be decoupled by design)
>> instead of only changing the implementation at the bus-component.
>>
>>     - Micke
>>
>> ----- Original Message -----
>> From: "Gary Brown" <gbrown at redhat.com>
>> To: "Discussions around Hawkular development"
>> <hawkular-dev at lists.jboss.org>
>> Sent: Wednesday, May 13, 2015 11:02:31 AM
>> Subject: [Hawkular-dev] The components, glue and kettle
>>
>> Hi
>>
>> On yesterday's watercooler discussion the main topic was about how to
>> package the individual components, with the "glue" code, within kettle.
>>
>> There seems to be a general idea to move all bus integration code into
>> Hawkular/Kettle repo. Although I agree that the kettle is the right
>> place to bring together the components and glue, not sure whether the
>> actual code for the glue should reside in that single repo.
>>
>> My preference would be for all component related code, including that
>> component's integration with the bus, to be located in that component
>> repo - that way there is a clear owner of the code, and any changes to
>> the core APIs are locally dealt across all integration points that may
>> be supported.
>>
>> Then the kettle repo can be responsible for selecting the relevant
>> artifacts to build what it requires.
>>
>> In terms of how the 'core' artifacts from each component should be
>> enhanced with the glue - may be the simplest way would be as one
>> person suggested - use an overlay to build upon the 'core' war
>> artifact to add the glue artifacts (which in general will probably
>> just be bus integration). So each component only needs to produce a
>> single 'core' war, but also manages the integration artifacts locally.
>>
>> I think I would prefer this approach over a single ear, as it still
>> retains the individual component boundaries but enhances them with
>> whatever they need to communicate in the kettle.
>>
>> It would be even more ideal if jboss modules allowed exploded wars, so
>> that we didn't need to use overlays, but I don't believe this is the
>> case.
>>
>> Regards
>> Gary
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>

From gbrown at redhat.com  Wed May 13 06:49:05 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 06:49:05 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <555328E8.5010708@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<555326B2.8090406@redhat.com> <555328E8.5010708@redhat.com>
Message-ID: <873283704.15841986.1431514145604.JavaMail.zimbra@redhat.com>

Hi Thomas

I agree that Hawkular/Kettle should have the ability to customise the components (e.g. add further percentiles, alert definitions, etc), and how the components communicate. But I still believe the code to support those customisations and communication options should live within the component.

It makes the components more maintainable/testable - with Hawkular/Kettle being responsible for assembly/customisation/end to end testing.

Regards
Gary

----- Original Message -----
> To add to this.
> 
> I think we are trying to put too much into the components, defeating the
> whole purpose of the componentization that I was advocating for in the
> 2014 f2f.
> 
> The components need to do minimum things and do them well. They should
> go to maintenance relatively early, after that all the specifics need to
> be in Hawkular.
> 
> One example, today we have calculation of 95 percentile within Metrics
> [1], IMO this should be in hawkular (and Metrics need to provide a way
> to add that functionality which I think was one thing discussed at f2f).
> If I need 97 or 98 or 99 or 99.99 percentile, I should be able to do
> that without another release of metrics.
> 
> Hawkular (the kettle) should be in charge of "deciding" who (which
> components) receive what information based on Hawkular configuration.
> 
> [1] I understand that this was a shortcut. No finger pointing
> 
> Thomas
> 
> 
> 
> 
> 
> On 05/13/2015 12:25 PM, Thomas Heute wrote:
> > +1
> >
> > On 05/13/2015 11:53 AM, Michael Burman wrote:
> >> Hi,
> >>
> >> I disagree with the fact where the actual bus-integration component
> >> should reside. The components themselves should have the capabilities
> >> of allowing another component to connect to their internal "feeds" but
> >> the actual component -> bus  connector should be in the
> >> Kettle-repository. Why? The bus-connector is highly dependent on the
> >> actual bus implementation. If we would change the bus in any way in
> >> terms of implementation or API, it would require changes to every
> >> Hawkular component (thus, they wouldn't be decoupled by design)
> >> instead of only changing the implementation at the bus-component.
> >>
> >>     - Micke
> >>
> >> ----- Original Message -----
> >> From: "Gary Brown" <gbrown at redhat.com>
> >> To: "Discussions around Hawkular development"
> >> <hawkular-dev at lists.jboss.org>
> >> Sent: Wednesday, May 13, 2015 11:02:31 AM
> >> Subject: [Hawkular-dev] The components, glue and kettle
> >>
> >> Hi
> >>
> >> On yesterday's watercooler discussion the main topic was about how to
> >> package the individual components, with the "glue" code, within kettle.
> >>
> >> There seems to be a general idea to move all bus integration code into
> >> Hawkular/Kettle repo. Although I agree that the kettle is the right
> >> place to bring together the components and glue, not sure whether the
> >> actual code for the glue should reside in that single repo.
> >>
> >> My preference would be for all component related code, including that
> >> component's integration with the bus, to be located in that component
> >> repo - that way there is a clear owner of the code, and any changes to
> >> the core APIs are locally dealt across all integration points that may
> >> be supported.
> >>
> >> Then the kettle repo can be responsible for selecting the relevant
> >> artifacts to build what it requires.
> >>
> >> In terms of how the 'core' artifacts from each component should be
> >> enhanced with the glue - may be the simplest way would be as one
> >> person suggested - use an overlay to build upon the 'core' war
> >> artifact to add the glue artifacts (which in general will probably
> >> just be bus integration). So each component only needs to produce a
> >> single 'core' war, but also manages the integration artifacts locally.
> >>
> >> I think I would prefer this approach over a single ear, as it still
> >> retains the individual component boundaries but enhances them with
> >> whatever they need to communicate in the kettle.
> >>
> >> It would be even more ideal if jboss modules allowed exploded wars, so
> >> that we didn't need to use overlays, but I don't believe this is the
> >> case.
> >>
> >> Regards
> >> Gary
> >>
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From tsegismo at redhat.com  Wed May 13 07:33:58 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 13 May 2015 13:33:58 +0200
Subject: [Hawkular-dev] HWKMETRICS-67 Influx endpoint: support pretty print
 query parameter #211
Message-ID: <555336A6.4070408@redhat.com>

Hi,

I've just sent a PR request for Metrics which enables pretty printing on 
the Influx endpoint (something supported by Influx in the first place)

I believe that's a capability which would be beneficial to the rest of 
the Metrics endpoints.

In practice, any request with the /pretty=true/ query parameter would 
have a JSON formatted output.

Please shout if you disagree.

Regards,
Thomas.


https://issues.jboss.org/browse/HWKMETRICS-84
https://github.com/hawkular/hawkular-metrics/pull/211

From miburman at redhat.com  Wed May 13 08:01:51 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 13 May 2015 08:01:51 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <55532161.70208@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<55532161.70208@redhat.com>
Message-ID: <692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>

Hi,

More like the bus is only a JMS topic with "distributed" not meaning probably what you hoped for. Since it's based on the ActiveMQ5 it's in HA configuration a single broker with master/slave (which with replicated LevelDB storage would then have ZooKeeper and everything else that's massively complex to manage). So nothing like the networks created by Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark / Cassandra / etc.

These restrictions create their own headache when it comes to scaling in Kubernetes for example, but I don't think we need to solve this issue quite yet. Creating components without locking them to a JMS is the key forward however as that would allow changing the implementation if requirements dictate such in the future.

  - Micke

----- Original Message -----
From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Wednesday, May 13, 2015 1:03:13 PM
Subject: Re: [Hawkular-dev] The components, glue and kettle

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/13/2015 11:53 AM, Michael Burman wrote:
> I disagree with the fact where the actual bus-integration component
> should reside. The components themselves should have the
> capabilities of allowing another component to connect to their
> internal "feeds" but the actual component -> bus  connector should
> be in the Kettle-repository. Why? The bus-connector is highly
> dependent on the actual bus implementation. If we would change the
> bus in any way in terms of implementation or API, it would require
> changes to every Hawkular component (thus, they wouldn't be
> decoupled by design) instead of only changing the implementation at
> the bus-component.

I haven't worked with the bus yet, but isn't "the bus" just a synonym
for "a distributed JMS topic" ?

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

iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
/LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
=+U0e
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev


From miburman at redhat.com  Wed May 13 08:33:59 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 13 May 2015 08:33:59 -0400 (EDT)
Subject: [Hawkular-dev] HWKMETRICS-67 Influx endpoint: support pretty
 print query parameter #211
In-Reply-To: <555336A6.4070408@redhat.com>
References: <555336A6.4070408@redhat.com>
Message-ID: <784181775.19641900.1431520439075.JavaMail.zimbra@redhat.com>

Hi,

Like I said in the IRC, it's true that this helps browser-based querying (although many do use some addon on their browsers for debugging anyway), but this is so easy feature to do on the client side that is it really useful? But then to the actual implementation.

If we want to support streaming large resultsets for analytic purposes, this solution will not cut it (not that it needs to - there's no point when dealing with large amount of data). You have to keep the whole result in the memory, format it and then print it. When we're migrating to RxJava, for example following process would be doable and very neat:

http://christopher-batey.blogspot.fi/2014/12/streaming-large-payloads-over-http-from.html

(this is Cassandra + RxJava + JAX-RS streaming blog article)

That would allow customers to fetch large amount of data from the Metrics interface and do their own calculations on the raw data. Perhaps even the idea that Thomas H threw earlier that we could calculate the "new requirements, such as percentiles" on the Kettle without modifying the Metrics component each time. Now, should we protect ourselves somehow from people using pretty on that case ? Otherwise there's a possibility for killing the server to OOM with silly request.

  -  Micke

----- Original Message -----
From: "Thomas Segismont" <tsegismo at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Wednesday, May 13, 2015 2:33:58 PM
Subject: [Hawkular-dev] HWKMETRICS-67 Influx endpoint: support pretty print query parameter #211

Hi,

I've just sent a PR request for Metrics which enables pretty printing on 
the Influx endpoint (something supported by Influx in the first place)

I believe that's a capability which would be beneficial to the rest of 
the Metrics endpoints.

In practice, any request with the /pretty=true/ query parameter would 
have a JSON formatted output.

Please shout if you disagree.

Regards,
Thomas.


https://issues.jboss.org/browse/HWKMETRICS-84
https://github.com/hawkular/hawkular-metrics/pull/211
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

From mwringe at redhat.com  Wed May 13 09:34:02 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Wed, 13 May 2015 09:34:02 -0400
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <55523C42.6010607@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
	<55523C42.6010607@redhat.com>
Message-ID: <555352CA.9040900@redhat.com>

On 12/05/15 01:45 PM, Thomas Segismont wrote:
> Le 12/05/2015 15:17, Stefan Negrea a ?crit :
>> ----- Original Message -----
>>>> From: "Thomas Segismont"<tsegismo at redhat.com>
>>>> To:hawkular-dev at lists.jboss.org
>>>> Sent: Tuesday, May 12, 2015 8:08:36 AM
>>>> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
>>>>
>>>> You mean use_hawkularTenant_  instead of the_tenant_  query param? That
>>>> makes less sense to me.
>> I would use an identical query parameter so consumers that do not want/have the option to use headers can just append an identical query parameter. The hyphen is not reserved, therefore it can be used as part of the query parameter name or value without encoding. Correct me if I am wrong about the hyphen.
>>
>> http://tools.ietf.org/html/rfc3986#section-2.3
>>
>>
> Please do not switch from top to bottom posting, or I might start to get
> sick :p

What is the correct convention for posting to the list? :) Top, bottom, 
inline?

For the query parameter, is there any reason why we are using a query 
parameter and not a matrix parameter?

Personally I think a matrix parameter makes a lot more sense

http://hawkular/metrics;tenant=foo/gauges/....

versus

http://hawkular/metrics/gauges/....?tenant=foo

Always having to specify tenant at the end of the url seems strange to 
be. Logically I would think that it should be applied to the metrics 
resource itself and not to all the child resources.

Something like this would normally mean that the parameter 'a' is to be 
applied to the 'foo/bar' resource:
http://foo/bar;a=b/baz

While, something like this would normally mean that the parameter 'a' is 
to be applied to the 'foo/bar/baz' resource:
http://foo/bar/baz?a=b

>
> Yes, "Hawkular-Tenant" is valid, but I'd prefer to pick something short
> ("tenant") for the query parameter fallback.
>
> In fact, I'd prefer to have short names for all out-of-band query
> parameters, like "pretty" to get a formatted JSON output.
> _______________________________________________

From jshaughn at redhat.com  Wed May 13 10:10:59 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 13 May 2015 10:10:59 -0400
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <555352CA.9040900@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>	<55523C42.6010607@redhat.com>
	<555352CA.9040900@redhat.com>
Message-ID: <55535B73.5000305@redhat.com>


Top if you want to be cool :)

I had never heard of this matrix parameter thing until your post. But I 
sort of like how it extracts the global and orthogonal authz info out of 
the path and query params.  I'll throw my support in this direction but 
reserve the right to change my mind.  More importantly, we need a 
consistent approach across Hawkular.  If we can't decide then I vote 
that Heiko choose and not let the discussion linger very long so as to 
get the API published ASAP.


On 5/13/2015 9:34 AM, Matt Wringe wrote:
> On 12/05/15 01:45 PM, Thomas Segismont wrote:
>> Le 12/05/2015 15:17, Stefan Negrea a ?crit :
>>> ----- Original Message -----
>>>>> From: "Thomas Segismont"<tsegismo at redhat.com>
>>>>> To:hawkular-dev at lists.jboss.org
>>>>> Sent: Tuesday, May 12, 2015 8:08:36 AM
>>>>> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
>>>>>
>>>>> You mean use_hawkularTenant_  instead of the_tenant_  query param? That
>>>>> makes less sense to me.
>>> I would use an identical query parameter so consumers that do not want/have the option to use headers can just append an identical query parameter. The hyphen is not reserved, therefore it can be used as part of the query parameter name or value without encoding. Correct me if I am wrong about the hyphen.
>>>
>>> http://tools.ietf.org/html/rfc3986#section-2.3
>>>
>>>
>> Please do not switch from top to bottom posting, or I might start to get
>> sick :p
> What is the correct convention for posting to the list? :) Top, bottom,
> inline?
>
> For the query parameter, is there any reason why we are using a query
> parameter and not a matrix parameter?
>
> Personally I think a matrix parameter makes a lot more sense
>
> http://hawkular/metrics;tenant=foo/gauges/....
>
> versus
>
> http://hawkular/metrics/gauges/....?tenant=foo
>
> Always having to specify tenant at the end of the url seems strange to
> be. Logically I would think that it should be applied to the metrics
> resource itself and not to all the child resources.
>
> Something like this would normally mean that the parameter 'a' is to be
> applied to the 'foo/bar' resource:
> http://foo/bar;a=b/baz
>
> While, something like this would normally mean that the parameter 'a' is
> to be applied to the 'foo/bar/baz' resource:
> http://foo/bar/baz?a=b
>
>> Yes, "Hawkular-Tenant" is valid, but I'd prefer to pick something short
>> ("tenant") for the query parameter fallback.
>>
>> In fact, I'd prefer to have short names for all out-of-band query
>> parameters, like "pretty" to get a formatted JSON output.
>> _______________________________________________
> _______________________________________________
> 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/20150513/765c947d/attachment.html 

From tsegismo at redhat.com  Wed May 13 10:36:42 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 13 May 2015 16:36:42 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <555352CA.9040900@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>	<55523C42.6010607@redhat.com>
	<555352CA.9040900@redhat.com>
Message-ID: <5553617A.6050702@redhat.com>

Le 13/05/2015 15:34, Matt Wringe a ?crit :
> Personally I think a matrix parameter makes a lot more sense
>
> http://hawkular/metrics;tenant=foo/gauges/....
>
> versus
>
> http://hawkular/metrics/gauges/....?tenant=foo
>
> Always having to specify tenant at the end of the url seems strange to
> be. Logically I would think that it should be applied to the metrics
> resource itself and not to all the child resources.
>
> Something like this would normally mean that the parameter 'a' is to be
> applied to the 'foo/bar' resource:
> http://foo/bar;a=b/baz
>
> While, something like this would normally mean that the parameter 'a' is
> to be applied to the 'foo/bar/baz' resource:
> http://foo/bar/baz?a=b
>

I have no strong preference.

Note that the query param is just a fallback, in case a client can't set 
the header (like somebody sending GET requests manually with a browser).

From ppalaga at redhat.com  Wed May 13 11:25:15 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 13 May 2015 17:25:15 +0200
Subject: [Hawkular-dev] Chrome extension to make HAWKULAR Jira refs on
	Github clickable
Message-ID: <55536CDB.4080409@redhat.com>

Hi *,

this might be interesting to you if you use Chrome and if you want to 
come faster from commits on github to related Jiras and BZs.

I have updated my older Chrome extension today, to cover also Hawkular 
Jira prefixes HAWKULAR HWKALERTS HWKBTM HWKINVENT HWKMETRICS.
The extension detects plain text references to JBoss Jira issues and Red 
Hat Bugzilla bugs and for each of them, it adds a link pointing to the 
related issue.
This is what it looks like:


== How to run

|cd ~/git
git clone https://github.com/ppalaga/jboss-jira-content-script.git
# Option 1: Chrome CLI
google-chrome --load-extension=jboss-jira-content-script
# Or option 2: follow http://developer.chrome.com/extensions/getstarted.html#unpacked
|


Best,

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150513/4aba0128/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfcijehc.png
Type: image/png
Size: 89416 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150513/4aba0128/attachment-0001.png 

From gbrown at redhat.com  Wed May 13 11:46:30 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 13 May 2015 11:46:30 -0400 (EDT)
Subject: [Hawkular-dev] Plans for Alerts UI
In-Reply-To: <1049912471.15970945.1431531345915.JavaMail.zimbra@redhat.com>
Message-ID: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>

Hi

As mentioned at the F2F, one of the things I need to do with BTM is ensure that it will be capable of providing equivalent functionality that is currently in RTGov.

If Alerts are used in place of RTGov Situations, then from the UI the user would need to be able to perform various tasks when focused on a particular alert, including viewing/editing a message for resubmission to the originating service, navigate to the business transaction instance view, etc.

It would be useful if there was a way to provide plugins to the alerts UI to register actions that could be performed, or contribute additional UI tabs that can perform capabilities related to the selected alert.

Is this going to be technically possible with hawt.io/angular to add such extension points?

What is the best way to proceed - should I just create a jira for now?

Regards
Gary

From tsegismo at redhat.com  Wed May 13 12:52:16 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 13 May 2015 18:52:16 +0200
Subject: [Hawkular-dev] HWKMETRICS-67 Influx endpoint: support pretty
 print query parameter #211
In-Reply-To: <784181775.19641900.1431520439075.JavaMail.zimbra@redhat.com>
References: <555336A6.4070408@redhat.com>
	<784181775.19641900.1431520439075.JavaMail.zimbra@redhat.com>
Message-ID: <55538140.6030406@redhat.com>



Le 13/05/2015 14:33, Michael Burman a ?crit :
> Hi,
>
> Like I said in the IRC, it's true that this helps browser-based querying (although many do use some addon on their browsers for debugging anyway), but this is so easy feature to do on the client side that is it really useful? But then to the actual implementation.

The usefulness question is important. It isn't if your IT department 
lets you install a browser with such plugins, or if the terminal access 
they give you lets you execute python or ruby. If you only have curl, 
then it is useful.

>
> If we want to support streaming large resultsets for analytic purposes, this solution will not cut it (not that it needs to - there's no point when dealing with large amount of data). You have to keep the whole result in the memory, format it and then print it. When we're migrating to RxJava, for example following process would be doable and very neat:
>
> http://christopher-batey.blogspot.fi/2014/12/streaming-large-payloads-over-http-from.html
>
> (this is Cassandra + RxJava + JAX-RS streaming blog article)
>
> That would allow customers to fetch large amount of data from the Metrics interface and do their own calculations on the raw data. Perhaps even the idea that Thomas H threw earlier that we could calculate the "new requirements, such as percentiles" on the Kettle without modifying the Metrics component each time. Now, should we protect ourselves somehow from people using pretty on that case ? Otherwise there's a possibility for killing the server to OOM with silly request.

Right, the problem narrows down to large (> hundreds of megabytes) 
content sent with StreamingOutput, because whenever we use the built-in 
Jackson provider to convert entities, the payload has to fit in memory 
(we create the response with an entity and then RestEasy calls the 
ObjectMapper)

For such endpoints, we could simply remove the PRETTY_PRINT hint from 
the request context.

>
>    -  Micke
>
> ----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 2:33:58 PM
> Subject: [Hawkular-dev] HWKMETRICS-67 Influx endpoint: support pretty print query parameter #211
>
> Hi,
>
> I've just sent a PR request for Metrics which enables pretty printing on
> the Influx endpoint (something supported by Influx in the first place)
>
> I believe that's a capability which would be beneficial to the rest of
> the Metrics endpoints.
>
> In practice, any request with the /pretty=true/ query parameter would
> have a JSON formatted output.
>
> Please shout if you disagree.
>
> Regards,
> Thomas.
>
>
> https://issues.jboss.org/browse/HWKMETRICS-84
> https://github.com/hawkular/hawkular-metrics/pull/211
> _______________________________________________
> 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 May 13 12:20:29 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 13 May 2015 18:20:29 +0200
Subject: [Hawkular-dev] Plans for Alerts UI
In-Reply-To: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>
References: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>
Message-ID: <334C9414-0A3D-4B78-87BF-F6F2628D37F2@redhat.com>

> What is the best way to proceed - should I just create a jira for now?

That is certainly the best start.
I can imagine that it would be helpful to see some examples
from RTGov on what you want to achieve and then we work together
with UxD how this will fit into the overall alert picture.

Perhaps do a demo of the RTGov side?

From snegrea at redhat.com  Wed May 13 14:45:29 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 13 May 2015 14:45:29 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <55523C42.6010607@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
	<5551FB54.7000408@redhat.com>
	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
	<55523C42.6010607@redhat.com>
Message-ID: <416601638.16607225.1431542729315.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, May 12, 2015 12:45:38 PM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> Le 12/05/2015 15:17, Stefan Negrea a ?crit :
> >
> > ----- Original Message -----
> >> >From: "Thomas Segismont"<tsegismo at redhat.com>
> >> >To:hawkular-dev at lists.jboss.org
> >> >Sent: Tuesday, May 12, 2015 8:08:36 AM
> >> >Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> >> >
> >> >You mean use_hawkularTenant_  instead of the_tenant_  query param? That
> >> >makes less sense to me.
> > I would use an identical query parameter so consumers that do not want/have
> > the option to use headers can just append an identical query parameter.
> > The hyphen is not reserved, therefore it can be used as part of the query
> > parameter name or value without encoding. Correct me if I am wrong about
> > the hyphen.
> >
> > http://tools.ietf.org/html/rfc3986#section-2.3
> >
> >
> 
> Please do not switch from top to bottom posting, or I might start to get
> sick :p
> 
> Yes, "Hawkular-Tenant" is valid, but I'd prefer to pick something short
> ("tenant") for the query parameter fallback.
> 
> In fact, I'd prefer to have short names for all out-of-band query
> parameters, like "pretty" to get a formatted JSON output.


We can alias any long name with short names (one or more). But we need to keep the long names around to avoid confusion. Since this is a REST interface, I expect that the typical consumer is another piece of software that does queries automatically. We should be consistent in naming to make the API easier for the developer that codes against it. And for the occasional manual use, we could throw in short aliases.


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


From snegrea at redhat.com  Wed May 13 14:49:08 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 13 May 2015 14:49:08 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5553617A.6050702@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
	<5551FB54.7000408@redhat.com>
	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
	<55523C42.6010607@redhat.com> <555352CA.9040900@redhat.com>
	<5553617A.6050702@redhat.com>
Message-ID: <888925342.16608947.1431542948105.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 9:36:42 AM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> Le 13/05/2015 15:34, Matt Wringe a ?crit :
> > Personally I think a matrix parameter makes a lot more sense
> >
> > http://hawkular/metrics;tenant=foo/gauges/....
> >
> > versus
> >
> > http://hawkular/metrics/gauges/....?tenant=foo
> >
> > Always having to specify tenant at the end of the url seems strange to
> > be. Logically I would think that it should be applied to the metrics
> > resource itself and not to all the child resources.
> >
> > Something like this would normally mean that the parameter 'a' is to be
> > applied to the 'foo/bar' resource:
> > http://foo/bar;a=b/baz
> >
> > While, something like this would normally mean that the parameter 'a' is
> > to be applied to the 'foo/bar/baz' resource:
> > http://foo/bar/baz?a=b
> >
> 
> I have no strong preference.
> 
> Note that the query param is just a fallback, in case a client can't set
> the header (like somebody sending GET requests manually with a browser).

I think the matrix parameters have a closer semantics to the header ones. The main issues was support for matrix params in the container. But we should not have any problems with WF9 or latest Undertow. So I vote for matrix params too. 

I will open a ticket against Hawkular Metrics to change the existing tenant query parameter to a matrix parameter.



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


From snegrea at redhat.com  Wed May 13 15:11:17 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 13 May 2015 15:11:17 -0400 (EDT)
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <1736827686.16609442.1431543016027.JavaMail.zimbra@redhat.com>
Message-ID: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>

Hello Everybody,

With the metrics aggregation work well under way, we have encountered the first case where timezones are important. The task queue [1] that John wrote to be used in the aggregation process is time sensitive. The tasks ran according to a schedule that is predefined; the time relationship also applies to failures, retries, and cancellation. Based on the experience we had with RHQ, not using an UTC timezone can lead to errors and loss of data (for more details visit [2])

I propose to set the default time zone for all the services to UTC. Only allow the concept of a timezone in the UI. This will avoid any problems due to automatic transitions between DST and non-DST times. For example, if the user wants to schedule something 2 weeks from now, let the UI handle the user selection. But when the user action is sent to the backend, it should be expressed in an timezone agnostic manner (eg. milliseconds since Unix Epoch).

The PR [1] sets the default timezone for the JODA library to be UTC for the classloader that contains the metrics service. With the recent discussions about creating a combined Kettle EAR or using a single classloader, that means this setting will extend to all the services in the same classloader that use JODA. And this is just the default, if a service really needs to set another timezone for a date object, it can be done by just specifying the timezone.

We tried to make the change more local in the metrics code, but the approach was error prone. Anybody could make a mistake and instantiate a date object in the current server timezone rather than UTC. This global approach drastically limits inadvertent mistakes.


Two questions for the group:
1) Does anybody see any issues with using the UTC timezone as default at the services layer?
2) Should we expand this setting to the JVM (not just JODA)?


[1] Task queue PR  - https://github.com/hawkular/hawkular-metrics/pull/205
[2] Old RHQ thread - https://lists.fedorahosted.org/pipermail/rhq-devel/2014-November/003709.html



Thank you,
Stefan Negrea

Software Engineer


From tsegismo at redhat.com  Wed May 13 15:20:26 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 13 May 2015 21:20:26 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <888925342.16608947.1431542948105.JavaMail.zimbra@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>	<55523C42.6010607@redhat.com>
	<555352CA.9040900@redhat.com>	<5553617A.6050702@redhat.com>
	<888925342.16608947.1431542948105.JavaMail.zimbra@redhat.com>
Message-ID: <5553A3FA.3000409@redhat.com>

Le 13/05/2015 20:49, Stefan Negrea a ?crit :
> I will open a ticket against Hawkular Metrics to change the existing tenant query parameter to a matrix parameter.

Could you update HWKMETRICS-86 instead? I'll add a commit once the 
existing PR[1] has been reviewed.

Or if there's a need to make the change before I'm back, please let me 
know. I would have to rebase (and possibly fix some issues).

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

From tsegismo at redhat.com  Wed May 13 15:44:53 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 13 May 2015 21:44:53 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>
Message-ID: <5553A9B5.8070206@redhat.com>

Le 13/05/2015 21:11, Stefan Negrea a ?crit :
> Hello Everybody,
>
> With the metrics aggregation work well under way, we have encountered the first case where timezones are important. The task queue [1] that John wrote to be used in the aggregation process is time sensitive. The tasks ran according to a schedule that is predefined; the time relationship also applies to failures, retries, and cancellation. Based on the experience we had with RHQ, not using an UTC timezone can lead to errors and loss of data (for more details visit [2])
>
> I propose to set the default time zone for all the services to UTC. Only allow the concept of a timezone in the UI. This will avoid any problems due to automatic transitions between DST and non-DST times. For example, if the user wants to schedule something 2 weeks from now, let the UI handle the user selection. But when the user action is sent to the backend, it should be expressed in an timezone agnostic manner (eg. milliseconds since Unix Epoch).
>
> The PR [1] sets the default timezone for the JODA library to be UTC for the classloader that contains the metrics service. With the recent discussions about creating a combined Kettle EAR or using a single classloader, that means this setting will extend to all the services in the same classloader that use JODA. And this is just the default, if a service really needs to set another timezone for a date object, it can be done by just specifying the timezone.
>
> We tried to make the change more local in the metrics code, but the approach was error prone. Anybody could make a mistake and instantiate a date object in the current server timezone rather than UTC. This global approach drastically limits inadvertent mistakes.
>
>
> Two questions for the group:
> 1) Does anybody see any issues with using the UTC timezone as default at the services layer?

I think it is error prone to have any joda.Date you create set in the 
UTC timezone, and any util.Date you create in the server timezone.

Also I can't see where the problem to create the joda.Instant objects 
properly in the scheduler utility class. Maybe I'm missing something?

> 2) Should we expand this setting to the JVM (not just JODA)?

-1

To make this properly the JVM must be started with user.timezone 
property set to UTC. Otherwise we don't control what happens at the 
server level or in libraries, because the setting is effective only when 
the class is loaded.
In the end, the system would rely on external config.

Also if we do this, it means than most users will have to configure all 
the loggers template, because you usually want your logs printed in the 
timezone of your hosts, but the default templates will print the logs 
for the JVM timezone.

I fear it's not the only annoyance which would show up.

>
>
> [1] Task queue PR  - https://github.com/hawkular/hawkular-metrics/pull/205
> [2] Old RHQ thread - https://lists.fedorahosted.org/pipermail/rhq-devel/2014-November/003709.html
>
>
>
> 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 jsanda at redhat.com  Wed May 13 23:09:26 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 13 May 2015 23:09:26 -0400
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<55532161.70208@redhat.com>
	<692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>
Message-ID: <B2AE7BE5-699E-4EA4-AAF2-2F54227EB52C@redhat.com>

This is interesting. I am not too familiar with ActiveMQ, and I just took a look at http://activemq.apache.org/masterslave.html <http://activemq.apache.org/masterslave.html> that describes the master/slave configurations. To this point I have taken for granted that we have distributed messaging. But I have to ask, how are we planning on setting up/configuring distributed messaging?

Storm does require ZooKeeper and Spark has a cluster manager component which can be ZooKeeper.

> On May 13, 2015, at 8:01 AM, Michael Burman <miburman at redhat.com> wrote:
> 
> Hi,
> 
> More like the bus is only a JMS topic with "distributed" not meaning probably what you hoped for. Since it's based on the ActiveMQ5 it's in HA configuration a single broker with master/slave (which with replicated LevelDB storage would then have ZooKeeper and everything else that's massively complex to manage). So nothing like the networks created by Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark / Cassandra / etc.
> 
> These restrictions create their own headache when it comes to scaling in Kubernetes for example, but I don't think we need to solve this issue quite yet. Creating components without locking them to a JMS is the key forward however as that would allow changing the implementation if requirements dictate such in the future.
> 
>  - Micke
> 
> ----- Original Message -----
> From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 1:03:13 PM
> Subject: Re: [Hawkular-dev] The components, glue and kettle
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/13/2015 11:53 AM, Michael Burman wrote:
>> I disagree with the fact where the actual bus-integration component
>> should reside. The components themselves should have the
>> capabilities of allowing another component to connect to their
>> internal "feeds" but the actual component -> bus  connector should
>> be in the Kettle-repository. Why? The bus-connector is highly
>> dependent on the actual bus implementation. If we would change the
>> bus in any way in terms of implementation or API, it would require
>> changes to every Hawkular component (thus, they wouldn't be
>> decoupled by design) instead of only changing the implementation at
>> the bus-component.
> 
> I haven't worked with the bus yet, but isn't "the bus" just a synonym
> for "a distributed JMS topic" ?
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
> /LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
> Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
> AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
> gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
> f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
> =+U0e
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

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

From gbrown at redhat.com  Thu May 14 03:06:35 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 14 May 2015 03:06:35 -0400 (EDT)
Subject: [Hawkular-dev] Plans for Alerts UI
In-Reply-To: <334C9414-0A3D-4B78-87BF-F6F2628D37F2@redhat.com>
References: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>
	<334C9414-0A3D-4B78-87BF-F6F2628D37F2@redhat.com>
Message-ID: <117987910.16226131.1431587195140.JavaMail.zimbra@redhat.com>

Ok will do. I'll attach some screenshots to the jira, and when UX team are ready to work on it I will do a demo.

Regards
Gary

----- Original Message -----
> > What is the best way to proceed - should I just create a jira for now?
> 
> That is certainly the best start.
> I can imagine that it would be helpful to see some examples
> from RTGov on what you want to achieve and then we work together
> with UxD how this will fit into the overall alert picture.
> 
> Perhaps do a demo of the RTGov side?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Thu May 14 09:27:25 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 14 May 2015 09:27:25 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <B2AE7BE5-699E-4EA4-AAF2-2F54227EB52C@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<55532161.70208@redhat.com>
	<692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>
	<B2AE7BE5-699E-4EA4-AAF2-2F54227EB52C@redhat.com>
Message-ID: <1476556873.16942002.1431610045239.JavaMail.zimbra@redhat.com>

Its been a while since I looked at the different distributed models for ActiveMQ but I thought there was more configurations available than simply master/slave.

I thought you could cluster brokers such that messages sent to one broker, could be received to consumers connected to other brokers and vice versa, with message persistence providing fault tolerance.

IIRC, I do remember in my testing I ran two kettle instances and sending messages via curl to one server was able to distribute those messages to consumers on the other.

As I understand it, isn't master/slave more for failover (that is, if the master goes down, the slave takes over)?

Again, its been a while since I looked into it, but I have to believe as mature as ActiveMQ is, that there are configurations of it we can use for distributed messaging in a way we need. I'm specifically talking about the later versions (like 5.10 we are using currently).

----- Original Message -----
> This is interesting. I am not too familiar with ActiveMQ, and I just took a
> look at http://activemq.apache.org/masterslave.html that describes the
> master/slave configurations. To this point I have taken for granted that we
> have distributed messaging. But I have to ask, how are we planning on
> setting up/configuring distributed messaging?
> 
> Storm does require ZooKeeper and Spark has a cluster manager component which
> can be ZooKeeper.
> 
> 
> 
> 
> On May 13, 2015, at 8:01 AM, Michael Burman < miburman at redhat.com > wrote:
> 
> Hi,
> 
> More like the bus is only a JMS topic with "distributed" not meaning probably
> what you hoped for. Since it's based on the ActiveMQ5 it's in HA
> configuration a single broker with master/slave (which with replicated
> LevelDB storage would then have ZooKeeper and everything else that's
> massively complex to manage). So nothing like the networks created by
> Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark /
> Cassandra / etc.
> 
> These restrictions create their own headache when it comes to scaling in
> Kubernetes for example, but I don't think we need to solve this issue quite
> yet. Creating components without locking them to a JMS is the key forward
> however as that would allow changing the implementation if requirements
> dictate such in the future.
> 
> - Micke
> 
> ----- Original Message -----
> From: "Juraci Paix?o Kr?hling" < jpkroehling at redhat.com >
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 1:03:13 PM
> Subject: Re: [Hawkular-dev] The components, glue and kettle
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/13/2015 11:53 AM, Michael Burman wrote:
> 
> 
> I disagree with the fact where the actual bus-integration component
> should reside. The components themselves should have the
> capabilities of allowing another component to connect to their
> internal "feeds" but the actual component -> bus connector should
> be in the Kettle-repository. Why? The bus-connector is highly
> dependent on the actual bus implementation. If we would change the
> bus in any way in terms of implementation or API, it would require
> changes to every Hawkular component (thus, they wouldn't be
> decoupled by design) instead of only changing the implementation at
> the bus-component.
> 
> I haven't worked with the bus yet, but isn't "the bus" just a synonym
> for "a distributed JMS topic" ?
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
> /LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
> Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
> AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
> gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
> f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
> =+U0e
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jsanda at redhat.com  Thu May 14 10:04:48 2015
From: jsanda at redhat.com (John Sanda)
Date: Thu, 14 May 2015 10:04:48 -0400
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <5553A9B5.8070206@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>
	<5553A9B5.8070206@redhat.com>
Message-ID: <550F4E25-AB83-4097-8C5D-8D1C2D4F5620@redhat.com>


> On May 13, 2015, at 3:44 PM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Le 13/05/2015 21:11, Stefan Negrea a ?crit :
>> Hello Everybody,
>> 
>> With the metrics aggregation work well under way, we have encountered the first case where timezones are important. The task queue [1] that John wrote to be used in the aggregation process is time sensitive. The tasks ran according to a schedule that is predefined; the time relationship also applies to failures, retries, and cancellation. Based on the experience we had with RHQ, not using an UTC timezone can lead to errors and loss of data (for more details visit [2])
>> 
>> I propose to set the default time zone for all the services to UTC. Only allow the concept of a timezone in the UI. This will avoid any problems due to automatic transitions between DST and non-DST times. For example, if the user wants to schedule something 2 weeks from now, let the UI handle the user selection. But when the user action is sent to the backend, it should be expressed in an timezone agnostic manner (eg. milliseconds since Unix Epoch).
>> 
>> The PR [1] sets the default timezone for the JODA library to be UTC for the classloader that contains the metrics service. With the recent discussions about creating a combined Kettle EAR or using a single classloader, that means this setting will extend to all the services in the same classloader that use JODA. And this is just the default, if a service really needs to set another timezone for a date object, it can be done by just specifying the timezone.
>> 
>> We tried to make the change more local in the metrics code, but the approach was error prone. Anybody could make a mistake and instantiate a date object in the current server timezone rather than UTC. This global approach drastically limits inadvertent mistakes.
>> 
>> 
>> Two questions for the group:
>> 1) Does anybody see any issues with using the UTC timezone as default at the services layer?
> 
> I think it is error prone to have any joda.Date you create set in the 
> UTC timezone, and any util.Date you create in the server timezone.
> 
> Also I can't see where the problem to create the joda.Instant objects 
> properly in the scheduler utility class. Maybe I'm missing something?

The challenge is that the time zone configuration is not just limited to a single class. Right now there are only a few places where DateTime objects are created and where the time zone needs to be set. AS the task scheduler code grows, the number of places where we have to worry about configuring the time zone may as well. I think that there are good arguments being made for and against the global setting. 

The one thing I ask right now though is whether we are ok with merging the branch into master while this discussion is ongoing. If we decide that changes are needed, they can be made after the merge. Right now other work is going to be held up until the task-queue branch gets merged.

> 
>> 2) Should we expand this setting to the JVM (not just JODA)?
> 
> -1
> 
> To make this properly the JVM must be started with user.timezone 
> property set to UTC. Otherwise we don't control what happens at the 
> server level or in libraries, because the setting is effective only when 
> the class is loaded.
> In the end, the system would rely on external config.
> 
> Also if we do this, it means than most users will have to configure all 
> the loggers template, because you usually want your logs printed in the 
> timezone of your hosts, but the default templates will print the logs 
> for the JVM timezone.
> 
> I fear it's not the only annoyance which would show up.
> 
>> 
>> 
>> [1] Task queue PR  - https://github.com/hawkular/hawkular-metrics/pull/205 <https://github.com/hawkular/hawkular-metrics/pull/205>
>> [2] Old RHQ thread - https://lists.fedorahosted.org/pipermail/rhq-devel/2014-November/003709.html <https://lists.fedorahosted.org/pipermail/rhq-devel/2014-November/003709.html>
>> 
>> 
>> 
>> Thank you,
>> Stefan Negrea
>> 
>> Software Engineer
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150514/bd46e0c6/attachment-0001.html 

From jshaughn at redhat.com  Thu May 14 11:37:16 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 14 May 2015 11:37:16 -0400
Subject: [Hawkular-dev] Plans for Alerts UI
In-Reply-To: <117987910.16226131.1431587195140.JavaMail.zimbra@redhat.com>
References: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>	<334C9414-0A3D-4B78-87BF-F6F2628D37F2@redhat.com>
	<117987910.16226131.1431587195140.JavaMail.zimbra@redhat.com>
Message-ID: <5554C12C.9040402@redhat.com>


One thing to mention that may not be clear, is that the Hawkular Alerts 
component itself offers no UI, and I don't think there is a plan to do 
anything in that area.  We did provide an initial UI as an interim 
solution and example for Hawkular, and for our own testing.  But I'm not 
sure that is still actively developed or still usable.  We offer only 
the REST interface, Hawkular Bus integration, and the engine at the 
component level.

It's something of a technicality, but with respect to the UI needs being 
discussed, it's really a Hawkular thing, I think.  So the necessary 
hooks and UX input would be at the Hawkular UI level.


On 5/14/2015 3:06 AM, Gary Brown wrote:
> Ok will do. I'll attach some screenshots to the jira, and when UX team are ready to work on it I will do a demo.
>
> Regards
> Gary
>
> ----- Original Message -----
>>> What is the best way to proceed - should I just create a jira for now?
>> That is certainly the best start.
>> I can imagine that it would be helpful to see some examples
>> from RTGov on what you want to achieve and then we work together
>> with UxD how this will fit into the overall alert picture.
>>
>> Perhaps do a demo of the RTGov side?
>> _______________________________________________
>> 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/20150514/7e153c4e/attachment.html 

From gbrown at redhat.com  Thu May 14 11:43:09 2015
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 14 May 2015 11:43:09 -0400 (EDT)
Subject: [Hawkular-dev] Plans for Alerts UI
In-Reply-To: <5554C12C.9040402@redhat.com>
References: <919043715.15974152.1431531990860.JavaMail.zimbra@redhat.com>
	<334C9414-0A3D-4B78-87BF-F6F2628D37F2@redhat.com>
	<117987910.16226131.1431587195140.JavaMail.zimbra@redhat.com>
	<5554C12C.9040402@redhat.com>
Message-ID: <1331753384.16560981.1431618189289.JavaMail.zimbra@redhat.com>

Ok thanks - I'll move the UI jira.

----- Original Message -----
> 
> One thing to mention that may not be clear, is that the Hawkular Alerts
> component itself offers no UI, and I don't think there is a plan to do
> anything in that area. We did provide an initial UI as an interim solution
> and example for Hawkular, and for our own testing. But I'm not sure that is
> still actively developed or still usable. We offer only the REST interface,
> Hawkular Bus integration, and the engine at the component level.
> 
> It's something of a technicality, but with respect to the UI needs being
> discussed, it's really a Hawkular thing, I think. So the necessary hooks and
> UX input would be at the Hawkular UI level.
> 
> 
> On 5/14/2015 3:06 AM, Gary Brown wrote:
> 
> 
> 
> Ok will do. I'll attach some screenshots to the jira, and when UX team are
> ready to work on it I will do a demo.
> 
> Regards
> Gary
> 
> ----- Original Message -----
> 
> 
> 
> 
> 
> What is the best way to proceed - should I just create a jira for now?
> That is certainly the best start.
> I can imagine that it would be helpful to see some examples
> from RTGov on what you want to achieve and then we work together
> with UxD how this will fit into the overall alert picture.
> 
> Perhaps do a demo of the RTGov side?
> _______________________________________________
> hawkular-dev mailing list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From miburman at redhat.com  Thu May 14 13:21:19 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 14 May 2015 13:21:19 -0400 (EDT)
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1476556873.16942002.1431610045239.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>
	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>
	<55532161.70208@redhat.com>
	<692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>
	<B2AE7BE5-699E-4EA4-AAF2-2F54227EB52C@redhat.com>
	<1476556873.16942002.1431610045239.JavaMail.zimbra@redhat.com>
Message-ID: <1746050890.21112007.1431624079389.JavaMail.zimbra@redhat.com>

Hi,

Yes, there's a mode to support routing messages from one broker to another (store and forward). There's however a major limitation to it:

"Note though that a store and forward network is not a solution for message HA; if a broker fails in a Store and Forward network, the messages owned by that broker remain inside the broker's persistent store until the broker comes back online. If you need HA of messages then you need to use Master/Slave described above."

http://activemq.apache.org/how-do-distributed-queues-work.html

  - Micke

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, May 14, 2015 4:27:25 PM
Subject: Re: [Hawkular-dev] The components, glue and kettle

Its been a while since I looked at the different distributed models for ActiveMQ but I thought there was more configurations available than simply master/slave.

I thought you could cluster brokers such that messages sent to one broker, could be received to consumers connected to other brokers and vice versa, with message persistence providing fault tolerance.

IIRC, I do remember in my testing I ran two kettle instances and sending messages via curl to one server was able to distribute those messages to consumers on the other.

As I understand it, isn't master/slave more for failover (that is, if the master goes down, the slave takes over)?

Again, its been a while since I looked into it, but I have to believe as mature as ActiveMQ is, that there are configurations of it we can use for distributed messaging in a way we need. I'm specifically talking about the later versions (like 5.10 we are using currently).

----- Original Message -----
> This is interesting. I am not too familiar with ActiveMQ, and I just took a
> look at http://activemq.apache.org/masterslave.html that describes the
> master/slave configurations. To this point I have taken for granted that we
> have distributed messaging. But I have to ask, how are we planning on
> setting up/configuring distributed messaging?
> 
> Storm does require ZooKeeper and Spark has a cluster manager component which
> can be ZooKeeper.
> 
> 
> 
> 
> On May 13, 2015, at 8:01 AM, Michael Burman < miburman at redhat.com > wrote:
> 
> Hi,
> 
> More like the bus is only a JMS topic with "distributed" not meaning probably
> what you hoped for. Since it's based on the ActiveMQ5 it's in HA
> configuration a single broker with master/slave (which with replicated
> LevelDB storage would then have ZooKeeper and everything else that's
> massively complex to manage). So nothing like the networks created by
> Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark /
> Cassandra / etc.
> 
> These restrictions create their own headache when it comes to scaling in
> Kubernetes for example, but I don't think we need to solve this issue quite
> yet. Creating components without locking them to a JMS is the key forward
> however as that would allow changing the implementation if requirements
> dictate such in the future.
> 
> - Micke
> 
> ----- Original Message -----
> From: "Juraci Paix?o Kr?hling" < jpkroehling at redhat.com >
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 1:03:13 PM
> Subject: Re: [Hawkular-dev] The components, glue and kettle
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/13/2015 11:53 AM, Michael Burman wrote:
> 
> 
> I disagree with the fact where the actual bus-integration component
> should reside. The components themselves should have the
> capabilities of allowing another component to connect to their
> internal "feeds" but the actual component -> bus connector should
> be in the Kettle-repository. Why? The bus-connector is highly
> dependent on the actual bus implementation. If we would change the
> bus in any way in terms of implementation or API, it would require
> changes to every Hawkular component (thus, they wouldn't be
> decoupled by design) instead of only changing the implementation at
> the bus-component.
> 
> I haven't worked with the bus yet, but isn't "the bus" just a synonym
> for "a distributed JMS topic" ?
> 
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
> /LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
> Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
> AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
> gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
> f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
> =+U0e
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

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


From jshaughn at redhat.com  Thu May 14 13:44:30 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 14 May 2015 13:44:30 -0400
Subject: [Hawkular-dev] The components, glue and kettle
In-Reply-To: <1746050890.21112007.1431624079389.JavaMail.zimbra@redhat.com>
References: <838475639.15809290.1431504151413.JavaMail.zimbra@redhat.com>	<1712374383.19511798.1431510794870.JavaMail.zimbra@redhat.com>	<55532161.70208@redhat.com>	<692757413.19614556.1431518511851.JavaMail.zimbra@redhat.com>	<B2AE7BE5-699E-4EA4-AAF2-2F54227EB52C@redhat.com>	<1476556873.16942002.1431610045239.JavaMail.zimbra@redhat.com>
	<1746050890.21112007.1431624079389.JavaMail.zimbra@redhat.com>
Message-ID: <5554DEFE.5020909@redhat.com>


The HornetQ usage in RHQ was the same.  Each broker owned its own 
messages.  So if one broker went down those messages were trapped until 
it came up.  In RHQ this wasn't too terrible because the messaging use 
was all internal.  We'd have to decide about how bad it would be to have 
this happen for bus messages.  I don't think there will be any "free 
lunch" for us in this area.

On 5/14/2015 1:21 PM, Michael Burman wrote:
> Hi,
>
> Yes, there's a mode to support routing messages from one broker to another (store and forward). There's however a major limitation to it:
>
> "Note though that a store and forward network is not a solution for message HA; if a broker fails in a Store and Forward network, the messages owned by that broker remain inside the broker's persistent store until the broker comes back online. If you need HA of messages then you need to use Master/Slave described above."
>
> http://activemq.apache.org/how-do-distributed-queues-work.html
>
>    - Micke
>
> ----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Thursday, May 14, 2015 4:27:25 PM
> Subject: Re: [Hawkular-dev] The components, glue and kettle
>
> Its been a while since I looked at the different distributed models for ActiveMQ but I thought there was more configurations available than simply master/slave.
>
> I thought you could cluster brokers such that messages sent to one broker, could be received to consumers connected to other brokers and vice versa, with message persistence providing fault tolerance.
>
> IIRC, I do remember in my testing I ran two kettle instances and sending messages via curl to one server was able to distribute those messages to consumers on the other.
>
> As I understand it, isn't master/slave more for failover (that is, if the master goes down, the slave takes over)?
>
> Again, its been a while since I looked into it, but I have to believe as mature as ActiveMQ is, that there are configurations of it we can use for distributed messaging in a way we need. I'm specifically talking about the later versions (like 5.10 we are using currently).
>
> ----- Original Message -----
>> This is interesting. I am not too familiar with ActiveMQ, and I just took a
>> look at http://activemq.apache.org/masterslave.html that describes the
>> master/slave configurations. To this point I have taken for granted that we
>> have distributed messaging. But I have to ask, how are we planning on
>> setting up/configuring distributed messaging?
>>
>> Storm does require ZooKeeper and Spark has a cluster manager component which
>> can be ZooKeeper.
>>
>>
>>
>>
>> On May 13, 2015, at 8:01 AM, Michael Burman < miburman at redhat.com > wrote:
>>
>> Hi,
>>
>> More like the bus is only a JMS topic with "distributed" not meaning probably
>> what you hoped for. Since it's based on the ActiveMQ5 it's in HA
>> configuration a single broker with master/slave (which with replicated
>> LevelDB storage would then have ZooKeeper and everything else that's
>> massively complex to manage). So nothing like the networks created by
>> Hazelcast (eg. Vert.x underlying messaging infrastructure) / Storm / Spark /
>> Cassandra / etc.
>>
>> These restrictions create their own headache when it comes to scaling in
>> Kubernetes for example, but I don't think we need to solve this issue quite
>> yet. Creating components without locking them to a JMS is the key forward
>> however as that would allow changing the implementation if requirements
>> dictate such in the future.
>>
>> - Micke
>>
>> ----- Original Message -----
>> From: "Juraci Paix?o Kr?hling" < jpkroehling at redhat.com >
>> To: hawkular-dev at lists.jboss.org
>> Sent: Wednesday, May 13, 2015 1:03:13 PM
>> Subject: Re: [Hawkular-dev] The components, glue and kettle
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 05/13/2015 11:53 AM, Michael Burman wrote:
>>
>>
>> I disagree with the fact where the actual bus-integration component
>> should reside. The components themselves should have the
>> capabilities of allowing another component to connect to their
>> internal "feeds" but the actual component -> bus connector should
>> be in the Kettle-repository. Why? The bus-connector is highly
>> dependent on the actual bus implementation. If we would change the
>> bus in any way in terms of implementation or API, it would require
>> changes to every Hawkular component (thus, they wouldn't be
>> decoupled by design) instead of only changing the implementation at
>> the bus-component.
>>
>> I haven't worked with the bus yet, but isn't "the bus" just a synonym
>> for "a distributed JMS topic" ?
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJVUyFhAAoJECKM1e+fkPrXKekH/2MFNSS+NYqP0v3uCNV3uY+J
>> /LYvrQptAXp/j0bUWkYR8rKPLedFTUiyZsZVW5DuwvwYEDMSDnlllaTKw2aQyawV
>> Z5xErHm4EYW+Q7cv5DO5ANZ3KZKufZhOlFxRYzG+zuZAoHNakWXgAhOqbW557l6R
>> AscC2EKGVmJQnFfjvw8aOaqc/Y2Bh/XuaMVfgGVeMXjpxSAzDP9iuxgfsXe4eEa/
>> gn0tSCVSPvWDfAKrEQOi5G35IKo0SuVVmM2rerww5CrPGXy2bLy25XC0RhXklhMW
>> f3D3ZbIk82Jl8QOOrJer3j2Py2t8s6nSTOPpyHf1+rI/qBICLPHMFvJ9ZgNpIlY=
>> =+U0e
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> 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/20150514/4b48c68e/attachment-0001.html 

From snegrea at redhat.com  Thu May 14 16:48:22 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 14 May 2015 16:48:22 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5553A3FA.3000409@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551FB54.7000408@redhat.com>
	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
	<55523C42.6010607@redhat.com> <555352CA.9040900@redhat.com>
	<5553617A.6050702@redhat.com>
	<888925342.16608947.1431542948105.JavaMail.zimbra@redhat.com>
	<5553A3FA.3000409@redhat.com>
Message-ID: <966502640.17137472.1431636502988.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 13, 2015 2:20:26 PM
> Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> 
> Le 13/05/2015 20:49, Stefan Negrea a ?crit :
> > I will open a ticket against Hawkular Metrics to change the existing tenant
> > query parameter to a matrix parameter.
> 
> Could you update HWKMETRICS-86 instead? I'll add a commit once the
> existing PR[1] has been reviewed.

I created a new JIRA and assigned it to you. I would like to keep track of this as a discrete item since it is going to impact the public API. I would not create a new pull request for this, PR 212 is perfect for this work.

Here is the JIRA: https://issues.jboss.org/browse/HWKMETRICS-97

> 
> Or if there's a need to make the change before I'm back, please let me
> know. I would have to rebase (and possibly fix some issues).
> 
> [1] https://github.com/hawkular/hawkular-metrics/pull/212
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From mithomps at redhat.com  Thu May 14 17:12:23 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 14 May 2015 14:12:23 -0700
Subject: [Hawkular-dev] Github Labels for PR
Message-ID: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>

The Typescript project has really put some thought into PR Labels:

https://github.com/Microsoft/TypeScript/labels <https://github.com/Microsoft/TypeScript/labels>

Thoughts on us using and standardising these across our projects?


? Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150514/64f0cca7/attachment.html 

From mwringe at redhat.com  Thu May 14 18:06:01 2015
From: mwringe at redhat.com (Matthew Wringe)
Date: Thu, 14 May 2015 18:06:01 -0400 (EDT)
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
Message-ID: <1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "mike thompson" <mithomps at redhat.com>
> To: "Discussions around Hawkular development" <Hawkular-dev at lists.jboss.org>
> Sent: Thursday, May 14, 2015 5:12:23 PM
> Subject: [Hawkular-dev] Github Labels for PR
> 
> The Typescript project has really put some thought into PR Labels:
> 
> https://github.com/Microsoft/TypeScript/labels
> 
> Thoughts on us using and standardising these across our projects?

+1 on standardisation

Can this be managed in one place? Or would each of the components have to manage their own list of labels?

From mithomps at redhat.com  Thu May 14 18:43:14 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 14 May 2015 15:43:14 -0700
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
	<1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
Message-ID: <909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>


> On 14 May 2015, at 15:06, Matthew Wringe <mwringe at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "mike thompson" <mithomps at redhat.com>
>> To: "Discussions around Hawkular development" <Hawkular-dev at lists.jboss.org>
>> Sent: Thursday, May 14, 2015 5:12:23 PM
>> Subject: [Hawkular-dev] Github Labels for PR
>> 
>> The Typescript project has really put some thought into PR Labels:
>> 
>> https://github.com/Microsoft/TypeScript/labels
>> 
>> Thoughts on us using and standardising these across our projects?
> 
> +1 on standardisation
> 
> Can this be managed in one place? Or would each of the components have to manage their own list of labels?
Unfortunately, this would have to happen on each git repo (that has PR enabled). The labels are quick to create though and the standard ones would likely remain static. 

This also facilitates faster historical lookup of say ?Documentation? PRs or ?API? PRs. 

If we want to do this, the first step would be to setup a google doc spreadsheet and agree on the labels.

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



From lkrejci at redhat.com  Thu May 14 20:08:13 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 15 May 2015 02:08:13 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <966502640.17137472.1431636502988.JavaMail.zimbra@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5553A3FA.3000409@redhat.com>
	<966502640.17137472.1431636502988.JavaMail.zimbra@redhat.com>
Message-ID: <1925224.TffYcDaaKG@localhost.localdomain>

For me, tenant ID implies authorization - otherwise there's no point in having 
multitenancy.

We use accounts for providing authz for Hawkular components.

Accounts currently only supports passing the persona ID using a header.

In future, other ways might appear.

But the point I try to make here I guess is that the way persona ID/tenant ID 
is passed to the component should be transparent as long as the component uses 
accounts for authz (and I know - metrics is the black sheep of Hawkular ;) ).

Btw. persona ID is an UUID, so using a matrix param, IMHO, would look even 
worse than using the query param which would add the ugliness of it to the end 
of the URI, not occluding the "true" path to the REST resource.

On Thursday, May 14, 2015 16:48:22 Stefan Negrea wrote:
> ----- Original Message -----
> 
> > From: "Thomas Segismont" <tsegismo at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Wednesday, May 13, 2015 2:20:26 PM
> > Subject: Re: [Hawkular-dev] Tenant Id - Not Part of URL
> > 
> > Le 13/05/2015 20:49, Stefan Negrea a ?crit :
> > > I will open a ticket against Hawkular Metrics to change the existing
> > > tenant
> > > query parameter to a matrix parameter.
> > 
> > Could you update HWKMETRICS-86 instead? I'll add a commit once the
> > existing PR[1] has been reviewed.
> 
> I created a new JIRA and assigned it to you. I would like to keep track of
> this as a discrete item since it is going to impact the public API. I would
> not create a new pull request for this, PR 212 is perfect for this work.
> 
> Here is the JIRA: https://issues.jboss.org/browse/HWKMETRICS-97
> 
> > Or if there's a need to make the change before I'm back, please let me
> > know. I would have to rebase (and possibly fix some issues).
> > 
> > [1] https://github.com/hawkular/hawkular-metrics/pull/212
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From miburman at redhat.com  Fri May 15 09:14:36 2015
From: miburman at redhat.com (Michael Burman)
Date: Fri, 15 May 2015 09:14:36 -0400 (EDT)
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
	<1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
	<909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
Message-ID: <1853867662.21938777.1431695676185.JavaMail.zimbra@redhat.com>

Hi,

I hope we're not duplicating the JIRA here? Since we're using JIRA anyway for issues, why not handle the PR status there also?

  -  Micke

----- Original Message -----
From: "mike thompson" <mithomps at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Friday, May 15, 2015 1:43:14 AM
Subject: Re: [Hawkular-dev] Github Labels for PR


> On 14 May 2015, at 15:06, Matthew Wringe <mwringe at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "mike thompson" <mithomps at redhat.com>
>> To: "Discussions around Hawkular development" <Hawkular-dev at lists.jboss.org>
>> Sent: Thursday, May 14, 2015 5:12:23 PM
>> Subject: [Hawkular-dev] Github Labels for PR
>> 
>> The Typescript project has really put some thought into PR Labels:
>> 
>> https://github.com/Microsoft/TypeScript/labels
>> 
>> Thoughts on us using and standardising these across our projects?
> 
> +1 on standardisation
> 
> Can this be managed in one place? Or would each of the components have to manage their own list of labels?
Unfortunately, this would have to happen on each git repo (that has PR enabled). The labels are quick to create though and the standard ones would likely remain static. 

This also facilitates faster historical lookup of say ?Documentation? PRs or ?API? PRs. 

If we want to do this, the first step would be to setup a google doc spreadsheet and agree on the labels.

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


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


From mithomps at redhat.com  Fri May 15 10:18:08 2015
From: mithomps at redhat.com (mike thompson)
Date: Fri, 15 May 2015 07:18:08 -0700
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <1853867662.21938777.1431695676185.JavaMail.zimbra@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
	<1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
	<909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
	<1853867662.21938777.1431695676185.JavaMail.zimbra@redhat.com>
Message-ID: <EC726583-F9F9-47BB-8A8E-2723EF54F761@redhat.com>


> On 15 May 2015, at 06:14, Michael Burman <miburman at redhat.com> wrote:
> 
> Hi,
> 
> I hope we're not duplicating the JIRA here? Since we're using JIRA anyway for issues, why not handle the PR status there also?

We are not duplicating JIRA here, because we are not using PRs for our issue tracking.  We still have PRs, and they still need status labels like the ?Don?t Merge Yet? label that we have now. The typescript example does have some examples of Issue type labels though, so it can be confusing (but we shouldn?t take those labels). 

> 
>  -  Micke
> 
> ----- Original Message -----
> From: "mike thompson" <mithomps at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, May 15, 2015 1:43:14 AM
> Subject: Re: [Hawkular-dev] Github Labels for PR
> 
> 
>> On 14 May 2015, at 15:06, Matthew Wringe <mwringe at redhat.com> wrote:
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "mike thompson" <mithomps at redhat.com>
>>> To: "Discussions around Hawkular development" <Hawkular-dev at lists.jboss.org>
>>> Sent: Thursday, May 14, 2015 5:12:23 PM
>>> Subject: [Hawkular-dev] Github Labels for PR
>>> 
>>> The Typescript project has really put some thought into PR Labels:
>>> 
>>> https://github.com/Microsoft/TypeScript/labels
>>> 
>>> Thoughts on us using and standardising these across our projects?
>> 
>> +1 on standardisation
>> 
>> Can this be managed in one place? Or would each of the components have to manage their own list of labels?
> Unfortunately, this would have to happen on each git repo (that has PR enabled). The labels are quick to create though and the standard ones would likely remain static. 
> 
> This also facilitates faster historical lookup of say ?Documentation? PRs or ?API? PRs. 
> 
> If we want to do this, the first step would be to setup a google doc spreadsheet and agree on the labels.
> 
>> _______________________________________________
>> 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 May 15 11:47:59 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 15 May 2015 17:47:59 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <5553617A.6050702@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>	<5551F3E8.9020507@redhat.com>	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>	<5551FB54.7000408@redhat.com>	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>	<55523C42.6010607@redhat.com>	<555352CA.9040900@redhat.com>
	<5553617A.6050702@redhat.com>
Message-ID: <5556152F.5090904@redhat.com>

Le 13/05/2015 16:36, Thomas Segismont a ?crit :
> Le 13/05/2015 15:34, Matt Wringe a ?crit :
>> Personally I think a matrix parameter makes a lot more sense
>>
>> http://hawkular/metrics;tenant=foo/gauges/....
>>
>> versus
>>
>> http://hawkular/metrics/gauges/....?tenant=foo
>>
>> Always having to specify tenant at the end of the url seems strange to
>> be. Logically I would think that it should be applied to the metrics
>> resource itself and not to all the child resources.
>>
>> Something like this would normally mean that the parameter 'a' is to be
>> applied to the 'foo/bar' resource:
>> http://foo/bar;a=b/baz
>>
>> While, something like this would normally mean that the parameter 'a' is
>> to be applied to the 'foo/bar/baz' resource:
>> http://foo/bar/baz?a=b
>>
>
> I have no strong preference.
>
> Note that the query param is just a fallback, in case a client can't set
> the header (like somebody sending GET requests manually with a browser).

I've worked on this today and there's an issue with the container: it is 
not able to deal with matrix parameters at the root resource level. So I 
had to create a servlet filter to cheat it.

The commit is here:

https://github.com/tsegismont/hawkular-metrics/commit/e4faf1bed71bbeb1b40d58dc3e0a10a3ea73a526

Comments?

From hrupp at redhat.com  Mon May 18 03:55:57 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 18 May 2015 09:55:57 +0200
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
	<1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
	<909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
Message-ID: <79E1BC37-120E-435D-A46B-6678FA06DC2B@redhat.com>

On 15 May 2015, at 0:43, mike thompson wrote:
> If we want to do this, the first step would be to setup a google doc 
> spreadsheet and agree on the labels.

And if agreed upon, document them on the hawkular.org web site.
		

From hrupp at redhat.com  Mon May 18 04:06:27 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 18 May 2015 10:06:27 +0200
Subject: [Hawkular-dev] Tenant Id - Not Part of URL
In-Reply-To: <555352CA.9040900@redhat.com>
References: <1799616218.8541357.1430235896155.JavaMail.zimbra@redhat.com>
	<5551F3E8.9020507@redhat.com>
	<99675118.15770952.1431435930101.JavaMail.zimbra@redhat.com>
	<5551FB54.7000408@redhat.com>
	<501353829.15785045.1431436653986.JavaMail.zimbra@redhat.com>
	<55523C42.6010607@redhat.com> <555352CA.9040900@redhat.com>
Message-ID: <69E47FEB-2750-4BA9-8833-68B7C0F645EC@redhat.com>

On 13 May 2015, at 15:34, Matt Wringe wrote:

> Personally I think a matrix parameter makes a lot more sense
>
> http://hawkular/metrics;tenant=foo/gauges/....
>
> versus
>
> http://hawkular/metrics/gauges/....?tenant=foo
>
> Always having to specify tenant at the end of the url seems strange to
> be. Logically I would think that it should be applied to the metrics
> resource itself and not to all the child resources.

Well.. We had it in the 1st place before the recent change, which made
it very explicit that everything in the url right to it belonged to that 
tenant.
>
> Something like this would normally mean that the parameter 'a' is to be
> applied to the 'foo/bar' resource:
> http://foo/bar;a=b/baz
>
> While, something like this would normally mean that the parameter 'a' is
> to be applied to the 'foo/bar/baz' resource:
> http://foo/bar/baz?a=b

I do not think we may want to have the tenant(id) at "arbitrary" levels
of he resource path (e.g. http://foo/bar/baz;tenant=bla meaning foo/bar
is shared by all tenants, while baz is now for tenant bla), so I see
this as sort of arbitrary.

Using the matrix parameter has the advantage that is omits the ? which
is a meta-character in shell and often needs special encoding (more so the &
in query-parameterS).

It has the disadvantage though, that one has to remember where in the
path it has to go as opposed to the query parameter, where everyone
knows that they end up in the end after the ? and the order of key-value-pairs
can be in random order.

Personally I'd go for a query parameter.

From hrupp at redhat.com  Mon May 18 04:21:03 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 18 May 2015 10:21:03 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <5553A9B5.8070206@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>
	<5553A9B5.8070206@redhat.com>
Message-ID: <828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>

On 13 May 2015, at 21:44, Thomas Segismont wrote:
>
>> 2) Should we expand this setting to the JVM (not just JODA)?
>
> In the end, the system would rely on external config.

Don't we do that in several places already? 
Where do you see the issue to put that property in
standalone.sh (.conf) ?

If we run metrics inside of e.g. OpenShift. Do we have enough
control to run "our" TZ-setting? What if all other parts of OpenShift
(incl. metrics feeds) run in Boston-time - how will we deal with that?

> Also if we do this, it means than most users will have to configure all
> the loggers template, because you usually want your logs printed in

Which templates do you mean here?

For the Hawkular-services, could we have a common 
time module, that does the right think when you do

java.util.Date now = HawkularTimeService.getNow();

instead of

java.util.Date now = new Date();


From tsegismo at redhat.com  Mon May 18 04:33:53 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 18 May 2015 10:33:53 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>	<5553A9B5.8070206@redhat.com>
	<828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>
Message-ID: <5559A3F1.2060708@redhat.com>

Le 18/05/2015 10:21, Heiko W.Rupp a ?crit :
> On 13 May 2015, at 21:44, Thomas Segismont wrote:
>>
>>> 2) Should we expand this setting to the JVM (not just JODA)?
>>
>> In the end, the system would rely on external config.
>
> Don't we do that in several places already?

I don't think so.

> Where do you see the issue to put that property in
> standalone.sh (.conf) ?

Because it wouldn't be configuration of the system, it would be a 
requirement of the system.

>
> If we run metrics inside of e.g. OpenShift. Do we have enough
> control to run "our" TZ-setting? What if all other parts of OpenShift
> (incl. metrics feeds) run in Boston-time - how will we deal with that?
>
>> Also if we do this, it means than most users will have to configure all
>> the loggers template, because you usually want your logs printed in
>
> Which templates do you mean here?

What log4j calls "patterns" for pattern layouts.

From hrupp at redhat.com  Mon May 18 06:07:31 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 18 May 2015 12:07:31 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <5559A3F1.2060708@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>
	<5553A9B5.8070206@redhat.com>
	<828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>
	<5559A3F1.2060708@redhat.com>
Message-ID: <85AFA878-44FA-4532-BF58-B2CE8FACE411@redhat.com>

On 18 May 2015, at 10:33, Thomas Segismont wrote:
>>> Also if we do this, it means than most users will have to configure all
>>> the loggers template, because you usually want your logs printed in
>>
>> Which templates do you mean here?
>
> What log4j calls "patterns" for pattern layouts.

Yes :-)  
What I meant is for the loggers of ours software.
Or of the clients like managed WildFly servers.
If the later - wouldn't they need to modify something
anyway to send it to us?

 Heiko

From tsegismo at redhat.com  Mon May 18 07:46:10 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 18 May 2015 13:46:10 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <85AFA878-44FA-4532-BF58-B2CE8FACE411@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>	<5553A9B5.8070206@redhat.com>	<828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>	<5559A3F1.2060708@redhat.com>
	<85AFA878-44FA-4532-BF58-B2CE8FACE411@redhat.com>
Message-ID: <5559D102.2020507@redhat.com>

Le 18/05/2015 12:07, Heiko W.Rupp a ?crit :
> On 18 May 2015, at 10:33, Thomas Segismont wrote:
>>>> >>>Also if we do this, it means than most users will have to configure all
>>>> >>>the loggers template, because you usually want your logs printed in
>>> >>
>>> >>Which templates do you mean here?
>> >
>> >What log4j calls "patterns" for pattern layouts.
> Yes:-)
> What I meant is for the loggers of ours software.
> Or of the clients like managed WildFly servers.
> If the later - wouldn't they need to modify something
> anyway to send it to us?

The clients issue is something I was concerned about too. But we had a 
conversation with Stefan and as long as clients send UNIX timestamps, 
everything should work fine (time since Jan,1 1970 00:00:00 UTC, 
regardless of the resolution).

If we start to accept instant information from clients in the form of 
dates, then we'll need to make sure they send the TZ info as well.

From mithomps at redhat.com  Mon May 18 09:45:06 2015
From: mithomps at redhat.com (mike thompson)
Date: Mon, 18 May 2015 06:45:06 -0700
Subject: [Hawkular-dev] Github Labels for PR
In-Reply-To: <79E1BC37-120E-435D-A46B-6678FA06DC2B@redhat.com>
References: <EEF90E85-CC92-4588-9CBD-04C04C6262A1@redhat.com>
	<1470721365.19973208.1431641161669.JavaMail.zimbra@redhat.com>
	<909BD1D8-5233-48E5-BC72-233232BC2635@redhat.com>
	<79E1BC37-120E-435D-A46B-6678FA06DC2B@redhat.com>
Message-ID: <317DDAF4-F611-4B93-AC2A-10776D4B13CC@redhat.com>


> On 18 May 2015, at 00:55, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 15 May 2015, at 0:43, mike thompson wrote:
>> If we want to do this, the first step would be to setup a google doc 
>> spreadsheet and agree on the labels.
> 
> And if agreed upon, document them on the hawkular.org web site.

On Friday, Villiam found an issue with labels that only admins of the repo can change the labels. This can still be useful for organization of PRs but makes it not as useful for marking the WIP or ?Don?t Merge Yet? for non-admins.


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



From jshaughn at redhat.com  Mon May 18 17:20:24 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 18 May 2015 17:20:24 -0400
Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
Message-ID: <555A5798.4020502@redhat.com>


I was getting really tired of checkstyle complaining about line-too-long 
and trailing spaces for Java comment lines.  I altered the config file 
(attached) to be more flexible.  But I don't have perms to create a PR 
against hawkular-build-tools.

If you'd like to see this changed maybe chime in and the powers that be 
will apply the change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150518/6d67cf34/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: checkstyle.xml
Type: text/xml
Size: 3644 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150518/6d67cf34/attachment.xml 

From jkremser at redhat.com  Tue May 19 03:28:32 2015
From: jkremser at redhat.com (Jiri Kremser)
Date: Tue, 19 May 2015 03:28:32 -0400 (EDT)
Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
In-Reply-To: <555A5798.4020502@redhat.com>
References: <555A5798.4020502@redhat.com>
Message-ID: <1354505015.999721.1432020512359.JavaMail.zimbra@redhat.com>

Hi,
  the change is basically the same as this PR https://github.com/hawkular/hawkular-build-tools/pull/10
I can re-open it, however, I am pretty fine with using -Dcheckstyle.skip all the time and do the dirty work only once before the commit.

jk

----- Original Message -----
| From: "Jay Shaughnessy" <jshaughn at redhat.com>
| To: hawkular-dev at lists.jboss.org
| Sent: Monday, 18 May, 2015 11:20:24 PM
| Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
| 
| 
| I was getting really tired of checkstyle complaining about line-too-long and
| trailing spaces for Java comment lines. I altered the config file (attached)
| to be more flexible. But I don't have perms to create a PR against
| hawkular-build-tools.
| 
| If you'd like to see this changed maybe chime in and the powers that be will
| apply the change.
| 
| _______________________________________________
| hawkular-dev mailing list
| hawkular-dev at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/hawkular-dev
| 

From gbrown at redhat.com  Tue May 19 03:50:40 2015
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 19 May 2015 03:50:40 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular alternative to nest
In-Reply-To: <5351784.956442.1432021545879.JavaMail.zimbra@redhat.com>
Message-ID: <1202880215.963427.1432021840397.JavaMail.zimbra@redhat.com>

Hi

I know that nest is going to be merged into hawkular, but wondering whether within hawkular the distribution can be built in two layers:

1) Bus + Accounts - i.e. the core shared "container"

2) Everything else added to (1)


This way, all of the components that will be built into (2), have the opportunity to perform local testing by building a distribution based on (1), without having the potential impact from other components not required for their component tests, and also not having to overwrite its own component in (2).

Although this is similar to the nest/hawkular approach used before, the benefit is that both of these layers would be managed in the hawkular repo and therefore should be easier to maintain.

Regards
Gary

From hrupp at redhat.com  Tue May 19 07:53:23 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 19 May 2015 13:53:23 +0200
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
Message-ID: <4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>

On 4 May 2015, at 14:03, Lukas Krejci wrote:

> In my mind almost anything "is changing like a metric", because 
> everything changes over time.

Well. Then lets stop your project and make metrics store inventory
data :;->


> Also IMHO  "key-value pairs" are just JSON. I think that the 
> structured data
> support for configs and operation params served us well in RHQ.

I don't say that the structured data in RHQ is by itself bad (the 
implementation
has IMO room for improvement). I also don't say that the traits in RHQ
are a bad thing.
But: with traits and configuration we have some very similar concepts
that have in RHQ some very different implementation.

> So IMHO we need a time-series store for structured data. I am not sure 
> inventory
> is that -  it is good for storing relationships among entities but I 
> am not
> sure if it is well suited for storing (versioned) structured data.

I do not think that each single property needs to be a separate object.
I can imagine that we keep one (JSON) object per version (with some 
additional
metadata) and the respective "client" of the store know how to deal with 
it.
My understanding was that Inventory can have such a list of things
hanging on a resource.

The question remains though if inventory is the right place or metrics.
Also for Traits, I think we should not (like for Availability) store the 
whole
string every 20sec, but only store an update when a change occurred (1),
which may or may be applicable for configuration too. In fact RHQ had
logic inside the agents to only send updates when it detected changes.
Also Traits are most likely r/o, while configuration data may be 
modified from
the UI.

1) And perhaps the last time the old version was still detected.


From hrupp at redhat.com  Tue May 19 08:03:30 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 19 May 2015 14:03:30 +0200
Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
In-Reply-To: <1354505015.999721.1432020512359.JavaMail.zimbra@redhat.com>
References: <555A5798.4020502@redhat.com>
	<1354505015.999721.1432020512359.JavaMail.zimbra@redhat.com>
Message-ID: <CD829592-C9C6-488A-887F-9BDB5E993005@redhat.com>

On 19 May 2015, at 9:28, Jiri Kremser wrote:

> the change is basically the same as this PR 
> https://github.com/hawkular/hawkular-build-tools/pull/10
> I can re-open it, however, I am pretty fine with using 
> -Dcheckstyle.skip all the time and do the dirty work only once before 
> the commit.

I sort of think this is wrong, that one has to specify -D*.skip to get
things done. People will put -D*.skip in settings.xml or a shell alias
and then the commit/push will have the bad changes.
If everyone says, that

| I was getting really tired of checkstyle complaining about 
line-too-long and
| trailing spaces for Java comment lines. I altered the config file 
(attached)

then we should fix the rules. And not have everyone bend them.

From lkrejci at redhat.com  Tue May 19 09:01:50 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 19 May 2015 15:01:50 +0200
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
	<4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
Message-ID: <3086859.cgacYzY7Wb@localhost.localdomain>

On Tuesday, May 19, 2015 13:53:23 Heiko W.Rupp wrote:
> On 4 May 2015, at 14:03, Lukas Krejci wrote:
> > In my mind almost anything "is changing like a metric", because
> > everything changes over time.
> 
> Well. Then lets stop your project and make metrics store inventory
> data :;->
> 
> > Also IMHO  "key-value pairs" are just JSON. I think that the
> > structured data
> > support for configs and operation params served us well in RHQ.
> 
> I don't say that the structured data in RHQ is by itself bad (the
> implementation
> has IMO room for improvement). I also don't say that the traits in RHQ
> are a bad thing.
> But: with traits and configuration we have some very similar concepts
> that have in RHQ some very different implementation.
> 
> > So IMHO we need a time-series store for structured data. I am not sure
> > inventory
> > is that -  it is good for storing relationships among entities but I
> > am not
> > sure if it is well suited for storing (versioned) structured data.
> 
> I do not think that each single property needs to be a separate object.
> I can imagine that we keep one (JSON) object per version (with some
> additional
> metadata) and the respective "client" of the store know how to deal with
> it.
> My understanding was that Inventory can have such a list of things
> hanging on a resource.
> 

Yes, it can, so in another words inventory can very well be used for storing 
traits or config or whatever.

I think the main difference between inventory or metrics being used for 
storing these is that of the focus of each component.

In my mind, inventory is primarily focused on displaying relationships and 
properties of different entities *at some point in time*.

Metrics on the other hand is mainly focused on displaying the evolution of 
values of a metric *over time*.

While you can certainly use inventory to build your view of changes over time, 
it will probably not be optimized for that use-case. Likewise, if you would 
like to use metrics to show you values of a number of metrics at some precise 
point in time, it might not be optimized for that (and yes, this is a wild 
guess of someone who doesn't know metrics at all ;) ).

But in the end, if we decide inventory is the best candidate for doing this, I 
hope it can be bent to do what we need in some reasonable way.

> The question remains though if inventory is the right place or metrics.
> Also for Traits, I think we should not (like for Availability) store the
> whole
> string every 20sec, but only store an update when a change occurred (1),
> which may or may be applicable for configuration too. In fact RHQ had
> logic inside the agents to only send updates when it detected changes.
> Also Traits are most likely r/o, while configuration data may be
> modified from
> the UI.
> 
> 1) And perhaps the last time the old version was still detected.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jsanda at redhat.com  Tue May 19 09:16:41 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 19 May 2015 09:16:41 -0400
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
	<4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
Message-ID: <3F3CAE9A-B614-432F-AF38-E993DC2146C1@redhat.com>


> On May 19, 2015, at 7:53 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 4 May 2015, at 14:03, Lukas Krejci wrote:
> 
>> In my mind almost anything "is changing like a metric", because 
>> everything changes over time.
> 
> Well. Then lets stop your project and make metrics store inventory
> data :;->

I agree with Lukas. At lease in RHQ, we treated most things as time series because we are interested in changes over time. Metrics is one type of time series.

> 
> 
>> Also IMHO  "key-value pairs" are just JSON. I think that the 
>> structured data
>> support for configs and operation params served us well in RHQ.
> 
> I don't say that the structured data in RHQ is by itself bad (the 
> implementation
> has IMO room for improvement). I also don't say that the traits in RHQ
> are a bad thing.
> But: with traits and configuration we have some very similar concepts
> that have in RHQ some very different implementation.
> 
>> So IMHO we need a time-series store for structured data. I am not sure 
>> inventory
>> is that -  it is good for storing relationships among entities but I 
>> am not
>> sure if it is well suited for storing (versioned) structured data.
> 
> I do not think that each single property needs to be a separate object.
> I can imagine that we keep one (JSON) object per version (with some 
> additional
> metadata) and the respective "client" of the store know how to deal with 
> it.
> My understanding was that Inventory can have such a list of things
> hanging on a resource.
> 
> The question remains though if inventory is the right place or metrics.
> Also for Traits, I think we should not (like for Availability) store the 
> whole
> string every 20sec, but only store an update when a change occurred (1),
> which may or may be applicable for configuration too. In fact RHQ had
> logic inside the agents to only send updates when it detected changes.
> Also Traits are most likely r/o, while configuration data may be 
> modified from
> the UI.
> 
> 1) And perhaps the last time the old version was still detected.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jshaughn at redhat.com  Tue May 19 09:23:34 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 19 May 2015 09:23:34 -0400
Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
In-Reply-To: <1354505015.999721.1432020512359.JavaMail.zimbra@redhat.com>
References: <555A5798.4020502@redhat.com>
	<1354505015.999721.1432020512359.JavaMail.zimbra@redhat.com>
Message-ID: <555B3956.8050102@redhat.com>


Hi Jiri,

I was unaware of that PR, sorry.  I see now there has been previous 
debate on this topic.  My config changes also dealt with block comments 
and trailing spaces.  I suppose I should commit to the existing PR 
branch.  The -Dcheckstyle.skip is fine, I use that along with 
license.skip, just to speed things up while developing.  But it's not 
the same as changing the policy we have in place.  I'd argue that 
comments should not be subject to line length or trailing whitespace 
constraints, and that is why I made the change.  We can keep things as 
is, but if no one really cares I'd rather the change go in.

On 5/19/2015 3:28 AM, Jiri Kremser wrote:
> Hi,
>    the change is basically the same as this PR https://github.com/hawkular/hawkular-build-tools/pull/10
> I can re-open it, however, I am pretty fine with using -Dcheckstyle.skip all the time and do the dirty work only once before the commit.
>
> jk
>
> ----- Original Message -----
> | From: "Jay Shaughnessy" <jshaughn at redhat.com>
> | To: hawkular-dev at lists.jboss.org
> | Sent: Monday, 18 May, 2015 11:20:24 PM
> | Subject: [Hawkular-dev] relaxing checkstyle on java comment lines
> |
> |
> | I was getting really tired of checkstyle complaining about line-too-long and
> | trailing spaces for Java comment lines. I altered the config file (attached)
> | to be more flexible. But I don't have perms to create a PR against
> | hawkular-build-tools.
> |
> | If you'd like to see this changed maybe chime in and the powers that be will
> | apply the change.
> |
> | _______________________________________________
> | 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/20150519/5eeb58e3/attachment.html 

From mwringe at redhat.com  Tue May 19 09:32:52 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Tue, 19 May 2015 09:32:52 -0400
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <5559D102.2020507@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>	<5553A9B5.8070206@redhat.com>	<828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>	<5559A3F1.2060708@redhat.com>	<85AFA878-44FA-4532-BF58-B2CE8FACE411@redhat.com>
	<5559D102.2020507@redhat.com>
Message-ID: <555B3B84.2050506@redhat.com>



On 18/05/15 07:46 AM, Thomas Segismont wrote:
> Le 18/05/2015 12:07, Heiko W.Rupp a ?crit :
>> On 18 May 2015, at 10:33, Thomas Segismont wrote:
>>>>>>>> Also if we do this, it means than most users will have to configure all
>>>>>>>> the loggers template, because you usually want your logs printed in
>>>>>> Which templates do you mean here?
>>>> What log4j calls "patterns" for pattern layouts.
>> Yes:-)
>> What I meant is for the loggers of ours software.
>> Or of the clients like managed WildFly servers.
>> If the later - wouldn't they need to modify something
>> anyway to send it to us?
> The clients issue is something I was concerned about too. But we had a
> conversation with Stefan and as long as clients send UNIX timestamps,
> everything should work fine (time since Jan,1 1970 00:00:00 UTC,
> regardless of the resolution).
>

For the timestamps, are you just looking at just seconds since the 
epoch, milliseconds, nanoseconds? Is the timestamp going to just be a 
simple numeric value that is passed (eg we can only ever pass 
milliseconds since epoch) or something slightly more complex which 
includes the resolution type?

And I assume that the machines internal clock being properly set and 
periodically synchronized is outside of the scope of what Hawkular wants 
to do.

From hrupp at redhat.com  Tue May 19 09:34:58 2015
From: hrupp at redhat.com (hrupp at redhat.com)
Date: Tue, 19 May 2015 13:34:58 +0000
Subject: [Hawkular-dev] [Update] Hawkular-Team Update
Message-ID: <f46d0443063c6aa6a205166f6065@google.com>

To reinvite people

Sie wurden f?r den folgenden Termin eingeladen.

Titel: Hawkular-Team Update
This is a all-Hawkular team meeting to give updates where we are and so on.

This is *open to the public*.

Location:
on bluejeans:  https://redhat.bluejeans.com/hrupp/

or alternatively teleconference Reservationless+ , passcode 204 2160 481

You can find Dial-In telephone numbers here:  
https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481

RedHat internal short dial numbers are 16666 and 15555 (and probably  
others, depends on your location)
Wann: Di 19. Mai 2015 3:30PM - 4PM Berlin
Wo: pc 204 2160 481
Wer
     * Heiko Rupp - Organisator
     * miburman at redhat.com
     * tsegismo at redhat.com
     * hawkular-dev at lists.jboss.org
     * gbrown at redhat.com
     * lkrejci at redhat.com
     * snegrea at redhat.com
     * jcosta at redhat.com
     * theute at redhat.com
     * amendonc at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150519/ea3d01cd/attachment-0001.html 

From hrupp at redhat.com  Tue May 19 10:11:05 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 19 May 2015 16:11:05 +0200
Subject: [Hawkular-dev] Tenant Id
Message-ID: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>

Hi,

as this discussion is going on and the other components need to adapt, 
we need to come to
an end.

The preferred form is to have the Tenant id in the header as:

Hawkular-Tenant: acme.org

This has been agreed upon by everyone I think and been committed to
hawkular-metrics yesterday as 
https://issues.jboss.org/browse/HWKMETRICS-86

Now the question is if we need a fallback in the case a client can not 
supply a
header.
Following some discussion here and on irc yesterday, a queryParameter
(?tenantid=acme.org) seems to be preferred over a matrix parameter.

Last but not least is the question if we need that fallback at all.
My litmus test here is always the usage via curl.

As curl allows to pass headers via -H "Hawkular-tenant: acme.org" I can
imagine not using a fallback at all.

Hawkular itself needs to check if a tenant is provided and otherwise 
reject the request with a
403 error code, providing a "missing Hawkular-Tenant" reason phrase.
While a 403 has a slightly different meaning, a 401 code is not 
applicable, as for a 401 the
response must indicate a challenge to be met for successful 
authentication.

If a tenant header is provided, but does not match a known tenant we 
should probably
return a 404 not found - I am not sure on this one though. Perhaps a 403 
with different reason
phrase is even better.

In cases where there is only one default tenant (e.g. metrics running 
standalone), the
check for the provided tenant can be omitted.

For fallback / non-fallback I've created a doodle: 
http://doodle.com/extrm4zreh25hhx3
Please respond until 5/20 EOD

From mwringe at redhat.com  Tue May 19 17:19:40 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Tue, 19 May 2015 17:19:40 -0400
Subject: [Hawkular-dev] Hawkular image and the docker hub registry
Message-ID: <555BA8EC.80200@redhat.com>

There are a few images we should push out under the 'hawkular' 
organization account on docker hub:

- hawkular-metrics
- hawkular-cassandra
- hawkular-heapster*

*: only until https://github.com/GoogleCloudPlatform/heapster/pull/284 
is closed

If there are no objections, I will create those images soon under the 
'hawkular' account.

Initially, it will probably set it up as an automated docker hub build 
(since we can get it up and running very quickly). But we should really 
change it so that we build the images ourselves as part of the CI build 
and push the images out to docker hub. This will keep things more inline 
with that the kubernetes application will be expecting and prevent us 
from manually having to update the docker configurations when the 
versions change.

I have no idea how our current CI works, so if someone could help me 
here that we would be great. I am assuming building the docker images 
there will be a simple task.

Thanks,

Matt Wringe


From lkrejci at redhat.com  Tue May 19 17:32:36 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 19 May 2015 17:32:36 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
Message-ID: <1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, 19 May, 2015 4:11:05 PM
> Subject: Re: [Hawkular-dev] Tenant Id
> 
> Hi,
> 
> as this discussion is going on and the other components need to adapt,
> we need to come to
> an end.
> 
> The preferred form is to have the Tenant id in the header as:
> 
> Hawkular-Tenant: acme.org
> 

Is accounts going to change to this format, too?

As far as I understand it, for us, Persona = Tenant. Accounts currently
gets the persona from the "X-Hawkular-Persona" header.

Also, because orgs and people can be renamed, I think we should not use the
name as the identifier of the tenant, but rather the persona ID
which is an UUID.

> This has been agreed upon by everyone I think and been committed to
> hawkular-metrics yesterday as
> https://issues.jboss.org/browse/HWKMETRICS-86
> 
> Now the question is if we need a fallback in the case a client can not
> supply a
> header.
> Following some discussion here and on irc yesterday, a queryParameter
> (?tenantid=acme.org) seems to be preferred over a matrix parameter.
> 
> Last but not least is the question if we need that fallback at all.
> My litmus test here is always the usage via curl.
> 
> As curl allows to pass headers via -H "Hawkular-tenant: acme.org" I can
> imagine not using a fallback at all.
>

+1
 
> Hawkular itself needs to check if a tenant is provided and otherwise
> reject the request with a
> 403 error code, providing a "missing Hawkular-Tenant" reason phrase.
> While a 403 has a slightly different meaning, a 401 code is not
> applicable, as for a 401 the
> response must indicate a challenge to be met for successful
> authentication.
> 

Hmm, good points... I need to change that in Inv..

> If a tenant header is provided, but does not match a known tenant we
> should probably
> return a 404 not found - I am not sure on this one though. Perhaps a 403
> with different reason
> phrase is even better.
> 

I would argue that this will never gonna happen. As far as I recall, our
mantra is Persona = Tenant, which means that whatever tenant we get is an
authenticated user impersonating as given persona - and for that we should
have a tenant.

In fact, inventory (in HWKINVENT-36) auto-creates such tentants because it
assumes a successful authentication and impersonation is enough of a reason
for the tenant to exist.

> In cases where there is only one default tenant (e.g. metrics running
> standalone), the
> check for the provided tenant can be omitted.
> 
> For fallback / non-fallback I've created a doodle:
> http://doodle.com/extrm4zreh25hhx3
> Please respond until 5/20 EOD
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Tue May 19 19:17:38 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 19 May 2015 19:17:38 -0400 (EDT)
Subject: [Hawkular-dev] maven release problem
In-Reply-To: <1703505515.2357798.1432077020807.JavaMail.zimbra@redhat.com>
Message-ID: <650458359.2359947.1432077458204.JavaMail.zimbra@redhat.com>

OK, so I tried to do a release (of the bus/nest components). After a few hours, I hit a brick wall and can't go further. Someone tell me what's wrong.

First off, you need to fix all your javadoc warnings - because the release plugin will fail if you have any javadoc warnings. So I fixed those. I then did:

   mvn clean install -Prelease

and it finished successfully. I then did:

   mvn clean release:clean release:prepare

and it also finished successfully. I now have a 0.0.2 tag and the git repo looks correct. So I then did:

   mvn release:perform

And it failed, like this:

[INFO] [INFO] Hawkular Nest Distribution ......................... FAILURE [  3.184 s]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 02:46 min
[INFO] [INFO] Finished at: 2015-05-19T17:19:38-04:00
[INFO] [INFO] Final Memory: 90M/560M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.1:single (distro-assembly) on project hawkular-nest-distro: Failed to create assembly: Error creating assembly archive distribution: You must set at least one file. -> [Help 1]

I have no idea why this failed when all the other builds were successful. Even Travis finished building successfully! See: http://travis-ci.org/hawkular/hawkular-bus/builds/63241958 ... and FYI: Nexus has a snapshot repo with all of my artifacts except for that last one that failed to build. So Nexus isn't the problem.

How do you debug this? I googled that error message and nothing came up as an obvious fix.

So, after a couple hours, I still have no idea how to do a release successfully, which is odd since I've been told this was supposed to only take me a few seconds to complete :)


From jpkroehling at redhat.com  Wed May 20 02:54:04 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 20 May 2015 08:54:04 +0200
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
Message-ID: <555C2F8C.6050004@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/19/2015 11:32 PM, Lukas Krejci wrote:
> Is accounts going to change to this format, too?

As far as I understand, this is specific to metrics. Accounts already
provides the tenant/persona data based on the auth data *or* via the
header "X-Hawkular-Persona", as you mentioned below.

> As far as I understand it, for us, Persona = Tenant. Accounts
> currently gets the persona from the "X-Hawkular-Persona" header.
> 

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVXC+LAAoJECKM1e+fkPrXfTEIAIBZTOU57+ox4rkyW+GkxK+z
GwpzIB/rkDL3M2l6D0EgTY9GNpeweT9VMssa8TrF0tIOXJXXYOOgadeAVvJYe41i
mHciXro97cChS8ppnel+ss3xihiFfVKRm3PQOyK8eHql3oSZhwaGr1sLlxFe0SUY
9BMC7iyWOPKsf9b447Mk2rZLKWzWA7joGjZ+DjnXtI1Eg8nN4XB1gvvVaVHFQnYn
plAEN5ahLg4F0MqP+y5/Sjoax3Cbl8mczhuGvLTcbi6pPLoV7WG9X0x1ASjG2VzR
DZRdeRz78fvYIHWsXxOa6sy94Kcbi5ntgRllXZXcqWkL1HIjWGr0/7sS+MgWTjw=
=aB9t
-----END PGP SIGNATURE-----

From gbrown at redhat.com  Wed May 20 03:10:13 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 20 May 2015 03:10:13 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <555C2F8C.6050004@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
	<555C2F8C.6050004@redhat.com>
Message-ID: <1860529529.1644657.1432105813944.JavaMail.zimbra@redhat.com>

If the X-Hawkular-Persona header is still required, shouldn't it atleast be changed to Hawkular-Persona, as in a previous email in this thread I believe "X-" prefix is reserved?

Regards
Gary

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/19/2015 11:32 PM, Lukas Krejci wrote:
> > Is accounts going to change to this format, too?
> 
> As far as I understand, this is specific to metrics. Accounts already
> provides the tenant/persona data based on the auth data *or* via the
> header "X-Hawkular-Persona", as you mentioned below.
> 
> > As far as I understand it, for us, Persona = Tenant. Accounts
> > currently gets the persona from the "X-Hawkular-Persona" header.
> > 
> 
> - - Juca.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVXC+LAAoJECKM1e+fkPrXfTEIAIBZTOU57+ox4rkyW+GkxK+z
> GwpzIB/rkDL3M2l6D0EgTY9GNpeweT9VMssa8TrF0tIOXJXXYOOgadeAVvJYe41i
> mHciXro97cChS8ppnel+ss3xihiFfVKRm3PQOyK8eHql3oSZhwaGr1sLlxFe0SUY
> 9BMC7iyWOPKsf9b447Mk2rZLKWzWA7joGjZ+DjnXtI1Eg8nN4XB1gvvVaVHFQnYn
> plAEN5ahLg4F0MqP+y5/Sjoax3Cbl8mczhuGvLTcbi6pPLoV7WG9X0x1ASjG2VzR
> DZRdeRz78fvYIHWsXxOa6sy94Kcbi5ntgRllXZXcqWkL1HIjWGr0/7sS+MgWTjw=
> =aB9t
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Wed May 20 03:17:39 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 20 May 2015 09:17:39 +0200
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <1860529529.1644657.1432105813944.JavaMail.zimbra@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
	<555C2F8C.6050004@redhat.com>
	<1860529529.1644657.1432105813944.JavaMail.zimbra@redhat.com>
Message-ID: <555C3513.6090006@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/20/2015 09:10 AM, Gary Brown wrote:
> If the X-Hawkular-Persona header is still required, shouldn't it
> atleast be changed to Hawkular-Persona, as in a previous email in
> this thread I believe "X-" prefix is reserved?

Yes, I think I've created a JIRA for me about that. But just to be
clear: consumers of Accounts shouldn't worry about this header. It's
parsed and checked by Accounts, which makes a Persona object available
to be injected.

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

iQEcBAEBCAAGBQJVXDUSAAoJECKM1e+fkPrXQQkIAIKU7p3pmLRUiJ7I2VcMWB9r
xh6bgJ77LvfYLp8kL7FCiHJcJkrs023C4CrX04Qs/ucJzHIQ/rGrojj5ckFoSRdU
tlLkUlYQgu9rVqNmw5CIiRyLp7BKhxgkuF2KkeGYOuTeW5vaiE5NCxyyIrjgRi3V
MnFQL88DHNYkFpSUKWe2p1sR4zrbSMIJHxuZmWiy7qFp806u6+z4Yrq9vweu1TX2
GVjEhSWwlGuHAk0/wFNvR5VeqSzN4fLpsJYkhE8VqwlQxiz2otXaw1xoBu84EL5k
Q+cvcXFBWH2MQOyVwgqj9BNvzxVAy7l043/AR8DZI2j/WLipwhDok/vH+h5VhH8=
=tf6s
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Wed May 20 03:28:09 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 20 May 2015 09:28:09 +0200
Subject: [Hawkular-dev] UTC Timezone - Default for Services
In-Reply-To: <555B3B84.2050506@redhat.com>
References: <1049324028.16618608.1431544277714.JavaMail.zimbra@redhat.com>	<5553A9B5.8070206@redhat.com>	<828423AD-7535-4E3A-B5DE-6D757F18D61B@redhat.com>	<5559A3F1.2060708@redhat.com>	<85AFA878-44FA-4532-BF58-B2CE8FACE411@redhat.com>	<5559D102.2020507@redhat.com>
	<555B3B84.2050506@redhat.com>
Message-ID: <555C3789.4010803@redhat.com>

Le 19/05/2015 15:32, Matt Wringe a ?crit :
>
>
> On 18/05/15 07:46 AM, Thomas Segismont wrote:
>> Le 18/05/2015 12:07, Heiko W.Rupp a ?crit :
>>> On 18 May 2015, at 10:33, Thomas Segismont wrote:
>>>>>>>>> Also if we do this, it means than most users will have to configure all
>>>>>>>>> the loggers template, because you usually want your logs printed in
>>>>>>> Which templates do you mean here?
>>>>> What log4j calls "patterns" for pattern layouts.
>>> Yes:-)
>>> What I meant is for the loggers of ours software.
>>> Or of the clients like managed WildFly servers.
>>> If the later - wouldn't they need to modify something
>>> anyway to send it to us?
>> The clients issue is something I was concerned about too. But we had a
>> conversation with Stefan and as long as clients send UNIX timestamps,
>> everything should work fine (time since Jan,1 1970 00:00:00 UTC,
>> regardless of the resolution).
>>
>
> For the timestamps, are you just looking at just seconds since the
> epoch, milliseconds, nanoseconds? Is the timestamp going to just be a
> simple numeric value that is passed (eg we can only ever pass
> milliseconds since epoch) or something slightly more complex which
> includes the resolution type?
>

All Metrics endpoints expect timestamps in milliseconds since the epoch. 
The only exception is the Influx endpoint, where queries support 
instants with a resolution.

For example:
select value from serie1 where time < 20y
Which means:
Load values of serie1 recorded in the 20 years following the epoch


> And I assume that the machines internal clock being properly set and
> periodically synchronized is outside of the scope of what Hawkular wants
> to do.

Right.


From tsegismo at redhat.com  Wed May 20 03:38:20 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 20 May 2015 09:38:20 +0200
Subject: [Hawkular-dev] Hawkular image and the docker hub registry
In-Reply-To: <555BA8EC.80200@redhat.com>
References: <555BA8EC.80200@redhat.com>
Message-ID: <555C39EC.3000905@redhat.com>

Le 19/05/2015 23:19, Matt Wringe a ?crit :
> There are a few images we should push out under the 'hawkular'
> organization account on docker hub:
>
> - hawkular-metrics
> - hawkular-cassandra
> - hawkular-heapster*
>
> *: only until https://github.com/GoogleCloudPlatform/heapster/pull/284
> is closed
>
> If there are no objections, I will create those images soon under the
> 'hawkular' account.
>
> Initially, it will probably set it up as an automated docker hub build
> (since we can get it up and running very quickly). But we should really
> change it so that we build the images ourselves as part of the CI build
> and push the images out to docker hub. This will keep things more inline
> with that the kubernetes application will be expecting and prevent us
> from manually having to update the docker configurations when the
> versions change.
>
> I have no idea how our current CI works, so if someone could help me
> here that we would be great. I am assuming building the docker images
> there will be a simple task.

We use Travis. Travis builds any branch or pull request when it changes. 
You might not be able to build a docker image with Travis. In this case 
you may want to speak to Filip Brychta who has set up some machines from 
QE to work with Git Hub. He could help you to get a machine from the QE 
lab to build docker images.


From lponce at redhat.com  Wed May 20 04:04:48 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 20 May 2015 04:04:48 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <1516793726.2453614.1432108409767.JavaMail.zimbra@redhat.com>
Message-ID: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>

Hello,

We were discussing in the F2F (and I guess it is still an on-going topic) about the components integration in hawkular.

I want to start using accounts with the REST endpoints in alerts and I would like to know where all the components are going to live.

If I am not wrong, I remember two approaches:

- A big hawkular.ear (with all components inside).
- A modules approach.

So, at some point we need to design integration tests to validate that components work well with accounts and I guess we need to decide how to do that.

At the moment, I see that components (metrics, alerts) have integration tests, I don't have the details for metrics, but for alerts what it uses the old nest distribution to put an embedded cassandra + alerts components to run the REST endpoints.

This is useful as JUnit tests are not enough to validate the full scenarios.

Now I think we need to agree which strategy we need to follow.

Thomas Heute and others commented (if I am wrong, please correct me) that is good to have glue code and integration tests inside hawkular, so hawkular project has responsability to put pieces together and validate it is correct.

Gary Brown and others commented (please, if it is not correct, feel free to correct me) that glue code should live in the component repo, as it has more sense to put our modifications there instead to propagate the change across several repo.

I like the option b) that the glue code lives in the component, but I see the benefits of a).

is there a possibility between something in the middle ? A tradeoff between both approaches ?

So I guess we need to find an agreement, if we need to move code it should be done quickly and also we need to test things.

I don't see how to proper integrate accounts without this topic more clear.

(I don't remember there is a final decision in the mailing list, please, point me to that if I missed it).

Thanks a lot,
Lucas


From hrupp at redhat.com  Wed May 20 04:29:42 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 20 May 2015 10:29:42 +0200
Subject: [Hawkular-dev] Kanban and the pull principle
Message-ID: <67A8365D-9E8F-402E-84E8-DA18B7BCAB8D@redhat.com>

Hey,

I was asked something in the lines of "what shall I work on when no one 
assigns tickets to me"?

Some ideas behind Kanban are:

1) stop starting, start finishing
2) pick where you see fit
3) limit work in progress (for those who were at the f2f, remember the 
coin flipping)

Now we have the columns in the workflow (see attachment).
The idea is that tickets flow from left (backlog to right, new to done).

If you see a situation like in the attachment, where there
are (many) issues in "dev coding done" = PR sent state, then
apply idea 1) to help finishing the ticket. Apply idea 2) and pick one 
of
those (only one, applying idea 3) verify and merge it.

Then rinse, repeat.

For principle 2, try to honor the priorities on the tickets.
Also pick something where you feel comfortable with - you have the 
freedom.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2015-04-27 um 20.48.42.png
Type: image/png
Size: 57829 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150520/3758d4d7/attachment-0001.png 

From theute at redhat.com  Wed May 20 04:33:52 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 20 May 2015 10:33:52 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
Message-ID: <555C46F0.6040707@redhat.com>



On 05/20/2015 10:04 AM, Lucas Ponce wrote:
> Hello,
>
> We were discussing in the F2F (and I guess it is still an on-going topic) about the components integration in hawkular.
>
> I want to start using accounts with the REST endpoints in alerts and I would like to know where all the components are going to live.
>
> If I am not wrong, I remember two approaches:
>
> - A big hawkular.ear (with all components inside).
> - A modules approach.

I think the main difference is:
	a - 1 server that scale by adding more servers (same server) in a cluster
	b - "microservices" kind-of architecture were if you need more metrics 
"power" you start new metrics nodes, if you need more alert "power"

While b offers most flexibility, I think this is overkill as it adds a 
lot of complexity to setup. It doesn't match with our target audience.

So I am definitely advocating for "a"


> So, at some point we need to design integration tests to validate that components work well with accounts and I guess we need to decide how to do that.
>
> At the moment, I see that components (metrics, alerts) have integration tests, I don't have the details for metrics, but for alerts what it uses the old nest distribution to put an embedded cassandra + alerts components to run the REST endpoints.
>
> This is useful as JUnit tests are not enough to validate the full scenarios.
>
> Now I think we need to agree which strategy we need to follow.
>
> Thomas Heute and others commented (if I am wrong, please correct me) that is good to have glue code and integration tests inside hawkular, so hawkular project has responsability to put pieces together and validate it is correct.

Correct.

I want the components (as in github repo) to do few things and do them 
well, they are supposed to mature relatively quickly and put in 
"maintenance", while all the actual features of the product belong to 
Hawkular.

If we don't do that, then the "componentization" is just a burden IMO.

IMO the unit tests belong to the components, the integration tests 
belong to Hawkular and Selenium/higher level tests belong to some 
external project. (I forgot if it was explicitly defined by Heiko at the 
f2f).

With or without a bus, it's Hawkular responsibility to "send" metrics to 
Hawkular metrics when something needs to be stored, "send" metrics to 
Hawkular alerts when something needs to be evaluated...

I questioned a while ago if the REST APIs should really belong to the 
component or if they should just be "a set of jars", we definitely need 
a REST API for Hawkular (at least for the UI).

Integration tests in the component don't give a lot of warranty for 
Hawkular itself.

Note: Hawkular Metrics is a bit particular, it has his own delivery as 
well as being part of Hawkular.


> Gary Brown and others commented (please, if it is not correct, feel free to correct me) that glue code should live in the component repo, as it has more sense to put our modifications there instead to propagate the change across several repo.
>
> I like the option b) that the glue code lives in the component, but I see the benefits of a).
>
> is there a possibility between something in the middle ? A tradeoff between both approaches ?
>
> So I guess we need to find an agreement, if we need to move code it should be done quickly and also we need to test things.
>
> I don't see how to proper integrate accounts without this topic more clear.
>
> (I don't remember there is a final decision in the mailing list, please, point me to that if I missed it).

Thanks for bringing this up, I wanted to :)

Thomas

>
> Thanks a lot,
> Lucas
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From gbrown at redhat.com  Wed May 20 04:50:16 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 20 May 2015 04:50:16 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555C46F0.6040707@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
Message-ID: <504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>



----- Original Message -----
> 
> 
> On 05/20/2015 10:04 AM, Lucas Ponce wrote:
> > Hello,
> >
> > We were discussing in the F2F (and I guess it is still an on-going topic)
> > about the components integration in hawkular.
> >
> > I want to start using accounts with the REST endpoints in alerts and I
> > would like to know where all the components are going to live.
> >
> > If I am not wrong, I remember two approaches:
> >
> > - A big hawkular.ear (with all components inside).
> > - A modules approach.
> 
> I think the main difference is:
> 	a - 1 server that scale by adding more servers (same server) in a cluster
> 	b - "microservices" kind-of architecture were if you need more metrics
> "power" you start new metrics nodes, if you need more alert "power"
> 
> While b offers most flexibility, I think this is overkill as it adds a
> lot of complexity to setup. It doesn't match with our target audience.
> 
> So I am definitely advocating for "a"
> 

One issue may be patching the product - if each component has its own deployment (with glue added using overlay), then if a component needs to be patched, it is just a case of replacing that one module.


> 
> > So, at some point we need to design integration tests to validate that
> > components work well with accounts and I guess we need to decide how to do
> > that.
> >
> > At the moment, I see that components (metrics, alerts) have integration
> > tests, I don't have the details for metrics, but for alerts what it uses
> > the old nest distribution to put an embedded cassandra + alerts components
> > to run the REST endpoints.
> >
> > This is useful as JUnit tests are not enough to validate the full
> > scenarios.
> >
> > Now I think we need to agree which strategy we need to follow.
> >
> > Thomas Heute and others commented (if I am wrong, please correct me) that
> > is good to have glue code and integration tests inside hawkular, so
> > hawkular project has responsability to put pieces together and validate it
> > is correct.
> 
> Correct.
> 
> I want the components (as in github repo) to do few things and do them
> well, they are supposed to mature relatively quickly and put in
> "maintenance", while all the actual features of the product belong to
> Hawkular.
> 
> If we don't do that, then the "componentization" is just a burden IMO.

I don't see this as a burden, I think it makes the boundaries between components much cleaner - each component with its integration points can be tested locally before being assembled/configured within hawkular.

> 
> IMO the unit tests belong to the components, the integration tests
> belong to Hawkular and Selenium/higher level tests belong to some
> external project. (I forgot if it was explicitly defined by Heiko at the
> f2f).

I believe the correct separation of tests should be:

Component - unit and component related integration tests - to minimise unnecessary dependencies being introduced and therefore impacting the component tests.

Hawkular - end to end integration and UI tests.

> 
> With or without a bus, it's Hawkular responsibility to "send" metrics to
> Hawkular metrics when something needs to be stored, "send" metrics to
> Hawkular alerts when something needs to be evaluated...
> 
> I questioned a while ago if the REST APIs should really belong to the
> component or if they should just be "a set of jars", we definitely need
> a REST API for Hawkular (at least for the UI).
> 
> Integration tests in the component don't give a lot of warranty for
> Hawkular itself.
> 
> Note: Hawkular Metrics is a bit particular, it has his own delivery as
> well as being part of Hawkular.
>

We also need to consider component reuse. If all of the integration glue code is in hawkular, then any other projects that want to reuse just one component has to depend on artifacts from two repos. If all of the glue code was also in component, then (as with hawkular) the other components simply assemble the required components and configure as required.

Regards
Gary

> 
> > Gary Brown and others commented (please, if it is not correct, feel free to
> > correct me) that glue code should live in the component repo, as it has
> > more sense to put our modifications there instead to propagate the change
> > across several repo.
> >
> > I like the option b) that the glue code lives in the component, but I see
> > the benefits of a).
> >
> > is there a possibility between something in the middle ? A tradeoff between
> > both approaches ?
> >
> > So I guess we need to find an agreement, if we need to move code it should
> > be done quickly and also we need to test things.
> >
> > I don't see how to proper integrate accounts without this topic more clear.
> >
> > (I don't remember there is a final decision in the mailing list, please,
> > point me to that if I missed it).
> 
> Thanks for bringing this up, I wanted to :)
> 
> Thomas
> 
> >
> > Thanks a lot,
> > Lucas
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Wed May 20 04:53:22 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 20 May 2015 04:53:22 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
Message-ID: <982201193.1856254.1432112002025.JavaMail.zimbra@redhat.com>

BTW I sent an email yesterday "Hawkular alternative to nest" related to a possible way to test components with bus+accounts.

----- Original Message -----
> Hello,
> 
> We were discussing in the F2F (and I guess it is still an on-going topic)
> about the components integration in hawkular.
> 
> I want to start using accounts with the REST endpoints in alerts and I would
> like to know where all the components are going to live.
> 
> If I am not wrong, I remember two approaches:
> 
> - A big hawkular.ear (with all components inside).
> - A modules approach.
> 
> So, at some point we need to design integration tests to validate that
> components work well with accounts and I guess we need to decide how to do
> that.
> 
> At the moment, I see that components (metrics, alerts) have integration
> tests, I don't have the details for metrics, but for alerts what it uses the
> old nest distribution to put an embedded cassandra + alerts components to
> run the REST endpoints.
> 
> This is useful as JUnit tests are not enough to validate the full scenarios.
> 
> Now I think we need to agree which strategy we need to follow.
> 
> Thomas Heute and others commented (if I am wrong, please correct me) that is
> good to have glue code and integration tests inside hawkular, so hawkular
> project has responsability to put pieces together and validate it is
> correct.
> 
> Gary Brown and others commented (please, if it is not correct, feel free to
> correct me) that glue code should live in the component repo, as it has more
> sense to put our modifications there instead to propagate the change across
> several repo.
> 
> I like the option b) that the glue code lives in the component, but I see the
> benefits of a).
> 
> is there a possibility between something in the middle ? A tradeoff between
> both approaches ?
> 
> So I guess we need to find an agreement, if we need to move code it should be
> done quickly and also we need to test things.
> 
> I don't see how to proper integrate accounts without this topic more clear.
> 
> (I don't remember there is a final decision in the mailing list, please,
> point me to that if I missed it).
> 
> Thanks a lot,
> Lucas
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Wed May 20 05:08:29 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 20 May 2015 11:08:29 +0200
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
Message-ID: <7A9B2B2B-497A-45A1-AD35-264B713AE7FA@redhat.com>

On 19 May 2015, at 23:32, Lukas Krejci wrote:
> Also, because orgs and people can be renamed, I think we should not use the
> name as the identifier of the tenant, but rather the persona ID
> which is an UUID.

Yes. Above example was to explicitly list the header. 

>> If a tenant header is provided, but does not match a known tenant we
>> should probably
>> return a 404 not found - I am not sure on this one though. Perhaps a 403
>> with different reason
>> phrase is even better.
>>
>
> I would argue that this will never gonna happen. As far as I recall, our
> mantra is Persona = Tenant, which means that whatever tenant we get is an
> authenticated user impersonating as given persona - and for that we should
> have a tenant.

A misconfigured feed (e.g. user configuring the WildFly agent and
making a typo) is what I was thinking off. Less the pinger or internal
calls from UI to backend.


From theute at redhat.com  Wed May 20 05:19:49 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 20 May 2015 11:19:49 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
Message-ID: <555C51B5.6030702@redhat.com>



On 05/20/2015 10:50 AM, Gary Brown wrote:
>
>
> ----- Original Message -----
>>
>>
>> On 05/20/2015 10:04 AM, Lucas Ponce wrote:
>>> Hello,
>>>
>>> We were discussing in the F2F (and I guess it is still an on-going topic)
>>> about the components integration in hawkular.
>>>
>>> I want to start using accounts with the REST endpoints in alerts and I
>>> would like to know where all the components are going to live.
>>>
>>> If I am not wrong, I remember two approaches:
>>>
>>> - A big hawkular.ear (with all components inside).
>>> - A modules approach.
>>
>> I think the main difference is:
>> 	a - 1 server that scale by adding more servers (same server) in a cluster
>> 	b - "microservices" kind-of architecture were if you need more metrics
>> "power" you start new metrics nodes, if you need more alert "power"
>>
>> While b offers most flexibility, I think this is overkill as it adds a
>> lot of complexity to setup. It doesn't match with our target audience.
>>
>> So I am definitely advocating for "a"
>>
>
> One issue may be patching the product - if each component has its own deployment (with glue added using overlay), then if a component needs to be patched, it is just a case of replacing that one module.

I don't think it makes a difference, we would want to touch the smallest 
possible part because one-off patches may collide.

>
>
>>
>>> So, at some point we need to design integration tests to validate that
>>> components work well with accounts and I guess we need to decide how to do
>>> that.
>>>
>>> At the moment, I see that components (metrics, alerts) have integration
>>> tests, I don't have the details for metrics, but for alerts what it uses
>>> the old nest distribution to put an embedded cassandra + alerts components
>>> to run the REST endpoints.
>>>
>>> This is useful as JUnit tests are not enough to validate the full
>>> scenarios.
>>>
>>> Now I think we need to agree which strategy we need to follow.
>>>
>>> Thomas Heute and others commented (if I am wrong, please correct me) that
>>> is good to have glue code and integration tests inside hawkular, so
>>> hawkular project has responsability to put pieces together and validate it
>>> is correct.
>>
>> Correct.
>>
>> I want the components (as in github repo) to do few things and do them
>> well, they are supposed to mature relatively quickly and put in
>> "maintenance", while all the actual features of the product belong to
>> Hawkular.
>>
>> If we don't do that, then the "componentization" is just a burden IMO.
>
> I don't see this as a burden, I think it makes the boundaries between components much cleaner - each component with its integration points can be tested locally before being assembled/configured within hawkular.

I think it actually ties more the components together and would require 
more frequent releases of the components.
>
>>
>> IMO the unit tests belong to the components, the integration tests
>> belong to Hawkular and Selenium/higher level tests belong to some
>> external project. (I forgot if it was explicitly defined by Heiko at the
>> f2f).
>
> I believe the correct separation of tests should be:
>
> Component - unit and component related integration tests - to minimise unnecessary dependencies being introduced and therefore impacting the component tests.
>
> Hawkular - end to end integration and UI tests.
>
>>
>> With or without a bus, it's Hawkular responsibility to "send" metrics to
>> Hawkular metrics when something needs to be stored, "send" metrics to
>> Hawkular alerts when something needs to be evaluated...
>>
>> I questioned a while ago if the REST APIs should really belong to the
>> component or if they should just be "a set of jars", we definitely need
>> a REST API for Hawkular (at least for the UI).
>>
>> Integration tests in the component don't give a lot of warranty for
>> Hawkular itself.
>>
>> Note: Hawkular Metrics is a bit particular, it has his own delivery as
>> well as being part of Hawkular.
>>
>
> We also need to consider component reuse. If all of the integration glue code is in hawkular, then any other projects that want to reuse just one component has to depend on artifacts from two repos. If all of the glue code was also in component, then (as with hawkular) the other components simply assemble the required components and configure as required.

Which components and reuse where ?
I think a library can be reused, or Hawkular metrics can be reused as 
standalone project. I hardly think that a component depending on the bus 
would be reused by anyone.

Thomas

>
> Regards
> Gary
>
>>
>>> Gary Brown and others commented (please, if it is not correct, feel free to
>>> correct me) that glue code should live in the component repo, as it has
>>> more sense to put our modifications there instead to propagate the change
>>> across several repo.
>>>
>>> I like the option b) that the glue code lives in the component, but I see
>>> the benefits of a).
>>>
>>> is there a possibility between something in the middle ? A tradeoff between
>>> both approaches ?
>>>
>>> So I guess we need to find an agreement, if we need to move code it should
>>> be done quickly and also we need to test things.
>>>
>>> I don't see how to proper integrate accounts without this topic more clear.
>>>
>>> (I don't remember there is a final decision in the mailing list, please,
>>> point me to that if I missed it).
>>
>> Thanks for bringing this up, I wanted to :)
>>
>> Thomas
>>
>>>
>>> Thanks a lot,
>>> Lucas
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From gbrown at redhat.com  Wed May 20 05:42:27 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 20 May 2015 05:42:27 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555C51B5.6030702@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
Message-ID: <1503643408.1949324.1432114947188.JavaMail.zimbra@redhat.com>


----- Original Message -----
> 
> 
> > One issue may be patching the product - if each component has its own
> > deployment (with glue added using overlay), then if a component needs to
> > be patched, it is just a case of replacing that one module.
> 
> I don't think it makes a difference, we would want to touch the smallest
> possible part because one-off patches may collide.

I guess first point to clear up is where the ear/wars would go. Based on using the nest, my assumption was that hawkular (in whatever form) would be deployed in the modules folder - in which case they would not be exploded, which would make patching more difficult.

However if we are going to be placing the archive(s) in standalone/deployment, then it is not an issue. So we need to clarify which location we are talking about.

> > We also need to consider component reuse. If all of the integration glue
> > code is in hawkular, then any other projects that want to reuse just one
> > component has to depend on artifacts from two repos. If all of the glue
> > code was also in component, then (as with hawkular) the other components
> > simply assemble the required components and configure as required.
> 
> Which components and reuse where ?
> I think a library can be reused, or Hawkular metrics can be reused as
> standalone project. I hardly think that a component depending on the bus
> would be reused by anyone.
> 

One possibility is apiman - I could see them using metrics initially but then wanting alerts to help detect situations and notify users. I guess they would have two options, use hawkular as a complete solution, or metrics+alerts - but then if each component had no bus integration available, they would need to provide that glue themselves.

So maybe it comes down to whether, even though used internally, is the bus considered to be one of the reusable components of the hawkular project?

Regards
Gary


From theute at redhat.com  Wed May 20 05:54:36 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 20 May 2015 11:54:36 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <1503643408.1949324.1432114947188.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<555C46F0.6040707@redhat.com>	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>	<555C51B5.6030702@redhat.com>
	<1503643408.1949324.1432114947188.JavaMail.zimbra@redhat.com>
Message-ID: <555C59DC.8010801@redhat.com>



On 05/20/2015 11:42 AM, Gary Brown wrote:
>
> ----- Original Message -----
>>
>>
>>> One issue may be patching the product - if each component has its own
>>> deployment (with glue added using overlay), then if a component needs to
>>> be patched, it is just a case of replacing that one module.
>>
>> I don't think it makes a difference, we would want to touch the smallest
>> possible part because one-off patches may collide.
>
> I guess first point to clear up is where the ear/wars would go. Based on using the nest, my assumption was that hawkular (in whatever form) would be deployed in the modules folder - in which case they would not be exploded, which would make patching more difficult.
> However if we are going to be placing the archive(s) in standalone/deployment, then it is not an issue. So we need to clarify which location we are talking about.

I think this is a different issue. It can be anywhere in exploded 
format. I am not sure why we have "deployments" in "modules" now that's 
a topic on its own. (related to WF layering)

>>> We also need to consider component reuse. If all of the integration glue
>>> code is in hawkular, then any other projects that want to reuse just one
>>> component has to depend on artifacts from two repos. If all of the glue
>>> code was also in component, then (as with hawkular) the other components
>>> simply assemble the required components and configure as required.
>>
>> Which components and reuse where ?
>> I think a library can be reused, or Hawkular metrics can be reused as
>> standalone project. I hardly think that a component depending on the bus
>> would be reused by anyone.
>>
>
> One possibility is apiman - I could see them using metrics initially but then wanting alerts to help detect situations and notify users. I guess they would have two options, use hawkular as a complete solution, or metrics+alerts - but then if each component had no bus integration available, they would need to provide that glue themselves.

It's likely preferable to use metrics + alerts without the dependency on 
the bus (or use the whole thing)

> So maybe it comes down to whether, even though used internally, is the bus considered to be one of the reusable components of the hawkular project?

For me it isn't.
I can hardly imagine someone willing to bring this piece in their 
architecture. They may have a bus already (and then would want to 
integrate with it) or prefer not to use one at all.

In the same way, I wouldn't integrate something that use some Spring 
dependency injection or Google Guice when I built my solution around 
CDI. (unless I really have no choice)

Thomas

>
> 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 May 20 05:56:13 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 20 May 2015 11:56:13 +0200
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <555C3513.6090006@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>	<555C2F8C.6050004@redhat.com>	<1860529529.1644657.1432105813944.JavaMail.zimbra@redhat.com>
	<555C3513.6090006@redhat.com>
Message-ID: <555C5A3D.8020107@redhat.com>

Le 20/05/2015 09:17, Juraci Paix?o Kr?hling a ?crit :
> On 05/20/2015 09:10 AM, Gary Brown wrote:
>> >If the X-Hawkular-Persona header is still required, shouldn't it
>> >atleast be changed to Hawkular-Persona, as in a previous email in
>> >this thread I believe "X-" prefix is reserved?
> Yes, I think I've created a JIRA for me about that. But just to be
> clear: consumers of Accounts shouldn't worry about this header. It's
> parsed and checked by Accounts, which makes a Persona object available
> to be injected.

Yes, the "Hawkular-Tenant" header is specific to Metrics. When Metrics 
is integrated with Accounts, I expect we will derive the tenant from the 
persona header.

We'll also need to think how to make clients 
(hawkular-agent/ptrans/vertx-monitor) work with both standalone and 
integrated Metrics services.


From miburman at redhat.com  Wed May 20 07:32:56 2015
From: miburman at redhat.com (Michael Burman)
Date: Wed, 20 May 2015 07:32:56 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
Message-ID: <615215917.2374284.1432121576162.JavaMail.zimbra@redhat.com>

> I don't see this as a burden, I think it makes the boundaries between components much cleaner - each component with its integration points can be tested locally before being assembled/configured within hawkular.

I'm failing to see how this is clearing the boundaries when there's a clear dependency on another module - bus. Any changes to bus-integration layer will require fixing all the modules instead of single bus-module. By definition that's coupling and considered bad practise. 

> We also need to consider component reuse. If all of the integration glue code is in hawkular, then any other projects that want to reuse just one component has to depend on artifacts from two repos. If all of the glue code was also in component, then (as with hawkular) the other components simply assemble the required components and configure as required.

I really doubt someone is going to use our bus layer instead of some other module. Our bus layer is based on another product which is what the other party would at most use. Metrics and Alerts are probably the ones that will be used outside Hawkular-proper and the integration between those two components is not necessarily the same that we use. So bus-project really has no need to be reusable, its only purpose is to connect Hawkular-modules.

  - Micke

From gbrown at redhat.com  Wed May 20 07:43:33 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 20 May 2015 07:43:33 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <615215917.2374284.1432121576162.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<615215917.2374284.1432121576162.JavaMail.zimbra@redhat.com>
Message-ID: <1757341202.2031030.1432122213033.JavaMail.zimbra@redhat.com>



----- Original Message -----
> > I don't see this as a burden, I think it makes the boundaries between
> > components much cleaner - each component with its integration points can
> > be tested locally before being assembled/configured within hawkular.
> 
> I'm failing to see how this is clearing the boundaries when there's a clear
> dependency on another module - bus. Any changes to bus-integration layer
> will require fixing all the modules instead of single bus-module. By
> definition that's coupling and considered bad practise.

I guess this is the reason for the difference in opinion - you see bus as a component, where as I see it as plumbing :)

Regards
Gary

From hrupp at redhat.com  Wed May 20 07:53:05 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 20 May 2015 13:53:05 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555C51B5.6030702@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
Message-ID: <28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>

On 20 May 2015, at 11:19, Thomas Heute wrote:
> I think a library can be reused, or Hawkular metrics can be reused as
> standalone project. I hardly think that a component depending on the bus
> would be reused by anyone.

+1

From hrupp at redhat.com  Wed May 20 08:13:09 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 20 May 2015 14:13:09 +0200
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <3F3CAE9A-B614-432F-AF38-E993DC2146C1@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
	<4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
	<3F3CAE9A-B614-432F-AF38-E993DC2146C1@redhat.com>
Message-ID: <588F08E0-D00D-4325-8A15-B84BF64CBC36@redhat.com>

On 19 May 2015, at 15:16, John Sanda wrote:

> I agree with Lukas. At lease in RHQ, we treated most things as time 
> series because we are interested in changes over time. Metrics is one 
> type of time series.

Of course we are interested in changes over time.
That does not imply storing everything as metric, as (to use that
argument too) also did not do in RHQ.

Traits and configuration data got a very separate treatment from
numeric metrics and also need it.

How do you aggregate traits or config objects?

How do you display traits or config objects in charts for gauge data?

From mazz at redhat.com  Wed May 20 08:38:44 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 20 May 2015 08:38:44 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
Message-ID: <2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>

Which is why we agreed at the F2F to have REST endpoints as the component interface that clients would use, but have a "hawkular" assembly that would include extra bus listeners/producers that would talk to other hawkular components when deployed in a Hawkular environment.  This was the dual assembly idea (one with just core pieces, for standalone deployments, and another one that included hawkular glue code that allowed it to run in a hawkular environment).

----- Original Message -----
> On 20 May 2015, at 11:19, Thomas Heute wrote:
> > I think a library can be reused, or Hawkular metrics can be reused as
> > standalone project. I hardly think that a component depending on the bus
> > would be reused by anyone.
> 
> +1
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Wed May 20 08:41:25 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 20 May 2015 08:41:25 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555C59DC.8010801@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<1503643408.1949324.1432114947188.JavaMail.zimbra@redhat.com>
	<555C59DC.8010801@redhat.com>
Message-ID: <158776915.2598287.1432125685652.JavaMail.zimbra@redhat.com>

> I think this is a different issue. It can be anywhere in exploded
> format. I am not sure why we have "deployments" in "modules" now that's
> a topic on its own. (related to WF layering)

That was the recommendation from Brian Stansberry. Brian explicitly told me that Red Hat products should not be shipping deployments in the scanner directory (e.g. standalone/deployments) specifically because they will not be patchable. This is why the nest supports the deployments/ directory - its under modules/ and therefore will be patchable using the WildFly patch mechanism.

From vnguyen at redhat.com  Wed May 20 09:17:44 2015
From: vnguyen at redhat.com (Viet Nguyen)
Date: Wed, 20 May 2015 09:17:44 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular image and the docker hub registry
In-Reply-To: <555BA8EC.80200@redhat.com>
References: <555BA8EC.80200@redhat.com>
Message-ID: <1927161227.1480195.1432127864757.JavaMail.zimbra@redhat.com>

Matt,


I put together a diagram awhile back:

https://docs.google.com/presentation/d/14zqOHOvXAB4uN7W_fWOub3ZD6txiS_Vp9cjUNIlj2yQ/edit?usp=sharing


Kettle build hook:

https://github.com/hawkular/hawkular/blob/master/.travis.yml#L20

Viet


----- Original Message -----
From: "Matt Wringe" <mwringe at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Wednesday, May 20, 2015 6:19:40 AM
Subject: [Hawkular-dev] Hawkular image and the docker hub registry

There are a few images we should push out under the 'hawkular' 
organization account on docker hub:

- hawkular-metrics
- hawkular-cassandra
- hawkular-heapster*

*: only until https://github.com/GoogleCloudPlatform/heapster/pull/284 
is closed

If there are no objections, I will create those images soon under the 
'hawkular' account.

Initially, it will probably set it up as an automated docker hub build 
(since we can get it up and running very quickly). But we should really 
change it so that we build the images ourselves as part of the CI build 
and push the images out to docker hub. This will keep things more inline 
with that the kubernetes application will be expecting and prevent us 
from manually having to update the docker configurations when the 
versions change.

I have no idea how our current CI works, so if someone could help me 
here that we would be great. I am assuming building the docker images 
there will be a simple task.

Thanks,

Matt Wringe

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

From theute at redhat.com  Wed May 20 11:18:17 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 20 May 2015 17:18:17 +0200
Subject: [Hawkular-dev] Spring cleaning
Message-ID: <555CA5B9.3040200@redhat.com>


Some of you may have noticed (sorry for the spam) but I was playing with 
HAWKULAR JIRA.

Few things:
	- Let's use the same terminology for the issues, this is JIRA's 
terminology:
		- Bug - A problem which impairs or prevents the functions of the product.
		- Feature Request - A new feature of the product, which has yet to be 
developed.
		- Task - A task that needs to be done.
		- Enhancement - An enhancement or refactoring of existing functionality

	Try to think from an Hawkular *user* perspective, so that the release 
notes are meaningful. Everything could be a task or enhancement, but 
thinking from a user point of view, changing kettle->dist is a task not 
an enhancement. Adding something that was not possible before for the 
user is a "feature request" not to be considered an enhancement (even 
though it is obviously an enhancement of the project).

	This is my workflow:
		- If a feature is broken, this is a bug (Bonus points if you can tell 
which release was affected, for the moment it's easy as there was no 
release)
		- If a feature didn't exist, it is a feature request
		- If a feature exists and does things faster/better (things changed in 
the UI for better clarity) this is en enhancement
		- If it's something that the end user would not really care about 
(added a test, changed some build stuff), it's a task.

	- tasks/sub-tasks are evil (as they all have the same kind). Instead of 
https://issues.jboss.org/browse/HAWKULAR-123 let's use the 
"Fix-Version(+component)" and properly fill the type. If tasks need to 
be grouped, please use links.

	- before closing an issue, check if the type, component, resolution, 
fix-version are filled and correct. (once closed you can only 
edit/change by reopening the issue and can't do bulk changes)


Thanks, if we all do that, we'll have human readable release notes.

Thomas

From jsanda at redhat.com  Wed May 20 23:23:25 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 20 May 2015 23:23:25 -0400
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <588F08E0-D00D-4325-8A15-B84BF64CBC36@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
	<4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
	<3F3CAE9A-B614-432F-AF38-E993DC2146C1@redhat.com>
	<588F08E0-D00D-4325-8A15-B84BF64CBC36@redhat.com>
Message-ID: <9410C3AD-0DA3-4181-9E55-84C57468DDFD@redhat.com>


> On May 20, 2015, at 8:13 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 19 May 2015, at 15:16, John Sanda wrote:
> 
>> I agree with Lukas. At lease in RHQ, we treated most things as time 
>> series because we are interested in changes over time. Metrics is one 
>> type of time series.
> 
> Of course we are interested in changes over time.
> That does not imply storing everything as metric, as (to use that
> argument too) also did not do in RHQ.
> 
> Traits and configuration data got a very separate treatment from
> numeric metrics and also need it.
> 
> How do you aggregate traits or config objects?
> 
> How do you display traits or config objects in charts for gauge data?

I think you misunderstand what I am suggesting. Think more along the lines of a version control system. Every piece of data that gets persisted has a timestamp associated with it. In general, updating data means persisting a new copy of the data with a new timestamp. Cassandra excels at handling time series data, and again, I am not just talking about metrics. It excels because of the read/write patterns that are common with time series. In RHQ we treated most things as time series as evidence from all of the History entities. Whether it is a trait or some resource configuration, we do not want to store just the latest value, but the changes over time.

From theute at redhat.com  Thu May 21 02:49:18 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 08:49:18 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<555C46F0.6040707@redhat.com>	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>	<555C51B5.6030702@redhat.com>	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
Message-ID: <555D7FEE.1000004@redhat.com>

I don't think this answers the question.

Or at least it's not clear what you suggest in terms of where the 
integration code with the bus should happen.

It's not clear to me what you mean by "standalone deployments".

Thomas



On 05/20/2015 02:38 PM, John Mazzitelli wrote:
> Which is why we agreed at the F2F to have REST endpoints as the component interface that clients would use, but have a "hawkular" assembly that would include extra bus listeners/producers that would talk to other hawkular components when deployed in a Hawkular environment.  This was the dual assembly idea (one with just core pieces, for standalone deployments, and another one that included hawkular glue code that allowed it to run in a hawkular environment).
>
> ----- Original Message -----
>> On 20 May 2015, at 11:19, Thomas Heute wrote:
>>> I think a library can be reused, or Hawkular metrics can be reused as
>>> standalone project. I hardly think that a component depending on the bus
>>> would be reused by anyone.
>>
>> +1
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From mazz at redhat.com  Thu May 21 05:22:04 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 21 May 2015 05:22:04 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555D7FEE.1000004@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C46F0.6040707@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
Message-ID: <947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>

At the F2F breakout session we had, we had talked about doing the following (though I've since heard that this might not be what we are going to do - instead, perhaps use something like war overlays - so take this with a grain of salt):

Each component should have two assemblies - one is a "core" assembly and the other is a "hawkular" assembly

The "core" assembly is the standalone product - for example, this would be H-Metrics that can be deployed on its own, standalone. This is to support our requirement that things like Hawkualr-Metrics must be able to run standalone outside of a full blown Hawkular environment.

The "hawkular" assembly is nothing more than the "core" assembly with an addition jar (or multiple jars, whatever they want to do) that contains the hawkular "glue" code. The "glue" code would be things like CDI listeners, bus listeners, bus producers.

We had come up with a design to allow the "core" assembly to run standalone but if in "hawkular" deployment, that glue code would be the way it hooks into the hawkular environment (e.g. a CDI listener would listen for the component to start up, and install a bus listener to listen for hawkular messages over the bus).

The assembly plugin would merely just add the glue code artifacts (the jar files) to the core build. 

So I envision something like this (as a maven layout) - this is a "psuedo" layout:

hawkular-metrics/parent
                   |
                   |----- core API (jar artifact)
                   |
                   |----- webapp (war artifact)
                   |
                   |----- glue code (jar artifact)
                   |
                   |----- dist

The "dist" maven module would build two assemblies - one that has the webapp+coreAPI ("core") and the other would be "core" + the glue code artifact jar shoved in, say, WEB-INF/lib (this jar is the thing that contains the CDI listeners, bus listeners, bus products, whatever).

Now, if you don't want to put the glue code in each component's repo, just put them wherever and just have a dependency on that glue code artifact in the "dist" maven module for the component that pulls it in.

This is similar to Heiko's idea of taking the Metrics WAR and in the kettle build just crack it open, put the glue code jar in the WEB-INF/lib, and re-archive the war. This design I mention above is just a formalization of that - its just how you would do it without messing with artifacts that come from the maven repo. I personally have a problem with us taking an artifact from the maven repo, cracking it open and modifying it, zipping it back up and THEN using that in the product. I much prefer that we put into the maven repository what we plan on actually deploying and running with. Just seems like there is a risk if our build processes modify artifacts before using them.

There was a concern about classloading issues and that perhaps we need an "uber" ear that wraps all the components. We need someone to experiment with that idea. That is a question we need to answer ("do we need a uber ear in kettle?").

Anyway, that's what we talked about (among other things) in that F2F break out session (which I thought was one of the most productive sessions we had :)


----- Original Message -----
> I don't think this answers the question.
> 
> Or at least it's not clear what you suggest in terms of where the
> integration code with the bus should happen.
> 
> It's not clear to me what you mean by "standalone deployments".
> 
> Thomas
> 
> 
> 
> On 05/20/2015 02:38 PM, John Mazzitelli wrote:
> > Which is why we agreed at the F2F to have REST endpoints as the component
> > interface that clients would use, but have a "hawkular" assembly that
> > would include extra bus listeners/producers that would talk to other
> > hawkular components when deployed in a Hawkular environment.  This was the
> > dual assembly idea (one with just core pieces, for standalone deployments,
> > and another one that included hawkular glue code that allowed it to run in
> > a hawkular environment).
> >
> > ----- Original Message -----
> >> On 20 May 2015, at 11:19, Thomas Heute wrote:
> >>> I think a library can be reused, or Hawkular metrics can be reused as
> >>> standalone project. I hardly think that a component depending on the bus
> >>> would be reused by anyone.
> >>
> >> +1
> >> _______________________________________________
> >> 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  Thu May 21 06:37:28 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 12:37:28 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<555C46F0.6040707@redhat.com>	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>	<555C51B5.6030702@redhat.com>	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
Message-ID: <555DB568.7000502@redhat.com>



On 05/21/2015 11:22 AM, John Mazzitelli wrote:
> At the F2F breakout session we had, we had talked about doing the following (though I've since heard that this might not be what we are going to do - instead, perhaps use something like war overlays - so take this with a grain of salt):
>
> Each component should have two assemblies - one is a "core" assembly and the other is a "hawkular" assembly
>
> The "core" assembly is the standalone product - for example, this would be H-Metrics that can be deployed on its own, standalone. This is to support our requirement that things like Hawkualr-Metrics must be able to run standalone outside of a full blown Hawkular environment.

This is a non-requirement, or only for Metrics. There is definitely no 
requirement that there is a package/runnable instance for each component 
or combination of components,.

> The "hawkular" assembly is nothing more than the "core" assembly with an addition jar (or multiple jars, whatever they want to do) that contains the hawkular "glue" code. The "glue" code would be things like CDI listeners, bus listeners, bus producers.
>
> We had come up with a design to allow the "core" assembly to run standalone but if in "hawkular" deployment, that glue code would be the way it hooks into the hawkular environment (e.g. a CDI listener would listen for the component to start up, and install a bus listener to listen for hawkular messages over the bus).
>
> The assembly plugin would merely just add the glue code artifacts (the jar files) to the core build.
>
> So I envision something like this (as a maven layout) - this is a "psuedo" layout:
>
> hawkular-metrics/parent
>                     |
>                     |----- core API (jar artifact)
>                     |
>                     |----- webapp (war artifact)
>                     |
>                     |----- glue code (jar artifact)
>                     |
>                     |----- dist

Hawkular Metrics is a bad example, it is the only component that we 
would want to run "standalone".

> The "dist" maven module would build two assemblies - one that has the webapp+coreAPI ("core") and the other would be "core" + the glue code artifact jar shoved in, say, WEB-INF/lib (this jar is the thing that contains the CDI listeners, bus listeners, bus products, whatever).
>
> Now, if you don't want to put the glue code in each component's repo, just put them wherever and just have a dependency on that glue code artifact in the "dist" maven module for the component that pulls it in.
>
> This is similar to Heiko's idea of taking the Metrics WAR and in the kettle build just crack it open, put the glue code jar in the WEB-INF/lib, and re-archive the war. This design I mention above is just a formalization of that - its just how you would do it without messing with artifacts that come from the maven repo. I personally have a problem with us taking an artifact from the maven repo, cracking it open and modifying it, zipping it back up and THEN using that in the product. I much prefer that we put into the maven repository what we plan on actually deploying and running with. Just seems like there is a risk if our build processes modify artifacts before using them.
>
> There was a concern about classloading issues and that perhaps we need an "uber" ear that wraps all the components. We need someone to experiment with that idea. That is a question we need to answer ("do we need a uber ear in kettle?").
>
> Anyway, that's what we talked about (among other things) in that F2F break out session (which I thought was one of the most productive sessions we had :)

I am really fearing that we completely lost the focus which is 
*Hawkular* and add unnecessarily burden for non-requirements.
What started as separation of concerns (One part that stores metrics, 
one part that manage alerts, one part that manage an inventory) became 
an a-la-carte project where we would need to produce/maintain/test 
combinations. We just don't have the time for that IMO.


Thomas


>
>
> ----- Original Message -----
>> I don't think this answers the question.
>>
>> Or at least it's not clear what you suggest in terms of where the
>> integration code with the bus should happen.
>>
>> It's not clear to me what you mean by "standalone deployments".
>>
>> Thomas
>>
>>
>>
>> On 05/20/2015 02:38 PM, John Mazzitelli wrote:
>>> Which is why we agreed at the F2F to have REST endpoints as the component
>>> interface that clients would use, but have a "hawkular" assembly that
>>> would include extra bus listeners/producers that would talk to other
>>> hawkular components when deployed in a Hawkular environment.  This was the
>>> dual assembly idea (one with just core pieces, for standalone deployments,
>>> and another one that included hawkular glue code that allowed it to run in
>>> a hawkular environment).
>>>
>>> ----- Original Message -----
>>>> On 20 May 2015, at 11:19, Thomas Heute wrote:
>>>>> I think a library can be reused, or Hawkular metrics can be reused as
>>>>> standalone project. I hardly think that a component depending on the bus
>>>>> would be reused by anyone.
>>>>
>>>> +1
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From mazz at redhat.com  Thu May 21 06:43:41 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 21 May 2015 06:43:41 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555DB568.7000502@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
Message-ID: <996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>

> This is a non-requirement, or only for Metrics. There is definitely no
> requirement that there is a package/runnable instance for each component
> or combination of components,.
>
> I am really fearing that we completely lost the focus which is
> *Hawkular* and add unnecessarily burden for non-requirements.
> What started as separation of concerns (One part that stores metrics,
> one part that manage alerts, one part that manage an inventory) became
> an a-la-carte project where we would need to produce/maintain/test
> combinations. We just don't have the time for that IMO.

OK, that's good to know. Even as recent as the F2F we were talking about deploying components (like alerts) standalone. Which was the whole reason behind the "CDI listener" stuff. But if Metrics is the only standalone component, they can figure out how they want to do that, but all our other components can be assumed to only be running in a full Hawkular environment. That makes some decisions easy. No need to play all these games to get components "pluggable" into the hawkular ecosystem - dual assemblies, or cracking open artifacts and injecting glue code. We can just assume we have dependencies on all the other components and be done with it.

From theute at redhat.com  Thu May 21 06:57:05 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 12:57:05 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>	<555C51B5.6030702@redhat.com>	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>	<555D7FEE.1000004@redhat.com>	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
Message-ID: <555DBA01.7030208@redhat.com>



On 05/21/2015 12:43 PM, John Mazzitelli wrote:
>> This is a non-requirement, or only for Metrics. There is definitely no
>> requirement that there is a package/runnable instance for each component
>> or combination of components,.
>>
>> I am really fearing that we completely lost the focus which is
>> *Hawkular* and add unnecessarily burden for non-requirements.
>> What started as separation of concerns (One part that stores metrics,
>> one part that manage alerts, one part that manage an inventory) became
>> an a-la-carte project where we would need to produce/maintain/test
>> combinations. We just don't have the time for that IMO.
>
> OK, that's good to know. Even as recent as the F2F we were talking about deploying components (like alerts) standalone. Which was the whole reason behind the "CDI listener" stuff. But if Metrics is the only standalone component, they can figure out how they want to do that, but all our other components can be assumed to only be running in a full Hawkular environment. That makes some decisions easy. No need to play all these games to get components "pluggable" into the hawkular ecosystem - dual assemblies, or cracking open artifacts and injecting glue code. We can just assume we have dependencies on all the other components and be done with it.

Exactly.
And let's keep components do 1 thing, do it well. Minimum dependencies 
between components, Hawkular is what bind/glue them together.

Thomas

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

From miburman at redhat.com  Thu May 21 07:50:46 2015
From: miburman at redhat.com (Michael Burman)
Date: Thu, 21 May 2015 07:50:46 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
Message-ID: <11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>

At F2F I got the impression that alerts will most likely be necessary to run with just metrics also - without rest of Hawkular? I'd say it's a good combo to keep those two as "standalone", as there are other alerting components available also (such as Bosun) - which we would probably like to 'compete' with.

  -  Micke

----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, May 21, 2015 1:43:41 PM
Subject: Re: [Hawkular-dev] Hawkular integration

> This is a non-requirement, or only for Metrics. There is definitely no
> requirement that there is a package/runnable instance for each component
> or combination of components,.
>
> I am really fearing that we completely lost the focus which is
> *Hawkular* and add unnecessarily burden for non-requirements.
> What started as separation of concerns (One part that stores metrics,
> one part that manage alerts, one part that manage an inventory) became
> an a-la-carte project where we would need to produce/maintain/test
> combinations. We just don't have the time for that IMO.

OK, that's good to know. Even as recent as the F2F we were talking about deploying components (like alerts) standalone. Which was the whole reason behind the "CDI listener" stuff. But if Metrics is the only standalone component, they can figure out how they want to do that, but all our other components can be assumed to only be running in a full Hawkular environment. That makes some decisions easy. No need to play all these games to get components "pluggable" into the hawkular ecosystem - dual assemblies, or cracking open artifacts and injecting glue code. We can just assume we have dependencies on all the other components and be done with it.
_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

From mazz at redhat.com  Thu May 21 07:50:47 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 21 May 2015 07:50:47 -0400 (EDT)
Subject: [Hawkular-dev] non-snapshot kettle dependencies
In-Reply-To: <910333914.3223409.1432208792148.JavaMail.zimbra@redhat.com>
Message-ID: <2103633236.3225079.1432209047261.JavaMail.zimbra@redhat.com>

We need to schedule the work to get kettle dependent on non-snapshot releases.

I recently released the following that can be used in the kettle build:

hawkular-bus:   0.0.5
hawkular-nest: ls 0.0.5
hawkular-agent: 0.0.2

We need folks to release the following:

hawkular-accounts (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-alerts (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-console (currently kettle uses 1.0.0-SNAPSHOT)
hawkular-inventory (currently kettle uses 0.0.1-SNAPSHOT)

Once those releases are done, we can edit the hawkular/pom.xml to reflect the non-snapshot versions.

From hrupp at redhat.com  Thu May 21 08:42:34 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 21 May 2015 14:42:34 +0200
Subject: [Hawkular-dev] Properties store?
In-Reply-To: <9410C3AD-0DA3-4181-9E55-84C57468DDFD@redhat.com>
References: <00F29776-1CA0-43B2-A1DC-9E17B3BF0A85@redhat.com>
	<706574510.13389309.1430740995914.JavaMail.zimbra@redhat.com>
	<4AB9F337-D940-4CC3-859B-6ADC28E95FB0@redhat.com>
	<3F3CAE9A-B614-432F-AF38-E993DC2146C1@redhat.com>
	<588F08E0-D00D-4325-8A15-B84BF64CBC36@redhat.com>
	<9410C3AD-0DA3-4181-9E55-84C57468DDFD@redhat.com>
Message-ID: <9FCB4F88-ACEA-4242-9B58-56DE9022D43B@redhat.com>


> Think more along the
> lines of a version control system. Every piece of data that gets 
> persisted has a timestamp associated with it. In general, updating

This is exactly what I am thinking of.

> Cassandra excels at handling time series data, and again, I am not 
> just talking about metrics. It excels because of the read/write 
> patterns that are common with time series. In RHQ we treated most 
> things as time series as evidence from all of the History entities. 
> Whether it is a trait or some resource configuration, we do not want 
> to store just the latest value, but the changes over time.

I fully agree here.

And I am not questioning the use of Cassandra for this at all.
In fact Inventory uses C* behind the scenes as well.

My point is rather that traits and configurations are very similar to 
each other,
while trait and numeric metric are less similar.

So the question is still, how and where to deal with that.

If we assume that configuration and traits are just ("arbitrary" long) 
strings,
we need
- de-duplication - we only want to save changes, not every value when it 
is
the same as the previous version
- making sure when expiring after some time, that there is always 
something
left to look at (the value that was first recorded may have never 
changed since)
- probably make sure we record (from time to time) the last time the 
value was seen

"Consumers" on top can then decide that the contents is actually a json-
structure, and translate it to json and a Map to deal with it.

While my gut feeling is that configuration data is "closer" to a 
resource, than
traits, I think at the end both are just one URI away. We could have 
another
component to store those, but having a "string store" inside the metrics 
project
that satisfies the above requirements (and probably more), is probably 
enough.

From mwringe at redhat.com  Thu May 21 09:20:52 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 21 May 2015 09:20:52 -0400
Subject: [Hawkular-dev] Hawkular image and the docker hub registry
In-Reply-To: <1927161227.1480195.1432127864757.JavaMail.zimbra@redhat.com>
References: <555BA8EC.80200@redhat.com>
	<1927161227.1480195.1432127864757.JavaMail.zimbra@redhat.com>
Message-ID: <555DDBB4.6040800@redhat.com>


On 20/05/15 09:17 AM, Viet Nguyen wrote:
> Matt,
>
>
> I put together a diagram awhile back:
>
> https://docs.google.com/presentation/d/14zqOHOvXAB4uN7W_fWOub3ZD6txiS_Vp9cjUNIlj2yQ/edit?usp=sharing
>
>
> Kettle build hook:
>
> https://github.com/hawkular/hawkular/blob/master/.travis.yml#L20

Yes, I have already seen that. If I were to use that approach, I still 
need access to the CI server which I don't current have (or need someone 
to help set that up if I am not allowed access).

The current approach is not something that I find works well for the 
docker containers I am dealing with. I would prefer to build the docker 
images in our CI and then push the binary to the docker repo, rather 
than have the images build using the docker hub automated build system.

But I think setting it up initially using the automated build will at 
least get us something up and running more quickly than trying to figure 
out how to build (and mange) the docker builds within our CI.

- Matt

>
>
> ----- Original Message -----
> From: "Matt Wringe" <mwringe at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 20, 2015 6:19:40 AM
> Subject: [Hawkular-dev] Hawkular image and the docker hub registry
>
> There are a few images we should push out under the 'hawkular'
> organization account on docker hub:
>
> - hawkular-metrics
> - hawkular-cassandra
> - hawkular-heapster*
>
> *: only until https://github.com/GoogleCloudPlatform/heapster/pull/284
> is closed
>
> If there are no objections, I will create those images soon under the
> 'hawkular' account.
>
> Initially, it will probably set it up as an automated docker hub build
> (since we can get it up and running very quickly). But we should really
> change it so that we build the images ourselves as part of the CI build
> and push the images out to docker hub. This will keep things more inline
> with that the kubernetes application will be expecting and prevent us
> from manually having to update the docker configurations when the
> versions change.
>
> I have no idea how our current CI works, so if someone could help me
> here that we would be great. I am assuming building the docker images
> there will be a simple task.
>
> Thanks,
>
> Matt Wringe
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From hrupp at redhat.com  Thu May 21 09:27:19 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 21 May 2015 15:27:19 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
	<11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>
Message-ID: <414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>

On 21 May 2015, at 13:50, Michael Burman wrote:

> it's a good combo to keep those two as "standalone", as there are 
> other alerting components available also (such as Bosun) - which we 
> would probably like to 'compete' with.

Question is though how much we need to take care of this now and not
address it when we need it.

From mwringe at redhat.com  Thu May 21 09:50:37 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 21 May 2015 09:50:37 -0400
Subject: [Hawkular-dev] Spring cleaning
In-Reply-To: <555CA5B9.3040200@redhat.com>
References: <555CA5B9.3040200@redhat.com>
Message-ID: <555DE2AD.6010206@redhat.com>

On 20/05/15 11:18 AM, Thomas Heute wrote:
> 	- before closing an issue, check if the type, component, resolution,
> fix-version are filled and correct. (once closed you can only
> edit/change by reopening the issue and can't do bulk changes)

Is there any way we can configure Jira to require all the fields to be 
set before its closed? Its really easy to forget to set things like the 
version fields.

Speaking of which, what is proper use of 'Fix Version' in Hawkular. Is 
this the version in which we are planning for the issue to be resolved 
(eg set before any work has started on the issue) or the version that 
the bug is actually fixed in (eg set after the code is committed).


From mwringe at redhat.com  Thu May 21 10:02:17 2015
From: mwringe at redhat.com (Matthew Wringe)
Date: Thu, 21 May 2015 10:02:17 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
	<11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>
	<414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>
Message-ID: <553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>

Yeah, I was under the impression that metrics needs to be handled in a special manner since we need to run it differently in OpenShift. Which means when we also add in Alerting to OpenShift, it will also need to be handled in a special manner.

But I guess we can figure that part out when we actually need to add in Alerting.

I think the discussion was also thinking about doing things in a modular manner, where we could have the different components running as individual containers in kubernetes, and then spin up (or down) more containers as needed. But it looks like the decision is to not to go with that approach for scaling the main Hawkular server.



----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Thursday, May 21, 2015 9:27:19 AM
> Subject: Re: [Hawkular-dev] Hawkular integration
> 
> On 21 May 2015, at 13:50, Michael Burman wrote:
> 
> > it's a good combo to keep those two as "standalone", as there are
> > other alerting components available also (such as Bosun) - which we
> > would probably like to 'compete' with.
> 
> Question is though how much we need to take care of this now and not
> address it when we need it.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lkrejci at redhat.com  Thu May 21 10:03:18 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 21 May 2015 16:03:18 +0200
Subject: [Hawkular-dev] non-snapshot kettle dependencies
In-Reply-To: <2103633236.3225079.1432209047261.JavaMail.zimbra@redhat.com>
References: <2103633236.3225079.1432209047261.JavaMail.zimbra@redhat.com>
Message-ID: <8589960.DMmkSbmrvS@localhost.localdomain>

I want to release inventory 0.0.2 once this PR lands: 
https://github.com/hawkular/hawkular-inventory/pull/67

I think with that inventory component should be ready for the MVP (of course 
there are UI fixes to accommodate for all the changes but that's external to 
the component itself or even glue).

On Thursday, May 21, 2015 07:50:47 John Mazzitelli wrote:
> We need to schedule the work to get kettle dependent on non-snapshot
> releases.
> 
> I recently released the following that can be used in the kettle build:
> 
> hawkular-bus:   0.0.5
> hawkular-nest: ls 0.0.5
> hawkular-agent: 0.0.2
> 
> We need folks to release the following:
> 
> hawkular-accounts (currently kettle uses 1.0.0-SNAPSHOT)
> hawkular-alerts (currently kettle uses 1.0.0-SNAPSHOT)
> hawkular-console (currently kettle uses 1.0.0-SNAPSHOT)
> hawkular-inventory (currently kettle uses 0.0.1-SNAPSHOT)
> 
> Once those releases are done, we can edit the hawkular/pom.xml to reflect
> the non-snapshot versions. _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From theute at redhat.com  Thu May 21 10:15:25 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 16:15:25 +0200
Subject: [Hawkular-dev] Spring cleaning
In-Reply-To: <555DE2AD.6010206@redhat.com>
References: <555CA5B9.3040200@redhat.com> <555DE2AD.6010206@redhat.com>
Message-ID: <555DE87D.50000@redhat.com>



On 05/21/2015 03:50 PM, Matt Wringe wrote:
> On 20/05/15 11:18 AM, Thomas Heute wrote:
>> 	- before closing an issue, check if the type, component, resolution,
>> fix-version are filled and correct. (once closed you can only
>> edit/change by reopening the issue and can't do bulk changes)
>
> Is there any way we can configure Jira to require all the fields to be
> set before its closed? Its really easy to forget to set things like the
> version fields.

I don't know

>
> Speaking of which, what is proper use of 'Fix Version' in Hawkular. Is
> this the version in which we are planning for the issue to be resolved
> (eg set before any work has started on the issue) or the version that
> the bug is actually fixed in (eg set after the code is committed).

Planned version when it's open and changed to actual version when 
resolving if needed.

Thomas

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

From theute at redhat.com  Thu May 21 10:20:01 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 16:20:01 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>	<555D7FEE.1000004@redhat.com>	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>	<555DB568.7000502@redhat.com>	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>	<11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>	<414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>
	<553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
Message-ID: <555DE991.7060607@redhat.com>



On 05/21/2015 04:02 PM, Matthew Wringe wrote:
> Yeah, I was under the impression that metrics needs to be handled in a special manner since we need to run it differently in OpenShift. Which means when we also add in Alerting to OpenShift, it will also need to be handled in a special manner.
> But I guess we can figure that part out when we actually need to add in Alerting.

Yes we'll likely want a Metrics+Alerts (and maybe replace Metrics only 
as we can't afford to QE many combinations) for OpenShift purpose.

> I think the discussion was also thinking about doing things in a modular manner, where we could have the different components running as individual containers in kubernetes, and then spin up (or down) more containers as needed. But it looks like the decision is to not to go with that approach for scaling the main Hawkular server.

Right this is not a requirement, we also voted for a zip distribution at 
the f2f (not a set of docker containers).

Thomas

>
>
>
> ----- Original Message -----
>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Thursday, May 21, 2015 9:27:19 AM
>> Subject: Re: [Hawkular-dev] Hawkular integration
>>
>> On 21 May 2015, at 13:50, Michael Burman wrote:
>>
>>> it's a good combo to keep those two as "standalone", as there are
>>> other alerting components available also (such as Bosun) - which we
>>> would probably like to 'compete' with.
>>
>> Question is though how much we need to take care of this now and not
>> address it when we need it.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From hrupp at redhat.com  Thu May 21 10:38:08 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 21 May 2015 16:38:08 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
	<11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>
	<414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>
	<553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
Message-ID: <F8FA92C0-F6C8-4A70-B50E-B87765A2460B@redhat.com>

On 21 May 2015, at 16:02, Matthew Wringe wrote:

> I think the discussion was also thinking about doing things in a 
> modular manner, where we could have the different components running 
> as individual containers in kubernetes, and then spin up (or down) 
> more containers as needed. But it looks like the decision is to not to 
> go with that approach for scaling the main Hawkular server.

This was (no matter if with Docker or not) the ideal world scenario
that I painted.
Now we need to go and (first) deal with the real-world one :-)

From hrupp at redhat.com  Thu May 21 10:40:24 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 21 May 2015 16:40:24 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>
	<555C51B5.6030702@redhat.com>
	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>
	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>
	<555D7FEE.1000004@redhat.com>
	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>
	<555DB568.7000502@redhat.com>
	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
Message-ID: <5AC51923-A3CC-45C1-9B6E-01949B52B9A3@redhat.com>

On 21 May 2015, at 12:43, John Mazzitelli wrote:
> only standalone component, they can figure out how they want to do 
> that, but all our other components can be assumed to only be running 
> in a full Hawkular environment. That makes some decisions easy. No 
> need to play all these games to get components "pluggable" into the

Yes. And with having them available, we can also extend the "glue"
to have business logic e.g. by providing logic that fetches data from
several places and returns it in one go to the UI instead of having the
business logic implemented in the UI (and rest-clients).

From theute at redhat.com  Thu May 21 10:51:15 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 16:51:15 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <5AC51923-A3CC-45C1-9B6E-01949B52B9A3@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<504593258.1850879.1432111816545.JavaMail.zimbra@redhat.com>	<555C51B5.6030702@redhat.com>	<28B0D18C-988F-420E-9E8B-452037886D2B@redhat.com>	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>	<555D7FEE.1000004@redhat.com>	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>	<555DB568.7000502@redhat.com>	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>
	<5AC51923-A3CC-45C1-9B6E-01949B52B9A3@redhat.com>
Message-ID: <555DF0E3.8080207@redhat.com>



On 05/21/2015 04:40 PM, Heiko W.Rupp wrote:
> On 21 May 2015, at 12:43, John Mazzitelli wrote:
>> only standalone component, they can figure out how they want to do
>> that, but all our other components can be assumed to only be running
>> in a full Hawkular environment. That makes some decisions easy. No
>> need to play all these games to get components "pluggable" into the
>
> Yes. And with having them available, we can also extend the "glue"
> to have business logic e.g. by providing logic that fetches data from
> several places and returns it in one go to the UI instead of having the
> business logic implemented in the UI (and rest-clients).

+1

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

From theute at redhat.com  Thu May 21 10:51:37 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 21 May 2015 16:51:37 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <F8FA92C0-F6C8-4A70-B50E-B87765A2460B@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>	<2074115093.2597432.1432125524576.JavaMail.zimbra@redhat.com>	<555D7FEE.1000004@redhat.com>	<947596025.3156133.1432200124525.JavaMail.zimbra@redhat.com>	<555DB568.7000502@redhat.com>	<996549519.3199196.1432205021705.JavaMail.zimbra@redhat.com>	<11993692.3403751.1432209046125.JavaMail.zimbra@redhat.com>	<414B9738-064B-47BA-AFDE-468F1ACB4E5C@redhat.com>	<553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
	<F8FA92C0-F6C8-4A70-B50E-B87765A2460B@redhat.com>
Message-ID: <555DF0F9.3070804@redhat.com>



On 05/21/2015 04:38 PM, Heiko W.Rupp wrote:
> On 21 May 2015, at 16:02, Matthew Wringe wrote:
>
>> I think the discussion was also thinking about doing things in a
>> modular manner, where we could have the different components running
>> as individual containers in kubernetes, and then spin up (or down)
>> more containers as needed. But it looks like the decision is to not to
>> go with that approach for scaling the main Hawkular server.
>
> This was (no matter if with Docker or not) the ideal world scenario
> that I painted.
> Now we need to go and (first) deal with the real-world one :-)

Indeed.

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

From jpkroehling at redhat.com  Thu May 21 12:08:06 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Thu, 21 May 2015 18:08:06 +0200
Subject: [Hawkular-dev] CORS filters
Message-ID: <555E02E6.1070503@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

I noticed that some components are implementing a custom CORS filter.
This is a feature that is provided also by Keycloak, and
administrators can use KC to set what are the allowed origins and
methods via its UI.

If you absolutely need a custom CORS filter for a different reason,
make sure to:

1) tell Keycloak to not handle CORS on your behalf. For instance, if I
were to disable Keycloak's CORS filter for Accounts, I'd change this
line to "false":

http://git.io/vTrkl

2) validate the user input ("origin" is a value that can be faked), so
that you are not vulnerable to an HTTP splitting attack:

https://www.owasp.org/index.php/HTTP_Response_Splitting

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

iQEcBAEBCAAGBQJVXgLmAAoJECKM1e+fkPrX3lQH/3eeQ8DKNrhmy2S9B8ZBORZD
JTWQ4WC5oCD3yDfoaVRFZw2CXLYVH1exAogOpQgtMxb/2RLa4+8NsUQMYSN03dB+
4QykeC/qnpmrlvhANZ6NgquH5Qpq6neI+p0YPMESmmsrxXpkvDhwANATWJE7+hGi
xM/6TGdFSKSNckR/CcZMc+M6w2SQMLEqfvfQqbOoJKy3TUk5/8XZK1eeTf/R+pf1
Xw99TfBmlmyOxr5qsQboFYZgroURMTbyi6WeBDUb0pwi/xEFaNjFLQi+uv0m3Nn5
GuXUruw2GmGRuERn/o2z2AV+WW41FcacgU863ET6VkatHpYhyq2TqwRWJeEAUG8=
=RcuH
-----END PGP SIGNATURE-----

From lkrejci at redhat.com  Thu May 21 13:03:03 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 21 May 2015 19:03:03 +0200
Subject: [Hawkular-dev] Hawkular integration
In-Reply-To: <555DE991.7060607@redhat.com>
References: <206960633.2459251.1432109088858.JavaMail.zimbra@redhat.com>
	<553643897.2669608.1432216937587.JavaMail.zimbra@redhat.com>
	<555DE991.7060607@redhat.com>
Message-ID: <716127702.Id9fVuuvQX@localhost.localdomain>

On Thursday, May 21, 2015 16:20:01 Thomas Heute wrote:
> On 05/21/2015 04:02 PM, Matthew Wringe wrote:
> > Yeah, I was under the impression that metrics needs to be handled in a
> > special manner since we need to run it differently in OpenShift. Which
> > means when we also add in Alerting to OpenShift, it will also need to be
> > handled in a special manner. But I guess we can figure that part out when
> > we actually need to add in Alerting.
> Yes we'll likely want a Metrics+Alerts (and maybe replace Metrics only
> as we can't afford to QE many combinations) for OpenShift purpose.
> 
> > I think the discussion was also thinking about doing things in a modular
> > manner, where we could have the different components running as
> > individual containers in kubernetes, and then spin up (or down) more
> > containers as needed. But it looks like the decision is to not to go with
> > that approach for scaling the main Hawkular server.
> Right this is not a requirement, we also voted for a zip distribution at
> the f2f (not a set of docker containers).
> 

I apologize if I don't remember that correctly, but a set of docker containers 
was not an option. "A" docker container was. That is a big difference because 
a zip and a docker container are conceptually almost identical.

Not so a set of containers that would assume the distributed deployment.

> Thomas
> 
> > ----- Original Message -----
> > 
> >> From: "Heiko W.Rupp" <hrupp at redhat.com>
> >> To: "Discussions around Hawkular development"
> >> <hawkular-dev at lists.jboss.org> Sent: Thursday, May 21, 2015 9:27:19 AM
> >> Subject: Re: [Hawkular-dev] Hawkular integration
> >> 
> >> On 21 May 2015, at 13:50, Michael Burman wrote:
> >>> it's a good combo to keep those two as "standalone", as there are
> >>> other alerting components available also (such as Bosun) - which we
> >>> would probably like to 'compete' with.
> >> 
> >> Question is though how much we need to take care of this now and not
> >> address it when we need it.
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From mazz at redhat.com  Thu May 21 16:33:21 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 21 May 2015 16:33:21 -0400 (EDT)
Subject: [Hawkular-dev] release instructions
In-Reply-To: <1356924771.3567557.1432240357347.JavaMail.zimbra@redhat.com>
Message-ID: <1402751538.3567639.1432240401949.JavaMail.zimbra@redhat.com>

Here's a PR to the build-tools repo - its just a README-like document that explains the steps you need to do to release a non-snapshot project.

I did not create a script because I thought it would only make it harder on the person using it since if the release fails, they won't even know (very easily anyway) at what stage the failure occurred.

So I just created this for people to follow. You do it enough times, and you'll remember what you have to do.

Here's the PR waiting to be merged

https://github.com/hawkular/hawkular-build-tools/pull/19/files

Here it is in AsciiDoc format:

https://github.com/hawkular/hawkular-build-tools/blob/mazz/release-notes/BUILDING-RELEASES.adoc

From hrupp at redhat.com  Fri May 22 02:49:36 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 22 May 2015 08:49:36 +0200
Subject: [Hawkular-dev] release instructions
In-Reply-To: <1402751538.3567639.1432240401949.JavaMail.zimbra@redhat.com>
References: <1402751538.3567639.1432240401949.JavaMail.zimbra@redhat.com>
Message-ID: <7FC3B426-C444-4A48-A9A5-6CF4866CE1D4@redhat.com>

On 21 May 2015, at 22:33, John Mazzitelli wrote:

> Here's a PR to the build-tools repo - its just a README-like document 
> that explains the steps you need to do to release a non-snapshot 
> project.

As it is not a script, but a readme - why not put it in 
hawkular.org/docs/dev ?


From mazz at redhat.com  Sat May 23 09:57:55 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 23 May 2015 09:57:55 -0400 (EDT)
Subject: [Hawkular-dev] WF9 requires us to change our agent subsystem
	extension classes
In-Reply-To: <1227124284.4113842.1432388745038.JavaMail.zimbra@redhat.com>
Message-ID: <953950862.4114527.1432389475695.JavaMail.zimbra@redhat.com>

The quick summary of this email: the Hawkular Wildfly Monitor Agent will not be able to run on WildFly 9 in its current state. It must be refactored due to changes that were made in the WildFly 9 subsystem extension API.

Details:

After staring at this for a while, I found that our currently WildFly8 code layout of the subsystem extensions in the agent needs to change for this to run in WF9 - I don't think I used this approach in the bus or nest subsystem extensions so nothing needs to change there.

The design pattern here is to use PersistentResourceDefinition subclasses for our the subsystem resource definitions (called the Definition classes). In here you define static members for all attributes and operations as well as an INSTANCE object of the definition itself, among other things.

The problem is, that same Definition class needs to grab (and thus create) an instance of the AddStepHandler within the Definition class' constructor. And THAT AddStepHandler needs to refer back to the Definition object for the attributes. Today, it does so in the populateModel() overloaded method, which isn't a problem. However, we needed to access a parent class' data field (this.attributes) to set our attributes in that populateModel() method. Unfortunately, that parent class in WF9 has changed that this.attributes data field to final. So we can't do that anymore. Instead, it appears the only way to set the attributes now is to pass them in via the AddStepHandler class' constructor (calling the superclass's "super(Collection<?> attributes")).

But this introduces an ugly circular dependency in the Definition and AddStepHandler constructors - it bombs with an NPE.

So this means in order for us to move the agent to WF9, I would need to refactor the subsystem definition classes - I would probably have to extract out all of the attribute/operation definitions into some independent class that can be shared between the *Definition and *Add classes to avoid this constructor-circularity dependency. It probably won't be hard to do this, just a hour or two hopefully. But as it is now, it can't run on WF9.

From mazz at redhat.com  Sat May 23 10:08:03 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 23 May 2015 10:08:03 -0400 (EDT)
Subject: [Hawkular-dev] WF9 requires us to change our agent subsystem
 extension classes
In-Reply-To: <953950862.4114527.1432389475695.JavaMail.zimbra@redhat.com>
References: <953950862.4114527.1432389475695.JavaMail.zimbra@redhat.com>
Message-ID: <205259278.4114794.1432390083981.JavaMail.zimbra@redhat.com>

Here's what the error looks like:

https://travis-ci.org/hawkular/hawkular-agent/builds/63771085

And here's the changes that would need to be made for it to compile with WildFly 9 but introduces the circular constructor problem (this is just to workaround that issue with this.attributes changed to "final"):

https://github.com/hawkular/hawkular-agent/commit/84fbfb3354f2eba4524fd4fd1849ef11eca45fd3

As the comment says,  I tried passing Array.asList(XYZDefinition.ATTRIBUTES) in the constructor, as well as what you see here (XYZDefinition.INSTANCE.getAttributes()) but both have this circular problem and breaks.

----- Original Message -----
> The quick summary of this email: the Hawkular Wildfly Monitor Agent will not
> be able to run on WildFly 9 in its current state. It must be refactored due
> to changes that were made in the WildFly 9 subsystem extension API.
> 
> Details:
> 
> After staring at this for a while, I found that our currently WildFly8 code
> layout of the subsystem extensions in the agent needs to change for this to
> run in WF9 - I don't think I used this approach in the bus or nest subsystem
> extensions so nothing needs to change there.
> 
> The design pattern here is to use PersistentResourceDefinition subclasses for
> our the subsystem resource definitions (called the Definition classes). In
> here you define static members for all attributes and operations as well as
> an INSTANCE object of the definition itself, among other things.
> 
> The problem is, that same Definition class needs to grab (and thus create) an
> instance of the AddStepHandler within the Definition class' constructor. And
> THAT AddStepHandler needs to refer back to the Definition object for the
> attributes. Today, it does so in the populateModel() overloaded method,
> which isn't a problem. However, we needed to access a parent class' data
> field (this.attributes) to set our attributes in that populateModel()
> method. Unfortunately, that parent class in WF9 has changed that
> this.attributes data field to final. So we can't do that anymore. Instead,
> it appears the only way to set the attributes now is to pass them in via the
> AddStepHandler class' constructor (calling the superclass's
> "super(Collection<?> attributes")).
> 
> But this introduces an ugly circular dependency in the Definition and
> AddStepHandler constructors - it bombs with an NPE.
> 
> So this means in order for us to move the agent to WF9, I would need to
> refactor the subsystem definition classes - I would probably have to extract
> out all of the attribute/operation definitions into some independent class
> that can be shared between the *Definition and *Add classes to avoid this
> constructor-circularity dependency. It probably won't be hard to do this,
> just a hour or two hopefully. But as it is now, it can't run on WF9.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lponce at redhat.com  Sun May 24 14:04:46 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Sun, 24 May 2015 14:04:46 -0400 (EDT)
Subject: [Hawkular-dev] Download hawkular-dist from Maven
Message-ID: <373510568.4252605.1432490686437.JavaMail.zimbra@redhat.com>

Hi,

I was having an issue with my maven configuration when I wanted to use hawkular-dist artifact with wildfly plugin.

Finally I have found that I had to change the <classifier> param in my pom.xml.

I have this one and it works:

          <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
            <configuration>
              <groupId>org.hawkular</groupId>
              <artifactId>hawkular-dist</artifactId>
              <version>1.0.0-SNAPSHOT</version>
              <!-- <classifier>distribution</classifier> -->
              <skip>${skipTests}</skip>
              <port>${wildfly.management.port}</port>
            </configuration>
            <executions>
              <execution>
                <id>start-wildfly</id>
                <phase>pre-integration-test</phase>
                <goals>
                  <goal>start</goal>
                </goals>
                <configuration>
                  <javaOpts>
                    <javaOpt>-Xms64m</javaOpt>
                    <javaOpt>-Xmx512m</javaOpt>
                    <javaOpt>-Xss256k</javaOpt>
                    <javaOpt>-Djava.net.preferIPv4Stack=true</javaOpt>
                    <javaOpt>-Dsun.rmi.dgc.client.gcInterval=3600000</javaOpt>
                    <javaOpt>-Dsun.rmi.dgc.server.gcInterval=3600000</javaOpt>
                    <javaOpt>-Djboss.socket.binding.port-offset=${wildfly.port.offset}</javaOpt>
                    <javaOpt>-Djboss.server.data.dir=${project.build.directory}/wildfly-data</javaOpt>
                    <javaOpt>-Dhawkular-metrics.backend=embedded_cass</javaOpt>
                    <javaOpt>-Xdebug</javaOpt>
                    <javaOpt>-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787</javaOpt>
                  </javaOpts>
                </configuration>
              </execution>
              <execution>
                <id>stop-wildfly</id>
                <phase>post-integration-test</phase>
                <goals>
                  <goal>shutdown</goal>
                </goals>
              </execution>
            </executions>
          </plugin>


Hope this can save some time.

Lucas

From hrupp at redhat.com  Tue May 26 05:02:24 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 26 May 2015 11:02:24 +0200
Subject: [Hawkular-dev] WF9 requires us to change our agent subsystem
 extension classes
In-Reply-To: <205259278.4114794.1432390083981.JavaMail.zimbra@redhat.com>
References: <953950862.4114527.1432389475695.JavaMail.zimbra@redhat.com>
	<205259278.4114794.1432390083981.JavaMail.zimbra@redhat.com>
Message-ID: <3897AA48-050E-4486-B061-18AAAFECB4E2@redhat.com>

On 23 May 2015, at 16:08, John Mazzitelli wrote:

> And here's the changes that would need to be made for it to compile 
> with WildFly 9 but introduces the circular constructor problem (this

Would that still work with WF 8?

From theute at redhat.com  Tue May 26 05:17:47 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 26 May 2015 11:17:47 +0200
Subject: [Hawkular-dev] Hawkular master
Message-ID: <55643A3B.5060500@redhat.com>




Hawkular master is working again, thanks a lot for the focus on that !

It's also starting to use non-SNAPSHOT releases: 
https://github.com/hawkular/hawkular/blob/master/pom.xml

Let's continue like this:
	* peer review for each Pull Request (this also means that everything 
goes through a Pull Request) and keep having Hawkular master in a 
working state.
	* more use of non-SNAPSHOTS, who is next ? (UI one should be last)


Thanks !

Thomas

From mazz at redhat.com  Tue May 26 06:29:37 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 26 May 2015 06:29:37 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular master
In-Reply-To: <55643A3B.5060500@redhat.com>
References: <55643A3B.5060500@redhat.com>
Message-ID: <209227872.4837947.1432636177543.JavaMail.zimbra@redhat.com>

I think metrics should go to a release now - they were the first ones to have releases :) We should be able to move to their latest and greatest release.

FWIW, I *should* be able to have the next release of the agent at the end of today which will give us an agent integrated with inventory (the agent's resources and their types should be registered with inventory).

----- Original Message -----
> 
> 
> 
> Hawkular master is working again, thanks a lot for the focus on that !
> 
> It's also starting to use non-SNAPSHOT releases:
> https://github.com/hawkular/hawkular/blob/master/pom.xml
> 
> Let's continue like this:
> 	* peer review for each Pull Request (this also means that everything
> goes through a Pull Request) and keep having Hawkular master in a
> working state.
> 	* more use of non-SNAPSHOTS, who is next ? (UI one should be last)
> 
> 
> Thanks !
> 
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Tue May 26 06:30:18 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 26 May 2015 06:30:18 -0400 (EDT)
Subject: [Hawkular-dev] WF9 requires us to change our agent subsystem
 extension classes
In-Reply-To: <3897AA48-050E-4486-B061-18AAAFECB4E2@redhat.com>
References: <953950862.4114527.1432389475695.JavaMail.zimbra@redhat.com>
	<205259278.4114794.1432390083981.JavaMail.zimbra@redhat.com>
	<3897AA48-050E-4486-B061-18AAAFECB4E2@redhat.com>
Message-ID: <940991226.4838475.1432636218138.JavaMail.zimbra@redhat.com>

> Would that still work with WF 8?

Yes, it should.

----- Original Message -----
> On 23 May 2015, at 16:08, John Mazzitelli wrote:
> 
> > And here's the changes that would need to be made for it to compile
> > with WildFly 9 but introduces the circular constructor problem (this
> 
> Would that still work with WF 8?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mmahoney at redhat.com  Tue May 26 10:01:18 2015
From: mmahoney at redhat.com (Matthew Mahoney)
Date: Tue, 26 May 2015 10:01:18 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Public Instances Update
In-Reply-To: <422656912.5764136.1432648846003.JavaMail.zimbra@redhat.com>
Message-ID: <331298786.5765733.1432648878525.JavaMail.zimbra@redhat.com>

Resending... 


Hawkular Community, 

We apologizes for the prolonged OS1 public Hawkular instance outage, which has been due to our need to build a new OS1 Kubernetes cluster. 

Current state 
- The new cluster is in place and build with Kubernetes 0.15 (was 0.9). 
- Public Hawkular instances are running , but as of today only manually started (no Hawkular image build trigger). 

Community: http://209.132.179.82:18080 
QE: http://209.132.179.82:18085 
Dev: http://209.132.179.82:18090 

Next steps 
- Wire Hawkular DockerHub project to trigger Jenkins job to deploy pods. This is expected to be completed early next week. 
- Further improvements to the Kubernetes cluster - add additional minions. 
- Abstract the Hawkular instance entry-points, as not to depend on a fixed minion IP in the URL. 

Ping me with any questions / concerns. 

Thanks, 




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

From jsanda at redhat.com  Tue May 26 10:11:15 2015
From: jsanda at redhat.com (John Sanda)
Date: Tue, 26 May 2015 10:11:15 -0400
Subject: [Hawkular-dev] [process] tickets and PRs
Message-ID: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>

Does there need to be a pull request for every ticket? Put another way, do all commits to master need to come by way of PRs? I think that there are scenarios where a manual merge makes more sense.

- John

From hrupp at redhat.com  Tue May 26 10:18:38 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 26 May 2015 16:18:38 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
Message-ID: <99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>

On 26 May 2015, at 16:11, John Sanda wrote:

> Does there need to be a pull request for every ticket? Put another 
> way, do all commits to master need to come by way of PRs? I think that 
> there are scenarios where a manual merge makes more sense.

I think the pull-request itself is not the issue here, but the case that
something that goes into master should have seen some peer-review
before.
How that happens - via pull-request, patch in email or a separate branch
that gets merged is secondary.


From theute at redhat.com  Tue May 26 10:27:01 2015
From: theute at redhat.com (Thomas Heute)
Date: Tue, 26 May 2015 16:27:01 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
Message-ID: <556482B5.2000208@redhat.com>



On 05/26/2015 04:18 PM, Heiko W.Rupp wrote:
> On 26 May 2015, at 16:11, John Sanda wrote:
>
>> Does there need to be a pull request for every ticket? Put another
>> way, do all commits to master need to come by way of PRs? I think that
>> there are scenarios where a manual merge makes more sense.
>
> I think the pull-request itself is not the issue here, but the case that
> something that goes into master should have seen some peer-review
> before.
> How that happens - via pull-request, patch in email or a separate branch
> that gets merged is secondary.

Pull-request is more visible, triggers a build and is wired with JIRA, 
so it must be used.

But how that gets merged is indeed separate, I know some teams (like 
GateIn) forbid the use of the green button, but that doesn't prevent a 
PR to be made and merged via CLI.

Thomas



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

From mmahoney at redhat.com  Tue May 26 15:06:37 2015
From: mmahoney at redhat.com (Matthew Mahoney)
Date: Tue, 26 May 2015 15:06:37 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Public Instances Update
In-Reply-To: <331298786.5765733.1432648878525.JavaMail.zimbra@redhat.com>
References: <331298786.5765733.1432648878525.JavaMail.zimbra@redhat.com>
Message-ID: <1770040370.6022473.1432667196999.JavaMail.zimbra@redhat.com>

The auto deploy of Hawkular public instance is working once again. 

Jenkins/IRC notify will again indicate a new available Hawkular build. 

Thanks, 

Matt 

----- Original Message -----

> From: "Matthew Mahoney" <mmahoney at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, May 26, 2015 10:01:18 AM
> Subject: [Hawkular-dev] Hawkular Public Instances Update

> Resending...

> Hawkular Community,

> We apologizes for the prolonged OS1 public Hawkular instance outage, which
> has been due to our need to build a new OS1 Kubernetes cluster.

> Current state
> - The new cluster is in place and build with Kubernetes 0.15 (was 0.9).
> - Public Hawkular instances are running , but as of today only manually
> started (no Hawkular image build trigger).

> Community: http://209.132.179.82:18080
> QE: http://209.132.179.82:18085
> Dev: http://209.132.179.82:18090

> Next steps
> - Wire Hawkular DockerHub project to trigger Jenkins job to deploy pods. This
> is expected to be completed early next week.
> - Further improvements to the Kubernetes cluster - add additional minions.
> - Abstract the Hawkular instance entry-points, as not to depend on a fixed
> minion IP in the URL.

> Ping me with any questions / concerns.

> Thanks,

> _______________________________________________
> 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/20150526/92462f87/attachment-0001.html 

From tsegismo at redhat.com  Wed May 27 06:06:51 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 27 May 2015 12:06:51 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <556482B5.2000208@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
	<556482B5.2000208@redhat.com>
Message-ID: <5565973B.2000804@redhat.com>

Le 26/05/2015 16:27, Thomas Heute a ?crit :
>
> On 05/26/2015 04:18 PM, Heiko W.Rupp wrote:
>> >On 26 May 2015, at 16:11, John Sanda wrote:
>> >
>>> >>Does there need to be a pull request for every ticket? Put another
>>> >>way, do all commits to master need to come by way of PRs? I think that
>>> >>there are scenarios where a manual merge makes more sense.
>> >
>> >I think the pull-request itself is not the issue here, but the case that
>> >something that goes into master should have seen some peer-review
>> >before.
>> >How that happens - via pull-request, patch in email or a separate branch
>> >that gets merged is secondary.
> Pull-request is more visible, triggers a build and is wired with JIRA,
> so it must be used.
>
> But how that gets merged is indeed separate, I know some teams (like
> GateIn) forbid the use of the green button, but that doesn't prevent a
> PR to be made and merged via CLI.

I agree with Heiko and Thomas.

That said, I think John is wondering about merging the rx-migration into 
master. In this case, I don't think there's a need for a PR, as many of 
the commits to the branch have been sent as PR already.

From tsegismo at redhat.com  Wed May 27 06:12:38 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 27 May 2015 12:12:38 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <5565973B.2000804@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>	<556482B5.2000208@redhat.com>
	<5565973B.2000804@redhat.com>
Message-ID: <55659896.3030007@redhat.com>

Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> as many of
> the commits to the branch have been sent as PR already.

Well, we should have sent all commits as part of PR and related to a 
ticket. That would have made the review process much easier than 
reviewing PR 228

From lponce at redhat.com  Wed May 27 06:41:02 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 27 May 2015 06:41:02 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <55659896.3030007@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
	<556482B5.2000208@redhat.com> <5565973B.2000804@redhat.com>
	<55659896.3030007@redhat.com>
Message-ID: <2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>

I also propose to squash commits when it has sense.

Project is growing and for debugging which "commit did that" grouping commits into a feature/fix/patch can help.

Obviosly there are situations that are not possible, but it can be good to start thinking on that.

Just my 2 cents.

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 27, 2015 12:12:38 PM
> Subject: Re: [Hawkular-dev] [process] tickets and PRs
> 
> Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> > as many of
> > the commits to the branch have been sent as PR already.
> 
> Well, we should have sent all commits as part of PR and related to a
> ticket. That would have made the review process much easier than
> reviewing PR 228
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From jpkroehling at redhat.com  Wed May 27 06:46:29 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 27 May 2015 12:46:29 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>	<556482B5.2000208@redhat.com>
	<5565973B.2000804@redhat.com>	<55659896.3030007@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
Message-ID: <5565A085.8050506@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> I also propose to squash commits when it has sense.

+1 , having "one commit per jira" helps a lot in debugging :-)

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZaCFAAoJECKM1e+fkPrXfC8H/jj7IQGl9IfdLFiPOE0HNnaw
WQgP+9LaOgyq5qd+eAzlY1G5FCD3YPcKdx0Cc08tkWL420YsvhMMo3CsuCXAOFYe
gY+sQPkGSdXTW5/V3kwlNXJIHecT3lp/xlEPQryzsmGWRgcilUdlQERhdMo8SaKS
NX8tswCRF9lq8+TwwuA7jQfk6AEpzbUgicbJsdkuxlpsTuPCjSyqrCdhPWD4KYMV
T8IztZdhxVdXADzsadACTy+ksDJiGsd7Px/9bfev/Cjbn1yZbCcEHXdMunoBkW9T
OvpgRARnR1zdVFgLMHWGznq7/Oav5HADb7hdIEzzBRJumjPg4Nwvo5SAOrH/mTk=
=t2TT
-----END PGP SIGNATURE-----

From mazz at redhat.com  Wed May 27 07:05:44 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 27 May 2015 07:05:44 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
	<556482B5.2000208@redhat.com> <5565973B.2000804@redhat.com>
	<55659896.3030007@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
Message-ID: <1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>

Uh...I recommend NO squash commits unless you are absolutely sure you know what you are doing :)

I can remember we screwed ourselves badly in the beginning of RHQ when we used squashed commits wrong - the repository got all messed up.

The only time I do a squash commit is if I immediately destroy the branch it came from after the squash commit is performed, that way I know I won't screw anything up.

----- Original Message -----
> I also propose to squash commits when it has sense.
> 
> Project is growing and for debugging which "commit did that" grouping commits
> into a feature/fix/patch can help.
> 
> Obviosly there are situations that are not possible, but it can be good to
> start thinking on that.
> 
> Just my 2 cents.
> 
> ----- Original Message -----
> > From: "Thomas Segismont" <tsegismo at redhat.com>
> > To: hawkular-dev at lists.jboss.org
> > Sent: Wednesday, May 27, 2015 12:12:38 PM
> > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > 
> > Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> > > as many of
> > > the commits to the branch have been sent as PR already.
> > 
> > Well, we should have sent all commits as part of PR and related to a
> > ticket. That would have made the review process much easier than
> > reviewing PR 228
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From lponce at redhat.com  Wed May 27 07:11:52 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 27 May 2015 07:11:52 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
	<556482B5.2000208@redhat.com> <5565973B.2000804@redhat.com>
	<55659896.3030007@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
	<1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>
Message-ID: <1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>

Let me explain myself better.

Or in which situations I think squash is good:

- I need to fix a HW-5555.
- I checkout master and I create a new branch for HW-5555.
- I start to work there:
- My commits:
  - Start working.
  - Adding a couple of things.
  - Javadoc typo.
  - License agains...

- I think this all 4 commits can be squashed without putting in danger anything.

- We can send the PR to review without squash, and after that, squash to have a cleaner structure.

Again, this can help IMHO.

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 27, 2015 1:05:44 PM
> Subject: Re: [Hawkular-dev] [process] tickets and PRs
> 
> Uh...I recommend NO squash commits unless you are absolutely sure you know
> what you are doing :)
> 
> I can remember we screwed ourselves badly in the beginning of RHQ when we
> used squashed commits wrong - the repository got all messed up.
> 
> The only time I do a squash commit is if I immediately destroy the branch it
> came from after the squash commit is performed, that way I know I won't
> screw anything up.
> 
> ----- Original Message -----
> > I also propose to squash commits when it has sense.
> > 
> > Project is growing and for debugging which "commit did that" grouping
> > commits
> > into a feature/fix/patch can help.
> > 
> > Obviosly there are situations that are not possible, but it can be good to
> > start thinking on that.
> > 
> > Just my 2 cents.
> > I can remember we screwed ourselves badly in the beginning of RHQ when we used squashed commits wrong - the repository got all messed up.

> > ----- Original Message -----
> > > From: "Thomas Segismont" <tsegismo at redhat.com>
> > > To: hawkular-dev at lists.jboss.org
> > > Sent: Wednesday, May 27, 2015 12:12:38 PM
> > > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > > 
> > > Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> > > > as many of
> > > > the commits to the branch have been sent as PR already.
> > > 
> > > Well, we should have sent all commits as part of PR and related to a
> > > ticket. That would have made the review process much easier than
> > > reviewing PR 228
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From mazz at redhat.com  Wed May 27 07:23:25 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 27 May 2015 07:23:25 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>
	<556482B5.2000208@redhat.com> <5565973B.2000804@redhat.com>
	<55659896.3030007@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
	<1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>
	<1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
Message-ID: <1430615441.5853545.1432725805478.JavaMail.zimbra@redhat.com>

Yes, this is a good idea. My point is if you do a squash from a branch to master, you have to remember to not push any more commits from that branch to master unless you remember to merge back master into that branch first. We screwed up the remote repository very badly one time when we were squashing multiple times from the same branch without merging master back into that branch each time.

Now my rule of thumb is, when I squash, I delete the branch that squash came from so I don't make that same mistake. Either that, or you have to remember to merge master back into that branch (I think that's how to fix it). But I worry I'll still screw up. To me, a squash means "I'm done with this branch" - so once the squash is done, I delete that branch.

----- Original Message -----
> Let me explain myself better.
> 
> Or in which situations I think squash is good:
> 
> - I need to fix a HW-5555.
> - I checkout master and I create a new branch for HW-5555.
> - I start to work there:
> - My commits:
>   - Start working.
>   - Adding a couple of things.
>   - Javadoc typo.
>   - License agains...
> 
> - I think this all 4 commits can be squashed without putting in danger
> anything.
> 
> - We can send the PR to review without squash, and after that, squash to have
> a cleaner structure.
> 
> Again, this can help IMHO.
> 
> ----- Original Message -----
> > From: "John Mazzitelli" <mazz at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Sent: Wednesday, May 27, 2015 1:05:44 PM
> > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > 
> > Uh...I recommend NO squash commits unless you are absolutely sure you know
> > what you are doing :)
> > 
> > I can remember we screwed ourselves badly in the beginning of RHQ when we
> > used squashed commits wrong - the repository got all messed up.
> > 
> > The only time I do a squash commit is if I immediately destroy the branch
> > it
> > came from after the squash commit is performed, that way I know I won't
> > screw anything up.
> > 
> > ----- Original Message -----
> > > I also propose to squash commits when it has sense.
> > > 
> > > Project is growing and for debugging which "commit did that" grouping
> > > commits
> > > into a feature/fix/patch can help.
> > > 
> > > Obviosly there are situations that are not possible, but it can be good
> > > to
> > > start thinking on that.
> > > 
> > > Just my 2 cents.
> > > I can remember we screwed ourselves badly in the beginning of RHQ when we
> > > used squashed commits wrong - the repository got all messed up.
> 
> > > ----- Original Message -----
> > > > From: "Thomas Segismont" <tsegismo at redhat.com>
> > > > To: hawkular-dev at lists.jboss.org
> > > > Sent: Wednesday, May 27, 2015 12:12:38 PM
> > > > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > > > 
> > > > Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> > > > > as many of
> > > > > the commits to the branch have been sent as PR already.
> > > > 
> > > > Well, we should have sent all commits as part of PR and related to a
> > > > ticket. That would have made the review process much easier than
> > > > reviewing PR 228
> > > > _______________________________________________
> > > > 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 lponce at redhat.com  Wed May 27 07:27:56 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Wed, 27 May 2015 07:27:56 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <1430615441.5853545.1432725805478.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<556482B5.2000208@redhat.com> <5565973B.2000804@redhat.com>
	<55659896.3030007@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
	<1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>
	<1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
	<1430615441.5853545.1432725805478.JavaMail.zimbra@redhat.com>
Message-ID: <200631813.5856174.1432726076493.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 27, 2015 1:23:25 PM
> Subject: Re: [Hawkular-dev] [process] tickets and PRs
> 
> Yes, this is a good idea. My point is if you do a squash from a branch to
> master, you have to remember to not push any more commits from that branch
> to master unless you remember to merge back master into that branch first.
> We screwed up the remote repository very badly one time when we were
> squashing multiple times from the same branch without merging master back
> into that branch each time.
> 
> Now my rule of thumb is, when I squash, I delete the branch that squash came
> from so I don't make that same mistake. Either that, or you have to remember
> to merge master back into that branch (I think that's how to fix it). But I
> worry I'll still screw up. To me, a squash means "I'm done with this branch"
> - so once the squash is done, I delete that branch.
> 

+1

Yes, scenarios like it was described, once the squashed commit is merged, it has not sense to maintain and old branch.

> ----- Original Message -----
> > Let me explain myself better.
> > 
> > Or in which situations I think squash is good:
> > 
> > - I need to fix a HW-5555.
> > - I checkout master and I create a new branch for HW-5555.
> > - I start to work there:
> > - My commits:
> >   - Start working.
> >   - Adding a couple of things.
> >   - Javadoc typo.
> >   - License agains...
> > 
> > - I think this all 4 commits can be squashed without putting in danger
> > anything.
> > 
> > - We can send the PR to review without squash, and after that, squash to
> > have
> > a cleaner structure.
> > 
> > Again, this can help IMHO.
> > 
> > ----- Original Message -----
> > > From: "John Mazzitelli" <mazz at redhat.com>
> > > To: "Discussions around Hawkular development"
> > > <hawkular-dev at lists.jboss.org>
> > > Sent: Wednesday, May 27, 2015 1:05:44 PM
> > > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > > 
> > > Uh...I recommend NO squash commits unless you are absolutely sure you
> > > know
> > > what you are doing :)
> > > 
> > > I can remember we screwed ourselves badly in the beginning of RHQ when we
> > > used squashed commits wrong - the repository got all messed up.
> > > 
> > > The only time I do a squash commit is if I immediately destroy the branch
> > > it
> > > came from after the squash commit is performed, that way I know I won't
> > > screw anything up.
> > > 
> > > ----- Original Message -----
> > > > I also propose to squash commits when it has sense.
> > > > 
> > > > Project is growing and for debugging which "commit did that" grouping
> > > > commits
> > > > into a feature/fix/patch can help.
> > > > 
> > > > Obviosly there are situations that are not possible, but it can be good
> > > > to
> > > > start thinking on that.
> > > > 
> > > > Just my 2 cents.
> > > > I can remember we screwed ourselves badly in the beginning of RHQ when
> > > > we
> > > > used squashed commits wrong - the repository got all messed up.
> > 
> > > > ----- Original Message -----
> > > > > From: "Thomas Segismont" <tsegismo at redhat.com>
> > > > > To: hawkular-dev at lists.jboss.org
> > > > > Sent: Wednesday, May 27, 2015 12:12:38 PM
> > > > > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > > > > 
> > > > > Le 27/05/2015 12:06, Thomas Segismont a ?crit :
> > > > > > as many of
> > > > > > the commits to the branch have been sent as PR already.
> > > > > 
> > > > > Well, we should have sent all commits as part of PR and related to a
> > > > > ticket. That would have made the review process much easier than
> > > > > reviewing PR 228
> > > > > _______________________________________________
> > > > > 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 snegrea at redhat.com  Wed May 27 10:20:45 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 27 May 2015 10:20:45 -0400 (EDT)
Subject: [Hawkular-dev] Tenant Id
In-Reply-To: <555C5A3D.8020107@redhat.com>
References: <C10BA9C4-3A94-419C-BFFE-40868421AA10@redhat.com>
	<1597313517.1770974.1432071156284.JavaMail.zimbra@redhat.com>
	<555C2F8C.6050004@redhat.com>
	<1860529529.1644657.1432105813944.JavaMail.zimbra@redhat.com>
	<555C3513.6090006@redhat.com> <555C5A3D.8020107@redhat.com>
Message-ID: <773770052.4818798.1432736445775.JavaMail.zimbra@redhat.com>

Hello Everybody,

I lost track a few times of where this long thread was going but I think the final decision is: Hawkular-Tenant header only. 

Here is the PR for Hawkular Metrics: https://github.com/hawkular/hawkular-metrics/pull/232 . The PR is ready for merging and will be part of the next Hawkular Metrics release.


Thank you,
Stefan

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Wednesday, May 20, 2015 4:56:13 AM
> Subject: Re: [Hawkular-dev] Tenant Id
> 
> Le 20/05/2015 09:17, Juraci Paix?o Kr?hling a ?crit :
> > On 05/20/2015 09:10 AM, Gary Brown wrote:
> >> >If the X-Hawkular-Persona header is still required, shouldn't it
> >> >atleast be changed to Hawkular-Persona, as in a previous email in
> >> >this thread I believe "X-" prefix is reserved?
> > Yes, I think I've created a JIRA for me about that. But just to be
> > clear: consumers of Accounts shouldn't worry about this header. It's
> > parsed and checked by Accounts, which makes a Persona object available
> > to be injected.
> 
> Yes, the "Hawkular-Tenant" header is specific to Metrics. When Metrics
> is integrated with Accounts, I expect we will derive the tenant from the
> persona header.
> 
> We'll also need to think how to make clients
> (hawkular-agent/ptrans/vertx-monitor) work with both standalone and
> integrated Metrics services.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From ppalaga at redhat.com  Wed May 27 10:23:53 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 27 May 2015 16:23:53 +0200
Subject: [Hawkular-dev] Hitting Travis Limits
Message-ID: <5565D379.7020100@redhat.com>

Hi *,

my attempt to run end to end tests by Travis seems to be exceeding the 
resources allowed by Travis.

I think so because my build [1] ends with "exited with 137" which [2] 
describes as exhausted CPUs and/or allocation of more than 3GB memory.

I am not sure myself, which of the two is my case. Before I spend any 
time on that, has anybody ever succeeded to start wildfly inside Travis 
and run some integration test?

Thanks,

Peter

[1] https://travis-ci.org/hawkular/hawkular/builds/64250753
[2] 
http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error

From gbrown at redhat.com  Wed May 27 10:31:51 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 27 May 2015 10:31:51 -0400 (EDT)
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <5565D379.7020100@redhat.com>
References: <5565D379.7020100@redhat.com>
Message-ID: <397863457.5053426.1432737111726.JavaMail.zimbra@redhat.com>

Yes, I've had wildfly integration tests running there.

----- Original Message -----
> Hi *,
> 
> my attempt to run end to end tests by Travis seems to be exceeding the
> resources allowed by Travis.
> 
> I think so because my build [1] ends with "exited with 137" which [2]
> describes as exhausted CPUs and/or allocation of more than 3GB memory.
> 
> I am not sure myself, which of the two is my case. Before I spend any
> time on that, has anybody ever succeeded to start wildfly inside Travis
> and run some integration test?
> 
> Thanks,
> 
> Peter
> 
> [1] https://travis-ci.org/hawkular/hawkular/builds/64250753
> [2]
> http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From ppalaga at redhat.com  Wed May 27 10:44:05 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 27 May 2015 16:44:05 +0200
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <397863457.5053426.1432737111726.JavaMail.zimbra@redhat.com>
References: <5565D379.7020100@redhat.com>
	<397863457.5053426.1432737111726.JavaMail.zimbra@redhat.com>
Message-ID: <5565D835.7050202@redhat.com>

Thanks for the feedback, Gary. Where is your project so that I can 
compare it with mine? -- P

On 2015-05-27 16:31, Gary Brown wrote:
> Yes, I've had wildfly integration tests running there.
>
> ----- Original Message -----
>> Hi *,
>>
>> my attempt to run end to end tests by Travis seems to be exceeding the
>> resources allowed by Travis.
>>
>> I think so because my build [1] ends with "exited with 137" which [2]
>> describes as exhausted CPUs and/or allocation of more than 3GB memory.
>>
>> I am not sure myself, which of the two is my case. Before I spend any
>> time on that, has anybody ever succeeded to start wildfly inside Travis
>> and run some integration test?
>>
>> Thanks,
>>
>> Peter
>>
>> [1] https://travis-ci.org/hawkular/hawkular/builds/64250753
>> [2]
>> http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From gbrown at redhat.com  Wed May 27 10:51:16 2015
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 27 May 2015 10:51:16 -0400 (EDT)
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <5565D835.7050202@redhat.com>
References: <5565D379.7020100@redhat.com>
	<397863457.5053426.1432737111726.JavaMail.zimbra@redhat.com>
	<5565D835.7050202@redhat.com>
Message-ID: <2141190608.5074056.1432738276545.JavaMail.zimbra@redhat.com>

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

Its only running a small amount of tests currently.

Regards
Gary

----- Original Message -----
> Thanks for the feedback, Gary. Where is your project so that I can
> compare it with mine? -- P
> 
> On 2015-05-27 16:31, Gary Brown wrote:
> > Yes, I've had wildfly integration tests running there.
> >
> > ----- Original Message -----
> >> Hi *,
> >>
> >> my attempt to run end to end tests by Travis seems to be exceeding the
> >> resources allowed by Travis.
> >>
> >> I think so because my build [1] ends with "exited with 137" which [2]
> >> describes as exhausted CPUs and/or allocation of more than 3GB memory.
> >>
> >> I am not sure myself, which of the two is my case. Before I spend any
> >> time on that, has anybody ever succeeded to start wildfly inside Travis
> >> and run some integration test?
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> [1] https://travis-ci.org/hawkular/hawkular/builds/64250753
> >> [2]
> >> http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error
> >> _______________________________________________
> >> 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 May 27 11:02:47 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 27 May 2015 17:02:47 +0200
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <5565D379.7020100@redhat.com>
References: <5565D379.7020100@redhat.com>
Message-ID: <6138015A-693F-4958-AB80-3880E0AEB965@redhat.com>

> I am not sure myself, which of the two is my case. Before I spend any
> time on that, has anybody ever succeeded to start wildfly inside Travis
> and run some integration test?

We had Hawkular-metrics running on Travis including tests (iirc both
with memory and Cassandra backend).

From brmeyer at redhat.com  Wed May 27 11:20:59 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 27 May 2015 11:20:59 -0400 (EDT)
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <2141190608.5074056.1432738276545.JavaMail.zimbra@redhat.com>
References: <5565D379.7020100@redhat.com>
	<397863457.5053426.1432737111726.JavaMail.zimbra@redhat.com>
	<5565D835.7050202@redhat.com>
	<2141190608.5074056.1432738276545.JavaMail.zimbra@redhat.com>
Message-ID: <1905160155.6733258.1432740059541.JavaMail.zimbra@redhat.com>

FWIW, Artificer also runs an integration test suite on Wildfly:

https://github.com/ArtificerRepo/artificer/blob/master/.travis.yml
https://github.com/ArtificerRepo/artificer/blob/master/.travis.maven.settings.xml

----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Peter Palaga" <ppalaga at redhat.com>
> Cc: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 27, 2015 10:51:16 AM
> Subject: Re: [Hawkular-dev] Hitting Travis Limits
> 
> https://github.com/hawkular/hawkular-btm
> 
> Its only running a small amount of tests currently.
> 
> Regards
> Gary
> 
> ----- Original Message -----
> > Thanks for the feedback, Gary. Where is your project so that I can
> > compare it with mine? -- P
> > 
> > On 2015-05-27 16:31, Gary Brown wrote:
> > > Yes, I've had wildfly integration tests running there.
> > >
> > > ----- Original Message -----
> > >> Hi *,
> > >>
> > >> my attempt to run end to end tests by Travis seems to be exceeding the
> > >> resources allowed by Travis.
> > >>
> > >> I think so because my build [1] ends with "exited with 137" which [2]
> > >> describes as exhausted CPUs and/or allocation of more than 3GB memory.
> > >>
> > >> I am not sure myself, which of the two is my case. Before I spend any
> > >> time on that, has anybody ever succeeded to start wildfly inside Travis
> > >> and run some integration test?
> > >>
> > >> Thanks,
> > >>
> > >> Peter
> > >>
> > >> [1] https://travis-ci.org/hawkular/hawkular/builds/64250753
> > >> [2]
> > >> http://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error
> > >> _______________________________________________
> > >> 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 May 27 12:04:14 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 27 May 2015 18:04:14 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>	<556482B5.2000208@redhat.com>
	<5565973B.2000804@redhat.com>	<55659896.3030007@redhat.com>	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>	<1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>
	<1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
Message-ID: <5565EAFE.4010702@redhat.com>

I'm opposed to that as a rule.

If a PR has been under works for several days and impacts more than an 
handful of files, then I think it should be created ASAP so that the 
review can start early and be split in small commits.

I think you can't expect a good job from the reviewer when the diff says
"Showing 60 changed files with 3,593 additions and 2,530 deletions."
https://github.com/hawkular/hawkular-alerts/pull/50/files

Maybe I'm a slacker :)

Le 27/05/2015 13:11, Lucas Ponce a ?crit :
> Let me explain myself better.
>
> Or in which situations I think squash is good:
>
> - I need to fix a HW-5555.
> - I checkout master and I create a new branch for HW-5555.
> - I start to work there:
> - My commits:
>    - Start working.
>    - Adding a couple of things.
>    - Javadoc typo.
>    - License agains...
>
> - I think this all 4 commits can be squashed without putting in danger anything.
>
> - We can send the PR to review without squash, and after that, squash to have a cleaner structure.
>
> Again, this can help IMHO.
>
> ----- Original Message -----
>> From: "John Mazzitelli" <mazz at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Wednesday, May 27, 2015 1:05:44 PM
>> Subject: Re: [Hawkular-dev] [process] tickets and PRs
>>
>> Uh...I recommend NO squash commits unless you are absolutely sure you know
>> what you are doing :)
>>
>> I can remember we screwed ourselves badly in the beginning of RHQ when we
>> used squashed commits wrong - the repository got all messed up.
>>
>> The only time I do a squash commit is if I immediately destroy the branch it
>> came from after the squash commit is performed, that way I know I won't
>> screw anything up.
>>
>> ----- Original Message -----
>>> I also propose to squash commits when it has sense.
>>>
>>> Project is growing and for debugging which "commit did that" grouping
>>> commits
>>> into a feature/fix/patch can help.
>>>
>>> Obviosly there are situations that are not possible, but it can be good to
>>> start thinking on that.
>>>
>>> Just my 2 cents.
>>> I can remember we screwed ourselves badly in the beginning of RHQ when we used squashed commits wrong - the repository got all messed up.
>
>>> ----- Original Message -----
>>>> From: "Thomas Segismont" <tsegismo at redhat.com>
>>>> To: hawkular-dev at lists.jboss.org
>>>> Sent: Wednesday, May 27, 2015 12:12:38 PM
>>>> Subject: Re: [Hawkular-dev] [process] tickets and PRs
>>>>
>>>> Le 27/05/2015 12:06, Thomas Segismont a ?crit :
>>>>> as many of
>>>>> the commits to the branch have been sent as PR already.
>>>>
>>>> Well, we should have sent all commits as part of PR and related to a
>>>> ticket. That would have made the review process much easier than
>>>> reviewing PR 228
>>>> _______________________________________________
>>>> 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  Wed May 27 12:06:56 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 27 May 2015 18:06:56 +0200
Subject: [Hawkular-dev] Hitting Travis Limits
In-Reply-To: <6138015A-693F-4958-AB80-3880E0AEB965@redhat.com>
References: <5565D379.7020100@redhat.com>
	<6138015A-693F-4958-AB80-3880E0AEB965@redhat.com>
Message-ID: <5565EBA0.6070201@redhat.com>

Le 27/05/2015 17:02, Heiko W.Rupp a ?crit :
>> I am not sure myself, which of the two is my case. Before I spend any
>> time on that, has anybody ever succeeded to start wildfly inside Travis
>> and run some integration test?
>
> We had Hawkular-metrics running on Travis including tests (iirc both
> with memory and Cassandra backend).

Well, the memory backend is long gone. But as a matter of fact, the 
Metrics build starts a Wildfly server twice: first in the rest-tests 
module, then in the ptrans module.




From vnguyen at redhat.com  Wed May 27 12:32:20 2015
From: vnguyen at redhat.com (Viet Nguyen)
Date: Wed, 27 May 2015 12:32:20 -0400 (EDT)
Subject: [Hawkular-dev] Web test fixture
In-Reply-To: <1761574994.5796680.1432741993870.JavaMail.zimbra@redhat.com>
Message-ID: <1991158872.5806420.1432744340733.JavaMail.zimbra@redhat.com>

I'm pleased to announce first version of the Web Test Fixture is up and running.  It's a web server (nginx) running inside Docker that can simulate a specific HTTP response code as well simple cron-like availability.  

Please let me know whether this is useful for Hawkular URL monitoring and what you want to see next. For example, a. simulate slow response time, b. cycle between http status codes, etc. 

Viet Nguyen

-----

Example usage:

[1] Launch a web fixture
docker run -d -p 8999:8080 hawkularqe/web-fixture

# get custom http code (replace 503 with any valid status code)
curl -I http://localhost:8999/http?return=503
--> HTTP/1.1 503 Service Temporarily Unavailable

[2] Launch a mostly-available fixture - server goes offline for 10 seconds every minute
docker run -p 8999:8080 -e "DURATION=50s" -e "CRON_EXP=* * * * *" hawkularqe/web-fixture


[1] and [2] in the example above are also running on public OS1:
1. http://209.132.179.82:50001
2. http://209.132.179.82:50002


Github:
https://github.com/Hawkular-QE/web-fixture

From theute at redhat.com  Wed May 27 13:16:27 2015
From: theute at redhat.com (Thomas Heute)
Date: Wed, 27 May 2015 19:16:27 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <5565EAFE.4010702@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<99E53B11-869A-479F-83C9-372977C4EDE3@redhat.com>	<556482B5.2000208@redhat.com>	<5565973B.2000804@redhat.com>	<55659896.3030007@redhat.com>	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>	<1289246474.5842439.1432724744539.JavaMail.zimbra@redhat.com>	<1109120346.5846697.1432725112679.JavaMail.zimbra@redhat.com>
	<5565EAFE.4010702@redhat.com>
Message-ID: <5565FBEB.2000709@redhat.com>



On 05/27/2015 06:04 PM, Thomas Segismont wrote:
> I'm opposed to that as a rule.
>
> If a PR has been under works for several days and impacts more than an
> handful of files, then I think it should be created ASAP so that the
> review can start early and be split in small commits.
>
> I think you can't expect a good job from the reviewer when the diff says
> "Showing 60 changed files with 3,593 additions and 2,530 deletions."
> https://github.com/hawkular/hawkular-alerts/pull/50/files

On the other hand reviewing changes affecting the same lines multiple 
times is a waste of time, this is the reason why I squashed most of my 
Kettle->Dist commits as it was just too hard to read through the many 
commits and my mistakes.

I don't think we need a rule, just that we should think about the 
squashing option that Git offers and can help reviewers.

Thomas


>
> Maybe I'm a slacker :)
>
> Le 27/05/2015 13:11, Lucas Ponce a ?crit :
>> Let me explain myself better.
>>
>> Or in which situations I think squash is good:
>>
>> - I need to fix a HW-5555.
>> - I checkout master and I create a new branch for HW-5555.
>> - I start to work there:
>> - My commits:
>>     - Start working.
>>     - Adding a couple of things.
>>     - Javadoc typo.
>>     - License agains...
>>
>> - I think this all 4 commits can be squashed without putting in danger anything.
>>
>> - We can send the PR to review without squash, and after that, squash to have a cleaner structure.
>>
>> Again, this can help IMHO.
>>
>> ----- Original Message -----
>>> From: "John Mazzitelli" <mazz at redhat.com>
>>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>>> Sent: Wednesday, May 27, 2015 1:05:44 PM
>>> Subject: Re: [Hawkular-dev] [process] tickets and PRs
>>>
>>> Uh...I recommend NO squash commits unless you are absolutely sure you know
>>> what you are doing :)
>>>
>>> I can remember we screwed ourselves badly in the beginning of RHQ when we
>>> used squashed commits wrong - the repository got all messed up.
>>>
>>> The only time I do a squash commit is if I immediately destroy the branch it
>>> came from after the squash commit is performed, that way I know I won't
>>> screw anything up.
>>>
>>> ----- Original Message -----
>>>> I also propose to squash commits when it has sense.
>>>>
>>>> Project is growing and for debugging which "commit did that" grouping
>>>> commits
>>>> into a feature/fix/patch can help.
>>>>
>>>> Obviosly there are situations that are not possible, but it can be good to
>>>> start thinking on that.
>>>>
>>>> Just my 2 cents.
>>>> I can remember we screwed ourselves badly in the beginning of RHQ when we used squashed commits wrong - the repository got all messed up.
>>
>>>> ----- Original Message -----
>>>>> From: "Thomas Segismont" <tsegismo at redhat.com>
>>>>> To: hawkular-dev at lists.jboss.org
>>>>> Sent: Wednesday, May 27, 2015 12:12:38 PM
>>>>> Subject: Re: [Hawkular-dev] [process] tickets and PRs
>>>>>
>>>>> Le 27/05/2015 12:06, Thomas Segismont a ?crit :
>>>>>> as many of
>>>>>> the commits to the branch have been sent as PR already.
>>>>>
>>>>> Well, we should have sent all commits as part of PR and related to a
>>>>> ticket. That would have made the review process much easier than
>>>>> reviewing PR 228
>>>>> _______________________________________________
>>>>> 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  Wed May 27 13:46:01 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 27 May 2015 13:46:01 -0400 (EDT)
Subject: [Hawkular-dev] new agent in kettle
In-Reply-To: <393125920.6247476.1432748659203.JavaMail.zimbra@redhat.com>
Message-ID: <504505291.6248151.1432748761194.JavaMail.zimbra@redhat.com>

The latest agent is in kettle, along with release versions of accounts and inventory.

The new agent inserts resources into inventory and metrics along with those resources get collected and stored into metrics.

There is only a top level server and one child resource for now. But this should be good enough for UI folks to start beating on it.

I'll be feverishly trying to get a fuller EAP into inventory. I might need inventory API to have some fixes. The agent code is there, its just blowing up because I'm trying to create resource types that I've already created and inventory doesn't like that.

From mazz at redhat.com  Wed May 27 13:51:21 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 27 May 2015 13:51:21 -0400 (EDT)
Subject: [Hawkular-dev] how to get literal $ in .xsl
In-Reply-To: <1445893832.6249559.1432749014605.JavaMail.zimbra@redhat.com>
Message-ID: <909577444.6252678.1432749081324.JavaMail.zimbra@redhat.com>

BTW: if anyone knows how to fix this, let me know.

In the agent configuration, Thomas H. wanted to be able to configure the agent to talk over a different IP/port than localhost:8080 (specifically the one Wildfly binds to - jboss.bind.address and jboss.http.port).

In the standalone.xml config, this actually works:

        <storage-adapter type="HAWKULAR"
                         username="jdoe"
                         password="password"
                         url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>

However, when I try to get that url value to be added to the default standalone.xml via our XSL, I get an error.

So, this line here:

https://github.com/hawkular/hawkular/blob/mazz/wip/dist/src/main/resources/wildfly/patches/standalone.xsl#L247

I want to be:

url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>

But XSL parser dies. I tried using "\$" and "&#36;" to no avail. Anyone know how to get a literal $ to be parsed here?

From mazz at redhat.com  Wed May 27 13:52:10 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 27 May 2015 13:52:10 -0400 (EDT)
Subject: [Hawkular-dev] new agent in kettle
In-Reply-To: <504505291.6248151.1432748761194.JavaMail.zimbra@redhat.com>
References: <504505291.6248151.1432748761194.JavaMail.zimbra@redhat.com>
Message-ID: <1992373560.6255190.1432749130810.JavaMail.zimbra@redhat.com>

Sorry, its not in kettle master yet - its in a PR here:

https://github.com/hawkular/hawkular/pull/137

Need someone to merge it.

----- Original Message -----
> The latest agent is in kettle, along with release versions of accounts and
> inventory.
> 
> The new agent inserts resources into inventory and metrics along with those
> resources get collected and stored into metrics.
> 
> There is only a top level server and one child resource for now. But this
> should be good enough for UI folks to start beating on it.
> 
> I'll be feverishly trying to get a fuller EAP into inventory. I might need
> inventory API to have some fixes. The agent code is there, its just blowing
> up because I'm trying to create resource types that I've already created and
> inventory doesn't like that.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From ppalaga at redhat.com  Wed May 27 13:56:41 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 27 May 2015 19:56:41 +0200
Subject: [Hawkular-dev] how to get literal $ in .xsl
In-Reply-To: <909577444.6252678.1432749081324.JavaMail.zimbra@redhat.com>
References: <909577444.6252678.1432749081324.JavaMail.zimbra@redhat.com>
Message-ID: <55660559.7040306@redhat.com>

I happen to have done the same thing today :) -- P
https://github.com/hawkular/hawkular/commit/55a62f6616b882729b057c2cf06d1d86c219d2a3#diff-e2136f7d72c510834df4ad85535af167R222

On 2015-05-27 19:51, John Mazzitelli wrote:
> BTW: if anyone knows how to fix this, let me know.
>
> In the agent configuration, Thomas H. wanted to be able to configure the agent to talk over a different IP/port than localhost:8080 (specifically the one Wildfly binds to - jboss.bind.address and jboss.http.port).
>
> In the standalone.xml config, this actually works:
>
>          <storage-adapter type="HAWKULAR"
>                           username="jdoe"
>                           password="password"
>                           url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
>
> However, when I try to get that url value to be added to the default standalone.xml via our XSL, I get an error.
>
> So, this line here:
>
> https://github.com/hawkular/hawkular/blob/mazz/wip/dist/src/main/resources/wildfly/patches/standalone.xsl#L247
>
> I want to be:
>
> url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/>
>
> But XSL parser dies. I tried using "\$" and "&#36;" to no avail. Anyone know how to get a literal $ to be parsed here?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jsanda at redhat.com  Wed May 27 14:47:04 2015
From: jsanda at redhat.com (John Sanda)
Date: Wed, 27 May 2015 14:47:04 -0400
Subject: [Hawkular-dev] Web test fixture
In-Reply-To: <1991158872.5806420.1432744340733.JavaMail.zimbra@redhat.com>
References: <1991158872.5806420.1432744340733.JavaMail.zimbra@redhat.com>
Message-ID: <28DF54A6-3820-40E0-BCD0-2573E6FA8853@redhat.com>

This looks interesting. Just out of curiosity, did you consider using Gatling (or anything similar)? I have not worked with Gatling, but it sounds like there is some similarity.

> On May 27, 2015, at 12:32 PM, Viet Nguyen <vnguyen at redhat.com> wrote:
> 
> I'm pleased to announce first version of the Web Test Fixture is up and running.  It's a web server (nginx) running inside Docker that can simulate a specific HTTP response code as well simple cron-like availability.  
> 
> Please let me know whether this is useful for Hawkular URL monitoring and what you want to see next. For example, a. simulate slow response time, b. cycle between http status codes, etc. 
> 
> Viet Nguyen
> 
> -----
> 
> Example usage:
> 
> [1] Launch a web fixture
> docker run -d -p 8999:8080 hawkularqe/web-fixture
> 
> # get custom http code (replace 503 with any valid status code)
> curl -I http://localhost:8999/http?return=503
> --> HTTP/1.1 503 Service Temporarily Unavailable
> 
> [2] Launch a mostly-available fixture - server goes offline for 10 seconds every minute
> docker run -p 8999:8080 -e "DURATION=50s" -e "CRON_EXP=* * * * *" hawkularqe/web-fixture
> 
> 
> [1] and [2] in the example above are also running on public OS1:
> 1. http://209.132.179.82:50001
> 2. http://209.132.179.82:50002
> 
> 
> Github:
> https://github.com/Hawkular-QE/web-fixture
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From tsegismo at redhat.com  Wed May 27 16:14:19 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 27 May 2015 22:14:19 +0200
Subject: [Hawkular-dev] Web test fixture
In-Reply-To: <28DF54A6-3820-40E0-BCD0-2573E6FA8853@redhat.com>
References: <1991158872.5806420.1432744340733.JavaMail.zimbra@redhat.com>
	<28DF54A6-3820-40E0-BCD0-2573E6FA8853@redhat.com>
Message-ID: <5566259B.1030702@redhat.com>

There must be a confusion. Viet's work is something Mike T had suggested 
in the past, to help with functional testing of availability and 
response time checks in the pinger. It's not related to load testing.

Le 27/05/2015 20:47, John Sanda a ?crit :
> This looks interesting. Just out of curiosity, did you consider using Gatling (or anything similar)? I have not worked with Gatling, but it sounds like there is some similarity.
>
>> On May 27, 2015, at 12:32 PM, Viet Nguyen <vnguyen at redhat.com> wrote:
>>
>> I'm pleased to announce first version of the Web Test Fixture is up and running.  It's a web server (nginx) running inside Docker that can simulate a specific HTTP response code as well simple cron-like availability.
>>
>> Please let me know whether this is useful for Hawkular URL monitoring and what you want to see next. For example, a. simulate slow response time, b. cycle between http status codes, etc.
>>
>> Viet Nguyen
>>
>> -----
>>
>> Example usage:
>>
>> [1] Launch a web fixture
>> docker run -d -p 8999:8080 hawkularqe/web-fixture
>>
>> # get custom http code (replace 503 with any valid status code)
>> curl -I http://localhost:8999/http?return=503
>> --> HTTP/1.1 503 Service Temporarily Unavailable
>>
>> [2] Launch a mostly-available fixture - server goes offline for 10 seconds every minute
>> docker run -p 8999:8080 -e "DURATION=50s" -e "CRON_EXP=* * * * *" hawkularqe/web-fixture
>>
>>
>> [1] and [2] in the example above are also running on public OS1:
>> 1. http://209.132.179.82:50001
>> 2. http://209.132.179.82:50002
>>
>>
>> Github:
>> https://github.com/Hawkular-QE/web-fixture
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jshaughn at redhat.com  Wed May 27 17:14:39 2015
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 27 May 2015 17:14:39 -0400
Subject: [Hawkular-dev] Alert Email Config
Message-ID: <556633BF.3020602@redhat.com>


It's not totally clear what we want to do in Hawkular to configure the 
smtp server for use with the e-mail action plugin for alerts.  OOB WFly 
is configured for smtp server localhost:25.  This generally does not 
work in dev envs.

So, we deploy the e-mail action plugin, we supply the e-mail address in 
Hawkular user registration, and then we just generate server log 
warnings when it doesn't work.  It's easily remedied with a a manual 
edit.  For us we can set it to the RH corp smtp server, which will work 
fine as long as you run from behind the VPN, or on the corp net.

We could hardcode this into our Dist but I'm not sure if we want to 
publicize that host.

Otherwise, a manual edit is required unless we provide for some sort of 
build-time command line prop to be applied to Dist by the build.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150527/adeb4050/attachment.html 

From mwringe at redhat.com  Wed May 27 17:51:54 2015
From: mwringe at redhat.com (Matt Wringe)
Date: Wed, 27 May 2015 17:51:54 -0400
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <556633BF.3020602@redhat.com>
References: <556633BF.3020602@redhat.com>
Message-ID: <55663C7A.6080908@redhat.com>

Would the SMTP setup not be something which is something we can display 
to the user in the UI? eg on first login we ask the admin to configure 
it. If they skip this setup, then when they go to add an email alert we 
have a modal which tells them they cannot add email alert until they 
configure the SMTP.

Or did I miss something here with how the email service is setup?


On 27/05/15 05:14 PM, Jay Shaughnessy wrote:
>
> It's not totally clear what we want to do in Hawkular to configure the 
> smtp server for use with the e-mail action plugin for alerts. OOB WFly 
> is configured for smtp server localhost:25.  This generally does not 
> work in dev envs.
>
> So, we deploy the e-mail action plugin, we supply the e-mail address 
> in Hawkular user registration, and then we just generate server log 
> warnings when it doesn't work.  It's easily remedied with a a manual 
> edit.  For us we can set it to the RH corp smtp server, which will 
> work fine as long as you run from behind the VPN, or on the corp net.
>
> We could hardcode this into our Dist but I'm not sure if we want to 
> publicize that host.
>
> Otherwise, a manual edit is required unless we provide for some sort 
> of build-time command line prop to be applied to Dist by the build.
>
> Thoughts?
>
>
> _______________________________________________
> 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/20150527/64469980/attachment-0001.html 

From jpkroehling at redhat.com  Thu May 28 03:04:23 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 28 May 2015 09:04:23 +0200
Subject: [Hawkular-dev] how to get literal $ in .xsl
In-Reply-To: <55660559.7040306@redhat.com>
References: <909577444.6252678.1432749081324.JavaMail.zimbra@redhat.com>
	<55660559.7040306@redhat.com>
Message-ID: <5566BDF7.5010508@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

My solution was a bit different:

<auth-server-url-for-backend-requests>
  <xsl:text disable-output-escaping="yes">
    http://${jboss.bind.address}/auth
  </xsl:text>
</auth-server-url-for-backend-requests>

- - Juca.

On 05/27/2015 07:56 PM, Peter Palaga wrote:
> I happen to have done the same thing today :) -- P 
> https://github.com/hawkular/hawkular/commit/55a62f6616b882729b057c2cf0
6d1d86c219d2a3#diff-e2136f7d72c510834df4ad85535af167R222
>
>  On 2015-05-27 19:51, John Mazzitelli wrote:
>> BTW: if anyone knows how to fix this, let me know.
>> 
>> In the agent configuration, Thomas H. wanted to be able to
>> configure the agent to talk over a different IP/port than
>> localhost:8080 (specifically the one Wildfly binds to -
>> jboss.bind.address and jboss.http.port).
>> 
>> In the standalone.xml config, this actually works:
>> 
>> <storage-adapter type="HAWKULAR" username="jdoe" 
>> password="password" 
>> url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/
>
>>
>>
>> 
However, when I try to get that url value to be added to the default
standalone.xml via our XSL, I get an error.
>> 
>> So, this line here:
>> 
>> https://github.com/hawkular/hawkular/blob/mazz/wip/dist/src/main/reso
urces/wildfly/patches/standalone.xsl#L247
>>
>>
>> 
I want to be:
>> 
>> url="http://${jboss.bind.address:127.0.0.1}:${jboss.http.port:8080}"/
>
>>
>>
>> 
But XSL parser dies. I tried using "\$" and "&#36;" to no avail. Anyone
know how to get a literal $ to be parsed here?
>> _______________________________________________ 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZr32AAoJECKM1e+fkPrXAn0IAJtONgdQtkaPTx/TkNsFUuWc
zWA2eltBShQAfH490jdD+F2NnDrOj7BLO3ePUk5IZD5if2Xfols1lXx1wUjuhIP7
8ESgf6eeUB+gfbWPXVefOXuiiJOQPiT45o7BgD1jpygfNV2csoM/68JrHN+4ssWR
iMy8h/9W32uKKYLZU/pp34Zn8CRoFUfKGaDQ3SLogj2d6T/YOmQBWAYpEePXejE+
2Gxp4BzIfFokhZs1D3CKTaJs/XGUCmN1y+2UF4YiCMQUqVCVd900RbMJ+VihHyv9
ld/rEVTI8VQStP/ppyhFP66MJKfrKUQsYkgW5s2r2Kt5eWQR7aSj0aRVR17EZ5I=
=PEoQ
-----END PGP SIGNATURE-----

From jpkroehling at redhat.com  Thu May 28 03:08:58 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 28 May 2015 09:08:58 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <556633BF.3020602@redhat.com>
References: <556633BF.3020602@redhat.com>
Message-ID: <5566BF0A.9080300@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/27/2015 11:14 PM, Jay Shaughnessy wrote:
> Otherwise, a manual edit is required unless we provide for some
> sort of build-time command line prop to be applied to Dist by the
> build.

We have it already, the "-Pdev" profile :) We could just apply an
extra XML stylesheet if that profile is active that would replace some
properties. The actual values could come from system property, and we
could define those in the ~/.m2/settings.xml . This way, we get a
build that fully works for devs while not making the actual values
public.

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZr8KAAoJECKM1e+fkPrXRQkH/2+tuYgZwlnT+cWgoqYqLjpb
YzRXK9b+UjdAO7RZttrqVDx8RnjrQzel2qDhRXL9EXAony/eQyvDssmZ1bqJMBjP
kMM2XHKZ50ns94LXEhI9MI0EgY7ejMPL92WtPnhFpBbnmEjE2a9EGV38ZDv6PJmk
2+OMpiBPmyFoRgf8XT+HIJZK2AaEwSGkoyB7mwyag/x18+lXBkPSoowVVgOmLMVF
1qIOOv4f1Jol8oAe/kKY/jsd3BDLRnNW1Z+HhOorwmf2c+jajRawSoqs8UKmxsXY
yS9BeLI6LnsR5UHvt2dtIeagK8wa+H2dJq5551f/HUPNTP285Dvuh7Ao8kWq0iI=
=D9dI
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Thu May 28 03:15:59 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 28 May 2015 09:15:59 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <55663C7A.6080908@redhat.com>
References: <556633BF.3020602@redhat.com> <55663C7A.6080908@redhat.com>
Message-ID: <5566C0AF.9010901@redhat.com>

Setting up the email service in the UI is a goal. That requires the 
ability to send configuration to action plugins instead of relying on 
system properties.

Le 27/05/2015 23:51, Matt Wringe a ?crit :
> Would the SMTP setup not be something which is something we can display
> to the user in the UI? eg on first login we ask the admin to configure
> it. If they skip this setup, then when they go to add an email alert we
> have a modal which tells them they cannot add email alert until they
> configure the SMTP.
>
> Or did I miss something here with how the email service is setup?
>
>
> On 27/05/15 05:14 PM, Jay Shaughnessy wrote:
>>
>> It's not totally clear what we want to do in Hawkular to configure the
>> smtp server for use with the e-mail action plugin for alerts. OOB WFly
>> is configured for smtp server localhost:25.  This generally does not
>> work in dev envs.
>>
>> So, we deploy the e-mail action plugin, we supply the e-mail address
>> in Hawkular user registration, and then we just generate server log
>> warnings when it doesn't work.  It's easily remedied with a a manual
>> edit.  For us we can set it to the RH corp smtp server, which will
>> work fine as long as you run from behind the VPN, or on the corp net.
>>
>> We could hardcode this into our Dist but I'm not sure if we want to
>> publicize that host.
>>
>> Otherwise, a manual edit is required unless we provide for some sort
>> of build-time command line prop to be applied to Dist by the build.
>>
>> Thoughts?
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Thu May 28 03:25:01 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 28 May 2015 09:25:01 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566C0AF.9010901@redhat.com>
References: <556633BF.3020602@redhat.com> <55663C7A.6080908@redhat.com>
	<5566C0AF.9010901@redhat.com>
Message-ID: <5566C2CD.9040704@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/28/2015 09:15 AM, Thomas Segismont wrote:
> Setting up the email service in the UI is a goal. That requires the
>  ability to send configuration to action plugins instead of relying
> on system properties.

Would that change the underlying Wildfly configuration for the mail
subsystem? Or would we store this information on our side?

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZsLNAAoJECKM1e+fkPrXFOMH/0KEhBwxxS0UI3Jt7e4ImhtJ
hU7Nm7BOJcS7kYRxLNsfQaJGil/J31vlatqhFNTek4XULl2Vc5tgBEP54t3NdREb
7geM9WecehQYMPtZ7KrGWtOWHbMCdmbYRcSDiW3j4ExI+xSlirqsXb9hjA/CYMVE
PYl2QRcXbTGFp5VZMfogg2zgDcqsmEjCe13ttFt41s5NRnlZAmANtgyTBswvqrlP
JLAjhjqxMytLCBHpaGGxf6Fs2iAqLDKPJmvnXMfJ5knfsc7BuxGnPGV2dN1yv54y
Pdfks6W8GZA39tXtaD2mi+nAi8kGVkJ2ndZwr6a5VYjCQja8FyZ1Q5JKH3cDulA=
=WhjA
-----END PGP SIGNATURE-----

From hrupp at redhat.com  Thu May 28 03:28:27 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 28 May 2015 09:28:27 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566C0AF.9010901@redhat.com>
References: <556633BF.3020602@redhat.com> <55663C7A.6080908@redhat.com>
	<5566C0AF.9010901@redhat.com>
Message-ID: <9F904D60-F2A4-41C3-B0A3-188EA2903A35@redhat.com>

On 28 May 2015, at 9:15, Thomas Segismont wrote:

> Setting up the email service in the UI is a goal. That requires the
> ability to send configuration to action plugins instead of relying on
> system properties.

This may be a bit trickier than in the past, with the multi-tenancy.
Certainly we need to have "global defaults" and not re-set up that
information for each trigger/notification definition.

This probably brings back the question of a "superuser" account
to set up these technical definitions ("site administrator").

From tsegismo at redhat.com  Thu May 28 03:47:42 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 28 May 2015 09:47:42 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566C2CD.9040704@redhat.com>
References: <556633BF.3020602@redhat.com>
	<55663C7A.6080908@redhat.com>	<5566C0AF.9010901@redhat.com>
	<5566C2CD.9040704@redhat.com>
Message-ID: <5566C81E.40102@redhat.com>

Le 28/05/2015 09:25, Juraci Paix?o Kr?hling a ?crit :
> On 05/28/2015 09:15 AM, Thomas Segismont wrote:
>> >Setting up the email service in the UI is a goal. That requires the
>> >  ability to send configuration to action plugins instead of relying
>> >on system properties.
> Would that change the underlying Wildfly configuration for the mail
> subsystem? Or would we store this information on our side?

If we allow users to select an SMTP server, then we can't use a mail 
session built by the container, we need to create it in the action plugin.

From jpkroehling at redhat.com  Thu May 28 04:03:55 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 28 May 2015 10:03:55 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566C81E.40102@redhat.com>
References: <556633BF.3020602@redhat.com>	<55663C7A.6080908@redhat.com>	<5566C0AF.9010901@redhat.com>	<5566C2CD.9040704@redhat.com>
	<5566C81E.40102@redhat.com>
Message-ID: <5566CBEB.10302@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/28/2015 09:47 AM, Thomas Segismont wrote:
> If we allow users to select an SMTP server, then we can't use a
> mail session built by the container, we need to create it in the
> action plugin.

I'm certain that I'm missing something, but why would we want them to
select an SMTP server? Isn't it for sending alerts to their email? The
"from" address will be the same, no matter the tenant, right?

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZsvrAAoJECKM1e+fkPrXAcIH/0mz7Ps0bIhww/iLCCjPwtYV
BXzTEvbcrur4kn+puIg72hugDXzxHObDlqPBu2ygdPkVtUwugqqazUVFnox9cxyW
PiRAqdjPuEdrV+5b6HAZKf3EBSmXmXRzB9zGUn643txUreb+djXeKXpRUTMRamt2
HZM1iLDZFEDIMJbwN0xNfnffLhWQwtdf57Qgnll3fxA7hwrlupVZg7pwfssuyhzT
qVhJnZAFsPGX+hA+FH3JPV/HA1W6o3XDwJf9yoqUu+INnzcyPMhXQNai1Hu/e+fW
2N5xLRhBC6KHrOJNESaMLqbG+d9o/Jkfn7zWHBETD6P/a9ZAS+OlKAYg3WI61jI=
=EPIA
-----END PGP SIGNATURE-----

From tsegismo at redhat.com  Thu May 28 05:32:25 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 28 May 2015 11:32:25 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566CBEB.10302@redhat.com>
References: <556633BF.3020602@redhat.com>	<55663C7A.6080908@redhat.com>	<5566C0AF.9010901@redhat.com>	<5566C2CD.9040704@redhat.com>	<5566C81E.40102@redhat.com>
	<5566CBEB.10302@redhat.com>
Message-ID: <5566E0A9.2010907@redhat.com>

Le 28/05/2015 10:03, Juraci Paix?o Kr?hling a ?crit :
> On 05/28/2015 09:47 AM, Thomas Segismont wrote:
>> >If we allow users to select an SMTP server, then we can't use a
>> >mail session built by the container, we need to create it in the
>> >action plugin.
> I'm certain that I'm missing something, but why would we want them to
> select an SMTP server? Isn't it for sending alerts to their email? The
> "from" address will be the same, no matter the tenant, right?

When Hawkular is installed at some big corp, then yes all tenants will 
probably want to use the same smtp server.

When Hawkular is provided by a hosting company to their customers, then 
they are good chances that every tenant will use its own smtp server.

From jpkroehling at redhat.com  Thu May 28 05:43:56 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 28 May 2015 11:43:56 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566E0A9.2010907@redhat.com>
References: <556633BF.3020602@redhat.com>	<55663C7A.6080908@redhat.com>	<5566C0AF.9010901@redhat.com>	<5566C2CD.9040704@redhat.com>	<5566C81E.40102@redhat.com>	<5566CBEB.10302@redhat.com>
	<5566E0A9.2010907@redhat.com>
Message-ID: <5566E35C.7060600@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/28/2015 11:32 AM, Thomas Segismont wrote:
> When Hawkular is provided by a hosting company to their customers,
> then they are good chances that every tenant will use its own smtp
> server.

Not sure I agree with that. If my hosting company "Acme, Inc" provides
Hawkular services, then I'd alert my clients as "alerts at acme.com", as
configured on standalone.xml. I don't think my clients would want the
trouble in creating a special SMTP account or sharing their
credentials to an existing account just to get a customized "from"
address.

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

iQEcBAEBCAAGBQJVZuNcAAoJECKM1e+fkPrXIpYIAJUWeJ8r+yetup7K//AFTW+C
otEVdK6EHM9LQLgNhmVLTG21vfkFDc4q/NzW77ofup1bfAoyARym12vBpnSUcWH0
VWPM+H9V/oU/QHluPjqJ6mZdrFQlKtmoFvvYCE9Jlxcib17pu0sUvaLcrgy25xmJ
or3RBzvdd1iXi591JeWJXmSHIu+xkyXBCzd111WnHvJLkouDs0j4c/YVSotSKRXu
1n7jrpQ5uAwJKke6RlJA2yLRNZDt5WwOyVSiPP5CHZccq1ykQ9waBf9U2a2TCT8G
RzY8RJdJ5ctfqqUZzl+C1+sXzRNJ2hnRDfIaYU20gZVW7JKc8fNkvbkJWztUAis=
=gIK8
-----END PGP SIGNATURE-----

From ppalaga at redhat.com  Thu May 28 06:34:29 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 28 May 2015 12:34:29 +0200
Subject: [Hawkular-dev] Hawkular project switching to Docker-based Travis
 workers; was: Hitting Travis Limits
In-Reply-To: <5565EBA0.6070201@redhat.com>
References: <5565D379.7020100@redhat.com>	<6138015A-693F-4958-AB80-3880E0AEB965@redhat.com>
	<5565EBA0.6070201@redhat.com>
Message-ID: <5566EF35.4030300@redhat.com>

In my case, switching to Travis container-based infrastructure [1][2] 
helped - see [3] for how to do that.

Hard to say which particular aspect of the container-based Travis worker 
has helped - here are some possible candidates:
* more RAM
* more CPUs (2 vs. 1.5)
* faster network -> faster artifact downloads and therefore shorter
   total build times -> less probable job timeouts

Another important pro for switching to docker workers is that the job 
starts much faster than with the traditional VM worker.

-- P

[1] http://docs.travis-ci.com/user/workers/container-based-infrastructure/
[2] 
http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

[3] 
https://github.com/ppalaga/hawkular/commit/351e046c3d383023e5a35fe5c15891f45c8b1c28#diff-354f30a63fb0907d4ad57269548329e3R4



On 2015-05-27 18:06, Thomas Segismont wrote:
> Le 27/05/2015 17:02, Heiko W.Rupp a ?crit :
>>> I am not sure myself, which of the two is my case. Before I spend any
>>> time on that, has anybody ever succeeded to start wildfly inside Travis
>>> and run some integration test?
>>
>> We had Hawkular-metrics running on Travis including tests (iirc both
>> with memory and Cassandra backend).
>
> Well, the memory backend is long gone. But as a matter of fact, the
> Metrics build starts a Wildfly server twice: first in the rest-tests
> module, then in the ptrans module.
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From lkrejci at redhat.com  Thu May 28 06:50:55 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 28 May 2015 12:50:55 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <5565A085.8050506@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>
	<5565A085.8050506@redhat.com>
Message-ID: <3697127.Ll7J4v9xBa@localhost.localdomain>

On Wednesday, May 27, 2015 12:46:29 Juraci Paix?o Kr?hling wrote:
> On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> > I also propose to squash commits when it has sense.
> 
> +1 , having "one commit per jira" helps a lot in debugging :-)
>

-1 on squashing all PRs (if that is what you meant).

IMHO squashes are a nice feature to get rid of "garbage" commits PRIOR to 
pushing those commits upstream but SHOULD NOT be used to modify any commits 
that exists also remotely.

There are at least 4 reasons against squashing, IMHO:

1) possibility of messing things up like Mazz described.
2) divergence of histories in different repos (git branch|tag --contains 
ceases to work)
3) squashing a large PR renders bisecting useless
4) it makes it impossible to "follow" a history of a feature development
 
So I agree that it makes sense to squash certain commits, but only before they 
are merged into the official repos.

Ideally I think squash should only be used on local commits. But I do 
recognize that one may just push stuff to their personal forks that they later 
on would like to modify the history of (i.e. you're working on something and 
either push quickly commits you didn't "clean out" locally or change your mind 
later about something and don't want to "pollute" upstream with commits going 
back and forth on the same lines of code).

So IMHO a) the number of commits for a jira should be proportional to the size 
of the change and b) the commit history should be finalized before merging the 
PR and retained using the merge of the PR.

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



From theute at redhat.com  Thu May 28 06:53:32 2015
From: theute at redhat.com (Thomas Heute)
Date: Thu, 28 May 2015 12:53:32 +0200
Subject: [Hawkular-dev] Alert Email Config
In-Reply-To: <5566BF0A.9080300@redhat.com>
References: <556633BF.3020602@redhat.com> <5566BF0A.9080300@redhat.com>
Message-ID: <5566F3AC.2070804@redhat.com>

We may have usecases for both, but IMO we are not limiting much if we 
provide a single SMTP configuration for all and we simplify the 
configuration which is a big plus.

Thomas

On 05/28/2015 09:08 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/27/2015 11:14 PM, Jay Shaughnessy wrote:
>> Otherwise, a manual edit is required unless we provide for some
>> sort of build-time command line prop to be applied to Dist by the
>> build.
>
> We have it already, the "-Pdev" profile :) We could just apply an
> extra XML stylesheet if that profile is active that would replace some
> properties. The actual values could come from system property, and we
> could define those in the ~/.m2/settings.xml . This way, we get a
> build that fully works for devs while not making the actual values
> public.
>
> - - Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVZr8KAAoJECKM1e+fkPrXRQkH/2+tuYgZwlnT+cWgoqYqLjpb
> YzRXK9b+UjdAO7RZttrqVDx8RnjrQzel2qDhRXL9EXAony/eQyvDssmZ1bqJMBjP
> kMM2XHKZ50ns94LXEhI9MI0EgY7ejMPL92WtPnhFpBbnmEjE2a9EGV38ZDv6PJmk
> 2+OMpiBPmyFoRgf8XT+HIJZK2AaEwSGkoyB7mwyag/x18+lXBkPSoowVVgOmLMVF
> 1qIOOv4f1Jol8oAe/kKY/jsd3BDLRnNW1Z+HhOorwmf2c+jajRawSoqs8UKmxsXY
> yS9BeLI6LnsR5UHvt2dtIeagK8wa+H2dJq5551f/HUPNTP285Dvuh7Ao8kWq0iI=
> =D9dI
> -----END PGP SIGNATURE-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From lkrejci at redhat.com  Thu May 28 06:58:50 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 28 May 2015 12:58:50 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <3697127.Ll7J4v9xBa@localhost.localdomain>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<5565A085.8050506@redhat.com>
	<3697127.Ll7J4v9xBa@localhost.localdomain>
Message-ID: <1597027.1nhl5eI2Dt@localhost.localdomain>

On Thursday, May 28, 2015 12:50:55 Lukas Krejci wrote:
> On Wednesday, May 27, 2015 12:46:29 Juraci Paix?o Kr?hling wrote:
> > On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> > > I also propose to squash commits when it has sense.
> > 
> > +1 , having "one commit per jira" helps a lot in debugging :-)
> 

btw. if you want to figure out how a certain commit got merged into the 
master, you can use:

git log <COMMIT_HASH>..master --ancestry-path --merges

or

https://github.com/mhagger/git-when-merged


> -1 on squashing all PRs (if that is what you meant).
> 
> IMHO squashes are a nice feature to get rid of "garbage" commits PRIOR to
> pushing those commits upstream but SHOULD NOT be used to modify any commits
> that exists also remotely.
> 
> There are at least 4 reasons against squashing, IMHO:
> 
> 1) possibility of messing things up like Mazz described.
> 2) divergence of histories in different repos (git branch|tag --contains
> ceases to work)
> 3) squashing a large PR renders bisecting useless
> 4) it makes it impossible to "follow" a history of a feature development
> 
> So I agree that it makes sense to squash certain commits, but only before
> they are merged into the official repos.
> 
> Ideally I think squash should only be used on local commits. But I do
> recognize that one may just push stuff to their personal forks that they
> later on would like to modify the history of (i.e. you're working on
> something and either push quickly commits you didn't "clean out" locally or
> change your mind later about something and don't want to "pollute" upstream
> with commits going back and forth on the same lines of code).
> 
> So IMHO a) the number of commits for a jira should be proportional to the
> size of the change and b) the commit history should be finalized before
> merging the PR and retained using the merge of the PR.
> 
> > - Juca.
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From hrupp at redhat.com  Thu May 28 07:09:11 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 28 May 2015 13:09:11 +0200
Subject: [Hawkular-dev] On the way to the M1 release ...
Message-ID: <A2F3783C-8DDC-4A61-99C4-E729C20C9CA3@redhat.com>

Hey,

I see those things that need (at least) to be done/fixed for the next 
Wed release:

- pinger does not respond to deletions (HAWKULAR-235/-263)
- inventory does not delete metrics on resource deletion HWKINVENT-45
   (if INV can not make it, can UI send the delete metrics requests ?)
- duplicate URL addition HAWKULAR-255
- alerts is not multi-tenant yet (PR is sent, but may be too disruptive 
?) HWKALERTS-40
-- Add url fails across tenants for same url (HAWKULAR-277 contains a 
possible solution)
-- marking alerts as resolved (needs above PR for the backend)
- working pagination
- working availability charts

- move everything on non-snapshot releases
- update / write documentation on hawkular.org


As we will most probably not have full app servers functionality,
we should disable that tab so that users are not confused by it
and re-enable and work on it after the release.
Similar for the embedded agent.

Can we please concentrate on the above (and what else is needed that is 
not yet on the list) to get
the release out?

From lponce at redhat.com  Thu May 28 07:09:27 2015
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 28 May 2015 07:09:27 -0400 (EDT)
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <1597027.1nhl5eI2Dt@localhost.localdomain>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<5565A085.8050506@redhat.com>
	<3697127.Ll7J4v9xBa@localhost.localdomain>
	<1597027.1nhl5eI2Dt@localhost.localdomain>
Message-ID: <903030779.6780868.1432811367549.JavaMail.zimbra@redhat.com>

Hi,

My suggestion of the use of squash for some scenarios comes from our experience with GateIn/Portal:

https://github.com/gatein/gatein-portal/commits/master

I'm not talking about granularity.

I'm +1 to have a PR with non-squash for a review, but once consolidated, a squash can help to have a better organized history (i.e. marked with a JIRA/Bugzilla related to the task involved).

And I admit that there are situations where squashing has not sense.

But the project is growing and it's good to have some "grouping" with some logical background about what feature/fix/patch is related.

Just my 2 cents.

----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Thursday, May 28, 2015 12:58:50 PM
> Subject: Re: [Hawkular-dev] [process] tickets and PRs
> 
> On Thursday, May 28, 2015 12:50:55 Lukas Krejci wrote:
> > On Wednesday, May 27, 2015 12:46:29 Juraci Paix?o Kr?hling wrote:
> > > On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> > > > I also propose to squash commits when it has sense.
> > > 
> > > +1 , having "one commit per jira" helps a lot in debugging :-)
> > 
> 
> btw. if you want to figure out how a certain commit got merged into the
> master, you can use:
> 
> git log <COMMIT_HASH>..master --ancestry-path --merges
> 
> or
> 
> https://github.com/mhagger/git-when-merged
> 
> 
> > -1 on squashing all PRs (if that is what you meant).
> > 
> > IMHO squashes are a nice feature to get rid of "garbage" commits PRIOR to
> > pushing those commits upstream but SHOULD NOT be used to modify any commits
> > that exists also remotely.
> > 
> > There are at least 4 reasons against squashing, IMHO:
> > 
> > 1) possibility of messing things up like Mazz described.
> > 2) divergence of histories in different repos (git branch|tag --contains
> > ceases to work)
> > 3) squashing a large PR renders bisecting useless
> > 4) it makes it impossible to "follow" a history of a feature development
> > 
> > So I agree that it makes sense to squash certain commits, but only before
> > they are merged into the official repos.
> > 
> > Ideally I think squash should only be used on local commits. But I do
> > recognize that one may just push stuff to their personal forks that they
> > later on would like to modify the history of (i.e. you're working on
> > something and either push quickly commits you didn't "clean out" locally or
> > change your mind later about something and don't want to "pollute" upstream
> > with commits going back and forth on the same lines of code).
> > 
> > So IMHO a) the number of commits for a jira should be proportional to the
> > size of the change and b) the commit history should be finalized before
> > merging the PR and retained using the merge of the PR.
> > 
> > > - Juca.
> > > 
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Thu May 28 07:35:50 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Thu, 28 May 2015 13:35:50 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <3697127.Ll7J4v9xBa@localhost.localdomain>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>	<2089557544.5825010.1432723262490.JavaMail.zimbra@redhat.com>	<5565A085.8050506@redhat.com>
	<3697127.Ll7J4v9xBa@localhost.localdomain>
Message-ID: <5566FD96.8050002@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/28/2015 12:50 PM, Lukas Krejci wrote:
> -1 on squashing all PRs (if that is what you meant).
> 
> IMHO squashes are a nice feature to get rid of "garbage" commits
> PRIOR to pushing those commits upstream but SHOULD NOT be used to
> modify any commits that exists also remotely.

I think that's what Lucas meant, and this is certainly what I meant
:-) To make it clear: I'm in favor of squashing the multiple commits
*for a single PR*. Once the single commit for the PR is merged into
master, there's no coming back.

- - Juca.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZv2WAAoJECKM1e+fkPrXRs4H/itZ1k8L5GlOjBl7WRXrLQ/i
a6y8+TaPMgb/wQaRM/4GoQFNjKIdkQm9VOpPFxVwMa3WGLoZDxDCsbXl2FOdPtIY
sa38GA72ml58Jg+dJvxPu3/RSiZdtSJluBmsWmlAP4tIk+WrDwe8HIstvdtoGj0j
ODa5aQnkxKGvbYidJSIzOnJn/ZBI+wLSy5ERc6Lx3apvadZrGLxCLdiCgwt1kvbH
BkSlxytw4oVjzMsedE9Zk6D71PLRoTW5TZN5TlcKRNTL6Sehxx3HuYBkPOJ0zOga
3gmdtXipvrd9rOuqIgP5r4iFyTfhunNsH9NLBNvDju+R378MtUAIrccMtElVr1Y=
=MC5+
-----END PGP SIGNATURE-----

From lkrejci at redhat.com  Thu May 28 07:50:31 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 28 May 2015 13:50:31 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <5566FD96.8050002@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<3697127.Ll7J4v9xBa@localhost.localdomain>
	<5566FD96.8050002@redhat.com>
Message-ID: <1655063.PVeQD4f587@localhost.localdomain>

On Thursday, May 28, 2015 13:35:50 Juraci Paix?o Kr?hling wrote:
> On 05/28/2015 12:50 PM, Lukas Krejci wrote:
> > -1 on squashing all PRs (if that is what you meant).
> > 
> > IMHO squashes are a nice feature to get rid of "garbage" commits
> > PRIOR to pushing those commits upstream but SHOULD NOT be used to
> > modify any commits that exists also remotely.
> 
> I think that's what Lucas meant, and this is certainly what I meant
> 
> :-) To make it clear: I'm in favor of squashing the multiple commits
> 
> *for a single PR*. Once the single commit for the PR is merged into
> master, there's no coming back.
> 

I'm -1 on that then. This defeats the purpose of distributed development.

What that means is that you are basically rebasing everything on top of master 
while at the same time destroying the history of the feature development.

How can the contributors know their commits made it to the repository?

Also, why destroy information when you can easily "linearize" the log history?

git log --oneline --no-merges

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



From lkrejci at redhat.com  Thu May 28 08:03:33 2015
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 28 May 2015 14:03:33 +0200
Subject: [Hawkular-dev] [process] tickets and PRs
In-Reply-To: <903030779.6780868.1432811367549.JavaMail.zimbra@redhat.com>
References: <B3A89B52-B99C-4D33-84A3-586D2123FD39@redhat.com>
	<1597027.1nhl5eI2Dt@localhost.localdomain>
	<903030779.6780868.1432811367549.JavaMail.zimbra@redhat.com>
Message-ID: <4635793.XkF2W8V8Dc@localhost.localdomain>

My main objection to this is that the contributor cannot verify their commits 
made it to the repository, because you destroy that information by squashing.

History is easily linearized using git log facilities (--no-merges or --merges 
in particular).

To figure what jira/PR a commit belongs to you can:

git log <COMMIT_HASH>..master --ancestry-path --merges

I.e. you can get the SAME view of history like if you squashed every PR prior 
to merging by doing this:

git log --merges

while at the same time you retain all the information about the evolution of 
the PRs + the contributors can be sure their code is in, because the commit 
hashes still match.

It is also possible to effectively bisect. If you squash a PR consisting of 
5000 lines changed and you bisect a hard-to-debug problem, all you know is 
that somewhere in those 5000 lines there's a problem.

If on the other hand you keep the individual commits of the PR you can bisect 
directly to the arguably smaller commit that introduced the problem and find 
out the reasons for the breakage in a more focused context.

On Thursday, May 28, 2015 07:09:27 Lucas Ponce wrote:
> Hi,
> 
> My suggestion of the use of squash for some scenarios comes from our
> experience with GateIn/Portal:
> 
> https://github.com/gatein/gatein-portal/commits/master
> 
> I'm not talking about granularity.
> 
> I'm +1 to have a PR with non-squash for a review, but once consolidated, a
> squash can help to have a better organized history (i.e. marked with a
> JIRA/Bugzilla related to the task involved).
> 
> And I admit that there are situations where squashing has not sense.
> 
> But the project is growing and it's good to have some "grouping" with some
> logical background about what feature/fix/patch is related.
> 
> Just my 2 cents.
> 
> ----- Original Message -----
> 
> > From: "Lukas Krejci" <lkrejci at redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org> Sent: Thursday, May 28, 2015 12:58:50 PM
> > Subject: Re: [Hawkular-dev] [process] tickets and PRs
> > 
> > On Thursday, May 28, 2015 12:50:55 Lukas Krejci wrote:
> > > On Wednesday, May 27, 2015 12:46:29 Juraci Paix?o Kr?hling wrote:
> > > > On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> > > > > I also propose to squash commits when it has sense.
> > > > 
> > > > +1 , having "one commit per jira" helps a lot in debugging :-)
> > 
> > btw. if you want to figure out how a certain commit got merged into the
> > master, you can use:
> > 
> > git log <COMMIT_HASH>..master --ancestry-path --merges
> > 
> > or
> > 
> > https://github.com/mhagger/git-when-merged
> > 
> > > -1 on squashing all PRs (if that is what you meant).
> > > 
> > > IMHO squashes are a nice feature to get rid of "garbage" commits PRIOR
> > > to
> > > pushing those commits upstream but SHOULD NOT be used to modify any
> > > commits
> > > that exists also remotely.
> > > 
> > > There are at least 4 reasons against squashing, IMHO:
> > > 
> > > 1) possibility of messing things up like Mazz described.
> > > 2) divergence of histories in different repos (git branch|tag --contains
> > > ceases to work)
> > > 3) squashing a large PR renders bisecting useless
> > > 4) it makes it impossible to "follow" a history of a feature development
> > > 
> > > So I agree that it makes sense to squash certain commits, but only
> > > before
> > > they are merged into the official repos.
> > > 
> > > Ideally I think squash should only be used on local commits. But I do
> > > recognize that one may just push stuff to their personal forks that they
> > > later on would like to modify the history of (i.e. you're working on
> > > something and either push quickly commits you didn't "clean out" locally
> > > or
> > > change your mind later about something and don't want to "pollute"
> > > upstream
> > > with commits going back and forth on the same lines of code).
> > > 
> > > So IMHO a) the number of commits for a jira should be proportional to
> > > the
> > > size of the change and b) the commit history should be finalized before
> > > merging the PR and retained using the merge of the PR.
> > > 
> > > > - Juca.
> > > > 
> > > > _______________________________________________
> > > > 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  Thu May 28 08:43:04 2015
From: tsegismo at redhat.com (Thomas Segismont)
Date: Thu, 28 May 2015 14:43:04 +0200
Subject: [Hawkular-dev] Hawkular project switching to Docker-based
 Travis workers; was: Hitting Travis Limits
In-Reply-To: <5566EF35.4030300@redhat.com>
References: <5565D379.7020100@redhat.com>	<6138015A-693F-4958-AB80-3880E0AEB965@redhat.com>	<5565EBA0.6070201@redhat.com>
	<5566EF35.4030300@redhat.com>
Message-ID: <55670D58.9030508@redhat.com>

The Metrics build uses sudo to install collectd packages :(

Le 28/05/2015 12:34, Peter Palaga a ?crit :
> In my case, switching to Travis container-based infrastructure [1][2]
> helped - see [3] for how to do that.
>
> Hard to say which particular aspect of the container-based Travis worker
> has helped - here are some possible candidates:
> * more RAM
> * more CPUs (2 vs. 1.5)
> * faster network -> faster artifact downloads and therefore shorter
>     total build times -> less probable job timeouts
>
> Another important pro for switching to docker workers is that the job
> starts much faster than with the traditional VM worker.
>
> -- P
>
> [1] http://docs.travis-ci.com/user/workers/container-based-infrastructure/
> [2]
> http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/
>
> [3]
> https://github.com/ppalaga/hawkular/commit/351e046c3d383023e5a35fe5c15891f45c8b1c28#diff-354f30a63fb0907d4ad57269548329e3R4
>
>
>
> On 2015-05-27 18:06, Thomas Segismont wrote:
>> Le 27/05/2015 17:02, Heiko W.Rupp a ?crit :
>>>> I am not sure myself, which of the two is my case. Before I spend any
>>>> time on that, has anybody ever succeeded to start wildfly inside Travis
>>>> and run some integration test?
>>>
>>> We had Hawkular-metrics running on Travis including tests (iirc both
>>> with memory and Cassandra backend).
>>
>> Well, the memory backend is long gone. But as a matter of fact, the
>> Metrics build starts a Wildfly server twice: first in the rest-tests
>> module, then in the ptrans 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 mazz at redhat.com  Thu May 28 09:18:12 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 28 May 2015 09:18:12 -0400 (EDT)
Subject: [Hawkular-dev] On the way to the M1 release ...
In-Reply-To: <A2F3783C-8DDC-4A61-99C4-E729C20C9CA3@redhat.com>
References: <A2F3783C-8DDC-4A61-99C4-E729C20C9CA3@redhat.com>
Message-ID: <656040849.6856346.1432819092597.JavaMail.zimbra@redhat.com>

> As we will most probably not have full app servers functionality,
> we should disable that tab so that users are not confused by it
> and re-enable and work on it after the release.
> Similar for the embedded agent.

FWIW, we have app server resources in inventory and their metrics (and deployment availabilities) stored in metrics as of yesterday.

Whether the UI can do anything with it at this stage, I dunno. But perhaps you can do at least something at the top app server level and its couple of metrics.

From hrupp at redhat.com  Thu May 28 10:58:54 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 28 May 2015 16:58:54 +0200
Subject: [Hawkular-dev] On the way to the M1 release ...
In-Reply-To: <A2F3783C-8DDC-4A61-99C4-E729C20C9CA3@redhat.com>
References: <A2F3783C-8DDC-4A61-99C4-E729C20C9CA3@redhat.com>
Message-ID: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com>

Small update

On 28 May 2015, at 13:09, Heiko W.Rupp wrote:

> Hey,
>
> I see those things that need (at least) to be done/fixed for the next
> Wed release:
>
> - pinger does not respond to deletions (HAWKULAR-235/-263)
   In master now

- pinger is hardcoded to send to localhost -> Peter working on it. 
HAWKULAR-106

> - inventory does not delete metrics on resource deletion HWKINVENT-45
>  (if INV can not make it, can UI send the delete metrics requests ?)
> - duplicate URL addition HAWKULAR-255
> - alerts is not multi-tenant yet (PR is sent, but may be too 
> disruptive
> ?) HWKALERTS-40
> -- Add url fails across tenants for same url (HAWKULAR-277 contains a
> possible solution)

> -- marking alerts as resolved (needs above PR for the backend)
    ==> probably too much work on UI side => add checkboxes for 
"resolved"

> - working pagination
   ==> HAWKULAR-247 is meant and now marked as resolved

> - working availability charts
>
> - move everything on non-snapshot releases
> - update / write documentation on hawkular.org
>

> As we will most probably not have full app servers functionality,
> we should disable that tab so that users are not confused by it
> and re-enable and work on it after the release.
> Similar for the embedded agent.

We will decide that on monday.

>
> Can we please concentrate on the above (and what else is needed that 
> is
> not yet on the list) to get
> the release out?
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

From ppalaga at redhat.com  Thu May 28 13:31:02 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 28 May 2015 19:31:02 +0200
Subject: [Hawkular-dev] What should -Pdev do?
Message-ID: <556750D6.8030900@redhat.com>

Hi *,

sorry, for bringing this up so late on this list. I discussed this on 
#hawkular but probably outside US office hours and I totally 
underestimated the amount of emotions some of us are tied by to -Pdev.

There was a change by me recently that changed a little bit how -Pdev 
behaves.

Originally, a -Pdev just produced a bundle in which the default 
configuration was changed to suit the dev use case: esp. one had jdoe 
loaded by invoking simply standalone.sh.

As I worked on fixing the end to end tests in Hawkular, Lucas was fixing 
the REST tests in alerts. We both had the problem that the hawkular 
bundle that maven has downloaded from JBoss Nexus was build without 
-Pdev and as a consequence of that we could not run our integration 
tests by simply taking the bundle. We had to unzip the bundle, do what 
-Pdev does and only after that we could start it.

Hence, as a solution, I have prepared

   https://github.com/hawkular/hawkular/pull/134

which caused that the stuff originally present only in bundles built 
with -Pdev became available by default, but to use that dev stuff, 
wildfly needs to be started with

   standalone.sh -c standalone-itest.xml

because standalone-itest.xml is the place where the dev configuration is 
activated.

With this change, there is only one way to build a hk bundle, hence 
there is only one bundle to distribute and download but you can do both 
dev and prod things with it. Not having jdoe/password by running the 
default config is a good thing from the security PoV.

The bottom line is that -Pdev in the present master has one small issue 
that I fixed in https://github.com/hawkular/hawkular/pull/148

Please comment.

Thanks,

Peter

From mazz at redhat.com  Thu May 28 14:41:41 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 28 May 2015 14:41:41 -0400 (EDT)
Subject: [Hawkular-dev] What should -Pdev do?
In-Reply-To: <556750D6.8030900@redhat.com>
References: <556750D6.8030900@redhat.com>
Message-ID: <1652184417.7157435.1432838501267.JavaMail.zimbra@redhat.com>

What I care about is that I start the server the same no matter how I build (standalone.sh) when I'm developing.

You can leave it the way you have now, because you are building both production and dev builds in one shot using just "mvn install". You don't need or use -Pdev. So that's fine to me.

But I want to resurrect -Pdev again and just have it copy standalone-itest.xml to standalone.xml so I can start my build the same way I do any other time. This would affect no one other than a developer's local machine since we are the one's building with -Pdev locally (travis isn't building with it so it doesn't affect those builds).

Also, keep in mind that once we have a need to build a dev build that has different content (other than config) than a production build, what you have probably isn't going to work as-is. When would we ever do that? I can tell you in the RHQ case, we did things like build with the Oracle JDBC driver out of box with the -Pdev build, but did NOT have the Oracle JDBC driver in the production build (for licensing reasons, don't ask :)). We also had different .sql scripts that stored additional data in the database (e.g. test users and test security roles) when using -Pdev. So we actually had different dev builds vs. production builds. But RHQ QE always ran integration tests on the production builds, not dev builds (which sounds like we - Hawkular - are not - sounds like our itests are running the "dev" build, which may or may not be what QE wants to do).

So -Pdev (in the future) may not be solely to tweak standalone.xml and why I say having one "uber" build to support both dev and prod environments may not be viable in the future.

----- Original Message -----
> Hi *,
> 
> sorry, for bringing this up so late on this list. I discussed this on
> #hawkular but probably outside US office hours and I totally
> underestimated the amount of emotions some of us are tied by to -Pdev.
> 
> There was a change by me recently that changed a little bit how -Pdev
> behaves.
> 
> Originally, a -Pdev just produced a bundle in which the default
> configuration was changed to suit the dev use case: esp. one had jdoe
> loaded by invoking simply standalone.sh.
> 
> As I worked on fixing the end to end tests in Hawkular, Lucas was fixing
> the REST tests in alerts. We both had the problem that the hawkular
> bundle that maven has downloaded from JBoss Nexus was build without
> -Pdev and as a consequence of that we could not run our integration
> tests by simply taking the bundle. We had to unzip the bundle, do what
> -Pdev does and only after that we could start it.
> 
> Hence, as a solution, I have prepared
> 
>    https://github.com/hawkular/hawkular/pull/134
> 
> which caused that the stuff originally present only in bundles built
> with -Pdev became available by default, but to use that dev stuff,
> wildfly needs to be started with
> 
>    standalone.sh -c standalone-itest.xml
> 
> because standalone-itest.xml is the place where the dev configuration is
> activated.
> 
> With this change, there is only one way to build a hk bundle, hence
> there is only one bundle to distribute and download but you can do both
> dev and prod things with it. Not having jdoe/password by running the
> default config is a good thing from the security PoV.
> 
> The bottom line is that -Pdev in the present master has one small issue
> that I fixed in https://github.com/hawkular/hawkular/pull/148
> 
> Please comment.
> 
> Thanks,
> 
> Peter
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mithomps at redhat.com  Thu May 28 14:50:29 2015
From: mithomps at redhat.com (mike thompson)
Date: Thu, 28 May 2015 11:50:29 -0700
Subject: [Hawkular-dev] What should -Pdev do?
In-Reply-To: <556750D6.8030900@redhat.com>
References: <556750D6.8030900@redhat.com>
Message-ID: <8FE4ADE7-3FB3-49A9-9DB6-124B6E162ED9@redhat.com>


> On 28 May 2015, at 10:31, Peter Palaga <ppalaga at redhat.com> wrote:
> 
> Hi *,
> 
> sorry, for bringing this up so late on this list. I discussed this on 
> #hawkular but probably outside US office hours and I totally 
> underestimated the amount of emotions some of us are tied by to -Pdev.
> 
> There was a change by me recently that changed a little bit how -Pdev 
> behaves.
> 
> Originally, a -Pdev just produced a bundle in which the default 
> configuration was changed to suit the dev use case: esp. one had jdoe 
> loaded by invoking simply standalone.sh.
> 
> As I worked on fixing the end to end tests in Hawkular, Lucas was fixing 
> the REST tests in alerts. We both had the problem that the hawkular 
> bundle that maven has downloaded from JBoss Nexus was build without 
> -Pdev and as a consequence of that we could not run our integration 
> tests by simply taking the bundle. We had to unzip the bundle, do what 
> -Pdev does and only after that we could start it.
> 
> Hence, as a solution, I have prepared
> 
>   https://github.com/hawkular/hawkular/pull/134
> 
> which caused that the stuff originally present only in bundles built 
> with -Pdev became available by default, but to use that dev stuff, 
> wildfly needs to be started with
> 
>   standalone.sh -c standalone-itest.xml
> 
> because standalone-itest.xml is the place where the dev configuration is 
> activated.
> 
> With this change, there is only one way to build a hk bundle, hence 
> there is only one bundle to distribute and download but you can do both 
> dev and prod things with it. Not having jdoe/password by running the 
> default config is a good thing from the security PoV.
> 
> The bottom line is that -Pdev in the present master has one small issue 
> that I fixed in https://github.com/hawkular/hawkular/pull/148
> 
> Please comment.

To make it easy/consistent on us devs  and our community the only thing that I really care about is that to start up that we use ?standalone.sh? (without any special options). I think this is what developers expect without having to impart special knowledge about ?our build?.

My two cents

? Mike


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



From mazz at redhat.com  Thu May 28 15:13:30 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 28 May 2015 15:13:30 -0400 (EDT)
Subject: [Hawkular-dev] logging categories
In-Reply-To: <99682849.7169392.1432840271607.JavaMail.zimbra@redhat.com>
Message-ID: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>

I created a JIRA [1] and PR [2] so that when we build a dev build you'll get the console to show DEBUG log messages. In production mode, it stays at INFO level. I also added additional logging categories - double check that I added your component's logger categories correctly. In addition, I removed xsl:if checks and changed to xsl:choose in the .xsl.

Merge at your earliest convenience, please :)

[1] https://issues.jboss.org/browse/HWKINVENT-55
[2] https://github.com/hawkular/hawkular/pull/149

From ppalaga at redhat.com  Thu May 28 16:17:07 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 28 May 2015 22:17:07 +0200
Subject: [Hawkular-dev] logging categories
In-Reply-To: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
Message-ID: <556777C3.40809@redhat.com>

Hm... am I the only one who finds it useless to have all hawkular 
components on DEBUG even when developing? Too much data to see anything 
useful.

If there is no significant and immediate opposition against this, I'll 
have to introduce a separate standalone-dev.xml where DEBUG can be kept 
for all, but it has to be set back to INFO or even WARN in 
standalone-itest.xml because DEBUGging all makes the log size exceed 
Travis limit of 4MB.

-- P


On 2015-05-28 21:13, John Mazzitelli wrote:
> I created a JIRA [1] and PR [2] so that when we build a dev build
> you'll get the console to show DEBUG log messages. In production
> mode, it stays at INFO level. I also added additional logging
> categories - double check that I added your component's logger
> categories correctly. In addition, I removed xsl:if checks and
> changed to xsl:choose in the .xsl.
>
> Merge at your earliest convenience, please :)
>
> [1] https://issues.jboss.org/browse/HWKINVENT-55 [2]
> https://github.com/hawkular/hawkular/pull/149
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From mazz at redhat.com  Thu May 28 16:28:18 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 28 May 2015 16:28:18 -0400 (EDT)
Subject: [Hawkular-dev] logging categories
In-Reply-To: <556777C3.40809@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
	<556777C3.40809@redhat.com>
Message-ID: <1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>

I only put them all at DEBUG only because its a dev build so I figured why not. If its too noisy, we can put them at INFO out of box. I do want at least the categories listed, so devs can easily go in and turn on and off debug for their particular components of interest. I've been doing this by hand and its annoying, so that's why its in the dev build now.

The CONSOLE needs to be at DEBUG because without that, it doesn't matter what you do to the individual categories, the debug messages get eaten up. changing the CONSOLE level to DEBUG was just yet another thing I had to remember to change manually, so again that is why its in the dev build. Leave that at DEBUG, but the individual components at INFO could be a good middle-ground configuration.

----- Original Message -----
> Hm... am I the only one who finds it useless to have all hawkular
> components on DEBUG even when developing? Too much data to see anything
> useful.
> 
> If there is no significant and immediate opposition against this, I'll
> have to introduce a separate standalone-dev.xml where DEBUG can be kept
> for all, but it has to be set back to INFO or even WARN in
> standalone-itest.xml because DEBUGging all makes the log size exceed
> Travis limit of 4MB.
> 
> -- P
> 
> 
> On 2015-05-28 21:13, John Mazzitelli wrote:
> > I created a JIRA [1] and PR [2] so that when we build a dev build
> > you'll get the console to show DEBUG log messages. In production
> > mode, it stays at INFO level. I also added additional logging
> > categories - double check that I added your component's logger
> > categories correctly. In addition, I removed xsl:if checks and
> > changed to xsl:choose in the .xsl.
> >
> > Merge at your earliest convenience, please :)
> >
> > [1] https://issues.jboss.org/browse/HWKINVENT-55 [2]
> > https://github.com/hawkular/hawkular/pull/149
> > _______________________________________________ hawkular-dev mailing
> > list hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 
> 

From ppalaga at redhat.com  Thu May 28 16:35:23 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 28 May 2015 22:35:23 +0200
Subject: [Hawkular-dev] logging categories
In-Reply-To: <1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
	<556777C3.40809@redhat.com>
	<1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
Message-ID: <55677C0B.5050106@redhat.com>

On 2015-05-28 22:28, John Mazzitelli wrote:
> I only put them all at DEBUG only because its a dev build so I
> figured why not.

Travis has said clearly why not.

> If its too noisy, we can put them at INFO out of box. I do want at
> least the categories listed, so devs can easily go in and turn on and
> off debug for their particular components of interest.

Yes, that is a good idea.

> I've been
> doing this by hand and its annoying, so that's why its in the dev
> build now.
>
> The CONSOLE needs to be at DEBUG because without that, it doesn't
> matter what you do to the individual categories, the debug messages
> get eaten up. changing the CONSOLE level to DEBUG was just yet
> another thing I had to remember to change manually, so again that is
> why its in the dev build. Leave that at DEBUG, but the individual
> components at INFO could be a good middle-ground configuration.

+1 would you please do that, so that Travis stops complaining about the 
4MB limit?

Thanks,

Peter

>
> ----- Original Message -----
>> Hm... am I the only one who finds it useless to have all hawkular
>> components on DEBUG even when developing? Too much data to see
>> anything useful.
>>
>> If there is no significant and immediate opposition against this,
>> I'll have to introduce a separate standalone-dev.xml where DEBUG
>> can be kept for all, but it has to be set back to INFO or even WARN
>> in standalone-itest.xml because DEBUGging all makes the log size
>> exceed Travis limit of 4MB.
>>
>> -- P
>>
>>
>> On 2015-05-28 21:13, John Mazzitelli wrote:
>>> I created a JIRA [1] and PR [2] so that when we build a dev
>>> build you'll get the console to show DEBUG log messages. In
>>> production mode, it stays at INFO level. I also added additional
>>> logging categories - double check that I added your component's
>>> logger categories correctly. In addition, I removed xsl:if checks
>>> and changed to xsl:choose in the .xsl.
>>>
>>> Merge at your earliest convenience, please :)
>>>
>>> [1] https://issues.jboss.org/browse/HWKINVENT-55 [2]
>>> https://github.com/hawkular/hawkular/pull/149
>>> _______________________________________________ hawkular-dev
>>> mailing list hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>>


From mazz at redhat.com  Thu May 28 17:03:41 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 28 May 2015 17:03:41 -0400 (EDT)
Subject: [Hawkular-dev] logging categories
In-Reply-To: <55677C0B.5050106@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
	<556777C3.40809@redhat.com>
	<1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
	<55677C0B.5050106@redhat.com>
Message-ID: <1064889905.7265846.1432847021627.JavaMail.zimbra@redhat.com>

This will go in when this is merged:

https://github.com/hawkular/hawkular/pull/151

----- Original Message -----
> On 2015-05-28 22:28, John Mazzitelli wrote:
> > I only put them all at DEBUG only because its a dev build so I
> > figured why not.
> 
> Travis has said clearly why not.
> 
> > If its too noisy, we can put them at INFO out of box. I do want at
> > least the categories listed, so devs can easily go in and turn on and
> > off debug for their particular components of interest.
> 
> Yes, that is a good idea.
> 
> > I've been
> > doing this by hand and its annoying, so that's why its in the dev
> > build now.
> >
> > The CONSOLE needs to be at DEBUG because without that, it doesn't
> > matter what you do to the individual categories, the debug messages
> > get eaten up. changing the CONSOLE level to DEBUG was just yet
> > another thing I had to remember to change manually, so again that is
> > why its in the dev build. Leave that at DEBUG, but the individual
> > components at INFO could be a good middle-ground configuration.
> 
> +1 would you please do that, so that Travis stops complaining about the
> 4MB limit?
> 
> Thanks,
> 
> Peter
> 
> >
> > ----- Original Message -----
> >> Hm... am I the only one who finds it useless to have all hawkular
> >> components on DEBUG even when developing? Too much data to see
> >> anything useful.
> >>
> >> If there is no significant and immediate opposition against this,
> >> I'll have to introduce a separate standalone-dev.xml where DEBUG
> >> can be kept for all, but it has to be set back to INFO or even WARN
> >> in standalone-itest.xml because DEBUGging all makes the log size
> >> exceed Travis limit of 4MB.
> >>
> >> -- P
> >>
> >>
> >> On 2015-05-28 21:13, John Mazzitelli wrote:
> >>> I created a JIRA [1] and PR [2] so that when we build a dev
> >>> build you'll get the console to show DEBUG log messages. In
> >>> production mode, it stays at INFO level. I also added additional
> >>> logging categories - double check that I added your component's
> >>> logger categories correctly. In addition, I removed xsl:if checks
> >>> and changed to xsl:choose in the .xsl.
> >>>
> >>> Merge at your earliest convenience, please :)
> >>>
> >>> [1] https://issues.jboss.org/browse/HWKINVENT-55 [2]
> >>> https://github.com/hawkular/hawkular/pull/149
> >>> _______________________________________________ hawkular-dev
> >>> mailing list hawkular-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>
> >>
> >>
> 
> 

From hrupp at redhat.com  Fri May 29 03:56:55 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 29 May 2015 09:56:55 +0200
Subject: [Hawkular-dev] What should -Pdev do?
In-Reply-To: <1652184417.7157435.1432838501267.JavaMail.zimbra@redhat.com>
References: <556750D6.8030900@redhat.com>
	<1652184417.7157435.1432838501267.JavaMail.zimbra@redhat.com>
Message-ID: <BBAC14FB-6E4A-428C-A8C4-DCF1C13D52F2@redhat.com>

On 28 May 2015, at 20:41, John Mazzitelli wrote:
> So -Pdev (in the future) may not be solely to tweak standalone.xml and 
> why I say having one "uber" build to support both dev and prod 
> environments may not be viable in the future.

Yes. E.g. -Pdev may use embedded Cassandra while a non-dev
build relies on an external C* instance by default.

From hrupp at redhat.com  Fri May 29 03:57:17 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 29 May 2015 09:57:17 +0200
Subject: [Hawkular-dev] What should -Pdev do?
In-Reply-To: <8FE4ADE7-3FB3-49A9-9DB6-124B6E162ED9@redhat.com>
References: <556750D6.8030900@redhat.com>
	<8FE4ADE7-3FB3-49A9-9DB6-124B6E162ED9@redhat.com>
Message-ID: <D087B607-5B9C-468E-89CF-9E359A663780@redhat.com>

On 28 May 2015, at 20:50, mike thompson wrote:
> To make it easy/consistent on us devs  and our community the only 
> thing that I really care about is that to start up that we use 
> ?standalone.sh? (without any special options). I think this is 
> what developers expect without having to impart special knowledge 
> about ?our build?.

+1

From hrupp at redhat.com  Fri May 29 04:30:53 2015
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 29 May 2015 10:30:53 +0200
Subject: [Hawkular-dev] logging categories
In-Reply-To: <1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
	<556777C3.40809@redhat.com>
	<1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
Message-ID: <0521E534-AF27-4E54-8A1C-CB26B24130CA@redhat.com>

On 28 May 2015, at 22:28, John Mazzitelli wrote:
> The CONSOLE needs to be at DEBUG because without that, it doesn't 
> matter what you do to the individual categories, the debug messages 
> get eaten up. changing the CONSOLE level to DEBUG was just yet

Could we put the DEBUG level only for the *log file* (and make it wrap
over only at large log sizes) and keep the (stdout) console at INFO 
level?


From mazz at redhat.com  Fri May 29 07:01:38 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 29 May 2015 07:01:38 -0400 (EDT)
Subject: [Hawkular-dev] logging categories
In-Reply-To: <0521E534-AF27-4E54-8A1C-CB26B24130CA@redhat.com>
References: <1906226675.7170431.1432840410691.JavaMail.zimbra@redhat.com>
	<556777C3.40809@redhat.com>
	<1271028212.7238826.1432844898708.JavaMail.zimbra@redhat.com>
	<0521E534-AF27-4E54-8A1C-CB26B24130CA@redhat.com>
Message-ID: <1295900552.7483031.1432897298293.JavaMail.zimbra@redhat.com>

Well, I can only speak for me - I'll let others chime in as to how they like to work. Maybe I'm in a minority, I don't know.

When I'm developing, I'm running "standalone.sh" and watching the console. I like to see my DEBUG msgs on the console. If we only do it for log files, then I'm forced to run standalone.sh in background (or run it in another command line window) and then tail the log file. Extra steps I have to do for each run of my server that I would prefer not to do.

So to recap, before yesterday, I would do:

standalone.sh

If we keep with the standalone-itest.xml and only put debug msgs in log files, I would do:

standalone.sh -c standalone-itest.xml &
tail -f ../standalone/log/server.log

I like just running "standalone.sh" :)

----- Original Message -----
> On 28 May 2015, at 22:28, John Mazzitelli wrote:
> > The CONSOLE needs to be at DEBUG because without that, it doesn't
> > matter what you do to the individual categories, the debug messages
> > get eaten up. changing the CONSOLE level to DEBUG was just yet
> 
> Could we put the DEBUG level only for the *log file* (and make it wrap
> over only at large log sizes) and keep the (stdout) console at INFO
> level?
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From snegrea at redhat.com  Fri May 29 13:15:48 2015
From: snegrea at redhat.com (Stefan Negrea)
Date: Fri, 29 May 2015 13:15:48 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.3.4 - Release & Beyond
In-Reply-To: <1693797366.6100385.1432918852014.JavaMail.zimbra@redhat.com>
Message-ID: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>

Hello Everybody,

I am happy to announce release 0.3.4 of Hawkular Metrics. The release is anchored by stability improvements and Docker + Kubernetes work.

Here are the release highlights:

1) InfluxDB Compatibility Layer
 - pretty printing of query results with the 'pretty' query parameter
 - absolute moment operands in queries (ex: select * from test where time > 1501560s and time < 4560546h)
 - various fixes which allow to integrate nicely with Grafana (declaring Hawkular Metrics as an InfluxDB 0.8 datasource)

2) RxJavaMigration 
 - big refactoring to use RxJava instead of Guava's ListenableFuture
 - RxJava provides a much richer API for building asynchronous programs

3) Server Start-up
 - the server no longer requires Cassandra to be started first
 - any client requests will get back a 503 response code if the server has not fully initialized due to Cassandra being down at start up time

4) Docker and Kubernetes
 - all project docker images are now available in Docker Hub! Get them here:
    https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
    https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
 - improved replication controller support now means that both the Hawkular-Metrics and Cassandra images can be scaled up or down
 - various other smaller improvements, including better support for when containers startup

5) REST API (IMPORTANT!)
 - tenantId header was renamed to Hawkular-Tenant
 - tenantId header fallback was removed
 - GET {id}/tags only returns the tags, not the whole definition anymore
 - GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known issue)

6) UI Explorer 
 - was removed from the project
 - discussions are underway to find a new home for the functionality and code (probably hawkular-ui-components)
 - npm is no longer required to compile the project

7) Task Queue
 - a generic task queue was designed and developed as part of this release 
 - provides functionality for scheduling and executing background tasks or jobs
 - task execution is
    scalable - automatically distributed among Hawkular Metrics servers
    durable - Tasks are persisted
    fault tolerant - Tasks are rescheduled for future execution when there is a failure
 - it will serve as the foundation for 
    computing/storing aggregated metrics (i.e., rollups)
    deleting metrics
    changing data retention
 - this functionality will be basis for any background task based design for the project


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

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

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


Hawkular Metrics 0.3.5 and Beyond
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.3.5.
2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. The plan for 0.3.5 is to increase coverage.
3) Improved Docker and Kubernetes support - this is a long term goal for the project
4) RXJava - the initial transition from Guava was done in 0.3.4. Future releases will build upon this foundation.
 

A big "Thank  you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, and Heiko Rupp for their project contributions. Special mentions go to Jeeva Kandasamy and Jirka  Kremser for their project  help.


[1] https://issues.jboss.org/browse/HWKMETRICS-110

Thank you,
Stefan Negrea

Software Engineer


From ppalaga at redhat.com  Fri May 29 18:12:44 2015
From: ppalaga at redhat.com (Peter Palaga)
Date: Sat, 30 May 2015 00:12:44 +0200
Subject: [Hawkular-dev] Hawkular Metrics 0.3.4 - Release & Beyond
In-Reply-To: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>
References: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>
Message-ID: <5568E45C.3010106@redhat.com>

Hi *,

Mike T. has created the metrics-api-0.3.4 branch in hawkular project to 
gather changes related to this metrics upgrade:

https://github.com/hawkular/hawkular/tree/metrics-api-0.3.4

Fixes for Pinger, avail creator and e2e tests are there already.

-- P

On 2015-05-29 19:15, Stefan Negrea wrote:
> Hello Everybody,
>
> I am happy to announce release 0.3.4 of Hawkular Metrics. The release is anchored by stability improvements and Docker + Kubernetes work.
>
> Here are the release highlights:
>
> 1) InfluxDB Compatibility Layer
>   - pretty printing of query results with the 'pretty' query parameter
>   - absolute moment operands in queries (ex: select * from test where time > 1501560s and time < 4560546h)
>   - various fixes which allow to integrate nicely with Grafana (declaring Hawkular Metrics as an InfluxDB 0.8 datasource)
>
> 2) RxJavaMigration
>   - big refactoring to use RxJava instead of Guava's ListenableFuture
>   - RxJava provides a much richer API for building asynchronous programs
>
> 3) Server Start-up
>   - the server no longer requires Cassandra to be started first
>   - any client requests will get back a 503 response code if the server has not fully initialized due to Cassandra being down at start up time
>
> 4) Docker and Kubernetes
>   - all project docker images are now available in Docker Hub! Get them here:
>      https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
>      https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
>   - improved replication controller support now means that both the Hawkular-Metrics and Cassandra images can be scaled up or down
>   - various other smaller improvements, including better support for when containers startup
>
> 5) REST API (IMPORTANT!)
>   - tenantId header was renamed to Hawkular-Tenant
>   - tenantId header fallback was removed
>   - GET {id}/tags only returns the tags, not the whole definition anymore
>   - GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known issue)
>
> 6) UI Explorer
>   - was removed from the project
>   - discussions are underway to find a new home for the functionality and code (probably hawkular-ui-components)
>   - npm is no longer required to compile the project
>
> 7) Task Queue
>   - a generic task queue was designed and developed as part of this release
>   - provides functionality for scheduling and executing background tasks or jobs
>   - task execution is
>      scalable - automatically distributed among Hawkular Metrics servers
>      durable - Tasks are persisted
>      fault tolerant - Tasks are rescheduled for future execution when there is a failure
>   - it will serve as the foundation for
>      computing/storing aggregated metrics (i.e., rollups)
>      deleting metrics
>      changing data retention
>   - this functionality will be basis for any background task based design for the project
>
>
> Github Release:
> https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.4
>
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
>
> Jira release tracker:
> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327259/
>
>
> Hawkular Metrics 0.3.5 and Beyond
> 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.3.5.
> 2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. The plan for 0.3.5 is to increase coverage.
> 3) Improved Docker and Kubernetes support - this is a long term goal for the project
> 4) RXJava - the initial transition from Guava was done in 0.3.4. Future releases will build upon this foundation.
>
>
> A big "Thank  you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, and Heiko Rupp for their project contributions. Special mentions go to Jeeva Kandasamy and Jirka  Kremser for their project  help.
>
>
> [1] https://issues.jboss.org/browse/HWKMETRICS-110
>
> 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 mazz at redhat.com  Fri May 29 20:57:14 2015
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 29 May 2015 20:57:14 -0400 (EDT)
Subject: [Hawkular-dev] new agent to support port offsets
In-Reply-To: <675473023.7949671.1432946465249.JavaMail.zimbra@redhat.com>
Message-ID: <9787846.7950722.1432947434345.JavaMail.zimbra@redhat.com>

This is for https://issues.jboss.org/browse/HAWKULAR-285 . I presume supporting port-offsets is so we can run integration tests on different ports so they don't step on other app servers running on the same machine.

I fixed this in the agent - it now gets address/port values the "official" WildFly way via socket-binding-group/socket-binding (that is, we use the same configuration mechanisms all other WildFly subsystems use). This also fixes the issue of having to have ${jboss.bind.address} and ${jboss.http.port} variables in the agent's "url" attribute. That's because the "url" attribute is no longer required.

You will notice now the agent running in kettle doesn't configure any URL in <storage-adapter>. That's because the default is to assume it is running co-located with the server components, in which case the agent will look at the <socket-binding> for "http" and use its address and port (defined in the normal WildFly location down at the bottom of standalone.xml). So you can use port offsets and it will work.

To support agents running external from the server components, there is a new attribute in the agent's <storage-adapter> called "serverOutboundSocketBindingRef". If this is set, you must have a <outbound-socket-binding> setting of the same name in your socket-binding-group. This defines where your hawkular server is. The agent will use those socket binding settings to know where to talk to Hawkular server components. For example, if your agent has this:

   <storage-adapter serverOutboundSocketBindingRef="hawkular" ... />

You need to tell WildFly (and hence the agent) about that outbound binding in the socket-binding-group like this:

    <socket-binding-group default-interface="public" name="standard-sockets" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
        <outbound-socket-binding name="hawkular">
            <remote-destination host="your-external-hawkular-server-hostname" port="8080"/>
        </outbound-socket-binding>
    ...

When you do this, the agent will use "http://your-external-hawkular-server-hostname:8080" as its URL to the hawkular server.

This will get into kettle when this PR is merged: https://github.com/hawkular/hawkular/pull/162

From gbrown at redhat.com  Sun May 31 09:02:10 2015
From: gbrown at redhat.com (Gary Brown)
Date: Sun, 31 May 2015 09:02:10 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Metrics 0.3.4 - Release & Beyond
In-Reply-To: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>
References: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>
Message-ID: <2120498197.6994000.1433077330677.JavaMail.zimbra@redhat.com>

Congratulations on the release.

Is the task queue mechanism going to be moved into Hawkular Commons repo, so it can be reused by other hawkular components?

Regards
Gary

----- Original Message -----
> Hello Everybody,
> 
> I am happy to announce release 0.3.4 of Hawkular Metrics. The release is
> anchored by stability improvements and Docker + Kubernetes work.
> 
> Here are the release highlights:
> 
> 1) InfluxDB Compatibility Layer
>  - pretty printing of query results with the 'pretty' query parameter
>  - absolute moment operands in queries (ex: select * from test where time >
>  1501560s and time < 4560546h)
>  - various fixes which allow to integrate nicely with Grafana (declaring
>  Hawkular Metrics as an InfluxDB 0.8 datasource)
> 
> 2) RxJavaMigration
>  - big refactoring to use RxJava instead of Guava's ListenableFuture
>  - RxJava provides a much richer API for building asynchronous programs
> 
> 3) Server Start-up
>  - the server no longer requires Cassandra to be started first
>  - any client requests will get back a 503 response code if the server has
>  not fully initialized due to Cassandra being down at start up time
> 
> 4) Docker and Kubernetes
>  - all project docker images are now available in Docker Hub! Get them here:
>     https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
>     https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
>  - improved replication controller support now means that both the
>  Hawkular-Metrics and Cassandra images can be scaled up or down
>  - various other smaller improvements, including better support for when
>  containers startup
> 
> 5) REST API (IMPORTANT!)
>  - tenantId header was renamed to Hawkular-Tenant
>  - tenantId header fallback was removed
>  - GET {id}/tags only returns the tags, not the whole definition anymore
>  - GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known
>  issue)
> 
> 6) UI Explorer
>  - was removed from the project
>  - discussions are underway to find a new home for the functionality and code
>  (probably hawkular-ui-components)
>  - npm is no longer required to compile the project
> 
> 7) Task Queue
>  - a generic task queue was designed and developed as part of this release
>  - provides functionality for scheduling and executing background tasks or
>  jobs
>  - task execution is
>     scalable - automatically distributed among Hawkular Metrics servers
>     durable - Tasks are persisted
>     fault tolerant - Tasks are rescheduled for future execution when there is
>     a failure
>  - it will serve as the foundation for
>     computing/storing aggregated metrics (i.e., rollups)
>     deleting metrics
>     changing data retention
>  - this functionality will be basis for any background task based design for
>  the project
> 
> 
> Github Release:
> https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.4
> 
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
> 
> Jira release tracker:
> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327259/
> 
> 
> Hawkular Metrics 0.3.5 and Beyond
> 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of
> losing some fidelity. With task queue released in 0.3.4, the expectation is
> to start the actual implementation 0.3.5.
> 2) Update REST testing - while the current set of tests is a good gauge for
> regressions, the overall coverage is still low. The plan for 0.3.5 is to
> increase coverage.
> 3) Improved Docker and Kubernetes support - this is a long term goal for the
> project
> 4) RXJava - the initial transition from Guava was done in 0.3.4. Future
> releases will build upon this foundation.
>  
> 
> A big "Thank  you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt
> Wringe, Michael Burman, and Heiko Rupp for their project contributions.
> Special mentions go to Jeeva Kandasamy and Jirka  Kremser for their project
> help.
> 
> 
> [1] https://issues.jboss.org/browse/HWKMETRICS-110
> 
> 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 jsanda at redhat.com  Sun May 31 20:24:41 2015
From: jsanda at redhat.com (John Sanda)
Date: Sun, 31 May 2015 20:24:41 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.3.4 - Release & Beyond
In-Reply-To: <2120498197.6994000.1433077330677.JavaMail.zimbra@redhat.com>
References: <2057909343.6119024.1432919748967.JavaMail.zimbra@redhat.com>
	<2120498197.6994000.1433077330677.JavaMail.zimbra@redhat.com>
Message-ID: <0EFBCE85-7EF2-4CE1-A497-CAC4BE53EFDC@redhat.com>

 I do think it makes sense to move it into the hawkular commons repo. I can plan on do doing that soon.

> On May 31, 2015, at 9:02 AM, Gary Brown <gbrown at redhat.com> wrote:
> 
> Congratulations on the release.
> 
> Is the task queue mechanism going to be moved into Hawkular Commons repo, so it can be reused by other hawkular components?
> 
> Regards
> Gary
> 
> ----- Original Message -----
>> Hello Everybody,
>> 
>> I am happy to announce release 0.3.4 of Hawkular Metrics. The release is
>> anchored by stability improvements and Docker + Kubernetes work.
>> 
>> Here are the release highlights:
>> 
>> 1) InfluxDB Compatibility Layer
>> - pretty printing of query results with the 'pretty' query parameter
>> - absolute moment operands in queries (ex: select * from test where time >
>> 1501560s and time < 4560546h)
>> - various fixes which allow to integrate nicely with Grafana (declaring
>> Hawkular Metrics as an InfluxDB 0.8 datasource)
>> 
>> 2) RxJavaMigration
>> - big refactoring to use RxJava instead of Guava's ListenableFuture
>> - RxJava provides a much richer API for building asynchronous programs
>> 
>> 3) Server Start-up
>> - the server no longer requires Cassandra to be started first
>> - any client requests will get back a 503 response code if the server has
>> not fully initialized due to Cassandra being down at start up time
>> 
>> 4) Docker and Kubernetes
>> - all project docker images are now available in Docker Hub! Get them here:
>>    https://registry.hub.docker.com/u/hawkular/hawkular-metrics/
>>    https://registry.hub.docker.com/u/hawkular/hawkular-cassandra/
>> - improved replication controller support now means that both the
>> Hawkular-Metrics and Cassandra images can be scaled up or down
>> - various other smaller improvements, including better support for when
>> containers startup
>> 
>> 5) REST API (IMPORTANT!)
>> - tenantId header was renamed to Hawkular-Tenant
>> - tenantId header fallback was removed
>> - GET {id}/tags only returns the tags, not the whole definition anymore
>> - GET {id} returns the metric definition (see HWKMETRICS-110 [1] for known
>> issue)
>> 
>> 6) UI Explorer
>> - was removed from the project
>> - discussions are underway to find a new home for the functionality and code
>> (probably hawkular-ui-components)
>> - npm is no longer required to compile the project
>> 
>> 7) Task Queue
>> - a generic task queue was designed and developed as part of this release
>> - provides functionality for scheduling and executing background tasks or
>> jobs
>> - task execution is
>>    scalable - automatically distributed among Hawkular Metrics servers
>>    durable - Tasks are persisted
>>    fault tolerant - Tasks are rescheduled for future execution when there is
>>    a failure
>> - it will serve as the foundation for
>>    computing/storing aggregated metrics (i.e., rollups)
>>    deleting metrics
>>    changing data retention
>> - this functionality will be basis for any background task based design for
>> the project
>> 
>> 
>> Github Release:
>> https://github.com/hawkular/hawkular-metrics/releases/tag/0.3.4
>> 
>> JBoss Nexus Maven artifacts:
>> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/
>> 
>> Jira release tracker:
>> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327259/
>> 
>> 
>> Hawkular Metrics 0.3.5 and Beyond
>> 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of
>> losing some fidelity. With task queue released in 0.3.4, the expectation is
>> to start the actual implementation 0.3.5.
>> 2) Update REST testing - while the current set of tests is a good gauge for
>> regressions, the overall coverage is still low. The plan for 0.3.5 is to
>> increase coverage.
>> 3) Improved Docker and Kubernetes support - this is a long term goal for the
>> project
>> 4) RXJava - the initial transition from Guava was done in 0.3.4. Future
>> releases will build upon this foundation.
>> 
>> 
>> A big "Thank  you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt
>> Wringe, Michael Burman, and Heiko Rupp for their project contributions.
>> Special mentions go to Jeeva Kandasamy and Jirka  Kremser for their project
>> help.
>> 
>> 
>> [1] https://issues.jboss.org/browse/HWKMETRICS-110
>> 
>> Thank you,
>> Stefan Negrea
>> 
>> Software Engineer
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev