From theute at redhat.com  Mon May  2 03:50:55 2016
From: theute at redhat.com (Thomas Heute)
Date: Mon, 2 May 2016 09:50:55 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <5723A528.1090901@redhat.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<566384428.1686940.1461948161763.JavaMail.zimbra@redhat.com>
	<5723A528.1090901@redhat.com>
Message-ID: <CA+aN=Mq_VVrtS9k_rKXCB9j17yJM8z_niHFGPKf8JdAwbs8Veg@mail.gmail.com>

+1
I changed last week the description of 2 repositories to show OBSOLETE in
the list view for that reason (-nest and -bus)

On Fri, Apr 29, 2016 at 8:17 PM, Jay Shaughnessy <jshaughn at redhat.com>
wrote:

>
> This seems like a good thing, a place for stuff to live, as an example or
> reference, or possibly to be revived later.  Pinger and avail_creator may
> be good candidates as well.
>
>
> On 4/29/2016 12:42 PM, John Mazzitelli wrote:
>
> I would like to propose a new organization in Github to host projects that no
> longer receive development. "Hawkular-Archive" seems a good name for this
> purpose. The goal is to keep the main Hawkular org focused on important
> projects and at the same time preserve work that was already done but away
> from the main organization.
>
> >From a quick look at the current organization here are two repositories that
> can be moved right away: hawkular-metrics-openshift (Openshit 2.x cartridge
> for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code moved to
> another repo). Am I am sure we can find other repositories to move.
>
> In the long run we can develop some criteria for archiving projects but for
> now we can just do a one-time major cleanup.
>
> Any repositories that should be archived right away? Any other suggestions
> for a name? Any thoughts on the idea in general?
>
> This should be archived - it is obsolete - this was what the hawkular-agent grew out of, but this wildfly-monitor is no longer needed.
> https://github.com/hawkular/wildfly-monitor
> _______________________________________________
> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160502/54c63c69/attachment.html 

From hrupp at redhat.com  Mon May  2 03:58:31 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 02 May 2016 09:58:31 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
Message-ID: <6CE00A06-435D-4151-ACF2-445D186585F2@redhat.com>

On 29 Apr 2016, at 15:58, Stefan Negrea wrote:
> Any repositories that should be archived right away? Any other suggestions
> for a name? Any thoughts on the idea in general?

Are there other organizations that do this?

Within the GitHub organization overview projects with
no activity automatically go to the back/bottom, as
those with activity bubble to the top.

To me adding "obsolete" to the short description sounds
enough.

From ppalaga at redhat.com  Mon May  2 04:04:47 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 2 May 2016 10:04:47 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
Message-ID: <57270A1F.2020304@redhat.com>

Hi Stefan,

I vote against the idea of archiving through moving to another GitHub 
organization. This will break srcdeps builds, because the git repository 
URL is one of the things the srcdep mech assumes to be stable.

Thanks,

Peter

On 2016-04-29 15:58, Stefan Negrea wrote:
> Hello,
>
> I would like to propose a new organization in Github to host projects
> that no longer receive development. "Hawkular-Archive" seems a good name
> for this purpose. The goal is to keep the main Hawkular org focused on
> important projects and at the same time preserve work that was already
> done but away from the main organization.
>
>  From a quick look at the current organization here are two repositories
> that can be moved right away: hawkular-metrics-openshift  (Openshit 2.x
> cartridge for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code
> moved to another repo). Am I am sure we can find other repositories to
> move.
>
> In the long run we can develop some criteria for archiving projects but
> for now we can just do a one-time major cleanup.
>
> Any repositories that should be archived right away? Any other
> suggestions for a name? Any thoughts on the idea in general?
>
>
> 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 preethi.kannan at hcl.com  Mon May  2 04:51:51 2016
From: preethi.kannan at hcl.com (Preethi Kannan)
Date: Mon, 2 May 2016 08:51:51 +0000
Subject: [Hawkular-dev] Hawkular-BTM UI Details
Message-ID: <9219B79FAD94E8489B871C56A44D47DD72C9D285@chn-hclt-mbs05.HCLT.CORP.HCL.IN>

Hi Team,

I am analysing Hawkular-BTM and trying to record business transactions for various applications.
I wish to get more detail about the various tabs we have in the Hawkular-BTM UI like (Candidate,Active,Disabled,Ignored).
It would be great to know the various features and use Hawkular to a greater extent.

Thanks,
Preethi




::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

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

From theute at redhat.com  Mon May  2 05:08:27 2016
From: theute at redhat.com (Thomas Heute)
Date: Mon, 2 May 2016 11:08:27 +0200
Subject: [Hawkular-dev] Agent - EAP Domain mode support
Message-ID: <CA+aN=MoFvgHUz7aL01uoXSac0dd7Ob2di6=m3Ki+cB4mAjgHSQ@mail.gmail.com>

The question is likely for Mazz, but I wanted to check how we will support
the WF domain mode.

As far as I understand, we are now able to run the agent in the host
controller but wanted to know a bit more on how we expect the setup to be
(one agent on the host controller for the whole domain ?)

Also I wanted to ask if older versions of the app server could be supported
or only WF 10 ? (in particular in the context of EAP7/EAP6 support)

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160502/40cf0ab0/attachment.html 

From hrupp at redhat.com  Mon May  2 06:54:09 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 02 May 2016 12:54:09 +0200
Subject: [Hawkular-dev] communty distribution question
In-Reply-To: <1521566022.43907670.1461942175271.JavaMail.zimbra@redhat.com>
References: <57225111.7070404@redhat.com>
	<b1bcdbc3-df70-17db-67a6-ba5b5c28c543@redhat.com>
	<A0BC4FF9-F3C7-4C8C-8277-E87488121C39@redhat.com>
	<a564b249-68d8-0707-46ff-e39b256502b5@redhat.com>
	<006EABD9-F693-4E78-9DCF-9BC85EA43372@redhat.com>
	<44f2137a-a03a-ff20-2b22-f504d62914aa@redhat.com>
	<1E7C14C9-28B3-4233-BC24-9C4E67059DF8@redhat.com>
	<E497D8D7-7C73-444B-9E78-C0AD4BA22075@redhat.com>
	<1521566022.43907670.1461942175271.JavaMail.zimbra@redhat.com>
Message-ID: <2625BE1A-227C-4D41-8FCB-340128D136FB@redhat.com>

On 29 Apr 2016, at 17:02, Gary Brown wrote:

> But this is the key point - the community should be using the upstream 
> version of what will be productised - not just the backend with a 
> completely different front end.

As the backend is accessed via frontend, all interaction via the 
frontend will
use and "test" the backend.

> hawkular specific UI is for ease of use, then it implies we don't care 
> how complex our product is to setup. I think this is the wrong 
> approach, we should

I don't think this implication is correct.

> use this difficulty in the current setup to motivate us to fix it 
> rather than trying to avoid the issue.

I do not see why this is an either/or here.

I still see a value in the Hawkular we have (without the App server) tab
beyond the use case of Middleware Management in MiQ, but am not able
to predict (to address Juca's questions) what users can come up with.

From miburman at redhat.com  Mon May  2 08:27:00 2016
From: miburman at redhat.com (Michael Burman)
Date: Mon, 2 May 2016 08:27:00 -0400 (EDT)
Subject: [Hawkular-dev] Is there the feature to provide timegap between
 ripple restart of WildFly(JBoss EAP) cluster in Hawkular?
In-Reply-To: <CAPcfNJMWuZoZ44WE0zZbTpUAUXZ1go-_OX6j4neX7Sf-2TYPfQ@mail.gmail.com>
References: <CAPcfNJMWuZoZ44WE0zZbTpUAUXZ1go-_OX6j4neX7Sf-2TYPfQ@mail.gmail.com>
Message-ID: <913140995.85184351.1462192020184.JavaMail.zimbra@redhat.com>

Hi,

While you can't find this out of the box in the UI of RHQ/JON, this is easily doable with the RHQ-CLI interface. If you take a look at the samples directory and deploy-to-restart-JBAS.js (or jbossas.js), you can find function function _restartAS7(group) which uses _runOperationSequentially(group, operationName, operationConfig) method. This restarts in sequential order all the AS instances and waits for up to 60 seconds. 

To modify the behavior to do one instance at a time and wait for it to finish and abort if it fails, create a loop around the group object (to find single instance ids) in the _runOperationSequantially, change GroupOperation to single reosurce operation and keep rest of the process intact. That should do all the things you need.

So using either of those scripts as a base provides you the functionality you're looking for. While it's not currently modified to work with Wildfly, that one also is quite simple to add (the resource names / groups are the only things that should need changing).

  -  Micke

----- Original Message -----
From: "Jong Seok Won" <jwon at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Friday, April 29, 2016 5:12:16 AM
Subject: [Hawkular-dev] Is there the feature to provide timegap between ripple restart of WildFly(JBoss EAP) cluster in Hawkular?

Hi all~, 

Is there the feature to provide timegap between ripple restart of WildFly(JBoss EAP) cluster in Hawkular? 
If there is no feature, I'm curious there is a roadmap for this feature. 
Actually, this kind of feature is useful in a production environment. 

I've already checked RHQ(JON) however there is no for ripple restart. 
RHQ(JON) provides below in restart operation page of Group menu. 
1. "Execute: in the order specified below 
2. "Halt on Failure?" 


Thanks in advance. 
-- 


Kindly Regards, 

Ted Won 



_______________________________________________
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  2 09:56:04 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 02 May 2016 15:56:04 +0200
Subject: [Hawkular-dev] Doodle: Hawkular community release
Message-ID: <5CB5F7D5-BE29-47B8-A3BD-53CC89C52750@redhat.com>

I set up a Doodle about the future of the Hawkular community releases,
as there is a huge drive to not do them anymore.

http://doodle.com/poll/mqxzfkm27ekzuevf

Please fill this in. Poll ends latest Wed 4th 10am EST.

From miburman at redhat.com  Mon May  2 10:23:29 2016
From: miburman at redhat.com (Michael Burman)
Date: Mon, 2 May 2016 10:23:29 -0400 (EDT)
Subject: [Hawkular-dev] Is there the feature to provide timegap between
 ripple restart of WildFly(JBoss EAP) cluster in Hawkular?
In-Reply-To: <913140995.85184351.1462192020184.JavaMail.zimbra@redhat.com>
References: <CAPcfNJMWuZoZ44WE0zZbTpUAUXZ1go-_OX6j4neX7Sf-2TYPfQ@mail.gmail.com>
	<913140995.85184351.1462192020184.JavaMail.zimbra@redhat.com>
Message-ID: <522779298.85275381.1462199009981.JavaMail.zimbra@redhat.com>

Hi,

Silly me, the whole feature exists in RHQ/JON. And as far as I can tell, it's even available in the UI, GroupOperationSchedulesDetailView.

GroupOperationSchedule has:

setHaltOnFailure(boolean) where you can set it to fail.

setExecutionOrder():

     * The order to execute the operations - the first resource in the list is the first one to get its operation
     * invoked. If this is <code>null</code>, all operations can be invoked in any order and may even be done
     * concurrently.

So if you use setExecutionOrder() & setHaltOnFailure() with the GroupOperationSchedule before passing it to the ScheduleManager, you have the feature you requested.

  -  Micke

----- Original Message -----
From: "Michael Burman" <miburman at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Cc: rhq-users at lists.fedorahosted.org
Sent: Monday, May 2, 2016 3:27:00 PM
Subject: Re: [Hawkular-dev] Is there the feature to provide timegap between ripple restart of WildFly(JBoss EAP) cluster in Hawkular?

Hi,

While you can't find this out of the box in the UI of RHQ/JON, this is easily doable with the RHQ-CLI interface. If you take a look at the samples directory and deploy-to-restart-JBAS.js (or jbossas.js), you can find function function _restartAS7(group) which uses _runOperationSequentially(group, operationName, operationConfig) method. This restarts in sequential order all the AS instances and waits for up to 60 seconds. 

To modify the behavior to do one instance at a time and wait for it to finish and abort if it fails, create a loop around the group object (to find single instance ids) in the _runOperationSequantially, change GroupOperation to single reosurce operation and keep rest of the process intact. That should do all the things you need.

So using either of those scripts as a base provides you the functionality you're looking for. While it's not currently modified to work with Wildfly, that one also is quite simple to add (the resource names / groups are the only things that should need changing).

  -  Micke

----- Original Message -----
From: "Jong Seok Won" <jwon at redhat.com>
To: hawkular-dev at lists.jboss.org
Sent: Friday, April 29, 2016 5:12:16 AM
Subject: [Hawkular-dev] Is there the feature to provide timegap between ripple restart of WildFly(JBoss EAP) cluster in Hawkular?

Hi all~, 

Is there the feature to provide timegap between ripple restart of WildFly(JBoss EAP) cluster in Hawkular? 
If there is no feature, I'm curious there is a roadmap for this feature. 
Actually, this kind of feature is useful in a production environment. 

I've already checked RHQ(JON) however there is no for ripple restart. 
RHQ(JON) provides below in restart operation page of Group menu. 
1. "Execute: in the order specified below 
2. "Halt on Failure?" 


Thanks in advance. 
-- 


Kindly Regards, 

Ted Won 



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

From snegrea at redhat.com  Mon May  2 11:14:17 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 2 May 2016 10:14:17 -0500
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CA+aN=Mq_VVrtS9k_rKXCB9j17yJM8z_niHFGPKf8JdAwbs8Veg@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<566384428.1686940.1461948161763.JavaMail.zimbra@redhat.com>
	<5723A528.1090901@redhat.com>
	<CA+aN=Mq_VVrtS9k_rKXCB9j17yJM8z_niHFGPKf8JdAwbs8Veg@mail.gmail.com>
Message-ID: <CADt-fV_tg6ukx670b_OOy6YW35YA2v5Bk+G0md961G6Bx3vSaA@mail.gmail.com>

Thank you,
Stefan Negrea

Software Engineer

On Mon, May 2, 2016 at 2:50 AM, Thomas Heute <theute at redhat.com> wrote:

> +1
>


So far the count in this thread is 4 in favour and 2 against.



>
I changed last week the description of 2 repositories to show OBSOLETE in
> the list view for that reason (-nest and -bus)
>

'Obsolete' or even 'retired' might be too strong, hence 'archived'. I see
archived meaning that a repository no longer has active maintainers and it
will not be used by active Hawkular projects. Also, we should not exclude
the possibility of reviving some of the archived projects if needed again.
Obsolete is very strong and has some implications on the tech or code,
which might not be true for some repositories that no longer receive
contributions.


>
> On Fri, Apr 29, 2016 at 8:17 PM, Jay Shaughnessy <jshaughn at redhat.com>
> wrote:
>
>>
>> This seems like a good thing, a place for stuff to live, as an example or
>> reference, or possibly to be revived later.  Pinger and avail_creator may
>> be good candidates as well.
>>
>>
>> On 4/29/2016 12:42 PM, John Mazzitelli wrote:
>>
>> I would like to propose a new organization in Github to host projects that no
>> longer receive development. "Hawkular-Archive" seems a good name for this
>> purpose. The goal is to keep the main Hawkular org focused on important
>> projects and at the same time preserve work that was already done but away
>> from the main organization.
>>
>> >From a quick look at the current organization here are two repositories that
>> can be moved right away: hawkular-metrics-openshift (Openshit 2.x cartridge
>> for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code moved to
>> another repo). Am I am sure we can find other repositories to move.
>>
>> In the long run we can develop some criteria for archiving projects but for
>> now we can just do a one-time major cleanup.
>>
>> Any repositories that should be archived right away? Any other suggestions
>> for a name? Any thoughts on the idea in general?
>>
>> This should be archived - it is obsolete - this was what the hawkular-agent grew out of, but this wildfly-monitor is no longer needed.
>> https://github.com/hawkular/wildfly-monitor
>> _______________________________________________
>> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160502/0382208f/attachment.html 

From snegrea at redhat.com  Mon May  2 11:47:10 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 2 May 2016 10:47:10 -0500
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <6CE00A06-435D-4151-ACF2-445D186585F2@redhat.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<6CE00A06-435D-4151-ACF2-445D186585F2@redhat.com>
Message-ID: <CADt-fV-PXJgpEtEmHXndr+Tne1hhnLc3z-Tu5yhE2jy0TvF_Aw@mail.gmail.com>

On Mon, May 2, 2016 at 2:58 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:

> On 29 Apr 2016, at 15:58, Stefan Negrea wrote:
> > Any repositories that should be archived right away? Any other
> suggestions
> > for a name? Any thoughts on the idea in general?
>
> Are there other organizations that do this?
>

Did not look but I would not be surprised if others do it. At the same
time, this proposal is very sensible given the current situation of the
Hawkular org. I would not have proposed this if it did not make sense, so
whether other orgs do the same is not very important.


>
> Within the GitHub organization overview projects with
> no activity automatically go to the back/bottom, as
> those with activity bubble to the top.
>

> To me adding "obsolete" to the short description sounds
> enough.
>

Keeping 30 repositories in an org with fewer active contributors than
repositories makes thinks confusing (priorities, importance, relevance,
focus). Rather than taking the drastic step of purging repositories, this
is a good approach to still have code that was developed for reference
purposes or to restart development if needed.

As I said before, marking a repository as 'obsolete' is really strong
compared to moving it to a sister org. And letting repositories drop to the
bottom does not resolve potential confusion. I  see a new org with clear
mission a much much better approach.


_______________________________________________
> 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/20160502/62953b4d/attachment-0001.html 

From snegrea at redhat.com  Mon May  2 12:00:48 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 2 May 2016 11:00:48 -0500
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <57270A1F.2020304@redhat.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<57270A1F.2020304@redhat.com>
Message-ID: <CADt-fV81hYPaH62_oTp49arq1VNwEA28f2E=J_=PxoFH9DH=WQ@mail.gmail.com>

Hello Peter,

The type of problem that you raised is the exact reason why I proposed
another org. Why would you have a source dep on something that is no longer
maintained? That is really bad for the active project because the raw
unmaintained repository is included in something active. What if there are
issues with building the unmaintained code? Who will fix it? Nobody should
touch the archived repository!


The proper course of action for the scenario you described is to have the
active project drop the dependency on the archived project. And the
archived project should have had a release prior to being archived. The
active project should have depended on the officially released version of
the archived project and drop it as soon as possible.


If we set aside srcdep scenario, do you have any other objections to a new
org for archived repositories?


Thank you,
Stefan Negrea

Software Engineer

On Mon, May 2, 2016 at 3:04 AM, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi Stefan,
>
> I vote against the idea of archiving through moving to another GitHub
> organization. This will break srcdeps builds, because the git repository
> URL is one of the things the srcdep mech assumes to be stable.
>
> Thanks,
>
> Peter
>
> On 2016-04-29 15:58, Stefan Negrea wrote:
> > Hello,
> >
> > I would like to propose a new organization in Github to host projects
> > that no longer receive development. "Hawkular-Archive" seems a good name
> > for this purpose. The goal is to keep the main Hawkular org focused on
> > important projects and at the same time preserve work that was already
> > done but away from the main organization.
> >
> >  From a quick look at the current organization here are two repositories
> > that can be moved right away: hawkular-metrics-openshift  (Openshit 2.x
> > cartridge for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code
> > moved to another repo). Am I am sure we can find other repositories to
> > move.
> >
> > In the long run we can develop some criteria for archiving projects but
> > for now we can just do a one-time major cleanup.
> >
> > Any repositories that should be archived right away? Any other
> > suggestions for a name? Any thoughts on the idea in general?
> >
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160502/f8f642f1/attachment.html 

From mazz at redhat.com  Mon May  2 13:32:32 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 2 May 2016 13:32:32 -0400 (EDT)
Subject: [Hawkular-dev] Agent - EAP Domain mode support
In-Reply-To: <CA+aN=MoFvgHUz7aL01uoXSac0dd7Ob2di6=m3Ki+cB4mAjgHSQ@mail.gmail.com>
References: <CA+aN=MoFvgHUz7aL01uoXSac0dd7Ob2di6=m3Ki+cB4mAjgHSQ@mail.gmail.com>
Message-ID: <369608784.206837.1462210352374.JavaMail.zimbra@redhat.com>

> The question is likely for Mazz, but I wanted to check how we will support the WF domain mode.
> 
> As far as I understand, we are now able to run the agent in the host
> controller but wanted to know a bit more on how we expect the setup to be
> (one agent on the host controller for the whole domain ?)

<TL;DR>
I can run an agent in a host controller, but my main question is: What special functionality are these agents supposed to provide by having them run in the DC or HC (as opposed to running in all the standalone servers?) 
</TL;DR>

Right now, I have the agent at least able to run in a host controller. Each machine where you run your app servers has one host controller on them. Additionally, somewhere in your network, there is a single host controller that is configured to run as the domain controller (i.e. a "domain controller" is just a specially configured host controller - there is only one DC per domain).

We can run the agent today in a host controller (note: I have no agent configuration that tells the agent how to monitor that HC itself - there are not the same subsystems running in a HC than what you see running in a standalone WildFly server).

Do we want to run the agent only in the domain controller? Or do we want to run one agent in each host controller? I suspect we want to do the latter, not the former, simply because it seems to follow the typical way agents are run (one per machine). However, I'm still not clear what it is people want these agents running in a DC or HC to do. What special functionality are these agents supposed to provide by having them run in the DC or HC (as opposed to running in all the standalone servers?)

A different approach to consider is that we can have the host controllers inject agents into the WildFly servers they spawn (so we can then monitor each of the standalone servers that are started by the host controller since each standalone server can get an agents installed via the HC). I am not sure if HCs can actually push out module subsystem extensions like they can deployments - we'd have to ask wildfly-dev. But it would be cool to add the agent subsystem to the domain's profiles so when a HC runs a WildFly server it can not only push out the deployments but also the agent subsystem extension.


> Also I wanted to ask if older versions of the app server could be supported
> or only WF 10 ? (in particular in the context of EAP7/EAP6 support)

I have not tried to run this in a WF9 instance - but alot of this is fairly new in the WF codebase. There was a time when custom subsystem extensions could NOT run in these host controllers - wildfly devs had to add some stuff to get that to work. I suspect (though I do not know for sure) that it won't work on EAP6.

From hrupp at redhat.com  Mon May  2 13:46:20 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 02 May 2016 19:46:20 +0200
Subject: [Hawkular-dev] Agent - EAP Domain mode support
In-Reply-To: <369608784.206837.1462210352374.JavaMail.zimbra@redhat.com>
References: <CA+aN=MoFvgHUz7aL01uoXSac0dd7Ob2di6=m3Ki+cB4mAjgHSQ@mail.gmail.com>
	<369608784.206837.1462210352374.JavaMail.zimbra@redhat.com>
Message-ID: <FCC35A39-1B4A-4344-BE08-E8D75DD8D8E4@redhat.com>

> DC or HC (as opposed to running in all the standalone servers?)

Those servers are not standalone, but managed by HCs and DC.
HCs for example start and stop them.

> is just a specially configured host controller - there is only one DC 
> per domain).

Yes. And it is the central brain of such a setup.
All config change requests have to go through the DC.

> Do we want to run the agent only in the domain controller? Or do we 
> want to run one agent in each host controller? I suspect we want to do 
> the latter, not

We may run them in the HCs for monitoring of the managed servers of
this HC.

> A different approach to consider is that we can have the host 
> controllers inject agents into the WildFly servers they spawn (so we 
> can then monitor each

I think this is a larger hit on the memory footprint, which is not 
necessary.


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

From lkrejci at redhat.com  Mon May  2 14:33:21 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 02 May 2016 20:33:21 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CADt-fV_tg6ukx670b_OOy6YW35YA2v5Bk+G0md961G6Bx3vSaA@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<CA+aN=Mq_VVrtS9k_rKXCB9j17yJM8z_niHFGPKf8JdAwbs8Veg@mail.gmail.com>
	<CADt-fV_tg6ukx670b_OOy6YW35YA2v5Bk+G0md961G6Bx3vSaA@mail.gmail.com>
Message-ID: <19243435.ps1RGrvRPH@localhost.localdomain>

On Monday, May 02, 2016 10:14:17 AM Stefan Negrea wrote:
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> On Mon, May 2, 2016 at 2:50 AM, Thomas Heute <theute at redhat.com> wrote:
> > +1
> 
> So far the count in this thread is 4 in favour and 2 against.
> 

Count me in against this proposal. OBSOLETE is very well visible both in the 
list of projects of the Hawkular org as well as at the project page itself. I 
see no reason for creating more confusion with moving projects around. Just 
let them live at the bottom of the project list, clearly marked as obsolete.

What if we realize we need to "unarchive" some project? I don't see that 
happening but that would create even more confusion. 

I'd say KISS.

> 
> 
> 
> I changed last week the description of 2 repositories to show OBSOLETE in
> 
> > the list view for that reason (-nest and -bus)
> 
> 'Obsolete' or even 'retired' might be too strong, hence 'archived'. I see
> archived meaning that a repository no longer has active maintainers and it
> will not be used by active Hawkular projects. Also, we should not exclude
> the possibility of reviving some of the archived projects if needed again.
> Obsolete is very strong and has some implications on the tech or code,
> which might not be true for some repositories that no longer receive
> contributions.
> 
> > On Fri, Apr 29, 2016 at 8:17 PM, Jay Shaughnessy <jshaughn at redhat.com>
> > 
> > wrote:
> >> This seems like a good thing, a place for stuff to live, as an example or
> >> reference, or possibly to be revived later.  Pinger and avail_creator may
> >> be good candidates as well.
> >> 
> >> 
> >> On 4/29/2016 12:42 PM, John Mazzitelli wrote:
> >> 
> >> I would like to propose a new organization in Github to host projects
> >> that no longer receive development. "Hawkular-Archive" seems a good name
> >> for this purpose. The goal is to keep the main Hawkular org focused on
> >> important projects and at the same time preserve work that was already
> >> done but away from the main organization.
> >> 
> >> >From a quick look at the current organization here are two repositories
> >> >that>> 
> >> can be moved right away: hawkular-metrics-openshift (Openshit 2.x
> >> cartridge
> >> for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code moved to
> >> another repo). Am I am sure we can find other repositories to move.
> >> 
> >> In the long run we can develop some criteria for archiving projects but
> >> for
> >> now we can just do a one-time major cleanup.
> >> 
> >> Any repositories that should be archived right away? Any other
> >> suggestions
> >> for a name? Any thoughts on the idea in general?
> >> 
> >> This should be archived - it is obsolete - this was what the
> >> hawkular-agent grew out of, but this wildfly-monitor is no longer
> >> needed. https://github.com/hawkular/wildfly-monitor
> >> _______________________________________________
> >> hawkular-dev mailing
> >> listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo
> >> /hawkular-dev
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Lukas Krejci

From lkrejci at redhat.com  Mon May  2 16:13:16 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Mon, 02 May 2016 22:13:16 +0200
Subject: [Hawkular-dev] Reform Inventory REST API
Message-ID: <3686951.SjXrC94kPK@localhost.localdomain>

Hi everyone,

tl;dr
Inventory's REST API is ambiguous and doesn't reflect the generic structure of 
the inventory well. Let's change that before it's too late!

The access patterns in inventory's REST API predate the concept of the 
canonical path that we now use extensively throughout the model to uniquely 
identify the entities and because of that we're running into various issues 
with the REST API. From slight inconveniences to outright breakage due to 
ambiguous URLs.

Here I propose a reformed REST API centered around the canonical paths. It 
should have the same expressive power as the original REST API but should not 
suffer from the ambiguities and should be much more cohesive and "logical".
The only thing that was possible using 1 call in the old API that will require 
2 calls in the new API is disassociation of 2 entities (i.e. disassociate a 
metric from a resource, etc.). These operations are IMHO rather rare so I am 
not too worried about this.

I'd like to know your opinions on the new API:

URIs below are defined in EBNF,
CP stands for canonical path of some entity,
REL stands for a name of some relationship (pre-defined or user defined)

== sync endpoint
URI = "/", "sync", "/", CP;

This is the same as it is currently. There is a parallel thread from the last 
week about the evolution of sync that will be addressed, too.

== bulk endpoint
URI = "/", "bulk";
might go away - we have sync doing almost the same thing

== GET URLs

This is a little bit complex but what this does is that it enhances a 
canonical path as is currently known with the ability to define filters on 
each path progression step.
Basically, this is an attempt to express a graph traversal using an URL.

ANY = ? just a URI path-escaped string  representing an entity ID or 
relationship name ? ;
FILTER_NAME = "type" | "id" | "name" | "cp" | "identical" | "propertyName" | 
"propertyValue" ;
FILTER = FILTER_NAME , [ "=", ANY ] ; (* value is not required for the 
"identical" filter *)
PATH_SEGMENT_TYPE = "t" | "e" | "mp" | "f" | "rt" | "mt" | "ot" | "r" | "m" | 
"d" ;
PATH_SEGMENT_ID = ANY ;
PATH_STEP = "/", PATH_SEGMENT_TYPE, ";", PATH_SEGMENT_ID, { ";", FILTER } ;
WELL_KNOWN_REL = "contains" | "defines" | "incorporates" | "isParentOf" ;
ANY_REL = ANY ;
DIR_FILTER = ";", ( "in" | "out" | "both" )
REL_FILTER = ( "propertyName" | "propertyValue"), "=", ANY ;
REL_STEP = "/rl;", ( WELL_KNOWN_REL | ANY_REL ), [ DIR_FILTER ], { REL_FILTER 
} ;
FILTER_STEP = FILTER, { ";", FILTER } ;
RETURN_TYPE = "" | "treeHash" ;
PATH_END = ( PATH_STEP | FILTER_STEP ), RETURN_TYPE ;
URI = { ( PATH_STEP | FILTER_STEP ), [ REL_STEP ] }, [ PATH_END ];

The "identical" bit is currently not present in the REST API but is in the 
Java API. What it'd do here is that it would "widen" the start of the query 
from the one entity specified by the CP to all entities that are identical to 
it according to the identity hash rules (same id, same significant structure).

This is useful for scenarios like "querying all EAPs". The way this would work 
is that you'd have your resource type that you expect defined and a global 
level, possibly contained in a metadata pack. You'd then look for resources 
that are defined by the resource types identical to yours. Because feeds are 
free to (re-)define their resource types, this would match resources from 
feeds that have types identical to the global one. Note that there is no 
special relationship needed between the types - inventory figures this out 
automagically. This way we loosen the requirement for synchronizing the 
updates to the types defined by feeds and the user at the cost of "eventually 
consistent behavior" once the parties upgrade at their own pace.

=== Examples

==== Return a tenant

  /

==== Access Entity By Canonical Path

  /t;tenant_id/f;feed_id/rt;resourceType_id

This is actually equivalent to:

  /t;tenant_id/rl;contains;out/f;feed_id/rl;contains;out/rt;resourceType_id

which is no longer a canonical path but showcases how we declare "hops" over
specific relationships. "rl;contains;out" translates to "relationship with
name contains in the outgoing direction" and is implicit, if no other "hop"
between entities is specified.

To return the tree hash of the entity instead of the entity itself, one can:

  /f;feed_id/r;resource/treeHash

Note that the tenant in the path is optional because it can be deduced from 
the authorization details.

==== Accessing Targets of Relationships

  /f;feed_id/r;resource_id/rl;incorporates/type=metric

This is equivalent to the current 
`/feeds/feed_id/resources/resource_id/metrics`.

  /f;feed_id/r;resource_id/rl;isParentOf/

(notice the trailing slash)
"give me all children of resource with id 'resource_id'".

==== Accessing Relationships

  /f;feed_id/rl;contains

(notice the lack of trailing slash)
"find all the 'contains' relationships going out of the feed with id 
'feed_id'."

To access a single relationship with known id:

  /rl;relationship_id

==== More Complex Example

  /f;feed_id/type=rt;name=My%20EAP;identical/rl;defines/type=resource/rl;isParentOf/type=resource?recursive=true

"get a feed with id 'feed_id' and find all resource types called "My EAP" that 
it contains and all other resource types that are identical to it (them). Then 
find all the resources that those resource types define and find all the 
resources (recursively) that those resources are parents of."

=== Query Parameters

==== Paging `per_page`, `page`, `sort`, `order`
Paging is very expensive, because it implies fully iterating through the 
result set (to be able to sort or determine the total). We may think about 
some kind of server-side "live result set" that would hold the results on the 
server and be accessed using some kind of token (with a TTL). This is how 
neo4j does it and would avoid having to fetch the full result set on each 
paged request.

==== `recursive`
This causes the last hop (relationship + entity filter) to be recursively
searched and added to the results. Tinkerpop defines a more generic concept of
"loop" using a label as a marker of the start of the "recursive hop" but I 
don't think we need to be that powerful in a REST interface. Advanced users 
may want to use the `query` endpoint with the full power of Gremlin query.

== POST URLs
URI = "/", CP, "/", "resource" | "metric" | "resourceType" | ...;

The idea here is that you can create the entities only at their canonical 
positions. While the Java API allows for creation after a non-canonical 
traversal, I think this would be unnecessarily complicated for the REST API. 
The users would pass the familiar blueprint objects to these endpoints as they 
do currently.

Examples:

/feed - send a feed blueprint and this will create a new feed
/resourceType - send a resource type blueprint and it will create a new global 
resource type
/metricType
...
/f;feed/resourceType - creates a feed-local resource type

== PUT URLs
URI = "/", CP

just send an update object corresponding to the type of entity on the path

== DELETE URLs
URI = "/", CP

deletes the entity on the path

disassociation needs to be 2 steps - find the relationship in question and 
then
delete the relationship, e.g.:

  GET /f;feed_id/r;resource/rl;defines
  DELETE /rl;id-found-in-the-results-from-the-previous-query

== Advanced Querying
URI = "/", "query"

free form, read-only gremlin query for more complex queries (this needs
to wait for the port to Tinkerpop3)


From hrupp at redhat.com  Tue May  3 02:51:35 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 03 May 2016 08:51:35 +0200
Subject: [Hawkular-dev] Reform Inventory REST API
In-Reply-To: <3686951.SjXrC94kPK@localhost.localdomain>
References: <3686951.SjXrC94kPK@localhost.localdomain>
Message-ID: <A66DC4DF-8C2D-42F0-87E8-1D41E930E82C@redhat.com>

Hey Lucas,

I agree that there is room for improvement, as I had to find out by 
using
inventory via the Ruby Gem.

What timeline do you have in mind, the changes seem large and will
probably impact not only inventory, but also the RubyGem (and existing
code in MiQ), the WF agent, the work of our GSoC students and others,
that we may not even know of.
Would it make sense to keep the old api in parallel for a while and
request the new one via different media type or api-root?

> Here I propose a reformed REST API centered around the canonical 
> paths. It

I like that - especially for things like GET requests where the CP is 
known
and all cases of "create something below X", where X can be identified 
by CP.
I think we already return the CP in all objects, so re-using this in 
subsequent calls
is good.

> This is useful for scenarios like "querying all EAPs". The way this 
> would work
> is that you'd have your resource type that you expect defined and a 
> global
> level, possibly contained in a metadata pack. You'd then look for 
> resources

Which we need for such types as EAP.

> ==== Access Entity By Canonical Path
>
>   /t;tenant_id/f;feed_id/rt;resourceType_id

Will the '/' in the CP need encoding. If so, I propose to change this
to a character that does not need url-encoding.
Otherwise requests get non-human-readable

GET %2ft;foo%2f;bar..

Which may get worse for local parts that contain '/' again as in the
subsystem=datasources/datasource=default case.

I think it would help me to explicitly write some of those
cases down (full working curl-command).

> ==== Accessing Targets of Relationships
>
>   /f;feed_id/r;resource_id/rl;incorporates/type=metric

I can't say I particularly like it - probably because it is longer

> This is equivalent to the current
> `/feeds/feed_id/resources/resource_id/metrics`.
>
>   /f;feed_id/r;resource_id/rl;isParentOf/
>
> (notice the trailing slash)

This sounds like a constant source of confusion

> "give me all children of resource with id 'resource_id'".
>
> ==== Accessing Relationships
>
>   /f;feed_id/rl;contains
>
> (notice the lack of trailing slash)

together with this.


> "find all the 'contains' relationships going out of the feed with id
> 'feed_id'."
>

> result set (to be able to sort or determine the total). We may think 
> about
> some kind of server-side "live result set" that would hold the results 
> on the
> server and be accessed using some kind of token (with a TTL). This is 
> how
> neo4j does it and would avoid having to fetch the full result set on 
> each
> paged request.

Sounds good. Do we know though how much paging is currently used?
Right now in the MiQ use case we don't use it, but that may change in
the future when we have to pull in hundreds or thousands of servers
from Hawkular.

> == POST URLs
> URI = "/", CP, "/", "resource" | "metric" | "resourceType" | ...;

SO with a CP starting with '/'
is this then POST /%2f;bla%2f;tfoo/resource ?

> The idea here is that you can create the entities only at their 
> canonical

What is the CP of something that does not exist yet? Or does the above
represent the to-be parent ? Looks like the latter from the examples 
below.

> positions. While the Java API allows for creation after a 
> non-canonical
> traversal, I think this would be unnecessarily complicated for the 
> REST API.
> The users would pass the familiar blueprint objects to these endpoints 
> as they
> do currently.
>
> Examples:
>
> /feed - send a feed blueprint and this will create a new feed
> /resourceType - send a resource type blueprint and it will create a 
> new global
> resource type
> /metricType
> ...
> /f;feed/resourceType - creates a feed-local resource type

> == PUT URLs
> URI = "/", CP
>
> just send an update object corresponding to the type of entity on the 
> path

+1


> == DELETE URLs
> URI = "/", CP

+1


From theute at redhat.com  Tue May  3 05:18:49 2016
From: theute at redhat.com (Thomas Heute)
Date: Tue, 3 May 2016 11:18:49 +0200
Subject: [Hawkular-dev] Agent - EAP Domain mode support
In-Reply-To: <369608784.206837.1462210352374.JavaMail.zimbra@redhat.com>
References: <CA+aN=MoFvgHUz7aL01uoXSac0dd7Ob2di6=m3Ki+cB4mAjgHSQ@mail.gmail.com>
	<369608784.206837.1462210352374.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MrGSUkocHOYQuZwUuSEjqgpZVuN6BjQ9mxY+6TscxqeCQ@mail.gmail.com>

On Mon, May 2, 2016 at 7:32 PM, John Mazzitelli <mazz at redhat.com> wrote:

> > The question is likely for Mazz, but I wanted to check how we will
> support the WF domain mode.
> >
> > As far as I understand, we are now able to run the agent in the host
> > controller but wanted to know a bit more on how we expect the setup to be
> > (one agent on the host controller for the whole domain ?)
>
> <TL;DR>
> I can run an agent in a host controller, but my main question is: What
> special functionality are these agents supposed to provide by having them
> run in the DC or HC (as opposed to running in all the standalone servers?)
> </TL;DR>
>



>
> Right now, I have the agent at least able to run in a host controller.
> Each machine where you run your app servers has one host controller on
> them. Additionally, somewhere in your network, there is a single host
> controller that is configured to run as the domain controller (i.e. a
> "domain controller" is just a specially configured host controller - there
> is only one DC per domain).
>
> We can run the agent today in a host controller (note: I have no agent
> configuration that tells the agent how to monitor that HC itself - there
> are not the same subsystems running in a HC than what you see running in a
> standalone WildFly server).
>
> Do we want to run the agent only in the domain controller? Or do we want
> to run one agent in each host controller? I suspect we want to do the
> latter, not the former, simply because it seems to follow the typical way
> agents are run (one per machine). However, I'm still not clear what it is
> people want these agents running in a DC or HC to do. What special
> functionality are these agents supposed to provide by having them run in
> the DC or HC (as opposed to running in all the standalone servers?)
>

We need to be able to "visualize" server groups and domains --> that
topology needs to fill in the inventory
We'll want to be able to execute operations on a domain or server group,
like deploy an application (without re-implementing the logic for failed
deployment on 1 or more servers for instance)

If the domain/host controller collects all metrics for all servers or if
each server reports itself is more of an implementation detail. Also I
understand that have all data going through the domain controller would
create a bottleneck, one per host seems more suitable on first thoughts.

Thomas



>
> A different approach to consider is that we can have the host controllers
> inject agents into the WildFly servers they spawn (so we can then monitor
> each of the standalone servers that are started by the host controller
> since each standalone server can get an agents installed via the HC). I am
> not sure if HCs can actually push out module subsystem extensions like they
> can deployments - we'd have to ask wildfly-dev. But it would be cool to add
> the agent subsystem to the domain's profiles so when a HC runs a WildFly
> server it can not only push out the deployments but also the agent
> subsystem extension.
>
>
> > Also I wanted to ask if older versions of the app server could be
> supported
> > or only WF 10 ? (in particular in the context of EAP7/EAP6 support)
>
> I have not tried to run this in a WF9 instance - but alot of this is
> fairly new in the WF codebase. There was a time when custom subsystem
> extensions could NOT run in these host controllers - wildfly devs had to
> add some stuff to get that to work. I suspect (though I do not know for
> sure) that it won't work on EAP6.
> _______________________________________________
> 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/20160503/f56ce9fd/attachment.html 

From hrupp at redhat.com  Tue May  3 05:50:04 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 03 May 2016 11:50:04 +0200
Subject: [Hawkular-dev] Fwd:  Doodle: Hawkular community release
References: <5CB5F7D5-BE29-47B8-A3BD-53CC89C52750@redhat.com>
Message-ID: <C9B69117-523C-426A-B73A-8F4AE10903F7@redhat.com>

If you haven't had a look yet, please do and vote.
If you don't want your name to be listed, vote anonymously.


> From: Heiko W.Rupp <hrupp at redhat.com>
> To: Discussions around Hawkular development <hawkular-dev at lists.jboss.org>
> Subject: [Hawkular-dev] Doodle: Hawkular community release
> Date: Mon, 02 May 2016 15:56:04 +0200
>
> I set up a Doodle about the future of the Hawkular community releases,
> as there is a huge drive to not do them anymore.
>
> http://doodle.com/poll/mqxzfkm27ekzuevf
>
> Please fill this in. Poll ends latest Wed 4th 10am EST.
> _______________________________________________
> 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  3 06:04:13 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 3 May 2016 06:04:13 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <19243435.ps1RGrvRPH@localhost.localdomain>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<CA+aN=Mq_VVrtS9k_rKXCB9j17yJM8z_niHFGPKf8JdAwbs8Veg@mail.gmail.com>
	<CADt-fV_tg6ukx670b_OOy6YW35YA2v5Bk+G0md961G6Bx3vSaA@mail.gmail.com>
	<19243435.ps1RGrvRPH@localhost.localdomain>
Message-ID: <1074157548.454265.1462269853326.JavaMail.zimbra@redhat.com>

I +1 on the extra repo to remove the crap we all know we'll never want to look at again.

wildfly-monitor is one such thing that I just want to delete - but if I can't just outright delete it, then move it out of hawkular repo because its useless and will never be used again.

----- Original Message -----
> On Monday, May 02, 2016 10:14:17 AM Stefan Negrea wrote:
> > Thank you,
> > Stefan Negrea
> > 
> > Software Engineer
> > 
> > On Mon, May 2, 2016 at 2:50 AM, Thomas Heute <theute at redhat.com> wrote:
> > > +1
> > 
> > So far the count in this thread is 4 in favour and 2 against.
> > 
> 
> Count me in against this proposal. OBSOLETE is very well visible both in the
> list of projects of the Hawkular org as well as at the project page itself. I
> see no reason for creating more confusion with moving projects around. Just
> let them live at the bottom of the project list, clearly marked as obsolete.
> 
> What if we realize we need to "unarchive" some project? I don't see that
> happening but that would create even more confusion.
> 
> I'd say KISS.
> 
> > 
> > 
> > 
> > I changed last week the description of 2 repositories to show OBSOLETE in
> > 
> > > the list view for that reason (-nest and -bus)
> > 
> > 'Obsolete' or even 'retired' might be too strong, hence 'archived'. I see
> > archived meaning that a repository no longer has active maintainers and it
> > will not be used by active Hawkular projects. Also, we should not exclude
> > the possibility of reviving some of the archived projects if needed again.
> > Obsolete is very strong and has some implications on the tech or code,
> > which might not be true for some repositories that no longer receive
> > contributions.
> > 
> > > On Fri, Apr 29, 2016 at 8:17 PM, Jay Shaughnessy <jshaughn at redhat.com>
> > > 
> > > wrote:
> > >> This seems like a good thing, a place for stuff to live, as an example
> > >> or
> > >> reference, or possibly to be revived later.  Pinger and avail_creator
> > >> may
> > >> be good candidates as well.
> > >> 
> > >> 
> > >> On 4/29/2016 12:42 PM, John Mazzitelli wrote:
> > >> 
> > >> I would like to propose a new organization in Github to host projects
> > >> that no longer receive development. "Hawkular-Archive" seems a good name
> > >> for this purpose. The goal is to keep the main Hawkular org focused on
> > >> important projects and at the same time preserve work that was already
> > >> done but away from the main organization.
> > >> 
> > >> >From a quick look at the current organization here are two repositories
> > >> >that>>
> > >> can be moved right away: hawkular-metrics-openshift (Openshit 2.x
> > >> cartridge
> > >> for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code moved to
> > >> another repo). Am I am sure we can find other repositories to move.
> > >> 
> > >> In the long run we can develop some criteria for archiving projects but
> > >> for
> > >> now we can just do a one-time major cleanup.
> > >> 
> > >> Any repositories that should be archived right away? Any other
> > >> suggestions
> > >> for a name? Any thoughts on the idea in general?
> > >> 
> > >> This should be archived - it is obsolete - this was what the
> > >> hawkular-agent grew out of, but this wildfly-monitor is no longer
> > >> needed. https://github.com/hawkular/wildfly-monitor
> > >> _______________________________________________
> > >> hawkular-dev mailing
> > >> listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo
> > >> /hawkular-dev
> > >> 
> > >> 
> > >> 
> > >> _______________________________________________
> > >> hawkular-dev mailing list
> > >> hawkular-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> --
> Lukas Krejci
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From auszon3 at gmail.com  Tue May  3 06:52:24 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Tue, 03 May 2016 10:52:24 +0000
Subject: [Hawkular-dev] [GSoC] Status update from Austin
Message-ID: <CAJ5TdT=D=TKJFE3bL1JVi19OYWdTXDLuWFHMxJZGyzv4v2tr=w@mail.gmail.com>

Working on:
vertx-hawkular-mertics: https://github.com/vert-x3/vertx-hawkular-metrics
Trying to enable it to send designated metrics with PR #20
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160503/7b75131a/attachment.html 

From lkrejci at redhat.com  Tue May  3 08:12:39 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 03 May 2016 14:12:39 +0200
Subject: [Hawkular-dev] Reform Inventory REST API
In-Reply-To: <A66DC4DF-8C2D-42F0-87E8-1D41E930E82C@redhat.com>
References: <3686951.SjXrC94kPK@localhost.localdomain>
	<A66DC4DF-8C2D-42F0-87E8-1D41E930E82C@redhat.com>
Message-ID: <4157457.VYBMNU4Zza@localhost.localdomain>

On Tuesday, May 03, 2016 08:51:35 AM Heiko W.Rupp wrote:
> Hey Lucas,
> 
> I agree that there is room for improvement, as I had to find out by
> using
> inventory via the Ruby Gem.
> 
> What timeline do you have in mind, the changes seem large and will
> probably impact not only inventory, but also the RubyGem (and existing
> code in MiQ), the WF agent, the work of our GSoC students and others,
> that we may not even know of.
> Would it make sense to keep the old api in parallel for a while and
> request the new one via different media type or api-root?
> 
> > Here I propose a reformed REST API centered around the canonical
> > paths. It
> 
> I like that - especially for things like GET requests where the CP is
> known
> and all cases of "create something below X", where X can be identified
> by CP.
> I think we already return the CP in all objects, so re-using this in
> subsequent calls
> is good.
> 
> > This is useful for scenarios like "querying all EAPs". The way this
> > would work
> > is that you'd have your resource type that you expect defined and a
> > global
> > level, possibly contained in a metadata pack. You'd then look for
> > resources
> 
> Which we need for such types as EAP.
> 
> > ==== Access Entity By Canonical Path
> > 
> >   /t;tenant_id/f;feed_id/rt;resourceType_id
> 
> Will the '/' in the CP need encoding. If so, I propose to change this
> to a character that does not need url-encoding.
> Otherwise requests get non-human-readable
> 
> GET %2ft;foo%2f;bar..
> 

No, that would literally be:

  GET /t;foo/f;bar

If a segment of a path already contained a forward slash, only that'd need to 
be encoded (and would return encoded in responses from inventory).

I.e. if you were creating a resource with a slash, you'd do a post:

  POST /t;foo/f;bar/r;my-parent
  {
     "id" : "subsystem=datasources/datasource=default",
     ...
  }

You'd get a location back in headers:

  Location: /hawkular/inventory/t;foo/f;bar/r;my-
parent/subsystem%3Ddatasources%2Fdatasource%3Ddefault

If you chop off "/hawkular/inventory" from that location you get the canonical 
path of your new entity (which you also obtain in the JSON response of the 
post request).

You don't need to do any additional encoding of that - just concatenate it to 
the URL you're building next.. Inventory encodes the CPs in URI-safe manner 
(took me a while to get there, but I think we do that correctly now).


> Which may get worse for local parts that contain '/' again as in the
> subsystem=datasources/datasource=default case.
> 
> I think it would help me to explicitly write some of those
> cases down (full working curl-command).
> 
> > ==== Accessing Targets of Relationships
> > 
> >   /f;feed_id/r;resource_id/rl;incorporates/type=metric
> 
> I can't say I particularly like it - probably because it is longer
> 

Yeah, me neither - but it's the cost of the additional flexibility we're 
adding here. You'd use the very same pattern if you'd want to ask for your 
custom relationship called "mummy" (or "critical" or whatever) - for that the 
current REST API is way more cumbersome.

Currently, you'd have to list all the relationships of the resource, find the 
IDs of the relationships with the "mummy" name, do another N requests to get 
the details of those relationship to find out their targets targets and then 
do another N requests to get the details of those targets.


> > This is equivalent to the current
> > `/feeds/feed_id/resources/resource_id/metrics`.
> > 
> >   /f;feed_id/r;resource_id/rl;isParentOf/
> > 
> > (notice the trailing slash)
> 
> This sounds like a constant source of confusion
> 
> > "give me all children of resource with id 'resource_id'".
> > 
> > ==== Accessing Relationships
> > 
> >   /f;feed_id/rl;contains
> > 
> > (notice the lack of trailing slash)
> 
> together with this.

Yes... I need to take a look at the grammar if adding "/entities" (instead of 
the "/") and "/relationships" (instead of no "/") doesn't give rise to some 
ambiguities - gut feeling is that it doesn't.

> 
> > "find all the 'contains' relationships going out of the feed with id
> > 'feed_id'."
> > 
> > 
> > result set (to be able to sort or determine the total). We may think
> > about
> > some kind of server-side "live result set" that would hold the results
> > on the
> > server and be accessed using some kind of token (with a TTL). This is
> > how
> > neo4j does it and would avoid having to fetch the full result set on
> > each
> > paged request.
> 
> Sounds good. Do we know though how much paging is currently used?
> Right now in the MiQ use case we don't use it, but that may change in
> the future when we have to pull in hundreds or thousands of servers
> from Hawkular.
> 

Paging was a specific request of the (old) UI which uses it heavily in all the 
inventory-based listings.

> > == POST URLs
> > URI = "/", CP, "/", "resource" | "metric" | "resourceType" | ...;
> 
> SO with a CP starting with '/'
> is this then POST /%2f;bla%2f;tfoo/resource ?
>

No, that'd literally be:

  POST /;bla/;tfoo/resource

which is an invalid CP ;), but you get the point - the CPs as they are encoded 
by inventory are already URI-safe and can just be concatenated to a URL, no 
need for escaping.

> > The idea here is that you can create the entities only at their
> > canonical
> 
> What is the CP of something that does not exist yet? Or does the above
> represent the to-be parent ? Looks like the latter from the examples
> below.
> 

Yes, POST /cp-of-the-parent/type-of-new-entity

> > positions. While the Java API allows for creation after a
> > non-canonical
> > traversal, I think this would be unnecessarily complicated for the
> > REST API.
> > The users would pass the familiar blueprint objects to these endpoints
> > as they
> > do currently.
> > 
> > Examples:
> > 
> > /feed - send a feed blueprint and this will create a new feed
> > /resourceType - send a resource type blueprint and it will create a
> > new global
> > resource type
> > /metricType
> > ...
> > /f;feed/resourceType - creates a feed-local resource type
> > 
> > == PUT URLs
> > URI = "/", CP
> > 
> > just send an update object corresponding to the type of entity on the
> > path
> 
> +1
> 
> > == DELETE URLs
> > URI = "/", CP
> 
> +1
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Lukas Krejci

From lkrejci at redhat.com  Tue May  3 08:29:58 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 03 May 2016 14:29:58 +0200
Subject: [Hawkular-dev] Reform Inventory REST API
In-Reply-To: <A66DC4DF-8C2D-42F0-87E8-1D41E930E82C@redhat.com>
References: <3686951.SjXrC94kPK@localhost.localdomain>
	<A66DC4DF-8C2D-42F0-87E8-1D41E930E82C@redhat.com>
Message-ID: <487429459.DxnkfRoUi4@localhost.localdomain>

Forgot to answer you compatibility and timing questions...

On Tuesday, May 03, 2016 08:51:35 AM Heiko W.Rupp wrote:
> Hey Lucas,
> 
> I agree that there is room for improvement, as I had to find out by
> using
> inventory via the Ruby Gem.
> 
> What timeline do you have in mind, the changes seem large and will
> probably impact not only inventory, but also the RubyGem (and existing
> code in MiQ), the WF agent, the work of our GSoC students and others,
> that we may not even know of.

This is very high on the list of things to the in the next release.

> Would it make sense to keep the old api in parallel for a while and
> request the new one via different media type or api-root?
>

I think it makes sense to do that. Given we're in 0.x phase of the project I'm 
a little bit reluctant to add "v2" or somesuch to the root though. What about 
instead of prefixing the new API, prefix the old API - that would require 
change in all clients, but a very easy one - instead of "/hawkular/inventory", 
they'd prefix their URLs with "/hawkular/inventory/deprecated"...

> > Here I propose a reformed REST API centered around the canonical
> > paths. It
> 
> I like that - especially for things like GET requests where the CP is
> known
> and all cases of "create something below X", where X can be identified
> by CP.
> I think we already return the CP in all objects, so re-using this in
> subsequent calls
> is good.
> 
> > This is useful for scenarios like "querying all EAPs". The way this
> > would work
> > is that you'd have your resource type that you expect defined and a
> > global
> > level, possibly contained in a metadata pack. You'd then look for
> > resources
> 
> Which we need for such types as EAP.
> 
> > ==== Access Entity By Canonical Path
> > 
> >   /t;tenant_id/f;feed_id/rt;resourceType_id
> 
> Will the '/' in the CP need encoding. If so, I propose to change this
> to a character that does not need url-encoding.
> Otherwise requests get non-human-readable
> 
> GET %2ft;foo%2f;bar..
> 
> Which may get worse for local parts that contain '/' again as in the
> subsystem=datasources/datasource=default case.
> 
> I think it would help me to explicitly write some of those
> cases down (full working curl-command).
> 
> > ==== Accessing Targets of Relationships
> > 
> >   /f;feed_id/r;resource_id/rl;incorporates/type=metric
> 
> I can't say I particularly like it - probably because it is longer
> 
> > This is equivalent to the current
> > `/feeds/feed_id/resources/resource_id/metrics`.
> > 
> >   /f;feed_id/r;resource_id/rl;isParentOf/
> > 
> > (notice the trailing slash)
> 
> This sounds like a constant source of confusion
> 
> > "give me all children of resource with id 'resource_id'".
> > 
> > ==== Accessing Relationships
> > 
> >   /f;feed_id/rl;contains
> > 
> > (notice the lack of trailing slash)
> 
> together with this.
> 
> > "find all the 'contains' relationships going out of the feed with id
> > 'feed_id'."
> > 
> > 
> > result set (to be able to sort or determine the total). We may think
> > about
> > some kind of server-side "live result set" that would hold the results
> > on the
> > server and be accessed using some kind of token (with a TTL). This is
> > how
> > neo4j does it and would avoid having to fetch the full result set on
> > each
> > paged request.
> 
> Sounds good. Do we know though how much paging is currently used?
> Right now in the MiQ use case we don't use it, but that may change in
> the future when we have to pull in hundreds or thousands of servers
> from Hawkular.
> 
> > == POST URLs
> > URI = "/", CP, "/", "resource" | "metric" | "resourceType" | ...;
> 
> SO with a CP starting with '/'
> is this then POST /%2f;bla%2f;tfoo/resource ?
> 
> > The idea here is that you can create the entities only at their
> > canonical
> 
> What is the CP of something that does not exist yet? Or does the above
> represent the to-be parent ? Looks like the latter from the examples
> below.
> 
> > positions. While the Java API allows for creation after a
> > non-canonical
> > traversal, I think this would be unnecessarily complicated for the
> > REST API.
> > The users would pass the familiar blueprint objects to these endpoints
> > as they
> > do currently.
> > 
> > Examples:
> > 
> > /feed - send a feed blueprint and this will create a new feed
> > /resourceType - send a resource type blueprint and it will create a
> > new global
> > resource type
> > /metricType
> > ...
> > /f;feed/resourceType - creates a feed-local resource type
> > 
> > == PUT URLs
> > URI = "/", CP
> > 
> > just send an update object corresponding to the type of entity on the
> > path
> 
> +1
> 
> > == DELETE URLs
> > URI = "/", CP
> 
> +1
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Lukas Krejci

From lkrejci at redhat.com  Tue May  3 11:27:35 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 03 May 2016 17:27:35 +0200
Subject: [Hawkular-dev] Inventory 0.15.1.Final released
Message-ID: <4781983.XiTVKmxXVh@localhost.localdomain>

Hi all,

Inventory 0.15.0.Final had a serious performance regression in the bulk 
insert. The 0.15.1.Final fixes that problem and the performance should now be 
on the same order of magnitude as previously (still 0.15.x is slower on 
creates, updates and deletes than 0.14.x thanks to the new identity hashing 
functionality).

Please update as soon as possible,

Thanks, 

-- 
Lukas Krejci

From gbrown at redhat.com  Wed May  4 05:55:40 2016
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 4 May 2016 05:55:40 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular-BTM UI Details
In-Reply-To: <9219B79FAD94E8489B871C56A44D47DD72C9D285@chn-hclt-mbs05.HCLT.CORP.HCL.IN>
References: <9219B79FAD94E8489B871C56A44D47DD72C9D285@chn-hclt-mbs05.HCLT.CORP.HCL.IN>
Message-ID: <331442386.45363284.1462355740173.JavaMail.zimbra@redhat.com>

Hi Preethi

The documentation regarding the purpose of each of the tabs is here: http://www.hawkular.org/docs/components/btm/index.html#_business_transactions

There will be another release in the next week which actually removes the 'disabled' tab - as these are now displayed on the main page showing a summary of all business transactions. So once that release is out, we will need to make some changes to the docs.

If you have specific questions, not addressed by the documentation, then please let me know.

Regards
Gary

----- Original Message -----
> 
> 
> Hi Team,
> 
> 
> 
> I am analysing Hawkular-BTM and trying to record business transactions for
> various applications.
> 
> I wish to get more detail about the various tabs we have in the Hawkular-BTM
> UI like (Candidate,Active,Disabled,Ignored).
> 
> It would be great to know the various features and use Hawkular to a greater
> extent.
> 
> 
> 
> Thanks,
> 
> Preethi
> 
> 
> 
> 
> 
> 
> 
> 
> ::DISCLAIMER::
> ----------------------------------------------------------------------------------------------------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
> 
> ----------------------------------------------------------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> 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  4 10:03:46 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 4 May 2016 09:03:46 -0500
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
Message-ID: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>

Hello Everybody,

I am happy to announce release 0.15.0 of Hawkular Metrics. This is one of
the largest ever Hawkular Metrics releases with a lot of new features and
changes.


Here is a list of major changes:

   1.

   *Cassandra 3.5*
   - Cassandra 3.5 is now the supported version of Cassandra
      - Cassandra 2.2.x support is deprecated
   2.

   *Schema Management Tools*
   - First release with tooling for schema change management
      - Only upgrades are supported; incremental schema changes are
      installed when Hawkular Metrics starts
      - Going forward new versions of Hawkular Metrics can be installed
      without the need to start with a fresh database or manually
update existing
      database even if the schema has been modified in the new version
      - For more details: HWKMETRICS-361
      <https://issues.jboss.org/browse/HWKMETRICS-361>, Cassalog
      <https://github.com/jsanda/cassalog>
   3.

   **/stats & */raw Replace */data*
   - */data has been **deprecated* and functionality split into two single
      purpose endpoints, this is applicable for all metric types
(gauge, counter,
      availability, and string)
      - */stats endpoints return bucketed, statistical or query-time
      aggregated data
      - */raw endpoints accept and return raw data for a metric
      - */data is being deprecated, will not receive any updates going
      forward, and will be removed in future releases. There is no
clear timeline
      for the removal since a lot of clients use it; it will be around at least
      for another two releases.
      - Please update your code to use the new endpoints and follow the
      release notes for more details regarding removal.
      - For more details: HWKMETRICS-24
      <https://issues.jboss.org/browse/HWKMETRICS-24>, HWKMETRICS-57
      <https://issues.jboss.org/browse/HWKMETRICS-57>
   4.

   *Data Point Tags*
   - An optional set of tags can be supplied with each data point when
      inserting data. Unlike metric definition tags, data point tags cannot be
      modified. HWKMETRICS-368
      <https://issues.jboss.org/browse/HWKMETRICS-368>, HWKMETRICS-54
      <https://issues.jboss.org/browse/HWKMETRICS-54>
      - Tag based bucketing for data points is supported for counters and
      gauges HWKMETRICS-377 <https://issues.jboss.org/browse/HWKMETRICS-377>,
      HWKMETRICS-373 <https://issues.jboss.org/browse/HWKMETRICS-373>
      - New endpoints for filtering and grouping data by tags:
         - GET /hawkular/metrics/gauges/{id}/stats/tags/{tags}
         - GET /hawkular/metrics/counters/{id}/stats/tags/{tags}
      5.

   *Tags*
   - Deleting tags only requires the tag keys and not the values, this
      simplifies the process for tag deletion. For backwards compatibility, the
      API will still accept name value pairs but will not take the value into
      account HWKMETRICS-385
      <https://issues.jboss.org/browse/HWKMETRICS-385>
      - A new endpoint was added to query for the available values
      contained in a tag HWKMETRICS-197
      <https://issues.jboss.org/browse/HWKMETRICS-197>
         - Endpoint: GET hawkular/metrics/gauge/tags/{tags}
         - Example: GET hawkular/metrics/gauge/tags/hostname:*01*
returns hostname:
         ["web01prod", "web01qa", "backend01prod", "backend01qa" ]
      6.

   *String Metric Type (Experimental)*
   - Hawkular Metrics now provides a string metric type. This release
      introduces new endpoints for reading and writing string data points
      HWKMETRICS-384 <https://issues.jboss.org/browse/HWKMETRICS-384>
      - There is a 2 KB size limit for each data point. That limit may be
      configurable in future releases.
      - New endpoints under /strings are experimental, so changes which
      break backwards compatibility could be introduced in future releases. The
      experimental tag allows time for feedback to better determine
what the API
      should be.
   7.

   *Asynchronous authentication for Openshift Metrics*
   - Important performance improvement: the authentication code now uses a
      non blocking HTTP Client (Undertow Client) to validate authentication
      tokens calling Kubernetes' master
      - Performance improvements details: #481 (comment)
      <https://github.com/hawkular/hawkular-metrics/pull/481#issue-148320027>,
      #481 (comment)
      <https://github.com/hawkular/hawkular-metrics/pull/481#issuecomment-209876952>
      - For more details: HWKMETRICS-330
      <https://issues.jboss.org/browse/HWKMETRICS-330>
   8.

   *API Updates*
   - Stats are excluded from empty bucket data points rather than returning
      the string NaN and zero for the samples property HWKMETRICS-396
      <https://issues.jboss.org/browse/HWKMETRICS-396>
      - Endpoints that use the order param also accept lower case values
      HWKMETRICS-389 <https://issues.jboss.org/browse/HWKMETRICS-389>
      - Sum is included in bucket output for gauges and counters
      HWKMETRICS-370 <https://issues.jboss.org/browse/HWKMETRICS-370>
      - The status page can now be loaded over HTTPS without errors
      HWKMETRICS-388 <https://issues.jboss.org/browse/HWKMETRICS-388>
      - Added overwrite param to tenant and metric creation. This will only
      overwrite the configuration (such as retention settings or tags) of the
      metric or tenant and not the actual data stored. Also overwrite the
      retention will only affect new data points added and not existing data
      already stored HWKMETRICS-148
      <https://issues.jboss.org/browse/HWKMETRICS-148>


*Updated Documentation*

The entire Hawkular Metrics User Guide
<http://www.hawkular.org/docs/components/metrics/index.html> has been
rewritten and it is now accessible from the top menu of Hawkular.org
<https://hawkular.org>. The new guide has extensive documentation about
metric types, query and tagging capabilities along lots of examples. Thank
you @jsanda <https://github.com/jsanda> for this amazing update!


*Java Client (Experimental)*

Thanks to an effort started by the Hawkular QE
<https://github.com/hawkular-qe> organization, Hawkular Metrics now has an
official Java client <https://github.com/hawkular/hawkular-client-java>.
The repository has been fully transferred to Hawkular community where will
be maintained going forward. The client is now at an experimental alpha
stage and we expect to polish the API and internals in the coming months.

A big thank you goes to @jkandasa <https://github.com/jkandasa> and @vnugent
<https://github.com/vnugent> for creating and the maintaining the project
until now. @jkandasa <https://github.com/jkandasa> will continue to serve
as an active contributor and core member.


*Blog Posts & Articles*

Here are some recently published Metrics related blog posts and articles
from around the Hawkular community:
Monitoring JVM applications with jmxtrans
<http://www.hawkular.org/blog/2016/04/19/jmxtrans-to-hawkular-metrics.html>
by @tsegismont <https://github.com/tsegismont>

Collecting Metrics from Prometheus Endpoints
<http://www.hawkular.org/blog/2016/04/22/collecting-metrics-from-prometheus-endpoints.html>
by @jmazzitelli <https://github.com/jmazzitelli>

Hawkular Data Mining 0.1.0.Final Released
<http://www.hawkular.org/blog/2016/04/21/datamining-first-release.html> by
@pavolloffay <https://github.com/pavolloffay>



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

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


Hawkular Metrics Clients
  * Ruby: https://github.com/hawkular/hawkular-client-ruby
  * Python: https://github.com/hawkular/hawkular-client-python
  * Go: https://github.com/hawkular/hawkular-client-go
  * Java: https://github.com/hawkular/hawkular-client-java


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



Thank you,
Stefan Negrea

Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160504/a3eba283/attachment-0001.html 

From hrupp at redhat.com  Wed May  4 10:05:00 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 04 May 2016 16:05:00 +0200
Subject: [Hawkular-dev] Composition of the community distribution / Naming
Message-ID: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>

Now that the votes has been cast, it is clear that there is a desire to 
still have
a community distribution.

Looking at the comments also make it clear that the scope needs to 
refined.
Especially in the light that it was not communicated well enough before 
that e.g.
the app-server tab in the UI will go away.
Discussion areas can be found below.

Another question is the naming.
In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
we referenced 3 'distributions'
1) Hawkular community release
which includes
2) Hawkular core services
which includes
3) Hawkular-metrics

I propose to to rename 1) and 2) going forward to

1new) Hawkular-aio distribution
2new) Hawkular



Technical areas for discussion in the community-release (Hawkular-aio) 
are:

* Url handling / pinger / avail-creator

Probably not needed going forward

* UI/ Alert Center

Needed in a generic way - i.e. allow to see fired alerts/events and to 
define
generic triggers. For the display it will be enough to iterate over the 
Event/Alert
object returned from the REST-api and to display the key/value pairs.

* UI/ Explorer

This needs to stay and we need to fix some smaller bugs to allow
for inventory browsing and display of metric charts

* Accounts / Multi-tenancy

I still see this as a great value and unique selling point, but also see 
the effort
of maintaining this (and the issues we have with KC and hostnames).
It may be good to also remove this


* Embedded Cassandra

I think this needs to be present in the community-distribution

* UI/Agent installer

Not sure if this is still needed or if we would just put the 
agent+installer
into a directory of the zip for the users to take the installer from 
there.

* Default user

The Hawkular-aio download should feature a default user jdoe/password
which is also set in the embedded agent.

From hrupp at redhat.com  Wed May  4 10:10:00 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 04 May 2016 16:10:00 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
Message-ID: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>

Hi,

we do have a larger number of repositories and source trees.
Now that we have narrowed down the scope of our work a bit and also
have an idea of what we need for the "core services" package, I wonder
if we can collapse repositories and source trees into larger ones.

As an example: alerts and metrics could go together into
hawkular-metrics and the forwarding of data to alerts could be
done with Java method invocation.

What else could be done here?


From jsanda at redhat.com  Wed May  4 10:33:26 2016
From: jsanda at redhat.com (John Sanda)
Date: Wed, 4 May 2016 10:33:26 -0400
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
Message-ID: <F8FC0F8D-167B-4D2A-9F1B-3AF2164E531E@redhat.com>


> On May 4, 2016, at 10:10 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Hi,
> 
> we do have a larger number of repositories and source trees.
> Now that we have narrowed down the scope of our work a bit and also
> have an idea of what we need for the "core services" package, I wonder
> if we can collapse repositories and source trees into larger ones.
> 
> As an example: alerts and metrics could go together into
> hawkular-metrics and the forwarding of data to alerts could be
> done with Java method invocation.
> 

I have had some one-off conversations about combining alerts and metrics but nothing formal and/or on the mailing list. That is a broader discussion beyond simply combining repos.

From ploffay at redhat.com  Wed May  4 10:41:37 2016
From: ploffay at redhat.com (Pavol Loffay)
Date: Wed, 4 May 2016 16:41:37 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <F8FC0F8D-167B-4D2A-9F1B-3AF2164E531E@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
	<F8FC0F8D-167B-4D2A-9F1B-3AF2164E531E@redhat.com>
Message-ID: <CAKLecW86siO2R1sS8CyfMzoV4agk61=QCiJXNTV_cQ+BDr3xuw@mail.gmail.com>

On Wed, May 4, 2016 at 4:33 PM, John Sanda <jsanda at redhat.com> wrote:

>
> > On May 4, 2016, at 10:10 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> >
> > Hi,
> >
> > we do have a larger number of repositories and source trees.
> > Now that we have narrowed down the scope of our work a bit and also
> > have an idea of what we need for the "core services" package, I wonder
> > if we can collapse repositories and source trees into larger ones.
> >
> > As an example: alerts and metrics could go together into
> > hawkular-metrics and the forwarding of data to alerts could be
> > done with Java method invocation.
> >
>

Data Mining also listen on the bus.


> I have had some one-off conversations about combining alerts and metrics
> but nothing formal and/or on the mailing list. That is a broader discussion
> beyond simply combining repos.
> _______________________________________________
> 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/20160504/d0474d94/attachment.html 

From hrupp at redhat.com  Wed May  4 10:56:56 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 04 May 2016 16:56:56 +0200
Subject: [Hawkular-dev] Doodle: Hawkular community release
In-Reply-To: <5CB5F7D5-BE29-47B8-A3BD-53CC89C52750@redhat.com>
References: <5CB5F7D5-BE29-47B8-A3BD-53CC89C52750@redhat.com>
Message-ID: <CB68E0F4-0C1A-4BF2-950B-A3B1BBA21A72@redhat.com>

On 2 May 2016, at 15:56, Heiko W.Rupp wrote:

> Please fill this in. Poll ends latest Wed 4th 10am EST.

Outcome is 11 yes, 0 no and 7 "if it has to be",
so we will continue with community "all in one" releases.

Please also see the thread "Composition of community distribution"

From miburman at redhat.com  Wed May  4 15:12:09 2016
From: miburman at redhat.com (Michael Burman)
Date: Wed, 4 May 2016 15:12:09 -0400 (EDT)
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
Message-ID: <990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>

Hi,

Why? More repositories is good. If something can be split to new repositories, it should be done (like the rxjava-cassandra-stuff from metrics). What could be advantage of pushing alerts stuff to the metrics-repository?

  - Micke

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Wednesday, May 4, 2016 5:10:00 PM
Subject: [Hawkular-dev] Collapsing of Repos ?

Hi,

we do have a larger number of repositories and source trees.
Now that we have narrowed down the scope of our work a bit and also
have an idea of what we need for the "core services" package, I wonder
if we can collapse repositories and source trees into larger ones.

As an example: alerts and metrics could go together into
hawkular-metrics and the forwarding of data to alerts could be
done with Java method invocation.

What else could be done here?

_______________________________________________
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  4 15:46:28 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 04 May 2016 21:46:28 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
	<990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>
Message-ID: <2897261A-578F-4C4A-8E64-81F34527A07C@redhat.com>

On 4 May 2016, at 21:12, Michael Burman wrote:

> it should be done (like the rxjava-cassandra-stuff from metrics). What 
> could be advantage of pushing alerts stuff to the metrics-repository?

Having one repo certainly makes the release process and interdependency
changes easier. With the many repos we have, we have a pretty 
complicated
setup to get a final release out with many operations that need to 
happen
in special ordering.

From jshaughn at redhat.com  Wed May  4 16:00:04 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 4 May 2016 16:00:04 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
Message-ID: <572A54C4.9010804@redhat.com>

Congrats!

On 5/4/2016 10:03 AM, Stefan Negrea wrote:
>
> 1.
>
>     *Schema Management Tools*
>
>       * First release with tooling for schema change management
>       * Only upgrades are supported; incremental schema changes are
>         installed when Hawkular Metrics starts
>       * Going forward new versions of Hawkular Metrics can be
>         installed without the need to start with a fresh database or
>         manually update existing database even if the schema has been
>         modified in the new version
>       * For more details: HWKMETRICS-361
>         <https://issues.jboss.org/browse/HWKMETRICS-361>, Cassalog
>         <https://github.com/jsanda/cassalog>
>

Are these tools useful for other components using the same cassandra 
instance for their own schemas?  For example, can Hawkular Alerting 
leverage this to perform updates to its schema?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160504/c1bf8556/attachment.html 

From lkrejci at redhat.com  Wed May  4 16:03:29 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Wed, 04 May 2016 22:03:29 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
	<990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>
Message-ID: <2461062.dBkZZ3hhu2@localhost.localdomain>

On Wednesday, May 04, 2016 03:12:09 PM Michael Burman wrote:
> Hi,
> 
> Why? More repositories is good. If something can be split to new
> repositories, it should be done (like the rxjava-cassandra-stuff from
> metrics). 

Twitter, Google, Facebook and others may disagree with you with their 
"monorepo" approach to development (a term I learned today :) ).

I'm not sure how they manage to a) have everything in 1 repo and b) have 
independently versioned artifacts without it being exactly the same pain as it 
is with multiple repos, but there must be something to it (like 
http://danluu.com/monorepo/ or http://www.pantsbuild.org/why_use_pants.html).

I'm a fan of granularity btw and I don't think we'd see much benefit in 
merging the repos unless we release all the components at the same time (which 
I don't think is a good idea).

> What could be advantage of pushing alerts stuff to the
> metrics-repository?
>

I don't see much of a benefit there either...
 
>   - Micke
> 
> ----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 4, 2016 5:10:00 PM
> Subject: [Hawkular-dev] Collapsing of Repos ?
> 
> Hi,
> 
> we do have a larger number of repositories and source trees.
> Now that we have narrowed down the scope of our work a bit and also
> have an idea of what we need for the "core services" package, I wonder
> if we can collapse repositories and source trees into larger ones.
> 
> As an example: alerts and metrics could go together into
> hawkular-metrics and the forwarding of data to alerts could be
> done with Java method invocation.
> 
> What else could be done 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

-- 
Lukas Krejci

From jkremser at redhat.com  Thu May  5 04:52:48 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Thu, 5 May 2016 10:52:48 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
Message-ID: <CAE7VWz-yteSNv_iS2tPipKSZHuBq54X9YM9ic9GiXR8muT3-Og@mail.gmail.com>

Hi,
  I don't like the idea either. In a way, it's similar to "git push -f". If
you move the repo, there is no way how anyone can find out the new location.

I vote for some big note in the readme, that it's abandoned (if it was
really abandoned) for reason X and it's better to use repo Y because of Z.

"What if we realize we need to "unarchive" some project? I don't see that
happening but that would create even more confusion."

It's unlikely, but it actually happened with
https://github.com/hawkular/hawkular-ui-components

jk

On Fri, Apr 29, 2016 at 3:58 PM, Stefan Negrea <snegrea at redhat.com> wrote:

> Hello,
>
> I would like to propose a new organization in Github to host projects that
> no longer receive development. "Hawkular-Archive" seems a good name for
> this purpose. The goal is to keep the main Hawkular org focused on
> important projects and at the same time preserve work that was already done
> but away from the main organization.
>
> From a quick look at the current organization here are two repositories
> that can be moved right away: hawkular-metrics-openshift  (Openshit 2.x
> cartridge for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus (code
> moved to another repo). Am I am sure we can find other repositories to
> move.
>
> In the long run we can develop some criteria for archiving projects but
> for now we can just do a one-time major cleanup.
>
> Any repositories that should be archived right away? Any other suggestions
> for a name? Any thoughts on the idea in general?
>
>
> Thank you,
> Stefan Negrea
>
> Software Engineer
>
> _______________________________________________
> 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/20160505/40f7ec83/attachment.html 

From ppalaga at redhat.com  Thu May  5 07:33:31 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 5 May 2016 13:33:31 +0200
Subject: [Hawkular-dev] Hawkular-Archive - New Org
In-Reply-To: <CADt-fV81hYPaH62_oTp49arq1VNwEA28f2E=J_=PxoFH9DH=WQ@mail.gmail.com>
References: <CADt-fV82Fh2Kq6upHEuOFTbwM+70e3WPviTFsUitWgvtBz2kCg@mail.gmail.com>
	<57270A1F.2020304@redhat.com>
	<CADt-fV81hYPaH62_oTp49arq1VNwEA28f2E=J_=PxoFH9DH=WQ@mail.gmail.com>
Message-ID: <572B2F8B.6000808@redhat.com>

Hi Stefan, inline...

On 2016-05-02 18:00, Stefan Negrea wrote:
> Hello Peter,
>
> The type of problem that you raised is the exact reason why I proposed
> another org. Why would you have a source dep on something that is no
> longer maintained?

srcdeps on those now abandoned repos are there in the histories of our 
components. It is the sustaining engineer speaking out of me, that it 
should be possible to re-build any old commit of any git repo. It may 
turn out to be necessary to build old commits in the future for whatever 
reason (e.g. when using git bisect to find the commit that introduced 
some bug). By changing the git repo URL, we break the builds of those 
old commits. It is like removing artifacts from Maven Central.

Abandoned repos should be marked as such and that's all we should do.

Thanks,

-- P

> That is really bad for the active project because the
> raw unmaintained repository is included in something active. What if
> there are issues with building the unmaintained code? Who will fix it?
> Nobody should touch the archived repository!
>
>
> The proper course of action for the scenario you described is to have
> the active project drop the dependency on the archived project. And the
> archived project should have had a release prior to being archived. The
> active project should have depended on the officially released version
> of the archived project and drop it as soon as possible.
>
>
> If we set aside srcdep scenario, do you have any other objections to a
> new org for archived repositories?
>
>
> Thank you,
> Stefan Negrea
>
> Software Engineer
>
> On Mon, May 2, 2016 at 3:04 AM, Peter Palaga <ppalaga at redhat.com
> <mailto:ppalaga at redhat.com>> wrote:
>
>     Hi Stefan,
>
>     I vote against the idea of archiving through moving to another GitHub
>     organization. This will break srcdeps builds, because the git repository
>     URL is one of the things the srcdep mech assumes to be stable.
>
>     Thanks,
>
>     Peter
>
>     On 2016-04-29 15:58, Stefan Negrea wrote:
>      > Hello,
>      >
>      > I would like to propose a new organization in Github to host projects
>      > that no longer receive development. "Hawkular-Archive" seems a
>     good name
>      > for this purpose. The goal is to keep the main Hawkular org
>     focused on
>      > important projects and at the same time preserve work that was
>     already
>      > done but away from the main organization.
>      >
>      >  From a quick look at the current organization here are two
>     repositories
>      > that can be moved right away: hawkular-metrics-openshift
>     (Openshit 2.x
>      > cartridge for Hawkular Metrics 0.2.7 or earlier) and hawkular-bus
>     (code
>      > moved to another repo). Am I am sure we can find other
>     repositories to
>      > move.
>      >
>      > In the long run we can develop some criteria for archiving
>     projects but
>      > for now we can just do a one-time major cleanup.
>      >
>      > Any repositories that should be archived right away? Any other
>      > suggestions for a name? Any thoughts on the idea in general?
>      >
>      >
>      > 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
>      >
>
>     _______________________________________________
>     hawkular-dev mailing list
>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From ppalaga at redhat.com  Thu May  5 07:56:21 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 5 May 2016 13:56:21 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2461062.dBkZZ3hhu2@localhost.localdomain>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
	<990538610.86291411.1462389129331.JavaMail.zimbra@redhat.com>
	<2461062.dBkZZ3hhu2@localhost.localdomain>
Message-ID: <572B34E5.9010700@redhat.com>

Yes, the overhead with releasing and synchronization of changes grows 
substantially with the number of component git repos.

Splitting strictly by business domains leads to many small git 
repositories: going that way, e.g. the nowadays commons would have to be 
split to as many as 7 component repositories: Nest, Bus, Embedded 
Cassandra, Email, Inventory Paths, Rest Status and Templates.

Clearly, we want neither this extreme, nor one (or too few) huge repos.

To find a good balance, there are several aspects to consider. Here are 
my favorite ones:

(1) The intensity of development. This can be measured by e.g. the 
number of developers working concurrently in the given git repo, the 
number of new PRs daily, etc.

(2) The usual time from sending a new PR to its merge. This consists of 
the time the CI needs to run all tests and the time needed for review.

Clearly, the bigger a git repo the more engineers will work on it and 
the more PRs will be sent daily.
And also, the bigger repo, the more tests and the longer CI run times, 
and the longer PR queue and the higher probability of conflicting PRs.

I do not know what is the max acceptable CI run time for other team 
members, my subjective value is 25mins. Furtermore, in the world I wish 
to live in, PRs are merged within 8 business hours. If we are under 
these numbers somewhere, we have potential to merge repos.

For the specific case of Alerts and Metrics:

While adding the ~4 Metrics devs to 2 Alerts devs seems to be OK, the 
summed CI times do not look acceptable to me.

Alerts CI time: Travis 34 mins
Metrics CI time: Travis 12min, Jenkins 30min (running in parallel)

By merging the two repos, probably only the Travis times would have to 
be summed together: ~40min

(3) The most devs assigned to the repo should be able to fix problems in 
all its parts. In other words, if my change in Metrics breaks Alerts 
(assuming they live in the same repo), am I able to fix Alerts? I would 
not want to wait for Jay or Lucas to fix my PR before it can be merged.

Thanks,

Peter


On 2016-05-04 22:03, Lukas Krejci wrote:
> On Wednesday, May 04, 2016 03:12:09 PM Michael Burman wrote:
>> Hi,
>>
>> Why? More repositories is good. If something can be split to new
>> repositories, it should be done (like the rxjava-cassandra-stuff from
>> metrics).
>
> Twitter, Google, Facebook and others may disagree with you with their
> "monorepo" approach to development (a term I learned today :) ).
>
> I'm not sure how they manage to a) have everything in 1 repo and b) have
> independently versioned artifacts without it being exactly the same pain as it
> is with multiple repos, but there must be something to it (like
> http://danluu.com/monorepo/ or http://www.pantsbuild.org/why_use_pants.html).
>
> I'm a fan of granularity btw and I don't think we'd see much benefit in
> merging the repos unless we release all the components at the same time (which
> I don't think is a good idea).
>
>> What could be advantage of pushing alerts stuff to the
>> metrics-repository?
>>
>
> I don't see much of a benefit there either...
>
>>    - Micke
>>
>> ----- Original Message -----
>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Wednesday, May 4, 2016 5:10:00 PM
>> Subject: [Hawkular-dev] Collapsing of Repos ?
>>
>> Hi,
>>
>> we do have a larger number of repositories and source trees.
>> Now that we have narrowed down the scope of our work a bit and also
>> have an idea of what we need for the "core services" package, I wonder
>> if we can collapse repositories and source trees into larger ones.
>>
>> As an example: alerts and metrics could go together into
>> hawkular-metrics and the forwarding of data to alerts could be
>> done with Java method invocation.
>>
>> What else could be done 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
>


From lponce at redhat.com  Thu May  5 08:50:26 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 5 May 2016 08:50:26 -0400 (EDT)
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
Message-ID: <2037104517.1441748.1462452626565.JavaMail.zimbra@redhat.com>

Personally I don't see the benefit of collapsing repos.

Also, I'm not sure if "collapsing" here means also "merging" in the sense that we move 2 or more components into 1, with only 1 new release of the joined component in the future.

I'm +1 to maintain repos by domain, perhaps joining helper repos in commons.

But I see more problematic if we join big repos like metrics, alerts or inventory into one. It is clear that they have their own lifecycle and merging can bring more issues than benefits.

Having said that, I don't see that having separate repo is a problem to make them work together.

For example, from my point of view, a join combination of alerts+metrics is just a packaging option which can be independent of if it is built from one repo or two.

Just my 2 cents.


----- Mensaje original -----
> De: "Heiko W.Rupp" <hrupp at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Mi?rcoles, 4 de Mayo 2016 16:10:00
> Asunto: [Hawkular-dev] Collapsing of Repos ?
> 
> Hi,
> 
> we do have a larger number of repositories and source trees.
> Now that we have narrowed down the scope of our work a bit and also
> have an idea of what we need for the "core services" package, I wonder
> if we can collapse repositories and source trees into larger ones.
> 
> As an example: alerts and metrics could go together into
> hawkular-metrics and the forwarding of data to alerts could be
> done with Java method invocation.
> 
> What else could be done here?
> 
> _______________________________________________
> 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  5 17:32:35 2016
From: mithomps at redhat.com (mike thompson)
Date: Thu, 5 May 2016 14:32:35 -0700
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
Message-ID: <2A4914AD-36FF-47DC-B6CF-4B76D35B2205@redhat.com>

Congrats to all involved! This looks like a major release!


> On 4 May 2016, at 07:03, Stefan Negrea <snegrea at redhat.com> wrote:
> 
> Hello Everybody,
> 
> 
> I am happy to announce release 0.15.0 of Hawkular Metrics. This is one of the largest ever Hawkular Metrics releases with a lot of new features and changes.
> 
> 
> 
> Here is a list of major changes:
> 
> Cassandra 3.5
> 
> Cassandra 3.5 is now the supported version of Cassandra
> Cassandra 2.2.x support is deprecated
> Schema Management Tools
> 
> First release with tooling for schema change management
> Only upgrades are supported; incremental schema changes are installed when Hawkular Metrics starts
> Going forward new versions of Hawkular Metrics can be installed without the need to start with a fresh database or manually update existing database even if the schema has been modified in the new version
> For more details: HWKMETRICS-361 <https://issues.jboss.org/browse/HWKMETRICS-361>, Cassalog <https://github.com/jsanda/cassalog>
> */stats & */raw Replace */data
> 
> */data has been *deprecated and functionality split into two single purpose endpoints, this is applicable for all metric types (gauge, counter, availability, and string)
> */stats endpoints return bucketed, statistical or query-time aggregated data
> */raw endpoints accept and return raw data for a metric
> */data is being deprecated, will not receive any updates going forward, and will be removed in future releases. There is no clear timeline for the removal since a lot of clients use it; it will be around at least for another two releases.
> Please update your code to use the new endpoints and follow the release notes for more details regarding removal.
> For more details: HWKMETRICS-24 <https://issues.jboss.org/browse/HWKMETRICS-24>, HWKMETRICS-57 <https://issues.jboss.org/browse/HWKMETRICS-57>
> Data Point Tags
> 
> An optional set of tags can be supplied with each data point when inserting data. Unlike metric definition tags, data point tags cannot be modified. HWKMETRICS-368 <https://issues.jboss.org/browse/HWKMETRICS-368>, HWKMETRICS-54 <https://issues.jboss.org/browse/HWKMETRICS-54>
> Tag based bucketing for data points is supported for counters and gauges HWKMETRICS-377 <https://issues.jboss.org/browse/HWKMETRICS-377>, HWKMETRICS-373 <https://issues.jboss.org/browse/HWKMETRICS-373>
> New endpoints for filtering and grouping data by tags:
> GET /hawkular/metrics/gauges/{id}/stats/tags/{tags}
> GET /hawkular/metrics/counters/{id}/stats/tags/{tags}
> Tags
> 
> Deleting tags only requires the tag keys and not the values, this simplifies the process for tag deletion. For backwards compatibility, the API will still accept name value pairs but will not take the value into account HWKMETRICS-385 <https://issues.jboss.org/browse/HWKMETRICS-385>
> A new endpoint was added to query for the available values contained in a tag HWKMETRICS-197 <https://issues.jboss.org/browse/HWKMETRICS-197>
> Endpoint: GET hawkular/metrics/gauge/tags/{tags}
> Example: GET hawkular/metrics/gauge/tags/hostname:*01* returns hostname: ["web01prod", "web01qa", "backend01prod", "backend01qa" ]
> String Metric Type (Experimental)
> 
> Hawkular Metrics now provides a string metric type. This release introduces new endpoints for reading and writing string data points HWKMETRICS-384 <https://issues.jboss.org/browse/HWKMETRICS-384>
> There is a 2 KB size limit for each data point. That limit may be configurable in future releases.
> New endpoints under /strings are experimental, so changes which break backwards compatibility could be introduced in future releases. The experimental tag allows time for feedback to better determine what the API should be.
> Asynchronous authentication for Openshift Metrics
> 
> Important performance improvement: the authentication code now uses a non blocking HTTP Client (Undertow Client) to validate authentication tokens calling Kubernetes' master
> Performance improvements details: #481 (comment) <https://github.com/hawkular/hawkular-metrics/pull/481#issue-148320027>, #481 (comment) <https://github.com/hawkular/hawkular-metrics/pull/481#issuecomment-209876952>
> For more details: HWKMETRICS-330 <https://issues.jboss.org/browse/HWKMETRICS-330>
> API Updates
> 
> Stats are excluded from empty bucket data points rather than returning the string NaN and zero for the samples property HWKMETRICS-396 <https://issues.jboss.org/browse/HWKMETRICS-396>
> Endpoints that use the order param also accept lower case values HWKMETRICS-389 <https://issues.jboss.org/browse/HWKMETRICS-389>
> Sum is included in bucket output for gauges and counters HWKMETRICS-370 <https://issues.jboss.org/browse/HWKMETRICS-370>
> The status page can now be loaded over HTTPS without errors HWKMETRICS-388 <https://issues.jboss.org/browse/HWKMETRICS-388>
> Added overwrite param to tenant and metric creation. This will only overwrite the configuration (such as retention settings or tags) of the metric or tenant and not the actual data stored. Also overwrite the retention will only affect new data points added and not existing data already stored HWKMETRICS-148 <https://issues.jboss.org/browse/HWKMETRICS-148>
> 
> 
> Updated Documentation
> 
> The entire Hawkular Metrics User Guide <http://www.hawkular.org/docs/components/metrics/index.html> has been rewritten and it is now accessible from the top menu of Hawkular.org <https://hawkular.org/>. The new guide has extensive documentation about metric types, query and tagging capabilities along lots of examples. Thank you @jsanda <https://github.com/jsanda> for this amazing update!
> 
> 
> 
> Java Client (Experimental)
> 
> Thanks to an effort started by the Hawkular QE <https://github.com/hawkular-qe> organization, Hawkular Metrics now has an official Java client <https://github.com/hawkular/hawkular-client-java>. The repository has been fully transferred to Hawkular community where will be maintained going forward. The client is now at an experimental alpha stage and we expect to polish the API and internals in the coming months.
> 
> A big thank you goes to @jkandasa <https://github.com/jkandasa> and @vnugent <https://github.com/vnugent> for creating and the maintaining the project until now. @jkandasa <https://github.com/jkandasa> will continue to serve as an active contributor and core member.
> 
> 
> 
> Blog Posts & Articles
> 
> Here are some recently published Metrics related blog posts and articles from around the Hawkular community:
> 
> Monitoring JVM applications with jmxtrans <http://www.hawkular.org/blog/2016/04/19/jmxtrans-to-hawkular-metrics.html> by @tsegismont <https://github.com/tsegismont>
> 
> Collecting Metrics from Prometheus Endpoints <http://www.hawkular.org/blog/2016/04/22/collecting-metrics-from-prometheus-endpoints.html> by @jmazzitelli <https://github.com/jmazzitelli>
> 
> Hawkular Data Mining 0.1.0.Final Released <http://www.hawkular.org/blog/2016/04/21/datamining-first-release.html> by @pavolloffay <https://github.com/pavolloffay> 
> 
> 
> 
> Github Release:
> https://github.com/hawkular/hawkular-metrics/releases/tag/0.15.0 <https://github.com/hawkular/hawkular-metrics/releases/tag/0.15.0>
> 
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/ <http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/>
> 
> Jira release tracker:
> https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12329846 <https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12329846>
> 
> 
> Hawkular Metrics Clients
>   * Ruby: https://github.com/hawkular/hawkular-client-ruby <https://github.com/hawkular/hawkular-client-ruby>
>   * Python: https://github.com/hawkular/hawkular-client-python <https://github.com/hawkular/hawkular-client-python>
>   * Go: https://github.com/hawkular/hawkular-client-go <https://github.com/hawkular/hawkular-client-go>
>   * Java: https://github.com/hawkular/hawkular-client-java <https://github.com/hawkular/hawkular-client-java>
> 
> 
> A big "Thank you" goes to John Sanda, Thomas Segismont, Matt Wringe, Mike Thompson, Michael Burman, and Heiko Rupp for their project contributions.
> 
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer

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

From mazz at redhat.com  Fri May  6 06:30:01 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 May 2016 06:30:01 -0400 (EDT)
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
Message-ID: <775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>

Now that Accounts is getting taken out, how is the agent to determine its tenant ID?

The agent needs to know its tenant ID when inserting data into Hawkular Metrics.

Right now, the agent makes an explicit http call to the Accounts URL to obtain the tenant of its user. If Accounts goes away, the only thing left that I can see is to make required the agent attribute "tenantId" in standalone.xml configuraiton of the agent subsystem.

Is that correct? There is no other way to get the tenant ID of a user now, I guess.

(for what its worth, tenant IDs are important in the Open Shift use-case)

From jpkroehling at redhat.com  Fri May  6 07:09:28 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Fri, 6 May 2016 13:09:28 +0200
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
References: <775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
Message-ID: <898361d5-2ea9-b608-01df-420148cdada3@redhat.com>

On 06.05.2016 12:30, John Mazzitelli wrote:
> ... is to make required the agent attribute "tenantId" in standalone.xml configuraiton of the agent subsystem.
>
> Is that correct? There is no other way to get the tenant ID of a user now, I guess.

Yes, that's also my understanding. Multi tenancy is to be managed 
outside of Hawkular, by the consuming "platform" (MiQ or OpenShift).

- Juca.

From jkremser at redhat.com  Fri May  6 07:55:49 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Fri, 6 May 2016 13:55:49 +0200
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
Message-ID: <CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>

Can't you just consider the tenantId the same as the feedId? Or use some
fixed word, like 'global'? Please don't use the slashes, equal symbols and
others :)

As for the inventory, currently the tenant is auto-created with the very
first call to the rest api. There is no dedicated endpoint to create the
tenant. The tenant id is obtained from the accounts component. Probably,
this will be changed to get the tenant id from the http header. So all you
need to do is to start inserting the data with the correctly set tenant id
header.

jk

On Fri, May 6, 2016 at 12:30 PM, John Mazzitelli <mazz at redhat.com> wrote:

> Now that Accounts is getting taken out, how is the agent to determine its
> tenant ID?
>
> The agent needs to know its tenant ID when inserting data into Hawkular
> Metrics.
>
> Right now, the agent makes an explicit http call to the Accounts URL to
> obtain the tenant of its user. If Accounts goes away, the only thing left
> that I can see is to make required the agent attribute "tenantId" in
> standalone.xml configuraiton of the agent subsystem.
>
> Is that correct? There is no other way to get the tenant ID of a user now,
> I guess.
>
> (for what its worth, tenant IDs are important in the Open Shift use-case)
> _______________________________________________
> 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/20160506/63144274/attachment.html 

From mazz at redhat.com  Fri May  6 08:21:54 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 May 2016 08:21:54 -0400 (EDT)
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
Message-ID: <1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>

> Can't you just consider the tenantId the same as the feedId? Or use some
> fixed word, like 'global'? Please don't use the slashes, equal symbols and
> others :)

That's what I was thinking of doing to avoid requiring people to set the tenantId. They can still set tenantId if they want something different, but, I think I will default to the feed ID.

> As for the inventory, currently the tenant is auto-created with the very
> first call to the rest api. There is no dedicated endpoint to create the
> tenant. The tenant id is obtained from the accounts component. Probably,
> this will be changed to get the tenant id from the http header. So all you
> need to do is to start inserting the data with the correctly set tenant id
> header.

Right. I would have to add that. Right now the agent only sends tenant ID header to metrics. Looks like I will need to send it to inventory as well.

I wonder if we need to start passing tenant ID around in the websocket commands too?

Peter/Juca - with all the work you are doing in cmdgw stuff - do you know if we need to add tenant ID to all the commands?

From jshaughn at redhat.com  Fri May  6 09:07:01 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 6 May 2016 09:07:01 -0400
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2037104517.1441748.1462452626565.JavaMail.zimbra@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
	<2037104517.1441748.1462452626565.JavaMail.zimbra@redhat.com>
Message-ID: <572C96F5.9050103@redhat.com>


I agree with Lucas, I'd rather see us package alerts+metrics together if 
that makes sense, but maintain separate repos/releases.  Note that H 
Alerting development/release is now on an on-demand need for a fix or 
enhancement that directly supports an external need, and the ability to 
release quickly is useful.  Overall, I don't see enough reward for a 
repo restructuring investment.

On 5/5/2016 8:50 AM, Lucas Ponce wrote:
> Personally I don't see the benefit of collapsing repos.
>
> Also, I'm not sure if "collapsing" here means also "merging" in the sense that we move 2 or more components into 1, with only 1 new release of the joined component in the future.
>
> I'm +1 to maintain repos by domain, perhaps joining helper repos in commons.
>
> But I see more problematic if we join big repos like metrics, alerts or inventory into one. It is clear that they have their own lifecycle and merging can bring more issues than benefits.
>
> Having said that, I don't see that having separate repo is a problem to make them work together.
>
> For example, from my point of view, a join combination of alerts+metrics is just a packaging option which can be independent of if it is built from one repo or two.
>
> Just my 2 cents.
>
>
> ----- Mensaje original -----
>> De: "Heiko W.Rupp" <hrupp at redhat.com>
>> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Enviados: Mi?rcoles, 4 de Mayo 2016 16:10:00
>> Asunto: [Hawkular-dev] Collapsing of Repos ?
>>
>> Hi,
>>
>> we do have a larger number of repositories and source trees.
>> Now that we have narrowed down the scope of our work a bit and also
>> have an idea of what we need for the "core services" package, I wonder
>> if we can collapse repositories and source trees into larger ones.
>>
>> As an example: alerts and metrics could go together into
>> hawkular-metrics and the forwarding of data to alerts could be
>> done with Java method invocation.
>>
>> What else could be done 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

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

From jshaughn at redhat.com  Fri May  6 09:08:52 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 6 May 2016 09:08:52 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <572A54C4.9010804@redhat.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
	<572A54C4.9010804@redhat.com>
Message-ID: <572C9764.1020203@redhat.com>


Stefan, in case it was missed, see the question I had asked below...

On 5/4/2016 4:00 PM, Jay Shaughnessy wrote:
> Congrats!
>
> On 5/4/2016 10:03 AM, Stefan Negrea wrote:
>>
>> 1.
>>
>>     *Schema Management Tools*
>>
>>       * First release with tooling for schema change management
>>       * Only upgrades are supported; incremental schema changes are
>>         installed when Hawkular Metrics starts
>>       * Going forward new versions of Hawkular Metrics can be
>>         installed without the need to start with a fresh database or
>>         manually update existing database even if the schema has been
>>         modified in the new version
>>       * For more details: HWKMETRICS-361
>>         <https://issues.jboss.org/browse/HWKMETRICS-361>, Cassalog
>>         <https://github.com/jsanda/cassalog>
>>
>
> Are these tools useful for other components using the same cassandra 
> instance for their own schemas?  For example, can Hawkular Alerting 
> leverage this to perform updates to its schema?


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

From jsanda at redhat.com  Fri May  6 09:21:52 2016
From: jsanda at redhat.com (John Sanda)
Date: Fri, 6 May 2016 09:21:52 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <572A54C4.9010804@redhat.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
	<572A54C4.9010804@redhat.com>
Message-ID: <7B84C854-E348-4427-977C-E5EB37C6A128@redhat.com>


> On May 4, 2016, at 4:00 PM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
> 
> Congrats!
> 
> On 5/4/2016 10:03 AM, Stefan Negrea wrote:
>> 
>> Schema Management Tools
>> 
>> First release with tooling for schema change management
>> Only upgrades are supported; incremental schema changes are installed when Hawkular Metrics starts
>> Going forward new versions of Hawkular Metrics can be installed without the need to start with a fresh database or manually update existing database even if the schema has been modified in the new version
>> For more details: HWKMETRICS-361 <https://issues.jboss.org/browse/HWKMETRICS-361>, Cassalog <https://github.com/jsanda/cassalog>
> Are these tools useful for other components using the same cassandra instance for their own schemas?  For example, can Hawkular Alerting leverage this to perform updates to its schema?

Yes, Cassalog can be used in other projects. It is not dependent on Hawkular Metrics in any way. There are things that we discussed and decided in HWKMETRICS-361 in terms of how to manage schema changes across versions. It boils down more to coming up with a process as opposed to a bunch of code changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160506/dd1aefba/attachment-0001.html 

From jshaughn at redhat.com  Fri May  6 09:21:59 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 6 May 2016 09:21:59 -0400
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
Message-ID: <572C9A77.7070302@redhat.com>


I always thought tenants were more akin to grouping associated data, 
like everything for datacenter-1, or company-x, and so users would have 
their queries limited to their relevant data.  If every feed has a 
different tenantid by default, then wouldn't it be difficult to 
consolidate data in a view?  I know in H Alerting that tenantId is used 
more in the fashion I discussed, and multi-tenant queries are not 
efficient.  It seems to me we'd be better off using a single default, 
like "global-tenant".

On 5/6/2016 8:21 AM, John Mazzitelli wrote:
>> Can't you just consider the tenantId the same as the feedId? Or use some
>> fixed word, like 'global'? Please don't use the slashes, equal symbols and
>> others :)
> That's what I was thinking of doing to avoid requiring people to set the tenantId. They can still set tenantId if they want something different, but, I think I will default to the feed ID.
>
>> As for the inventory, currently the tenant is auto-created with the very
>> first call to the rest api. There is no dedicated endpoint to create the
>> tenant. The tenant id is obtained from the accounts component. Probably,
>> this will be changed to get the tenant id from the http header. So all you
>> need to do is to start inserting the data with the correctly set tenant id
>> header.
> Right. I would have to add that. Right now the agent only sends tenant ID header to metrics. Looks like I will need to send it to inventory as well.
>
> I wonder if we need to start passing tenant ID around in the websocket commands too?
>
> Peter/Juca - with all the work you are doing in cmdgw stuff - do you know if we need to add tenant ID to all the commands?
> _______________________________________________
> 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/20160506/5c4873ae/attachment.html 

From mwringe at redhat.com  Fri May  6 10:31:07 2016
From: mwringe at redhat.com (Matt Wringe)
Date: Fri, 6 May 2016 10:31:07 -0400 (EDT)
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <572C9A77.7070302@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
	<572C9A77.7070302@redhat.com>
Message-ID: <1816496776.1365086.1462545067425.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Friday, May 6, 2016 9:21:59 AM
> Subject: Re: [Hawkular-dev] accounts, tenants, the agent
> 
> 
> I always thought tenants were more akin to grouping associated data, like
> everything for datacenter-1, or company-x, and so users would have their
> queries limited to their relevant data. If every feed has a different
> tenantid by default, then wouldn't it be difficult to consolidate data in a
> view? I know in H Alerting that tenantId is used more in the fashion I
> discussed, and multi-tenant queries are not efficient. It seems to me we'd
> be better off using a single default, like "global-tenant".

I always view tenants as being more of a user concern. As a user I can rent one or more units in an apartment building and I control the keys to these apartments. I can only be in one apartment at a time, but I can leave and go to another apartment I own if I want. Other users can also rent one or more units in the building as well. There may be a landlord (admin) who also has a key to all units as well.

I think we need to keep one default tenant for everything (eg 'hawkular' or something generic) and not have a per feed tenant. You can't query or aggregate data across tenants in Hawkular Metrics, and I would assume most users would want to have one tenant by default rather than one tenant per feed. I assume that users will probably want to perform aggregates across a cluster of similar machines, which you can't do if each machine has a separate tenant id.

Tenants are also used for access control. In OpenShift they have projects (aka namespaces) which we use as the tenant id. A user in OpenShift needs to specify that project they are using when they perform any action, and access control is configured on a per project basis. For metrics, when someone tries to access one of the endpoints, we verify that they have access to the corresponding project in OpenShift before granting them access to the corresponding metrics in Hawkular Metrics.

> 
> On 5/6/2016 8:21 AM, John Mazzitelli wrote:
> 
> 
> 
> 
> 
> Can't you just consider the tenantId the same as the feedId? Or use some
> fixed word, like 'global'? Please don't use the slashes, equal symbols and
> others :)
> That's what I was thinking of doing to avoid requiring people to set the
> tenantId. They can still set tenantId if they want something different, but,
> I think I will default to the feed ID.
> 
> 
> 
> As for the inventory, currently the tenant is auto-created with the very
> first call to the rest api. There is no dedicated endpoint to create the
> tenant. The tenant id is obtained from the accounts component. Probably,
> this will be changed to get the tenant id from the http header. So all you
> need to do is to start inserting the data with the correctly set tenant id
> header.
> Right. I would have to add that. Right now the agent only sends tenant ID
> header to metrics. Looks like I will need to send it to inventory as well.
> 
> I wonder if we need to start passing tenant ID around in the websocket
> commands too?
> 
> Peter/Juca - with all the work you are doing in cmdgw stuff - do you know if
> we need to add tenant ID to all the commands?
> _______________________________________________
> hawkular-dev mailing list hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jsanda at redhat.com  Fri May  6 10:34:40 2016
From: jsanda at redhat.com (John Sanda)
Date: Fri, 6 May 2016 10:34:40 -0400
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <572C9A77.7070302@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
	<572C9A77.7070302@redhat.com>
Message-ID: <66227A5B-2F93-472F-9D54-BB00414963FB@redhat.com>

H-Metrics is in the same situation as H-Alerts. The tenant id is really only used to partition data; however, it is not the only thing used to partition data. H-Metrics currently does not have any APIs for querying across multiple tenants. There is no technical restriction or limitation that prevents us from doing so. More fine-grained tenants won?t make querying in H-Metrics any less efficient because we are querying across multiple partitions either way. We always do those queries in parallel. More fine-grained tenants would have some implications though on how we design background jobs like computing rollups.

> On May 6, 2016, at 9:21 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
> 
> 
> I always thought tenants were more akin to grouping associated data, like everything for datacenter-1, or company-x, and so users would have their queries limited to their relevant data.  If every feed has a different tenantid by default, then wouldn't it be difficult to consolidate data in a view?  I know in H Alerting that tenantId is used more in the fashion I discussed, and multi-tenant queries are not efficient.  It seems to me we'd be better off using a single default, like "global-tenant".
> 
> On 5/6/2016 8:21 AM, John Mazzitelli wrote:
>>> Can't you just consider the tenantId the same as the feedId? Or use some
>>> fixed word, like 'global'? Please don't use the slashes, equal symbols and
>>> others :)
>> That's what I was thinking of doing to avoid requiring people to set the tenantId. They can still set tenantId if they want something different, but, I think I will default to the feed ID.
>> 
>>> As for the inventory, currently the tenant is auto-created with the very
>>> first call to the rest api. There is no dedicated endpoint to create the
>>> tenant. The tenant id is obtained from the accounts component. Probably,
>>> this will be changed to get the tenant id from the http header. So all you
>>> need to do is to start inserting the data with the correctly set tenant id
>>> header.
>> Right. I would have to add that. Right now the agent only sends tenant ID header to metrics. Looks like I will need to send it to inventory as well.
>> 
>> I wonder if we need to start passing tenant ID around in the websocket commands too?
>> 
>> Peter/Juca - with all the work you are doing in cmdgw stuff - do you know if we need to add tenant ID to all the commands?
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

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

From mazz at redhat.com  Fri May  6 17:08:26 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 6 May 2016 17:08:26 -0400 (EDT)
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <572C9A77.7070302@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
	<572C9A77.7070302@redhat.com>
Message-ID: <1827147727.1933328.1462568906842.JavaMail.zimbra@redhat.com>

> It seems to me we'd be better off using a single default, like "global-tenant".

Good point. I think we should just ship with a global "hawkular" tenant ID pre-configured and just let the customer change it if he wants.

From lponce at redhat.com  Fri May  6 17:20:18 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 6 May 2016 17:20:18 -0400 (EDT)
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <1827147727.1933328.1462568906842.JavaMail.zimbra@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
	<572C9A77.7070302@redhat.com>
	<1827147727.1933328.1462568906842.JavaMail.zimbra@redhat.com>
Message-ID: <252340999.1934754.1462569618384.JavaMail.zimbra@redhat.com>

ManageIQ has the notion of "Zone" which is also used to group servers.

I.e.: Zone "Default" has 1 EVM Server, 2 Providers, etc.

Sometimes when I'm cathing up with ManageIQ code I wonder if our tenant concept in Hawkular maps with this Zone concept.

If it matches, also I wonder who is responsible to assign the tenant (the ownership of tenant belongs to the agent? to hawkular server ? ManageIQ ?), how/when (at agent installation? at hawkular installation? at ManageIQ provider registration ?).

It is still an open point but good to discuss about it to see possible and cascade implications (i.e. mixed tenants are possible ? In which scenarios ?)

----- Mensaje original -----
> De: "John Mazzitelli" <mazz at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Viernes, 6 de Mayo 2016 23:08:26
> Asunto: Re: [Hawkular-dev] accounts, tenants, the agent
> 
> > It seems to me we'd be better off using a single default, like
> > "global-tenant".
> 
> Good point. I think we should just ship with a global "hawkular" tenant ID
> pre-configured and just let the customer change it if he wants.
> _______________________________________________
> 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  9 04:58:05 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 09 May 2016 10:58:05 +0200
Subject: [Hawkular-dev] accounts, tenants, the agent
In-Reply-To: <1816496776.1365086.1462545067425.JavaMail.zimbra@redhat.com>
References: <1712851551.1749858.1462530394013.JavaMail.zimbra@redhat.com>
	<775414261.1750150.1462530601252.JavaMail.zimbra@redhat.com>
	<CAE7VWz-1hZzYoO3QwMd6mffJhoW0jkobBCPYsRsM4A3kvey4EQ@mail.gmail.com>
	<1301359407.1789963.1462537314274.JavaMail.zimbra@redhat.com>
	<572C9A77.7070302@redhat.com>
	<1816496776.1365086.1462545067425.JavaMail.zimbra@redhat.com>
Message-ID: <EDB8B165-9B46-4B4D-8A96-0A5096BE3B05@redhat.com>

On 6 May 2016, at 16:31, Matt Wringe wrote:

> I always view tenants as being more of a user concern. As a user I can 
> rent one or more units in an apartment building and I control the keys 
> to these apartments. I can only be in one apartment at a time, but I 
> can leave and go to another apartment I own if I want. Other users can 
> also rent one or more
> units in the building as well. There may be a landlord (admin) who 
> also has a key to all units as well.

This is a perfect analogy. Also the keys I have only allow me to go to
my apartments and prevent other users from entering in mine.

> I think we need to keep one default tenant for everything (eg 
> 'hawkular' or
Yes

> something generic) and not have a per feed tenant. You can't query or

Per feed is not the right granularity. A feed would be a single 
apartment or
even a room within the apartment, while the tenant applies to all 
apartments
I rented.


From hrupp at redhat.com  Mon May  9 05:55:08 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 09 May 2016 11:55:08 +0200
Subject: [Hawkular-dev] Collapsing of Repos ?
In-Reply-To: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
References: <2252670F-D07F-4E1A-B610-AB62C981D71D@redhat.com>
Message-ID: <33D03541-FFE1-4CEC-A6DD-60CCE9A577A8@redhat.com>

On 4 May 2016, at 16:10, Heiko W.Rupp wrote:

> have an idea of what we need for the "core services" package, I wonder
> if we can collapse repositories and source trees into larger ones.

I read the replies as "this is no good idea". So be it.

From hrupp at redhat.com  Mon May  9 06:35:28 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 09 May 2016 12:35:28 +0200
Subject: [Hawkular-dev] Fwd: Composition of the community distribution /
 Naming
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
Message-ID: <F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>

Ping
Silence means acceptance :-) (Especially for the naming)

> From: Heiko W.Rupp <hrupp at redhat.com>
> To: Discussions around Hawkular development <hawkular-dev at lists.jboss.org>
> Subject: [Hawkular-dev] Composition of the community distribution / Naming
> Date: Wed, 04 May 2016 16:05:00 +0200
>
> Now that the votes has been cast, it is clear that there is a desire to
> still have
> a community distribution.
>
> Looking at the comments also make it clear that the scope needs to
> refined.
> Especially in the light that it was not communicated well enough before
> that e.g.
> the app-server tab in the UI will go away.
> Discussion areas can be found below.
>
> Another question is the naming.
> In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
> we referenced 3 'distributions'
> 1) Hawkular community release
> which includes
> 2) Hawkular core services
> which includes
> 3) Hawkular-metrics
>
> I propose to to rename 1) and 2) going forward to
>
> 1new) Hawkular-aio distribution
> 2new) Hawkular
>
>
>
> Technical areas for discussion in the community-release (Hawkular-aio)
> are:
>
> * Url handling / pinger / avail-creator
>
> Probably not needed going forward
>
> * UI/ Alert Center
>
> Needed in a generic way - i.e. allow to see fired alerts/events and to
> define
> generic triggers. For the display it will be enough to iterate over the
> Event/Alert
> object returned from the REST-api and to display the key/value pairs.
>
> * UI/ Explorer
>
> This needs to stay and we need to fix some smaller bugs to allow
> for inventory browsing and display of metric charts
>
> * Accounts / Multi-tenancy
>
> I still see this as a great value and unique selling point, but also see
> the effort
> of maintaining this (and the issues we have with KC and hostnames).
> It may be good to also remove this
>
>
> * Embedded Cassandra
>
> I think this needs to be present in the community-distribution
>
> * UI/Agent installer
>
> Not sure if this is still needed or if we would just put the
> agent+installer
> into a directory of the zip for the users to take the installer from
> there.
>
> * Default user
>
> The Hawkular-aio download should feature a default user jdoe/password
> which is also set in the embedded agent.
> _______________________________________________
> 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  9 06:49:13 2016
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 9 May 2016 06:49:13 -0400 (EDT)
Subject: [Hawkular-dev] Fwd: Composition of the community distribution /
 Naming
In-Reply-To: <F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
Message-ID: <1320827789.47322031.1462790953418.JavaMail.zimbra@redhat.com>

What about:

1) Hawkular - the community (all in one) distribution, and

2) Hawkular-server - the server only, which may be of interest to community as a server only install, but also as foundation for MiQ integration.

Regards
Gary

----- Original Message -----
> Ping
> Silence means acceptance :-) (Especially for the naming)
> 
> > From: Heiko W.Rupp <hrupp at redhat.com>
> > To: Discussions around Hawkular development <hawkular-dev at lists.jboss.org>
> > Subject: [Hawkular-dev] Composition of the community distribution / Naming
> > Date: Wed, 04 May 2016 16:05:00 +0200
> >
> > Now that the votes has been cast, it is clear that there is a desire to
> > still have
> > a community distribution.
> >
> > Looking at the comments also make it clear that the scope needs to
> > refined.
> > Especially in the light that it was not communicated well enough before
> > that e.g.
> > the app-server tab in the UI will go away.
> > Discussion areas can be found below.
> >
> > Another question is the naming.
> > In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
> > we referenced 3 'distributions'
> > 1) Hawkular community release
> > which includes
> > 2) Hawkular core services
> > which includes
> > 3) Hawkular-metrics
> >
> > I propose to to rename 1) and 2) going forward to
> >
> > 1new) Hawkular-aio distribution
> > 2new) Hawkular
> >
> >
> >
> > Technical areas for discussion in the community-release (Hawkular-aio)
> > are:
> >
> > * Url handling / pinger / avail-creator
> >
> > Probably not needed going forward
> >
> > * UI/ Alert Center
> >
> > Needed in a generic way - i.e. allow to see fired alerts/events and to
> > define
> > generic triggers. For the display it will be enough to iterate over the
> > Event/Alert
> > object returned from the REST-api and to display the key/value pairs.
> >
> > * UI/ Explorer
> >
> > This needs to stay and we need to fix some smaller bugs to allow
> > for inventory browsing and display of metric charts
> >
> > * Accounts / Multi-tenancy
> >
> > I still see this as a great value and unique selling point, but also see
> > the effort
> > of maintaining this (and the issues we have with KC and hostnames).
> > It may be good to also remove this
> >
> >
> > * Embedded Cassandra
> >
> > I think this needs to be present in the community-distribution
> >
> > * UI/Agent installer
> >
> > Not sure if this is still needed or if we would just put the
> > agent+installer
> > into a directory of the zip for the users to take the installer from
> > there.
> >
> > * Default user
> >
> > The Hawkular-aio download should feature a default user jdoe/password
> > which is also set in the embedded agent.
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lponce at redhat.com  Mon May  9 06:54:11 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 9 May 2016 06:54:11 -0400 (EDT)
Subject: [Hawkular-dev] Fwd: Composition of the community distribution /
 Naming
In-Reply-To: <F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
Message-ID: <1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>

"Hawkular-aio" stands for "Hawkular All In One" ?

I prefer to not use acronyms, those are harder to identify (sometimes).

I propose:

1) Hawkular
2) Hawkular Services
3) Hawkular Metrics



----- Mensaje original -----
> De: "Heiko W.Rupp" <hrupp at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Lunes, 9 de Mayo 2016 12:35:28
> Asunto: [Hawkular-dev] Fwd: Composition of the community distribution / Naming
> 
> Ping
> Silence means acceptance :-) (Especially for the naming)
> 
> > From: Heiko W.Rupp <hrupp at redhat.com>
> > To: Discussions around Hawkular development <hawkular-dev at lists.jboss.org>
> > Subject: [Hawkular-dev] Composition of the community distribution / Naming
> > Date: Wed, 04 May 2016 16:05:00 +0200
> >
> > Now that the votes has been cast, it is clear that there is a desire to
> > still have
> > a community distribution.
> >
> > Looking at the comments also make it clear that the scope needs to
> > refined.
> > Especially in the light that it was not communicated well enough before
> > that e.g.
> > the app-server tab in the UI will go away.
> > Discussion areas can be found below.
> >
> > Another question is the naming.
> > In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
> > we referenced 3 'distributions'
> > 1) Hawkular community release
> > which includes
> > 2) Hawkular core services
> > which includes
> > 3) Hawkular-metrics
> >
> > I propose to to rename 1) and 2) going forward to
> >
> > 1new) Hawkular-aio distribution
> > 2new) Hawkular
> >
> >
> >
> > Technical areas for discussion in the community-release (Hawkular-aio)
> > are:
> >
> > * Url handling / pinger / avail-creator
> >
> > Probably not needed going forward
> >
> > * UI/ Alert Center
> >
> > Needed in a generic way - i.e. allow to see fired alerts/events and to
> > define
> > generic triggers. For the display it will be enough to iterate over the
> > Event/Alert
> > object returned from the REST-api and to display the key/value pairs.
> >
> > * UI/ Explorer
> >
> > This needs to stay and we need to fix some smaller bugs to allow
> > for inventory browsing and display of metric charts
> >
> > * Accounts / Multi-tenancy
> >
> > I still see this as a great value and unique selling point, but also see
> > the effort
> > of maintaining this (and the issues we have with KC and hostnames).
> > It may be good to also remove this
> >
> >
> > * Embedded Cassandra
> >
> > I think this needs to be present in the community-distribution
> >
> > * UI/Agent installer
> >
> > Not sure if this is still needed or if we would just put the
> > agent+installer
> > into a directory of the zip for the users to take the installer from
> > there.
> >
> > * Default user
> >
> > The Hawkular-aio download should feature a default user jdoe/password
> > which is also set in the embedded agent.
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From fbrychta at redhat.com  Mon May  9 07:02:11 2016
From: fbrychta at redhat.com (Filip Brychta)
Date: Mon, 9 May 2016 07:02:11 -0400 (EDT)
Subject: [Hawkular-dev] Upgrade to cassandra 3.5 caused performance drop ~5%
In-Reply-To: <140294772.29582029.1462791522172.JavaMail.zimbra@redhat.com>
Message-ID: <1518229432.29582337.1462791731559.JavaMail.zimbra@redhat.com>

Hello,
I updated tests to start using cassandra 3.5 and performance went down ~5%

Shall I create a Jira for that to investigate more or just change baselines directly?

Filip

From jsanda at redhat.com  Mon May  9 09:59:16 2016
From: jsanda at redhat.com (John Sanda)
Date: Mon, 9 May 2016 09:59:16 -0400
Subject: [Hawkular-dev] Upgrade to cassandra 3.5 caused performance drop
	~5%
In-Reply-To: <1518229432.29582337.1462791731559.JavaMail.zimbra@redhat.com>
References: <1518229432.29582337.1462791731559.JavaMail.zimbra@redhat.com>
Message-ID: <9CBFD130-E190-43EC-BDFD-67E316E254B1@redhat.com>

It would be good to know what caused the drop. What version(s) of metrics are you testing with? A whole bunch of changes went into the last release. Maybe some of those changes are involved?

> On May 9, 2016, at 7:02 AM, Filip Brychta <fbrychta at redhat.com> wrote:
> 
> Hello,
> I updated tests to start using cassandra 3.5 and performance went down ~5%
> 
> Shall I create a Jira for that to investigate more or just change baselines directly?
> 
> Filip
> _______________________________________________
> 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  9 10:45:37 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 09 May 2016 16:45:37 +0200
Subject: [Hawkular-dev] Composition of the community distribution /
	Naming
In-Reply-To: <1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
	<1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
Message-ID: <B08A661E-57E8-4317-8AC8-1BF893AE641C@redhat.com>

On 9 May 2016, at 12:54, Lucas Ponce wrote:

> "Hawkular-aio" stands for "Hawkular All In One" ?
>
> I prefer to not use acronyms, those are harder to identify (sometimes).
>
> I propose:
>
> 1) Hawkular
> 2) Hawkular Services

Sounds good.

> 3) Hawkular Metrics

From tsegismo at redhat.com  Mon May  9 10:55:08 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 9 May 2016 16:55:08 +0200
Subject: [Hawkular-dev] Fwd: Composition of the community distribution /
	Naming
In-Reply-To: <1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
	<1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
Message-ID: <CAHnC0xiSp1-qUfPJwS8p18CWNMA9StgLfJ1D1hzd=b8xyJVCrg@mail.gmail.com>

+1

2016-05-09 12:54 GMT+02:00 Lucas Ponce <lponce at redhat.com>:

> "Hawkular-aio" stands for "Hawkular All In One" ?
>
> I prefer to not use acronyms, those are harder to identify (sometimes).
>
> I propose:
>
> 1) Hawkular
> 2) Hawkular Services
> 3) Hawkular Metrics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160509/cfee488f/attachment.html 

From fbrychta at redhat.com  Mon May  9 11:40:08 2016
From: fbrychta at redhat.com (Filip Brychta)
Date: Mon, 9 May 2016 11:40:08 -0400 (EDT)
Subject: [Hawkular-dev] Upgrade to cassandra 3.5 caused performance
	drop	~5%
In-Reply-To: <9CBFD130-E190-43EC-BDFD-67E316E254B1@redhat.com>
References: <1518229432.29582337.1462791731559.JavaMail.zimbra@redhat.com>
	<9CBFD130-E190-43EC-BDFD-67E316E254B1@redhat.com>
Message-ID: <1513858499.29671754.1462808408951.JavaMail.zimbra@redhat.com>

I'm testing with latest master snapshot. Thing is that it's really caused just by cassandra version. When I switch back to cassandra 2.2 the performance is better again.

Filip

----- Original Message -----
> It would be good to know what caused the drop. What version(s) of metrics are
> you testing with? A whole bunch of changes went into the last release. Maybe
> some of those changes are involved?
> 
> > On May 9, 2016, at 7:02 AM, Filip Brychta <fbrychta at redhat.com> wrote:
> > 
> > Hello,
> > I updated tests to start using cassandra 3.5 and performance went down ~5%
> > 
> > Shall I create a Jira for that to investigate more or just change baselines
> > directly?
> > 
> > Filip
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From snegrea at redhat.com  Mon May  9 13:54:12 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 9 May 2016 12:54:12 -0500
Subject: [Hawkular-dev] Fwd: Composition of the community distribution /
	Naming
In-Reply-To: <1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
	<1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
Message-ID: <CADt-fV_AhUnbza0FymqojebWZ0s-1ZkqhYG297=k=e2W6T7EqQ@mail.gmail.com>

+1

Thank you,
Stefan Negrea

Software Engineer

On Mon, May 9, 2016 at 5:54 AM, Lucas Ponce <lponce at redhat.com> wrote:

> "Hawkular-aio" stands for "Hawkular All In One" ?
>
> I prefer to not use acronyms, those are harder to identify (sometimes).
>
> I propose:
>
> 1) Hawkular
> 2) Hawkular Services
> 3) Hawkular Metrics
>
>
>
> ----- Mensaje original -----
> > De: "Heiko W.Rupp" <hrupp at redhat.com>
> > Para: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> > Enviados: Lunes, 9 de Mayo 2016 12:35:28
> > Asunto: [Hawkular-dev] Fwd: Composition of the community distribution /
> Naming
> >
> > Ping
> > Silence means acceptance :-) (Especially for the naming)
> >
> > > From: Heiko W.Rupp <hrupp at redhat.com>
> > > To: Discussions around Hawkular development <
> hawkular-dev at lists.jboss.org>
> > > Subject: [Hawkular-dev] Composition of the community distribution /
> Naming
> > > Date: Wed, 04 May 2016 16:05:00 +0200
> > >
> > > Now that the votes has been cast, it is clear that there is a desire to
> > > still have
> > > a community distribution.
> > >
> > > Looking at the comments also make it clear that the scope needs to
> > > refined.
> > > Especially in the light that it was not communicated well enough before
> > > that e.g.
> > > the app-server tab in the UI will go away.
> > > Discussion areas can be found below.
> > >
> > > Another question is the naming.
> > > In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
> > > we referenced 3 'distributions'
> > > 1) Hawkular community release
> > > which includes
> > > 2) Hawkular core services
> > > which includes
> > > 3) Hawkular-metrics
> > >
> > > I propose to to rename 1) and 2) going forward to
> > >
> > > 1new) Hawkular-aio distribution
> > > 2new) Hawkular
> > >
> > >
> > >
> > > Technical areas for discussion in the community-release (Hawkular-aio)
> > > are:
> > >
> > > * Url handling / pinger / avail-creator
> > >
> > > Probably not needed going forward
> > >
> > > * UI/ Alert Center
> > >
> > > Needed in a generic way - i.e. allow to see fired alerts/events and to
> > > define
> > > generic triggers. For the display it will be enough to iterate over the
> > > Event/Alert
> > > object returned from the REST-api and to display the key/value pairs.
> > >
> > > * UI/ Explorer
> > >
> > > This needs to stay and we need to fix some smaller bugs to allow
> > > for inventory browsing and display of metric charts
> > >
> > > * Accounts / Multi-tenancy
> > >
> > > I still see this as a great value and unique selling point, but also
> see
> > > the effort
> > > of maintaining this (and the issues we have with KC and hostnames).
> > > It may be good to also remove this
> > >
> > >
> > > * Embedded Cassandra
> > >
> > > I think this needs to be present in the community-distribution
> > >
> > > * UI/Agent installer
> > >
> > > Not sure if this is still needed or if we would just put the
> > > agent+installer
> > > into a directory of the zip for the users to take the installer from
> > > there.
> > >
> > > * Default user
> > >
> > > The Hawkular-aio download should feature a default user jdoe/password
> > > which is also set in the embedded agent.
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160509/407dbd6d/attachment.html 

From jpkroehling at redhat.com  Tue May 10 10:01:39 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 16:01:39 +0200
Subject: [Hawkular-dev] Tenancy on Hawkular Services
Message-ID: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>

(this email uses the Hawkular naming as proposed by lponce)

It seems there has been some confusion about the situation around the 
multi tenancy in Hawkular Services. Most of what was discussed today on 
IRC was already discussed in a way or another before, but here's a 
summary of the previous discussions + what was discussed today on IRC:

Hawkular Services, except Agent:
* Tenant data is not going to be derived from Hawkular Services Auth Data.
* Tenancy is to be determined by the client and sent to Hawkular 
Services via the "Hawkular-Tenant" header.
* As tenancy is not to be determined at Hawkular Services, there's no 
point in having Accounts anymore. Most, if not all, components have 
already a "remove Accounts dependency" JIRA. If you need help on this 
task, let me know
* Removing Accounts != removing tenancy support. Multi tenancy is still 
a requirement for Hawkular Services!
* If the tenant is not provided (ie: Hawkular-Tenant HTTP header is 
non-existent or invalid), your endpoint should return a "400 - Bad Request".
* We might still have multi tenancy on Hawkular. But that's irrelevant 
for your component.

Agent and non-Hawkular Services:
* Agent will allow the user to set a tenant on standalone.xml . By 
default, it will be set to "hawkular"
* The Hawkular Ruby Gem, used by MiQ, will use tenancy information from 
MiQ when available. By default, it will be set to "hawkular"
* OpenShift already sends Hawkular-Tenant to Hawkular Metrics

- Juca.

From mwringe at redhat.com  Tue May 10 10:19:33 2016
From: mwringe at redhat.com (Matt Wringe)
Date: Tue, 10 May 2016 10:19:33 -0400 (EDT)
Subject: [Hawkular-dev] Fwd: Composition of the community distribution
	/	Naming
In-Reply-To: <CADt-fV_AhUnbza0FymqojebWZ0s-1ZkqhYG297=k=e2W6T7EqQ@mail.gmail.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<F07EB999-7009-44CD-B0CD-96148FDB1BD9@redhat.com>
	<1220922645.2421496.1462791251672.JavaMail.zimbra@redhat.com>
	<CADt-fV_AhUnbza0FymqojebWZ0s-1ZkqhYG297=k=e2W6T7EqQ@mail.gmail.com>
Message-ID: <1771746015.2582870.1462889973381.JavaMail.zimbra@redhat.com>

There is a bit of confusion over what 'Hawkular' is. I constantly have to remind people that we are using 'Hawkular Metrics' in OpenShift and not 'Hawkular' (but half of the time they continue to just call it 'Hawkular' anyways).

This means I sometimes get questions (or even bugs) opened when people are trying to access the main 'Hawkular' UI or to access the endpoints of other services (such as Alerts) because they think that all of 'Hawkular' is in OpenShift somewhere.

I would prefer to use 'Hawkular' as the term for the technology umbrella, rather than call one of those components 'Hawkular' directly. I think that would just confuse things even more.

----- Original Message -----
> From: "Stefan Negrea" <snegrea at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, May 9, 2016 1:54:12 PM
> Subject: Re: [Hawkular-dev] Fwd: Composition of the community distribution /	Naming
> 
> +1
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> On Mon, May 9, 2016 at 5:54 AM, Lucas Ponce < lponce at redhat.com > wrote:
> 
> 
> "Hawkular-aio" stands for "Hawkular All In One" ?
> 
> I prefer to not use acronyms, those are harder to identify (sometimes).
> 
> I propose:
> 
> 1) Hawkular
> 2) Hawkular Services
> 3) Hawkular Metrics
> 
> 
> 
> ----- Mensaje original -----
> > De: "Heiko W.Rupp" < hrupp at redhat.com >
> > Para: "Discussions around Hawkular development" <
> > hawkular-dev at lists.jboss.org >
> > Enviados: Lunes, 9 de Mayo 2016 12:35:28
> > Asunto: [Hawkular-dev] Fwd: Composition of the community distribution /
> > Naming
> > 
> > Ping
> > Silence means acceptance :-) (Especially for the naming)
> > 
> > > From: Heiko W.Rupp < hrupp at redhat.com >
> > > To: Discussions around Hawkular development <
> > > hawkular-dev at lists.jboss.org >
> > > Subject: [Hawkular-dev] Composition of the community distribution /
> > > Naming
> > > Date: Wed, 04 May 2016 16:05:00 +0200
> > > 
> > > Now that the votes has been cast, it is clear that there is a desire to
> > > still have
> > > a community distribution.
> > > 
> > > Looking at the comments also make it clear that the scope needs to
> > > refined.
> > > Especially in the light that it was not communicated well enough before
> > > that e.g.
> > > the app-server tab in the UI will go away.
> > > Discussion areas can be found below.
> > > 
> > > Another question is the naming.
> > > In http://www.hawkular.org/blog/2016/04/28/new-packaging.html
> > > we referenced 3 'distributions'
> > > 1) Hawkular community release
> > > which includes
> > > 2) Hawkular core services
> > > which includes
> > > 3) Hawkular-metrics
> > > 
> > > I propose to to rename 1) and 2) going forward to
> > > 
> > > 1new) Hawkular-aio distribution
> > > 2new) Hawkular
> > > 
> > > 
> > > 
> > > Technical areas for discussion in the community-release (Hawkular-aio)
> > > are:
> > > 
> > > * Url handling / pinger / avail-creator
> > > 
> > > Probably not needed going forward
> > > 
> > > * UI/ Alert Center
> > > 
> > > Needed in a generic way - i.e. allow to see fired alerts/events and to
> > > define
> > > generic triggers. For the display it will be enough to iterate over the
> > > Event/Alert
> > > object returned from the REST-api and to display the key/value pairs.
> > > 
> > > * UI/ Explorer
> > > 
> > > This needs to stay and we need to fix some smaller bugs to allow
> > > for inventory browsing and display of metric charts
> > > 
> > > * Accounts / Multi-tenancy
> > > 
> > > I still see this as a great value and unique selling point, but also see
> > > the effort
> > > of maintaining this (and the issues we have with KC and hostnames).
> > > It may be good to also remove this
> > > 
> > > 
> > > * Embedded Cassandra
> > > 
> > > I think this needs to be present in the community-distribution
> > > 
> > > * UI/Agent installer
> > > 
> > > Not sure if this is still needed or if we would just put the
> > > agent+installer
> > > into a directory of the zip for the users to take the installer from
> > > there.
> > > 
> > > * Default user
> > > 
> > > The Hawkular-aio download should feature a default user jdoe/password
> > > which is also set in the embedded agent.
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> 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 10 10:31:35 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 10 May 2016 10:31:35 -0400 (EDT)
Subject: [Hawkular-dev] Tenancy on Hawkular Services
In-Reply-To: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
References: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
Message-ID: <1088208002.1252481.1462890695333.JavaMail.zimbra@redhat.com>

> point in having Accounts anymore. Most, if not all, components have
> already a "remove Accounts dependency" JIRA. If you need help on this
> task, let me know

Agent JIRA: https://issues.jboss.org/browse/HWKAGENT-86
Agent PR: https://github.com/hawkular/hawkular-agent/pull/180

That PR still has Accounts feature pack stuff in it for the itests stuff. I need help on that task
.
> Agent and non-Hawkular Services:
> * Agent will allow the user to set a tenant on standalone.xml . By
> default, it will be set to "hawkular"

This is implemented in the above PR

From jpkroehling at redhat.com  Tue May 10 11:04:53 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 17:04:53 +0200
Subject: [Hawkular-dev] Tenancy on Hawkular Services
In-Reply-To: <1088208002.1252481.1462890695333.JavaMail.zimbra@redhat.com>
References: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
	<1088208002.1252481.1462890695333.JavaMail.zimbra@redhat.com>
Message-ID: <811a3eeb-1865-0b43-a6c7-702fd22d693b@redhat.com>

On 10.05.2016 16:31, John Mazzitelli wrote:
> Agent JIRA: https://issues.jboss.org/browse/HWKAGENT-86
> Agent PR: https://github.com/hawkular/hawkular-agent/pull/180
>
> That PR still has Accounts feature pack stuff in it for the itests stuff. I need help on that task

I believe that Peter is already working on that. For most components, 
the change will be simple: just start using the Nest Feature Pack 
instead of Accounts, and add JAAS configuration to the Wildfly server 
you build for the integration tests.

To add the JAAS configuration, you'd need this:

https://git.io/vwADp - web.xml (on your WAR)
https://git.io/vwAyT - application-roles.properties
https://git.io/vwAyL - application-users.properties

- Juca.

From jpkroehling at redhat.com  Tue May 10 11:31:27 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 17:31:27 +0200
Subject: [Hawkular-dev] Keycloak on Hawkular
Message-ID: <e20910bc-f264-b41e-e297-53c35a19ee48@redhat.com>

Similar to the thread about Tenancy on Hawkular Services, I thought I'd 
also post about the current state of Keycloak for Hawkular.

Hawkular Services cannot depend on Keycloak. Because of that, Nest is 
being changed to not consume the Keycloak Feature pack as before.

As a side effect, we do not have support for tokens anymore (key/secret 
tokens, created via the "Tokens" UI), as those tokens were backed by 
OAuth Offline Tokens.

Hawkular Services will have a simple JAAS integration, which should give 
us enough flexibility for the scenarios that we need to support.

The UI on Hawkular will also have to remove the keycloak.js . I have yet 
to talk to the UI developers, but I think the main idea for now would be 
to have the WAR for the UI to be deployed and protected like any other 
backend component. The Accounts-related part will also have to be 
removed, such as the Organization and Token management.

Nothing prevents Hawkular from shipping with Keycloak (server and/or 
adapter), as recent versions of Keycloak can protect any WAR deployments 
transparently, via the Keycloak Adapter Subsystem for Wildfly. This can 
be done by the community if interest in that integration exists but I 
currently have no plans on working on that.

For reference, this is how you can activate a simple JAAS for your 
deployments:

https://git.io/vwADp - web.xml (on your WAR)
https://git.io/vwAyT - application-roles.properties
https://git.io/vwAyL - application-users.properties

- Juca.

From jpkroehling at redhat.com  Tue May 10 11:41:48 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 17:41:48 +0200
Subject: [Hawkular-dev] What are your Authentication and Authorization
 needs?
In-Reply-To: <571A0F63.7010105@redhat.com>
References: <571A0F63.7010105@redhat.com>
Message-ID: <feca21c6-e8cf-0d96-2dc8-8965e24da67f@redhat.com>

On 22.04.2016 13:47, Juraci Paix?o Kr?hling wrote:
> Due to the changes in requirements for Hawkular, I'm collecting the
> needs we have around authentication and authorization.

It seems we have very simple needs on this front. From what I could 
gather, all we need is to support two roles: read-write and read-only .

So, it's safe to assume that your component will be protected via JAAS 
and that the Principal will either be in the "read-only" role or will 
have both "read-only" and "read-write" roles. This means, of course, 
that you can (or even, that you should) make use of the JAAS API and 
annotations to protect your backend endpoints, such as @RolesAllowed or 
HttpServletRequest#getUserPrincipal() .

- Juca.

From kurrent93 at gmail.com  Tue May 10 11:46:03 2016
From: kurrent93 at gmail.com (Anton)
Date: Tue, 10 May 2016 17:46:03 +0200
Subject: [Hawkular-dev] Keycloak on Hawkular
In-Reply-To: <e20910bc-f264-b41e-e297-53c35a19ee48@redhat.com>
References: <e20910bc-f264-b41e-e297-53c35a19ee48@redhat.com>
Message-ID: <CAD44pJD9hJff54Az6rVVRN+7Vb3U8Q3wYEEuKc4w1L-v3_Giig@mail.gmail.com>

On Tue, May 10, 2016 at 5:31 PM, Juraci Paix?o Kr?hling <
jpkroehling at redhat.com> wrote:

> Nothing prevents Hawkular from shipping with Keycloak (server and/or
> adapter), as recent versions of Keycloak can protect any WAR deployments
> transparently, via the Keycloak Adapter Subsystem for Wildfly. This can
> be done by the community if interest in that integration exists but I
> currently have no plans on working on that.
>

I really hope this is included. I can appreciate you want to remove
dependencies, but Keycloak is extremely useful, and I had come to expect -
falsely - that jboss/redhat products would provide easy or OOTB support for
something so fundamental as Keycloak.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160510/9ce3afa2/attachment.html 

From jpkroehling at redhat.com  Tue May 10 12:07:02 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 18:07:02 +0200
Subject: [Hawkular-dev] Keycloak on Hawkular
In-Reply-To: <CAD44pJD9hJff54Az6rVVRN+7Vb3U8Q3wYEEuKc4w1L-v3_Giig@mail.gmail.com>
References: <e20910bc-f264-b41e-e297-53c35a19ee48@redhat.com>
	<CAD44pJD9hJff54Az6rVVRN+7Vb3U8Q3wYEEuKc4w1L-v3_Giig@mail.gmail.com>
Message-ID: <65ebe5e8-55a3-1f0a-ff97-ba55bc750b24@redhat.com>

On 10.05.2016 17:46, Anton wrote:
>
> On Tue, May 10, 2016 at 5:31 PM, Juraci Paix?o Kr?hling
> <jpkroehling at redhat.com <mailto:jpkroehling at redhat.com>> wrote:
>
>     Nothing prevents Hawkular from shipping with Keycloak (server and/or
>     adapter), as recent versions of Keycloak can protect any WAR deployments
>     transparently, via the Keycloak Adapter Subsystem for Wildfly. This can
>     be done by the community if interest in that integration exists but I
>     currently have no plans on working on that.
>
>
> I really hope this is included. I can appreciate you want to remove
> dependencies, but Keycloak is extremely useful, and I had come to expect
> - falsely - that jboss/redhat products would provide easy or OOTB
> support for something so fundamental as Keycloak.

"Easy" is subjective, but I'd say that it's still easy to have Keycloak 
protecting Hawkular: it's just a matter of installing the Keycloak 
Adapter and adding the <secure-deployment> sections to the standalone.xml :

https://git.io/vrU8h

Note that we did ship Keycloak server on the same Wildfly instance as 
Hawkular, but that was never a recommended approach other than for 
development purposes. So, one could argue that it's easier to do a 
proper Keycloak integration now than it was before :)

- Juca.

From gbrown at redhat.com  Tue May 10 12:16:25 2016
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 10 May 2016 12:16:25 -0400 (EDT)
Subject: [Hawkular-dev] Tenancy on Hawkular Services
In-Reply-To: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
References: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
Message-ID: <1796315942.47777681.1462896985836.JavaMail.zimbra@redhat.com>

Hi Juca

So just to be clear, this means that there is no server side validation to ensure the user is able to read from/write to the supplied tenant? This would have to be handled in the client aswell?

Regards
Gary

----- Original Message -----
> (this email uses the Hawkular naming as proposed by lponce)
> 
> It seems there has been some confusion about the situation around the
> multi tenancy in Hawkular Services. Most of what was discussed today on
> IRC was already discussed in a way or another before, but here's a
> summary of the previous discussions + what was discussed today on IRC:
> 
> Hawkular Services, except Agent:
> * Tenant data is not going to be derived from Hawkular Services Auth Data.
> * Tenancy is to be determined by the client and sent to Hawkular
> Services via the "Hawkular-Tenant" header.
> * As tenancy is not to be determined at Hawkular Services, there's no
> point in having Accounts anymore. Most, if not all, components have
> already a "remove Accounts dependency" JIRA. If you need help on this
> task, let me know
> * Removing Accounts != removing tenancy support. Multi tenancy is still
> a requirement for Hawkular Services!
> * If the tenant is not provided (ie: Hawkular-Tenant HTTP header is
> non-existent or invalid), your endpoint should return a "400 - Bad Request".
> * We might still have multi tenancy on Hawkular. But that's irrelevant
> for your component.
> 
> Agent and non-Hawkular Services:
> * Agent will allow the user to set a tenant on standalone.xml . By
> default, it will be set to "hawkular"
> * The Hawkular Ruby Gem, used by MiQ, will use tenancy information from
> MiQ when available. By default, it will be set to "hawkular"
> * OpenShift already sends Hawkular-Tenant to Hawkular Metrics
> 
> - Juca.
> _______________________________________________
> 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 10 12:33:51 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 10 May 2016 18:33:51 +0200
Subject: [Hawkular-dev] Tenancy on Hawkular Services
In-Reply-To: <1796315942.47777681.1462896985836.JavaMail.zimbra@redhat.com>
References: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
	<1796315942.47777681.1462896985836.JavaMail.zimbra@redhat.com>
Message-ID: <2db90a03-a64d-3a98-24d3-39959abb7910@redhat.com>

On 10.05.2016 18:16, Gary Brown wrote:
> So just to be clear, this means that there is no server side validation to ensure the user is able to read from/write to the supplied tenant? This would have to be handled in the client aswell?

Correct, we rely on accurate tenant information being provided by the 
client. Such authorization checks are to be done at the client level as 
well.

- Juca.


From mazz at redhat.com  Tue May 10 16:22:25 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 10 May 2016 16:22:25 -0400 (EDT)
Subject: [Hawkular-dev] Tenancy on Hawkular Services
In-Reply-To: <811a3eeb-1865-0b43-a6c7-702fd22d693b@redhat.com>
References: <98253f3d-848d-74b1-4b8d-dcb0d89c3cc5@redhat.com>
	<1088208002.1252481.1462890695333.JavaMail.zimbra@redhat.com>
	<811a3eeb-1865-0b43-a6c7-702fd22d693b@redhat.com>
Message-ID: <47245259.1349273.1462911745354.JavaMail.zimbra@redhat.com>

> On 10.05.2016 16:31, John Mazzitelli wrote:
> > Agent JIRA: https://issues.jboss.org/browse/HWKAGENT-86
> > Agent PR: https://github.com/hawkular/hawkular-agent/pull/180
> >
> > That PR still has Accounts feature pack stuff in it for the itests stuff. I
> > need help on that task
> 
> I believe that Peter is already working on that.

I see Peter is working on taking out Accounts from Inventory right now. I will assign this agent JIRA to Peter since it will probably take him 5 minutes to do the agent once he gets everything figured out with Inventory :)

From jsanda at redhat.com  Tue May 10 16:42:02 2016
From: jsanda at redhat.com (John Sanda)
Date: Tue, 10 May 2016 16:42:02 -0400
Subject: [Hawkular-dev] What are your Authentication and Authorization
	needs?
In-Reply-To: <571E1BBA.2070907@redhat.com>
References: <571A0F63.7010105@redhat.com>
	<149057485.4675131.1461568383225.JavaMail.zimbra@redhat.com>
	<7bbb3a40-fd71-043f-7982-b458b501c017@redhat.com>
	<62209943.4681477.1461569516237.JavaMail.zimbra@redhat.com>
	<571E1BBA.2070907@redhat.com>
Message-ID: <C5B26837-5599-4765-9653-93E400FFA63C@redhat.com>


> On Apr 25, 2016, at 9:29 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
> 
> 
> Juca,  I think Lucas is correct, Alerts has the multi-tenancy model built in and so requires a tenantId on everything.   We already have a standalone distribution (for use outside of Hawkular) that drives off of the Hawkular-Tenant header, so I guess we would just continue to use that mechanism in all cases.  I guess that means we may drop the h-accounts dependency but I will discuss further with Lucas and we'll continue to monitor the accounts changes.
> 
> Lucas, this may further drive the need for schema refactoring because if we only receive a single tenant on everything coming from MIQ, we will get very little data distribution.

I?ve said it in the past and it?s worth mentioning again. Even with multiple tenants, you should be partitioning by more than just tenant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160510/75064126/attachment.html 

From jshaughn at redhat.com  Wed May 11 08:51:28 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 11 May 2016 08:51:28 -0400
Subject: [Hawkular-dev] What are your Authentication and Authorization
 needs?
In-Reply-To: <C5B26837-5599-4765-9653-93E400FFA63C@redhat.com>
References: <571A0F63.7010105@redhat.com>
	<149057485.4675131.1461568383225.JavaMail.zimbra@redhat.com>
	<7bbb3a40-fd71-043f-7982-b458b501c017@redhat.com>
	<62209943.4681477.1461569516237.JavaMail.zimbra@redhat.com>
	<571E1BBA.2070907@redhat.com>
	<C5B26837-5599-4765-9653-93E400FFA63C@redhat.com>
Message-ID: <57332AD0.9040802@redhat.com>


Yes, yes, we know it's far from perfect :) Just can't yet get the 
bandwidth to do that schema review...

On 5/10/2016 4:42 PM, John Sanda wrote:
>
>> On Apr 25, 2016, at 9:29 AM, Jay Shaughnessy <jshaughn at redhat.com 
>> <mailto:jshaughn at redhat.com>> wrote:
>>
>>
>> Juca,  I think Lucas is correct, Alerts has the multi-tenancy model 
>> built in and so requires a tenantId on everything.   We already have 
>> a standalone distribution (for use outside of Hawkular) that drives 
>> off of the Hawkular-Tenant header, so I guess we would just continue 
>> to use that mechanism in all cases.  I guess that means we may drop 
>> the h-accounts dependency but I will discuss further with Lucas and 
>> we'll continue to monitor the accounts changes.
>>
>> Lucas, this may further drive the need for schema refactoring because 
>> if we only receive a single tenant on everything coming from MIQ, we 
>> will get very little data distribution.
>
> I?ve said it in the past and it?s worth mentioning again. Even with 
> multiple tenants, you should be partitioning by more than just tenant.
>
>
> _______________________________________________
> 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/20160511/aacd0d71/attachment-0001.html 

From gbrown at redhat.com  Wed May 11 11:01:56 2016
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 11 May 2016 11:01:56 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application in Hawkular BTM
In-Reply-To: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
Message-ID: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>

Hi

I would like to discuss how best to define the concept of an Application within the BTM project, how it relates to the existing concept of a "Business Transaction" and how it may link in with the concept of an application in Hawkular/ManageIQ in general.

Firstly, for those not familiar with Hawkular BTM, without configuration the project can capture and trace an invocation across multiple interconnected services. The information can be used to provide stats on the individual components used (endpoints, databases, ejbs, etc) as well as (in the next version) present a graph showing the relationships between the communicating services.

The project also enables "Business Transactions" to be configured - this enables a particular invocation of an endpoint to be labelled with a business transaction name (which is propagated to the fragments associated with the invoked services), and also perform additional processing on the messages, such as extract business properties, etc. Once a "Business Transaction" has been defined, it is possible to view high level stats about the complete "end to end" business transactions.

This is achieved by creating a configuration that identifies the initial endpoint for the business transaction, using a regular expression, and then a set of 'processors' that are used to perform various processing tasks within the scope of that business transaction.

We now have a requirement to identify the concept of an Application, and be able to present various stats about it. I believe that the Application can be viewed as orthogonal to the Business Transaction concept - so an Application represents the various operations that can be performed on a particular architectural component, whereas the Business Transaction represents a particular path through multiple Applications/Services, only using a subset of the operations/endpoints supported by the Application.

However the requirements are very similar - when we detect some activity on a particular endpoint we want to determine if it belongs to an Application, in the same way as we currently do with Business Transactions. And similarly, once classified as being associated with an Application, we may want to do some application specific processing on the data.

Therefore what I am considering is making the existing Business Transaction Configuration generic so that it is suitable for both tasks, with a simple classifier to indicate whether it relates to a Business Transaction or Application.

This will mean that the fragments of activity being recorded and sent to the BTM server could now potentially have two names, one for the business transaction (which is propagated across application/service boundaries) and one for an application name (which is not propagated).

Where appropriate, the UI could then be updated to allow the user to also filter information based on application - this may only make sense on the APM page, but could be considered if useful elsewhere. We may also want to make the current Business Transaction overview page more general to include both Business Transactions and Applications, and then have a different type of details page for applications.

The final point is how this may link into Hawkular/ManageIQ. Was thinking that where possible, it would be good if a deployment event could be used to trigger the configuration of the Application in Hawkular BTM - especially if it is possible to obtain the web context for the application (or JMS queue/topic), which can then be used to establish the regular expression. If this level of integration was possible, then no user defined configuration would be necessary to capture application information using the same name as in Hawkular - allowing an integrated view of the information to be made available.

Thoughts?

Regards
Gary


From snegrea at redhat.com  Wed May 11 19:28:44 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 11 May 2016 18:28:44 -0500
Subject: [Hawkular-dev] Hawkular Organization - Repositories
Message-ID: <CADt-fV8DLBJoX1UOu+Kx2dwHsYTqzYKPctQ2t52vmapnVG1wfw@mail.gmail.com>

Hello Everybody,

As a continuation of the previous discussions regarding the Hawkular
reorganization, I created a spreadsheet with all repositories. The goal is
to get a clear idea on the prospect of each repository.

Below the red line are all the repositories no longer relevant, their
future will be decided at the end of this process. If I missed something no
longer needed, please move it below the red line with a note.

Above the red line are all the repositories still relevant. Please add
comments if you think there should be some consolidation (merging repos) or
if it might become irrelevant/obsolete soon.


Document:
https://docs.google.com/a/redhat.com/spreadsheets/d/1IzoBP9glz3GgkcwTRF6cobQCylUaZFLhFgqxRfuQCn0/edit?usp=sharing


Thank you,
Stefan Negrea

Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160511/fb00c398/attachment.html 

From theute at redhat.com  Thu May 12 07:20:54 2016
From: theute at redhat.com (Thomas Heute)
Date: Thu, 12 May 2016 13:20:54 +0200
Subject: [Hawkular-dev] Definition the concept of Application in
	Hawkular BTM
In-Reply-To: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>

On Wed, May 11, 2016 at 5:01 PM, Gary Brown <gbrown at redhat.com> wrote:

> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration
> the project can capture and trace an invocation across multiple
> interconnected services. The information can be used to provide stats on
> the individual components used (endpoints, databases, ejbs, etc) as well as
> (in the next version) present a graph showing the relationships between the
> communicating services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats
> about the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and
> be able to present various stats about it. I believe that the Application
> can be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>


I quite agree here, except that I would map an application to *several*
achitectural components (for instance N microservices).
Now if you have 2 logical applications (say e-commerce and brand website),
a same architecture component may be shared (say user registration) in the
2 apps.


>
> However the requirements are very similar - when we detect some activity
> on a particular endpoint we want to determine if it belongs to an
> Application, in the same way as we currently do with Business Transactions.
> And similarly, once classified as being associated with an Application, we
> may want to do some application specific processing on the data.
>

So here if an activity on a user registration endpoint is recorded, would
it record for each segment with app it referred to ?


>
> Therefore what I am considering is making the existing Business
> Transaction Configuration generic so that it is suitable for both tasks,
> with a simple classifier to indicate whether it relates to a Business
> Transaction or Application.
>
> This will mean that the fragments of activity being recorded and sent to
> the BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used
> to trigger the configuration of the Application in Hawkular BTM -
> especially if it is possible to obtain the web context for the application
> (or JMS queue/topic), which can then be used to establish the regular
> expression. If this level of integration was possible, then no user defined
> configuration would be necessary to capture application information using
> the same name as in Hawkular - allowing an integrated view of the
> information to be made available.
>
> Thoughts?
>

In general from the very high level view (ManageIQ), I would want to be
able to define a logical notion  of "application" for monitoring purposes,
I would expect to be able to add "entities" to that logical view. It may
just be a war file (and in the case of BTM, I would likely be interested by
all entry points to that application) or it could be an "OpenShift Project"
with all its dependencies (all docker containers + everything in it), or it
could be a selection of MW servers...

In the end, the user should be able to dig into infrastructure details (and
he already has that, he can see details about the infrastructure: a
container, a host, a MW server (coming soon), a MW deployment (coming
soon)...) + details on Business transactions but also have that synthetic
view where he knows that all services that makes his online store are
running fine, and have a few KPI such as the Apdex for all user-facing
interactions, the N slowest URLs or DB requests...

(This definitely goes beyond BTM, and we likely need to simplify and work
on iterations of those ideas (or better ideas))

That's what I dream of, as a user.

Thomas



>
> Regards
> Gary
>
> _______________________________________________
> 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/20160512/b4479ac8/attachment.html 

From gbrown at redhat.com  Thu May 12 08:47:46 2016
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 12 May 2016 08:47:46 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application
	in	Hawkular BTM
In-Reply-To: <CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
Message-ID: <692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>

Hi Thomas

I think possibly there are different concepts here, so I need to clarify - the one I was trying to describe is to capture the individual services, which may be user facing, and would essentially map onto the individual services (in a micro-services world).

So possibly rather than application, it should be termed "service"? which would actually match the microservices world better anyway.

This service concept, especially in the case of user facing endpoints, would be used to derive stats like Apdex - although the same stats could be defined for internal services as well, to provide the dev teams behind those services with a satisfaction index for their consumers.

I think the highlevel communication diagram provided in the Distributed Tracing UI page could act as the basis for understanding which 'services' and resources (if we dig further to understand databases, etc used) are used to deliver the total 'application'.

Having an understanding of the separate 'services' and potentially the resources they used, could then enable ManageIQ to build the logical grouping that you mention, out of those services? So to be clear, BTM could provide a highlevel understanding of the services and their communication paths (and possibly resources used), and ManageIQ could use this information to selectively (or as a complete set of interrelated services) present the user with a logical group consisting of those managed objects.

> So here if an activity on a user registration endpoint is recorded, would it
> record for each segment with app it referred to ?
> 

Wasn't sure what you meant here, if you could give an example?

Regards
Gary


----- Original Message -----
> 
> 
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown at redhat.com > wrote:
> 
> 
> Hi
> 
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
> 
> Firstly, for those not familiar with Hawkular BTM, without configuration the
> project can capture and trace an invocation across multiple interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the communicating
> services.
> 
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats about
> the complete "end to end" business transactions.
> 
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
> 
> We now have a requirement to identify the concept of an Application, and be
> able to present various stats about it. I believe that the Application can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
> 
> 
> I quite agree here, except that I would map an application to *several*
> achitectural components (for instance N microservices).
> Now if you have 2 logical applications (say e-commerce and brand website), a
> same architecture component may be shared (say user registration) in the 2
> apps.
> 
> 
> 
> However the requirements are very similar - when we detect some activity on a
> particular endpoint we want to determine if it belongs to an Application, in
> the same way as we currently do with Business Transactions. And similarly,
> once classified as being associated with an Application, we may want to do
> some application specific processing on the data.
> 
> So here if an activity on a user registration endpoint is recorded, would it
> record for each segment with app it referred to ?
> 
> 
> 
> Therefore what I am considering is making the existing Business Transaction
> Configuration generic so that it is suitable for both tasks, with a simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
> 
> This will mean that the fragments of activity being recorded and sent to the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
> 
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
> 
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used to
> trigger the configuration of the Application in Hawkular BTM - especially if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular expression. If
> this level of integration was possible, then no user defined configuration
> would be necessary to capture application information using the same name as
> in Hawkular - allowing an integrated view of the information to be made
> available.
> 
> Thoughts?
> 
> In general from the very high level view (ManageIQ), I would want to be able
> to define a logical notion of "application" for monitoring purposes, I would
> expect to be able to add "entities" to that logical view. It may just be a
> war file (and in the case of BTM, I would likely be interested by all entry
> points to that application) or it could be an "OpenShift Project" with all
> its dependencies (all docker containers + everything in it), or it could be
> a selection of MW servers...
> 
> In the end, the user should be able to dig into infrastructure details (and
> he already has that, he can see details about the infrastructure: a
> container, a host, a MW server (coming soon), a MW deployment (coming
> soon)...) + details on Business transactions but also have that synthetic
> view where he knows that all services that makes his online store are
> running fine, and have a few KPI such as the Apdex for all user-facing
> interactions, the N slowest URLs or DB requests...
> 
> (This definitely goes beyond BTM, and we likely need to simplify and work on
> iterations of those ideas (or better ideas))
> 
> That's what I dream of, as a user.
> 
> Thomas
> 
> 
> 
> 
> 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 snegrea at redhat.com  Thu May 12 10:23:11 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 12 May 2016 09:23:11 -0500
Subject: [Hawkular-dev] Definition the concept of Application in
	Hawkular BTM
In-Reply-To: <692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
	<692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
Message-ID: <CADt-fV-UvNJCeFcYvKt-GVnPi=U7PLViGn0J_b1q=FxhEQuVKA@mail.gmail.com>

Hello,

What was described in the original email sounded to me like tagging. A
transaction fragment stored in BTM could be tagged with an arbitrarily
number of tags. Here is an example { application: myapp, service:
superservice, datacenter: east}. And then the API needs to allow users to
query data based on tags and query the actual tag values.

So rather than expanding the design to cover just one other single concept
(application) the design with tags is generic and flexible.


Thank you,
Stefan Negrea

Software Engineer

On Thu, May 12, 2016 at 7:47 AM, Gary Brown <gbrown at redhat.com> wrote:

> Hi Thomas
>
> I think possibly there are different concepts here, so I need to clarify -
> the one I was trying to describe is to capture the individual services,
> which may be user facing, and would essentially map onto the individual
> services (in a micro-services world).
>
> So possibly rather than application, it should be termed "service"? which
> would actually match the microservices world better anyway.
>
> This service concept, especially in the case of user facing endpoints,
> would be used to derive stats like Apdex - although the same stats could be
> defined for internal services as well, to provide the dev teams behind
> those services with a satisfaction index for their consumers.
>
> I think the highlevel communication diagram provided in the Distributed
> Tracing UI page could act as the basis for understanding which 'services'
> and resources (if we dig further to understand databases, etc used) are
> used to deliver the total 'application'.
>
> Having an understanding of the separate 'services' and potentially the
> resources they used, could then enable ManageIQ to build the logical
> grouping that you mention, out of those services? So to be clear, BTM could
> provide a highlevel understanding of the services and their communication
> paths (and possibly resources used), and ManageIQ could use this
> information to selectively (or as a complete set of interrelated services)
> present the user with a logical group consisting of those managed objects.
>
> > So here if an activity on a user registration endpoint is recorded,
> would it
> > record for each segment with app it referred to ?
> >
>
> Wasn't sure what you meant here, if you could give an example?
>
> Regards
> Gary
>
>
> ----- Original Message -----
> >
> >
> > On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown at redhat.com > wrote:
> >
> >
> > Hi
> >
> > I would like to discuss how best to define the concept of an Application
> > within the BTM project, how it relates to the existing concept of a
> > "Business Transaction" and how it may link in with the concept of an
> > application in Hawkular/ManageIQ in general.
> >
> > Firstly, for those not familiar with Hawkular BTM, without configuration
> the
> > project can capture and trace an invocation across multiple
> interconnected
> > services. The information can be used to provide stats on the individual
> > components used (endpoints, databases, ejbs, etc) as well as (in the next
> > version) present a graph showing the relationships between the
> communicating
> > services.
> >
> > The project also enables "Business Transactions" to be configured - this
> > enables a particular invocation of an endpoint to be labelled with a
> > business transaction name (which is propagated to the fragments
> associated
> > with the invoked services), and also perform additional processing on the
> > messages, such as extract business properties, etc. Once a "Business
> > Transaction" has been defined, it is possible to view high level stats
> about
> > the complete "end to end" business transactions.
> >
> > This is achieved by creating a configuration that identifies the initial
> > endpoint for the business transaction, using a regular expression, and
> then
> > a set of 'processors' that are used to perform various processing tasks
> > within the scope of that business transaction.
> >
> > We now have a requirement to identify the concept of an Application, and
> be
> > able to present various stats about it. I believe that the Application
> can
> > be viewed as orthogonal to the Business Transaction concept - so an
> > Application represents the various operations that can be performed on a
> > particular architectural component, whereas the Business Transaction
> > represents a particular path through multiple Applications/Services, only
> > using a subset of the operations/endpoints supported by the Application.
> >
> >
> > I quite agree here, except that I would map an application to *several*
> > achitectural components (for instance N microservices).
> > Now if you have 2 logical applications (say e-commerce and brand
> website), a
> > same architecture component may be shared (say user registration) in the
> 2
> > apps.
> >
> >
> >
> > However the requirements are very similar - when we detect some activity
> on a
> > particular endpoint we want to determine if it belongs to an
> Application, in
> > the same way as we currently do with Business Transactions. And
> similarly,
> > once classified as being associated with an Application, we may want to
> do
> > some application specific processing on the data.
> >
> > So here if an activity on a user registration endpoint is recorded,
> would it
> > record for each segment with app it referred to ?
> >
> >
> >
> > Therefore what I am considering is making the existing Business
> Transaction
> > Configuration generic so that it is suitable for both tasks, with a
> simple
> > classifier to indicate whether it relates to a Business Transaction or
> > Application.
> >
> > This will mean that the fragments of activity being recorded and sent to
> the
> > BTM server could now potentially have two names, one for the business
> > transaction (which is propagated across application/service boundaries)
> and
> > one for an application name (which is not propagated).
> >
> > Where appropriate, the UI could then be updated to allow the user to also
> > filter information based on application - this may only make sense on the
> > APM page, but could be considered if useful elsewhere. We may also want
> to
> > make the current Business Transaction overview page more general to
> include
> > both Business Transactions and Applications, and then have a different
> type
> > of details page for applications.
> >
> > The final point is how this may link into Hawkular/ManageIQ. Was thinking
> > that where possible, it would be good if a deployment event could be
> used to
> > trigger the configuration of the Application in Hawkular BTM -
> especially if
> > it is possible to obtain the web context for the application (or JMS
> > queue/topic), which can then be used to establish the regular
> expression. If
> > this level of integration was possible, then no user defined
> configuration
> > would be necessary to capture application information using the same
> name as
> > in Hawkular - allowing an integrated view of the information to be made
> > available.
> >
> > Thoughts?
> >
> > In general from the very high level view (ManageIQ), I would want to be
> able
> > to define a logical notion of "application" for monitoring purposes, I
> would
> > expect to be able to add "entities" to that logical view. It may just be
> a
> > war file (and in the case of BTM, I would likely be interested by all
> entry
> > points to that application) or it could be an "OpenShift Project" with
> all
> > its dependencies (all docker containers + everything in it), or it could
> be
> > a selection of MW servers...
> >
> > In the end, the user should be able to dig into infrastructure details
> (and
> > he already has that, he can see details about the infrastructure: a
> > container, a host, a MW server (coming soon), a MW deployment (coming
> > soon)...) + details on Business transactions but also have that synthetic
> > view where he knows that all services that makes his online store are
> > running fine, and have a few KPI such as the Apdex for all user-facing
> > interactions, the N slowest URLs or DB requests...
> >
> > (This definitely goes beyond BTM, and we likely need to simplify and
> work on
> > iterations of those ideas (or better ideas))
> >
> > That's what I dream of, as a user.
> >
> > Thomas
> >
> >
> >
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160512/010459b0/attachment.html 

From gbrown at redhat.com  Thu May 12 10:37:56 2016
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 12 May 2016 10:37:56 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application
	in	Hawkular BTM
In-Reply-To: <CADt-fV-UvNJCeFcYvKt-GVnPi=U7PLViGn0J_b1q=FxhEQuVKA@mail.gmail.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
	<692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
	<CADt-fV-UvNJCeFcYvKt-GVnPi=U7PLViGn0J_b1q=FxhEQuVKA@mail.gmail.com>
Message-ID: <2009459565.48230496.1463063876608.JavaMail.zimbra@redhat.com>

Hi Stefan

Yes that would be possible with the current approach, although the concept of 'service' has a specific benefit as being a first class citizen, in that it can name a node in the communication diagram, and where the 'service' is implemented using multiple concurrent threads, then it can also glue together those fragments - but only because it will have special meaning.

But apart from that, having the ability for the user/administrator to tag the fragments with concepts that they are interested in, and then query on them (whether on the basis of being part of a service or business transaction or neither or both) would be possible.

Regards
Gary

----- Original Message -----
> Hello,
> 
> What was described in the original email sounded to me like tagging. A
> transaction fragment stored in BTM could be tagged with an arbitrarily
> number of tags. Here is an example { application: myapp, service:
> superservice, datacenter: east}. And then the API needs to allow users to
> query data based on tags and query the actual tag values.
> 
> So rather than expanding the design to cover just one other single concept
> (application) the design with tags is generic and flexible.
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> On Thu, May 12, 2016 at 7:47 AM, Gary Brown < gbrown at redhat.com > wrote:
> 
> 
> Hi Thomas
> 
> I think possibly there are different concepts here, so I need to clarify -
> the one I was trying to describe is to capture the individual services,
> which may be user facing, and would essentially map onto the individual
> services (in a micro-services world).
> 
> So possibly rather than application, it should be termed "service"? which
> would actually match the microservices world better anyway.
> 
> This service concept, especially in the case of user facing endpoints, would
> be used to derive stats like Apdex - although the same stats could be
> defined for internal services as well, to provide the dev teams behind those
> services with a satisfaction index for their consumers.
> 
> I think the highlevel communication diagram provided in the Distributed
> Tracing UI page could act as the basis for understanding which 'services'
> and resources (if we dig further to understand databases, etc used) are used
> to deliver the total 'application'.
> 
> Having an understanding of the separate 'services' and potentially the
> resources they used, could then enable ManageIQ to build the logical
> grouping that you mention, out of those services? So to be clear, BTM could
> provide a highlevel understanding of the services and their communication
> paths (and possibly resources used), and ManageIQ could use this information
> to selectively (or as a complete set of interrelated services) present the
> user with a logical group consisting of those managed objects.
> 
> > So here if an activity on a user registration endpoint is recorded, would
> > it
> > record for each segment with app it referred to ?
> > 
> 
> Wasn't sure what you meant here, if you could give an example?
> 
> Regards
> Gary
> 
> 
> ----- Original Message -----
> > 
> > 
> > On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown at redhat.com > wrote:
> > 
> > 
> > Hi
> > 
> > I would like to discuss how best to define the concept of an Application
> > within the BTM project, how it relates to the existing concept of a
> > "Business Transaction" and how it may link in with the concept of an
> > application in Hawkular/ManageIQ in general.
> > 
> > Firstly, for those not familiar with Hawkular BTM, without configuration
> > the
> > project can capture and trace an invocation across multiple interconnected
> > services. The information can be used to provide stats on the individual
> > components used (endpoints, databases, ejbs, etc) as well as (in the next
> > version) present a graph showing the relationships between the
> > communicating
> > services.
> > 
> > The project also enables "Business Transactions" to be configured - this
> > enables a particular invocation of an endpoint to be labelled with a
> > business transaction name (which is propagated to the fragments associated
> > with the invoked services), and also perform additional processing on the
> > messages, such as extract business properties, etc. Once a "Business
> > Transaction" has been defined, it is possible to view high level stats
> > about
> > the complete "end to end" business transactions.
> > 
> > This is achieved by creating a configuration that identifies the initial
> > endpoint for the business transaction, using a regular expression, and then
> > a set of 'processors' that are used to perform various processing tasks
> > within the scope of that business transaction.
> > 
> > We now have a requirement to identify the concept of an Application, and be
> > able to present various stats about it. I believe that the Application can
> > be viewed as orthogonal to the Business Transaction concept - so an
> > Application represents the various operations that can be performed on a
> > particular architectural component, whereas the Business Transaction
> > represents a particular path through multiple Applications/Services, only
> > using a subset of the operations/endpoints supported by the Application.
> > 
> > 
> > I quite agree here, except that I would map an application to *several*
> > achitectural components (for instance N microservices).
> > Now if you have 2 logical applications (say e-commerce and brand website),
> > a
> > same architecture component may be shared (say user registration) in the 2
> > apps.
> > 
> > 
> > 
> > However the requirements are very similar - when we detect some activity on
> > a
> > particular endpoint we want to determine if it belongs to an Application,
> > in
> > the same way as we currently do with Business Transactions. And similarly,
> > once classified as being associated with an Application, we may want to do
> > some application specific processing on the data.
> > 
> > So here if an activity on a user registration endpoint is recorded, would
> > it
> > record for each segment with app it referred to ?
> > 
> > 
> > 
> > Therefore what I am considering is making the existing Business Transaction
> > Configuration generic so that it is suitable for both tasks, with a simple
> > classifier to indicate whether it relates to a Business Transaction or
> > Application.
> > 
> > This will mean that the fragments of activity being recorded and sent to
> > the
> > BTM server could now potentially have two names, one for the business
> > transaction (which is propagated across application/service boundaries) and
> > one for an application name (which is not propagated).
> > 
> > Where appropriate, the UI could then be updated to allow the user to also
> > filter information based on application - this may only make sense on the
> > APM page, but could be considered if useful elsewhere. We may also want to
> > make the current Business Transaction overview page more general to include
> > both Business Transactions and Applications, and then have a different type
> > of details page for applications.
> > 
> > The final point is how this may link into Hawkular/ManageIQ. Was thinking
> > that where possible, it would be good if a deployment event could be used
> > to
> > trigger the configuration of the Application in Hawkular BTM - especially
> > if
> > it is possible to obtain the web context for the application (or JMS
> > queue/topic), which can then be used to establish the regular expression.
> > If
> > this level of integration was possible, then no user defined configuration
> > would be necessary to capture application information using the same name
> > as
> > in Hawkular - allowing an integrated view of the information to be made
> > available.
> > 
> > Thoughts?
> > 
> > In general from the very high level view (ManageIQ), I would want to be
> > able
> > to define a logical notion of "application" for monitoring purposes, I
> > would
> > expect to be able to add "entities" to that logical view. It may just be a
> > war file (and in the case of BTM, I would likely be interested by all entry
> > points to that application) or it could be an "OpenShift Project" with all
> > its dependencies (all docker containers + everything in it), or it could be
> > a selection of MW servers...
> > 
> > In the end, the user should be able to dig into infrastructure details (and
> > he already has that, he can see details about the infrastructure: a
> > container, a host, a MW server (coming soon), a MW deployment (coming
> > soon)...) + details on Business transactions but also have that synthetic
> > view where he knows that all services that makes his online store are
> > running fine, and have a few KPI such as the Apdex for all user-facing
> > interactions, the N slowest URLs or DB requests...
> > 
> > (This definitely goes beyond BTM, and we likely need to simplify and work
> > on
> > iterations of those ideas (or better ideas))
> > 
> > That's what I dream of, as a user.
> > 
> > Thomas
> > 
> > 
> > 
> > 
> > Regards
> > Gary
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > 
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From miburman at redhat.com  Fri May 13 02:41:10 2016
From: miburman at redhat.com (Michael Burman)
Date: Fri, 13 May 2016 02:41:10 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
References: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
Message-ID: <844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>

Hi,

Based on my previous experience, I'll make an example that I would've considered important to me. This is coming from something that used to be called "SaaS" or outsourced processing or pick any other neat word of the time. The important part that I think you presented in the message is that the users of BTM could provide different information to their customers and to themselves.

So assuming the full service would have been: "we send invoice in, it gets processed to the next company, archived and it's passthrough is monitored". For internal use that means basically: "it's received by the front-end server, transferred to the back-end server, processed in the invoicing router, a copy is sent to the archiving process, one copy is sent to the next party and the invoice router waits for acknowledgement message from next party". These were very simple definitions of these two.

Thus, there are multiple transactions inside a transaction. For the customer who pays, the transaction is a single one: "how long did it take until next customer received it" and in some cases "how long did it take on the first party to process it and ship it to the next destination" (different SLA on both scenarios). And of course the most important "did all the messages get processed and delivered"

For the internal monitoring usage, there are multiple cases. How long did it take for each service to process something? How long did it take until the invoice reached the next microservice (there could be asynchronous transfers between services, lets not forget that not all communication is using something like HTTP, there are many FTP batch jobs in the world still doing the most important things in the world) ? Did the acknowledgement come from the next party inside 24 hours?

I don't like the term "service" or "application" in this case a lot, since all of these are services, yet from different perspectives the size of the service changes. However obviously we would need to call the application the smallest part for example and service the larger part. However, there are certainly micro-transactions inside the transactions which would need to be linked to get all the relevant information (the acknowledgement processing is sort of the same as the invoicing processing, including all the front-end/back-end stuff as well, but it also plays a part in the larger transaction).

So couldn't we just have tree of transaction-ids and not a definition of "service/application" ? It would scale to any depth.

  -  Micke

----- Original Message -----
From: "Gary Brown" <gbrown at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Wednesday, May 11, 2016 6:01:56 PM
Subject: [Hawkular-dev] Definition the concept of Application in Hawkular BTM

Hi

I would like to discuss how best to define the concept of an Application within the BTM project, how it relates to the existing concept of a "Business Transaction" and how it may link in with the concept of an application in Hawkular/ManageIQ in general.

Firstly, for those not familiar with Hawkular BTM, without configuration the project can capture and trace an invocation across multiple interconnected services. The information can be used to provide stats on the individual components used (endpoints, databases, ejbs, etc) as well as (in the next version) present a graph showing the relationships between the communicating services.

The project also enables "Business Transactions" to be configured - this enables a particular invocation of an endpoint to be labelled with a business transaction name (which is propagated to the fragments associated with the invoked services), and also perform additional processing on the messages, such as extract business properties, etc. Once a "Business Transaction" has been defined, it is possible to view high level stats about the complete "end to end" business transactions.

This is achieved by creating a configuration that identifies the initial endpoint for the business transaction, using a regular expression, and then a set of 'processors' that are used to perform various processing tasks within the scope of that business transaction.

We now have a requirement to identify the concept of an Application, and be able to present various stats about it. I believe that the Application can be viewed as orthogonal to the Business Transaction concept - so an Application represents the various operations that can be performed on a particular architectural component, whereas the Business Transaction represents a particular path through multiple Applications/Services, only using a subset of the operations/endpoints supported by the Application.

However the requirements are very similar - when we detect some activity on a particular endpoint we want to determine if it belongs to an Application, in the same way as we currently do with Business Transactions. And similarly, once classified as being associated with an Application, we may want to do some application specific processing on the data.

Therefore what I am considering is making the existing Business Transaction Configuration generic so that it is suitable for both tasks, with a simple classifier to indicate whether it relates to a Business Transaction or Application.

This will mean that the fragments of activity being recorded and sent to the BTM server could now potentially have two names, one for the business transaction (which is propagated across application/service boundaries) and one for an application name (which is not propagated).

Where appropriate, the UI could then be updated to allow the user to also filter information based on application - this may only make sense on the APM page, but could be considered if useful elsewhere. We may also want to make the current Business Transaction overview page more general to include both Business Transactions and Applications, and then have a different type of details page for applications.

The final point is how this may link into Hawkular/ManageIQ. Was thinking that where possible, it would be good if a deployment event could be used to trigger the configuration of the Application in Hawkular BTM - especially if it is possible to obtain the web context for the application (or JMS queue/topic), which can then be used to establish the regular expression. If this level of integration was possible, then no user defined configuration would be necessary to capture application information using the same name as in Hawkular - allowing an integrated view of the information to be made available.

Thoughts?

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 13 03:16:04 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Fri, 13 May 2016 09:16:04 +0200
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
References: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
Message-ID: <d45ee226-6e8c-fa58-4e51-3223864fb5f6@redhat.com>

On 13.05.2016 08:41, Michael Burman wrote:
> So couldn't we just have tree of transaction-ids and not a definition of "service/application" ? It would scale to any depth.

Adding Stefan's tagging feature on top of this, there could be a nice 
feature of grouping transactions by affinity based on tags. So, 
service/application is something that could be defined by a tag or a 
collection of tags.

- Juca.

From gbrown at redhat.com  Fri May 13 03:47:49 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 13 May 2016 03:47:49 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
References: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
Message-ID: <1374897837.48392395.1463125669661.JavaMail.zimbra@redhat.com>

Hi Micke

Thanks for the detailed response.

I agree that we may want to model a hierarchy of business transactions, but each transaction is likely to extend across multiple 'services' - just considering a micro-service architecture for now. So it would be good to be able to obtain information about those shared sub-business transactions in the context of the higher level transactions.

Having said that, I believe we still need to be able to identify the individual component parts of the architecture, whether services or resources, and from an operational perspective be able to provide stats that are independent of the particular business transaction instances - although those stats may need to be filtered to narrow in on specific criteria, which may include focusing on a particular business transaction.

So having the ability to decompose the overall business transaction into a hierarchy of sub transactions that are relevant to different parts of the organisation would be a great idea.

Regards
Gary

----- Original Message -----
> Hi,
> 
> Based on my previous experience, I'll make an example that I would've
> considered important to me. This is coming from something that used to be
> called "SaaS" or outsourced processing or pick any other neat word of the
> time. The important part that I think you presented in the message is that
> the users of BTM could provide different information to their customers and
> to themselves.
> 
> So assuming the full service would have been: "we send invoice in, it gets
> processed to the next company, archived and it's passthrough is monitored".
> For internal use that means basically: "it's received by the front-end
> server, transferred to the back-end server, processed in the invoicing
> router, a copy is sent to the archiving process, one copy is sent to the
> next party and the invoice router waits for acknowledgement message from
> next party". These were very simple definitions of these two.
> 
> Thus, there are multiple transactions inside a transaction. For the customer
> who pays, the transaction is a single one: "how long did it take until next
> customer received it" and in some cases "how long did it take on the first
> party to process it and ship it to the next destination" (different SLA on
> both scenarios). And of course the most important "did all the messages get
> processed and delivered"
> 
> For the internal monitoring usage, there are multiple cases. How long did it
> take for each service to process something? How long did it take until the
> invoice reached the next microservice (there could be asynchronous transfers
> between services, lets not forget that not all communication is using
> something like HTTP, there are many FTP batch jobs in the world still doing
> the most important things in the world) ? Did the acknowledgement come from
> the next party inside 24 hours?
> 
> I don't like the term "service" or "application" in this case a lot, since
> all of these are services, yet from different perspectives the size of the
> service changes. However obviously we would need to call the application the
> smallest part for example and service the larger part. However, there are
> certainly micro-transactions inside the transactions which would need to be
> linked to get all the relevant information (the acknowledgement processing
> is sort of the same as the invoicing processing, including all the
> front-end/back-end stuff as well, but it also plays a part in the larger
> transaction).
> 
> So couldn't we just have tree of transaction-ids and not a definition of
> "service/application" ? It would scale to any depth.
> 
>   -  Micke
> 
> ----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 11, 2016 6:01:56 PM
> Subject: [Hawkular-dev] Definition the concept of Application in Hawkular BTM
> 
> Hi
> 
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
> 
> Firstly, for those not familiar with Hawkular BTM, without configuration the
> project can capture and trace an invocation across multiple interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the communicating
> services.
> 
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats about
> the complete "end to end" business transactions.
> 
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
> 
> We now have a requirement to identify the concept of an Application, and be
> able to present various stats about it. I believe that the Application can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
> 
> However the requirements are very similar - when we detect some activity on a
> particular endpoint we want to determine if it belongs to an Application, in
> the same way as we currently do with Business Transactions. And similarly,
> once classified as being associated with an Application, we may want to do
> some application specific processing on the data.
> 
> Therefore what I am considering is making the existing Business Transaction
> Configuration generic so that it is suitable for both tasks, with a simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
> 
> This will mean that the fragments of activity being recorded and sent to the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
> 
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
> 
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used to
> trigger the configuration of the Application in Hawkular BTM - especially if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular expression. If
> this level of integration was possible, then no user defined configuration
> would be necessary to capture application information using the same name as
> in Hawkular - allowing an integrated view of the information to be made
> available.
> 
> Thoughts?
> 
> Regards
> Gary
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From gbrown at redhat.com  Fri May 13 03:50:35 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 13 May 2016 03:50:35 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <d45ee226-6e8c-fa58-4e51-3223864fb5f6@redhat.com>
References: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
	<d45ee226-6e8c-fa58-4e51-3223864fb5f6@redhat.com>
Message-ID: <749440084.48392496.1463125835883.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 13.05.2016 08:41, Michael Burman wrote:
> > So couldn't we just have tree of transaction-ids and not a definition of
> > "service/application" ? It would scale to any depth.
> 
> Adding Stefan's tagging feature on top of this, there could be a nice
> feature of grouping transactions by affinity based on tags. So,
> service/application is something that could be defined by a tag or a
> collection of tags.

A business transaction is something that spans across multiple services/applications/resources and provides the context for a particular use of these shared components. There is the ability to 'tag' fragments captured (associated with a business txn or not) so this type of grouping is possible now.

Regards
Gary

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

From theute at redhat.com  Fri May 13 04:02:58 2016
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 May 2016 10:02:58 +0200
Subject: [Hawkular-dev] Definition the concept of Application in
	Hawkular BTM
In-Reply-To: <844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
References: <1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<844875850.91077237.1463121670101.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=Mpg_os0K3o9NqKGpRCaxyhkefwy3z0iS1uXRnvO-hAM2w@mail.gmail.com>

The "Application" is definitely first a user notion, I am personally
interested to think about the user facing features (in the context of
Application Performance Management/Monitoring) of what we can provide.

So far we have a good understanding of the individual metrics we can track
and how to track those:
    - Infrastructure metrics (CPU/Memory of a host)
    - Our dear MW metrics (Number of JMS messages sent/received, servlet
response time...)
    - Business Transaction time split into "segments
    -...

But for the user of the monitoring tools, it's hard to make sense of those
details (but we definitely need them, and the user may want to dig into
those details).

I just accidentally found this article:
http://apmdigest.com/the-anatomy-of-apm-4-foundational-elements-to-a-successful-strategy
"The translation of IT metrics into business meaning (value) is what APM is
all about."
I couldn't agree more :)

I've asked Gary/Pavol to look into the Apdex, it's a relatively interesting
index to measure the user satisfaction, it's "simple" (only based on
response time) but still give 1 indicator that can be useful to quickly
assess the health of an application. It may or may not belong to the BTM
project though.

Thomas



On Fri, May 13, 2016 at 8:41 AM, Michael Burman <miburman at redhat.com> wrote:

> Hi,
>
> Based on my previous experience, I'll make an example that I would've
> considered important to me. This is coming from something that used to be
> called "SaaS" or outsourced processing or pick any other neat word of the
> time. The important part that I think you presented in the message is that
> the users of BTM could provide different information to their customers and
> to themselves.
>
> So assuming the full service would have been: "we send invoice in, it gets
> processed to the next company, archived and it's passthrough is monitored".
> For internal use that means basically: "it's received by the front-end
> server, transferred to the back-end server, processed in the invoicing
> router, a copy is sent to the archiving process, one copy is sent to the
> next party and the invoice router waits for acknowledgement message from
> next party". These were very simple definitions of these two.
>
> Thus, there are multiple transactions inside a transaction. For the
> customer who pays, the transaction is a single one: "how long did it take
> until next customer received it" and in some cases "how long did it take on
> the first party to process it and ship it to the next destination"
> (different SLA on both scenarios). And of course the most important "did
> all the messages get processed and delivered"
>
> For the internal monitoring usage, there are multiple cases. How long did
> it take for each service to process something? How long did it take until
> the invoice reached the next microservice (there could be asynchronous
> transfers between services, lets not forget that not all communication is
> using something like HTTP, there are many FTP batch jobs in the world still
> doing the most important things in the world) ? Did the acknowledgement
> come from the next party inside 24 hours?
>
> I don't like the term "service" or "application" in this case a lot, since
> all of these are services, yet from different perspectives the size of the
> service changes. However obviously we would need to call the application
> the smallest part for example and service the larger part. However, there
> are certainly micro-transactions inside the transactions which would need
> to be linked to get all the relevant information (the acknowledgement
> processing is sort of the same as the invoicing processing, including all
> the front-end/back-end stuff as well, but it also plays a part in the
> larger transaction).
>
> So couldn't we just have tree of transaction-ids and not a definition of
> "service/application" ? It would scale to any depth.
>
>   -  Micke
>
> ----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> Sent: Wednesday, May 11, 2016 6:01:56 PM
> Subject: [Hawkular-dev] Definition the concept of Application in Hawkular
> BTM
>
> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration
> the project can capture and trace an invocation across multiple
> interconnected services. The information can be used to provide stats on
> the individual components used (endpoints, databases, ejbs, etc) as well as
> (in the next version) present a graph showing the relationships between the
> communicating services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats
> about the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and
> be able to present various stats about it. I believe that the Application
> can be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>
> However the requirements are very similar - when we detect some activity
> on a particular endpoint we want to determine if it belongs to an
> Application, in the same way as we currently do with Business Transactions.
> And similarly, once classified as being associated with an Application, we
> may want to do some application specific processing on the data.
>
> Therefore what I am considering is making the existing Business
> Transaction Configuration generic so that it is suitable for both tasks,
> with a simple classifier to indicate whether it relates to a Business
> Transaction or Application.
>
> This will mean that the fragments of activity being recorded and sent to
> the BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used
> to trigger the configuration of the Application in Hawkular BTM -
> especially if it is possible to obtain the web context for the application
> (or JMS queue/topic), which can then be used to establish the regular
> expression. If this level of integration was possible, then no user defined
> configuration would be necessary to capture application information using
> the same name as in Hawkular - allowing an integrated view of the
> information to be made available.
>
> Thoughts?
>
> Regards
> Gary
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160513/05f32607/attachment-0001.html 

From hrupp at redhat.com  Fri May 13 05:14:37 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 May 2016 11:14:37 +0200
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
	<692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
Message-ID: <DE7C734B-DEBB-4F98-9444-B1DADD736BD4@redhat.com>

On 12 May 2016, at 14:47, Gary Brown wrote:
> So possibly rather than application, it should be termed "service"? 
> which would actually match the microservices world better anyway.

An application is in my understanding composed of multiple services.
Those can be micro services calling other micro services, external 
providers
or things just like a database. Some may be provided by multiple micro 
services
running (or being deployed) in parallel on several machines.

I don't think the concept of an application in the BTM world is much 
different
from what we always said.

A user first wants to know "is my application doing all right?". And if 
not,
she wants to zoom in to figure out where bottlenecks are.
The other direction is true as well: the user sees a machine clamped at 
100%
cpu and wants to see what is creating the load, which service and 
ultimately
which application (and if only for billing purposes).


From gbrown at redhat.com  Fri May 13 06:04:39 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 13 May 2016 06:04:39 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application in
 Hawkular BTM
In-Reply-To: <DE7C734B-DEBB-4F98-9444-B1DADD736BD4@redhat.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
	<692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
	<DE7C734B-DEBB-4F98-9444-B1DADD736BD4@redhat.com>
Message-ID: <257562886.48410489.1463133879010.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 12 May 2016, at 14:47, Gary Brown wrote:
> > So possibly rather than application, it should be termed "service"?
> > which would actually match the microservices world better anyway.
> 
> An application is in my understanding composed of multiple services.
> Those can be micro services calling other micro services, external
> providers
> or things just like a database. Some may be provided by multiple micro
> services
> running (or being deployed) in parallel on several machines.

+1

> 
> I don't think the concept of an application in the BTM world is much
> different
> from what we always said.
> 
> A user first wants to know "is my application doing all right?". And if
> not,
> she wants to zoom in to figure out where bottlenecks are.
> The other direction is true as well: the user sees a machine clamped at
> 100%
> cpu and wants to see what is creating the load, which service and
> ultimately
> which application (and if only for billing purposes).

I think we need to build up a list of use cases that we wish to support with the integration of MiQ and BTM.

But as outlined in your scenarios, it will be important to have a common concept of services and resources across the two. At the moment BTM only understands activities triggered at endpoints, so this needs to be linked to these static notions of service and resource (e.g. database).

Regards
Gary

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

From hrupp at redhat.com  Fri May 13 06:09:31 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 May 2016 12:09:31 +0200
Subject: [Hawkular-dev] Composition of the community distribution /
	Naming
In-Reply-To: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
Message-ID: <FFA725C7-0D26-474B-B6A6-A5A0439C1E3B@redhat.com>

On 4 May 2016, at 16:05, Heiko W.Rupp wrote:
> Technical areas for discussion in the community-release (Hawkular-aio)
> are:
>
> * Url handling / pinger / avail-creator
>
> Probably not needed going forward

Ok, will be removed.
See https://issues.jboss.org/browse/HAWKULAR-1077

> * UI/ Alert Center
>
> Needed in a generic way - i.e. allow to see fired alerts/events and to
> define
> generic triggers. For the display it will be enough to iterate over the
> Event/Alert
> object returned from the REST-api and to display the key/value pairs.
>
> * UI/ Explorer
>
> This needs to stay and we need to fix some smaller bugs to allow
> for inventory browsing and display of metric charts
>
> * Accounts / Multi-tenancy
>
> I still see this as a great value and unique selling point, but also see
> the effort
> of maintaining this (and the issues we have with KC and hostnames).
> It may be good to also remove this

This is addressed by the JAAS work that is going on and
the 'hawkular' default tenant. Juca sent email about that
some days ago.

> * Embedded Cassandra
>
> I think this needs to be present in the community-distribution
>
> * UI/Agent installer
>
> Not sure if this is still needed or if we would just put the
> agent+installer
> into a directory of the zip for the users to take the installer from
> there.

Opinions? For hawkular-services, there is no UI, so there will be
no UI screen there. I think for the full/community distribution
just putting that in a directory of the downloaded .zip is enough.


> * Default user
>
> The Hawkular-aio download should feature a default user jdoe/password
> which is also set in the embedded agent.

And also being prepopulated with the default tenant.

From hrupp at redhat.com  Fri May 13 06:12:19 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 May 2016 12:12:19 +0200
Subject: [Hawkular-dev] Composition of the community distribution /
	Naming
In-Reply-To: <FFA725C7-0D26-474B-B6A6-A5A0439C1E3B@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<FFA725C7-0D26-474B-B6A6-A5A0439C1E3B@redhat.com>
Message-ID: <A0610DF2-35C9-47F9-99E5-BD7EFF5D7D47@redhat.com>

And of course I forgot the elephant in the room:

removal of the app-server tab and its special knowledge.

On 13 May 2016, at 12:09, Heiko W.Rupp wrote:

> On 4 May 2016, at 16:05, Heiko W.Rupp wrote:
>> Technical areas for discussion in the community-release 
>> (Hawkular-aio)
>> are:
>>
>> * Url handling / pinger / avail-creator
>>
>> Probably not needed going forward
>
> Ok, will be removed.
> See https://issues.jboss.org/browse/HAWKULAR-1077
>
>> * UI/ Alert Center
>>
>> Needed in a generic way - i.e. allow to see fired alerts/events and 
>> to
>> define
>> generic triggers. For the display it will be enough to iterate over 
>> the
>> Event/Alert
>> object returned from the REST-api and to display the key/value pairs.
>>
>> * UI/ Explorer
>>
>> This needs to stay and we need to fix some smaller bugs to allow
>> for inventory browsing and display of metric charts
>>
>> * Accounts / Multi-tenancy
>>
>> I still see this as a great value and unique selling point, but also 
>> see
>> the effort
>> of maintaining this (and the issues we have with KC and hostnames).
>> It may be good to also remove this
>
> This is addressed by the JAAS work that is going on and
> the 'hawkular' default tenant. Juca sent email about that
> some days ago.
>
>> * Embedded Cassandra
>>
>> I think this needs to be present in the community-distribution
>>
>> * UI/Agent installer
>>
>> Not sure if this is still needed or if we would just put the
>> agent+installer
>> into a directory of the zip for the users to take the installer from
>> there.
>
> Opinions? For hawkular-services, there is no UI, so there will be
> no UI screen there. I think for the full/community distribution
> just putting that in a directory of the downloaded .zip is enough.
>
>
>> * Default user
>>
>> The Hawkular-aio download should feature a default user jdoe/password
>> which is also set in the embedded agent.
>
> And also being prepopulated with the default tenant.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


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

From ppalaga at redhat.com  Fri May 13 06:14:53 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 13 May 2016 12:14:53 +0200
Subject: [Hawkular-dev] Hawkular Organization - Repositories
In-Reply-To: <CADt-fV8DLBJoX1UOu+Kx2dwHsYTqzYKPctQ2t52vmapnVG1wfw@mail.gmail.com>
References: <CADt-fV8DLBJoX1UOu+Kx2dwHsYTqzYKPctQ2t52vmapnVG1wfw@mail.gmail.com>
Message-ID: <5735A91D.2080807@redhat.com>

Hi Stefan, hawkular-command-gateway is getting obsolete now that [1] was 
merged recently, cmdgw thus having been moved to Commons. 
hawkular-command-gateway was not marked as obsolete yet, I'd do so after 
releasing Commons. -- P

[1] https://github.com/hawkular/hawkular-commons/pull/63

On 2016-05-12 01:28, Stefan Negrea wrote:
> Hello Everybody,
>
> As a continuation of the previous discussions regarding the Hawkular
> reorganization, I created a spreadsheet with all repositories. The goal
> is to get a clear idea on the prospect of each repository.
>
> Below the red line are all the repositories no longer relevant, their
> future will be decided at the end of this process. If I missed something
> no longer needed, please move it below the red line with a note.
>
> Above the red line are all the repositories still relevant. Please add
> comments if you think there should be some consolidation (merging repos)
> or if it might become irrelevant/obsolete soon.
>
>
> Document:
> https://docs.google.com/a/redhat.com/spreadsheets/d/1IzoBP9glz3GgkcwTRF6cobQCylUaZFLhFgqxRfuQCn0/edit?usp=sharing
>
>
> 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 gbrown at redhat.com  Fri May 13 06:24:33 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 13 May 2016 06:24:33 -0400 (EDT)
Subject: [Hawkular-dev] Definition the concept of Application
	in	Hawkular BTM
In-Reply-To: <CADt-fV-UvNJCeFcYvKt-GVnPi=U7PLViGn0J_b1q=FxhEQuVKA@mail.gmail.com>
References: <210436070.47993086.1462977503917.JavaMail.zimbra@redhat.com>
	<1625095859.47999612.1462978916907.JavaMail.zimbra@redhat.com>
	<CA+aN=MrAFv8y6JNK7exiHTtLvOa5WM+PG8kmdV5VJhS=ZDYW5w@mail.gmail.com>
	<692767571.48189808.1463057266537.JavaMail.zimbra@redhat.com>
	<CADt-fV-UvNJCeFcYvKt-GVnPi=U7PLViGn0J_b1q=FxhEQuVKA@mail.gmail.com>
Message-ID: <1398289538.48411416.1463135073378.JavaMail.zimbra@redhat.com>

Hi Stefan

On further reflection, I think your suggestion of using properties/tags is better. Will help to simplify the UI and enable greater flexibility in how the fragments are categorised.

Regards
Gary


----- Original Message -----
> Hello,
> 
> What was described in the original email sounded to me like tagging. A
> transaction fragment stored in BTM could be tagged with an arbitrarily
> number of tags. Here is an example { application: myapp, service:
> superservice, datacenter: east}. And then the API needs to allow users to
> query data based on tags and query the actual tag values.
> 
> So rather than expanding the design to cover just one other single concept
> (application) the design with tags is generic and flexible.
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> 
> On Thu, May 12, 2016 at 7:47 AM, Gary Brown < gbrown at redhat.com > wrote:
> 
> 
> Hi Thomas
> 
> I think possibly there are different concepts here, so I need to clarify -
> the one I was trying to describe is to capture the individual services,
> which may be user facing, and would essentially map onto the individual
> services (in a micro-services world).
> 
> So possibly rather than application, it should be termed "service"? which
> would actually match the microservices world better anyway.
> 
> This service concept, especially in the case of user facing endpoints, would
> be used to derive stats like Apdex - although the same stats could be
> defined for internal services as well, to provide the dev teams behind those
> services with a satisfaction index for their consumers.
> 
> I think the highlevel communication diagram provided in the Distributed
> Tracing UI page could act as the basis for understanding which 'services'
> and resources (if we dig further to understand databases, etc used) are used
> to deliver the total 'application'.
> 
> Having an understanding of the separate 'services' and potentially the
> resources they used, could then enable ManageIQ to build the logical
> grouping that you mention, out of those services? So to be clear, BTM could
> provide a highlevel understanding of the services and their communication
> paths (and possibly resources used), and ManageIQ could use this information
> to selectively (or as a complete set of interrelated services) present the
> user with a logical group consisting of those managed objects.
> 
> > So here if an activity on a user registration endpoint is recorded, would
> > it
> > record for each segment with app it referred to ?
> > 
> 
> Wasn't sure what you meant here, if you could give an example?
> 
> Regards
> Gary
> 
> 
> ----- Original Message -----
> > 
> > 
> > On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown at redhat.com > wrote:
> > 
> > 
> > Hi
> > 
> > I would like to discuss how best to define the concept of an Application
> > within the BTM project, how it relates to the existing concept of a
> > "Business Transaction" and how it may link in with the concept of an
> > application in Hawkular/ManageIQ in general.
> > 
> > Firstly, for those not familiar with Hawkular BTM, without configuration
> > the
> > project can capture and trace an invocation across multiple interconnected
> > services. The information can be used to provide stats on the individual
> > components used (endpoints, databases, ejbs, etc) as well as (in the next
> > version) present a graph showing the relationships between the
> > communicating
> > services.
> > 
> > The project also enables "Business Transactions" to be configured - this
> > enables a particular invocation of an endpoint to be labelled with a
> > business transaction name (which is propagated to the fragments associated
> > with the invoked services), and also perform additional processing on the
> > messages, such as extract business properties, etc. Once a "Business
> > Transaction" has been defined, it is possible to view high level stats
> > about
> > the complete "end to end" business transactions.
> > 
> > This is achieved by creating a configuration that identifies the initial
> > endpoint for the business transaction, using a regular expression, and then
> > a set of 'processors' that are used to perform various processing tasks
> > within the scope of that business transaction.
> > 
> > We now have a requirement to identify the concept of an Application, and be
> > able to present various stats about it. I believe that the Application can
> > be viewed as orthogonal to the Business Transaction concept - so an
> > Application represents the various operations that can be performed on a
> > particular architectural component, whereas the Business Transaction
> > represents a particular path through multiple Applications/Services, only
> > using a subset of the operations/endpoints supported by the Application.
> > 
> > 
> > I quite agree here, except that I would map an application to *several*
> > achitectural components (for instance N microservices).
> > Now if you have 2 logical applications (say e-commerce and brand website),
> > a
> > same architecture component may be shared (say user registration) in the 2
> > apps.
> > 
> > 
> > 
> > However the requirements are very similar - when we detect some activity on
> > a
> > particular endpoint we want to determine if it belongs to an Application,
> > in
> > the same way as we currently do with Business Transactions. And similarly,
> > once classified as being associated with an Application, we may want to do
> > some application specific processing on the data.
> > 
> > So here if an activity on a user registration endpoint is recorded, would
> > it
> > record for each segment with app it referred to ?
> > 
> > 
> > 
> > Therefore what I am considering is making the existing Business Transaction
> > Configuration generic so that it is suitable for both tasks, with a simple
> > classifier to indicate whether it relates to a Business Transaction or
> > Application.
> > 
> > This will mean that the fragments of activity being recorded and sent to
> > the
> > BTM server could now potentially have two names, one for the business
> > transaction (which is propagated across application/service boundaries) and
> > one for an application name (which is not propagated).
> > 
> > Where appropriate, the UI could then be updated to allow the user to also
> > filter information based on application - this may only make sense on the
> > APM page, but could be considered if useful elsewhere. We may also want to
> > make the current Business Transaction overview page more general to include
> > both Business Transactions and Applications, and then have a different type
> > of details page for applications.
> > 
> > The final point is how this may link into Hawkular/ManageIQ. Was thinking
> > that where possible, it would be good if a deployment event could be used
> > to
> > trigger the configuration of the Application in Hawkular BTM - especially
> > if
> > it is possible to obtain the web context for the application (or JMS
> > queue/topic), which can then be used to establish the regular expression.
> > If
> > this level of integration was possible, then no user defined configuration
> > would be necessary to capture application information using the same name
> > as
> > in Hawkular - allowing an integrated view of the information to be made
> > available.
> > 
> > Thoughts?
> > 
> > In general from the very high level view (ManageIQ), I would want to be
> > able
> > to define a logical notion of "application" for monitoring purposes, I
> > would
> > expect to be able to add "entities" to that logical view. It may just be a
> > war file (and in the case of BTM, I would likely be interested by all entry
> > points to that application) or it could be an "OpenShift Project" with all
> > its dependencies (all docker containers + everything in it), or it could be
> > a selection of MW servers...
> > 
> > In the end, the user should be able to dig into infrastructure details (and
> > he already has that, he can see details about the infrastructure: a
> > container, a host, a MW server (coming soon), a MW deployment (coming
> > soon)...) + details on Business transactions but also have that synthetic
> > view where he knows that all services that makes his online store are
> > running fine, and have a few KPI such as the Apdex for all user-facing
> > interactions, the N slowest URLs or DB requests...
> > 
> > (This definitely goes beyond BTM, and we likely need to simplify and work
> > on
> > iterations of those ideas (or better ideas))
> > 
> > That's what I dream of, as a user.
> > 
> > Thomas
> > 
> > 
> > 
> > 
> > Regards
> > Gary
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > 
> > 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From theute at redhat.com  Fri May 13 06:32:16 2016
From: theute at redhat.com (Thomas Heute)
Date: Fri, 13 May 2016 12:32:16 +0200
Subject: [Hawkular-dev] Composition of the community distribution /
	Naming
In-Reply-To: <FFA725C7-0D26-474B-B6A6-A5A0439C1E3B@redhat.com>
References: <A0D1F65E-172D-4D24-97B8-B9FE2D44839E@redhat.com>
	<FFA725C7-0D26-474B-B6A6-A5A0439C1E3B@redhat.com>
Message-ID: <CA+aN=Mp4dMOAabd_rb3EOX5gZ2etWhK0z_p=JXsUNeXRTZW0iQ@mail.gmail.com>

On Fri, May 13, 2016 at 12:09 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:

> On 4 May 2016, at 16:05, Heiko W.Rupp wrote:
> > Technical areas for discussion in the community-release (Hawkular-aio)
> > are:
> >
> > * Url handling / pinger / avail-creator
> >
> > Probably not needed going forward
>
> Ok, will be removed.
> See https://issues.jboss.org/browse/HAWKULAR-1077
>
> > * UI/ Alert Center
> >
> > Needed in a generic way - i.e. allow to see fired alerts/events and to
> > define
> > generic triggers. For the display it will be enough to iterate over the
> > Event/Alert
> > object returned from the REST-api and to display the key/value pairs.
> >
> > * UI/ Explorer
> >
> > This needs to stay and we need to fix some smaller bugs to allow
> > for inventory browsing and display of metric charts
> >
> > * Accounts / Multi-tenancy
> >
> > I still see this as a great value and unique selling point, but also see
> > the effort
> > of maintaining this (and the issues we have with KC and hostnames).
> > It may be good to also remove this
>
> This is addressed by the JAAS work that is going on and
> the 'hawkular' default tenant. Juca sent email about that
> some days ago.
>
> > * Embedded Cassandra
> >
> > I think this needs to be present in the community-distribution
> >
> > * UI/Agent installer
> >
> > Not sure if this is still needed or if we would just put the
> > agent+installer
> > into a directory of the zip for the users to take the installer from
> > there.
>
> Opinions? For hawkular-services, there is no UI, so there will be
> no UI screen there. I think for the full/community distribution
> just putting that in a directory of the downloaded .zip is enough.
>

I'm not sure we need to put it there anyway, since this is MW specific
unlike everything else.

That said I guess it makes the release process easier ?

Thomas





>
>
> > * Default user
> >
> > The Hawkular-aio download should feature a default user jdoe/password
> > which is also set in the embedded agent.
>
> And also being prepopulated with the default tenant.
> _______________________________________________
> 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/20160513/8de1e1f4/attachment.html 

From hrupp at redhat.com  Fri May 13 10:05:02 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 13 May 2016 16:05:02 +0200
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <7B84C854-E348-4427-977C-E5EB37C6A128@redhat.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
	<572A54C4.9010804@redhat.com>
	<7B84C854-E348-4427-977C-E5EB37C6A128@redhat.com>
Message-ID: <EF9BCC1D-B18C-4FE6-A834-30AF4DEF0A96@redhat.com>

Also a belated congrats from me.  :-)


> Yes, Cassalog can be used in other projects. It is not dependent on 
> Hawkular Metrics in any way. There are things that we discussed and 
> decided in

Would it make sense to move that to commons then?

From jsanda at redhat.com  Fri May 13 10:18:35 2016
From: jsanda at redhat.com (John Sanda)
Date: Fri, 13 May 2016 10:18:35 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <EF9BCC1D-B18C-4FE6-A834-30AF4DEF0A96@redhat.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
	<572A54C4.9010804@redhat.com>
	<7B84C854-E348-4427-977C-E5EB37C6A128@redhat.com>
	<EF9BCC1D-B18C-4FE6-A834-30AF4DEF0A96@redhat.com>
Message-ID: <D2629B5D-95D1-4DB1-88B5-56D7A47788D0@redhat.com>


> On May 13, 2016, at 10:05 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> Also a belated congrats from me.  :-)
> 
> 
>> Yes, Cassalog can be used in other projects. It is not dependent on 
>> Hawkular Metrics in any way. There are things that we discussed and 
>> decided in
> 
> Would it make sense to move that to commons then?

I don?t think so. When I first started working it, that?s what I did. I chatted with Peter to see what he thought. He thought and I agreed that a separate repo would be better. 

From jsanda at redhat.com  Fri May 13 10:20:51 2016
From: jsanda at redhat.com (John Sanda)
Date: Fri, 13 May 2016 10:20:51 -0400
Subject: [Hawkular-dev] Hawkular Metrics 0.15.0 - Release
In-Reply-To: <D2629B5D-95D1-4DB1-88B5-56D7A47788D0@redhat.com>
References: <CADt-fV9pE+g8vn70CrBEvJaHdoRO3Eie-6MywP6LiYVxschUrw@mail.gmail.com>
	<572A54C4.9010804@redhat.com>
	<7B84C854-E348-4427-977C-E5EB37C6A128@redhat.com>
	<EF9BCC1D-B18C-4FE6-A834-30AF4DEF0A96@redhat.com>
	<D2629B5D-95D1-4DB1-88B5-56D7A47788D0@redhat.com>
Message-ID: <62503E77-D69A-4302-8F61-056BE0138640@redhat.com>


> On May 13, 2016, at 10:18 AM, John Sanda <jsanda at redhat.com> wrote:
> 
> 
>> On May 13, 2016, at 10:05 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>> 
>> Also a belated congrats from me.  :-)
>> 
>> 
>>> Yes, Cassalog can be used in other projects. It is not dependent on 
>>> Hawkular Metrics in any way. There are things that we discussed and 
>>> decided in
>> 
>> Would it make sense to move that to commons then?
> 
> I don?t think so. When I first started working it, that?s what I did. I chatted with Peter to see what he thought. He thought and I agreed that a separate repo would be better.

I would put the rx-java-driver module[1] in this category as well. It is a more general purpose library that could easily be used outside of hawkular. 

[1] https://github.com/hawkular/hawkular-metrics/tree/master/core/rx-java-driver <https://github.com/hawkular/hawkular-metrics/tree/master/core/rx-java-driver>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160513/f64bf138/attachment.html 

From auszon3 at gmail.com  Tue May 17 06:45:51 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Tue, 17 May 2016 10:45:51 +0000
Subject: [Hawkular-dev] [GSoC] Status update from Austin
In-Reply-To: <CAJ5TdT=D=TKJFE3bL1JVi19OYWdTXDLuWFHMxJZGyzv4v2tr=w@mail.gmail.com>
References: <CAJ5TdT=D=TKJFE3bL1JVi19OYWdTXDLuWFHMxJZGyzv4v2tr=w@mail.gmail.com>
Message-ID: <CAJ5TdTnky9h=0KEuZLj5yQc=0u1o39V=J1fMr=HQU1FoFPMPEg@mail.gmail.com>

Issue merged https://github.com/vert-x3/vertx-hawkular-metrics/pull/20.
Trying to run hawkfx(inventory explorer) and hawkular.

On Tue, May 3, 2016 at 6:52 PM Austin Kuo <auszon3 at gmail.com> wrote:

> Working on:
> vertx-hawkular-mertics: https://github.com/vert-x3/vertx-hawkular-metrics
> Trying to enable it to send designated metrics with PR #20
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160517/ece436a2/attachment.html 

From jshaughn at redhat.com  Thu May 19 13:22:58 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Thu, 19 May 2016 13:22:58 -0400
Subject: [Hawkular-dev] Hawkular Alerting 1.1.0.Final Released
Message-ID: <573DF672.2080105@redhat.com>


We're happy to announce version 1.1.0.Final of Hawkular Alerting!

Hawkular Alerting is an open source, scalable alerting and eventing tool 
for monitoring your Data Center or anything else. Out of the box you get:

  * A robust REST API
  * Complex Alerting
  * Powerful Event Handling
  * Pluggable Action Handlers with many built-in (e-mail, SMS, etc)
  * Alert Lifecycle (Ack, Resolved, etc)
  * Flexible Deployment, either standalone or as part of Hawkular
  * And Much More


What's new:

  * Update Cassandra Support
      o [HWKALERTS-142] - Upgrade to Cassandra 3.x
  * Use Hawkular-Tenant HTTP Header in both Hawkular and Standalone
    deployments
      o   [HWKALERTS-145] - Make hawkular profile independent of
        Hawkular Accounts
  * Improve Action validation
      o [HWKALERTS-139] - Action creation should warn/fail on unknown
        properties
      o [HWKALERTS-140] - Validate actions definitions against plugins
        deployed
      o [HWKALERTS-141] - NPE when plugin is not present
      o [HWKALERTS-137] - Get action plugin for unknown plugin should
        return 404
      o [HWKALERTS-138] - Action creation for unknown plugin should not
        return 200
  * Group Trigger Fixes
      o [HWKALERTS-147] - Unable to delete member trigger
  * Documentation Generation Fixes
      o [HWKALERTS-143] - Swagger annotations broken
      o [HWKALERTS-144] - REST API doc not properly rendered

Links:

  * Jira release-notes
      o https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12329652
  * Hawkular
      o http://www.hawkular.org/
  * Hawkular Alerting
      o http://www.hawkular.org/docs/dev/alerts.html
  * Hawkular Alerting Rest API
      o http://www.hawkular.org/docs/rest/rest-alerts.html
  * GitHub
      o https://github.com/hawkular/hawkular-alerts
  * Examples
      o https://github.com/hawkular/hawkular-alerts/tree/master/examples


Hawkular Alerts Team
    Jay Shaughnessy (jshaughn at redhat.com)
    Lucas Ponce (lponce at redhat.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160519/7ab63837/attachment-0001.html 

From theute at redhat.com  Thu May 19 14:36:50 2016
From: theute at redhat.com (Thomas Heute)
Date: Thu, 19 May 2016 20:36:50 +0200
Subject: [Hawkular-dev] Hawkular Alerting 1.1.0.Final Released
In-Reply-To: <573DF672.2080105@redhat.com>
References: <573DF672.2080105@redhat.com>
Message-ID: <CA+aN=MrqFE+Ud7vBaV6jEGU4kye7o9rqJCLn+zo79TbksTmkpA@mail.gmail.com>

Congrats !

On Thu, May 19, 2016 at 7:22 PM, Jay Shaughnessy <jshaughn at redhat.com>
wrote:

>
> We're happy to announce version 1.1.0.Final of Hawkular Alerting!
>
> Hawkular Alerting is an open source, scalable alerting and eventing tool
> for monitoring your Data Center or anything else. Out of the box you get:
>
>    - A robust REST API
>    - Complex Alerting
>    - Powerful Event Handling
>    - Pluggable Action Handlers with many built-in (e-mail, SMS, etc)
>    - Alert Lifecycle (Ack, Resolved, etc)
>    - Flexible Deployment, either standalone or as part of Hawkular
>    - And Much More
>
>
> What's new:
>
>    - Update Cassandra Support
>       - [HWKALERTS-142] - Upgrade to Cassandra 3.x
>    - Use Hawkular-Tenant HTTP Header in both Hawkular and Standalone
>    deployments
>       -  [HWKALERTS-145] - Make hawkular profile independent of Hawkular
>       Accounts
>    - Improve Action validation
>       - [HWKALERTS-139] - Action creation should warn/fail on unknown
>       properties
>       - [HWKALERTS-140] - Validate actions definitions against plugins
>       deployed
>       - [HWKALERTS-141] - NPE when plugin is not present
>       - [HWKALERTS-137] - Get action plugin for unknown plugin should
>       return 404
>       - [HWKALERTS-138] - Action creation for unknown plugin should not
>       return 200
>    - Group Trigger Fixes
>       - [HWKALERTS-147] - Unable to delete member trigger
>    - Documentation Generation Fixes
>    - [HWKALERTS-143] - Swagger annotations broken
>       - [HWKALERTS-144] - REST API doc not properly rendered
>
> Links:
>
>    - Jira release-notes
>       -
>       https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12329652
>       <https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12329367>
>    - Hawkular
>       - http://www.hawkular.org/
>       - Hawkular Alerting
>       - http://www.hawkular.org/docs/dev/alerts.html
>       - Hawkular Alerting Rest API
>       - http://www.hawkular.org/docs/rest/rest-alerts.html
>       - GitHub
>       - https://github.com/hawkular/hawkular-alerts
>       - Examples
>       - https://github.com/hawkular/hawkular-alerts/tree/master/examples
>
>
> Hawkular Alerts Team
>    Jay Shaughnessy (jshaughn at redhat.com)
>    Lucas Ponce (lponce at redhat.com)
>
> _______________________________________________
> 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/20160519/d4ff9e53/attachment.html 

From tsegismo at redhat.com  Fri May 20 04:06:11 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 20 May 2016 10:06:11 +0200
Subject: [Hawkular-dev] Hawkular Alerting 1.1.0.Final Released
In-Reply-To: <573DF672.2080105@redhat.com>
References: <573DF672.2080105@redhat.com>
Message-ID: <CAHnC0xi2b5V1cJ=3g5gn3Gg6c1VMrxf7VkMd7DsoPvUjKksiiw@mail.gmail.com>

Congratulations to the team!

2016-05-19 19:22 GMT+02:00 Jay Shaughnessy <jshaughn at redhat.com>:

>
> We're happy to announce version 1.1.0.Final of Hawkular Alerting!
>
> Hawkular Alerting is an open source, scalable alerting and eventing tool
> for monitoring your Data Center or anything else. Out of the box you get:
>
>    - A robust REST API
>    - Complex Alerting
>    - Powerful Event Handling
>    - Pluggable Action Handlers with many built-in (e-mail, SMS, etc)
>    - Alert Lifecycle (Ack, Resolved, etc)
>    - Flexible Deployment, either standalone or as part of Hawkular
>    - And Much More
>
>
> What's new:
>
>    - Update Cassandra Support
>       - [HWKALERTS-142] - Upgrade to Cassandra 3.x
>    - Use Hawkular-Tenant HTTP Header in both Hawkular and Standalone
>    deployments
>       -  [HWKALERTS-145] - Make hawkular profile independent of Hawkular
>       Accounts
>    - Improve Action validation
>       - [HWKALERTS-139] - Action creation should warn/fail on unknown
>       properties
>       - [HWKALERTS-140] - Validate actions definitions against plugins
>       deployed
>       - [HWKALERTS-141] - NPE when plugin is not present
>       - [HWKALERTS-137] - Get action plugin for unknown plugin should
>       return 404
>       - [HWKALERTS-138] - Action creation for unknown plugin should not
>       return 200
>    - Group Trigger Fixes
>       - [HWKALERTS-147] - Unable to delete member trigger
>    - Documentation Generation Fixes
>    - [HWKALERTS-143] - Swagger annotations broken
>       - [HWKALERTS-144] - REST API doc not properly rendered
>
> Links:
>
>    - Jira release-notes
>       -
>       https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12329652
>       <https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12329367>
>    - Hawkular
>       - http://www.hawkular.org/
>       - Hawkular Alerting
>       - http://www.hawkular.org/docs/dev/alerts.html
>       - Hawkular Alerting Rest API
>       - http://www.hawkular.org/docs/rest/rest-alerts.html
>       - GitHub
>       - https://github.com/hawkular/hawkular-alerts
>       - Examples
>       - https://github.com/hawkular/hawkular-alerts/tree/master/examples
>
>
> Hawkular Alerts Team
>    Jay Shaughnessy (jshaughn at redhat.com)
>    Lucas Ponce (lponce at redhat.com)
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160520/3c47179c/attachment.html 

From mazz at redhat.com  Fri May 20 07:21:08 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 20 May 2016 07:21:08 -0400 (EDT)
Subject: [Hawkular-dev] documentation on new services stuff
In-Reply-To: <1333679999.4734229.1463743264959.JavaMail.zimbra@redhat.com>
Message-ID: <838921711.4734232.1463743268715.JavaMail.zimbra@redhat.com>

I know juca and peter are working on getting the new hawkualr services distro repo built and working. It would be nice if, after its all done, that a brief email can be sent to explain how it is built and how it works. The feature pack stuff that is now all over the place could use a bit of explanation - its a mystery to most folks right now.

From mazz at redhat.com  Fri May 20 11:07:30 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Fri, 20 May 2016 11:07:30 -0400 (EDT)
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <11789257.4803619.1463756571303.JavaMail.zimbra@redhat.com>
Message-ID: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>

I am playing with the new hawkular services distro to see if it can get me moving again with the "no more accounts, need to pass tenant header" stuff:

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

Has anyone played with this? It appears there is no default user created so that means this isn't a fully working distro yet - at least you can't unzip, run, and expect things to work.

There doesn't exist a -Pdev profile that you can use to build a distro for demo and developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user to play with).

Am I missing something or is this just not fully cooked yet?

From auszon3 at gmail.com  Mon May 23 04:28:49 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Mon, 23 May 2016 08:28:49 +0000
Subject: [Hawkular-dev] Building hawkular failed
Message-ID: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>

Hi guys,
I was trying to build the latest repo on master.
It complained that
```
[ERROR] import yargs from ?yargs';
[ERROR] ^^^^^^
[ERROR]
[ERROR] SyntaxError: Unexpected reserved word
[ERROR]     at exports.runInThisContext (vm.js:53:16)
[ERROR]     at Module._compile (module.js:414:25)
[ERROR]     at Object.Module._extensions..js (module.js:442:10)
[ERROR]     at Module.load (module.js:356:32)
[ERROR]     at Function.Module._load (module.js:311:12)
[ERROR]     at Module.require (module.js:366:17)
[ERROR]     at require (module.js:385:17)
[ERROR]     at Liftoff.handleArguments
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
[ERROR]     at Liftoff.<anonymous>
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
[ERROR]     at module.exports
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
```
?
[ERROR] Failed to execute goal
com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
project hawkular-console: Failed to run task: ?gulp.js build --production
--no-color' failed. (error code 1) -> [Help 1]

Anyone knows how to fix this?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160523/e22bf7cd/attachment-0001.html 

From khala at redhat.com  Mon May 23 05:08:24 2016
From: khala at redhat.com (Karel Hala)
Date: Mon, 23 May 2016 05:08:24 -0400 (EDT)
Subject: [Hawkular-dev] Building hawkular failed
In-Reply-To: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>
References: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>
Message-ID: <267800677.37514014.1463994504732.JavaMail.zimbra@redhat.com>

Hello,

it's problem with gulp and packing [.ts, .js] files.

What version of npm do you have? (npm -v).

I suppose you've built the application before so you have installed npm, bower, gulp... right?

Also you can try navigating to 
$ hawkular/directory/hawkular/console/target/gulp-build

and run
$ gulp build
to see the exact error (from what you've pasted it looks like babel was not registered correctly, which is odd)

Karel.

----- Original Message -----
From: "Austin Kuo" <auszon3 at gmail.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Monday, May 23, 2016 10:28:49 AM
Subject: [Hawkular-dev] Building hawkular failed

Hi guys, 
I was trying to build the latest repo on master. 
It complained that 
``` 
[ERROR] import yargs from ?yargs'; 
[ERROR] ^^^^^^ 
[ERROR] 
[ERROR] SyntaxError: Unexpected reserved word 
[ERROR] at exports.runInThisContext (vm.js:53:16) 
[ERROR] at Module._compile (module.js:414:25) 
[ERROR] at Object.Module._extensions..js (module.js:442:10) 
[ERROR] at Module.load (module.js:356:32) 
[ERROR] at Function.Module._load (module.js:311:12) 
[ERROR] at Module.require (module.js:366:17) 
[ERROR] at require (module.js:385:17) 
[ERROR] at Liftoff.handleArguments (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3) 
[ERROR] at Liftoff.<anonymous> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16) 
[ERROR] at module.exports (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3) 
``` 
? 
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on project hawkular-console: Failed to run task: ?gulp.js build --production --no-color' failed. (error code 1) -> [Help 1] 

Anyone knows how to fix this? 
Thanks 

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


From auszon3 at gmail.com  Mon May 23 05:26:51 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Mon, 23 May 2016 09:26:51 +0000
Subject: [Hawkular-dev] Building hawkular failed
In-Reply-To: <267800677.37514014.1463994504732.JavaMail.zimbra@redhat.com>
References: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>
	<267800677.37514014.1463994504732.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ5TdT=B3h=L6=nxxhEMffWDkg2_bXR5+OkNcFZcY6YHw_Fn=g@mail.gmail.com>

my npm version: 2.15.1,  (But it seems that it has another npm in hawkular
/console/target/gulp-build/node)
exact errors with `gulp build`
```
/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/gulpfile.babel.js:17
import yargs from 'yargs';
^^^^^^

SyntaxError: Unexpected reserved word
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Liftoff.handleArguments
(/usr/local/lib/node_modules/gulp/bin/gulp.js:116:3)
    at Liftoff.<anonymous>
(/usr/local/lib/node_modules/gulp/node_modules/liftoff/index.js:193:16)
    at module.exports
(/usr/local/lib/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
```
Thanks!

On Mon, May 23, 2016 at 5:08 PM Karel Hala <khala at redhat.com> wrote:

> Hello,
>
> it's problem with gulp and packing [.ts, .js] files.
>
> What version of npm do you have? (npm -v).
>
> I suppose you've built the application before so you have installed npm,
> bower, gulp... right?
>
> Also you can try navigating to
> $ hawkular/directory/hawkular/console/target/gulp-build
>
> and run
> $ gulp build
> to see the exact error (from what you've pasted it looks like babel was
> not registered correctly, which is odd)
>
> Karel.
>
> ----- Original Message -----
> From: "Austin Kuo" <auszon3 at gmail.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> Sent: Monday, May 23, 2016 10:28:49 AM
> Subject: [Hawkular-dev] Building hawkular failed
>
> Hi guys,
> I was trying to build the latest repo on master.
> It complained that
> ```
> [ERROR] import yargs from ?yargs';
> [ERROR] ^^^^^^
> [ERROR]
> [ERROR] SyntaxError: Unexpected reserved word
> [ERROR] at exports.runInThisContext (vm.js:53:16)
> [ERROR] at Module._compile (module.js:414:25)
> [ERROR] at Object.Module._extensions..js (module.js:442:10)
> [ERROR] at Module.load (module.js:356:32)
> [ERROR] at Function.Module._load (module.js:311:12)
> [ERROR] at Module.require (module.js:366:17)
> [ERROR] at require (module.js:385:17)
> [ERROR] at Liftoff.handleArguments
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
> [ERROR] at Liftoff.<anonymous>
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
> [ERROR] at module.exports
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
> ```
> ?
> [ERROR] Failed to execute goal
> com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
> project hawkular-console: Failed to run task: ?gulp.js build --production
> --no-color' failed. (error code 1) -> [Help 1]
>
> Anyone knows how to fix this?
> 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/20160523/1769930c/attachment.html 

From khala at redhat.com  Mon May 23 05:52:15 2016
From: khala at redhat.com (Karel Hala)
Date: Mon, 23 May 2016 05:52:15 -0400 (EDT)
Subject: [Hawkular-dev] Building hawkular failed
In-Reply-To: <CAJ5TdT=B3h=L6=nxxhEMffWDkg2_bXR5+OkNcFZcY6YHw_Fn=g@mail.gmail.com>
References: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>
	<267800677.37514014.1463994504732.JavaMail.zimbra@redhat.com>
	<CAJ5TdT=B3h=L6=nxxhEMffWDkg2_bXR5+OkNcFZcY6YHw_Fn=g@mail.gmail.com>
Message-ID: <1368569349.37541430.1463997135517.JavaMail.zimbra@redhat.com>

Try reding this thread:

https://github.com/google/web-starter-kit/issues/713

I'd start with
$ npm ls babel
inside gulp-build, removing node_modules and running
$ npm install.

I know that it's vague response, but sadly I am unable to reproduce it.

Karel.

----- Original Message -----
From: "Austin Kuo" <auszon3 at gmail.com>
To: "Karel Hala" <khala at redhat.com>, "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Monday, May 23, 2016 11:26:51 AM
Subject: Re: [Hawkular-dev] Building hawkular failed

my npm version: 2.15.1,  (But it seems that it has another npm in hawkular
/console/target/gulp-build/node)
exact errors with `gulp build`
```
/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/gulpfile.babel.js:17
import yargs from 'yargs';
^^^^^^

SyntaxError: Unexpected reserved word
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Liftoff.handleArguments
(/usr/local/lib/node_modules/gulp/bin/gulp.js:116:3)
    at Liftoff.<anonymous>
(/usr/local/lib/node_modules/gulp/node_modules/liftoff/index.js:193:16)
    at module.exports
(/usr/local/lib/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
```
Thanks!

On Mon, May 23, 2016 at 5:08 PM Karel Hala <khala at redhat.com> wrote:

> Hello,
>
> it's problem with gulp and packing [.ts, .js] files.
>
> What version of npm do you have? (npm -v).
>
> I suppose you've built the application before so you have installed npm,
> bower, gulp... right?
>
> Also you can try navigating to
> $ hawkular/directory/hawkular/console/target/gulp-build
>
> and run
> $ gulp build
> to see the exact error (from what you've pasted it looks like babel was
> not registered correctly, which is odd)
>
> Karel.
>
> ----- Original Message -----
> From: "Austin Kuo" <auszon3 at gmail.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> Sent: Monday, May 23, 2016 10:28:49 AM
> Subject: [Hawkular-dev] Building hawkular failed
>
> Hi guys,
> I was trying to build the latest repo on master.
> It complained that
> ```
> [ERROR] import yargs from ?yargs';
> [ERROR] ^^^^^^
> [ERROR]
> [ERROR] SyntaxError: Unexpected reserved word
> [ERROR] at exports.runInThisContext (vm.js:53:16)
> [ERROR] at Module._compile (module.js:414:25)
> [ERROR] at Object.Module._extensions..js (module.js:442:10)
> [ERROR] at Module.load (module.js:356:32)
> [ERROR] at Function.Module._load (module.js:311:12)
> [ERROR] at Module.require (module.js:366:17)
> [ERROR] at require (module.js:385:17)
> [ERROR] at Liftoff.handleArguments
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
> [ERROR] at Liftoff.<anonymous>
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
> [ERROR] at module.exports
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
> ```
> ?
> [ERROR] Failed to execute goal
> com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
> project hawkular-console: Failed to run task: ?gulp.js build --production
> --no-color' failed. (error code 1) -> [Help 1]
>
> Anyone knows how to fix this?
> Thanks
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


From jpkroehling at redhat.com  Mon May 23 09:46:03 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 23 May 2016 15:46:03 +0200
Subject: [Hawkular-dev] Do we still need the nest? Or: do we still need
	Wildfly Patching?
Message-ID: <882a0f0f-ac13-c468-38b8-ff39b0f315e1@redhat.com>

Bringing a discussion from IRC to the mailing list: do we still need the 
Nest? It seems that the only reason we need the Nest at this point is 
that it provides Wildfly Patching support.

Considering that we'll ship an appliance and RPMs, do we still have the 
requirement of supporting Wildfly Patching?

- Juca.

From mazz at redhat.com  Mon May 23 09:55:03 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 23 May 2016 09:55:03 -0400 (EDT)
Subject: [Hawkular-dev] Do we still need the nest? Or: do we still
	need	Wildfly Patching?
In-Reply-To: <882a0f0f-ac13-c468-38b8-ff39b0f315e1@redhat.com>
References: <882a0f0f-ac13-c468-38b8-ff39b0f315e1@redhat.com>
Message-ID: <1664671332.42366.1464011703829.JavaMail.zimbra@redhat.com>

> Bringing a discussion from IRC to the mailing list: do we still need the
> Nest? It seems that the only reason we need the Nest at this point is
> that it provides Wildfly Patching support.

FYI: here's a hipchat question I posted and David's reply:

[9:27 AM] Mazz: I need a quick confirmation - last I researched this, in order to be able to have a "patchable" product, we cannot deploy our ears/wars via deployment scanner in standalone/deployments - we need to put them in a module subsystem ala "a mixed approach" discussed here: https://developer.jboss.org/wiki/ExtendingAS7
[9:28 AM] Mazz: is this still the case? Or does the latest WildFly patching mechanism somehow workaround the issues and allow for standalone/deployments to be patchable?
[9:29 AM] Mazz: I am assuming it is still recommended to NOT ship things in standalone/deployment if those things are expected to be patchable. But I ask only because it came up again today and since it has been a while since I looked into this, I figure I should ask again.
[9:44 AM] David M. Lloyd: AFAIK nothing has changed in this area

From snegrea at redhat.com  Mon May 23 12:15:51 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Mon, 23 May 2016 11:15:51 -0500
Subject: [Hawkular-dev] Hawkular Organization - Repositories - Vote
Message-ID: <CADt-fV8g+Ec7p6w3=+9QBRRza3bM=bMEzNGedbWRBVjvz6Hnvg@mail.gmail.com>

Hello Everybody,

Based on the emails and discussions from the past few weeks, I created a
community poll to finalize the decision on unmaintained Hawkular
repositories. The current Github org has a significant number of projects
that no longer receive development. For a full list of projects please see
[1], projects below red line are not active.

Please vote on what to do with repos below the red line and future repos
that will no longer be developed by Hawkular:

1) Move to new Hawkular-Archive organization
2) Keep in Hawkular organization marked as "obsolete"


Voting will be open until Monday, May 31st, 7:00 am (US Central).


Doodle Poll - http://doodle.com/poll/vnaqgppvunhaweks


Please contact me if you have any questions about the two options or have
any comments/feedback.


[1]
https://docs.google.com/spreadsheets/d/1IzoBP9glz3GgkcwTRF6cobQCylUaZFLhFgqxRfuQCn0


Thank you,
Stefan Negrea

Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160523/9a99531a/attachment-0001.html 

From jshaughn at redhat.com  Mon May 23 17:19:11 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 23 May 2016 17:19:11 -0400
Subject: [Hawkular-dev] Revisiting Availability (again)
Message-ID: <66eca391-1d2f-229c-dfe5-a4b9fb8c44d8@redhat.com>


I've put together a little doc to try and bring the Avail discussion up 
to speed with respect to what we've implemented so far in Hawkular and 
the Agent.  Please take some time to comment if you're interested in 
this topic.  It's a few pages long, but any time you have to contribute 
is appreciated... -Jay

https://docs.google.com/document/d/1rq9JdOffG_V4oh-9kjnn8K70vupBVoxRm3mKlYCsRRA/edit?pli=1

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

From auszon3 at gmail.com  Tue May 24 01:24:27 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Tue, 24 May 2016 05:24:27 +0000
Subject: [Hawkular-dev] Building hawkular failed
In-Reply-To: <1368569349.37541430.1463997135517.JavaMail.zimbra@redhat.com>
References: <CAJ5TdTka2YmE_r0ezL703s4miF_fqKbUCV2t6d_0fwKgm1Huaw@mail.gmail.com>
	<267800677.37514014.1463994504732.JavaMail.zimbra@redhat.com>
	<CAJ5TdT=B3h=L6=nxxhEMffWDkg2_bXR5+OkNcFZcY6YHw_Fn=g@mail.gmail.com>
	<1368569349.37541430.1463997135517.JavaMail.zimbra@redhat.com>
Message-ID: <CAJ5TdTkwnXJVsDMzdzahcXXtoF7Y14exYRbGeGSQTr4gydkN8w@mail.gmail.com>

it worked!
thanks!
Karel Hala <khala at redhat.com>? 2016?5?23? ???17:52???

> Try reding this thread:
>
> https://github.com/google/web-starter-kit/issues/713
>
> I'd start with
> $ npm ls babel
> inside gulp-build, removing node_modules and running
> $ npm install.
>
> I know that it's vague response, but sadly I am unable to reproduce it.
>
> Karel.
>
> ----- Original Message -----
> From: "Austin Kuo" <auszon3 at gmail.com>
> To: "Karel Hala" <khala at redhat.com>, "Discussions around Hawkular
> development" <hawkular-dev at lists.jboss.org>
> Sent: Monday, May 23, 2016 11:26:51 AM
> Subject: Re: [Hawkular-dev] Building hawkular failed
>
> my npm version: 2.15.1,  (But it seems that it has another npm in hawkular
> /console/target/gulp-build/node)
> exact errors with `gulp build`
> ```
>
> /Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/gulpfile.babel.js:17
> import yargs from 'yargs';
> ^^^^^^
>
> SyntaxError: Unexpected reserved word
>     at exports.runInThisContext (vm.js:53:16)
>     at Module._compile (module.js:373:25)
>     at Object.Module._extensions..js (module.js:416:10)
>     at Module.load (module.js:343:32)
>     at Function.Module._load (module.js:300:12)
>     at Module.require (module.js:353:17)
>     at require (internal/module.js:12:17)
>     at Liftoff.handleArguments
> (/usr/local/lib/node_modules/gulp/bin/gulp.js:116:3)
>     at Liftoff.<anonymous>
> (/usr/local/lib/node_modules/gulp/node_modules/liftoff/index.js:193:16)
>     at module.exports
>
> (/usr/local/lib/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
> ```
> Thanks!
>
> On Mon, May 23, 2016 at 5:08 PM Karel Hala <khala at redhat.com> wrote:
>
> > Hello,
> >
> > it's problem with gulp and packing [.ts, .js] files.
> >
> > What version of npm do you have? (npm -v).
> >
> > I suppose you've built the application before so you have installed npm,
> > bower, gulp... right?
> >
> > Also you can try navigating to
> > $ hawkular/directory/hawkular/console/target/gulp-build
> >
> > and run
> > $ gulp build
> > to see the exact error (from what you've pasted it looks like babel was
> > not registered correctly, which is odd)
> >
> > Karel.
> >
> > ----- Original Message -----
> > From: "Austin Kuo" <auszon3 at gmail.com>
> > To: "Discussions around Hawkular development" <
> > hawkular-dev at lists.jboss.org>
> > Sent: Monday, May 23, 2016 10:28:49 AM
> > Subject: [Hawkular-dev] Building hawkular failed
> >
> > Hi guys,
> > I was trying to build the latest repo on master.
> > It complained that
> > ```
> > [ERROR] import yargs from ?yargs';
> > [ERROR] ^^^^^^
> > [ERROR]
> > [ERROR] SyntaxError: Unexpected reserved word
> > [ERROR] at exports.runInThisContext (vm.js:53:16)
> > [ERROR] at Module._compile (module.js:414:25)
> > [ERROR] at Object.Module._extensions..js (module.js:442:10)
> > [ERROR] at Module.load (module.js:356:32)
> > [ERROR] at Function.Module._load (module.js:311:12)
> > [ERROR] at Module.require (module.js:366:17)
> > [ERROR] at require (module.js:385:17)
> > [ERROR] at Liftoff.handleArguments
> >
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
> > [ERROR] at Liftoff.<anonymous>
> >
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
> > [ERROR] at module.exports
> >
> (/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
> > ```
> > ?
> > [ERROR] Failed to execute goal
> > com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
> > project hawkular-console: Failed to run task: ?gulp.js build --production
> > --no-color' failed. (error code 1) -> [Help 1]
> >
> > Anyone knows how to fix this?
> > 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/20160524/18fbf2c4/attachment.html 

From ppalaga at redhat.com  Tue May 24 04:29:48 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 24 May 2016 10:29:48 +0200
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
Message-ID: <574410FC.4090400@redhat.com>

Hi Mazz, inline...

On 2016-05-20 17:07, John Mazzitelli wrote:
> I am playing with the new hawkular services distro to see if it can get me moving again with the "no more accounts, need to pass tenant header" stuff:
>
> https://github.com/hawkular/hawkular-services/pull/1
>
> Has anyone played with this? It appears there is no default user created so that means this isn't a fully working distro yet - at least you can't unzip, run, and expect things to work.
>
> There doesn't exist a -Pdev profile that you can use to build a distro for demo and developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user to play with).

I have added maven dev profile yesterday, that adds jdoe:password. The 
present state of the PR#1 also boots without any apparent failures. Now, 
we need to figure out how to itest it.

-- P




From jpkroehling at redhat.com  Tue May 24 04:48:03 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 24 May 2016 10:48:03 +0200
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <574410FC.4090400@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
Message-ID: <335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>

On 24.05.2016 10:29, Peter Palaga wrote:
> I have added maven dev profile yesterday, that adds jdoe:password. The
> present state of the PR#1 also boots without any apparent failures. Now,
> we need to figure out how to itest it.

Let me put my QE hat and share my thoughts: Hawkular Services REST 
endpoints is what we expose as API to other clients, like agents, the Go 
client, the Ruby client and so on. What is done "inside" doesn't matter 
much, as long as this API is stable. So, I'd build a set of use cases 
and do a set of independent test cases, which could in turn be run by 
CI/CD platform.

We could even get fancy and do it using some "Given/When/Then" framework 
like Cucumber, so that end users can use it as reference on how to use 
Hawkular Services.

- Juca.

From lkrejci at redhat.com  Tue May 24 04:55:00 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 24 May 2016 10:55 +0200
Subject: [Hawkular-dev] Hawkular Inventory 0.16.0.Final Released
Message-ID: <9387453.YJE47Pubnj@localhost.localdomain>

Hi all,

I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.

The most important change in this release is the alignment of authorization 
and tenant selection with the rest of the Hawkular components.

>From now on, Inventory no longer depends on Keycloak for authentication and 
instead is using JAAS. Any authenticated user is allowed to do anything by 
default.

The tenant is no longer deduced from the authenticated user but is selected 
using the Hawkular-Tenant header (which is therefore required in every request 
to inventory).

This moves inventory more into a role of a "backend service" which delegates 
more granular authentication and authorization to the application layer above 
inventory.

That said, the authorization logic has been factored out and made pluggable 
and a mechanism to check per-entity CRUD privileges is still in place. We just 
swapped the default implementation for a "permissive" one and changed the way 
we figure out the tenant.

Apart from this big change, the following enhancements and fixes have been 
included in the release:

* all internal properties, stored as "__foo" in the backend, are now available 
for filtering as "foo".
* SwitchElementType filter has been "promoted" to the API so that it is usable 
by the API clients.
* Hawkular Commons dependency has been updated to 0.7.2.Final

In 0.17.0.Final we will introduce a new REST API and will deprecate the 
current one (most probably by moving it to /hawkular/inventory/deprecated). 
This work is well underway but unfortunately didn't make it for 0.16.0.Final.

Huge thanks go out to Peter Palaga who did all the security related changes in 
this release and Jirka Kremser who provided the generic mapping of internal 
properties.

-- 
Lukas Krejci

From tsegismo at redhat.com  Tue May 24 04:56:46 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Tue, 24 May 2016 10:56:46 +0200
Subject: [Hawkular-dev] Hawkular Inventory 0.16.0.Final Released
In-Reply-To: <9387453.YJE47Pubnj@localhost.localdomain>
References: <9387453.YJE47Pubnj@localhost.localdomain>
Message-ID: <CAHnC0xjMX4=o6TWbP2r=w3-1f36Oqb=_0cK1QY+y1S6sC4TxGA@mail.gmail.com>

Congratulations guys!

2016-05-24 10:55 GMT+02:00 Lukas Krejci <lkrejci at redhat.com>:

> Hi all,
>
> I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.
>
> The most important change in this release is the alignment of authorization
> and tenant selection with the rest of the Hawkular components.
>
> >From now on, Inventory no longer depends on Keycloak for authentication
> and
> instead is using JAAS. Any authenticated user is allowed to do anything by
> default.
>
> The tenant is no longer deduced from the authenticated user but is selected
> using the Hawkular-Tenant header (which is therefore required in every
> request
> to inventory).
>
> This moves inventory more into a role of a "backend service" which
> delegates
> more granular authentication and authorization to the application layer
> above
> inventory.
>
> That said, the authorization logic has been factored out and made pluggable
> and a mechanism to check per-entity CRUD privileges is still in place. We
> just
> swapped the default implementation for a "permissive" one and changed the
> way
> we figure out the tenant.
>
> Apart from this big change, the following enhancements and fixes have been
> included in the release:
>
> * all internal properties, stored as "__foo" in the backend, are now
> available
> for filtering as "foo".
> * SwitchElementType filter has been "promoted" to the API so that it is
> usable
> by the API clients.
> * Hawkular Commons dependency has been updated to 0.7.2.Final
>
> In 0.17.0.Final we will introduce a new REST API and will deprecate the
> current one (most probably by moving it to /hawkular/inventory/deprecated).
> This work is well underway but unfortunately didn't make it for
> 0.16.0.Final.
>
> Huge thanks go out to Peter Palaga who did all the security related
> changes in
> this release and Jirka Kremser who provided the generic mapping of internal
> properties.
>
> --
> Lukas Krejci
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>



-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160524/067114b6/attachment-0001.html 

From theute at redhat.com  Tue May 24 04:59:36 2016
From: theute at redhat.com (Thomas Heute)
Date: Tue, 24 May 2016 10:59:36 +0200
Subject: [Hawkular-dev] Hawkular Inventory 0.16.0.Final Released
In-Reply-To: <CAHnC0xjMX4=o6TWbP2r=w3-1f36Oqb=_0cK1QY+y1S6sC4TxGA@mail.gmail.com>
References: <9387453.YJE47Pubnj@localhost.localdomain>
	<CAHnC0xjMX4=o6TWbP2r=w3-1f36Oqb=_0cK1QY+y1S6sC4TxGA@mail.gmail.com>
Message-ID: <CA+aN=MpODPT2aHJfpAyitu44kpmLM0viELzwiM4pDgPNBoB2Jw@mail.gmail.com>

Nice !

On Tue, May 24, 2016 at 10:56 AM, Thomas Segismont <tsegismo at redhat.com>
wrote:

> Congratulations guys!
>
> 2016-05-24 10:55 GMT+02:00 Lukas Krejci <lkrejci at redhat.com>:
>
>> Hi all,
>>
>> I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.
>>
>> The most important change in this release is the alignment of
>> authorization
>> and tenant selection with the rest of the Hawkular components.
>>
>> >From now on, Inventory no longer depends on Keycloak for authentication
>> and
>> instead is using JAAS. Any authenticated user is allowed to do anything by
>> default.
>>
>> The tenant is no longer deduced from the authenticated user but is
>> selected
>> using the Hawkular-Tenant header (which is therefore required in every
>> request
>> to inventory).
>>
>> This moves inventory more into a role of a "backend service" which
>> delegates
>> more granular authentication and authorization to the application layer
>> above
>> inventory.
>>
>> That said, the authorization logic has been factored out and made
>> pluggable
>> and a mechanism to check per-entity CRUD privileges is still in place. We
>> just
>> swapped the default implementation for a "permissive" one and changed the
>> way
>> we figure out the tenant.
>>
>> Apart from this big change, the following enhancements and fixes have been
>> included in the release:
>>
>> * all internal properties, stored as "__foo" in the backend, are now
>> available
>> for filtering as "foo".
>> * SwitchElementType filter has been "promoted" to the API so that it is
>> usable
>> by the API clients.
>> * Hawkular Commons dependency has been updated to 0.7.2.Final
>>
>> In 0.17.0.Final we will introduce a new REST API and will deprecate the
>> current one (most probably by moving it to
>> /hawkular/inventory/deprecated).
>> This work is well underway but unfortunately didn't make it for
>> 0.16.0.Final.
>>
>> Huge thanks go out to Peter Palaga who did all the security related
>> changes in
>> this release and Jirka Kremser who provided the generic mapping of
>> internal
>> properties.
>>
>> --
>> Lukas Krejci
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
>
> --
> Thomas Segismont
> JBoss ON Engineering Team
>
> _______________________________________________
> 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/20160524/d811b4c3/attachment.html 

From hrupp at redhat.com  Tue May 24 05:09:50 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 May 2016 11:09:50 +0200
Subject: [Hawkular-dev] Hawkular Inventory 0.16.0.Final Released
In-Reply-To: <9387453.YJE47Pubnj@localhost.localdomain>
References: <9387453.YJE47Pubnj@localhost.localdomain>
Message-ID: <D7582E64-96CF-4FD5-BF2C-4BA0714B1EAE@redhat.com>

On 24 May 2016, at 10:55, Lukas Krejci wrote:
>
> I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.

Congrats

> In 0.17.0.Final we will introduce a new REST API and will deprecate the
> current one (most probably by moving it to /hawkular/inventory/deprecated).

This way you break all existing clients !

You may either move the new api to a new prefix
Or use content negotiation where the new api gets a content of e.g.
application/hawkular-inventory+json;v2
A request without that content type gets the old endpoints and
semantics.
A request with that content type in the request will access the
new endpoints (which may be separate or overlay the old ones)
with potentially new data formats.

This way clients can upgrade as they want

From ppalaga at redhat.com  Tue May 24 05:38:44 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 24 May 2016 11:38:44 +0200
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
	<335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
Message-ID: <57442124.6000609@redhat.com>

Hi *,

PR#1 was just merged and you are all invited to build and try the 
Services [1]. You may want to build with -Pdev to get a distro with 
jdoe:password.

[1] https://github.com/hawkular/hawkular-services

More inline...

On 2016-05-24 10:48, Juraci Paix?o Kr?hling wrote:
> On 24.05.2016 10:29, Peter Palaga wrote:
>> I have added maven dev profile yesterday, that adds jdoe:password. The
>> present state of the PR#1 also boots without any apparent failures. Now,
>> we need to figure out how to itest it.
>
> Let me put my QE hat and share my thoughts: Hawkular Services REST
> endpoints is what we expose as API to other clients, like agents, the Go
> client, the Ruby client and so on. What is done "inside" doesn't matter
> much, as long as this API is stable. So, I'd build a set of use cases
> and do a set of independent test cases, which could in turn be run by
> CI/CD platform.
>
> We could even get fancy and do it using some "Given/When/Then" framework
> like Cucumber, so that end users can use it as reference on how to use
> Hawkular Services.

@Juca: I am not sure if you are proposing to create a new wide-coverage 
test suite in Services git repo. I do not think that Services is a good 
place for maintaining such a wide-coverage test suite. I think that 
individual components should take care for their all-covering test 
suites in their respective git repos.

As I said earlier on IRC, we should either (a) have a few basic smoke 
tests in Services git repo, or (b) we should find a way to run itests 
pulled as test-jars from the components' repos.

I think that (a) is a safer bet for now. Actually, the e2e tests now 
present in Hawkular could be taken as a good starting point for what we 
need here in Services.

Thanks,

Peter



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


From lkrejci at redhat.com  Tue May 24 05:57:20 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Tue, 24 May 2016 11:57:20 +0200
Subject: [Hawkular-dev] How to gradually remove unfitting old REST APIs?
Message-ID: <2190791.8Qy8N1910l@localhost.localdomain>

This stems from the mention of deprecating the REST API of inventory and 
making the new API the default one, forcing the existing clients to change.

I think this is a generic problem with the "emergent design" of iterative 
development - sometimes the stuff you come up with turns out to be wrong and 
you need to toss it away. At the same time, we need to minimize the "damage" 
we do to the existing clients.

Let me just copy the relevant parts from the other thread and answer them 
inline:

> > In 0.17.0.Final we will introduce a new REST API and will deprecate the
> > current one (most probably by moving it to
> > /hawkular/inventory/deprecated).
> 
> This way you break all existing clients !
> 

I know... At the same time Inventory is still not stable, it's 0.x.y, and the 
current REST API really is broken in some ways.

I'd rather encourage clients to move away from it than keep it forever.

> You may either move the new api to a new prefix

I want the new API to be the default when inventory goes stable.

> Or use content negotiation where the new api gets a content of e.g.
> application/hawkular-inventory+json;v2

Again, I don't want to keep the old stuff around when inventory goes stable. 
So having the new stuff as a v2 doesn't really make sense when v1 is going 
away and will not be available in the future.

> A request without that content type gets the old endpoints and
> semantics.
> A request with that content type in the request will access the
> new endpoints (which may be separate or overlay the old ones)
> with potentially new data formats.
> 
> This way clients can upgrade as they want

Content negotiation or new root context for the new API is certainly the clean 
solution here, I can't argue that. It requires no change on the clients that 
want to keep using the old API.

But I really want to prod the clients to upgrade, because I don't intend to 
maintain the old API moving forward. So the "solution" is to actually MOVE the 
old API to a new context root "/deprecated" (and I don't say it is the ideal 
one and I am open to be persuaded to use another).

This will have 2 consequences:
* if you want to keep using the old API, update your client to use the new 
context root. This usually should be as simple as changing a constant in the 
client with the new context root. After this change, the clients are free to 
upgrade as they want.
* the new REST API remains "clean" - no need to specifically ask for it.


There are other options:
* When the old API is called, "compute" the new URI (if possible) and return 
301. According to the spec, the clients should "relink" and use the new URI in 
the future. The drawback here is that IMHO this is messy for the clients - 
they don't have an idea WHY is this being done, nor are they explicitly told 
about the new capabilities of the new API. Additionally, this can only work if 
the old and new URIs are "mappable" and the actual content format doesn't 
change.

* Add a Warning: 299 - "Deprecated. Consider upgrading to new API." header 
(https://tools.ietf.org/html/rfc7234#section-5.5). If the clients look at the 
response headers, this gives them the information about the deprecation. Con - 
this might be missed by the clients.


-- 
Lukas Krejci

From jpkroehling at redhat.com  Tue May 24 06:16:54 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 24 May 2016 12:16:54 +0200
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <57442124.6000609@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
	<335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
	<57442124.6000609@redhat.com>
Message-ID: <09ccbcbe-df4b-58a8-599c-53abd0ae80df@redhat.com>

On 24.05.2016 11:38, Peter Palaga wrote:
> @Juca: I am not sure if you are proposing to create a new wide-coverage
> test suite in Services git repo. I do not think that Services is a good
> place for maintaining such a wide-coverage test suite. I think that
> individual components should take care for their all-covering test
> suites in their respective git repos.
>
> As I said earlier on IRC, we should either (a) have a few basic smoke
> tests in Services git repo, or (b) we should find a way to run itests
> pulled as test-jars from the components' repos.
>
> I think that (a) is a safer bet for now. Actually, the e2e tests now
> present in Hawkular could be taken as a good starting point for what we
> need here in Services.

+1 . I was trying to avoid having duplicate logic/tests by having one 
place that could be used as reference on "how to consume Hawkular 
Services" (instead of "how to consume Metrics") and what to expect from 
Inventory when you create something on Metrics, but in the end, there's 
nothing special on Hawkular Services that doesn't exist on the 
individual components themselves, I suppose. So, this would also be 
redundant.

- Juca.

From hrupp at redhat.com  Tue May 24 08:24:51 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Tue, 24 May 2016 14:24:51 +0200
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
	<335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
Message-ID: <E564911D-A4FF-4F95-B76D-5FA46658DDEE@redhat.com>

On 24 May 2016, at 10:48, Juraci Paix?o Kr?hling wrote:

> Let me put my QE hat and share my thoughts: Hawkular Services REST
> endpoints is what we expose as API to other clients, like agents, the 
> Go
> client, the Ruby client and so on. What is done "inside" doesn't 
> matter
> much, as long as this API is stable. So, I'd build a set of use cases
> and do a set of independent test cases, which could in turn be run by
> CI/CD platform.

+1

In fact the ruby-client's test suite already tests a lot of this (*) and
could be used for this purpose


*) Standard operation mode is though to run against recorded cassettes,
so we would need to invest a bit more to reliably run with live-requests
against hawkular-services


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

From lponce at redhat.com  Tue May 24 08:27:52 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Tue, 24 May 2016 08:27:52 -0400 (EDT)
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <E564911D-A4FF-4F95-B76D-5FA46658DDEE@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
	<335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
	<E564911D-A4FF-4F95-B76D-5FA46658DDEE@redhat.com>
Message-ID: <348753624.294219.1464092872405.JavaMail.zimbra@redhat.com>



----- Mensaje original -----
> De: "Heiko W.Rupp" <hrupp at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Martes, 24 de Mayo 2016 14:24:51
> Asunto: Re: [Hawkular-dev] the new hawkular services distro
> 
> On 24 May 2016, at 10:48, Juraci Paix?o Kr?hling wrote:
> 
> > Let me put my QE hat and share my thoughts: Hawkular Services REST
> > endpoints is what we expose as API to other clients, like agents, the
> > Go
> > client, the Ruby client and so on. What is done "inside" doesn't
> > matter
> > much, as long as this API is stable. So, I'd build a set of use cases
> > and do a set of independent test cases, which could in turn be run by
> > CI/CD platform.
> 
> +1
> 
> In fact the ruby-client's test suite already tests a lot of this (*) and
> could be used for this purpose
> 
> 
> *) Standard operation mode is though to run against recorded cassettes,
> so we would need to invest a bit more to reliably run with live-requests
> against hawkular-services
> 
> 

+1

I like the idea to maintain the itest on the component to focus on pure REST API specifics and use the client(s) (ruby here as it is most mature, but this can change on the future) to test a wider integration test usecases.



From miburman at redhat.com  Tue May 24 08:39:53 2016
From: miburman at redhat.com (Michael Burman)
Date: Tue, 24 May 2016 08:39:53 -0400 (EDT)
Subject: [Hawkular-dev] the new hawkular services distro
In-Reply-To: <348753624.294219.1464092872405.JavaMail.zimbra@redhat.com>
References: <703701533.4804392.1463756850466.JavaMail.zimbra@redhat.com>
	<574410FC.4090400@redhat.com>
	<335eb517-b307-d027-1919-782f7fbe3d3d@redhat.com>
	<E564911D-A4FF-4F95-B76D-5FA46658DDEE@redhat.com>
	<348753624.294219.1464092872405.JavaMail.zimbra@redhat.com>
Message-ID: <1541781597.95251201.1464093593258.JavaMail.zimbra@redhat.com>

I'd say Golang client is the most mature as it's the only one in production use ;) (and those production use-cases are included in its tests). But of course it's metrics only. 

Metrics itself has large amount of rest-tests, so repeating all of those makes no sense. They could be run against a live Hawkular Services instance though.

  - Micke

----- Original Message -----
From: "Lucas Ponce" <lponce at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Tuesday, May 24, 2016 3:27:52 PM
Subject: Re: [Hawkular-dev] the new hawkular services distro



----- Mensaje original -----
> De: "Heiko W.Rupp" <hrupp at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Martes, 24 de Mayo 2016 14:24:51
> Asunto: Re: [Hawkular-dev] the new hawkular services distro
> 
> On 24 May 2016, at 10:48, Juraci Paix?o Kr?hling wrote:
> 
> > Let me put my QE hat and share my thoughts: Hawkular Services REST
> > endpoints is what we expose as API to other clients, like agents, the
> > Go
> > client, the Ruby client and so on. What is done "inside" doesn't
> > matter
> > much, as long as this API is stable. So, I'd build a set of use cases
> > and do a set of independent test cases, which could in turn be run by
> > CI/CD platform.
> 
> +1
> 
> In fact the ruby-client's test suite already tests a lot of this (*) and
> could be used for this purpose
> 
> 
> *) Standard operation mode is though to run against recorded cassettes,
> so we would need to invest a bit more to reliably run with live-requests
> against hawkular-services
> 
> 

+1

I like the idea to maintain the itest on the component to focus on pure REST API specifics and use the client(s) (ruby here as it is most mature, but this can change on the future) to test a wider integration test usecases.


_______________________________________________
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 24 08:54:25 2016
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 24 May 2016 08:54:25 -0400
Subject: [Hawkular-dev] How to gradually remove unfitting old REST APIs?
In-Reply-To: <2190791.8Qy8N1910l@localhost.localdomain>
References: <2190791.8Qy8N1910l@localhost.localdomain>
Message-ID: <624ef2d5-857b-2e00-6a2d-e4c5bcc5f35a@redhat.com>


Normally I would say we should avoid breaking changes at all costs.  
Even having to change the context root means having to rebuilt the 
client in order to potentially get a fix that went along with the 
breaking API change.  But, in this case I really have to wonder how many 
existing clients we're talking about outside of our own stuff.  
Inventory is still in early releases and I don't want to see us have to 
do extra work to support non-existing clients.  If you care enough to 
already be using HI I think you'd be OK with this early instability. 
Remember, the changes to auth just broke *all* of the component releases.


On 5/24/2016 5:57 AM, Lukas Krejci wrote:
> This stems from the mention of deprecating the REST API of inventory and
> making the new API the default one, forcing the existing clients to change.
>
> I think this is a generic problem with the "emergent design" of iterative
> development - sometimes the stuff you come up with turns out to be wrong and
> you need to toss it away. At the same time, we need to minimize the "damage"
> we do to the existing clients.
>
> Let me just copy the relevant parts from the other thread and answer them
> inline:
>
>>> In 0.17.0.Final we will introduce a new REST API and will deprecate the
>>> current one (most probably by moving it to
>>> /hawkular/inventory/deprecated).
>> This way you break all existing clients !
>>
> I know... At the same time Inventory is still not stable, it's 0.x.y, and the
> current REST API really is broken in some ways.
>
> I'd rather encourage clients to move away from it than keep it forever.
>
>> You may either move the new api to a new prefix
> I want the new API to be the default when inventory goes stable.
>
>> Or use content negotiation where the new api gets a content of e.g.
>> application/hawkular-inventory+json;v2
> Again, I don't want to keep the old stuff around when inventory goes stable.
> So having the new stuff as a v2 doesn't really make sense when v1 is going
> away and will not be available in the future.
>
>> A request without that content type gets the old endpoints and
>> semantics.
>> A request with that content type in the request will access the
>> new endpoints (which may be separate or overlay the old ones)
>> with potentially new data formats.
>>
>> This way clients can upgrade as they want
> Content negotiation or new root context for the new API is certainly the clean
> solution here, I can't argue that. It requires no change on the clients that
> want to keep using the old API.
>
> But I really want to prod the clients to upgrade, because I don't intend to
> maintain the old API moving forward. So the "solution" is to actually MOVE the
> old API to a new context root "/deprecated" (and I don't say it is the ideal
> one and I am open to be persuaded to use another).
>
> This will have 2 consequences:
> * if you want to keep using the old API, update your client to use the new
> context root. This usually should be as simple as changing a constant in the
> client with the new context root. After this change, the clients are free to
> upgrade as they want.
> * the new REST API remains "clean" - no need to specifically ask for it.
>
>
> There are other options:
> * When the old API is called, "compute" the new URI (if possible) and return
> 301. According to the spec, the clients should "relink" and use the new URI in
> the future. The drawback here is that IMHO this is messy for the clients -
> they don't have an idea WHY is this being done, nor are they explicitly told
> about the new capabilities of the new API. Additionally, this can only work if
> the old and new URIs are "mappable" and the actual content format doesn't
> change.
>
> * Add a Warning: 299 - "Deprecated. Consider upgrading to new API." header
> (https://tools.ietf.org/html/rfc7234#section-5.5). If the clients look at the
> response headers, this gives them the information about the deprecation. Con -
> this might be missed by the clients.
>
>

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

From auszon3 at gmail.com  Wed May 25 05:03:33 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Wed, 25 May 2016 09:03:33 +0000
Subject: [Hawkular-dev] System requirement for hawkular server
Message-ID: <CAJ5TdTm8P-QMGm=CVFsbEDe1DDjEbLytWN11Ce96Jrv-VM7rcw@mail.gmail.com>

Hi all,
When I was trying to running the server on my VM (2G memory), it shows
```
?
java.lang.OutOfMemoryError
Java HotSpot(TM) 64-Bit Server VM warning: INFO:
os::commit_memory(0x00007f4d913cc000, 12288, 0) failed; error='Cannot
allocate memory' (errno=12)
```
Wondering how much memory & CPU is sufficient for it?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160525/32867597/attachment.html 

From tsegismo at redhat.com  Wed May 25 05:56:23 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 25 May 2016 11:56:23 +0200
Subject: [Hawkular-dev] System requirement for hawkular server
In-Reply-To: <CAJ5TdTm8P-QMGm=CVFsbEDe1DDjEbLytWN11Ce96Jrv-VM7rcw@mail.gmail.com>
References: <CAJ5TdTm8P-QMGm=CVFsbEDe1DDjEbLytWN11Ce96Jrv-VM7rcw@mail.gmail.com>
Message-ID: <CAHnC0xgOmhUQjG8hXh_75+QzhZNbD4KrVjcSFRf6EGrwMDRasQ@mail.gmail.com>

The all-in-one package has all the services embedded on top of Cassandra. I
think 4G for you VM would be better.

2016-05-25 11:03 GMT+02:00 Austin Kuo <auszon3 at gmail.com>:

> Hi all,
> When I was trying to running the server on my VM (2G memory), it shows
> ```
> ?
> java.lang.OutOfMemoryError
> Java HotSpot(TM) 64-Bit Server VM warning: INFO:
> os::commit_memory(0x00007f4d913cc000, 12288, 0) failed; error='Cannot
> allocate memory' (errno=12)
> ```
> Wondering how much memory & CPU is sufficient for it?
>
> Thanks!
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160525/31d3fcee/attachment.html 

From jpkroehling at redhat.com  Wed May 25 07:54:47 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 25 May 2016 13:54:47 +0200
Subject: [Hawkular-dev] SSL by default
Message-ID: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>

Team,

I just sent a PR for hawkular-services [1] that adds SSL support by 
default to the distribution.

I'd like you to take a moment and do a couple of simple tests of your 
component against this distribution, specially if you perform REST calls 
to a component endpoint.

Apart from the Agent, I'm not aware of any REST calls made by individual 
components, but I'd need to be aware of any problems that this change 
might cause.

My next step is to change the agent to accept certs on our keystore.

A few comments:
- The HTTP port is not redirecting to HTTPS yet. This might require 
changes to the individual component's web.xml , which I'll be adding soon.
- The certificate inside the keystore is a self-signed one. Should we 
ship it on the main distribution, with instructions telling users to 
replace our certificate with a real one? Or should we *not* ship it? 
Related question: are we even allowed to ship such keystores?
- As mentioned in the previous point, the cert is self-signed. So, you 
might need to add "-k" to curl to bypass the cert verification.
- Authentication with client cert is not yet available.

1 - https://github.com/hawkular/hawkular-services/pull/2

- Juca.

From mazz at redhat.com  Wed May 25 09:16:55 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 25 May 2016 09:16:55 -0400 (EDT)
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
Message-ID: <847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>

> My next step is to change the agent to accept certs on our keystore.

If everything works as I am expecting it to work, you should just need to configure the agent's storage adapter to use the WildFly security realm where the keystore is defined, and it should "just work." But then again, its been a while since I tested the agent using secure comm to the server, but that is how I got it to work last time.

See http://www.hawkular.org/docs/user/secure-comm.html

> A few comments:
> - The HTTP port is not redirecting to HTTPS yet. This might require
> changes to the individual component's web.xml , which I'll be adding soon.
> - The certificate inside the keystore is a self-signed one. Should we
> ship it on the main distribution, with instructions telling users to
> replace our certificate with a real one? Or should we *not* ship it?

RHQ ships with such a keystore, too. I can't remember if we explicitly told people in the docs to change it. But that is how we ship it. We should tell people about it.

> Related question: are we even allowed to ship such keystores?

It is how RHQ does it :-)


> - As mentioned in the previous point, the cert is self-signed. So, you
> might need to add "-k" to curl to bypass the cert verification.
> - Authentication with client cert is not yet available.


I do not know how to tell WildFly in its security-realm to do this same kind of bypass... did you look into that? Because the agent will need to be told about doing this bypass, too. The way I worked around it was I actually put my self-signed cert into my JVM's truststore (which isn't something I think we want to ask people to do).

From jpkroehling at redhat.com  Wed May 25 09:46:40 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 25 May 2016 15:46:40 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
Message-ID: <c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>

On 25.05.2016 15:16, John Mazzitelli wrote:
>> My next step is to change the agent to accept certs on our keystore.
>
> If everything works as I am expecting it to work, you should just need to configure the agent's storage adapter to use the WildFly security realm where the keystore is defined, and it should "just work." But then again, its been a while since I tested the agent using secure comm to the server, but that is how I got it to work last time.
>
> See http://www.hawkular.org/docs/user/secure-comm.html

Cool ! That would work for the local agent, which is the scenario I was 
planning on working on. For remote agents, we should *not* do this, as 
the keystore includes the private key for the cert, which should be 
known only to the server. But for the remote agent, I expect the server 
to use a proper certificate chain.

>> Related question: are we even allowed to ship such keystores?
>
> It is how RHQ does it :-)

That's good to know, thanks!

>> - As mentioned in the previous point, the cert is self-signed. So, you
>> might need to add "-k" to curl to bypass the cert verification.
>> - Authentication with client cert is not yet available.
>
>
> I do not know how to tell WildFly in its security-realm to do this same kind of bypass... did you look into that? Because the agent will need to be told about doing this bypass, too. The way I worked around it was I actually put my self-signed cert into my JVM's truststore (which isn't something I think we want to ask people to do).

It depends on the HTTP client you are using. In the "production" 
scenarios, no change is needed, as the cert would probably have a valid 
chain.

For dev scenarios, or scenarios where the cert is issued by an unknown 
root CA (like internal certificates), the common practice is to add the 
root CA to the JVM's keystore, similar to what you did. The reason is 
that this cert is not trusted by any known Certificate Authority, so, an 
admin would have to explicitly tell that this cert is known and is to be 
trusted. The cert we will be shipping on the keystore is *not* trusted 
and is intended to be used only on dev scenarios.

Another practice is to do a certificate pinning, ie, tell your HTTP 
client that you know about this specific cert. The disadvantage of this 
is that we'd have to keep the server and client in sync. Looking at your 
instructions on secure-comm.html , this is probably what you are doing 
on the agent side.

Unfortunately, there's no secure solution that I know of that would 
allow us to ship something usable for our production distribution.

There was a thread some time ago on wildfly-dev about auto generating 
certificates on the first boot. I believe this was part of Elytron and 
we might be able to benefit from this in the future.

- Juca.

From fbrychta at redhat.com  Wed May 25 09:59:50 2016
From: fbrychta at redhat.com (Filip Brychta)
Date: Wed, 25 May 2016 09:59:50 -0400 (EDT)
Subject: [Hawkular-dev] Running perf tests with 2 h-metrics instances on the
 same host - results
In-Reply-To: <1655289336.32518977.1464183060079.JavaMail.zimbra@redhat.com>
Message-ID: <1529835024.32525431.1464184790066.JavaMail.zimbra@redhat.com>

Hello,
I finished quick testing of two h-metrics instances running on the same host both using the same external cassandra node.
Motivation for this was to find a bottleneck.

>From previous testing we know following:
- with additional h-metric instance the throughput was increased almost linearly
- question was why it's not possible to get higher throughput from single h-metrics instance while we know that cassandra node is not the bottleneck

Test:
1 - run perf tests against 1 h-metrics with 4GB memory using one external cassandra node
2 - run perf tests against 2 h-metrics with 2GB memory each (on the same VM as previous test) using one external cassandra node (again the same VM as previous test)
3 - compare results

Results:
- for small msgs (1 metrics per request) there was almost no difference -> CPU was fully utilized -> for small msgs the CPU is bottleneck
- for bigger msgs (100 metrics per request) total throughput was almost 2 times better -> it's possible to get 2 times better throughput from the same VM -> neither cpu, nor memory, nor network is the bottleneck -> h-metrics is doing some kind of throttling
- I tried 500 metrics per request as well but I was getting timout exceptions. Maybe it was too much for this VM.


Filip


From gbrown at redhat.com  Wed May 25 10:15:18 2016
From: gbrown at redhat.com (Gary Brown)
Date: Wed, 25 May 2016 10:15:18 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular BTM 0.8.0.Final
In-Reply-To: <1480746213.51898894.1464185546291.JavaMail.zimbra@redhat.com>
Message-ID: <1897348251.51899731.1464185718366.JavaMail.zimbra@redhat.com>

Hi all

I'm pleased to announce the availability of version 0.8.0.Final of the Hawkular BTM project. The release can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.8.0.Final

The main focus for this release has been adding Distributed Tracing capabilities to the project, and general UI improvements:

    * Distributed Tracing
        - New UI tab to display aggregated end to end view of activities across a distributed application
        - Supporting REST operations

    * Numerous UI improvements, including
        - Simplified Business Transaction overview page, including active and disabled business transactions
        - Common filter sidebar used by Application Performance and Distributed Tracing pages
        - Filtering on inclusion/exclusion of properties and/or faults
        - Finer grained control over start/end date and time on Application Performance and Distributed Tracing pages

    * Deriving end to end completion time

    * Deriving latency information from interactions between services

    * Instrumentation rules for
        - RxJava
        - Netty

    * Many bug fixes.


I would like to thank the following people for their contributions to this release:

    Alexandre Mendon?a - thanks for all the cool UI work in this release
    Gabriel Cardoso - thanks for providing feedback and support on the UI style
    Andrew Dinn - thanks for continued (and very responsive) support with the use of Byteman
    Juraci Paix?o Kr?hling - thanks for continued support with integration with Hawkular Accounts
    Andrea Scarpino - thanks for identifying and helping to fix issues with the SQL driver instrumentation


Regards
Gary



From tsegismo at redhat.com  Wed May 25 11:05:45 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Wed, 25 May 2016 17:05:45 +0200
Subject: [Hawkular-dev] Hawkular BTM 0.8.0.Final
In-Reply-To: <1897348251.51899731.1464185718366.JavaMail.zimbra@redhat.com>
References: <1480746213.51898894.1464185546291.JavaMail.zimbra@redhat.com>
	<1897348251.51899731.1464185718366.JavaMail.zimbra@redhat.com>
Message-ID: <CAHnC0xjB6vYorBSYAQu_v3TNMx-=PGOEN7LkVJgjkZ7jBbO_kg@mail.gmail.com>

Great job! Congrats!

2016-05-25 16:15 GMT+02:00 Gary Brown <gbrown at redhat.com>:

> Hi all
>
> I'm pleased to announce the availability of version 0.8.0.Final of the
> Hawkular BTM project. The release can be found here:
> https://github.com/hawkular/hawkular-btm/releases/tag/0.8.0.Final
>
> The main focus for this release has been adding Distributed Tracing
> capabilities to the project, and general UI improvements:
>
>     * Distributed Tracing
>         - New UI tab to display aggregated end to end view of activities
> across a distributed application
>         - Supporting REST operations
>
>     * Numerous UI improvements, including
>         - Simplified Business Transaction overview page, including active
> and disabled business transactions
>         - Common filter sidebar used by Application Performance and
> Distributed Tracing pages
>         - Filtering on inclusion/exclusion of properties and/or faults
>         - Finer grained control over start/end date and time on
> Application Performance and Distributed Tracing pages
>
>     * Deriving end to end completion time
>
>     * Deriving latency information from interactions between services
>
>     * Instrumentation rules for
>         - RxJava
>         - Netty
>
>     * Many bug fixes.
>
>
> I would like to thank the following people for their contributions to this
> release:
>
>     Alexandre Mendon?a - thanks for all the cool UI work in this release
>     Gabriel Cardoso - thanks for providing feedback and support on the UI
> style
>     Andrew Dinn - thanks for continued (and very responsive) support with
> the use of Byteman
>     Juraci Paix?o Kr?hling - thanks for continued support with integration
> with Hawkular Accounts
>     Andrea Scarpino - thanks for identifying and helping to fix issues
> with the SQL driver instrumentation
>
>
> Regards
> Gary
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>



-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160525/60c24bc4/attachment.html 

From jdoyle at redhat.com  Wed May 25 11:37:33 2016
From: jdoyle at redhat.com (John Doyle)
Date: Wed, 25 May 2016 11:37:33 -0400
Subject: [Hawkular-dev] Hawkular BTM 0.8.0.Final
In-Reply-To: <1897348251.51899731.1464185718366.JavaMail.zimbra@redhat.com>
References: <1480746213.51898894.1464185546291.JavaMail.zimbra@redhat.com>
	<1897348251.51899731.1464185718366.JavaMail.zimbra@redhat.com>
Message-ID: <CAKSM3oe1SG9=Z4Lp6FVPgaSVU82xsVu3Sq4P5_x1SHkaNPz3zQ@mail.gmail.com>

Congratulations!

On Wed, May 25, 2016 at 10:15 AM, Gary Brown <gbrown at redhat.com> wrote:
> Hi all
>
> I'm pleased to announce the availability of version 0.8.0.Final of the Hawkular BTM project. The release can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.8.0.Final
>
> The main focus for this release has been adding Distributed Tracing capabilities to the project, and general UI improvements:
>
>     * Distributed Tracing
>         - New UI tab to display aggregated end to end view of activities across a distributed application
>         - Supporting REST operations
>
>     * Numerous UI improvements, including
>         - Simplified Business Transaction overview page, including active and disabled business transactions
>         - Common filter sidebar used by Application Performance and Distributed Tracing pages
>         - Filtering on inclusion/exclusion of properties and/or faults
>         - Finer grained control over start/end date and time on Application Performance and Distributed Tracing pages
>
>     * Deriving end to end completion time
>
>     * Deriving latency information from interactions between services
>
>     * Instrumentation rules for
>         - RxJava
>         - Netty
>
>     * Many bug fixes.
>
>
> I would like to thank the following people for their contributions to this release:
>
>     Alexandre Mendon?a - thanks for all the cool UI work in this release
>     Gabriel Cardoso - thanks for providing feedback and support on the UI style
>     Andrew Dinn - thanks for continued (and very responsive) support with the use of Byteman
>     Juraci Paix?o Kr?hling - thanks for continued support with integration with Hawkular Accounts
>     Andrea Scarpino - thanks for identifying and helping to fix issues with the SQL driver instrumentation
>
>
> Regards
> Gary
>
>
> _______________________________________________
> 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 26 03:31:40 2016
From: theute at redhat.com (Thomas Heute)
Date: Thu, 26 May 2016 09:31:40 +0200
Subject: [Hawkular-dev] Ansible playbooks
Message-ID: <CA+aN=MpWFyyFqEoafZdyJCG3QTZhEEhEToND1-DcMtmA0ZkQnA@mail.gmail.com>

I was working on Ansible playbooks (mostly to do a demo, but the work
extended to actually build the demo...)

I started with:

https://github.com/hawkular/hawkular-agent/tree/mazz/ansible/hawkular-wildfly-agent-ansible-playbook

and then I found:
   https://github.com/pilhuhn/hawkular-agent-ansible


And I wanted to create a playbook to install Hawkular Server as well.

I am not very familiar with Ansible (Tower) but it looks like we should
have a top level repo with all our playbooks, we could also upload to
Ansible Galaxy when we are comfortable about maintaining those.

Any comment ?


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

From theute at redhat.com  Thu May 26 03:50:05 2016
From: theute at redhat.com (Thomas Heute)
Date: Thu, 26 May 2016 09:50:05 +0200
Subject: [Hawkular-dev] Ansible playbooks
In-Reply-To: <CA+aN=MpWFyyFqEoafZdyJCG3QTZhEEhEToND1-DcMtmA0ZkQnA@mail.gmail.com>
References: <CA+aN=MpWFyyFqEoafZdyJCG3QTZhEEhEToND1-DcMtmA0ZkQnA@mail.gmail.com>
Message-ID: <CA+aN=MrSQtaZg+YG2Bh_L6BpWtKKZw+6083dWYKkuKad18gwBg@mail.gmail.com>

Looking at Galaxy some more, it requires to have 1 repo per role...

So it would make more sense to do something like we did for docker:
https://github.com/jboss-dockerfiles so I created:
https://github.com/jboss-ansible

On Thu, May 26, 2016 at 9:31 AM, Thomas Heute <theute at redhat.com> wrote:

> I was working on Ansible playbooks (mostly to do a demo, but the work
> extended to actually build the demo...)
>
> I started with:
>
> https://github.com/hawkular/hawkular-agent/tree/mazz/ansible/hawkular-wildfly-agent-ansible-playbook
>
> and then I found:
>    https://github.com/pilhuhn/hawkular-agent-ansible
>
>
> And I wanted to create a playbook to install Hawkular Server as well.
>
> I am not very familiar with Ansible (Tower) but it looks like we should
> have a top level repo with all our playbooks, we could also upload to
> Ansible Galaxy when we are comfortable about maintaining those.
>
> Any comment ?
>
>
> Thomas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160526/791e4428/attachment-0001.html 

From jkremser at redhat.com  Thu May 26 05:51:46 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Thu, 26 May 2016 11:51:46 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
Message-ID: <CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>

Hi,
  what about creating a default certificate that is issued by a commonly
accepted root CA (at least in the modern browsers, not sure about JVM if
there is something similar). On the internets there is a service
https://letsencrypt.org .I haven't tried yet, but it has also some API for
doing it automatically, so we can even go further. What I've tried is the
https://www.startssl.com and it worked perfectly, I can see the green https
in the chrome :] Both services are for free, but afaik, don't allow to
issue the "star" certificate, but for the dev purposes all we need is the
cert for the localhost, right?

As for the production, we may provide some script + docs how to generate
the cert in the https://letsencrypt.org

my 2c
jk

On Wed, May 25, 2016 at 3:46 PM, Juraci Paix?o Kr?hling <
jpkroehling at redhat.com> wrote:

> On 25.05.2016 15:16, John Mazzitelli wrote:
> >> My next step is to change the agent to accept certs on our keystore.
> >
> > If everything works as I am expecting it to work, you should just need
> to configure the agent's storage adapter to use the WildFly security realm
> where the keystore is defined, and it should "just work." But then again,
> its been a while since I tested the agent using secure comm to the server,
> but that is how I got it to work last time.
> >
> > See http://www.hawkular.org/docs/user/secure-comm.html
>
> Cool ! That would work for the local agent, which is the scenario I was
> planning on working on. For remote agents, we should *not* do this, as
> the keystore includes the private key for the cert, which should be
> known only to the server. But for the remote agent, I expect the server
> to use a proper certificate chain.
>
> >> Related question: are we even allowed to ship such keystores?
> >
> > It is how RHQ does it :-)
>
> That's good to know, thanks!
>
> >> - As mentioned in the previous point, the cert is self-signed. So, you
> >> might need to add "-k" to curl to bypass the cert verification.
> >> - Authentication with client cert is not yet available.
> >
> >
> > I do not know how to tell WildFly in its security-realm to do this same
> kind of bypass... did you look into that? Because the agent will need to be
> told about doing this bypass, too. The way I worked around it was I
> actually put my self-signed cert into my JVM's truststore (which isn't
> something I think we want to ask people to do).
>
> It depends on the HTTP client you are using. In the "production"
> scenarios, no change is needed, as the cert would probably have a valid
> chain.
>
> For dev scenarios, or scenarios where the cert is issued by an unknown
> root CA (like internal certificates), the common practice is to add the
> root CA to the JVM's keystore, similar to what you did. The reason is
> that this cert is not trusted by any known Certificate Authority, so, an
> admin would have to explicitly tell that this cert is known and is to be
> trusted. The cert we will be shipping on the keystore is *not* trusted
> and is intended to be used only on dev scenarios.
>
> Another practice is to do a certificate pinning, ie, tell your HTTP
> client that you know about this specific cert. The disadvantage of this
> is that we'd have to keep the server and client in sync. Looking at your
> instructions on secure-comm.html , this is probably what you are doing
> on the agent side.
>
> Unfortunately, there's no secure solution that I know of that would
> allow us to ship something usable for our production distribution.
>
> There was a thread some time ago on wildfly-dev about auto generating
> certificates on the first boot. I believe this was part of Elytron and
> we might be able to benefit from this in the future.
>
> - Juca.
> _______________________________________________
> 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/20160526/efbbc3da/attachment.html 

From mazz at redhat.com  Thu May 26 09:41:25 2016
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 26 May 2016 09:41:25 -0400 (EDT)
Subject: [Hawkular-dev] Ansible playbooks
In-Reply-To: <CA+aN=MpWFyyFqEoafZdyJCG3QTZhEEhEToND1-DcMtmA0ZkQnA@mail.gmail.com>
References: <CA+aN=MpWFyyFqEoafZdyJCG3QTZhEEhEToND1-DcMtmA0ZkQnA@mail.gmail.com>
Message-ID: <1036924547.1883992.1464270085845.JavaMail.zimbra@redhat.com>

I took Heiko's and built them out some more - those are the ones you see in hawkular/hawkular-agent. You'll probably fine the playbooks in hawkular/hawkular-agent more fully "baked" (it can discover wildflys and inject agents in them, for example).

----- Original Message -----
> I was working on Ansible playbooks (mostly to do a demo, but the work
> extended to actually build the demo...)
> 
> I started with:
> https://github.com/hawkular/hawkular-agent/tree/mazz/ansible/hawkular-wildfly-agent-ansible-playbook
> 
> and then I found:
> https://github.com/pilhuhn/hawkular-agent-ansible
> 
> 
> And I wanted to create a playbook to install Hawkular Server as well.
> 
> I am not very familiar with Ansible (Tower) but it looks like we should have
> a top level repo with all our playbooks, we could also upload to Ansible
> Galaxy when we are comfortable about maintaining those.
> 
> Any comment ?
> 
> 
> Thomas
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lponce at redhat.com  Thu May 26 09:48:44 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 26 May 2016 09:48:44 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Client Ruby
In-Reply-To: <1294415403.1883878.1464270054478.JavaMail.zimbra@redhat.com>
Message-ID: <1915066650.1885733.1464270524457.JavaMail.zimbra@redhat.com>

Hello,

These days we have had several discussions about the hawkular client ruby.

Today there are two main uses cases (Hawkular Metrics from OpenShift and Hawkular Services for MiQ provider) and there are some complexity in the side effects of updating the clients related to the backward compatibility.

I have started to collect some notes about this

https://docs.google.com/document/d/17bAPbBJ6_2wdXAAg_XIQRMi0_RQfODyOEmdOsRjk2v8/edit

I hope it can help to gather all requeriments to have a clear picture of what could be a good decision for future implementations, studying the pros/cons.

Please, feel free to add your comments or thoughts about the topic.

Thanks,
Lucas

From snegrea at redhat.com  Thu May 26 10:31:10 2016
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 26 May 2016 09:31:10 -0500
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
Message-ID: <CADt-fV_1g1pFomS9Cyptjh32+wQ9AEx69XcqxOugK7FytThBuw@mail.gmail.com>

Hello,

I like Jiri's idea. Why not deliver the distribution without a certificate
but add documentation and tooling (scripts or code) to easily install a
certificate from letsencrypt.org? It's the cleanest solution since it will
avoid bundling a self-signed certificate. The main issue I have with
self-signed certificates is that users will most likely not change it,
which is a bigger issue than using unsecured connections.



Thank you,
Stefan Negrea

Software Engineer

On Thu, May 26, 2016 at 4:51 AM, Jiri Kremser <jkremser at redhat.com> wrote:

> Hi,
>   what about creating a default certificate that is issued by a commonly
> accepted root CA (at least in the modern browsers, not sure about JVM if
> there is something similar). On the internets there is a service
> https://letsencrypt.org .I haven't tried yet, but it has also some API
> for doing it automatically, so we can even go further. What I've tried is
> the https://www.startssl.com and it worked perfectly, I can see the green
> https in the chrome :] Both services are for free, but afaik, don't allow
> to issue the "star" certificate, but for the dev purposes all we need is
> the cert for the localhost, right?
>
> As for the production, we may provide some script + docs how to generate
> the cert in the https://letsencrypt.org
>
> my 2c
> jk
>
> On Wed, May 25, 2016 at 3:46 PM, Juraci Paix?o Kr?hling <
> jpkroehling at redhat.com> wrote:
>
>> On 25.05.2016 15:16, John Mazzitelli wrote:
>> >> My next step is to change the agent to accept certs on our keystore.
>> >
>> > If everything works as I am expecting it to work, you should just need
>> to configure the agent's storage adapter to use the WildFly security realm
>> where the keystore is defined, and it should "just work." But then again,
>> its been a while since I tested the agent using secure comm to the server,
>> but that is how I got it to work last time.
>> >
>> > See http://www.hawkular.org/docs/user/secure-comm.html
>>
>> Cool ! That would work for the local agent, which is the scenario I was
>> planning on working on. For remote agents, we should *not* do this, as
>> the keystore includes the private key for the cert, which should be
>> known only to the server. But for the remote agent, I expect the server
>> to use a proper certificate chain.
>>
>> >> Related question: are we even allowed to ship such keystores?
>> >
>> > It is how RHQ does it :-)
>>
>> That's good to know, thanks!
>>
>> >> - As mentioned in the previous point, the cert is self-signed. So, you
>> >> might need to add "-k" to curl to bypass the cert verification.
>> >> - Authentication with client cert is not yet available.
>> >
>> >
>> > I do not know how to tell WildFly in its security-realm to do this same
>> kind of bypass... did you look into that? Because the agent will need to be
>> told about doing this bypass, too. The way I worked around it was I
>> actually put my self-signed cert into my JVM's truststore (which isn't
>> something I think we want to ask people to do).
>>
>> It depends on the HTTP client you are using. In the "production"
>> scenarios, no change is needed, as the cert would probably have a valid
>> chain.
>>
>> For dev scenarios, or scenarios where the cert is issued by an unknown
>> root CA (like internal certificates), the common practice is to add the
>> root CA to the JVM's keystore, similar to what you did. The reason is
>> that this cert is not trusted by any known Certificate Authority, so, an
>> admin would have to explicitly tell that this cert is known and is to be
>> trusted. The cert we will be shipping on the keystore is *not* trusted
>> and is intended to be used only on dev scenarios.
>>
>> Another practice is to do a certificate pinning, ie, tell your HTTP
>> client that you know about this specific cert. The disadvantage of this
>> is that we'd have to keep the server and client in sync. Looking at your
>> instructions on secure-comm.html , this is probably what you are doing
>> on the agent side.
>>
>> Unfortunately, there's no secure solution that I know of that would
>> allow us to ship something usable for our production distribution.
>>
>> There was a thread some time ago on wildfly-dev about auto generating
>> certificates on the first boot. I believe this was part of Elytron and
>> we might be able to benefit from this in the future.
>>
>> - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160526/1b1e2863/attachment-0001.html 

From jkremser at redhat.com  Thu May 26 11:50:22 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Thu, 26 May 2016 17:50:22 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
Message-ID: <CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>

Apart from the Agent, I'm not aware of any REST calls made by individual
components, but I'd need to be aware of any problems that this change
might cause.

It's not a hawkular component, but hawkular ruby client uses only REST to
communicate with hawkular. The underlying rest client has support for
adding explicitly the CA, if not specified it's taken from the system.
Adding client certificates is also possible, but that's not necessary, imho.

There is also an option not to do the certificate check at all by
passing :verify_ssl
=> false. This way we get the encrypted comm channel and save the trouble
with adding the certificates. However, it's less secure, because it's not
guaranteed that the server side is the one who it claims to be.

jk

On Thu, May 26, 2016 at 11:51 AM, Jiri Kremser <jkremser at redhat.com> wrote:

> Hi,
>   what about creating a default certificate that is issued by a commonly
> accepted root CA (at least in the modern browsers, not sure about JVM if
> there is something similar). On the internets there is a service
> https://letsencrypt.org .I haven't tried yet, but it has also some API
> for doing it automatically, so we can even go further. What I've tried is
> the https://www.startssl.com and it worked perfectly, I can see the green
> https in the chrome :] Both services are for free, but afaik, don't allow
> to issue the "star" certificate, but for the dev purposes all we need is
> the cert for the localhost, right?
>
> As for the production, we may provide some script + docs how to generate
> the cert in the https://letsencrypt.org
>
> my 2c
> jk
>
> On Wed, May 25, 2016 at 3:46 PM, Juraci Paix?o Kr?hling <
> jpkroehling at redhat.com> wrote:
>
>> On 25.05.2016 15:16, John Mazzitelli wrote:
>> >> My next step is to change the agent to accept certs on our keystore.
>> >
>> > If everything works as I am expecting it to work, you should just need
>> to configure the agent's storage adapter to use the WildFly security realm
>> where the keystore is defined, and it should "just work." But then again,
>> its been a while since I tested the agent using secure comm to the server,
>> but that is how I got it to work last time.
>> >
>> > See http://www.hawkular.org/docs/user/secure-comm.html
>>
>> Cool ! That would work for the local agent, which is the scenario I was
>> planning on working on. For remote agents, we should *not* do this, as
>> the keystore includes the private key for the cert, which should be
>> known only to the server. But for the remote agent, I expect the server
>> to use a proper certificate chain.
>>
>> >> Related question: are we even allowed to ship such keystores?
>> >
>> > It is how RHQ does it :-)
>>
>> That's good to know, thanks!
>>
>> >> - As mentioned in the previous point, the cert is self-signed. So, you
>> >> might need to add "-k" to curl to bypass the cert verification.
>> >> - Authentication with client cert is not yet available.
>> >
>> >
>> > I do not know how to tell WildFly in its security-realm to do this same
>> kind of bypass... did you look into that? Because the agent will need to be
>> told about doing this bypass, too. The way I worked around it was I
>> actually put my self-signed cert into my JVM's truststore (which isn't
>> something I think we want to ask people to do).
>>
>> It depends on the HTTP client you are using. In the "production"
>> scenarios, no change is needed, as the cert would probably have a valid
>> chain.
>>
>> For dev scenarios, or scenarios where the cert is issued by an unknown
>> root CA (like internal certificates), the common practice is to add the
>> root CA to the JVM's keystore, similar to what you did. The reason is
>> that this cert is not trusted by any known Certificate Authority, so, an
>> admin would have to explicitly tell that this cert is known and is to be
>> trusted. The cert we will be shipping on the keystore is *not* trusted
>> and is intended to be used only on dev scenarios.
>>
>> Another practice is to do a certificate pinning, ie, tell your HTTP
>> client that you know about this specific cert. The disadvantage of this
>> is that we'd have to keep the server and client in sync. Looking at your
>> instructions on secure-comm.html , this is probably what you are doing
>> on the agent side.
>>
>> Unfortunately, there's no secure solution that I know of that would
>> allow us to ship something usable for our production distribution.
>>
>> There was a thread some time ago on wildfly-dev about auto generating
>> certificates on the first boot. I believe this was part of Elytron and
>> we might be able to benefit from this in the future.
>>
>> - Juca.
>> _______________________________________________
>> 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/20160526/dc801697/attachment.html 

From ploffay at redhat.com  Thu May 26 12:03:29 2016
From: ploffay at redhat.com (Pavol Loffay)
Date: Thu, 26 May 2016 18:03:29 +0200
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
Message-ID: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>

I'm happy to announce release 0.2.0.Final of Hawkular Data Mining.

List of major changes:

   - Getting historical metrics from Hawkular Metrics
   - Calculation of prediction/confidence intervals of predicted points
   - Improved REST API for more specific configuration of automatic
   forecaster


Regards,
Pavol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160526/e22ae752/attachment.html 

From gbrown at redhat.com  Thu May 26 12:14:51 2016
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 26 May 2016 12:14:51 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
In-Reply-To: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
References: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
Message-ID: <1777742276.52121219.1464279291384.JavaMail.zimbra@redhat.com>

Congratulations!

Regards
Gary

----- Original Message -----
> I'm happy to announce release 0.2.0.Final of Hawkular Data Mining.
> 
> List of major changes:
> 
> 
>     * Getting historical metrics from Hawkular Metrics
>     * Calculation of prediction/confidence intervals of predicted points
>     * Improved REST API for more specific configuration of automatic
>     forecaster
> 
> Regards,
> Pavol
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From lponce at redhat.com  Thu May 26 12:25:01 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 26 May 2016 12:25:01 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
In-Reply-To: <1777742276.52121219.1464279291384.JavaMail.zimbra@redhat.com>
References: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
	<1777742276.52121219.1464279291384.JavaMail.zimbra@redhat.com>
Message-ID: <1407165318.1953980.1464279901637.JavaMail.zimbra@redhat.com>

+1

Congrats !

----- Mensaje original -----
> De: "Gary Brown" <gbrown at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Jueves, 26 de Mayo 2016 18:14:51
> Asunto: Re: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
> 
> Congratulations!
> 
> Regards
> Gary
> 
> ----- Original Message -----
> > I'm happy to announce release 0.2.0.Final of Hawkular Data Mining.
> > 
> > List of major changes:
> > 
> > 
> >     * Getting historical metrics from Hawkular Metrics
> >     * Calculation of prediction/confidence intervals of predicted points
> >     * Improved REST API for more specific configuration of automatic
> >     forecaster
> > 
> > Regards,
> > Pavol
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mithomps at redhat.com  Thu May 26 14:06:21 2016
From: mithomps at redhat.com (mike thompson)
Date: Thu, 26 May 2016 11:06:21 -0700
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
In-Reply-To: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
References: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
Message-ID: <F70DAC05-17DE-449B-9C2C-3DFC0F5A710D@redhat.com>

Very Nice! Pavol!

> On 26 May 2016, at 09:03, Pavol Loffay <ploffay at redhat.com> wrote:
> 
> I'm happy to announce release 0.2.0.Final of Hawkular Data Mining. 
> 
> List of major changes:
> Getting historical metrics from Hawkular Metrics
> Calculation of prediction/confidence intervals of predicted points
> Improved REST API for more specific configuration of automatic forecaster
> 
> Regards,
> Pavol
> _______________________________________________
> 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/20160526/5fcf05b2/attachment.html 

From jdoyle at redhat.com  Thu May 26 16:27:56 2016
From: jdoyle at redhat.com (John Doyle)
Date: Thu, 26 May 2016 16:27:56 -0400
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
In-Reply-To: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
References: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
Message-ID: <CAKSM3ocj78fy=kB_=w-8FrL+=bF5e4oYusH-A=txLT4HE29VDg@mail.gmail.com>

Congrats Pavol!

On Thu, May 26, 2016 at 12:03 PM, Pavol Loffay <ploffay at redhat.com> wrote:
> I'm happy to announce release 0.2.0.Final of Hawkular Data Mining.
>
> List of major changes:
>
> Getting historical metrics from Hawkular Metrics
> Calculation of prediction/confidence intervals of predicted points
> Improved REST API for more specific configuration of automatic forecaster
>
>
> Regards,
> Pavol
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

From auszon3 at gmail.com  Thu May 26 23:29:16 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Fri, 27 May 2016 03:29:16 +0000
Subject: [Hawkular-dev] inventory standalone server
Message-ID: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>

Hi all,
I?m currently trying to report vertx instance to inventory, therefore I am
doing some experiments that is communicating to the server with REST API.
Wondering if there?s a way not to run an entire hawkular server (because
i?m working on my laptop) but the inventory component alone? or any other
better way to do that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160527/f7a7428c/attachment.html 

From tsegismo at redhat.com  Fri May 27 04:07:42 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 27 May 2016 10:07:42 +0200
Subject: [Hawkular-dev] inventory standalone server
In-Reply-To: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
References: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
Message-ID: <CAHnC0xioZ3f3DfFDhtUhZCmR+oyTHVYp9GDRoxbtVmgXt7Z7aw@mail.gmail.com>

Hey Austin,

Can you describe your laptop setup?

If your laptop resources are constrained, you might try to run an external,
tuned down Cassandra node with ccm (https://github.com/pcmanus/ccm). And
then start the Hawkular server without embedded Cassandra (
http://www.hawkular.org/docs/user/installation-guide.html#_using_an_external_cassandra_cluster
).

Regards,

2016-05-27 5:29 GMT+02:00 Austin Kuo <auszon3 at gmail.com>:

> Hi all,
> I?m currently trying to report vertx instance to inventory, therefore I am
> doing some experiments that is communicating to the server with REST API.
> Wondering if there?s a way not to run an entire hawkular server (because
> i?m working on my laptop) but the inventory component alone? or any other
> better way to do that?
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>


-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160527/f6e1108f/attachment.html 

From ppalaga at redhat.com  Fri May 27 04:53:23 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 27 May 2016 10:53:23 +0200
Subject: [Hawkular-dev] inventory standalone server
In-Reply-To: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
References: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
Message-ID: <57480B03.5000906@redhat.com>

Hi Austin, inline...

On 2016-05-27 05:29, Austin Kuo wrote:
> Hi all,
> I?m currently trying to report vertx instance to inventory, therefore I
> am doing some experiments that is communicating to the server with REST
> API. Wondering if there?s a way not to run an entire hawkular server
> (because i?m working on my laptop) but the inventory component alone?

Yes, that's exactly what we do when running Inventory integration tests.

If you build Inventory with

   maven clean install -Pitest

you can find a ready-to-run minimalistic Hawkular with just Inventory 
and nothing else in 
hawkular-inventory/hawkular-inventory-itest/target/hawkular-inventory-itest-* 
directory.

The user "jdoe" with password "password" is there in the distro.

The distro uses the embedded Cassandra by default, that we tried to make 
as resource-minimalistic as possible too.

If you still face the shortage of system resources with this distro (or 
even when building it), you probably need to increase some of the ulimit 
(linux/mac) settings. These are limits on my laptop:

[ppalaga at slama ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 62872
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 62872
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


Good luck,

-- Peter

From gbrown at redhat.com  Fri May 27 05:07:55 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 May 2016 05:07:55 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
Message-ID: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>

Hi all

As discussed in the recent blog (and demo), Hawkular BTM now provides Application Performance Management (APM), Distributed Tracing (DT) and Business Transaction Management (BTM).

The project was initially started to address the third area, hence being called BTM - however BTM requires the collection of the information used to provide APM and DT - and providing those other views on the information is useful to users.

Due to the wider scope, just wondering whether the BTM name is now misleading. If a project component rename was considered a good idea, then now would probably be the best time to do it, before getting close to a stable 1.0 version?

So two questions:

1) Is a component rename a good idea?

2) If so, any suggestions for a name, either some generic term that encapsulates APM, DT and BTM - or alternatively a completely unrelated name (but then it would not follow the pattern used by other Hawkular components).


Regards
Gary

From theute at redhat.com  Fri May 27 05:11:19 2016
From: theute at redhat.com (Thomas Heute)
Date: Fri, 27 May 2016 11:11:19 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>

I would favor a renaming to "Hawkular <Something>" if we had an idea for a
name that encapsulate the 3 notions... (I don't). I agree that BTM is
confusing now.

On Fri, May 27, 2016 at 11:07 AM, Gary Brown <gbrown at redhat.com> wrote:

> Hi all
>
> As discussed in the recent blog (and demo), Hawkular BTM now provides
> Application Performance Management (APM), Distributed Tracing (DT) and
> Business Transaction Management (BTM).
>
> The project was initially started to address the third area, hence being
> called BTM - however BTM requires the collection of the information used to
> provide APM and DT - and providing those other views on the information is
> useful to users.
>
> Due to the wider scope, just wondering whether the BTM name is now
> misleading. If a project component rename was considered a good idea, then
> now would probably be the best time to do it, before getting close to a
> stable 1.0 version?
>
> So two questions:
>
> 1) Is a component rename a good idea?
>
> 2) If so, any suggestions for a name, either some generic term that
> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> (but then it would not follow the pattern used by other Hawkular
> components).
>
>
> Regards
> Gary
> _______________________________________________
> 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/20160527/ea551939/attachment.html 

From lponce at redhat.com  Fri May 27 05:15:17 2016
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 27 May 2016 05:15:17 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>
Message-ID: <964062431.2106479.1464340517444.JavaMail.zimbra@redhat.com>

Extracting some ideas from MiQ.

They uses the term "Performace" as a wider concept that is focus in the health of the system.

So how it sounds 

 - Hawkular App Performance
 - Hawkular Business Performance ?



----- Mensaje original -----
> De: "Thomas Heute" <theute at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Enviados: Viernes, 27 de Mayo 2016 11:11:19
> Asunto: Re: [Hawkular-dev] BTM or not BTM, that is the question
> 
> I would favor a renaming to "Hawkular <Something>" if we had an idea for a
> name that encapsulate the 3 notions... (I don't). I agree that BTM is
> confusing now.
> 
> On Fri, May 27, 2016 at 11:07 AM, Gary Brown < gbrown at redhat.com > wrote:
> 
> 
> Hi all
> 
> As discussed in the recent blog (and demo), Hawkular BTM now provides
> Application Performance Management (APM), Distributed Tracing (DT) and
> Business Transaction Management (BTM).
> 
> The project was initially started to address the third area, hence being
> called BTM - however BTM requires the collection of the information used to
> provide APM and DT - and providing those other views on the information is
> useful to users.
> 
> Due to the wider scope, just wondering whether the BTM name is now
> misleading. If a project component rename was considered a good idea, then
> now would probably be the best time to do it, before getting close to a
> stable 1.0 version?
> 
> So two questions:
> 
> 1) Is a component rename a good idea?
> 
> 2) If so, any suggestions for a name, either some generic term that
> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> (but then it would not follow the pattern used by other Hawkular
> components).
> 
> 
> 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 lkrejci at redhat.com  Fri May 27 05:23:28 2016
From: lkrejci at redhat.com (Lukas Krejci)
Date: Fri, 27 May 2016 11:23:28 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
References: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
Message-ID: <5979180.3Kdm5lpNeF@localhost.localdomain>

Hawkular Coach

watches your apps and analyses their performance..

The alternative that would follow the naming convention of the rest of the 
Hawkular components would I think be "Hawkular Performance Management" or 
"Hawkular Application Performance" which is a little bit too much of a 
mouthful for my taste...

On Friday, May 27, 2016 05:07:55 AM Gary Brown wrote:
> Hi all
> 
> As discussed in the recent blog (and demo), Hawkular BTM now provides
> Application Performance Management (APM), Distributed Tracing (DT) and
> Business Transaction Management (BTM).
> 
> The project was initially started to address the third area, hence being
> called BTM - however BTM requires the collection of the information used to
> provide APM and DT - and providing those other views on the information is
> useful to users.
> 
> Due to the wider scope, just wondering whether the BTM name is now
> misleading. If a project component rename was considered a good idea, then
> now would probably be the best time to do it, before getting close to a
> stable 1.0 version?
> 
> So two questions:
> 
> 1) Is a component rename a good idea?
> 
> 2) If so, any suggestions for a name, either some generic term that
> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> (but then it would not follow the pattern used by other Hawkular
> components).
> 
> 
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-- 
Lukas Krejci

From gbrown at redhat.com  Fri May 27 05:25:12 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 May 2016 05:25:12 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <964062431.2106479.1464340517444.JavaMail.zimbra@redhat.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>
	<964062431.2106479.1464340517444.JavaMail.zimbra@redhat.com>
Message-ID: <458145327.52246650.1464341112539.JavaMail.zimbra@redhat.com>

Was looking at the wikipedia page for APM: https://en.wikipedia.org/wiki/Application_performance_management

Their definition (conceptual framework) includes user defined 'business transactions' as well, which fits with the project - so possibly Hawkular APM.

Although if inclusion of 'performance' maybe indicates too much of an IT tool, rather than a tool for IT and Business, then possibly Hawkular App Manager?


----- Original Message -----
> Extracting some ideas from MiQ.
> 
> They uses the term "Performace" as a wider concept that is focus in the
> health of the system.
> 
> So how it sounds
> 
>  - Hawkular App Performance
>  - Hawkular Business Performance ?
> 
> 
> 
> ----- Mensaje original -----
> > De: "Thomas Heute" <theute at redhat.com>
> > Para: "Discussions around Hawkular development"
> > <hawkular-dev at lists.jboss.org>
> > Enviados: Viernes, 27 de Mayo 2016 11:11:19
> > Asunto: Re: [Hawkular-dev] BTM or not BTM, that is the question
> > 
> > I would favor a renaming to "Hawkular <Something>" if we had an idea for a
> > name that encapsulate the 3 notions... (I don't). I agree that BTM is
> > confusing now.
> > 
> > On Fri, May 27, 2016 at 11:07 AM, Gary Brown < gbrown at redhat.com > wrote:
> > 
> > 
> > Hi all
> > 
> > As discussed in the recent blog (and demo), Hawkular BTM now provides
> > Application Performance Management (APM), Distributed Tracing (DT) and
> > Business Transaction Management (BTM).
> > 
> > The project was initially started to address the third area, hence being
> > called BTM - however BTM requires the collection of the information used to
> > provide APM and DT - and providing those other views on the information is
> > useful to users.
> > 
> > Due to the wider scope, just wondering whether the BTM name is now
> > misleading. If a project component rename was considered a good idea, then
> > now would probably be the best time to do it, before getting close to a
> > stable 1.0 version?
> > 
> > So two questions:
> > 
> > 1) Is a component rename a good idea?
> > 
> > 2) If so, any suggestions for a name, either some generic term that
> > encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> > (but then it would not follow the pattern used by other Hawkular
> > components).
> > 
> > 
> > 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 jkremser at redhat.com  Fri May 27 05:46:32 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Fri, 27 May 2016 11:46:32 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <458145327.52246650.1464341112539.JavaMail.zimbra@redhat.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>
	<964062431.2106479.1464340517444.JavaMail.zimbra@redhat.com>
	<458145327.52246650.1464341112539.JavaMail.zimbra@redhat.com>
Message-ID: <CAE7VWz-oG2vzo4SbcHghRb5Jd8Y=KqW3h8cWPQZPH9th_Rz1MQ@mail.gmail.com>

Hawkular App Insight or shorter Hawkular Insight.

side note "App" sounds less enterprisy to me than "Application"

On Fri, May 27, 2016 at 11:25 AM, Gary Brown <gbrown at redhat.com> wrote:

> Was looking at the wikipedia page for APM:
> https://en.wikipedia.org/wiki/Application_performance_management
>
> Their definition (conceptual framework) includes user defined 'business
> transactions' as well, which fits with the project - so possibly Hawkular
> APM.
>
> Although if inclusion of 'performance' maybe indicates too much of an IT
> tool, rather than a tool for IT and Business, then possibly Hawkular App
> Manager?
>
>
> ----- Original Message -----
> > Extracting some ideas from MiQ.
> >
> > They uses the term "Performace" as a wider concept that is focus in the
> > health of the system.
> >
> > So how it sounds
> >
> >  - Hawkular App Performance
> >  - Hawkular Business Performance ?
> >
> >
> >
> > ----- Mensaje original -----
> > > De: "Thomas Heute" <theute at redhat.com>
> > > Para: "Discussions around Hawkular development"
> > > <hawkular-dev at lists.jboss.org>
> > > Enviados: Viernes, 27 de Mayo 2016 11:11:19
> > > Asunto: Re: [Hawkular-dev] BTM or not BTM, that is the question
> > >
> > > I would favor a renaming to "Hawkular <Something>" if we had an idea
> for a
> > > name that encapsulate the 3 notions... (I don't). I agree that BTM is
> > > confusing now.
> > >
> > > On Fri, May 27, 2016 at 11:07 AM, Gary Brown < gbrown at redhat.com >
> wrote:
> > >
> > >
> > > Hi all
> > >
> > > As discussed in the recent blog (and demo), Hawkular BTM now provides
> > > Application Performance Management (APM), Distributed Tracing (DT) and
> > > Business Transaction Management (BTM).
> > >
> > > The project was initially started to address the third area, hence
> being
> > > called BTM - however BTM requires the collection of the information
> used to
> > > provide APM and DT - and providing those other views on the
> information is
> > > useful to users.
> > >
> > > Due to the wider scope, just wondering whether the BTM name is now
> > > misleading. If a project component rename was considered a good idea,
> then
> > > now would probably be the best time to do it, before getting close to a
> > > stable 1.0 version?
> > >
> > > So two questions:
> > >
> > > 1) Is a component rename a good idea?
> > >
> > > 2) If so, any suggestions for a name, either some generic term that
> > > encapsulates APM, DT and BTM - or alternatively a completely unrelated
> name
> > > (but then it would not follow the pattern used by other Hawkular
> > > components).
> > >
> > >
> > > Regards
> > > Gary
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160527/45b56209/attachment.html 

From gbrown at redhat.com  Fri May 27 05:52:38 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 May 2016 05:52:38 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <CAE7VWz-oG2vzo4SbcHghRb5Jd8Y=KqW3h8cWPQZPH9th_Rz1MQ@mail.gmail.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CA+aN=MoYmHQtyvNKiNxFkWG3rJP50LSaMWTjM5JDhzZUgq2NbA@mail.gmail.com>
	<964062431.2106479.1464340517444.JavaMail.zimbra@redhat.com>
	<458145327.52246650.1464341112539.JavaMail.zimbra@redhat.com>
	<CAE7VWz-oG2vzo4SbcHghRb5Jd8Y=KqW3h8cWPQZPH9th_Rz1MQ@mail.gmail.com>
Message-ID: <404888152.52253115.1464342758396.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Hawkular App Insight or shorter Hawkular Insight.

Unfortunately I think fuse have a component called "Insight", and used by other companies, so probably would lead to confusion.

> 
> side note "App" sounds less enterprisy to me than "Application"

Agree, but Application is much longer, especially as we would need some other term, ApplicationManager, etc.

Good thing is that every suggestion so far seems to focus more on the application concept, so we are narrowing it down :)

> 
> On Fri, May 27, 2016 at 11:25 AM, Gary Brown < gbrown at redhat.com > wrote:
> 
> 
> Was looking at the wikipedia page for APM:
> https://en.wikipedia.org/wiki/Application_performance_management
> 
> Their definition (conceptual framework) includes user defined 'business
> transactions' as well, which fits with the project - so possibly Hawkular
> APM.
> 
> Although if inclusion of 'performance' maybe indicates too much of an IT
> tool, rather than a tool for IT and Business, then possibly Hawkular App
> Manager?
> 
> 
> ----- Original Message -----
> > Extracting some ideas from MiQ.
> > 
> > They uses the term "Performace" as a wider concept that is focus in the
> > health of the system.
> > 
> > So how it sounds
> > 
> > - Hawkular App Performance
> > - Hawkular Business Performance ?
> > 
> > 
> > 
> > ----- Mensaje original -----
> > > De: "Thomas Heute" < theute at redhat.com >
> > > Para: "Discussions around Hawkular development"
> > > < hawkular-dev at lists.jboss.org >
> > > Enviados: Viernes, 27 de Mayo 2016 11:11:19
> > > Asunto: Re: [Hawkular-dev] BTM or not BTM, that is the question
> > > 
> > > I would favor a renaming to "Hawkular <Something>" if we had an idea for
> > > a
> > > name that encapsulate the 3 notions... (I don't). I agree that BTM is
> > > confusing now.
> > > 
> > > On Fri, May 27, 2016 at 11:07 AM, Gary Brown < gbrown at redhat.com > wrote:
> > > 
> > > 
> > > Hi all
> > > 
> > > As discussed in the recent blog (and demo), Hawkular BTM now provides
> > > Application Performance Management (APM), Distributed Tracing (DT) and
> > > Business Transaction Management (BTM).
> > > 
> > > The project was initially started to address the third area, hence being
> > > called BTM - however BTM requires the collection of the information used
> > > to
> > > provide APM and DT - and providing those other views on the information
> > > is
> > > useful to users.
> > > 
> > > Due to the wider scope, just wondering whether the BTM name is now
> > > misleading. If a project component rename was considered a good idea,
> > > then
> > > now would probably be the best time to do it, before getting close to a
> > > stable 1.0 version?
> > > 
> > > So two questions:
> > > 
> > > 1) Is a component rename a good idea?
> > > 
> > > 2) If so, any suggestions for a name, either some generic term that
> > > encapsulates APM, DT and BTM - or alternatively a completely unrelated
> > > name
> > > (but then it would not follow the pattern used by other Hawkular
> > > components).
> > > 
> > > 
> > > Regards
> > > Gary
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> _______________________________________________
> 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 27 07:01:49 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Fri, 27 May 2016 13:01:49 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
Message-ID: <CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>

2016-05-27 11:07 GMT+02:00 Gary Brown <gbrown at redhat.com>:

> 1) Is a component rename a good idea?
>

I believe so.


>
> 2) If so, any suggestions for a name, either some generic term that
> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> (but then it would not follow the pattern used by other Hawkular
> components).


To me Hawkular APM would be good (in long and short form)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160527/65587ef3/attachment.html 

From ploffay at redhat.com  Fri May 27 09:37:11 2016
From: ploffay at redhat.com (Pavol Loffay)
Date: Fri, 27 May 2016 15:37:11 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>
Message-ID: <CAKLecW-2wBBPooFQ=EEDEtPAWx6OKnEscQY7vLn8aBcBuXxG1Q@mail.gmail.com>

What about:

Hawkular Application Analytics: hawkular-app-analytics (It's part of the
APM)


Pavol

On Fri, May 27, 2016 at 1:01 PM, Thomas Segismont <tsegismo at redhat.com>
wrote:

>
>
> 2016-05-27 11:07 GMT+02:00 Gary Brown <gbrown at redhat.com>:
>
>> 1) Is a component rename a good idea?
>>
>
> I believe so.
>
>
>>
>> 2) If so, any suggestions for a name, either some generic term that
>> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
>> (but then it would not follow the pattern used by other Hawkular
>> components).
>
>
> To me Hawkular APM would be good (in long and short form)
>
> _______________________________________________
> 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/20160527/0eec6f24/attachment.html 

From gbrown at redhat.com  Fri May 27 09:47:16 2016
From: gbrown at redhat.com (Gary Brown)
Date: Fri, 27 May 2016 09:47:16 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <CAKLecW-2wBBPooFQ=EEDEtPAWx6OKnEscQY7vLn8aBcBuXxG1Q@mail.gmail.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>
	<CAKLecW-2wBBPooFQ=EEDEtPAWx6OKnEscQY7vLn8aBcBuXxG1Q@mail.gmail.com>
Message-ID: <1491839371.52295761.1464356836226.JavaMail.zimbra@redhat.com>



----- Original Message -----
> What about:
> 
> Hawkular Application Analytics: hawkular-app-analytics (It's part of the APM)
>

The fact that it is part of the conceptual framework definition for APM, along with Business Transactions, makes a more compelling case to use APM :)

I think it also means we could explore more of the analytics angle in the future. But if we were to use the analytics name in the project title, it would be as limiting/misleading as the BTM name has turned out to be.
 
> Pavol
> 
> On Fri, May 27, 2016 at 1:01 PM, Thomas Segismont < tsegismo at redhat.com >
> wrote:
> 
> 
> 
> 
> 
> 2016-05-27 11:07 GMT+02:00 Gary Brown < gbrown at redhat.com > :
> 
> 
> 1) Is a component rename a good idea?
> 
> I believe so.
> 
> 
> 
> 2) If so, any suggestions for a name, either some generic term that
> encapsulates APM, DT and BTM - or alternatively a completely unrelated name
> (but then it would not follow the pattern used by other Hawkular
> components).
> 
> To me Hawkular APM would be good (in long and short form)
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From theute at redhat.com  Fri May 27 09:48:40 2016
From: theute at redhat.com (Thomas Heute)
Date: Fri, 27 May 2016 15:48:40 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <1491839371.52295761.1464356836226.JavaMail.zimbra@redhat.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>
	<CAKLecW-2wBBPooFQ=EEDEtPAWx6OKnEscQY7vLn8aBcBuXxG1Q@mail.gmail.com>
	<1491839371.52295761.1464356836226.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MoM1ne0+nvTGJdihj95WCxWfswH5HG3YhNDNyV7PZ-Gow@mail.gmail.com>

Hawkular APM seems good indeed (better than BTM)

On Fri, May 27, 2016 at 3:47 PM, Gary Brown <gbrown at redhat.com> wrote:

>
>
> ----- Original Message -----
> > What about:
> >
> > Hawkular Application Analytics: hawkular-app-analytics (It's part of the
> APM)
> >
>
> The fact that it is part of the conceptual framework definition for APM,
> along with Business Transactions, makes a more compelling case to use APM :)
>
> I think it also means we could explore more of the analytics angle in the
> future. But if we were to use the analytics name in the project title, it
> would be as limiting/misleading as the BTM name has turned out to be.
>
> > Pavol
> >
> > On Fri, May 27, 2016 at 1:01 PM, Thomas Segismont < tsegismo at redhat.com
> >
> > wrote:
> >
> >
> >
> >
> >
> > 2016-05-27 11:07 GMT+02:00 Gary Brown < gbrown at redhat.com > :
> >
> >
> > 1) Is a component rename a good idea?
> >
> > I believe so.
> >
> >
> >
> > 2) If so, any suggestions for a name, either some generic term that
> > encapsulates APM, DT and BTM - or alternatively a completely unrelated
> name
> > (but then it would not follow the pattern used by other Hawkular
> > components).
> >
> > To me Hawkular APM would be good (in long and short form)
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.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/20160527/2c27b764/attachment.html 

From jkremser at redhat.com  Fri May 27 13:07:47 2016
From: jkremser at redhat.com (Jiri Kremser)
Date: Fri, 27 May 2016 19:07:47 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
	<CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>
Message-ID: <CAE7VWz8nGoikf0Ga1Up51xZAi8NUeHLrHLE22yh1BD-HcKDMxQ@mail.gmail.com>

Hello *,

  I am adding some tests for hawkular ruby client over SSL and I was able
to make the calls with the SSL verification turned off, but if I turn it
on, the verification phase fails when talking to
hawkular.torii.gva.redhat.com. I am using the right CA .pem file as a param
to the http client.

Using this script https://github.com/mislav/ssl-tools/blob/8b3dec4/doctor.rb
I figured out, it's because of the:

"
The server presented a certificate that could not be verified:
  subject: /O=Red Hat/OU=prod/CN=Intermediate Certificate Authority
  issuer: /C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=Red Hat
IT/CN=Red Hat IT Root CA/emailAddress=infosec at redhat.com
  error code 2: unable to get issuer certificate
"

The root cause is that CA certificate has the empty issuer field. I'll set
up my own nginx as a reverse proxy with a certificate that will pass the
verification for now to record the VCRs for the client, but whatever method
for creating a default certificate we choose, it needs to pass the if
the SSL_VERIFY_PEER flag is set (
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html)

jk

On Thu, May 26, 2016 at 5:50 PM, Jiri Kremser <jkremser at redhat.com> wrote:

> Apart from the Agent, I'm not aware of any REST calls made by individual
> components, but I'd need to be aware of any problems that this change
> might cause.
>
> It's not a hawkular component, but hawkular ruby client uses only REST to
> communicate with hawkular. The underlying rest client has support for
> adding explicitly the CA, if not specified it's taken from the system.
> Adding client certificates is also possible, but that's not necessary, imho.
>
> There is also an option not to do the certificate check at all by passing :verify_ssl
> => false. This way we get the encrypted comm channel and save the trouble
> with adding the certificates. However, it's less secure, because it's not
> guaranteed that the server side is the one who it claims to be.
>
> jk
>
> On Thu, May 26, 2016 at 11:51 AM, Jiri Kremser <jkremser at redhat.com>
> wrote:
>
>> Hi,
>>   what about creating a default certificate that is issued by a commonly
>> accepted root CA (at least in the modern browsers, not sure about JVM if
>> there is something similar). On the internets there is a service
>> https://letsencrypt.org .I haven't tried yet, but it has also some API
>> for doing it automatically, so we can even go further. What I've tried is
>> the https://www.startssl.com and it worked perfectly, I can see the
>> green https in the chrome :] Both services are for free, but afaik, don't
>> allow to issue the "star" certificate, but for the dev purposes all we need
>> is the cert for the localhost, right?
>>
>> As for the production, we may provide some script + docs how to generate
>> the cert in the https://letsencrypt.org
>>
>> my 2c
>> jk
>>
>> On Wed, May 25, 2016 at 3:46 PM, Juraci Paix?o Kr?hling <
>> jpkroehling at redhat.com> wrote:
>>
>>> On 25.05.2016 15:16, John Mazzitelli wrote:
>>> >> My next step is to change the agent to accept certs on our keystore.
>>> >
>>> > If everything works as I am expecting it to work, you should just need
>>> to configure the agent's storage adapter to use the WildFly security realm
>>> where the keystore is defined, and it should "just work." But then again,
>>> its been a while since I tested the agent using secure comm to the server,
>>> but that is how I got it to work last time.
>>> >
>>> > See http://www.hawkular.org/docs/user/secure-comm.html
>>>
>>> Cool ! That would work for the local agent, which is the scenario I was
>>> planning on working on. For remote agents, we should *not* do this, as
>>> the keystore includes the private key for the cert, which should be
>>> known only to the server. But for the remote agent, I expect the server
>>> to use a proper certificate chain.
>>>
>>> >> Related question: are we even allowed to ship such keystores?
>>> >
>>> > It is how RHQ does it :-)
>>>
>>> That's good to know, thanks!
>>>
>>> >> - As mentioned in the previous point, the cert is self-signed. So, you
>>> >> might need to add "-k" to curl to bypass the cert verification.
>>> >> - Authentication with client cert is not yet available.
>>> >
>>> >
>>> > I do not know how to tell WildFly in its security-realm to do this
>>> same kind of bypass... did you look into that? Because the agent will need
>>> to be told about doing this bypass, too. The way I worked around it was I
>>> actually put my self-signed cert into my JVM's truststore (which isn't
>>> something I think we want to ask people to do).
>>>
>>> It depends on the HTTP client you are using. In the "production"
>>> scenarios, no change is needed, as the cert would probably have a valid
>>> chain.
>>>
>>> For dev scenarios, or scenarios where the cert is issued by an unknown
>>> root CA (like internal certificates), the common practice is to add the
>>> root CA to the JVM's keystore, similar to what you did. The reason is
>>> that this cert is not trusted by any known Certificate Authority, so, an
>>> admin would have to explicitly tell that this cert is known and is to be
>>> trusted. The cert we will be shipping on the keystore is *not* trusted
>>> and is intended to be used only on dev scenarios.
>>>
>>> Another practice is to do a certificate pinning, ie, tell your HTTP
>>> client that you know about this specific cert. The disadvantage of this
>>> is that we'd have to keep the server and client in sync. Looking at your
>>> instructions on secure-comm.html , this is probably what you are doing
>>> on the agent side.
>>>
>>> Unfortunately, there's no secure solution that I know of that would
>>> allow us to ship something usable for our production distribution.
>>>
>>> There was a thread some time ago on wildfly-dev about auto generating
>>> certificates on the first boot. I believe this was part of Elytron and
>>> we might be able to benefit from this in the future.
>>>
>>> - Juca.
>>> _______________________________________________
>>> 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/20160527/62b74cc2/attachment.html 

From auszon3 at gmail.com  Fri May 27 19:26:27 2016
From: auszon3 at gmail.com (Austin Kuo)
Date: Fri, 27 May 2016 23:26:27 +0000
Subject: [Hawkular-dev] inventory standalone server
In-Reply-To: <57480B03.5000906@redhat.com>
References: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
	<57480B03.5000906@redhat.com>
Message-ID: <CAJ5TdTm4PW86eDZPxdpg-1wS9HARE97UpjQ4hEVkKaB1L8Mkng@mail.gmail.com>

My laptop is macbook pro mid 2012, 8G ram, intel i5 2.5GHz.
I will try that. :)

On Fri, May 27, 2016 at 4:53 PM Peter Palaga <ppalaga at redhat.com> wrote:

> Hi Austin, inline...
>
> On 2016-05-27 05:29, Austin Kuo wrote:
> > Hi all,
> > I?m currently trying to report vertx instance to inventory, therefore I
> > am doing some experiments that is communicating to the server with REST
> > API. Wondering if there?s a way not to run an entire hawkular server
> > (because i?m working on my laptop) but the inventory component alone?
>
> Yes, that's exactly what we do when running Inventory integration tests.
>
> If you build Inventory with
>
>    maven clean install -Pitest
>
> you can find a ready-to-run minimalistic Hawkular with just Inventory
> and nothing else in
>
> hawkular-inventory/hawkular-inventory-itest/target/hawkular-inventory-itest-*
> directory.
>
> The user "jdoe" with password "password" is there in the distro.
>
> The distro uses the embedded Cassandra by default, that we tried to make
> as resource-minimalistic as possible too.
>
> If you still face the shortage of system resources with this distro (or
> even when building it), you probably need to increase some of the ulimit
> (linux/mac) settings. These are limits on my laptop:
>
> [ppalaga at slama ~]$ ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 62872
> max locked memory       (kbytes, -l) 64
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 62872
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
>
>
> Good luck,
>
> -- Peter
> _______________________________________________
> 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/20160527/7ab23c79/attachment-0001.html 

From jpkroehling at redhat.com  Mon May 30 03:14:46 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 30 May 2016 09:14:46 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
Message-ID: <d97ce328-1f5f-6742-d128-2e42949db018@redhat.com>

On 26.05.2016 11:51, Jiri Kremser wrote:
>   what about creating a default certificate that is issued by a commonly
> accepted root CA (at least in the modern browsers, not sure about JVM if
> there is something similar). On the internets there is a service
> https://letsencrypt.org .I haven't tried yet, but it has also some API
> for doing it automatically, so we can even go further. What I've tried
> is the https://www.startssl.com and it worked perfectly, I can see the
> green https in the chrome :] Both services are for free, but afaik,
> don't allow to issue the "star" certificate, but for the dev purposes
> all we need is the cert for the localhost, right?

Not sure I got what you mean. Any issuer requires to have the real name 
for the host you are registering. So, you can't register "localhost" :) 
You'd have to register something like jenkins.kroehling.de (this uses 
Let's Encrypt). For Let's Encrypt, it's automated in the way that you 
tell it that you want to register "hawkular.domain.tld" and it will make 
an HTTP call to 
"http://hawkular.domain.tld/letsencrypt-some-file-created-by-cli". So, 
this requires the client to have a functional DNS name.

But even if it were possible to register a name like localhost (such as 
"hawkular"), your certificate would be revoked by the issuer if you 
exposed your private key. One of the common terms among all certificate 
providers is that you should take reasonable steps to protect your keys.

- Juca.

From jpkroehling at redhat.com  Mon May 30 03:18:21 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 30 May 2016 09:18:21 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CADt-fV_1g1pFomS9Cyptjh32+wQ9AEx69XcqxOugK7FytThBuw@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
	<CADt-fV_1g1pFomS9Cyptjh32+wQ9AEx69XcqxOugK7FytThBuw@mail.gmail.com>
Message-ID: <99be605a-3769-fd1a-5399-24ecd7e5289a@redhat.com>

On 26.05.2016 16:31, Stefan Negrea wrote:
> I like Jiri's idea. Why not deliver the distribution without a
> certificate but add documentation and tooling (scripts or code) to
> easily install a certificate from letsencrypt.org
> <http://letsencrypt.org>? It's the cleanest solution since it will avoid
> bundling a self-signed certificate.

I believe there was a discussion some time ago on Elytron on adding 
something like this to Wildfly proper. I'll check what's the current 
status on this.

 > The main issue I have with
> self-signed certificates is that users will most likely not change it,
> which is a bigger issue than using unsecured connections.

We are not shipping any certs on the proper distribution. We are adding 
the self signed only for dev builds.

- Juca.

From jpkroehling at redhat.com  Mon May 30 03:20:34 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 30 May 2016 09:20:34 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
	<CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>
Message-ID: <e7ddb65d-cc84-f352-2d06-fabee089fa4c@redhat.com>

On 26.05.2016 17:50, Jiri Kremser wrote:
> There is also an option not to do the certificate check at all by
> passing :verify_ssl => false. This way we get the encrypted comm channel
> and save the trouble with adding the certificates. However, it's less
> secure, because it's not guaranteed that the server side is the one who
> it claims to be.

No client should *ever* have this enabled on real code. If we need this 
on the Gem or on other clients, I'd halt the task of adding self signed 
certs for dev builds, as it would void real security on production boxes.

- Juca.

From hrupp at redhat.com  Mon May 30 03:29:40 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 30 May 2016 09:29:40 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <CA+aN=MoM1ne0+nvTGJdihj95WCxWfswH5HG3YhNDNyV7PZ-Gow@mail.gmail.com>
References: <775044415.52240478.1464339652854.JavaMail.zimbra@redhat.com>
	<775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<CAHnC0xinjZ2f6OCw6AWy2FDRVx7S-E121sDMNLFQqx+_DZemyw@mail.gmail.com>
	<CAKLecW-2wBBPooFQ=EEDEtPAWx6OKnEscQY7vLn8aBcBuXxG1Q@mail.gmail.com>
	<1491839371.52295761.1464356836226.JavaMail.zimbra@redhat.com>
	<CA+aN=MoM1ne0+nvTGJdihj95WCxWfswH5HG3YhNDNyV7PZ-Gow@mail.gmail.com>
Message-ID: <253AEC3B-D892-4D9C-A1B0-5EE1EEA88C15@redhat.com>

On 27 May 2016, at 15:48, Thomas Heute wrote:

> Hawkular APM seems good indeed (better than BTM)
Yep

While I also like 'Hawkular App Insight' I fear that
when talking it will mostly be 'Hawkular app inside' :)
Also 'Insight' is taken by that Red Hat Access Insight already.

From jpkroehling at redhat.com  Mon May 30 03:38:47 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 30 May 2016 09:38:47 +0200
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
References: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
Message-ID: <69b8a338-8c89-110a-42db-702ec177a822@redhat.com>

On 27.05.2016 11:07, Gary Brown wrote:
> 1) Is a component rename a good idea?

Yes :)

> 2) If so, any suggestions for a name, either some generic term that encapsulates APM, DT and BTM - or alternatively a completely unrelated name (but then it would not follow the pattern used by other Hawkular components).

Hawkular APM looks good.

- Juca.

From tsegismo at redhat.com  Mon May 30 03:55:53 2016
From: tsegismo at redhat.com (Thomas Segismont)
Date: Mon, 30 May 2016 09:55:53 +0200
Subject: [Hawkular-dev] inventory standalone server
In-Reply-To: <CAJ5TdTm4PW86eDZPxdpg-1wS9HARE97UpjQ4hEVkKaB1L8Mkng@mail.gmail.com>
References: <CAJ5TdTnA_DN7m12d-Vi9327D8uEq5P1o8cXMWtaCZqMwL-eRew@mail.gmail.com>
	<57480B03.5000906@redhat.com>
	<CAJ5TdTm4PW86eDZPxdpg-1wS9HARE97UpjQ4hEVkKaB1L8Mkng@mail.gmail.com>
Message-ID: <CAHnC0xi=ZyeDcxc_-_WK14G3mUzNdbuvAwcKgFeUzZNymV9VwQ@mail.gmail.com>

With such a config you should have no issue building and running. You can
start working with an Inventory standalone build. But sooner or later we
will have to fix your Hawlular master build issue.

2016-05-28 1:26 GMT+02:00 Austin Kuo <auszon3 at gmail.com>:

> My laptop is macbook pro mid 2012, 8G ram, intel i5 2.5GHz.
> I will try that. :)
>
> On Fri, May 27, 2016 at 4:53 PM Peter Palaga <ppalaga at redhat.com> wrote:
>
>> Hi Austin, inline...
>>
>> On 2016-05-27 05:29, Austin Kuo wrote:
>> > Hi all,
>> > I?m currently trying to report vertx instance to inventory, therefore I
>> > am doing some experiments that is communicating to the server with REST
>> > API. Wondering if there?s a way not to run an entire hawkular server
>> > (because i?m working on my laptop) but the inventory component alone?
>>
>> Yes, that's exactly what we do when running Inventory integration tests.
>>
>> If you build Inventory with
>>
>>    maven clean install -Pitest
>>
>> you can find a ready-to-run minimalistic Hawkular with just Inventory
>> and nothing else in
>>
>> hawkular-inventory/hawkular-inventory-itest/target/hawkular-inventory-itest-*
>> directory.
>>
>> The user "jdoe" with password "password" is there in the distro.
>>
>> The distro uses the embedded Cassandra by default, that we tried to make
>> as resource-minimalistic as possible too.
>>
>> If you still face the shortage of system resources with this distro (or
>> even when building it), you probably need to increase some of the ulimit
>> (linux/mac) settings. These are limits on my laptop:
>>
>> [ppalaga at slama ~]$ ulimit -a
>> core file size          (blocks, -c) 0
>> data seg size           (kbytes, -d) unlimited
>> scheduling priority             (-e) 0
>> file size               (blocks, -f) unlimited
>> pending signals                 (-i) 62872
>> max locked memory       (kbytes, -l) 64
>> max memory size         (kbytes, -m) unlimited
>> open files                      (-n) 1024
>> pipe size            (512 bytes, -p) 8
>> POSIX message queues     (bytes, -q) 819200
>> real-time priority              (-r) 0
>> stack size              (kbytes, -s) 8192
>> cpu time               (seconds, -t) unlimited
>> max user processes              (-u) 62872
>> virtual memory          (kbytes, -v) unlimited
>> file locks                      (-x) unlimited
>>
>>
>> Good luck,
>>
>> -- 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
>
>


-- 
Thomas Segismont
JBoss ON Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160530/0c6d5d0f/attachment.html 

From hrupp at redhat.com  Mon May 30 05:32:52 2016
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 30 May 2016 11:32:52 +0200
Subject: [Hawkular-dev] Hawkular Data Mining 0.2.0.Final Released
In-Reply-To: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
References: <CAKLecW-G4HRbfU--CMPK2FeJDReVh6LcoduPk1QpnLg-wf_MSw@mail.gmail.com>
Message-ID: <2228E52D-4AC1-4995-A19A-D8D3D20BAD95@redhat.com>

On 26 May 2016, at 18:03, Pavol Loffay wrote:

> I'm happy to announce release 0.2.0.Final of Hawkular Data Mining.

Blog post or it did not happen :-)

Congrats!

From anuj1708 at gmail.com  Tue May 31 02:44:15 2016
From: anuj1708 at gmail.com (Anuj Garg)
Date: Tue, 31 May 2016 12:14:15 +0530
Subject: [Hawkular-dev] Progress Report on Android Client of Hawkular
Message-ID: <CALZCyhD3aAEgfrBgy+DO8Zn1W5MAq2BZGmf=jGr9ZuYQ-X8RqA@mail.gmail.com>

Hello,

I am Anuj. Final year computer Science graduation student and currently
working on Android Client of Hawkular as my GSoC Project.

It is my first report of what is going on the client recently.

*What have been accomplished till yet*

-> A detail screen for alert have been introduced from where you can change
the state of alert read important detail about it. Read and send comments
on the alert.


-> Previously Android client showed only Open Alerts which have been
changed to something similar server. By it shows {OPEN & ACK} when you
press '+' sign it includes resolved alerts.

-> As more status type of alerts are being displayed so, state of alert is
also added in the list view. For which I need some suggestions if this one
is OK, or I should use symbols instead.

*Video of current work*

https://drive.google.com/file/d/0B8tYKC1-UERHSDVSa1hGQ3VEbzQ/view?usp=sharing

*What to come soon*

-> From detailed alert, jump to trigger to view or alter the trigger.

-> Tabbed pane for list of alerts and associated triggers with that
resources.

-> Detail screen of triggers with enabling, disabling the trigger.


Please suggest if any changes are to be done.

Thanks,

Anuj Garg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160531/4aea5494/attachment-0001.html 

From jpkroehling at redhat.com  Tue May 31 05:59:49 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Tue, 31 May 2016 11:59:49 +0200
Subject: [Hawkular-dev] SSL by default
In-Reply-To: <CAE7VWz8nGoikf0Ga1Up51xZAi8NUeHLrHLE22yh1BD-HcKDMxQ@mail.gmail.com>
References: <ffb02462-5cb5-acba-f543-33d8a3c36cd3@redhat.com>
	<847004311.1484021.1464182215107.JavaMail.zimbra@redhat.com>
	<c0d7faba-61f7-6dc3-5308-a51e3a0ae1ac@redhat.com>
	<CAE7VWz8DafK+QjOTzF28To3WQiL_vGu0gdMyL_3PeteHgDm-bA@mail.gmail.com>
	<CAE7VWz_-Q3jCEBAfZ4a4f+nU29K7Dvpbm3MruPoRpa9XujOVrg@mail.gmail.com>
	<CAE7VWz8nGoikf0Ga1Up51xZAi8NUeHLrHLE22yh1BD-HcKDMxQ@mail.gmail.com>
Message-ID: <6f34b7dc-e3bb-7f3f-eb89-70cda4a83f1d@redhat.com>

On 27.05.2016 19:07, Jiri Kremser wrote:
> "
> The server presented a certificate that could not be verified:
>   subject: /O=Red Hat/OU=prod/CN=Intermediate Certificate Authority
>   issuer: /C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=Red Hat
> IT/CN=Red Hat IT Root CA/emailAddress=infosec at redhat.com
> <mailto:infosec at redhat.com>
>   error code 2: unable to get issuer certificate
> "
>
> The root cause is that CA certificate has the empty issuer field. I'll
> set up my own nginx as a reverse proxy with a certificate that will pass
> the verification for now to record the VCRs for the client, but whatever
> method for creating a default certificate we choose, it needs to pass
> the if the SSL_VERIFY_PEER flag is set
> (https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html)

I'm not sure I understand the problem. Note that this is a certificate 
generated by a Red Hat internal CA, so, you might need to import Red 
Hat's root CA.

- Juca.

From ppalaga at redhat.com  Tue May 31 07:03:43 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 31 May 2016 13:03:43 +0200
Subject: [Hawkular-dev] Metrics: Cassandra Driver timeouts during the build
Message-ID: <844620e9-73d1-21d1-3a7f-a73f7e6bfff6@redhat.com>

Hi *,

Short version: doubling the read timeouts [1] for all three uses of 
Cassandra Driver solved the problem for me. Is this a good idea? Can 
anybody see a better solution to my problem?


Long version:

https://issues.jboss.org/browse/HWKMETRICS-404

As some of you already know from my complaints on IRC, I have not been 
able to build Metrics since a couple of weeks.

My builds failed mostly on core-services but sometimes also in 
configuration-service and resr-tests-jaxrs, the error always being the same:

com.datastax.driver.core.exceptions.NoHostAvailableException: All 
host(s) tried for query failed (tried: /127.0.0.1:9042 
(com.datastax.driver.core.exceptions.OperationTimedOutException: 
[/127.0.0.1] Timed out waiting for server response))

The whole build log: http://paste.fedoraproject.org/372623/46116551/

This started happening at some point after my PR 
https://github.com/hawkular/hawkular-metrics/pull/478 was merged. I do 
not say this PR is the cause, this is just an attempt to narrow down the 
set of commits that might have introduced the problem.

As nobody else (incl. Travis) complained about anything similar, I was 
thinking the issue must be somewhere in my environment. I double checked 
I use the right Cassandra version, ulimits, Java version, Maven version, 
system updates, but nothing helped.

Then I tried doubling the read timeouts [1] for all three uses of 
Cassandra Driver and the build started passing again. Is this a good 
idea? Can anybody see a better solution to my problem?

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

From fbrychta at redhat.com  Tue May 31 08:18:54 2016
From: fbrychta at redhat.com (Filip Brychta)
Date: Tue, 31 May 2016 08:18:54 -0400 (EDT)
Subject: [Hawkular-dev] Metrics: Cassandra Driver timeouts during the
 build
In-Reply-To: <844620e9-73d1-21d1-3a7f-a73f7e6bfff6@redhat.com>
References: <844620e9-73d1-21d1-3a7f-a73f7e6bfff6@redhat.com>
Message-ID: <658654681.33190154.1464697134777.JavaMail.zimbra@redhat.com>

I've seen this exception several times but only when hitting h-metrics with heavy load -> if there is no load it will be probably env issue.
I also noticed that it takes longer to start up cassandra version 3.x then 2.x. Is the cassandra node fully up before starting h-metrics?

Filip


----- Original Message -----
> Hi *,
> 
> Short version: doubling the read timeouts [1] for all three uses of
> Cassandra Driver solved the problem for me. Is this a good idea? Can
> anybody see a better solution to my problem?
> 
> 
> Long version:
> 
> https://issues.jboss.org/browse/HWKMETRICS-404
> 
> As some of you already know from my complaints on IRC, I have not been
> able to build Metrics since a couple of weeks.
> 
> My builds failed mostly on core-services but sometimes also in
> configuration-service and resr-tests-jaxrs, the error always being the same:
> 
> com.datastax.driver.core.exceptions.NoHostAvailableException: All
> host(s) tried for query failed (tried: /127.0.0.1:9042
> (com.datastax.driver.core.exceptions.OperationTimedOutException:
> [/127.0.0.1] Timed out waiting for server response))
> 
> The whole build log: http://paste.fedoraproject.org/372623/46116551/
> 
> This started happening at some point after my PR
> https://github.com/hawkular/hawkular-metrics/pull/478 was merged. I do
> not say this PR is the cause, this is just an attempt to narrow down the
> set of commits that might have introduced the problem.
> 
> As nobody else (incl. Travis) complained about anything similar, I was
> thinking the issue must be somewhere in my environment. I double checked
> I use the right Cassandra version, ulimits, Java version, Maven version,
> system updates, but nothing helped.
> 
> Then I tried doubling the read timeouts [1] for all three uses of
> Cassandra Driver and the build started passing again. Is this a good
> idea? Can anybody see a better solution to my problem?
> 
> [1] https://github.com/hawkular/hawkular-metrics/pull/510
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From ppalaga at redhat.com  Tue May 31 09:08:30 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 31 May 2016 15:08:30 +0200
Subject: [Hawkular-dev] Metrics: Cassandra Driver timeouts during the
 build
In-Reply-To: <658654681.33190154.1464697134777.JavaMail.zimbra@redhat.com>
References: <844620e9-73d1-21d1-3a7f-a73f7e6bfff6@redhat.com>
	<658654681.33190154.1464697134777.JavaMail.zimbra@redhat.com>
Message-ID: <6c58ab24-cbff-1664-bf7a-ec4536a7f0ca@redhat.com>

Ahoj Filip, inline...

On 2016-05-31 14:18, Filip Brychta wrote:
> I've seen this exception several times but only when hitting h-metrics with heavy load -> if there is no load it will be probably env issue.

Any ideas which part of the env should I check?

> I also noticed that it takes longer to start up cassandra version 3.x then 2.x. Is the cassandra node fully up before starting h-metrics?

Yes, I have run ccm start in the morning and the builds are failing 
constantly during the whole day.

-- P

> Filip
>
>
> ----- Original Message -----
>> Hi *,
>>
>> Short version: doubling the read timeouts [1] for all three uses of
>> Cassandra Driver solved the problem for me. Is this a good idea? Can
>> anybody see a better solution to my problem?
>>
>>
>> Long version:
>>
>> https://issues.jboss.org/browse/HWKMETRICS-404
>>
>> As some of you already know from my complaints on IRC, I have not been
>> able to build Metrics since a couple of weeks.
>>
>> My builds failed mostly on core-services but sometimes also in
>> configuration-service and resr-tests-jaxrs, the error always being the same:
>>
>> com.datastax.driver.core.exceptions.NoHostAvailableException: All
>> host(s) tried for query failed (tried: /127.0.0.1:9042
>> (com.datastax.driver.core.exceptions.OperationTimedOutException:
>> [/127.0.0.1] Timed out waiting for server response))
>>
>> The whole build log: http://paste.fedoraproject.org/372623/46116551/
>>
>> This started happening at some point after my PR
>> https://github.com/hawkular/hawkular-metrics/pull/478 was merged. I do
>> not say this PR is the cause, this is just an attempt to narrow down the
>> set of commits that might have introduced the problem.
>>
>> As nobody else (incl. Travis) complained about anything similar, I was
>> thinking the issue must be somewhere in my environment. I double checked
>> I use the right Cassandra version, ulimits, Java version, Maven version,
>> system updates, but nothing helped.
>>
>> Then I tried doubling the read timeouts [1] for all three uses of
>> Cassandra Driver and the build started passing again. Is this a good
>> idea? Can anybody see a better solution to my problem?
>>
>> [1] https://github.com/hawkular/hawkular-metrics/pull/510
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.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 31 12:28:38 2016
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 31 May 2016 12:28:38 -0400 (EDT)
Subject: [Hawkular-dev] BTM or not BTM, that is the question
In-Reply-To: <69b8a338-8c89-110a-42db-702ec177a822@redhat.com>
References: <775714457.52241211.1464340075186.JavaMail.zimbra@redhat.com>
	<69b8a338-8c89-110a-42db-702ec177a822@redhat.com>
Message-ID: <1557177335.53535347.1464712118222.JavaMail.zimbra@redhat.com>

Thanks to everyone who contributed to the discussion.

We've now got approval to change the name to Hawkular APM - so this change will happen over the course of the next week or two. Once completed, I'll blog about it.

Regards
Gary


----- Original Message -----
> On 27.05.2016 11:07, Gary Brown wrote:
> > 1) Is a component rename a good idea?
> 
> Yes :)
> 
> > 2) If so, any suggestions for a name, either some generic term that
> > encapsulates APM, DT and BTM - or alternatively a completely unrelated
> > name (but then it would not follow the pattern used by other Hawkular
> > components).
> 
> Hawkular APM looks good.
> 
> - Juca.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>