From lponce at redhat.com  Thu Mar  2 12:51:46 2017
From: lponce at redhat.com (Lucas Ponce)
Date: Thu, 2 Mar 2017 18:51:46 +0100
Subject: [Hawkular-dev] Cross-Tenant endpoints in Alerting on OS
In-Reply-To: <b4d5bb34-ba1b-dd87-7e5b-22c3ef847c89@redhat.com>
References: <c301209d-4065-bcb4-cd67-751b7211ff58@redhat.com>
	<1655878501.37837405.1487891140663.JavaMail.zimbra@redhat.com>
	<b4d5bb34-ba1b-dd87-7e5b-22c3ef847c89@redhat.com>
Message-ID: <CAGUuq3Vc1Y-=YkZkNY0PtcbBgiHdgRuv2Q3gRD0YvF67ojNYNQ@mail.gmail.com>

What is the result of this discussion ?

If I understood well, even if we had a discoordination for these endpoints,
those are not a security concern, or is there any additional test to
perform to validate this ?

The original motivation is still valid, as for Alerting these two endpoints
are demanded for users.

Do you want any additional enhancement around this ?

I can see two potential actions:
- Perhaps to move the /admin endpoint prefix to /tenants to align with the
same in metrics.
- Extend the security filter on /admin (/tenants) endpoint.

Thanks,
Lucas



On Fri, Feb 24, 2017 at 2:04 PM, Jay Shaughnessy <jshaughn at redhat.com>
wrote:

>
> On 2/23/2017 6:05 PM, Matt Wringe wrote:
> > Is there any reason why this being sent in private emails and not to a
> mailing list?
>
> Matt, Not really, sending to dev-list for anyone interested in the
> discussion...
>
> > ----- Original Message -----
> >> There was an IRC discussion today about $SUBJECT.  Here is a summary of
> >> a conversation Matt and I had to drill down into whether there was a
> >> cross-tenant security concern with the Alerting API in OS.  In short,
> >> the answer seems to be no. Alerting (1.4+) offers two endpoints for
> >> fetching cross-tenant: /alerts/admin/alerts and /alerts/admin/events.
> >> Note that the 'admin' is just in the path, and was chosen just to group
> >> what we deemed were admin-level endpoints, the first two of which are
> >> these cross-tenant fetches.  The 'admin' does not mean anything else in
> >> this context, it does not reflect a special user or tenant.  The way
> >> these endpoints work is that that they accept a Hawkular-Tenant HTTP
> >> header that can be a comma-separated-list of tenantIds.  As with any of
> >> the alerting endpoints.  Alerting does not perform any security in the
> >> request handling.  But, in OS the HAM deployments both have the OS
> >> security filtering in place. That filtering does two things, for a
> >> cluster-admin user it's basically a pass-thru, the CSL Hawkular-Tenant
> >> header is passed on and the endpoints work.  For all other users the
> >> Hawkular-Tenant header is validated.  Because each project name is a
> >> tenant name, the value must match a project name.  As such, the
> >> validation fails if a CSL is supplied.  This is decent behavior for now
> >> as it prevents any undesired access.  Note that as a corner-case, these
> >> endpoints will work fine if the header just supplies a single tenant, in
> >> which case they are basically the same as the typical single-tenant
> >> fetch endpoints.
> > What has happened is now Alerts is not considering the Hawkular-tenant
> header to contain just a string, but a comma separated lists of strings.
> >
> > eg "Hawkular-tenant: projectA,projectB"
>
> Note, not in general, comma-separated-lists handled only for the two
> cross-tenant endpoints mentioned above.
>
>
> > The OpenShift filter still considers this to be a string, so it will
> check with OpenShift if the user has permission to access the project named
> with a string value of "projectA,projectB". Since a project cannot have a
> ',' within its name, this check will always fail and return an access
> denied error.
> >
> > If the user is a cluster level user they are given access to everything,
> even impossibly named projects. So a cluster level user will happen to be
> able to use the current setup just due to how this works.
> >
> > So there doesn't appear to be any security issue that we need to deal
> with immediately, but we do probably want to handle this properly in the
> future. It might not be too difficult to add support to the tenant to
> consider a csl.
> >
> >> I'm not totally familiar with the Metrics approach to cross-tenant
> >> handling but going forward we (Metrics and Alerting) should probably
> >> look for some consistency, if possible.  Moreover, any solution should
> >> reflect what best serves OS.  The idea of a CSL for the header is fairly
> >> simple and flexible.  It may be something to consider, for the OS filter
> >> it would mean validating that the bearer has access to each of the
> >> individual tenants before forwarding the request.
> > I don't recall any meetings about adding multitenancy to Metrics. From
> what I recall, there is no plans at all to introduce multitenancy at all
> for metrics.
> >
> > If I was aware of this discussion when this was brought up for alerts, I
> would have probably objected to the endpoint being called 'admin' since I
> don't think that reflects what the true purpose of this is suppose to be.
> Its not really an admin endpoint, but an endpoint for cross-tenancy. I
> could have access to projectA and projectB, but not be an 'admin'
> >
> > If we are making changes like this which affect security, I would really
> like to be notified so that I can make sure our security filters will
> function properly. Even if I am in the meeting when its being discussed it
> would be good to ping me on the PR with the actual implementation.
>
> Of course.  This stuff went in in mid November and at that time we (in
> alerting) were really just getting settled with the initial integration
> into metrics for OS.  Going forward I think we have a better idea of
> what is relevant to OS and can more easily flag items of import.
>
> _______________________________________________
> 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/20170302/cc3d2ebf/attachment.html 

From mwringe at redhat.com  Thu Mar  2 16:52:55 2017
From: mwringe at redhat.com (Matt Wringe)
Date: Thu, 2 Mar 2017 16:52:55 -0500 (EST)
Subject: [Hawkular-dev] Cross-Tenant endpoints in Alerting on OS
In-Reply-To: <CAGUuq3Vc1Y-=YkZkNY0PtcbBgiHdgRuv2Q3gRD0YvF67ojNYNQ@mail.gmail.com>
References: <c301209d-4065-bcb4-cd67-751b7211ff58@redhat.com>
	<1655878501.37837405.1487891140663.JavaMail.zimbra@redhat.com>
	<b4d5bb34-ba1b-dd87-7e5b-22c3ef847c89@redhat.com>
	<CAGUuq3Vc1Y-=YkZkNY0PtcbBgiHdgRuv2Q3gRD0YvF67ojNYNQ@mail.gmail.com>
Message-ID: <1146619743.41418571.1488491575325.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lucas Ponce" <lponce at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Thursday, 2 March, 2017 12:51:46 PM
> Subject: Re: [Hawkular-dev] Cross-Tenant endpoints in Alerting on OS
> 
> What is the result of this discussion ?

I think the result is that we need to have a meeting over cross tenancy and how it should be applied.

Supporting cross-tenancy is a fairly large architectural change and should be affecting multiple components.

At the very least we need to discuss how to properly handle it with regards to security integration with OpenShift.

> 
> If I understood well, even if we had a discoordination for these endpoints,
> those are not a security concern, or is there any additional test to perform
> to validate this ?
> 
> The original motivation is still valid, as for Alerting these two endpoints
> are demanded for users.

The validity of any feature request can always be up for discussion :)

> Do you want any additional enhancement around this ?
> 
> I can see two potential actions:
> - Perhaps to move the /admin endpoint prefix to /tenants to align with the
> same in metrics.

The /tenants endpoint in metrics is not for cross-tenant operations. Its probably not a great idea to to have two endpoints of the same name between components which do different things.

> - Extend the security filter on /admin (/tenants) endpoint.
> 
> Thanks,
> Lucas
> 
> 
> 
> On Fri, Feb 24, 2017 at 2:04 PM, Jay Shaughnessy < jshaughn at redhat.com >
> wrote:
> 
> 
> 
> On 2/23/2017 6:05 PM, Matt Wringe wrote:
> > Is there any reason why this being sent in private emails and not to a
> > mailing list?
> 
> Matt, Not really, sending to dev-list for anyone interested in the
> discussion...
> 
> > ----- Original Message -----
> >> There was an IRC discussion today about $SUBJECT. Here is a summary of
> >> a conversation Matt and I had to drill down into whether there was a
> >> cross-tenant security concern with the Alerting API in OS. In short,
> >> the answer seems to be no. Alerting (1.4+) offers two endpoints for
> >> fetching cross-tenant: /alerts/admin/alerts and /alerts/admin/events.
> >> Note that the 'admin' is just in the path, and was chosen just to group
> >> what we deemed were admin-level endpoints, the first two of which are
> >> these cross-tenant fetches. The 'admin' does not mean anything else in
> >> this context, it does not reflect a special user or tenant. The way
> >> these endpoints work is that that they accept a Hawkular-Tenant HTTP
> >> header that can be a comma-separated-list of tenantIds. As with any of
> >> the alerting endpoints. Alerting does not perform any security in the
> >> request handling. But, in OS the HAM deployments both have the OS
> >> security filtering in place. That filtering does two things, for a
> >> cluster-admin user it's basically a pass-thru, the CSL Hawkular-Tenant
> >> header is passed on and the endpoints work. For all other users the
> >> Hawkular-Tenant header is validated. Because each project name is a
> >> tenant name, the value must match a project name. As such, the
> >> validation fails if a CSL is supplied. This is decent behavior for now
> >> as it prevents any undesired access. Note that as a corner-case, these
> >> endpoints will work fine if the header just supplies a single tenant, in
> >> which case they are basically the same as the typical single-tenant
> >> fetch endpoints.
> > What has happened is now Alerts is not considering the Hawkular-tenant
> > header to contain just a string, but a comma separated lists of strings.
> > 
> > eg "Hawkular-tenant: projectA,projectB"
> 
> Note, not in general, comma-separated-lists handled only for the two
> cross-tenant endpoints mentioned above.
> 
> 
> > The OpenShift filter still considers this to be a string, so it will check
> > with OpenShift if the user has permission to access the project named with
> > a string value of "projectA,projectB". Since a project cannot have a ','
> > within its name, this check will always fail and return an access denied
> > error.
> > 
> > If the user is a cluster level user they are given access to everything,
> > even impossibly named projects. So a cluster level user will happen to be
> > able to use the current setup just due to how this works.
> > 
> > So there doesn't appear to be any security issue that we need to deal with
> > immediately, but we do probably want to handle this properly in the
> > future. It might not be too difficult to add support to the tenant to
> > consider a csl.
> > 
> >> I'm not totally familiar with the Metrics approach to cross-tenant
> >> handling but going forward we (Metrics and Alerting) should probably
> >> look for some consistency, if possible. Moreover, any solution should
> >> reflect what best serves OS. The idea of a CSL for the header is fairly
> >> simple and flexible. It may be something to consider, for the OS filter
> >> it would mean validating that the bearer has access to each of the
> >> individual tenants before forwarding the request.
> > I don't recall any meetings about adding multitenancy to Metrics. >From
> > what I recall, there is no plans at all to introduce multitenancy at all
> > for metrics.
> > 
> > If I was aware of this discussion when this was brought up for alerts, I
> > would have probably objected to the endpoint being called 'admin' since I
> > don't think that reflects what the true purpose of this is suppose to be.
> > Its not really an admin endpoint, but an endpoint for cross-tenancy. I
> > could have access to projectA and projectB, but not be an 'admin'
> > 
> > If we are making changes like this which affect security, I would really
> > like to be notified so that I can make sure our security filters will
> > function properly. Even if I am in the meeting when its being discussed it
> > would be good to ping me on the PR with the actual implementation.
> 
> Of course. This stuff went in in mid November and at that time we (in
> alerting) were really just getting settled with the initial integration
> into metrics for OS. Going forward I think we have a better idea of
> what is relevant to OS and can more easily flag items of import.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.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  Fri Mar  3 03:23:18 2017
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 3 Mar 2017 09:23:18 +0100
Subject: [Hawkular-dev] Cross-Tenant endpoints in Alerting on OS
In-Reply-To: <1146619743.41418571.1488491575325.JavaMail.zimbra@redhat.com>
References: <c301209d-4065-bcb4-cd67-751b7211ff58@redhat.com>
	<1655878501.37837405.1487891140663.JavaMail.zimbra@redhat.com>
	<b4d5bb34-ba1b-dd87-7e5b-22c3ef847c89@redhat.com>
	<CAGUuq3Vc1Y-=YkZkNY0PtcbBgiHdgRuv2Q3gRD0YvF67ojNYNQ@mail.gmail.com>
	<1146619743.41418571.1488491575325.JavaMail.zimbra@redhat.com>
Message-ID: <CAGUuq3VNLe2iL4ej5VbL8hSVb9OzikrONVrToSSVB2NwR118eg@mail.gmail.com>

>
> >
> > What is the result of this discussion ?
>
> I think the result is that we need to have a meeting over cross tenancy
> and how it should be applied.
>
>
We had one meeting about this and it was discussed that cross tenancy was
not requested for Metrics components but it was requested for Alerting.

Is there any change on this since that meeting ?


> Supporting cross-tenancy is a fairly large architectural change and should
> be affecting multiple components.
>
>
Multiple components beyond Metrics / Alerts or the security filters ? Can
you ellaborate this, please ?


> At the very least we need to discuss how to properly handle it with
> regards to security integration with OpenShift.
>
>
Yes. Please, could you prepare some info you would need from Alerting
component ?
I.e. tenant formats or other related info different from the current logic.



> > Do you want any additional enhancement around this ?
> >
> > I can see two potential actions:
> > - Perhaps to move the /admin endpoint prefix to /tenants to align with
> the
> > same in metrics.
>
> The /tenants endpoint in metrics is not for cross-tenant operations. Its
> probably not a great idea to to have two endpoints of the same name between
> components which do different things.
>

The /tenants endpoint provides all the tenants of the system.
That was why in the previous meeting we proposed the /admin endpoint.

Renaming and endpoint is not a problem but as this is already released we
are going to maintain it for backwards compatibility.
(And we can mark it as deprecated for following versions).

Suggestions for other names are welcome.

Please, lets move on this, as this feature is important for Alerting users.

Lucas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170303/0bc69591/attachment-0001.html 

From hrupp at redhat.com  Fri Mar  3 04:48:41 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 03 Mar 2017 10:48:41 +0100
Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
Message-ID: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>

Hey,

on Kubernetes a common use case (that has been demonstrated by Thomas
and Juca recently) are rolling upgrades (blue/green, canary, ...) where a
new version of a service comes into play, gets scaled up and when this
is scaled up, the old version of the service gets scaled down and eventually
disappears.
It can also happen though that the new version is buggy and the previous
version gets scaled up again to take the full load until a fix is available.

We need to make sure to support those rolling upgrades and also the
rollback to the previous version of a service.

E.g. if a (No)Sql schema update happens in version N+1, a still
running instance of version N must not break by it, when N+1
is rolling out while N is still active. Similarly when N+1 has upgraded
the schema and the application gets rolled back to version N, it must
still be able to cope with the upgraded schema version.

Same applies to APIs, but this is something we have discussed and
mastered in the past.

We should perhaps investigate how we can automatically test
this scenario in our Travis testing.


From jshaughn at redhat.com  Fri Mar  3 08:04:43 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 3 Mar 2017 08:04:43 -0500
Subject: [Hawkular-dev] Cross-Tenant endpoints in Alerting on OS
In-Reply-To: <CAGUuq3VNLe2iL4ej5VbL8hSVb9OzikrONVrToSSVB2NwR118eg@mail.gmail.com>
References: <c301209d-4065-bcb4-cd67-751b7211ff58@redhat.com>
	<1655878501.37837405.1487891140663.JavaMail.zimbra@redhat.com>
	<b4d5bb34-ba1b-dd87-7e5b-22c3ef847c89@redhat.com>
	<CAGUuq3Vc1Y-=YkZkNY0PtcbBgiHdgRuv2Q3gRD0YvF67ojNYNQ@mail.gmail.com>
	<1146619743.41418571.1488491575325.JavaMail.zimbra@redhat.com>
	<CAGUuq3VNLe2iL4ej5VbL8hSVb9OzikrONVrToSSVB2NwR118eg@mail.gmail.com>
Message-ID: <e15a54db-aae4-cc26-d734-9141346d032a@redhat.com>


> Multiple components beyond Metrics / Alerts or the security filters ? 
> Can you ellaborate this, please ?
>
>     At the very least we need to discuss how to properly handle it
>     with regards to security integration with OpenShift.
>
>
> Yes. Please, could you prepare some info you would need from Alerting 
> component ?
> I.e. tenant formats or other related info different from the current 
> logic.

I don't think we can ask anything for alerting specifically, until we 
meet to ensure that, minimally, alerting and metrics are on the same 
page wrt MT and OS.    I can schedule something for next week...


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

From mwringe at redhat.com  Fri Mar  3 10:54:02 2017
From: mwringe at redhat.com (Matt Wringe)
Date: Fri, 3 Mar 2017 10:54:02 -0500 (EST)
Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
In-Reply-To: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>
References: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>
Message-ID: <652649839.41929899.1488556442797.JavaMail.zimbra@redhat.com>

For APIs, I think this is possible.

But how do we handle the situations where we want to go from Cassandra 3.x to Cassandra 4.x? Or what happens when we need to update components when those components themselves don't support this type of rollback?

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, 3 March, 2017 4:48:41 AM
> Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
> 
> Hey,
> 
> on Kubernetes a common use case (that has been demonstrated by Thomas
> and Juca recently) are rolling upgrades (blue/green, canary, ...) where a
> new version of a service comes into play, gets scaled up and when this
> is scaled up, the old version of the service gets scaled down and eventually
> disappears.

I believe this only one type of scenario, there are other options depending on how your application should behave.

For Cassandra, we want to bring down all the instances and bring up all new versions (which is what we currently do in origin-metrics). The reason being that we want to use the persistent storage from the previous versions. Otherwise we would need to bring up new versions with empty volumes and then wait for the data to transfer from the old versions to the new ones, which is really not what we want.

> It can also happen though that the new version is buggy and the previous
> version gets scaled up again to take the full load until a fix is available.
> 
> We need to make sure to support those rolling upgrades and also the
> rollback to the previous version of a service.
> 
> E.g. if a (No)Sql schema update happens in version N+1, a still
> running instance of version N must not break by it, when N+1
> is rolling out while N is still active. Similarly when N+1 has upgraded
> the schema and the application gets rolled back to version N, it must
> still be able to cope with the upgraded schema version.
> 
> Same applies to APIs, but this is something we have discussed and
> mastered in the past.
> 
> We should perhaps investigate how we can automatically test
> this scenario in our Travis testing.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From hrupp at redhat.com  Fri Mar  3 11:05:00 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 03 Mar 2017 17:05:00 +0100
Subject: [Hawkular-dev] [metrics] Internal stats?
In-Reply-To: <13B5CAB4-D3A7-4108-9C64-24A9C4B2C30A@redhat.com>
References: <BA6C0106-664F-4951-81BF-F4E104C55286@redhat.com>
	<13B5CAB4-D3A7-4108-9C64-24A9C4B2C30A@redhat.com>
Message-ID: <FD98F439-9B10-47FF-9A7A-9A4A7E498FCC@redhat.com>

I have (finally) opened https://issues.jboss.org/browse/HWKMETRICS-619
for this.

On 30 Jan 2017, at 16:12, John Sanda wrote:

> Not that I think this is a bad idea, but it is the first I have heard 
> about the per tenant metrics. Where is this feature 
> request/requirement coming from? I?d just like some context.
>> On Jan 30, 2017, at 5:50 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>
>> Hey,
>>
>> what internal stats of the Hawkular metrics do we currently collect?
>> I think Joel did some work for the C* part.
>>
>> What I think we need is
>> - number of data points stored on a per tenant basis.
>> Resolution could be something like "last minute" or
>> "last 5 minutes" I.e. not realtime updates in the table.
>> - Total number of data points (i.e. sum over all tenants)
>>
>> Query stats. This is probably more complicated, as
>> querying on metrics that are still in some buffer is
>> cheaper than over 3 years of raw data.
>> To get started I'd go with # of queries per tenant and global
>> Those could perhaps be differentiated on
>>
>> raw endpoint
>> stats endpoint
>> What about alerting? More alert definitions certainly
>> need more cpu, so number of alert definitions per tenant
>> and total would be another pair.
>>
>> does number of fired alerts also make sense?
>> The idea behind those is to get some usage figures of the
>> shared resource "Hawkular metrics" and then to be able to
>> charge them back onto individual tenants e.g. inside of
>> OpenShift.
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


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

From hrupp at redhat.com  Fri Mar  3 11:54:27 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 03 Mar 2017 17:54:27 +0100
Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
In-Reply-To: <652649839.41929899.1488556442797.JavaMail.zimbra@redhat.com>
References: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>
	<652649839.41929899.1488556442797.JavaMail.zimbra@redhat.com>
Message-ID: <327050FA-3CC4-4126-8B3E-9EA4E5B8A342@redhat.com>

On 3 Mar 2017, at 16:54, Matt Wringe wrote:

> But how do we handle the situations where we want to go from Cassandra 
> 3.x to Cassandra 4.x? Or what happens when we need to update 
> components when those components themselves don't support this type of 
> rollback?

I did not say this is easy :)

Let me construct a case to illustrate this.

In version N we have a column that stores a string in the form
"tenantId:metricid". Now we decide for N+1 that this is not
good and we need to split that in two separate columns.

In a traditional way we would do the split and also remove the
old single column. Here a rollback is not possible.

If we change this to keep the old column around and the two
new ones we are safe for version N+1, but as there may be
still version N containers around we may end up with inconsistencies
when version N updates an item and N+1 already has split that row.

Here version N+1 would potentially need to read/write from both
scenarios and also update both (if the old one still exists, see below).
This allows rolling back.

Version N+2 could then drop the old "tenantId:metricid" column
and only operate on the split columns.

Heavier updates like C* version 3.x to 4.x can probably really not
be done without downtime - especially when they require massive
migrations of Gigabytes of data.
But still in this case the Metrics frontend code could work against
both versions of C* and redundantly store data in both while slowly
migrating data over. Reads could then still go to the old code by
default until the migration is complete.

From jsanda at redhat.com  Fri Mar  3 14:18:39 2017
From: jsanda at redhat.com (John Sanda)
Date: Fri, 3 Mar 2017 14:18:39 -0500
Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
In-Reply-To: <327050FA-3CC4-4126-8B3E-9EA4E5B8A342@redhat.com>
References: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>
	<652649839.41929899.1488556442797.JavaMail.zimbra@redhat.com>
	<327050FA-3CC4-4126-8B3E-9EA4E5B8A342@redhat.com>
Message-ID: <7E4F747D-39A2-4C6C-B28D-064F37A90754@redhat.com>


> On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 3 Mar 2017, at 16:54, Matt Wringe wrote:
> 
>> But how do we handle the situations where we want to go from Cassandra 
>> 3.x to Cassandra 4.x? Or what happens when we need to update 
>> components when those components themselves don't support this type of 
>> rollback?
> 
> I did not say this is easy :)
> 
> Let me construct a case to illustrate this.
> 
> In version N we have a column that stores a string in the form
> "tenantId:metricid". Now we decide for N+1 that this is not
> good and we need to split that in two separate columns.
> 
> In a traditional way we would do the split and also remove the
> old single column. Here a rollback is not possible.
> 
> If we change this to keep the old column around and the two
> new ones we are safe for version N+1, but as there may be
> still version N containers around we may end up with inconsistencies
> when version N updates an item and N+1 already has split that row.
> 
> Here version N+1 would potentially need to read/write from both
> scenarios and also update both (if the old one still exists, see below).
> This allows rolling back.
> 
> Version N+2 could then drop the old "tenantId:metricid" column
> and only operate on the split columns.
> 
> Heavier updates like C* version 3.x to 4.x can probably really not
> be done without downtime - especially when they require massive
> migrations of Gigabytes of data.
> But still in this case the Metrics frontend code could work against
> both versions of C* and redundantly store data in both while slowly
> migrating data over. Reads could then still go to the old code by
> default until the migration is complete.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>

As far as I know rolling upgrades of Cassandra with a major version change is well supported, and rolling upgrades is pretty common among Cassandra users. Here is the scenario I am not sure we could handle without downtime.  We want to make make a schema change that involves something introduced in the new version of Cassandra, e.g., SASI index.

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

From mwringe at redhat.com  Fri Mar  3 15:29:37 2017
From: mwringe at redhat.com (Matt Wringe)
Date: Fri, 3 Mar 2017 15:29:37 -0500 (EST)
Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
In-Reply-To: <7E4F747D-39A2-4C6C-B28D-064F37A90754@redhat.com>
References: <2630C7D2-A4A7-4750-86DE-6302F027A291@redhat.com>
	<652649839.41929899.1488556442797.JavaMail.zimbra@redhat.com>
	<327050FA-3CC4-4126-8B3E-9EA4E5B8A342@redhat.com>
	<7E4F747D-39A2-4C6C-B28D-064F37A90754@redhat.com>
Message-ID: <1051947284.42007104.1488572977725.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, 3 March, 2017 2:18:39 PM
> Subject: Re: [Hawkular-dev] Rolling upgrades (on Kubernetes)
> 
> 
> 
> 
> 
> On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp < hrupp at redhat.com > wrote:
> 
> On 3 Mar 2017, at 16:54, Matt Wringe wrote:
> 
> 
> 
> But how do we handle the situations where we want to go from Cassandra
> 3.x to Cassandra 4.x? Or what happens when we need to update
> components when those components themselves don't support this type of
> rollback?
> 
> I did not say this is easy :)
> 
> Let me construct a case to illustrate this.
> 
> In version N we have a column that stores a string in the form
> "tenantId:metricid". Now we decide for N+1 that this is not
> good and we need to split that in two separate columns.
> 
> In a traditional way we would do the split and also remove the
> old single column. Here a rollback is not possible.
> 
> If we change this to keep the old column around and the two
> new ones we are safe for version N+1, but as there may be
> still version N containers around we may end up with inconsistencies
> when version N updates an item and N+1 already has split that row.
> 
> Here version N+1 would potentially need to read/write from both
> scenarios and also update both (if the old one still exists, see below).
> This allows rolling back.
> 
> Version N+2 could then drop the old "tenantId:metricid" column
> and only operate on the split columns.
> 
> Heavier updates like C* version 3.x to 4.x can probably really not
> be done without downtime - especially when they require massive
> migrations of Gigabytes of data.
> But still in this case the Metrics frontend code could work against
> both versions of C* and redundantly store data in both while slowly
> migrating data over. Reads could then still go to the old code by
> default until the migration is complete.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> As far as I know rolling upgrades of Cassandra with a major version change is
> well supported, and rolling upgrades is pretty common among Cassandra users.
> Here is the scenario I am not sure we could handle without downtime. We want
> to make make a schema change that involves something introduced in the new
> version of Cassandra, e.g., SASI index.

Yeah, its not the rolling upgrades I think we will run into problems with, its the downgrade when someone wants to revert back to the previous version that might cause problems.

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

From anuj1708 at gmail.com  Mon Mar  6 03:04:34 2017
From: anuj1708 at gmail.com (Anuj Garg)
Date: Mon, 6 Mar 2017 13:34:34 +0530
Subject: [Hawkular-dev] Requirement of Aerogear Unified Push Server Instance
Message-ID: <CALZCyhBWHeKbHqD4vxXye3kY+DGD-cpP0zBKnkheCJQTK0T5Kw@mail.gmail.com>

Hello team,

We need one instance of Aerogear Unified Push Server for setting up push
messaging feature in android client of hawkular.

I can think of 2 ways this can be achieved.

   1. Creating instance on openshift.
   2. Asking aerogear team if they can provide account for one application.

I request suggestions about what in these or other things we can do for
this.

Regards

Anuj Garg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170306/255ab259/attachment.html 

From lponce at redhat.com  Mon Mar  6 03:20:42 2017
From: lponce at redhat.com (Lucas Ponce)
Date: Mon, 6 Mar 2017 09:20:42 +0100
Subject: [Hawkular-dev] Requirement of Aerogear Unified Push Server
	Instance
In-Reply-To: <CALZCyhBWHeKbHqD4vxXye3kY+DGD-cpP0zBKnkheCJQTK0T5Kw@mail.gmail.com>
References: <CALZCyhBWHeKbHqD4vxXye3kY+DGD-cpP0zBKnkheCJQTK0T5Kw@mail.gmail.com>
Message-ID: <CAGUuq3V_G9LRH+9+=tSh5zpHeoWvLqNAbk7KKKPC0TVWu8_dog@mail.gmail.com>

For the tests done in the aerogear plugin I mostly used an openshift
instance.

It worked just fine for preliminar use cases and making configurable allows
to the user pointing to whatever instance they would like to set up.

I haven't explored the option 2.

Lucas

On Mon, Mar 6, 2017 at 9:04 AM, Anuj Garg <anuj1708 at gmail.com> wrote:

> Hello team,
>
> We need one instance of Aerogear Unified Push Server for setting up push
> messaging feature in android client of hawkular.
>
> I can think of 2 ways this can be achieved.
>
>    1. Creating instance on openshift.
>    2. Asking aerogear team if they can provide account for one
>    application.
>
> I request suggestions about what in these or other things we can do for
> this.
>
> Regards
>
> Anuj Garg
>
> _______________________________________________
> 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/20170306/6cd1d33e/attachment.html 

From miburman at redhat.com  Mon Mar  6 06:41:42 2017
From: miburman at redhat.com (Michael Burman)
Date: Mon, 6 Mar 2017 13:41:42 +0200
Subject: [Hawkular-dev] Little research help with collection times..
Message-ID: <8060b59e-a3e0-bbc0-b5dd-2a6567dbb080@redhat.com>

Hi,

I could use some help if someone has access to this sort of data. I'm 
trying to find our collection interval fluctuations when using our 
collectors. The actual collection interval is not interesting, but the 
amount it's delayed per run and how that changes.

Currently we use the default's from the Gorilla paper (with the typo 
that the paper had), which gives us ranges: [-63,64] (7 bits), 
[-255,256] (9 bits), [-2047,2048] (12 bits) and rest. First one needs 2 
bits as metadata, second needs 3 and third needs already 4 bits.

Those ranges were done by the Facebook guys from their data, but that 
was using the second precision. We use milliseconds like for example 
Prometheus does, and they use ranges for 14,17,20 meaningful bits 
(IIRC). I don't think their values are however useful to us as from what 
I've gathered from my small set of data, our best ranges are somewhere 
around:

[-256,256] millisecond difference in delta of delta, D = (tn - t(n-1) - 
(t(n-1) - t(n-2))

[-512,512] milliseconds

[-2048,2048] milliseconds

First two are probably wiser to merge to a single range and ignore the 
first one. While we store one extra bit of info, we save one on the 
metadata. Last one could technically be something like "missed one 
datapoint", but then that would be collection interval and I'm not sure 
if we have any target value for that in the long range.

But, I'm guessing too much. From the hawkular-openshift-agent I can see 
that values are fetched in sequential mode, so delay in fetching one 
metric will cause the next one to be delayed and so on. I can see from 
an empty instance how much this time is, but when running in a congested 
environment, what can we expect?

Saving a bit or two might not sound like much, but lets say with 30 000 
pods in Openshift, 32 metrics per pod in 15 seconds interval we're 
talking about 5 529 600 000 datapoints per day and it adds up (659MB per 
day saved space with a single bit). So getting the ranges correct nets 
us a lot of savings.

   - Micke


From neil.okamoto+hawkular at gmail.com  Mon Mar  6 12:31:36 2017
From: neil.okamoto+hawkular at gmail.com (Neil Okamoto)
Date: Mon, 6 Mar 2017 09:31:36 -0800
Subject: [Hawkular-dev] auto testing client integrations with hawkular apm
Message-ID: <CAG3XP79Fgv+kOa7mLuTE_J12bgWB==YXkRGm1AfJTGhbyeFmLg@mail.gmail.com>

I'm in the process of developing a clojure library that wraps the
opentracing-java client (the abstract interface), and provides concrete
implementations for Hawkular APM and Zipkin.

I'm considering ways to test the concrete Hawkular implementation in
Travis. One thought is to configure Travis to launch a hawkular dev server
(from the docker image) and then execute a series of test cases to collect
traces, and finally use the REST API to read back what hawkular received.

The problem being, I haven't found the documentation for the query
parameters you pass to "GET /traces/fragments/search".

https://hawkular.gitbooks.io/hawkular-apm-user-guide/
content/restapi/#GET__traces_fragments_search

Any pointers how to do this? How does the hawkular development team run
integration tests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170306/5c8d165c/attachment.html 

From jtakvori at redhat.com  Mon Mar  6 13:11:13 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Mon, 6 Mar 2017 19:11:13 +0100
Subject: [Hawkular-dev]  Inventory storage on metrics
Message-ID: <CAJo5TFn6GG8Puucpwiv3g03J9K4+rMOHeBHdJAr5NgV2vfJdHg@mail.gmail.com>

Quick reminder for those who may not have followed the discussions: this is
about removing the inventory project as it currently stands, and replace it
with Metrics-based (so C*-based) storage, using String metrics and json
blobs.

So, I've been analyzing the usages of inventory in the wildfly agent and in
manageiq / ruby client.

As posted on another topic, I started with the following pattern for
putting inventories in string metrics:

- metrics are named:
*inventory.[feedid].[r|rt|mt].[id]*

which means that we would store JSON blobs by resource type, by metric type
and by root resource (all per feed id). Which also means we don't allow
anything outside of a feed.

This naming pattern seems to be quite easily transposable to the wildfly
agent feeding.

Things become more complicated when we look at the ruby client / manageIQ.
To help in querying, we can add those tags on every metric:

module: inventory

feed: [feedid]

type: [r|rt|mt]

With this, we can easily query, for instance, all resource types of a given
feed, or all feeds, or child resources at a given path, etc.

Now, after analysis of the ruby code (and I hope I didn't miss important
stuff), I have two remarks:

- There is a lot a methods in the ruby client that are not used in manage
IQ (listed below [1]). Of course those methods may have an interest for a
general purpose client, but since we're removing a lot of functionalities
in inventory, I would suggest not to focus on them, and just remove them
for the time being. This is possible, of course, if no other product than
manageIQ consumes then... is it the case?

- I've found just 1 method in the ruby client that would be badly impacted
by the usage of string metrics as currently defined. And unfortunately it's
also the one that is most called (in number of occurrence in code) by
manage IQ, it's "list_resources_for_type"; With the implementation I
described above, to list all resources of a given type we would have to get
all resource blobs of a feed and search in all of them to check all root &
child resource types. That would probably be terrible for performances.

A suggestion to this problem, is to tag each root resource with one tag per
resource type, something like: "
*rt.MyResourceType=resource1,resource2,resource3*".
Then, we would still have to load the whole blobs and search resources in
them, but we would exclude from the search all root resources that doesn't
have those types, and we wouldn't have to search extensively in the blobs
as we would know the paths.

*Question to metrics devs* about that: can we use any character for
tagging, or is there some limitation?

Or if you can suggest a better way, I'm all ears  :)

[1] list of methods that seem to be unused from the ruby client:
- list_resources_for_feed
- list_relationships
- list_relationships_for_feed
- get_entity
- list_metrics_for_metric_type
- list_metrics_for_resource_type
- create_feed
- delete_feed
- create_resource_type
- create_resource
- create_resource_under_resource
- create_metric_type
- list_operation_definitions
- list_operation_definitions_for_resource
- create_metric_for_resource
- no_more_events

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

From mazz at redhat.com  Mon Mar  6 13:28:03 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 6 Mar 2017 13:28:03 -0500 (EST)
Subject: [Hawkular-dev] Inventory storage on metrics
In-Reply-To: <CAJo5TFn6GG8Puucpwiv3g03J9K4+rMOHeBHdJAr5NgV2vfJdHg@mail.gmail.com>
References: <CAJo5TFn6GG8Puucpwiv3g03J9K4+rMOHeBHdJAr5NgV2vfJdHg@mail.gmail.com>
Message-ID: <1115823553.3976721.1488824883238.JavaMail.zimbra@redhat.com>

This also affects the command-gateway stuff since virtually all of the messages require an Inventory ResourcePath (that is how the MiQ UI targets where it wants the message to go, and how the server knows what agent to pass the message to, and how the agent knows what specific resource to operate on).

These ResourcePaths are Hawkular-Inventory resource paths - if resource path formats change, we need to change the way the command-gateway stuff works.

I can't speak for the MiQ UI side, but from server/agent sides, it isn't trivial but also not that hard to do these changes. It is just work we need to remember we have to do - work in the MiQ UI, server, and agent.

----- Original Message -----
> Quick reminder for those who may not have followed the discussions: this is
> about removing the inventory project as it currently stands, and replace it
> with Metrics-based (so C*-based) storage, using String metrics and json
> blobs.
> 
> So, I've been analyzing the usages of inventory in the wildfly agent and in
> manageiq / ruby client.
> 
> As posted on another topic, I started with the following pattern for putting
> inventories in string metrics:
> 
> - metrics are named:
> inventory.[feedid].[r|rt|mt].[id]
> 
> which means that we would store JSON blobs by resource type, by metric type
> and by root resource (all per feed id). Which also means we don't allow
> anything outside of a feed.
> 
> This naming pattern seems to be quite easily transposable to the wildfly
> agent feeding.
> 
> Things become more complicated when we look at the ruby client / manageIQ. To
> help in querying, we can add those tags on every metric:
> 
> 
> 
> module: inventory
> 
> feed: [feedid]
> 
> type: [r|rt|mt]
> 
> With this, we can easily query, for instance, all resource types of a given
> feed, or all feeds, or child resources at a given path, etc.
> 
> Now, after analysis of the ruby code (and I hope I didn't miss important
> stuff), I have two remarks:
> 
> - There is a lot a methods in the ruby client that are not used in manage IQ
> (listed below [1]). Of course those methods may have an interest for a
> general purpose client, but since we're removing a lot of functionalities in
> inventory, I would suggest not to focus on them, and just remove them for
> the time being. This is possible, of course, if no other product than
> manageIQ consumes then... is it the case?
> 
> - I've found just 1 method in the ruby client that would be badly impacted by
> the usage of string metrics as currently defined. And unfortunately it's
> also the one that is most called (in number of occurrence in code) by manage
> IQ, it's "list_resources_for_type"; With the implementation I described
> above, to list all resources of a given type we would have to get all
> resource blobs of a feed and search in all of them to check all root & child
> resource types. That would probably be terrible for performances.
> 
> A suggestion to this problem, is to tag each root resource with one tag per
> resource type, something like: "
> rt.MyResourceType=resource1,resource2,resource3 ".
> Then, we would still have to load the whole blobs and search resources in
> them, but we would exclude from the search all root resources that doesn't
> have those types, and we wouldn't have to search extensively in the blobs as
> we would know the paths.
> 
> Question to metrics devs about that: can we use any character for tagging, or
> is there some limitation?
> 
> Or if you can suggest a better way, I'm all ears :)
> 
> [1] list of methods that seem to be unused from the ruby client:
> - list_resources_for_feed
> - list_relationships
> - list_relationships_for_feed
> - get_entity
> - list_metrics_for_metric_type
> - list_metrics_for_resource_type
> - create_feed
> - delete_feed
> - create_resource_type
> - create_resource
> - create_resource_under_resource
> - create_metric_type
> - list_operation_definitions
> - list_operation_definitions_for_resource
> - create_metric_for_resource
> - no_more_events
> 
> Joel
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jtakvori at redhat.com  Mon Mar  6 14:18:43 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Mon, 6 Mar 2017 20:18:43 +0100
Subject: [Hawkular-dev] Inventory storage on metrics
In-Reply-To: <1115823553.3976721.1488824883238.JavaMail.zimbra@redhat.com>
References: <CAJo5TFn6GG8Puucpwiv3g03J9K4+rMOHeBHdJAr5NgV2vfJdHg@mail.gmail.com>
	<1115823553.3976721.1488824883238.JavaMail.zimbra@redhat.com>
Message-ID: <CAJo5TFm3JS=FQk=n_dsYJjY6noA9mQZhs7U6tHiaWdbUbTb2vA@mail.gmail.com>

I haven't checked that part of the puzzle yet, will do it tomorrow. However
I hope it is possible to keep the ResourcePath as they are currently used.
Since we can retrieve the root resource from a canonical path of a child
resource, it's should be ok to find the desired associated string metric.

On Mon, Mar 6, 2017 at 7:28 PM, John Mazzitelli <mazz at redhat.com> wrote:

> This also affects the command-gateway stuff since virtually all of the
> messages require an Inventory ResourcePath (that is how the MiQ UI targets
> where it wants the message to go, and how the server knows what agent to
> pass the message to, and how the agent knows what specific resource to
> operate on).
>
> These ResourcePaths are Hawkular-Inventory resource paths - if resource
> path formats change, we need to change the way the command-gateway stuff
> works.
>
> I can't speak for the MiQ UI side, but from server/agent sides, it isn't
> trivial but also not that hard to do these changes. It is just work we need
> to remember we have to do - work in the MiQ UI, server, and agent.
>
> ----- Original Message -----
> > Quick reminder for those who may not have followed the discussions: this
> is
> > about removing the inventory project as it currently stands, and replace
> it
> > with Metrics-based (so C*-based) storage, using String metrics and json
> > blobs.
> >
> > So, I've been analyzing the usages of inventory in the wildfly agent and
> in
> > manageiq / ruby client.
> >
> > As posted on another topic, I started with the following pattern for
> putting
> > inventories in string metrics:
> >
> > - metrics are named:
> > inventory.[feedid].[r|rt|mt].[id]
> >
> > which means that we would store JSON blobs by resource type, by metric
> type
> > and by root resource (all per feed id). Which also means we don't allow
> > anything outside of a feed.
> >
> > This naming pattern seems to be quite easily transposable to the wildfly
> > agent feeding.
> >
> > Things become more complicated when we look at the ruby client /
> manageIQ. To
> > help in querying, we can add those tags on every metric:
> >
> >
> >
> > module: inventory
> >
> > feed: [feedid]
> >
> > type: [r|rt|mt]
> >
> > With this, we can easily query, for instance, all resource types of a
> given
> > feed, or all feeds, or child resources at a given path, etc.
> >
> > Now, after analysis of the ruby code (and I hope I didn't miss important
> > stuff), I have two remarks:
> >
> > - There is a lot a methods in the ruby client that are not used in
> manage IQ
> > (listed below [1]). Of course those methods may have an interest for a
> > general purpose client, but since we're removing a lot of
> functionalities in
> > inventory, I would suggest not to focus on them, and just remove them for
> > the time being. This is possible, of course, if no other product than
> > manageIQ consumes then... is it the case?
> >
> > - I've found just 1 method in the ruby client that would be badly
> impacted by
> > the usage of string metrics as currently defined. And unfortunately it's
> > also the one that is most called (in number of occurrence in code) by
> manage
> > IQ, it's "list_resources_for_type"; With the implementation I described
> > above, to list all resources of a given type we would have to get all
> > resource blobs of a feed and search in all of them to check all root &
> child
> > resource types. That would probably be terrible for performances.
> >
> > A suggestion to this problem, is to tag each root resource with one tag
> per
> > resource type, something like: "
> > rt.MyResourceType=resource1,resource2,resource3 ".
> > Then, we would still have to load the whole blobs and search resources in
> > them, but we would exclude from the search all root resources that
> doesn't
> > have those types, and we wouldn't have to search extensively in the
> blobs as
> > we would know the paths.
> >
> > Question to metrics devs about that: can we use any character for
> tagging, or
> > is there some limitation?
> >
> > Or if you can suggest a better way, I'm all ears :)
> >
> > [1] list of methods that seem to be unused from the ruby client:
> > - list_resources_for_feed
> > - list_relationships
> > - list_relationships_for_feed
> > - get_entity
> > - list_metrics_for_metric_type
> > - list_metrics_for_resource_type
> > - create_feed
> > - delete_feed
> > - create_resource_type
> > - create_resource
> > - create_resource_under_resource
> > - create_metric_type
> > - list_operation_definitions
> > - list_operation_definitions_for_resource
> > - create_metric_for_resource
> > - no_more_events
> >
> > Joel
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.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/20170306/5d0f2b1b/attachment.html 

From gbrown at redhat.com  Tue Mar  7 03:21:25 2017
From: gbrown at redhat.com (Gary Brown)
Date: Tue, 7 Mar 2017 03:21:25 -0500 (EST)
Subject: [Hawkular-dev] auto testing client integrations with hawkular
 apm
In-Reply-To: <CAG3XP79Fgv+kOa7mLuTE_J12bgWB==YXkRGm1AfJTGhbyeFmLg@mail.gmail.com>
References: <CAG3XP79Fgv+kOa7mLuTE_J12bgWB==YXkRGm1AfJTGhbyeFmLg@mail.gmail.com>
Message-ID: <551131357.66632129.1488874885711.JavaMail.zimbra@redhat.com>

Hi Neil

The easiest way to do it is use the Java client for the trace service: https://github.com/hawkular/hawkular-apm/blob/master/client/trace-service-rest-client/src/main/java/org/hawkular/apm/trace/service/rest/client/TraceServiceRESTClient.java#L63

Regards
Gary

----- Original Message -----
> I'm in the process of developing a clojure library that wraps the
> opentracing-java client (the abstract interface), and provides concrete
> implementations for Hawkular APM and Zipkin.
> 
> I'm considering ways to test the concrete Hawkular implementation in Travis.
> One thought is to configure Travis to launch a hawkular dev server (from the
> docker image) and then execute a series of test cases to collect traces, and
> finally use the REST API to read back what hawkular received.
> 
> The problem being, I haven't found the documentation for the query parameters
> you pass to "GET /traces/fragments/search".
> 
> https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/restapi/#GET__traces_fragments_search
> 
> Any pointers how to do this? How does the hawkular development team run
> integration tests?
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Tue Mar  7 09:12:36 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 7 Mar 2017 09:12:36 -0500 (EST)
Subject: [Hawkular-dev] Command gateway and WF agent
In-Reply-To: <CAJo5TF=4Xtc1Rj-U_u3f9yxLWv=p5A9E-hzHjq7zHq5FAtN8fQ@mail.gmail.com>
References: <CAJo5TF=4Xtc1Rj-U_u3f9yxLWv=p5A9E-hzHjq7zHq5FAtN8fQ@mail.gmail.com>
Message-ID: <1813151977.4439961.1488895956664.JavaMail.zimbra@redhat.com>

> Can you explain to me what's the big picture of the command gateway? What's
> the chain of calls when, for instance, there's a new deployment in Wildfly?

Joel asked this question - I figured it is good to post to h-dev, too, since I'm sure others don't know this.

The "big picture" is:

First, remember the MiQ UI is connected to Hawkular-Services server via websocket. The agents all connect to some Hawkular-Services server via a websocket. There can be more than one Hawkular-Services server running and the UI may be talking to a server that is different than the server the agent is talking to:

UI <---websocket---> Server A
                         ^
                         |
                   (message bus)
                         |
                         V
                     Server B <---websocket---> agent


1) MiQ sends a JSON message over the websocket to a Hawkular-Services server (Server A in the diagram above).
2) Hawkular-Services server A looks at the ResourcePath in the message to determine what agent is responsible for managing that resource.
3) Hawkular-Services server A addresses the message to the proper agent and puts the JSON message on the agent's queue on the message bus.
3b) At this point the Hawkular-Services server A sends back a JSON message to the UI over the websocket that says "message forwarded to the bus".
4) The Hawkular-Services server that has a websocket connection to the targeted agent picks off that message from the bus (Server B in the diagram)
5) That Hawkular-Services server B forwards the message to the agent via its websocket connection.
6) Agent looks the the message's ResourcePath and the rest of the JSON to determine what it needs to do. It does the action.

// now the process goes in reverse

7) Agent sends back a response to the server B over websocket (either a success or fail message)
8) Server B takes response, figures out which UI the response should go to, and puts it on message bus addressed to the correct UI
9) The Server A takes the response message off the bus
10) Server A sends the response message to the UI over its websocket connection.


> Tell me if I'm correct, for what I've seen it's MIQ which, though the ruby
> client, sends a websocket event, caught by the WF agent through the command
> gateway. In the end, the WF agent will perform a full sync of affected root
> resources in inventory. Is that correct?

In the case of a "Deployment" JSON message, yes, the agent will trigger a full discovery scan so it can quickly discover the new deployment you just added to WildFly.

> If that's correct, there's no direct interaction between inventory and the
> command gateway. I'm asking because I hope we can keep the command gateway
> messages unchanged, and change only places where there's direct calls to
> the inventory rest api.

Most of the time, its just using ResourcePath API (just that simple inventory POJO). HOWEVER, I believe Jay added some code that does interact with Inventory to do things like create relationships in inventory when new cluster entities are added. That is why (I think) he did this commit. Though I can't remember where this code is that builds inventory relationships - he'll have to point that out. But I'm pretty sure there is some inventory stuff going on under the covers for that stuff - more than just using the canonical ResourcePath stuff.

From jtakvori at redhat.com  Tue Mar  7 09:26:30 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Tue, 7 Mar 2017 15:26:30 +0100
Subject: [Hawkular-dev] Command gateway and WF agent
In-Reply-To: <1813151977.4439961.1488895956664.JavaMail.zimbra@redhat.com>
References: <CAJo5TF=4Xtc1Rj-U_u3f9yxLWv=p5A9E-hzHjq7zHq5FAtN8fQ@mail.gmail.com>
	<1813151977.4439961.1488895956664.JavaMail.zimbra@redhat.com>
Message-ID: <CAJo5TF=NJ9fzL4s5wQKqb_f59q58-KbrdmzOdFcwLejsDQZOcA@mail.gmail.com>

Nice explanation, thanks!

On Tue, Mar 7, 2017 at 3:12 PM, John Mazzitelli <mazz at redhat.com> wrote:

> > Can you explain to me what's the big picture of the command gateway?
> What's
> > the chain of calls when, for instance, there's a new deployment in
> Wildfly?
>
> Joel asked this question - I figured it is good to post to h-dev, too,
> since I'm sure others don't know this.
>
> The "big picture" is:
>
> First, remember the MiQ UI is connected to Hawkular-Services server via
> websocket. The agents all connect to some Hawkular-Services server via a
> websocket. There can be more than one Hawkular-Services server running and
> the UI may be talking to a server that is different than the server the
> agent is talking to:
>
> UI <---websocket---> Server A
>                          ^
>                          |
>                    (message bus)
>                          |
>                          V
>                      Server B <---websocket---> agent
>
>
> 1) MiQ sends a JSON message over the websocket to a Hawkular-Services
> server (Server A in the diagram above).
> 2) Hawkular-Services server A looks at the ResourcePath in the message to
> determine what agent is responsible for managing that resource.
> 3) Hawkular-Services server A addresses the message to the proper agent
> and puts the JSON message on the agent's queue on the message bus.
> 3b) At this point the Hawkular-Services server A sends back a JSON message
> to the UI over the websocket that says "message forwarded to the bus".
> 4) The Hawkular-Services server that has a websocket connection to the
> targeted agent picks off that message from the bus (Server B in the diagram)
> 5) That Hawkular-Services server B forwards the message to the agent via
> its websocket connection.
> 6) Agent looks the the message's ResourcePath and the rest of the JSON to
> determine what it needs to do. It does the action.
>
> // now the process goes in reverse
>
> 7) Agent sends back a response to the server B over websocket (either a
> success or fail message)
> 8) Server B takes response, figures out which UI the response should go
> to, and puts it on message bus addressed to the correct UI
> 9) The Server A takes the response message off the bus
> 10) Server A sends the response message to the UI over its websocket
> connection.
>
>
> > Tell me if I'm correct, for what I've seen it's MIQ which, though the
> ruby
> > client, sends a websocket event, caught by the WF agent through the
> command
> > gateway. In the end, the WF agent will perform a full sync of affected
> root
> > resources in inventory. Is that correct?
>
> In the case of a "Deployment" JSON message, yes, the agent will trigger a
> full discovery scan so it can quickly discover the new deployment you just
> added to WildFly.
>
> > If that's correct, there's no direct interaction between inventory and
> the
> > command gateway. I'm asking because I hope we can keep the command
> gateway
> > messages unchanged, and change only places where there's direct calls to
> > the inventory rest api.
>
> Most of the time, its just using ResourcePath API (just that simple
> inventory POJO). HOWEVER, I believe Jay added some code that does interact
> with Inventory to do things like create relationships in inventory when new
> cluster entities are added. That is why (I think) he did this commit.
> Though I can't remember where this code is that builds inventory
> relationships - he'll have to point that out. But I'm pretty sure there is
> some inventory stuff going on under the covers for that stuff - more than
> just using the canonical ResourcePath stuff.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170307/75e4eb91/attachment-0001.html 

From neil.okamoto+hawkular at gmail.com  Tue Mar  7 10:07:57 2017
From: neil.okamoto+hawkular at gmail.com (Neil Okamoto)
Date: Tue, 7 Mar 2017 07:07:57 -0800
Subject: [Hawkular-dev] auto testing client integrations with hawkular
	apm
In-Reply-To: <551131357.66632129.1488874885711.JavaMail.zimbra@redhat.com>
References: <CAG3XP79Fgv+kOa7mLuTE_J12bgWB==YXkRGm1AfJTGhbyeFmLg@mail.gmail.com>
	<551131357.66632129.1488874885711.JavaMail.zimbra@redhat.com>
Message-ID: <CAG3XP78GG_7wJyOZUkWuYGB+otnEg71_hGoYBH24jARKB8QxQg@mail.gmail.com>

Thanks Gary.

Based on the code sample it looks like the syntax for a query is "GET
/traces/fragments/search?criteria=%s" where the criteria is a url encoded
JSON dictionary. I think I can create those url parameters manually if I
wanted.

I also discovered last night that the implementation of a Span has a method
called "state" which yields a hashmap containing the span's traceId [1].
That suggests my test can construct a span, record the traceId, and later
go back to the server and "GET /traces/complete/{id}" [2] with a generic
http client. I haven't implemented, but I'll try that first when time
permits.

[1]
https://github.com/hawkular/hawkular-apm/blob/afcdb73f1c8a45289f620b0d9557c81c5f532364/client/opentracing/src/main/java/io/opentracing/impl/APMSpan.java#L417
[2]
https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/restapi/#GET__traces_fragments__id_



On Tue, Mar 7, 2017 at 12:21 AM, Gary Brown <gbrown at redhat.com> wrote:

> Hi Neil
>
> The easiest way to do it is use the Java client for the trace service:
> https://github.com/hawkular/hawkular-apm/blob/master/
> client/trace-service-rest-client/src/main/java/org/
> hawkular/apm/trace/service/rest/client/TraceServiceRESTClient.java#L63
>
> Regards
> Gary
>
> ----- Original Message -----
> > I'm in the process of developing a clojure library that wraps the
> > opentracing-java client (the abstract interface), and provides concrete
> > implementations for Hawkular APM and Zipkin.
> >
> > I'm considering ways to test the concrete Hawkular implementation in
> Travis.
> > One thought is to configure Travis to launch a hawkular dev server (from
> the
> > docker image) and then execute a series of test cases to collect traces,
> and
> > finally use the REST API to read back what hawkular received.
> >
> > The problem being, I haven't found the documentation for the query
> parameters
> > you pass to "GET /traces/fragments/search".
> >
> > https://hawkular.gitbooks.io/hawkular-apm-user-guide/
> content/restapi/#GET__traces_fragments_search
> >
> > Any pointers how to do this? How does the hawkular development team run
> > integration tests?
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.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/20170307/56fd3ec2/attachment.html 

From mazz at redhat.com  Tue Mar  7 16:26:46 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 7 Mar 2017 16:26:46 -0500 (EST)
Subject: [Hawkular-dev] agent running in EAP6.4 cannot talk to Hawkular
	Server over HTTPS
In-Reply-To: <518213568.4736233.1488920801532.JavaMail.zimbra@redhat.com>
Message-ID: <1676766165.4743736.1488922006074.JavaMail.zimbra@redhat.com>

Josejulio, cc hawkular-dev:

<TL;DR>
Due to incomplete API support in a EAP 6.4 library, we cannot support the agent installed as a subsystem extension inside EAP6 if the agent is to talk to the Hawkular Server over HTTPS.
</TL;DR>

I don't know how to workaround this one - maybe someone has a bright idea. But right now, it looks like we can't support an EAP6-based agent talking to Hawkular-Metrics over HTTPS *unless* the agent is running as a javaagent (a new feature not even in master yet, but I tried it and it works).

This is a EAP 6.4 method that OKHttp is calling when making an HTTP request requiring SSL - I'll give you the summary - its a one-line auto-generated stub method that "return null;" :)

https://github.com/wildfly/wildfly-core/blame/de6b17d4d342e98871c0e95f7e6faa9006383768/domain-management/src/main/java/org/jboss/as/domain/management/security/WrapperSSLContext.java#L124-L126

I stepped into this code via a debugger and the line number and behavior (returning null always) matches up with that code.

Needless to say, this causes a NullPointerException later on in the OKHttp library and thus cannot talk to the Hawkular Server over HTTPS.

Here's the stack trace that got me there:

Daemon Thread [Hawkular WildFly Agent Startup Thread] (Suspended)	
	org.jboss.as.domain.management.security.WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory.createSocket(java.net.Socket, java.lang.String, int, boolean) line: 126	
	okhttp3.internal.connection.RealConnection.connectTls(int, int, okhttp3.internal.connection.ConnectionSpecSelector) line: 230	
	okhttp3.internal.connection.RealConnection.establishProtocol(int, int, okhttp3.internal.connection.ConnectionSpecSelector) line: 198	
	okhttp3.internal.connection.RealConnection.buildConnection(int, int, int, okhttp3.internal.connection.ConnectionSpecSelector) line: 174	
	okhttp3.internal.connection.RealConnection.connect(int, int, int, java.util.List<okhttp3.ConnectionSpec>, boolean) line: 114	
	okhttp3.internal.connection.StreamAllocation.findConnection(int, int, int, boolean) line: 193	
	okhttp3.internal.connection.StreamAllocation.findHealthyConnection(int, int, int, boolean, boolean) line: 129	
	okhttp3.internal.connection.StreamAllocation.newStream(okhttp3.OkHttpClient, boolean) line: 98	
	okhttp3.internal.connection.ConnectInterceptor.intercept(okhttp3.Interceptor$Chain) line: 42	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request, okhttp3.internal.connection.StreamAllocation, okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67	
	okhttp3.internal.cache.CacheInterceptor.intercept(okhttp3.Interceptor$Chain) line: 109	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request, okhttp3.internal.connection.StreamAllocation, okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67	
	okhttp3.internal.http.BridgeInterceptor.intercept(okhttp3.Interceptor$Chain) line: 93	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request, okhttp3.internal.connection.StreamAllocation, okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92	
	okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(okhttp3.Interceptor$Chain) line: 124	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request, okhttp3.internal.connection.StreamAllocation, okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92	
	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67	
	okhttp3.RealCall.getResponseWithInterceptorChain() line: 170	
	okhttp3.RealCall.execute() line: 60	
	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).waitForHawkularServer() line: 648	
	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent(org.hawkular.agent.monitor.config.AgentCoreEngineConfiguration) line: 279	
	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent() line: 164	
	org.hawkular.agent.monitor.service.MonitorService$1CustomPropertyChangeListener$1.run() line: 395	
	java.lang.Thread.run() line: 745	

From mazz at redhat.com  Tue Mar  7 17:03:38 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 7 Mar 2017 17:03:38 -0500 (EST)
Subject: [Hawkular-dev] agent running in EAP6.4 cannot talk to Hawkular
 Server over HTTPS
In-Reply-To: <1676766165.4743736.1488922006074.JavaMail.zimbra@redhat.com>
References: <1676766165.4743736.1488922006074.JavaMail.zimbra@redhat.com>
Message-ID: <1050522903.4753988.1488924218305.JavaMail.zimbra@redhat.com>

BTW: the latest agent release/master branch will not produce this NPE but it still isn't good because, instead of getting an NPE, you get this loveliness:

16:57:53,081 ERROR [org.hawkular.agent.monitor.service.MonitorService] (Hawkular WildFly Agent Startup Thread) HAWKMONITOR010054: Agent encountered errors during start up and will be stopped.: java.lang.IllegalStateException: Unable to extract the trust manager on okhttp3.internal.platform.Platform at 69f176ea, sslSocketFactory is class org.jboss.as.domain.management.security.WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory
	at okhttp3.OkHttpClient$Builder.sslSocketFactory(OkHttpClient.java:599)

OKHttp is looking for particular SSL class to find a trust manager but is thrown for a loop when it finds WildFly has its own wrapper implementation. This is the whole reason why this PR exists (and the NPE shows up when running with that PR):

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

(and just to clarify, this is only an issue on EAP6.4. Everything works fine on EAP7+)

----- Original Message -----
> Josejulio, cc hawkular-dev:
> 
> <TL;DR>
> Due to incomplete API support in a EAP 6.4 library, we cannot support the
> agent installed as a subsystem extension inside EAP6 if the agent is to talk
> to the Hawkular Server over HTTPS.
> </TL;DR>
> 
> I don't know how to workaround this one - maybe someone has a bright idea.
> But right now, it looks like we can't support an EAP6-based agent talking to
> Hawkular-Metrics over HTTPS *unless* the agent is running as a javaagent (a
> new feature not even in master yet, but I tried it and it works).
> 
> This is a EAP 6.4 method that OKHttp is calling when making an HTTP request
> requiring SSL - I'll give you the summary - its a one-line auto-generated
> stub method that "return null;" :)
> 
> https://github.com/wildfly/wildfly-core/blame/de6b17d4d342e98871c0e95f7e6faa9006383768/domain-management/src/main/java/org/jboss/as/domain/management/security/WrapperSSLContext.java#L124-L126
> 
> I stepped into this code via a debugger and the line number and behavior
> (returning null always) matches up with that code.
> 
> Needless to say, this causes a NullPointerException later on in the OKHttp
> library and thus cannot talk to the Hawkular Server over HTTPS.
> 
> Here's the stack trace that got me there:
> 
> Daemon Thread [Hawkular WildFly Agent Startup Thread] (Suspended)
> 	org.jboss.as.domain.management.security.WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory.createSocket(java.net.Socket,
> 	java.lang.String, int, boolean) line: 126
> 	okhttp3.internal.connection.RealConnection.connectTls(int, int,
> 	okhttp3.internal.connection.ConnectionSpecSelector) line: 230
> 	okhttp3.internal.connection.RealConnection.establishProtocol(int, int,
> 	okhttp3.internal.connection.ConnectionSpecSelector) line: 198
> 	okhttp3.internal.connection.RealConnection.buildConnection(int, int, int,
> 	okhttp3.internal.connection.ConnectionSpecSelector) line: 174
> 	okhttp3.internal.connection.RealConnection.connect(int, int, int,
> 	java.util.List<okhttp3.ConnectionSpec>, boolean) line: 114
> 	okhttp3.internal.connection.StreamAllocation.findConnection(int, int, int,
> 	boolean) line: 193
> 	okhttp3.internal.connection.StreamAllocation.findHealthyConnection(int, int,
> 	int, boolean, boolean) line: 129
> 	okhttp3.internal.connection.StreamAllocation.newStream(okhttp3.OkHttpClient,
> 	boolean) line: 98
> 	okhttp3.internal.connection.ConnectInterceptor.intercept(okhttp3.Interceptor$Chain)
> 	line: 42
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request,
> 	okhttp3.internal.connection.StreamAllocation,
> 	okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67
> 	okhttp3.internal.cache.CacheInterceptor.intercept(okhttp3.Interceptor$Chain)
> 	line: 109
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request,
> 	okhttp3.internal.connection.StreamAllocation,
> 	okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67
> 	okhttp3.internal.http.BridgeInterceptor.intercept(okhttp3.Interceptor$Chain)
> 	line: 93
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request,
> 	okhttp3.internal.connection.StreamAllocation,
> 	okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> 	okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(okhttp3.Interceptor$Chain)
> 	line: 124
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request,
> 	okhttp3.internal.connection.StreamAllocation,
> 	okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> 	okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request) line: 67
> 	okhttp3.RealCall.getResponseWithInterceptorChain() line: 170
> 	okhttp3.RealCall.execute() line: 60
> 	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).waitForHawkularServer()
> 	line: 648
> 	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent(org.hawkular.agent.monitor.config.AgentCoreEngineConfiguration)
> 	line: 279
> 	org.hawkular.agent.monitor.service.MonitorService(org.hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent()
> 	line: 164
> 	org.hawkular.agent.monitor.service.MonitorService$1CustomPropertyChangeListener$1.run()
> 	line: 395
> 	java.lang.Thread.run() line: 745
> 

From jmartine at redhat.com  Tue Mar  7 19:48:58 2017
From: jmartine at redhat.com (Josejulio Martinez Magana)
Date: Tue, 7 Mar 2017 18:48:58 -0600
Subject: [Hawkular-dev] agent running in EAP6.4 cannot talk to Hawkular
 Server over HTTPS
In-Reply-To: <1050522903.4753988.1488924218305.JavaMail.zimbra@redhat.com>
References: <1676766165.4743736.1488922006074.JavaMail.zimbra@redhat.com>
	<1050522903.4753988.1488924218305.JavaMail.zimbra@redhat.com>
Message-ID: <CAD4MJEDRY+Q7RnHELxJutzYrbOxtwCyMCEJQ9mXPTevMdhwNWA@mail.gmail.com>

Only thing I could think of was to use reflection to get the actual wrapped
factory:

https://github.com/hawkular/hawkular-agent/pull/300/commits/bedf8a19496aba56df71c95447b1327c766676d5#diff-394e3f128a0dd5307095aab90861bce7R319

This is currently working on EAP6 (and EAP7).

On Tue, Mar 7, 2017 at 4:03 PM, John Mazzitelli <mazz at redhat.com> wrote:

> BTW: the latest agent release/master branch will not produce this NPE but
> it still isn't good because, instead of getting an NPE, you get this
> loveliness:
>
> 16:57:53,081 ERROR [org.hawkular.agent.monitor.service.MonitorService]
> (Hawkular WildFly Agent Startup Thread) HAWKMONITOR010054: Agent
> encountered errors during start up and will be stopped.: java.lang.IllegalStateException:
> Unable to extract the trust manager on okhttp3.internal.platform.
> Platform at 69f176ea, sslSocketFactory is class org.jboss.as.domain.
> management.security.WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory
>         at okhttp3.OkHttpClient$Builder.sslSocketFactory(OkHttpClient.
> java:599)
>
> OKHttp is looking for particular SSL class to find a trust manager but is
> thrown for a loop when it finds WildFly has its own wrapper implementation.
> This is the whole reason why this PR exists (and the NPE shows up when
> running with that PR):
>
> https://github.com/hawkular/hawkular-agent/pull/300
>
> (and just to clarify, this is only an issue on EAP6.4. Everything works
> fine on EAP7+)
>
> ----- Original Message -----
> > Josejulio, cc hawkular-dev:
> >
> > <TL;DR>
> > Due to incomplete API support in a EAP 6.4 library, we cannot support the
> > agent installed as a subsystem extension inside EAP6 if the agent is to
> talk
> > to the Hawkular Server over HTTPS.
> > </TL;DR>
> >
> > I don't know how to workaround this one - maybe someone has a bright
> idea.
> > But right now, it looks like we can't support an EAP6-based agent
> talking to
> > Hawkular-Metrics over HTTPS *unless* the agent is running as a javaagent
> (a
> > new feature not even in master yet, but I tried it and it works).
> >
> > This is a EAP 6.4 method that OKHttp is calling when making an HTTP
> request
> > requiring SSL - I'll give you the summary - its a one-line auto-generated
> > stub method that "return null;" :)
> >
> > https://github.com/wildfly/wildfly-core/blame/
> de6b17d4d342e98871c0e95f7e6faa9006383768/domain-management/
> src/main/java/org/jboss/as/domain/management/security/
> WrapperSSLContext.java#L124-L126
> >
> > I stepped into this code via a debugger and the line number and behavior
> > (returning null always) matches up with that code.
> >
> > Needless to say, this causes a NullPointerException later on in the
> OKHttp
> > library and thus cannot talk to the Hawkular Server over HTTPS.
> >
> > Here's the stack trace that got me there:
> >
> > Daemon Thread [Hawkular WildFly Agent Startup Thread] (Suspended)
> >       org.jboss.as.domain.management.security.
> WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory.
> createSocket(java.net.Socket,
> >       java.lang.String, int, boolean) line: 126
> >       okhttp3.internal.connection.RealConnection.connectTls(int, int,
> >       okhttp3.internal.connection.ConnectionSpecSelector) line: 230
> >       okhttp3.internal.connection.RealConnection.establishProtocol(int,
> int,
> >       okhttp3.internal.connection.ConnectionSpecSelector) line: 198
> >       okhttp3.internal.connection.RealConnection.buildConnection(int,
> int, int,
> >       okhttp3.internal.connection.ConnectionSpecSelector) line: 174
> >       okhttp3.internal.connection.RealConnection.connect(int, int, int,
> >       java.util.List<okhttp3.ConnectionSpec>, boolean) line: 114
> >       okhttp3.internal.connection.StreamAllocation.findConnection(int,
> int, int,
> >       boolean) line: 193
> >       okhttp3.internal.connection.StreamAllocation.findHealthyConnection(int,
> int,
> >       int, boolean, boolean) line: 129
> >       okhttp3.internal.connection.StreamAllocation.newStream(
> okhttp3.OkHttpClient,
> >       boolean) line: 98
> >       okhttp3.internal.connection.ConnectInterceptor.intercept(
> okhttp3.Interceptor$Chain)
> >       line: 42
> >       okhttp3.internal.http.RealInterceptorChain.proceed(
> okhttp3.Request,
> >       okhttp3.internal.connection.StreamAllocation,
> >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> line: 67
> >       okhttp3.internal.cache.CacheInterceptor.intercept(
> okhttp3.Interceptor$Chain)
> >       line: 109
> >       okhttp3.internal.http.RealInterceptorChain.proceed(
> okhttp3.Request,
> >       okhttp3.internal.connection.StreamAllocation,
> >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> line: 67
> >       okhttp3.internal.http.BridgeInterceptor.intercept(
> okhttp3.Interceptor$Chain)
> >       line: 93
> >       okhttp3.internal.http.RealInterceptorChain.proceed(
> okhttp3.Request,
> >       okhttp3.internal.connection.StreamAllocation,
> >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> >       okhttp3.internal.http.RetryAndFollowUpInterceptor.
> intercept(okhttp3.Interceptor$Chain)
> >       line: 124
> >       okhttp3.internal.http.RealInterceptorChain.proceed(
> okhttp3.Request,
> >       okhttp3.internal.connection.StreamAllocation,
> >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> line: 67
> >       okhttp3.RealCall.getResponseWithInterceptorChain() line: 170
> >       okhttp3.RealCall.execute() line: 60
> >       org.hawkular.agent.monitor.service.MonitorService(org.
> hawkular.agent.monitor.service.AgentCoreEngine).waitForHawkularServer()
> >       line: 648
> >       org.hawkular.agent.monitor.service.MonitorService(org.
> hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent(org.
> hawkular.agent.monitor.config.AgentCoreEngineConfiguration)
> >       line: 279
> >       org.hawkular.agent.monitor.service.MonitorService(org.
> hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent()
> >       line: 164
> >       org.hawkular.agent.monitor.service.MonitorService$
> 1CustomPropertyChangeListener$1.run()
> >       line: 395
> >       java.lang.Thread.run() line: 745
> >
> _______________________________________________
> 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/20170307/efee44b3/attachment-0001.html 

From mazz at redhat.com  Wed Mar  8 00:55:05 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 8 Mar 2017 00:55:05 -0500 (EST)
Subject: [Hawkular-dev] agent running in EAP6.4 cannot talk to Hawkular
 Server over HTTPS
In-Reply-To: <CAD4MJEDRY+Q7RnHELxJutzYrbOxtwCyMCEJQ9mXPTevMdhwNWA@mail.gmail.com>
References: <1676766165.4743736.1488922006074.JavaMail.zimbra@redhat.com>
	<1050522903.4753988.1488924218305.JavaMail.zimbra@redhat.com>
	<CAD4MJEDRY+Q7RnHELxJutzYrbOxtwCyMCEJQ9mXPTevMdhwNWA@mail.gmail.com>
Message-ID: <529088565.4912501.1488952505758.JavaMail.zimbra@redhat.com>

Thank you, JoseJulio - your fix worked! Crisis averted :)

I ran some tests over here and it looks good.

----- Original Message -----
> Only thing I could think of was to use reflection to get the actual wrapped
> factory:
> 
> https://github.com/hawkular/hawkular-agent/pull/300/commits/bedf8a19496aba56df71c95447b1327c766676d5#diff-394e3f128a0dd5307095aab90861bce7R319
> 
> This is currently working on EAP6 (and EAP7).
> 
> On Tue, Mar 7, 2017 at 4:03 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> > BTW: the latest agent release/master branch will not produce this NPE but
> > it still isn't good because, instead of getting an NPE, you get this
> > loveliness:
> >
> > 16:57:53,081 ERROR [org.hawkular.agent.monitor.service.MonitorService]
> > (Hawkular WildFly Agent Startup Thread) HAWKMONITOR010054: Agent
> > encountered errors during start up and will be stopped.:
> > java.lang.IllegalStateException:
> > Unable to extract the trust manager on okhttp3.internal.platform.
> > Platform at 69f176ea, sslSocketFactory is class org.jboss.as.domain.
> > management.security.WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory
> >         at okhttp3.OkHttpClient$Builder.sslSocketFactory(OkHttpClient.
> > java:599)
> >
> > OKHttp is looking for particular SSL class to find a trust manager but is
> > thrown for a loop when it finds WildFly has its own wrapper implementation.
> > This is the whole reason why this PR exists (and the NPE shows up when
> > running with that PR):
> >
> > https://github.com/hawkular/hawkular-agent/pull/300
> >
> > (and just to clarify, this is only an issue on EAP6.4. Everything works
> > fine on EAP7+)
> >
> > ----- Original Message -----
> > > Josejulio, cc hawkular-dev:
> > >
> > > <TL;DR>
> > > Due to incomplete API support in a EAP 6.4 library, we cannot support the
> > > agent installed as a subsystem extension inside EAP6 if the agent is to
> > talk
> > > to the Hawkular Server over HTTPS.
> > > </TL;DR>
> > >
> > > I don't know how to workaround this one - maybe someone has a bright
> > idea.
> > > But right now, it looks like we can't support an EAP6-based agent
> > talking to
> > > Hawkular-Metrics over HTTPS *unless* the agent is running as a javaagent
> > (a
> > > new feature not even in master yet, but I tried it and it works).
> > >
> > > This is a EAP 6.4 method that OKHttp is calling when making an HTTP
> > request
> > > requiring SSL - I'll give you the summary - its a one-line auto-generated
> > > stub method that "return null;" :)
> > >
> > > https://github.com/wildfly/wildfly-core/blame/
> > de6b17d4d342e98871c0e95f7e6faa9006383768/domain-management/
> > src/main/java/org/jboss/as/domain/management/security/
> > WrapperSSLContext.java#L124-L126
> > >
> > > I stepped into this code via a debugger and the line number and behavior
> > > (returning null always) matches up with that code.
> > >
> > > Needless to say, this causes a NullPointerException later on in the
> > OKHttp
> > > library and thus cannot talk to the Hawkular Server over HTTPS.
> > >
> > > Here's the stack trace that got me there:
> > >
> > > Daemon Thread [Hawkular WildFly Agent Startup Thread] (Suspended)
> > >       org.jboss.as.domain.management.security.
> > WrapperSSLContext$WrapperSpi$WrapperSSLSocketFactory.
> > createSocket(java.net.Socket,
> > >       java.lang.String, int, boolean) line: 126
> > >       okhttp3.internal.connection.RealConnection.connectTls(int, int,
> > >       okhttp3.internal.connection.ConnectionSpecSelector) line: 230
> > >       okhttp3.internal.connection.RealConnection.establishProtocol(int,
> > int,
> > >       okhttp3.internal.connection.ConnectionSpecSelector) line: 198
> > >       okhttp3.internal.connection.RealConnection.buildConnection(int,
> > int, int,
> > >       okhttp3.internal.connection.ConnectionSpecSelector) line: 174
> > >       okhttp3.internal.connection.RealConnection.connect(int, int, int,
> > >       java.util.List<okhttp3.ConnectionSpec>, boolean) line: 114
> > >       okhttp3.internal.connection.StreamAllocation.findConnection(int,
> > int, int,
> > >       boolean) line: 193
> > >       okhttp3.internal.connection.StreamAllocation.findHealthyConnection(int,
> > int,
> > >       int, boolean, boolean) line: 129
> > >       okhttp3.internal.connection.StreamAllocation.newStream(
> > okhttp3.OkHttpClient,
> > >       boolean) line: 98
> > >       okhttp3.internal.connection.ConnectInterceptor.intercept(
> > okhttp3.Interceptor$Chain)
> > >       line: 42
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(
> > okhttp3.Request,
> > >       okhttp3.internal.connection.StreamAllocation,
> > >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> > line: 67
> > >       okhttp3.internal.cache.CacheInterceptor.intercept(
> > okhttp3.Interceptor$Chain)
> > >       line: 109
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(
> > okhttp3.Request,
> > >       okhttp3.internal.connection.StreamAllocation,
> > >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> > line: 67
> > >       okhttp3.internal.http.BridgeInterceptor.intercept(
> > okhttp3.Interceptor$Chain)
> > >       line: 93
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(
> > okhttp3.Request,
> > >       okhttp3.internal.connection.StreamAllocation,
> > >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> > >       okhttp3.internal.http.RetryAndFollowUpInterceptor.
> > intercept(okhttp3.Interceptor$Chain)
> > >       line: 124
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(
> > okhttp3.Request,
> > >       okhttp3.internal.connection.StreamAllocation,
> > >       okhttp3.internal.http.HttpStream, okhttp3.Connection) line: 92
> > >       okhttp3.internal.http.RealInterceptorChain.proceed(okhttp3.Request)
> > line: 67
> > >       okhttp3.RealCall.getResponseWithInterceptorChain() line: 170
> > >       okhttp3.RealCall.execute() line: 60
> > >       org.hawkular.agent.monitor.service.MonitorService(org.
> > hawkular.agent.monitor.service.AgentCoreEngine).waitForHawkularServer()
> > >       line: 648
> > >       org.hawkular.agent.monitor.service.MonitorService(org.
> > hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent(org.
> > hawkular.agent.monitor.config.AgentCoreEngineConfiguration)
> > >       line: 279
> > >       org.hawkular.agent.monitor.service.MonitorService(org.
> > hawkular.agent.monitor.service.AgentCoreEngine).startHawkularAgent()
> > >       line: 164
> > >       org.hawkular.agent.monitor.service.MonitorService$
> > 1CustomPropertyChangeListener$1.run()
> > >       line: 395
> > >       java.lang.Thread.run() line: 745
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> 

From jshaughn at redhat.com  Wed Mar  8 10:49:24 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Wed, 8 Mar 2017 10:49:24 -0500
Subject: [Hawkular-dev] Command gateway and WF agent
In-Reply-To: <CAJo5TF=NJ9fzL4s5wQKqb_f59q58-KbrdmzOdFcwLejsDQZOcA@mail.gmail.com>
References: <CAJo5TF=4Xtc1Rj-U_u3f9yxLWv=p5A9E-hzHjq7zHq5FAtN8fQ@mail.gmail.com>
	<1813151977.4439961.1488895956664.JavaMail.zimbra@redhat.com>
	<CAJo5TF=NJ9fzL4s5wQKqb_f59q58-KbrdmzOdFcwLejsDQZOcA@mail.gmail.com>
Message-ID: <e97219ea-87b1-0d56-a371-6b2c31750b24@redhat.com>

 > First, remember the MiQ UI is connected to Hawkular-Services server 
via websocket.

One small nit, the MIQ UI websocket connection is via our ruby gem, so 
really any user of the rubly client could, I think, utilize the cmdgw stuff.

 > ... HOWEVER, I believe Jay added some code that does interact with 
Inventory to do things like create relationships in inventory when new 
cluster entities are added.

There is no code in cmdgw doing any interaction with inventory.  In 
cmdgw we only declare the supported request/responses.  There are two 
aspects of hServices that interact with inventory.

The InventoryEventListener listens for JMS events publish by Inventory 
and is responsible for:

  * generating Added/Removed Server events to be consumed by MIQ
      o using events for various server types
  * generating "isClusteredWith" relationships for clustered servers
      o using events for JGroups Channels

Inventory will no longer be generating these events and this listener 
will likely have to go away.  Either the agent will need to start 
generating the events or we'll need a new component to drive off of the 
persisted inventory data in metrics.


The Feed BackFill mechanism:

  * Needs to get and set the avail metrics for a feed's resources when
    the feed goes down (detected either by lack of avail heartbeat, or
    via broken websocket).

We will need to replace the inventory traversal query with something 
based on the new metrics impl.


On 3/7/2017 9:26 AM, Joel Takvorian wrote:
> Nice explanation, thanks!
>
> On Tue, Mar 7, 2017 at 3:12 PM, John Mazzitelli <mazz at redhat.com 
> <mailto:mazz at redhat.com>> wrote:
>
>     > Can you explain to me what's the big picture of the command gateway? What's
>     > the chain of calls when, for instance, there's a new deployment
>     in Wildfly?
>
>     Joel asked this question - I figured it is good to post to h-dev,
>     too, since I'm sure others don't know this.
>
>     The "big picture" is:
>
>     First, remember the MiQ UI is connected to Hawkular-Services
>     server via websocket. The agents all connect to some
>     Hawkular-Services server via a websocket. There can be more than
>     one Hawkular-Services server running and the UI may be talking to
>     a server that is different than the server the agent is talking to:
>
>     UI <---websocket---> Server A
>                              ^
>                              |
>                        (message bus)
>                              |
>                              V
>                          Server B <---websocket---> agent
>
>
>     1) MiQ sends a JSON message over the websocket to a
>     Hawkular-Services server (Server A in the diagram above).
>     2) Hawkular-Services server A looks at the ResourcePath in the
>     message to determine what agent is responsible for managing that
>     resource.
>     3) Hawkular-Services server A addresses the message to the proper
>     agent and puts the JSON message on the agent's queue on the
>     message bus.
>     3b) At this point the Hawkular-Services server A sends back a JSON
>     message to the UI over the websocket that says "message forwarded
>     to the bus".
>     4) The Hawkular-Services server that has a websocket connection to
>     the targeted agent picks off that message from the bus (Server B
>     in the diagram)
>     5) That Hawkular-Services server B forwards the message to the
>     agent via its websocket connection.
>     6) Agent looks the the message's ResourcePath and the rest of the
>     JSON to determine what it needs to do. It does the action.
>
>     // now the process goes in reverse
>
>     7) Agent sends back a response to the server B over websocket
>     (either a success or fail message)
>     8) Server B takes response, figures out which UI the response
>     should go to, and puts it on message bus addressed to the correct UI
>     9) The Server A takes the response message off the bus
>     10) Server A sends the response message to the UI over its
>     websocket connection.
>
>
>     > Tell me if I'm correct, for what I've seen it's MIQ which,
>     though the ruby
>     > client, sends a websocket event, caught by the WF agent through
>     the command
>     > gateway. In the end, the WF agent will perform a full sync of
>     affected root
>     > resources in inventory. Is that correct?
>
>     In the case of a "Deployment" JSON message, yes, the agent will
>     trigger a full discovery scan so it can quickly discover the new
>     deployment you just added to WildFly.
>
>     > If that's correct, there's no direct interaction between
>     inventory and the
>     > command gateway. I'm asking because I hope we can keep the
>     command gateway
>     > messages unchanged, and change only places where there's direct
>     calls to
>     > the inventory rest api.
>
>     Most of the time, its just using ResourcePath API (just that
>     simple inventory POJO). HOWEVER, I believe Jay added some code
>     that does interact with Inventory to do things like create
>     relationships in inventory when new cluster entities are added.
>     That is why (I think) he did this commit. Though I can't remember
>     where this code is that builds inventory relationships - he'll
>     have to point that out. But I'm pretty sure there is some
>     inventory stuff going on under the covers for that stuff - more
>     than just using the canonical ResourcePath stuff.
>
>
>
>
> _______________________________________________
> 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/20170308/9dd6d2a5/attachment.html 

From hrupp at redhat.com  Wed Mar  8 11:54:46 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 08 Mar 2017 17:54:46 +0100
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
Message-ID: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>

Hi,

I know I brought that up in the past ... (and I am sure Juca will easily 
find where :-)

In the good old datacenter, one deployed an application server with 
application, added it to monitoring and it hummed there happily. The 
server sometimes got rebooted for OS updates or other things, but the 
app-server always stayed the same and the monitoring system knew all its 
pets by their name and the admins happily did this: 
http://www.starwars-union.de/bilder/news/20110401_sunset.jpg

Nowadays in orchestration system the situation more looks like this
http://www.animationsfilme.ch/wp-content/uploads/2013/07/DespicableMe_01.jpg

where containers come and go and an application in container once it has 
died is not re-started but a new container with its own ID is started.

Of course we can identify applications with labels so that I don't need 
to know the container id. So I can gather and display metrics for those 
and all is fine.

But: all those containers will create new
- metric ids
- inventory entries
- ???

The question is now: how long do we want/need to keep them?
Hawkular-metrics has a TTL for the datapoints, but I think metric 
definitions are not evicted.
Similar a container being killed can't easily tell inventory that its 
entry can go away.

For inventory-new we could use the expiration feature of 
Hawkular-metrics for datapoints, where e.g. the agent would regularly 
sync data and thus refresh the last-seen time to keep an entry "alive".

Also for the pure metrics - how much of historic data do we want/need. 
And if we would e.g. aggregate those for long(er) term storage I think 
we could perhaps actually aggregate over all individual time series over 
many parallel pods and aggregate them into one for the entire 
application.

   Heiko


From mazz at redhat.com  Wed Mar  8 12:08:22 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 8 Mar 2017 12:08:22 -0500 (EST)
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
	solution
In-Reply-To: <1201856641.5257299.1488990871411.JavaMail.zimbra@redhat.com>
Message-ID: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>

Right now, the Hawkular WildFly Agent runs as a WildFly subsystem extension - which means it must run in EAP.

To avoid this requirement, I refactored the agent code [1] so it can be run using a standard VM javaagent (using the VM argument -javaagent).

This means the agent need not run as a subsystem extension, in fact, it can run in any VM (non-EAP/WildFly based). Just pass in the -javaagent command line argument to your VM and you got an agent. You have a Karaf container in a JVM exposing metrics via JMX? You can use this. You got a vert.x server in a JVM exposing metrics via JMX? You can use this.

This new agent's config file is a single YAML file that mimics virtually the same settings as you see today in the agent's <subsystem> XML in standalone.xml.

Like the EAP-based agent, this new agent can still:

* collect DMR metrics and inventory from any EAP 6.4, EAP 7.x, or WildFly 10+ servers - local or remote.
* collect JMX metrics and inventory from any remote Jolokia endpoint or local JMX MBeanServer
* receive websocket messages from a Hawkular Server (if running in full Hawkular mode)
* run in metrics-only mode where it only stores data to Hawkular-Metrics and does not connect via websocket to the server nor stores inventory to H-Inventory
* Talk to the Hawkular Server and remote DMR/JMX endpoints via SSL/https using defined security-realms/keystores

Unlike the EAP-based agent, this new agent:

* does NOT have a CLI (jboss-cli.sh is the EAP-based agent's CLI)
* does NOT have a built-in configuration persistent mechanicm (EAP-based agents can persist their config changes to standalone.xml when those changes are made via the WildFly management interface - because the javaagent is completely independent, it has nothing like this for its YAML config).
* does NOT integrate with the lifecycle of any EAP/WildFly running in the same VM (in other words, if you ask to "reload" the EAP server, the javaagent knows nothing about that and won't also itself reload. Remember, this javaagent is now completely independent of any co-located EAP/WildFly server).

In addition, if your JVM is installed in OpenShift, you can get the nice option of putting the javaagent's YAML config in a config map and mount it so your javaagent can access it. This means you can edit your javaagent YAML directly in the OpenShift UI :)

I still need to see how well this supports the disabling/enabling of metrics on the fly from the websocket commands (e.g. I will need to add the ability to change the YAML config to persist the settings, that is not done yet - the EAP-based agent got this support for free - its config changes go into standalone.xml).

Other than persisting changes to the YAML file, I believe this javaagent will work essentially the same as the current agent (indeed, the core agent engine is identical - its the same code). Just have to make sure the websocket commands can work considering there is a YAML config backing the settings and not standalone.xml.

I need people's feedback on this. Thoughts? If you want to try it, you can build it from my PR right now using the README [2] and the instructions [3].

--John Mazz

[1] https://github.com/hawkular/hawkular-agent/pull/302

[2] https://github.com/jmazzitelli/hawkular-agent/blob/refactor-core/hawkular-javaagent/README.adoc

[3] Instructions to build using the PR and test it by collecting EAP metrics:

1) Build it:

   $ git clone git at github.com:hawkular/hawkular-agent.git
   $ cd hawkular-agent
   $ git checkout -b jmazzitelli-refactor-core master
   $ git pull https://github.com/jmazzitelli/hawkular-agent.git refactor-core
   $ mvn clean install

2) Install it - assuming you have a base EAP 6.4 or 7.x or WildFly 10+ installed at <eap.dir>

2a) Change this line in <eap.dir>/bin/standalone.conf:

   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"

to this:

   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager"

2b) Inside that same <eap.dir>/bin/standalone.conf you add this line in the
    appropriate place (you know where, just under where it sets JAVA_OPTS):

   JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -javaagent:$JBOSS_HOME/bin/hawkular-javaagent-*.jar=config=$JBOSS_HOME/standalone/configuration/real-config*.yaml,delay=10"

2c) Copy the binary/config files you built to that EAP / WildFly install:

   cp hawkular-agent/hawkular-javaagent/target/hawkular-javaagent-*-jar-with-dependencies.jar <eap.dir>/bin

   if EAP 7.x/WildFly 10+:

   cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config.yaml <eap.dir>/standalone/configuration

   if EAP 6.4:

   cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config-eap6.yaml <eap.dir>/standalone/configuration





From mazz at redhat.com  Wed Mar  8 14:09:32 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 8 Mar 2017 14:09:32 -0500 (EST)
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP
	based	solution
In-Reply-To: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
Message-ID: <1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>

> I still need to see how well this supports the disabling/enabling of metrics
> on the fly from the websocket commands (e.g. I will need to add the ability
> to change the YAML config to persist the settings, that is not done yet -
> the EAP-based agent got this support for free - its config changes go into
> standalone.xml).

Just checked - the cmdgw command to update collection intervals won't work because it is assuming the agent is always DMR-accessible which it no longer is. This won't be hard to refactor that command to get it to work, but for now, this will not work when running as javaagent - still works as normal with the subsystem agent.

From jtakvori at redhat.com  Thu Mar  9 03:21:44 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Thu, 9 Mar 2017 09:21:44 +0100
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
Message-ID: <CAJo5TF=pVw=M-9DxxzVNpnHh5fZ=VjarMbrD1oz+NoUgOr1E2Q@mail.gmail.com>

>
>
>
> For inventory-new we could use the expiration feature of
> Hawkular-metrics for datapoints, where e.g. the agent would regularly
> sync data and thus refresh the last-seen time to keep an entry "alive".
>

If datapoints expire (that is, inventory "blobs"), their underlying metrics
will still be present in the database, even with no data associated. We may
want to delete them as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170309/58851af3/attachment.html 

From hrupp at redhat.com  Thu Mar  9 03:52:53 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 09 Mar 2017 09:52:53 +0100
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <CAJo5TF=pVw=M-9DxxzVNpnHh5fZ=VjarMbrD1oz+NoUgOr1E2Q@mail.gmail.com>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
	<CAJo5TF=pVw=M-9DxxzVNpnHh5fZ=VjarMbrD1oz+NoUgOr1E2Q@mail.gmail.com>
Message-ID: <0D3C72A7-E6D7-404A-8654-A281836C97A2@redhat.com>

On 9 Mar 2017, at 9:21, Joel Takvorian wrote:

> If datapoints expire (that is, inventory "blobs"), their underlying 
> metrics
> will still be present in the database, even with no data associated. 
> We may want to delete them as well.

While I would expect them to also expire by TTL.

It is though a discussion we need to have, as  this may not be
what is wanted:
Suppose you have an application with label app=shop.
Now that application has a component that comes from a 3rd party vendor 
and which has a memory hole. The vendor is not willing to provide a 
quick fix, but only at their usual 3 month cadence. To keep your shop 
online, you will either 'manually' restart it every night. Or have a 
liveness check for Kubernetes, which checks for free memory and when 
this is exhausted will report the container as non-live. Kubernetes will 
kill the pod and start a new one.
In any case here, you get a new pod for your app=shop and the old server 
in inventory is no longer needed, but e.g. for capacity planning you 
want to keep all metrics for app=shop.

What may hold true though is that e.g. after a week the granularity of 
the data may decrease and we may only keep aggregates. In this case the 
auto-expiry of the data could/would need to trigger an aggregation into 
another time-series that holds the aggregates. And perhaps at that point 
(as I wrote before) drop the container id(*) part from the metric id and 
actually "aggregate into the label"  E.g.

container1.cpu.usage{app=shop1}  -> label.app=shop1.cpu.usage
container2.cpu.usage{app=shop1}  -> label.app=shop1.cpu.usage

(the 'label.' prefix is used here to distinguish from "normal metrics" 
for illustration purposes

If container 1 and 2 above happen to run in parallel then the "usual" 
aggregation rules for a group would apply

label.app=shop1.cpu.usage.max = max (container1.cpu.usage{app=shop1}, 
container2.cpu.usage{app=shop1})

and so on. Basically aggregation of all parallel running containers and 
over a time interval.

From hrupp at redhat.com  Thu Mar  9 05:13:50 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 09 Mar 2017 11:13:50 +0100
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
Message-ID: <E558A6CC-66E1-4C06-8469-F3C3BBD0FAEE@redhat.com>

On 8 Mar 2017, at 18:08, John Mazzitelli wrote:

> In addition, if your JVM is installed in OpenShift, you can get the 
> nice option of putting the javaagent's YAML config in a config map and 
> mount it so your javaagent can access it.

> I still need to see how well this supports the disabling/enabling of 
> metrics on the fly from the websocket commands (e.g. I will need to 
> add the ability to change the YAML config to persist the settings, 
> that is not done yet - the EAP-based agent got this support for free - 
> its config changes go into standalone.xml).

This needs to differentiate openshift/non-openshift, so the
immutable+in-container flags would still be in action.

I think in OpenShift you could listen on the edit config map
event like Hosa does and then trigger a config reload.
There is https://github.com/fabric8io/kubernetes-client
that should already have the necessary functionality.

From theute at redhat.com  Thu Mar  9 05:34:42 2017
From: theute at redhat.com (Thomas Heute)
Date: Thu, 9 Mar 2017 11:34:42 +0100
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
	solution
In-Reply-To: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
References: <1201856641.5257299.1488990871411.JavaMail.zimbra@redhat.com>
	<1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MrNRY+SF8Ou==8N5XPOZSkS=p2xMRvAhQ49wUs7LnGcqg@mail.gmail.com>

Adding Thomas, as this could be interesting for Fuse on Karaf if we proceed
with this javaagent.

On Wed, Mar 8, 2017 at 6:08 PM, John Mazzitelli <mazz at redhat.com> wrote:

> Right now, the Hawkular WildFly Agent runs as a WildFly subsystem
> extension - which means it must run in EAP.
>
> To avoid this requirement, I refactored the agent code [1] so it can be
> run using a standard VM javaagent (using the VM argument -javaagent).
>
> This means the agent need not run as a subsystem extension, in fact, it
> can run in any VM (non-EAP/WildFly based). Just pass in the -javaagent
> command line argument to your VM and you got an agent. You have a Karaf
> container in a JVM exposing metrics via JMX? You can use this. You got a
> vert.x server in a JVM exposing metrics via JMX? You can use this.
>
> This new agent's config file is a single YAML file that mimics virtually
> the same settings as you see today in the agent's <subsystem> XML in
> standalone.xml.
>
> Like the EAP-based agent, this new agent can still:
>
> * collect DMR metrics and inventory from any EAP 6.4, EAP 7.x, or WildFly
> 10+ servers - local or remote.
> * collect JMX metrics and inventory from any remote Jolokia endpoint or
> local JMX MBeanServer
> * receive websocket messages from a Hawkular Server (if running in full
> Hawkular mode)
> * run in metrics-only mode where it only stores data to Hawkular-Metrics
> and does not connect via websocket to the server nor stores inventory to
> H-Inventory
> * Talk to the Hawkular Server and remote DMR/JMX endpoints via SSL/https
> using defined security-realms/keystores
>
> Unlike the EAP-based agent, this new agent:
>
> * does NOT have a CLI (jboss-cli.sh is the EAP-based agent's CLI)
> * does NOT have a built-in configuration persistent mechanicm (EAP-based
> agents can persist their config changes to standalone.xml when those
> changes are made via the WildFly management interface - because the
> javaagent is completely independent, it has nothing like this for its YAML
> config).
> * does NOT integrate with the lifecycle of any EAP/WildFly running in the
> same VM (in other words, if you ask to "reload" the EAP server, the
> javaagent knows nothing about that and won't also itself reload. Remember,
> this javaagent is now completely independent of any co-located EAP/WildFly
> server).
>
> In addition, if your JVM is installed in OpenShift, you can get the nice
> option of putting the javaagent's YAML config in a config map and mount it
> so your javaagent can access it. This means you can edit your javaagent
> YAML directly in the OpenShift UI :)
>
> I still need to see how well this supports the disabling/enabling of
> metrics on the fly from the websocket commands (e.g. I will need to add the
> ability to change the YAML config to persist the settings, that is not done
> yet - the EAP-based agent got this support for free - its config changes go
> into standalone.xml).
>
> Other than persisting changes to the YAML file, I believe this javaagent
> will work essentially the same as the current agent (indeed, the core agent
> engine is identical - its the same code). Just have to make sure the
> websocket commands can work considering there is a YAML config backing the
> settings and not standalone.xml.
>
> I need people's feedback on this. Thoughts? If you want to try it, you can
> build it from my PR right now using the README [2] and the instructions [3].
>
> --John Mazz
>
> [1] https://github.com/hawkular/hawkular-agent/pull/302
>
> [2] https://github.com/jmazzitelli/hawkular-agent/
> blob/refactor-core/hawkular-javaagent/README.adoc
>
> [3] Instructions to build using the PR and test it by collecting EAP
> metrics:
>
> 1) Build it:
>
>    $ git clone git at github.com:hawkular/hawkular-agent.git
>    $ cd hawkular-agent
>    $ git checkout -b jmazzitelli-refactor-core master
>    $ git pull https://github.com/jmazzitelli/hawkular-agent.git
> refactor-core
>    $ mvn clean install
>
> 2) Install it - assuming you have a base EAP 6.4 or 7.x or WildFly 10+
> installed at <eap.dir>
>
> 2a) Change this line in <eap.dir>/bin/standalone.conf:
>
>    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
>
> to this:
>
>    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager"
>
> 2b) Inside that same <eap.dir>/bin/standalone.conf you add this line in the
>     appropriate place (you know where, just under where it sets JAVA_OPTS):
>
>    JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -javaagent:$JBOSS_HOME/bin/hawkular-javaagent-*.jar=
> config=$JBOSS_HOME/standalone/configuration/real-config*.yaml,delay=10"
>
> 2c) Copy the binary/config files you built to that EAP / WildFly install:
>
>    cp hawkular-agent/hawkular-javaagent/target/hawkular-
> javaagent-*-jar-with-dependencies.jar <eap.dir>/bin
>
>    if EAP 7.x/WildFly 10+:
>
>    cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config.yaml
> <eap.dir>/standalone/configuration
>
>    if EAP 6.4:
>
>    cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config-eap6.yaml
> <eap.dir>/standalone/configuration
>
>
>
>
> _______________________________________________
> 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/20170309/da179a5f/attachment.html 

From lkrejci at redhat.com  Thu Mar  9 05:35:36 2017
From: lkrejci at redhat.com (Lukas Krejci)
Date: Thu, 09 Mar 2017 11:35:36 +0100
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
	especially with (orchestrated) containers
In-Reply-To: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
Message-ID: <3412312.S3QrPxfIO6@localhost.localdomain>

On Wednesday, March 8, 2017 5:54:46 PM CET Heiko W.Rupp wrote:
> Hi,
> 
> I know I brought that up in the past ... (and I am sure Juca will easily
> find where :-)
> 
> In the good old datacenter, one deployed an application server with
> application, added it to monitoring and it hummed there happily. The
> server sometimes got rebooted for OS updates or other things, but the
> app-server always stayed the same and the monitoring system knew all its
> pets by their name and the admins happily did this:
> http://www.starwars-union.de/bilder/news/20110401_sunset.jpg
> 
> Nowadays in orchestration system the situation more looks like this
> http://www.animationsfilme.ch/wp-content/uploads/2013/07/DespicableMe_01.jpg
> 
> where containers come and go and an application in container once it has
> died is not re-started but a new container with its own ID is started.
> 
> Of course we can identify applications with labels so that I don't need
> to know the container id. So I can gather and display metrics for those
> and all is fine.
> 
> But: all those containers will create new
> - metric ids
> - inventory entries
> - ???
> 
> The question is now: how long do we want/need to keep them?

Isn't the question rather "how do we associate them with the application(s)"? 
Because if we want to track e.g. CPU load generated by an application in a 
container - isn't that something users would want to look at history of? IMHO, 
using the ephemeral "container id" as (part of) metric ids is a wrong thing to 
do, because really the user isn't interested in the container itself, but the 
applications that are running in it and their consumption of container's 
resources.


> Hawkular-metrics has a TTL for the datapoints, but I think metric
> definitions are not evicted.
> Similar a container being killed can't easily tell inventory that its
> entry can go away.
> 
> For inventory-new we could use the expiration feature of
> Hawkular-metrics for datapoints, where e.g. the agent would regularly
> sync data and thus refresh the last-seen time to keep an entry "alive".
> 
> Also for the pure metrics - how much of historic data do we want/need.
> And if we would e.g. aggregate those for long(er) term storage I think
> we could perhaps actually aggregate over all individual time series over
> many parallel pods and aggregate them into one for the entire
> application.
> 
>    Heiko
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


-- 
Lukas Krejci

From hrupp at redhat.com  Thu Mar  9 07:13:33 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Thu, 09 Mar 2017 13:13:33 +0100
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <3412312.S3QrPxfIO6@localhost.localdomain>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
	<3412312.S3QrPxfIO6@localhost.localdomain>
Message-ID: <FF9600E0-3969-413F-AB9A-E2ADB9DA1320@redhat.com>

On 9 Mar 2017, at 11:35, Lukas Krejci wrote:
>> The question is now: how long do we want/need to keep them?
>
> Isn't the question rather "how do we associate them with the  
> application(s)"?

Yes. And I think labels are the way of choice here.

> Because if we want to track e.g. CPU load generated by an application 
> in a container - isn't that something users would want to look at 
> history of? IMHO, using the ephemeral "container id" as (part of) 
> metric ids is a wrong thing to
> do, because really the user isn't interested in the container itself, 
> but the applications that are running in it and their consumption of 
> container's resources.

I think one needs to differentiate two time ranges here
- container active or just died
- historic view in the application
In both time ranges it is of course important to know how the overall
application behaves.

While the container is active one does not only want to know how the 
application behaves, but also how each individual container does. If 
there is only one running in parallel (scale=1) then it is less of an 
issue as application=container.
But once you scale the application up, this is no longer true. And 
individual containers may behave differently ( e.g. this memory hole I 
described does not always show ) so one may want to have the data to act 
accordingly. Either live or in a post mortem.

When aggregation kicks in, the difference between containers goes moot 
and just looking at it by label is ok.
I think for most (all?) aggregations it will not matter if the data is 
reported to one time-series for all parallel running containers or on 
one per container.

From gbrown at redhat.com  Thu Mar  9 09:14:49 2017
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 9 Mar 2017 09:14:49 -0500 (EST)
Subject: [Hawkular-dev] Example github repos for Hawkular
In-Reply-To: <500521498.489.1489068612292.JavaMail.zimbra@redhat.com>
Message-ID: <1531131452.6587.1489068889615.JavaMail.zimbra@redhat.com>

I have been working on a github repo [1] for a Spring Boot example, which uses the new OpenTracing Java Agent [2] with Hawkular APM.

Currently this is located in my own github account - but will soon be referenced from the OpenTracing JavaAgent project as an example of how to use the agent with an OpenTracing compliant tracer.

Therefore was wondering if it would be better for this example repo to be located under the Hawkular org?

Regards
Gary

[1] https://github.com/objectiser/java-agent-spring-boot-example
[2] https://github.com/opentracing-contrib/java-agent


From mazz at redhat.com  Thu Mar  9 09:50:02 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 9 Mar 2017 09:50:02 -0500 (EST)
Subject: [Hawkular-dev] Example github repos for Hawkular
In-Reply-To: <1531131452.6587.1489068889615.JavaMail.zimbra@redhat.com>
References: <1531131452.6587.1489068889615.JavaMail.zimbra@redhat.com>
Message-ID: <1837553333.139699.1489071002747.JavaMail.zimbra@redhat.com>

> I have been working on a github repo [1] for a Spring Boot example, which
> uses the new OpenTracing Java Agent [2] with Hawkular APM.
> 
> Currently this is located in my own github account - but will soon be
> referenced from the OpenTracing JavaAgent project as an example of how to
> use the agent with an OpenTracing compliant tracer.
> 
> Therefore was wondering if it would be better for this example repo to be
> located under the Hawkular org?



You should put it under some kind of "examples" folder in your APM repo.

I do the same thing with the several HOSA examples:

https://github.com/hawkular/hawkular-openshift-agent/tree/master/examples



> 
> Regards
> Gary
> 
> [1] https://github.com/objectiser/java-agent-spring-boot-example
> [2] https://github.com/opentracing-contrib/java-agent

From gbrown at redhat.com  Thu Mar  9 10:05:03 2017
From: gbrown at redhat.com (Gary Brown)
Date: Thu, 9 Mar 2017 10:05:03 -0500 (EST)
Subject: [Hawkular-dev] Example github repos for Hawkular
In-Reply-To: <1837553333.139699.1489071002747.JavaMail.zimbra@redhat.com>
References: <1531131452.6587.1489068889615.JavaMail.zimbra@redhat.com>
	<1837553333.139699.1489071002747.JavaMail.zimbra@redhat.com>
Message-ID: <375970879.49714.1489071903044.JavaMail.zimbra@redhat.com>

We already have an examples folder, so have used that approach in the past. However for someone just looking to try out the OpenTracing javaagent with a tracing solution, it seems a big overhead to clone the complete source for the Hawkular APM project, given that it is not actually necessary/built before using the example.

As the example is using Hawkular APM as a ready built service (via docker), it seems better if the example repo was small and independent of the Hawkular APM repo.

Maybe a hawkular-apm-examples repo? with a collection of such examples, and similarly hawkular-services-examples repo?

Regards
Gary

----- Original Message -----
> > I have been working on a github repo [1] for a Spring Boot example, which
> > uses the new OpenTracing Java Agent [2] with Hawkular APM.
> > 
> > Currently this is located in my own github account - but will soon be
> > referenced from the OpenTracing JavaAgent project as an example of how to
> > use the agent with an OpenTracing compliant tracer.
> > 
> > Therefore was wondering if it would be better for this example repo to be
> > located under the Hawkular org?
> 
> 
> 
> You should put it under some kind of "examples" folder in your APM repo.
> 
> I do the same thing with the several HOSA examples:
> 
> https://github.com/hawkular/hawkular-openshift-agent/tree/master/examples
> 
> 
> 
> > 
> > Regards
> > Gary
> > 
> > [1] https://github.com/objectiser/java-agent-spring-boot-example
> > [2] https://github.com/opentracing-contrib/java-agent
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From jpkroehling at redhat.com  Thu Mar  9 10:28:41 2017
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Thu, 9 Mar 2017 16:28:41 +0100
Subject: [Hawkular-dev] Example github repos for Hawkular
In-Reply-To: <375970879.49714.1489071903044.JavaMail.zimbra@redhat.com>
References: <1531131452.6587.1489068889615.JavaMail.zimbra@redhat.com>
	<1837553333.139699.1489071002747.JavaMail.zimbra@redhat.com>
	<375970879.49714.1489071903044.JavaMail.zimbra@redhat.com>
Message-ID: <392ea3b2-76a6-7b7c-fb9f-d315eac18e8c@redhat.com>

On 03/09/2017 04:05 PM, Gary Brown wrote:
> Maybe a hawkular-apm-examples repo?

I see those examples as OpenTracing examples, not APM. Hawkular APM is 
there "just" to supply a dependency (the server), but the showcase is 
around OpenTracing. As such, I'd name it as "opentracing-showcase", or 
"opentracing-examples".

- Juca.

From mazz at redhat.com  Thu Mar  9 15:04:44 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 9 Mar 2017 15:04:44 -0500 (EST)
Subject: [Hawkular-dev] agent running as a VM javaagent -
	non-EAP	based	solution
In-Reply-To: <1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
Message-ID: <1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>

> > I still need to see how well this supports the disabling/enabling of
> > metrics on the fly from the websocket commands (e.g. I will need to add the ability
> > to change the YAML config to persist the settings, that is not done yet -
> > the EAP-based agent got this support for free - its config changes go into
> > standalone.xml).
> 
> Just checked - the cmdgw command to update collection intervals won't work
> because it is assuming the agent is always DMR-accessible which it no longer
> is. This won't be hard to refactor that command to get it to work, but for
> now, this will not work when running as javaagent - still works as normal
> with the subsystem agent.

This is fixed now. Updating collection intervals and enabling/disabling metrics should now work even when deployed at a javaagent.

At this point in time, I'm hard-pressed to think of a feature the WildFly Agent has that the javaagent does not (short of the obvious "there is no CLI" and "there is no installer" - but there is really nothing to install so that's moot). If anyone plays with this (especially with CFME on the front end) let me know what you find.

I'm sure I'm forgetting something, but right now, it looks like it is working really well. I just have to build in itests for it (right now, all the WildFly Agent itests still exist and pass, so I know I didn't break that).

From snegrea at redhat.com  Thu Mar  9 15:34:14 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Thu, 9 Mar 2017 14:34:14 -0600
Subject: [Hawkular-dev] Hawkular Metrics 0.25.0 - Release
Message-ID: <CADt-fV8RL1o2Xk5Z37-3WEUk5nch5krA9Mrzw-Tu-mLT+VV2Dg@mail.gmail.com>

Hello,

I am happy to announce release 0.25.0 of Hawkular Metrics. This release is
anchored by general stability improvements and enhanced query capabilities
for the external metrics alerter.

Here is a list of major changes:

   - *External Metrics Alerter - Enhancements*
      - Both syntax and query capabilities have been revamped to allow
      defining conditions using flexible expressions with embedded stats queries
      - The ExternalCondition expression is now JSON and has support for
      the new tag query language
      - The full documentation about this feature can be found in the Alerting
      section
      <http://www.hawkular.org/hawkular-metrics/docs/user-guide/#_alerting>
      of the user guide
      <http://www.hawkular.org/hawkular-metrics/docs/user-guide/>
      - For more details please see: HWKMETRICS-566
      <https://issues.jboss.org/browse/HWKMETRICS-566> and Pull Request 727
      <https://github.com/hawkular/hawkular-metrics/pull/727>
   - *Dropwizard-Metrics - Merged*
      - The Dropwizard-Metrics reporter
      <https://github.com/hawkular/hawkular-dropwizard-reporter> has been
      merged into the Metrics repository in clients/dropwizard
      <https://github.com/hawkular/hawkular-metrics/tree/44677cc5d6267e738ea51bdd9a37be062ca1b8c2/clients/dropwizard>
      module
      - The old repository
      <https://github.com/hawkular/hawkular-dropwizard-reporter> is
      decommissioned, all new development will happen in the Metrics project
      - This was done to simplify the compatibility matrix between the
      reporter and Hawkular Metrics REST API; going forward they will have
      identical versions. Furthermore, the compatibility is now tested via
      continuous integration tests.
      - Please use the new maven artifact hawkular-dropwizard-reporter
      <http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-dropwizard-reporter/0.25.0.Final/>
      - For more details please see: HWKMETRICS-585
      <https://issues.jboss.org/browse/HWKMETRICS-585>
   - *Tag Query Language - Enhancements*
      - The tag query language now supports the dot character in the tag
      name. The list of allowed characters is *a-zA-Z_0-9.*
      - The query language allows regex matching for tag values but not tag
      names
      - This allows translating JSON-like tag structures into Hawkular
      Metrics tags and query using the new tag query language
      - For example, a tag structure like [tag.subtag1: value1,
      tag.subtag2.subsubtag1: value2] is now queriable via the tag query
      language with queries like tag.subtag1 = value1 or
      tag.subtag2.subsubtag1
      - For more details please see: HWKMETRICS-611
      <https://issues.jboss.org/browse/HWKMETRICS-611>
   - *REST API - Request Logging*
      - It is now possible to enable detailed logging for all REST API
      requests
      - Two properties have been added to enable this features:
      hawkular.metrics.request.logging.level to enable logging for all read
      requests and hawkular.metrics.request.logging.level.writes to enable
      logging for write requests
      - By default this feature is disabled, to enable just set the log
      level via each property
      - For more details please see: HWKMETRICS-589
      <https://issues.jboss.org/browse/HWKMETRICS-589>
      - Here is a sample log:

INFO  [org.hawkular.metrics.api.jaxrs.util.RequestLoggingFilter]
(default task-49)
REST API request:
--------------------------------------
path: /metrics
segments: [metrics]
method: GET
query parameters: {type=[availability]}
Tenant: T9a116f18-28cf-41b3-8ff8-c9752ac60e26232


   - *Other Updates*
      - Automatically fix schema issues that occur when the server is
      restarted during initial schema installation (HWKMETRICS-594
      <https://issues.jboss.org/browse/HWKMETRICS-594>)
      - Metric data points inserts have been optimized to use token ranges
      for Cassandra writes (HWKMETRICS-599
      <https://issues.jboss.org/browse/HWKMETRICS-599>)


*Hawkular Alerting - Included*

   - Version 1.5.3
   <https://issues.jboss.org/projects/HWKALERTS/versions/12333651>
   - Project details and repository: Github
   <https://github.com/hawkular/hawkular-alerts>
   - Documentation: REST API
   <http://www.hawkular.org/docs/rest/rest-alerts.html>, Examples
   <https://github.com/hawkular/hawkular-alerts/tree/master/examples>,
Developer
   Guide
   <http://www.hawkular.org/community/docs/developer-guide/alerts.html>

*Hawkular Metrics Clients*

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


*Release Links*

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

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

Jira release tracker:
https://issues.jboss.org/projects/HWKMETRICS/versions/12333676

A big "Thank you" goes to John Sanda, Matt Wringe, Michael Burman, Joel
Takvorian, Jay Shaughnessy, Lucas Ponce, and Heiko Rupp for their project
contributions.

Thank you,
Stefan Negrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170309/8cbdbc97/attachment-0001.html 

From theute at redhat.com  Thu Mar  9 16:06:24 2017
From: theute at redhat.com (Thomas Heute)
Date: Thu, 9 Mar 2017 22:06:24 +0100
Subject: [Hawkular-dev] Hawkular Metrics 0.25.0 - Release
In-Reply-To: <CADt-fV8RL1o2Xk5Z37-3WEUk5nch5krA9Mrzw-Tu-mLT+VV2Dg@mail.gmail.com>
References: <CADt-fV8RL1o2Xk5Z37-3WEUk5nch5krA9Mrzw-Tu-mLT+VV2Dg@mail.gmail.com>
Message-ID: <CA+aN=Mq12b15EtJYTKkVtWrgXEcWyjH6T=qz0zWhz7GrLOHV7w@mail.gmail.com>

Congratulations!

Le 9 mars 2017 21:34, "Stefan Negrea" <snegrea at redhat.com> a ?crit :

> Hello,
>
> I am happy to announce release 0.25.0 of Hawkular Metrics. This release is
> anchored by general stability improvements and enhanced query capabilities
> for the external metrics alerter.
>
> Here is a list of major changes:
>
>    - *External Metrics Alerter - Enhancements*
>       - Both syntax and query capabilities have been revamped to allow
>       defining conditions using flexible expressions with embedded stats queries
>       - The ExternalCondition expression is now JSON and has support for
>       the new tag query language
>       - The full documentation about this feature can be found in the Alerting
>       section
>       <http://www.hawkular.org/hawkular-metrics/docs/user-guide/#_alerting>
>       of the user guide
>       <http://www.hawkular.org/hawkular-metrics/docs/user-guide/>
>       - For more details please see: HWKMETRICS-566
>       <https://issues.jboss.org/browse/HWKMETRICS-566> and Pull Request
>       727 <https://github.com/hawkular/hawkular-metrics/pull/727>
>    - *Dropwizard-Metrics - Merged*
>       - The Dropwizard-Metrics reporter
>       <https://github.com/hawkular/hawkular-dropwizard-reporter> has been
>       merged into the Metrics repository in clients/dropwizard
>       <https://github.com/hawkular/hawkular-metrics/tree/44677cc5d6267e738ea51bdd9a37be062ca1b8c2/clients/dropwizard>
>       module
>       - The old repository
>       <https://github.com/hawkular/hawkular-dropwizard-reporter> is
>       decommissioned, all new development will happen in the Metrics project
>       - This was done to simplify the compatibility matrix between the
>       reporter and Hawkular Metrics REST API; going forward they will have
>       identical versions. Furthermore, the compatibility is now tested via
>       continuous integration tests.
>       - Please use the new maven artifact hawkular-dropwizard-reporter
>       <http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-dropwizard-reporter/0.25.0.Final/>
>       - For more details please see: HWKMETRICS-585
>       <https://issues.jboss.org/browse/HWKMETRICS-585>
>    - *Tag Query Language - Enhancements*
>       - The tag query language now supports the dot character in the tag
>       name. The list of allowed characters is *a-zA-Z_0-9.*
>       - The query language allows regex matching for tag values but not
>       tag names
>       - This allows translating JSON-like tag structures into Hawkular
>       Metrics tags and query using the new tag query language
>       - For example, a tag structure like [tag.subtag1: value1,
>       tag.subtag2.subsubtag1: value2] is now queriable via the tag query
>       language with queries like tag.subtag1 = value1 or
>       tag.subtag2.subsubtag1
>       - For more details please see: HWKMETRICS-611
>       <https://issues.jboss.org/browse/HWKMETRICS-611>
>    - *REST API - Request Logging*
>       - It is now possible to enable detailed logging for all REST API
>       requests
>       - Two properties have been added to enable this features:
>       hawkular.metrics.request.logging.level to enable logging for all
>       read requests and hawkular.metrics.request.logging.level.writes to
>       enable logging for write requests
>       - By default this feature is disabled, to enable just set the log
>       level via each property
>       - For more details please see: HWKMETRICS-589
>       <https://issues.jboss.org/browse/HWKMETRICS-589>
>       - Here is a sample log:
>
> INFO  [org.hawkular.metrics.api.jaxrs.util.RequestLoggingFilter] (default task-49)
> REST API request:
> --------------------------------------
> path: /metrics
> segments: [metrics]
> method: GET
> query parameters: {type=[availability]}
> Tenant: T9a116f18-28cf-41b3-8ff8-c9752ac60e26232
>
>
>    - *Other Updates*
>       - Automatically fix schema issues that occur when the server is
>       restarted during initial schema installation (HWKMETRICS-594
>       <https://issues.jboss.org/browse/HWKMETRICS-594>)
>       - Metric data points inserts have been optimized to use token
>       ranges for Cassandra writes (HWKMETRICS-599
>       <https://issues.jboss.org/browse/HWKMETRICS-599>)
>
>
> *Hawkular Alerting - Included*
>
>    - Version 1.5.3
>    <https://issues.jboss.org/projects/HWKALERTS/versions/12333651>
>    - Project details and repository: Github
>    <https://github.com/hawkular/hawkular-alerts>
>    - Documentation: REST API
>    <http://www.hawkular.org/docs/rest/rest-alerts.html>, Examples
>    <https://github.com/hawkular/hawkular-alerts/tree/master/examples>, Developer
>    Guide
>    <http://www.hawkular.org/community/docs/developer-guide/alerts.html>
>
> *Hawkular Metrics Clients*
>
>    - Python: https://github.com/hawkular/hawkular-client-python
>    - Go: https://github.com/hawkular/hawkular-client-go
>    - Ruby: https://github.com/hawkular/hawkular-client-ruby
>    - Java: https://github.com/hawkular/hawkular-client-java
>
>
> *Release Links*
>
> Github Release: https://github.com/hawkular/hawkular-metrics/
> releases/tag/0.25.0
>
> JBoss Nexus Maven artifacts:
> http://origin-repository.jboss.org/nexus/content/repositorie
> s/public/org/hawkular/metrics/
>
> Jira release tracker:
> https://issues.jboss.org/projects/HWKMETRICS/versions/12333676
>
> A big "Thank you" goes to John Sanda, Matt Wringe, Michael Burman, Joel
> Takvorian, Jay Shaughnessy, Lucas Ponce, and Heiko Rupp for their project
> contributions.
>
> Thank you,
> Stefan Negrea
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170309/34f368cb/attachment.html 

From tcunning at redhat.com  Thu Mar  9 16:50:19 2017
From: tcunning at redhat.com (Thomas Cunningham)
Date: Thu, 9 Mar 2017 16:50:19 -0500
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
	solution
In-Reply-To: <1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
Message-ID: <CALAW+WKLkATLu0V-0T-7VyqJfV6xmgfUG8PUCb0fr-JDjZfgbw@mail.gmail.com>

I've been testing this out for the past day, and this is fantastic.   I
have it attached to Karaf pushing metrics to Hawkular and it looks like
it's working very well.   I'm trying it on SpringBoot next, but if it works
on Karaf, I'm not sure why it wouldn't work on SpringBoot.

Things I'd like to contribute back possibly if they sound interesting :

- delay (the delay X seconds is useful, but I'd like to have a way of
polling to see if the MBeans are registered yet, and then starting the
agent)
- size of javaagent : it looks like the JAR is about 24MB, I might look
into seeing if there's a way of slimming that down.    For our purposes,
we're only really interested in JMX support, so I'm going to see if I can
build a profile that filters out the DMR stuff and their dependencies for a
smaller fat JAR
- optional log integration with Karaf?




On Thu, Mar 9, 2017 at 3:04 PM, John Mazzitelli <mazz at redhat.com> wrote:

> > > I still need to see how well this supports the disabling/enabling of
> > > metrics on the fly from the websocket commands (e.g. I will need to
> add the ability
> > > to change the YAML config to persist the settings, that is not done
> yet -
> > > the EAP-based agent got this support for free - its config changes go
> into
> > > standalone.xml).
> >
> > Just checked - the cmdgw command to update collection intervals won't
> work
> > because it is assuming the agent is always DMR-accessible which it no
> longer
> > is. This won't be hard to refactor that command to get it to work, but
> for
> > now, this will not work when running as javaagent - still works as normal
> > with the subsystem agent.
>
> This is fixed now. Updating collection intervals and enabling/disabling
> metrics should now work even when deployed at a javaagent.
>
> At this point in time, I'm hard-pressed to think of a feature the WildFly
> Agent has that the javaagent does not (short of the obvious "there is no
> CLI" and "there is no installer" - but there is really nothing to install
> so that's moot). If anyone plays with this (especially with CFME on the
> front end) let me know what you find.
>
> I'm sure I'm forgetting something, but right now, it looks like it is
> working really well. I just have to build in itests for it (right now, all
> the WildFly Agent itests still exist and pass, so I know I didn't break
> that).
> _______________________________________________
> 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/20170309/f1422502/attachment.html 

From mazz at redhat.com  Thu Mar  9 18:41:10 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Thu, 9 Mar 2017 18:41:10 -0500 (EST)
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <CALAW+WKLkATLu0V-0T-7VyqJfV6xmgfUG8PUCb0fr-JDjZfgbw@mail.gmail.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<CALAW+WKLkATLu0V-0T-7VyqJfV6xmgfUG8PUCb0fr-JDjZfgbw@mail.gmail.com>
Message-ID: <337827562.1024350.1489102870724.JavaMail.zimbra@redhat.com>

> - delay (the delay X seconds is useful, but I'd like to have a way of
> polling to see if the MBeans are registered yet, and then starting the
> agent)

This is something on my TODO - I'd like the javaagent to wait until at least one of its managed-servers can be connected to.

From hrupp at redhat.com  Fri Mar 10 04:48:05 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 10 Mar 2017 10:48:05 +0100
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <CALAW+WKLkATLu0V-0T-7VyqJfV6xmgfUG8PUCb0fr-JDjZfgbw@mail.gmail.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<CALAW+WKLkATLu0V-0T-7VyqJfV6xmgfUG8PUCb0fr-JDjZfgbw@mail.gmail.com>
Message-ID: <5D2DB277-BBF0-47D1-947B-080C0EF7DFC1@redhat.com>

On 9 Mar 2017, at 22:50, Thomas Cunningham wrote:

> I've been testing this out for the past day, and this is fantastic.   
> I have it attached to Karaf pushing metrics to Hawkular and it looks 
> like
> it's working very well.   I'm trying it on SpringBoot next,

Awesome

> Things I'd like to contribute back possibly if they sound interesting 
> :

Yes. We need to move quickly, so contributions are very
welcome.

> build a profile that filters out the DMR stuff and their dependencies 
> for a smaller fat JAR

This is certainly a good idea and we should perhaps
even try to see if that would work for WildFly.
But if WildFly needs DMR, then we also need to consider
the creation process of container images, as one
can't just put a Rhel-atomic+Java+Hawkular-javvagent-jmx
image out there and use it with WildFly, so there would
be an need for two images, which complicates
things.

From hrupp at redhat.com  Fri Mar 10 06:43:33 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Fri, 10 Mar 2017 12:43:33 +0100
Subject: [Hawkular-dev] Hawkular Metrics 0.25.0 - Release
In-Reply-To: <CADt-fV8RL1o2Xk5Z37-3WEUk5nch5krA9Mrzw-Tu-mLT+VV2Dg@mail.gmail.com>
References: <CADt-fV8RL1o2Xk5Z37-3WEUk5nch5krA9Mrzw-Tu-mLT+VV2Dg@mail.gmail.com>
Message-ID: <3B60F087-6B62-48E4-8676-CF10C94B29A4@redhat.com>


> I am happy to announce release 0.25.0 of Hawkular Metrics.

Great! Congratulations and thanks to everyone involved in the making!

From miburman at redhat.com  Fri Mar 10 07:35:28 2017
From: miburman at redhat.com (Michael Burman)
Date: Fri, 10 Mar 2017 14:35:28 +0200
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <3412312.S3QrPxfIO6@localhost.localdomain>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
	<3412312.S3QrPxfIO6@localhost.localdomain>
Message-ID: <30160b37-108e-cb90-5d5f-ae770b4800db@redhat.com>

Hi,

This is actually a solved issue if you want to track a single metric's 
history. Remember, metricId has no context information, it could (and it 
should have been so that people don't get confused) a randomly generated 
uuid.

The way you track the container's historic CPU usage is by using the tags:

For example, to get all the datapoints for a single container, you use:

container_name=hawkular-metrics

The podid does not make any difference here, it's just some random 
information. Now, on the other hand, if you want to  compare how the 
hawkular-metrics memory usage has changed between different pod versions 
or pod ids, you can do that also by actually using the tags of pod_id 
and container_version.

Just use pod_id as one sorting method and container_version as one (I 
don't remember the exact names of these tags). Tags are the key to 
sorting and finding the information you want - not the metricId. 
MetricId is something you should completely forget, it's not relevant.

The Kubernetes metrics have tags available that you can use for sorting, 
grouping and finding.

   -  Micke

On 03/09/2017 12:35 PM, Lukas Krejci wrote:
> Isn't the question rather "how do we associate them with the 
> application(s)"?
> Because if we want to track e.g. CPU load generated by an application in a
> container - isn't that something users would want to look at history of? IMHO,
> using the ephemeral "container id" as (part of) metric ids is a wrong thing to
> do, because really the user isn't interested in the container itself, but the
> applications that are running in it and their consumption of container's
> resources.
>
>


From jshaughn at redhat.com  Fri Mar 10 07:57:02 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 10 Mar 2017 07:57:02 -0500
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
Message-ID: <ad56fc03-7874-ea20-f70b-5f82818fb05d@redhat.com>


Try the turing test, replace it in hServices and see what happens.

On 3/9/2017 3:04 PM, John Mazzitelli wrote:
>>> I still need to see how well this supports the disabling/enabling of
>>> metrics on the fly from the websocket commands (e.g. I will need to add the ability
>>> to change the YAML config to persist the settings, that is not done yet -
>>> the EAP-based agent got this support for free - its config changes go into
>>> standalone.xml).
>> Just checked - the cmdgw command to update collection intervals won't work
>> because it is assuming the agent is always DMR-accessible which it no longer
>> is. This won't be hard to refactor that command to get it to work, but for
>> now, this will not work when running as javaagent - still works as normal
>> with the subsystem agent.
> This is fixed now. Updating collection intervals and enabling/disabling metrics should now work even when deployed at a javaagent.
>
> At this point in time, I'm hard-pressed to think of a feature the WildFly Agent has that the javaagent does not (short of the obvious "there is no CLI" and "there is no installer" - but there is really nothing to install so that's moot). If anyone plays with this (especially with CFME on the front end) let me know what you find.
>
> I'm sure I'm forgetting something, but right now, it looks like it is working really well. I just have to build in itests for it (right now, all the WildFly Agent itests still exist and pass, so I know I didn't break that).
> _______________________________________________
> 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/20170310/7476054f/attachment.html 

From mazz at redhat.com  Sat Mar 11 18:09:45 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 11 Mar 2017 18:09:45 -0500 (EST)
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <EB74FBB2-3B64-4FFA-921B-652A42435795@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<EB74FBB2-3B64-4FFA-921B-652A42435795@redhat.com>
Message-ID: <1206376090.3000373.1489273785156.JavaMail.zimbra@redhat.com>

As for the question "Did you try deployments over this?" - I have been writing a bunch of itests. I basically copied the itests we already have and tweeked them to run against the javaagent. So far, so good. All of the tests pass in this PR with virtually no changes to the core engine (they pass on my box, who knows what travis is doing - sometimes they pass, sometimes they don't).

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

I need to create two more sets of tests before I can say it all works the same as the wildfly agent without breakage:

1) domain tests (I've got the standalone tests passing - including deployments - just have to test domain mode)
2) immutability tests (show that the agent won't try to change anything if its immutable)

Tests I'm building are here:

https://github.com/jmazzitelli/hawkular-agent/tree/refactor-core/hawkular-javaagent-itest-parent/hawkular-javaagent-all-itests

NOTE: the agents (both javaagent and wildfly agent) now support invoking JMX operations in both local and remote JMX servers in my branch - the old agent did not have this support.

From theute at redhat.com  Mon Mar 13 03:50:32 2017
From: theute at redhat.com (Thomas Heute)
Date: Mon, 13 Mar 2017 08:50:32 +0100
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
	solution
In-Reply-To: <1206376090.3000373.1489273785156.JavaMail.zimbra@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<EB74FBB2-3B64-4FFA-921B-652A42435795@redhat.com>
	<1206376090.3000373.1489273785156.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MoRtEL6U75W36JA=rHVtY0Yj9-cnC+w+ChGGkiOv07TWw@mail.gmail.com>

Something that just hit me. With this we don't even need an installer
anymore... (we just need to include a doc page for the parameters to pass)

Simplification FTW !

On Sun, Mar 12, 2017 at 12:09 AM, John Mazzitelli <mazz at redhat.com> wrote:

> As for the question "Did you try deployments over this?" - I have been
> writing a bunch of itests. I basically copied the itests we already have
> and tweeked them to run against the javaagent. So far, so good. All of the
> tests pass in this PR with virtually no changes to the core engine (they
> pass on my box, who knows what travis is doing - sometimes they pass,
> sometimes they don't).
>
> https://github.com/hawkular/hawkular-agent/pull/302
>
> I need to create two more sets of tests before I can say it all works the
> same as the wildfly agent without breakage:
>
> 1) domain tests (I've got the standalone tests passing - including
> deployments - just have to test domain mode)
> 2) immutability tests (show that the agent won't try to change anything if
> its immutable)
>
> Tests I'm building are here:
>
> https://github.com/jmazzitelli/hawkular-agent/tree/refactor-core/hawkular-
> javaagent-itest-parent/hawkular-javaagent-all-itests
>
> NOTE: the agents (both javaagent and wildfly agent) now support invoking
> JMX operations in both local and remote JMX servers in my branch - the old
> agent did not have this support.
> _______________________________________________
> 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/20170313/38e964e6/attachment.html 

From hrupp at redhat.com  Mon Mar 13 07:14:33 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Mon, 13 Mar 2017 12:14:33 +0100
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <CA+aN=MoRtEL6U75W36JA=rHVtY0Yj9-cnC+w+ChGGkiOv07TWw@mail.gmail.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<EB74FBB2-3B64-4FFA-921B-652A42435795@redhat.com>
	<1206376090.3000373.1489273785156.JavaMail.zimbra@redhat.com>
	<CA+aN=MoRtEL6U75W36JA=rHVtY0Yj9-cnC+w+ChGGkiOv07TWw@mail.gmail.com>
Message-ID: <02C1FE1E-00AF-4CE9-A252-CDF421915C03@redhat.com>

On 13 Mar 2017, at 8:50, Thomas Heute wrote:

> Something that just hit me. With this we don't even need an installer
> anymore... (we just need to include a doc page for the parameters to pass)

Yes. Not dorking with standalone.xml is a big plus.

> Simplification FTW !

So far we can't remove the installer completely as the
javaagent does not work in domain mode due to some
limitations of WildFly, that should be resolved in WF11.
But at least for the OpenShift use case, this is no issue
anyway.

From mazz at redhat.com  Mon Mar 13 09:00:37 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 13 Mar 2017 09:00:37 -0400 (EDT)
Subject: [Hawkular-dev] agent running as a VM javaagent - non-EAP based
 solution
In-Reply-To: <02C1FE1E-00AF-4CE9-A252-CDF421915C03@redhat.com>
References: <1464871943.5269528.1488992902671.JavaMail.zimbra@redhat.com>
	<1503038921.5317209.1489000172222.JavaMail.zimbra@redhat.com>
	<1890416833.788943.1489089884373.JavaMail.zimbra@redhat.com>
	<EB74FBB2-3B64-4FFA-921B-652A42435795@redhat.com>
	<1206376090.3000373.1489273785156.JavaMail.zimbra@redhat.com>
	<CA+aN=MoRtEL6U75W36JA=rHVtY0Yj9-cnC+w+ChGGkiOv07TWw@mail.gmail.com>
	<02C1FE1E-00AF-4CE9-A252-CDF421915C03@redhat.com>
Message-ID: <491913720.3640161.1489410037581.JavaMail.zimbra@redhat.com>

Right, installer can be gone for standalone case.

Not in host controller case, as Heiko just said. Not because there is something wrong with the design of the javaagent, but rather there is a bug in host controller that stops our agent from being injectable into the host controller (well, you CAN inject it, but the spawned servers all crash :)

Heiko, as the fix is now currently, it will NOT fix our problem in WF 11. See my JIRA comment here:

https://issues.jboss.org/browse/WFCORE-350?focusedCommentId=13376718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13376718

There is a workaround to this that we can implement but it is a drastic measure. We can get this to work IF WE REMOVE ALL JBOSS LOGGING from the agent. That means switch to something like java util logging or slf4j and REMOVE EVERY ONE of our JBoss Logging message codes (that is remove all our MsgLogger classes and all references to their log message methods).

Note: if we can get rid of the installer for both standalone and domain, it means we can get rid of the download war that is in the Hawkular Services server.

----- Original Message -----
> On 13 Mar 2017, at 8:50, Thomas Heute wrote:
> 
> > Something that just hit me. With this we don't even need an installer
> > anymore... (we just need to include a doc page for the parameters to pass)
> 
> Yes. Not dorking with standalone.xml is a big plus.
> 
> > Simplification FTW !
> 
> So far we can't remove the installer completely as the
> javaagent does not work in domain mode due to some
> limitations of WildFly, that should be resolved in WF11.
> But at least for the OpenShift use case, this is no issue
> anyway.
> 

From jtakvori at redhat.com  Mon Mar 13 13:37:49 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Mon, 13 Mar 2017 18:37:49 +0100
Subject: [Hawkular-dev] Inventory storage on metrics
In-Reply-To: <CAJo5TFm3JS=FQk=n_dsYJjY6noA9mQZhs7U6tHiaWdbUbTb2vA@mail.gmail.com>
References: <CAJo5TFn6GG8Puucpwiv3g03J9K4+rMOHeBHdJAr5NgV2vfJdHg@mail.gmail.com>
	<1115823553.3976721.1488824883238.JavaMail.zimbra@redhat.com>
	<CAJo5TFm3JS=FQk=n_dsYJjY6noA9mQZhs7U6tHiaWdbUbTb2vA@mail.gmail.com>
Message-ID: <CAJo5TFmhTuwtPk-_H8=TF=jGh49FEzEYHSToL7pXJGwr4AhHEQ@mail.gmail.com>

For information, the string sizes I have while running the agent's
integration tests is about 32KB uncompressed per metric (2.5KB gzipped), up
to 200KB (gzipped: 6.7KB). However I don't know if those numbers are of any
interest or if they will vary too much from real-world usage.

Joel

On Mon, Mar 6, 2017 at 8:18 PM, Joel Takvorian <jtakvori at redhat.com> wrote:

> I haven't checked that part of the puzzle yet, will do it tomorrow.
> However I hope it is possible to keep the ResourcePath as they are
> currently used. Since we can retrieve the root resource from a canonical
> path of a child resource, it's should be ok to find the desired associated
> string metric.
>
> On Mon, Mar 6, 2017 at 7:28 PM, John Mazzitelli <mazz at redhat.com> wrote:
>
>> This also affects the command-gateway stuff since virtually all of the
>> messages require an Inventory ResourcePath (that is how the MiQ UI targets
>> where it wants the message to go, and how the server knows what agent to
>> pass the message to, and how the agent knows what specific resource to
>> operate on).
>>
>> These ResourcePaths are Hawkular-Inventory resource paths - if resource
>> path formats change, we need to change the way the command-gateway stuff
>> works.
>>
>> I can't speak for the MiQ UI side, but from server/agent sides, it isn't
>> trivial but also not that hard to do these changes. It is just work we need
>> to remember we have to do - work in the MiQ UI, server, and agent.
>>
>> ----- Original Message -----
>> > Quick reminder for those who may not have followed the discussions:
>> this is
>> > about removing the inventory project as it currently stands, and
>> replace it
>> > with Metrics-based (so C*-based) storage, using String metrics and json
>> > blobs.
>> >
>> > So, I've been analyzing the usages of inventory in the wildfly agent
>> and in
>> > manageiq / ruby client.
>> >
>> > As posted on another topic, I started with the following pattern for
>> putting
>> > inventories in string metrics:
>> >
>> > - metrics are named:
>> > inventory.[feedid].[r|rt|mt].[id]
>> >
>> > which means that we would store JSON blobs by resource type, by metric
>> type
>> > and by root resource (all per feed id). Which also means we don't allow
>> > anything outside of a feed.
>> >
>> > This naming pattern seems to be quite easily transposable to the wildfly
>> > agent feeding.
>> >
>> > Things become more complicated when we look at the ruby client /
>> manageIQ. To
>> > help in querying, we can add those tags on every metric:
>> >
>> >
>> >
>> > module: inventory
>> >
>> > feed: [feedid]
>> >
>> > type: [r|rt|mt]
>> >
>> > With this, we can easily query, for instance, all resource types of a
>> given
>> > feed, or all feeds, or child resources at a given path, etc.
>> >
>> > Now, after analysis of the ruby code (and I hope I didn't miss important
>> > stuff), I have two remarks:
>> >
>> > - There is a lot a methods in the ruby client that are not used in
>> manage IQ
>> > (listed below [1]). Of course those methods may have an interest for a
>> > general purpose client, but since we're removing a lot of
>> functionalities in
>> > inventory, I would suggest not to focus on them, and just remove them
>> for
>> > the time being. This is possible, of course, if no other product than
>> > manageIQ consumes then... is it the case?
>> >
>> > - I've found just 1 method in the ruby client that would be badly
>> impacted by
>> > the usage of string metrics as currently defined. And unfortunately it's
>> > also the one that is most called (in number of occurrence in code) by
>> manage
>> > IQ, it's "list_resources_for_type"; With the implementation I described
>> > above, to list all resources of a given type we would have to get all
>> > resource blobs of a feed and search in all of them to check all root &
>> child
>> > resource types. That would probably be terrible for performances.
>> >
>> > A suggestion to this problem, is to tag each root resource with one tag
>> per
>> > resource type, something like: "
>> > rt.MyResourceType=resource1,resource2,resource3 ".
>> > Then, we would still have to load the whole blobs and search resources
>> in
>> > them, but we would exclude from the search all root resources that
>> doesn't
>> > have those types, and we wouldn't have to search extensively in the
>> blobs as
>> > we would know the paths.
>> >
>> > Question to metrics devs about that: can we use any character for
>> tagging, or
>> > is there some limitation?
>> >
>> > Or if you can suggest a better way, I'm all ears :)
>> >
>> > [1] list of methods that seem to be unused from the ruby client:
>> > - list_resources_for_feed
>> > - list_relationships
>> > - list_relationships_for_feed
>> > - get_entity
>> > - list_metrics_for_metric_type
>> > - list_metrics_for_resource_type
>> > - create_feed
>> > - delete_feed
>> > - create_resource_type
>> > - create_resource
>> > - create_resource_under_resource
>> > - create_metric_type
>> > - list_operation_definitions
>> > - list_operation_definitions_for_resource
>> > - create_metric_for_resource
>> > - no_more_events
>> >
>> > Joel
>> >
>> > _______________________________________________
>> > hawkular-dev mailing list
>> > hawkular-dev at lists.jboss.org
>> > https://lists.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/20170313/80d90c25/attachment.html 

From mazz at redhat.com  Mon Mar 13 18:07:53 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 13 Mar 2017 18:07:53 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent ready - itests passing
In-Reply-To: <1171954216.4224863.1489442057192.JavaMail.zimbra@redhat.com>
Message-ID: <2043154900.4243998.1489442873429.JavaMail.zimbra@redhat.com>

OK, I have been feverishly finishing this up. I believe this PR is ready. We now have a java agent that can be used in the place of the agent subsystem.

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

All the unit tests and itests pass - I even have itests running against the javaagent so I can say its working at least as well as the agent as a subsystem. The itests are essentially a copy of the ones we have for the wildfly subsystem agent so I'm exercising the javaagent in the same ways.

Two caveats that I can think of:

1) you can't run javaagent inside host controller directly. You have to run it as a separate process (the javaagent can also run on in its own JVM via "java -jar hawkular-javaagent.jar - it does not HAVE to be attached to some other JVM) and point to the host controller remotely. If you want to run it inside Host Controller, use the Hawkular WildFly Agent as a subsystem (i.e. use it like you do now with the original agent).

2) The "local" DMR mode isn't really local - under the covers it is going through the remote management endpoint so long as the WildFly EAP is configured on the default 127.0.0.1:9990. If it is not, just configure the agent to talk to its local WildFly as if it were a remote-dmr managed server.

To solve 1 we need the host controller to incorporate this enhancement: https://issues.jboss.org/browse/WFCORE-2526

To solve 2 I need to play games with classloading and JBoss Modules - I was given some ideas from some folks. I plan to try something to get that to work.

This javaagent has JMX support. It talks local JMX API if local, and Jolokia REST if remote. It supports cmdgw websocket command ExecuteOperationRequest to invoke JMX operations (itests show this working). So we have full DMR and JMX support.

So this is ready for people to try out for non-EAP based products with JMX as their management interface. Tom Cunningham is testing now. He already spotted a packaging issue with sprintboot which he is figuring out - I'll let him explain if he has the energy :)

I think I can merge this soon, unless someone has reservations.

FWIW: the wildfly agent subsystem support remains intact and as it was. So that didn't change and works like it always has (its itests are still there and passing so I know I didn't break those :).

From loleary at redhat.com  Tue Mar 14 17:29:25 2017
From: loleary at redhat.com (Larry O'Leary)
Date: Tue, 14 Mar 2017 16:29:25 -0500
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <30160b37-108e-cb90-5d5f-ae770b4800db@redhat.com>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
	<3412312.S3QrPxfIO6@localhost.localdomain>
	<30160b37-108e-cb90-5d5f-ae770b4800db@redhat.com>
Message-ID: <CAOPk7XWJUYs5jPMtDZeVCv+Lw0PicCZq7CVTYV7B352U_Ngzow@mail.gmail.com>

If I understand how tags are getting used, I think tags will provide the
ability to keep track of history regardless of whether we are dealing with
a new container or an application which is no longer alive.

However, what is not clear to me is what happens when the old container
goes away. I am assuming that we will no longer be attempting to probe it
or gather data from it?

Ultimately what I, as a user, want to be able to do is change network
configuration or platform or container without changing what defines my
application. For example, if I have a helloworld.war deployed to an EAP
server and am monitoring it, I really don't care about the other stuff. If
it changes, so be it. But my helloworld application should still be
reflected the same.

If the database my helloworld application uses changes, so be it. I still
want to treat the datasource as the same datasource it always was even if
the underlying implementation changes and a new inventory object to
represent it gets created. My expectation is that _helloworld-datasource_
is _datasource-pg94_ and _datasource-pg95_ and _datasource_mysql_ combined.
Even though in reality I started with PostgreSQL 9.4; upgraded to
PostgreSQL 9.5; and decided to migrate to MySQL at some point. In the end,
I want to view the datasource metrics based on the entire life-cycle as
that datasource relates to my helloworld application.

The same could be said for my helloworld application's underlying
application server. Perhaps I have my WAR deployed to EAP 7.1 to start but
later I upgrade to EAP 8. It is still my helloworld application.

In the past I would suggest providing a "linking" capability that would
allow me to identify the EAP 8 instance as a continuation or upgrade of the
specific EAP 7.1 instance. Or the MySQL datasource as a continuation or
upgrade of the PostgreSQL 9.5 datasource and the 9.5 datasource an upgrade
or continuation of the PostgreSQL 9.4 datasource. However, if I understand
how tagging is getting implemented, tags would also accomplish this.

If I have separate objects in inventory, they would just get tagged as
helloworld application. When I view history, I am seeing the milestones
across the various inventory objects that make up what I am referring to as
helloworld application. For example, if I had to spin up a new container
every day for the last 7 days, then perhaps it would be interesting to see
that indicated in the history, but the metric values are considered to be a
single series as they relate to the all 7 containers.

But to take the burden of the user to tag each new container that
represents helloworld, I would hope that we can figure out how to do this
automatically and then allow the user to update/fix tags if they are wrong?

In any event, just my thoughts as this does relate to a very big pain point
with the legacy RHQ and JBoss ON implementation.

--
Larry O'Leary


On Fri, Mar 10, 2017 at 6:35 AM, Michael Burman <miburman at redhat.com> wrote:

> Hi,
>
> This is actually a solved issue if you want to track a single metric's
> history. Remember, metricId has no context information, it could (and it
> should have been so that people don't get confused) a randomly generated
> uuid.
>
> The way you track the container's historic CPU usage is by using the tags:
>
> For example, to get all the datapoints for a single container, you use:
>
> container_name=hawkular-metrics
>
> The podid does not make any difference here, it's just some random
> information. Now, on the other hand, if you want to  compare how the
> hawkular-metrics memory usage has changed between different pod versions
> or pod ids, you can do that also by actually using the tags of pod_id
> and container_version.
>
> Just use pod_id as one sorting method and container_version as one (I
> don't remember the exact names of these tags). Tags are the key to
> sorting and finding the information you want - not the metricId.
> MetricId is something you should completely forget, it's not relevant.
>
> The Kubernetes metrics have tags available that you can use for sorting,
> grouping and finding.
>
>    -  Micke
>
> On 03/09/2017 12:35 PM, Lukas Krejci wrote:
> > Isn't the question rather "how do we associate them with the
> > application(s)"?
> > Because if we want to track e.g. CPU load generated by an application in
> a
> > container - isn't that something users would want to look at history of?
> IMHO,
> > using the ephemeral "container id" as (part of) metric ids is a wrong
> thing to
> > do, because really the user isn't interested in the container itself,
> but the
> > applications that are running in it and their consumption of container's
> > resources.
> >
> >
>
> _______________________________________________
> 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/20170314/6cdab72f/attachment-0001.html 

From miburman at redhat.com  Wed Mar 15 09:11:22 2017
From: miburman at redhat.com (Michael Burman)
Date: Wed, 15 Mar 2017 15:11:22 +0200
Subject: [Hawkular-dev] Garbage collection of outdated Servers/Metrics -
 especially with (orchestrated) containers
In-Reply-To: <CAOPk7XWJUYs5jPMtDZeVCv+Lw0PicCZq7CVTYV7B352U_Ngzow@mail.gmail.com>
References: <C7381DE8-6394-4CDD-938D-FD3DCAB43BB8@redhat.com>
	<3412312.S3QrPxfIO6@localhost.localdomain>
	<30160b37-108e-cb90-5d5f-ae770b4800db@redhat.com>
	<CAOPk7XWJUYs5jPMtDZeVCv+Lw0PicCZq7CVTYV7B352U_Ngzow@mail.gmail.com>
Message-ID: <c2ba1e02-9cc1-afeb-1006-fd828cb5230f@redhat.com>

On 03/14/2017 11:29 PM, Larry O'Leary wrote:
> If I understand how tags are getting used, I think tags will provide 
> the ability to keep track of history regardless of whether
> But to take the burden of the user to tag each new container that 
> represents helloworld, I would hope that we can figure out how to do 
> this automatically and then allow the user to update/fix tags if they 
> are wrong?
>
I think most of your concerns are not our domain anymore, but instead 
how Openshift for example manages it and whether we can store that 
"inventory information". Here's one example of what we've extracted by 
gathering information:

{
   "tags": {
     "resource_id_description": "Identifier(s) specific to a metric",
     "labels": "deployment:router-1,deploymentconfig:router,router:router",
     "nodename": "localhost",
     "resource_id": "/",
     "type": "pod_container",
     "hostname": "localhost",
     "container_base_image": "openshift/origin-haproxy-router:latest",
     "namespace_id": "ef59e1bb-ea0d-11e6-9dc8-a0d3c1f893c0",
     "descriptor_name": "filesystem/usage",
     "pod_name": "router-1-bwvdt",
     "container_name": "router",
     "units": "bytes",
     "host_id": "localhost",
     "group_id": "router/filesystem/usage",
     "pod_namespace": "default",
     "pod_id": "fe42efce-ea0d-11e6-9dc8-a0d3c1f893c0",
     "namespace_name": "default"
   },
   "tenantId": "default",
   "dataRetention": 7,
   "minTimestamp": 1488967200000,
   "type": "gauge",
   "id": "router/fe42efce-ea0d-11e6-9dc8-a0d3c1f893c0/filesystem/usage//",
   "maxTimestamp": 1489581220000
}

If your "helloworld" is always running in the project 
"ef59e1bb-ea0d-11e6-9dc8-a0d3c1f893c0" then there's one search criteria 
that will not change even if you redeploy it or change the EAP to a 
newer version etc.

Next up we can look at descriptor_name (or group_id), that is the metric 
you might want to follow. This one does not change either, so you can 
still keep a track of the newest running instance in this way. labels 
are in Openshift which gives you the information you might seek, such as 
labeling it "application_name = Our ultimate frontend application". Now 
you can track with that name also, regardless of whether the pod changed 
underneath.

So these issues you've noted are mostly due to how you use Openshift. If 
you mark it there so that it can be followed, then our tags allow you to 
follow it. But now it gives you the ability to follow it, even if you 
have multiple pods running concurrently or if you update versions, the 
pod crashes, changes node etc.

But, you can also track all those options also. "Show me the 
filesystem/usage between node1 and node2" or "show me how the previous 
version compared to new version". Or list all the instances running 
physically on node "localhost".

We don't do inventoring for the container environments, but we try to 
gather as much information as possible to allow the end-user to create 
their own groupings without restricting the possibilities. And in 
dynamic environment.

I'm not sure if I answered to your problem definition - as I don't think 
it's in our hands anymore. This comment might not apply to ManageIQ 
environment ;)

Now, once this pod goes down this metricId will not receive new metrics 
(new pod_id will come up and new metricId created). We don't however 
delete this history of old pod_ids and their metric definitions even if 
the datapoints associated with them have expired. Your queries - if done 
with tags - do not change and they do not have to care how many times 
the underlying pod was restarted. Which I think was one of your worries. 
Consider the metricId as internal information of Hawkular-Metrics.

   - Micke

From mazz at redhat.com  Wed Mar 15 13:51:50 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 15 Mar 2017 13:51:50 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent to be merged / released
In-Reply-To: <1523585907.6101890.1489599370812.JavaMail.zimbra@redhat.com>
Message-ID: <685543020.6138896.1489600310791.JavaMail.zimbra@redhat.com>

FYI: I am going to merge the PR that introduces the javaagent and then I will release a new agent from that new master branch.

Just to be clear, here is what will then be supported:

1) The Hawkular WildFly Agent (HWFA) remains as-is. Nothing changes. The agent you've come to love and enjoy doesn't change.

2) There is a new Java Agent (HJA) that you can run in any JVM (including but not limited to EAP-based projects). You do so by passing in a "-javaagent" command line option to your JVM (e.g. java -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar ...yadda...). There are two additional properties you must set in standalone.conf if you want to run it inside an EAP JVM. The README will have the details.

This new HJA is configured with a yaml file that largely mimics all the standalone.xml data that HWFA has. There is no ${x} support in the YAML file right now.

This new HJA can talk to any EAP or WildFly server over the DMR management API. It can do deployments to your EAP/WildFly servers and monitoring of EAP/WildFly subsystems just like HWFA can.

This new HJA can talk to any JMX server just like HWFA can (it will talk to the local MBeanServer or, if remotely monitoring a JMX server, it will talk to it over Jolokia/REST API).

This new HJA can NOT run directly inside of a Host Controller due to https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA externally in its own JVM (e.g. java -jar hawkular-javaagent.jar config=config.yaml) and have its config.yaml point to a remote Host Controller and you'll get the same functionality.

--John Mazz

From mazz at redhat.com  Wed Mar 15 14:10:30 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 15 Mar 2017 14:10:30 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent to be merged / released
In-Reply-To: <685543020.6138896.1489600310791.JavaMail.zimbra@redhat.com>
References: <685543020.6138896.1489600310791.JavaMail.zimbra@redhat.com>
Message-ID: <2084170964.6164045.1489601430416.JavaMail.zimbra@redhat.com>

BTW: there is a third thing that is possible, whether anyone wants to do this or not I dunno, but its there:

You can embed an agent directly in your own Java app via:

java.io.File configFile = new File("my-config.yaml");
new org.hawkular.agent.javaagent.JavaAgentEngine(configFile).startHawkularAgent();

----- Original Message -----
> FYI: I am going to merge the PR that introduces the javaagent and then I will
> release a new agent from that new master branch.
> 
> Just to be clear, here is what will then be supported:
> 
> 1) The Hawkular WildFly Agent (HWFA) remains as-is. Nothing changes. The
> agent you've come to love and enjoy doesn't change.
> 
> 2) There is a new Java Agent (HJA) that you can run in any JVM (including but
> not limited to EAP-based projects). You do so by passing in a "-javaagent"
> command line option to your JVM (e.g. java
> -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar
> ...yadda...). There are two additional properties you must set in
> standalone.conf if you want to run it inside an EAP JVM. The README will
> have the details.
> 
> This new HJA is configured with a yaml file that largely mimics all the
> standalone.xml data that HWFA has. There is no ${x} support in the YAML file
> right now.
> 
> This new HJA can talk to any EAP or WildFly server over the DMR management
> API. It can do deployments to your EAP/WildFly servers and monitoring of
> EAP/WildFly subsystems just like HWFA can.
> 
> This new HJA can talk to any JMX server just like HWFA can (it will talk to
> the local MBeanServer or, if remotely monitoring a JMX server, it will talk
> to it over Jolokia/REST API).
> 
> This new HJA can NOT run directly inside of a Host Controller due to
> https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA
> externally in its own JVM (e.g. java -jar hawkular-javaagent.jar
> config=config.yaml) and have its config.yaml point to a remote Host
> Controller and you'll get the same functionality.
> 
> --John Mazz

From mazz at redhat.com  Wed Mar 15 15:06:06 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 15 Mar 2017 15:06:06 -0400 (EDT)
Subject: [Hawkular-dev] Hawkular Java Agent released - 0.29.0.Final
In-Reply-To: <685543020.6138896.1489600310791.JavaMail.zimbra@redhat.com>
References: <685543020.6138896.1489600310791.JavaMail.zimbra@redhat.com>
Message-ID: <2081214200.6250348.1489604766439.JavaMail.zimbra@redhat.com>

> FYI: I am going to merge the PR that introduces the javaagent and then I will
> release a new agent from that new master branch.

0.29.0.Final released.

[1] is the new Java Agent jar.
[2] is a config you can use to talk to EAP7 / Wildfly10+.
[3] is the small README on how to use it.

Now it is just a matter of people using it to let me know what I broke :)

Thanks,
John Mazz

[1] https://repository.jboss.org/nexus/content/groups/public/org/hawkular/agent/hawkular-javaagent/0.29.0.Final/hawkular-javaagent-0.29.0.Final.jar
[2] https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent/src/test/resources/real-config.yaml
[3] https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent/README.adoc

From mazz at redhat.com  Sat Mar 18 10:22:42 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Sat, 18 Mar 2017 10:22:42 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
Message-ID: <1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>

Just released Hawkular Java Agent 0.29.1.Final that contains a new feature.

To support deploying Java Agent within containers (though this feature isn't restricted to that use-case), you can configure many settings in the Java Agent YAML config with ${x} expressions (similar to how HWFA can be configured in standalone.xml).

It supports getting values from system properties, environment variables, with default values optionally defined. The following expressions are supported - hopefully this is self-explanatory:

${some.system.property}

${some.system.property:a-default-value}

${ENV~SOME_ENV_VAR}

${ENV~SOME_ENV_VAR:a-default-value}

Not all properties support expressions (most don't need them) but properties that define things like hosts, ports, urls, passwords, filepaths, do support expressions.

If I missed any, or if you'd like a property to support expressions that does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/projects/HWKAGENT


From theute at redhat.com  Mon Mar 20 03:56:34 2017
From: theute at redhat.com (Thomas Heute)
Date: Mon, 20 Mar 2017 08:56:34 +0100
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
References: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
	<1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>

Thanks for the update ! And for releasing-early/releasing-often

On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz at redhat.com> wrote:

> Just released Hawkular Java Agent 0.29.1.Final that contains a new feature.
>
> To support deploying Java Agent within containers (though this feature
> isn't restricted to that use-case), you can configure many settings in the
> Java Agent YAML config with ${x} expressions (similar to how HWFA can be
> configured in standalone.xml).
>
> It supports getting values from system properties, environment variables,
> with default values optionally defined. The following expressions are
> supported - hopefully this is self-explanatory:
>
> ${some.system.property}
>
> ${some.system.property:a-default-value}
>
> ${ENV~SOME_ENV_VAR}
>
> ${ENV~SOME_ENV_VAR:a-default-value}
>
> Not all properties support expressions (most don't need them) but
> properties that define things like hosts, ports, urls, passwords,
> filepaths, do support expressions.
>
> If I missed any, or if you'd like a property to support expressions that
> does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/
> projects/HWKAGENT
>
> _______________________________________________
> 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/20170320/beddc233/attachment.html 

From mazz at redhat.com  Mon Mar 20 07:16:42 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 20 Mar 2017 07:16:42 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>
References: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
	<1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
	<CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>
Message-ID: <596470726.9710647.1490008602441.JavaMail.zimbra@redhat.com>

It was pointed out to me (which I forgot) that WildFly itself supports the syntax ${env.X} to denote environment variables.

Now, this Java Agent isn't based on WildFly and these ${x} tokens appear in the yaml file and not the standalone.xml so we technically do no have to be consistent with WildFly syntax, but I wonder if I should switch this anyway to use the ${env.X} syntax just to make it consistent for people that are familiar with WildFly syntax.

Let me know - this would be a trivial change but I would like to make another release quickly if this change is to be made.

--John Mazz

----- Original Message -----
> Thanks for the update ! And for releasing-early/releasing-often
> 
> On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> > Just released Hawkular Java Agent 0.29.1.Final that contains a new feature.
> >
> > To support deploying Java Agent within containers (though this feature
> > isn't restricted to that use-case), you can configure many settings in the
> > Java Agent YAML config with ${x} expressions (similar to how HWFA can be
> > configured in standalone.xml).
> >
> > It supports getting values from system properties, environment variables,
> > with default values optionally defined. The following expressions are
> > supported - hopefully this is self-explanatory:
> >
> > ${some.system.property}
> >
> > ${some.system.property:a-default-value}
> >
> > ${ENV~SOME_ENV_VAR}
> >
> > ${ENV~SOME_ENV_VAR:a-default-value}
> >
> > Not all properties support expressions (most don't need them) but
> > properties that define things like hosts, ports, urls, passwords,
> > filepaths, do support expressions.
> >
> > If I missed any, or if you'd like a property to support expressions that
> > does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/
> > projects/HWKAGENT
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> >
> 

From theute at redhat.com  Mon Mar 20 07:41:10 2017
From: theute at redhat.com (Thomas Heute)
Date: Mon, 20 Mar 2017 12:41:10 +0100
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <596470726.9710647.1490008602441.JavaMail.zimbra@redhat.com>
References: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
	<1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
	<CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>
	<596470726.9710647.1490008602441.JavaMail.zimbra@redhat.com>
Message-ID: <CA+aN=MoUhOdg2RBUP7Q5bt8hxdQtuv6Z-BA8jdymZ+7t7rUkTg@mail.gmail.com>

Consistency helps :)

On Mon, Mar 20, 2017 at 12:16 PM, John Mazzitelli <mazz at redhat.com> wrote:

> It was pointed out to me (which I forgot) that WildFly itself supports the
> syntax ${env.X} to denote environment variables.
>
> Now, this Java Agent isn't based on WildFly and these ${x} tokens appear
> in the yaml file and not the standalone.xml so we technically do no have to
> be consistent with WildFly syntax, but I wonder if I should switch this
> anyway to use the ${env.X} syntax just to make it consistent for people
> that are familiar with WildFly syntax.
>
> Let me know - this would be a trivial change but I would like to make
> another release quickly if this change is to be made.
>
> --John Mazz
>
> ----- Original Message -----
> > Thanks for the update ! And for releasing-early/releasing-often
> >
> > On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz at redhat.com>
> wrote:
> >
> > > Just released Hawkular Java Agent 0.29.1.Final that contains a new
> feature.
> > >
> > > To support deploying Java Agent within containers (though this feature
> > > isn't restricted to that use-case), you can configure many settings in
> the
> > > Java Agent YAML config with ${x} expressions (similar to how HWFA can
> be
> > > configured in standalone.xml).
> > >
> > > It supports getting values from system properties, environment
> variables,
> > > with default values optionally defined. The following expressions are
> > > supported - hopefully this is self-explanatory:
> > >
> > > ${some.system.property}
> > >
> > > ${some.system.property:a-default-value}
> > >
> > > ${ENV~SOME_ENV_VAR}
> > >
> > > ${ENV~SOME_ENV_VAR:a-default-value}
> > >
> > > Not all properties support expressions (most don't need them) but
> > > properties that define things like hosts, ports, urls, passwords,
> > > filepaths, do support expressions.
> > >
> > > If I missed any, or if you'd like a property to support expressions
> that
> > > does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/
> > > projects/HWKAGENT
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.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/20170320/d9202aeb/attachment.html 

From mazz at redhat.com  Mon Mar 20 08:12:08 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 20 Mar 2017 08:12:08 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <CA+aN=MoUhOdg2RBUP7Q5bt8hxdQtuv6Z-BA8jdymZ+7t7rUkTg@mail.gmail.com>
References: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
	<1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
	<CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>
	<596470726.9710647.1490008602441.JavaMail.zimbra@redhat.com>
	<CA+aN=MoUhOdg2RBUP7Q5bt8hxdQtuv6Z-BA8jdymZ+7t7rUkTg@mail.gmail.com>
Message-ID: <1219158672.9729188.1490011928056.JavaMail.zimbra@redhat.com>

OK. I'll make this change now - should have a new release shortly that will use the ${env.X} syntax.

----- Original Message -----
> Consistency helps :)
> 
> On Mon, Mar 20, 2017 at 12:16 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
> > It was pointed out to me (which I forgot) that WildFly itself supports the
> > syntax ${env.X} to denote environment variables.
> >
> > Now, this Java Agent isn't based on WildFly and these ${x} tokens appear
> > in the yaml file and not the standalone.xml so we technically do no have to
> > be consistent with WildFly syntax, but I wonder if I should switch this
> > anyway to use the ${env.X} syntax just to make it consistent for people
> > that are familiar with WildFly syntax.
> >
> > Let me know - this would be a trivial change but I would like to make
> > another release quickly if this change is to be made.
> >
> > --John Mazz
> >
> > ----- Original Message -----
> > > Thanks for the update ! And for releasing-early/releasing-often
> > >
> > > On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz at redhat.com>
> > wrote:
> > >
> > > > Just released Hawkular Java Agent 0.29.1.Final that contains a new
> > feature.
> > > >
> > > > To support deploying Java Agent within containers (though this feature
> > > > isn't restricted to that use-case), you can configure many settings in
> > the
> > > > Java Agent YAML config with ${x} expressions (similar to how HWFA can
> > be
> > > > configured in standalone.xml).
> > > >
> > > > It supports getting values from system properties, environment
> > variables,
> > > > with default values optionally defined. The following expressions are
> > > > supported - hopefully this is self-explanatory:
> > > >
> > > > ${some.system.property}
> > > >
> > > > ${some.system.property:a-default-value}
> > > >
> > > > ${ENV~SOME_ENV_VAR}
> > > >
> > > > ${ENV~SOME_ENV_VAR:a-default-value}
> > > >
> > > > Not all properties support expressions (most don't need them) but
> > > > properties that define things like hosts, ports, urls, passwords,
> > > > filepaths, do support expressions.
> > > >
> > > > If I missed any, or if you'd like a property to support expressions
> > that
> > > > does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/
> > > > projects/HWKAGENT
> > > >
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > >
> > > >
> > > >
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> >
> 

From mazz at redhat.com  Mon Mar 20 08:50:41 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 20 Mar 2017 08:50:41 -0400 (EDT)
Subject: [Hawkular-dev] hawkular java agent now supports ${x} in config
In-Reply-To: <1219158672.9729188.1490011928056.JavaMail.zimbra@redhat.com>
References: <527051509.8866693.1489846636292.JavaMail.zimbra@redhat.com>
	<1201044701.8866787.1489846962176.JavaMail.zimbra@redhat.com>
	<CA+aN=Mp32MdwpuqnXv7p3U-bW-4w1499SSNxCeZuVzHORdQG8w@mail.gmail.com>
	<596470726.9710647.1490008602441.JavaMail.zimbra@redhat.com>
	<CA+aN=MoUhOdg2RBUP7Q5bt8hxdQtuv6Z-BA8jdymZ+7t7rUkTg@mail.gmail.com>
	<1219158672.9729188.1490011928056.JavaMail.zimbra@redhat.com>
Message-ID: <362763270.9746529.1490014241813.JavaMail.zimbra@redhat.com>

OK, 0.29.2.Final uses the ${env.X} syntax.

Just to expand on why I introduced this ${x} feature in the first place. I assume when you install the Java Agent in your Java app (be it WildFly or whatever) when the app is deployed inside OpenShift, things like IP addresses are not going to be known at the time you build your pod definition yaml or the agent's own yaml. So you won't be able to pre-define config settings like that - you'll have to specify them via this ${env.X} (if you want to pass them in as environment variables that you define in the pod) or as system properties (${x}) that you pass to the Java app in your container definition for the pod.

----- Original Message -----
> OK. I'll make this change now - should have a new release shortly that will
> use the ${env.X} syntax.
> 
> ----- Original Message -----
> > Consistency helps :)
> > 
> > On Mon, Mar 20, 2017 at 12:16 PM, John Mazzitelli <mazz at redhat.com> wrote:
> > 
> > > It was pointed out to me (which I forgot) that WildFly itself supports
> > > the
> > > syntax ${env.X} to denote environment variables.
> > >
> > > Now, this Java Agent isn't based on WildFly and these ${x} tokens appear
> > > in the yaml file and not the standalone.xml so we technically do no have
> > > to
> > > be consistent with WildFly syntax, but I wonder if I should switch this
> > > anyway to use the ${env.X} syntax just to make it consistent for people
> > > that are familiar with WildFly syntax.
> > >
> > > Let me know - this would be a trivial change but I would like to make
> > > another release quickly if this change is to be made.
> > >
> > > --John Mazz
> > >
> > > ----- Original Message -----
> > > > Thanks for the update ! And for releasing-early/releasing-often
> > > >
> > > > On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz at redhat.com>
> > > wrote:
> > > >
> > > > > Just released Hawkular Java Agent 0.29.1.Final that contains a new
> > > feature.
> > > > >
> > > > > To support deploying Java Agent within containers (though this
> > > > > feature
> > > > > isn't restricted to that use-case), you can configure many settings
> > > > > in
> > > the
> > > > > Java Agent YAML config with ${x} expressions (similar to how HWFA can
> > > be
> > > > > configured in standalone.xml).
> > > > >
> > > > > It supports getting values from system properties, environment
> > > variables,
> > > > > with default values optionally defined. The following expressions are
> > > > > supported - hopefully this is self-explanatory:
> > > > >
> > > > > ${some.system.property}
> > > > >
> > > > > ${some.system.property:a-default-value}
> > > > >
> > > > > ${ENV~SOME_ENV_VAR}
> > > > >
> > > > > ${ENV~SOME_ENV_VAR:a-default-value}
> > > > >
> > > > > Not all properties support expressions (most don't need them) but
> > > > > properties that define things like hosts, ports, urls, passwords,
> > > > > filepaths, do support expressions.
> > > > >
> > > > > If I missed any, or if you'd like a property to support expressions
> > > that
> > > > > does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/
> > > > > projects/HWKAGENT
> > > > >
> > > > > _______________________________________________
> > > > > hawkular-dev mailing list
> > > > > hawkular-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > >
> > > > >
> > > > >
> > > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > >
> > >
> > 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 

From mazz at redhat.com  Mon Mar 27 11:00:57 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Mon, 27 Mar 2017 11:00:57 -0400 (EDT)
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
Message-ID: <148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>

<tl;dr>

Need ideas on how we are to implement the following two things in the agent:

1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"

2. When a new server is discovered, the agent should send an event to the server about the new server EXCEPT if the server isn't really new at all (see 1. above)

</tl;dr>


===


This post is to open up a discussion on how we want to implement a new features in the agent.

Joel is developing a new "inventory in metrics" feature: https://github.com/hawkular/hawkular-agent/pull/303

This means the agent will be storing inventory directly into Hawkular-Metrics. Because of this, we need to figure out how to get events sent based on things happening in H-Metric's inventory so MiQ can do things with it (like put things in the timeline such as "new server discovered" or "new WAR was deployed").

Jay looked at the code and the only thing that would be "missing" after this move of inventory into metrics is an event triggered when a new server is added to inventory. (When a new deployment is added, or a deployment is removed, the server is looking at command responses and generating events from that - so we don't lose anything by moving inventory into metrics).

By "new server", what we mean is a new resource that has no parent resources (i.e. a "root resource"). This includes standalone WildFly Servers and domain Host Controllers.

Right now, the agent starts with a "clean slate" when it starts up for the first time, or restarts. That means the agent's in-memory inventory graph is completely empty at startup - when discovery is run, the agent's internal inventory graph is filled in. After that, the agent just keeps the inventory graph up to date as it discovers new things coming and old things going away.

We need the agent to know if it already stored its top level servers into H-Metrics inventory and if it did, not to generate any "new server event". But if the agent is brand new, and it never sent any top-level resources to H-Metrics inventory yet, it should now send a "new server" event to the server (the agent never sent events like this before).

So there are two new things (assuming we keep the stuff Joel is doing - that is, we store inventory into H-Metrics):

1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"

2. When a new server is discovered, the agent should send an event (whatever this means - probably a REST API call somewhere) about the new server EXCEPT if the server isn't really new at all (see 1. above)

We need to figure out how to implement 1. and 2. So we are soliciting thoughts on those two subjects.

From jtakvori at redhat.com  Mon Mar 27 12:40:19 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Mon, 27 Mar 2017 18:40:19 +0200
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
Message-ID: <CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>

For point 1., we can probably use some functions I wrote in the integration
tests, see there:
https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java

I assume you can build a canonical path? (The same "canonical path" than in
the existing inventory) If so, the method "getBlueprintFromCP" gives it to
you as an Optional blueprint.

On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com> wrote:

> <tl;dr>
>
> Need ideas on how we are to implement the following two things in the
> agent:
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I
> told you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event to the
> server about the new server EXCEPT if the server isn't really new at all
> (see 1. above)
>
> </tl;dr>
>
>
> ===
>
>
> This post is to open up a discussion on how we want to implement a new
> features in the agent.
>
> Joel is developing a new "inventory in metrics" feature:
> https://github.com/hawkular/hawkular-agent/pull/303
>
> This means the agent will be storing inventory directly into
> Hawkular-Metrics. Because of this, we need to figure out how to get events
> sent based on things happening in H-Metric's inventory so MiQ can do things
> with it (like put things in the timeline such as "new server discovered" or
> "new WAR was deployed").
>
> Jay looked at the code and the only thing that would be "missing" after
> this move of inventory into metrics is an event triggered when a new server
> is added to inventory. (When a new deployment is added, or a deployment is
> removed, the server is looking at command responses and generating events
> from that - so we don't lose anything by moving inventory into metrics).
>
> By "new server", what we mean is a new resource that has no parent
> resources (i.e. a "root resource"). This includes standalone WildFly
> Servers and domain Host Controllers.
>
> Right now, the agent starts with a "clean slate" when it starts up for the
> first time, or restarts. That means the agent's in-memory inventory graph
> is completely empty at startup - when discovery is run, the agent's
> internal inventory graph is filled in. After that, the agent just keeps the
> inventory graph up to date as it discovers new things coming and old things
> going away.
>
> We need the agent to know if it already stored its top level servers into
> H-Metrics inventory and if it did, not to generate any "new server event".
> But if the agent is brand new, and it never sent any top-level resources to
> H-Metrics inventory yet, it should now send a "new server" event to the
> server (the agent never sent events like this before).
>
> So there are two new things (assuming we keep the stuff Joel is doing -
> that is, we store inventory into H-Metrics):
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I
> told you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event
> (whatever this means - probably a REST API call somewhere) about the new
> server EXCEPT if the server isn't really new at all (see 1. above)
>
> We need to figure out how to implement 1. and 2. So we are soliciting
> thoughts on those two subjects.
> _______________________________________________
> 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/20170327/393a5f0b/attachment-0001.html 

From jshaughn at redhat.com  Mon Mar 27 17:02:15 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Mon, 27 Mar 2017 17:02:15 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
Message-ID: <0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>


i was thinking, perhaps it's not even necessary to involve inventory to 
know if the server was reported or not.  We define metrics, like avail, 
for these root types, I think.  At startup if the metric existed perhaps 
you could assume it was already reported, otherwise you could send a 
"new server" event.  Would that approach fly or be easier?

On 3/27/2017 12:40 PM, Joel Takvorian wrote:
> For point 1., we can probably use some functions I wrote in the 
> integration tests, see there: 
> https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java 
>
>
> I assume you can build a canonical path? (The same "canonical path" 
> than in the existing inventory) If so, the method "getBlueprintFromCP" 
> gives it to you as an Optional blueprint.
>
> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com 
> <mailto:mazz at redhat.com>> wrote:
>
>     <tl;dr>
>
>     Need ideas on how we are to implement the following two things in
>     the agent:
>
>     1. At startup, agent needs to ask H-Metrics "what top-level
>     servers have I told you about in an earlier life?"
>
>     2. When a new server is discovered, the agent should send an event
>     to the server about the new server EXCEPT if the server isn't
>     really new at all (see 1. above)
>
>     </tl;dr>
>
>
>     ===
>
>
>     This post is to open up a discussion on how we want to implement a
>     new features in the agent.
>
>     Joel is developing a new "inventory in metrics" feature:
>     https://github.com/hawkular/hawkular-agent/pull/303
>     <https://github.com/hawkular/hawkular-agent/pull/303>
>
>     This means the agent will be storing inventory directly into
>     Hawkular-Metrics. Because of this, we need to figure out how to
>     get events sent based on things happening in H-Metric's inventory
>     so MiQ can do things with it (like put things in the timeline such
>     as "new server discovered" or "new WAR was deployed").
>
>     Jay looked at the code and the only thing that would be "missing"
>     after this move of inventory into metrics is an event triggered
>     when a new server is added to inventory. (When a new deployment is
>     added, or a deployment is removed, the server is looking at
>     command responses and generating events from that - so we don't
>     lose anything by moving inventory into metrics).
>
>     By "new server", what we mean is a new resource that has no parent
>     resources (i.e. a "root resource"). This includes standalone
>     WildFly Servers and domain Host Controllers.
>
>     Right now, the agent starts with a "clean slate" when it starts up
>     for the first time, or restarts. That means the agent's in-memory
>     inventory graph is completely empty at startup - when discovery is
>     run, the agent's internal inventory graph is filled in. After
>     that, the agent just keeps the inventory graph up to date as it
>     discovers new things coming and old things going away.
>
>     We need the agent to know if it already stored its top level
>     servers into H-Metrics inventory and if it did, not to generate
>     any "new server event". But if the agent is brand new, and it
>     never sent any top-level resources to H-Metrics inventory yet, it
>     should now send a "new server" event to the server (the agent
>     never sent events like this before).
>
>     So there are two new things (assuming we keep the stuff Joel is
>     doing - that is, we store inventory into H-Metrics):
>
>     1. At startup, agent needs to ask H-Metrics "what top-level
>     servers have I told you about in an earlier life?"
>
>     2. When a new server is discovered, the agent should send an event
>     (whatever this means - probably a REST API call somewhere) about
>     the new server EXCEPT if the server isn't really new at all (see
>     1. above)
>
>     We need to figure out how to implement 1. and 2. So we are
>     soliciting thoughts on those two subjects.
>     _______________________________________________
>     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/20170327/8b14e6c5/attachment.html 

From jsanda at redhat.com  Mon Mar 27 23:36:51 2017
From: jsanda at redhat.com (John Sanda)
Date: Mon, 27 Mar 2017 23:36:51 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
Message-ID: <BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>

My first thought was a string metric where data points are the servers that get discovered. There are a couple things though that I do not like about this. First, all data point queries in hawkular-metrics have a date range. Having to use a date range here seems a bit awkward. Secondly all data points in hawkular-metrics expire. These does not seem like data that we would want to expire.

> On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
> 
> 
> i was thinking, perhaps it's not even necessary to involve inventory to know if the server was reported or not.  We define metrics, like avail, for these root types, I think.  At startup if the metric existed perhaps you could assume it was already reported, otherwise you could send a "new server" event.  Would that approach fly or be easier?
> 
> On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>> For point 1., we can probably use some functions I wrote in the integration tests, see there: https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
>> 
>> I assume you can build a canonical path? (The same "canonical path" than in the existing inventory) If so, the method "getBlueprintFromCP" gives it to you as an Optional blueprint.
>> 
>> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>> <tl;dr>
>> 
>> Need ideas on how we are to implement the following two things in the agent:
>> 
>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"
>> 
>> 2. When a new server is discovered, the agent should send an event to the server about the new server EXCEPT if the server isn't really new at all (see 1. above)
>> 
>> </tl;dr>
>> 
>> 
>> ===
>> 
>> 
>> This post is to open up a discussion on how we want to implement a new features in the agent.
>> 
>> Joel is developing a new "inventory in metrics" feature: https://github.com/hawkular/hawkular-agent/pull/303 <https://github.com/hawkular/hawkular-agent/pull/303>
>> 
>> This means the agent will be storing inventory directly into Hawkular-Metrics. Because of this, we need to figure out how to get events sent based on things happening in H-Metric's inventory so MiQ can do things with it (like put things in the timeline such as "new server discovered" or "new WAR was deployed").
>> 
>> Jay looked at the code and the only thing that would be "missing" after this move of inventory into metrics is an event triggered when a new server is added to inventory. (When a new deployment is added, or a deployment is removed, the server is looking at command responses and generating events from that - so we don't lose anything by moving inventory into metrics).
>> 
>> By "new server", what we mean is a new resource that has no parent resources (i.e. a "root resource"). This includes standalone WildFly Servers and domain Host Controllers.
>> 
>> Right now, the agent starts with a "clean slate" when it starts up for the first time, or restarts. That means the agent's in-memory inventory graph is completely empty at startup - when discovery is run, the agent's internal inventory graph is filled in. After that, the agent just keeps the inventory graph up to date as it discovers new things coming and old things going away.
>> 
>> We need the agent to know if it already stored its top level servers into H-Metrics inventory and if it did, not to generate any "new server event". But if the agent is brand new, and it never sent any top-level resources to H-Metrics inventory yet, it should now send a "new server" event to the server (the agent never sent events like this before).
>> 
>> So there are two new things (assuming we keep the stuff Joel is doing - that is, we store inventory into H-Metrics):
>> 
>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"
>> 
>> 2. When a new server is discovered, the agent should send an event (whatever this means - probably a REST API call somewhere) about the new server EXCEPT if the server isn't really new at all (see 1. above)
>> 
>> We need to figure out how to implement 1. and 2. So we are soliciting thoughts on those two subjects.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>> 
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> 
> _______________________________________________
> 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/20170327/55bd760c/attachment-0001.html 

From jtakvori at redhat.com  Tue Mar 28 04:36:23 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Tue, 28 Mar 2017 10:36:23 +0200
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
Message-ID: <CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>

It could be interesting to have the possibility to deactivate TTL (for
instance by setting a negative value, without any change in the existing
API for that) but for the time being we could have the workaround of
setting an arbitrary high value, no?

Concerning the time range, at some point I was using "fromEarliest: true",
" order: desc" and "limit:1" ... It seems that it could also be used here.

Joel


Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com> a ?crit :

My first thought was a string metric where data points are the servers that
get discovered. There are a couple things though that I do not like about
this. First, all data point queries in hawkular-metrics have a date range.
Having to use a date range here seems a bit awkward. Secondly all data
points in hawkular-metrics expire. These does not seem like data that we
would want to expire.

On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com> wrote:


i was thinking, perhaps it's not even necessary to involve inventory to
know if the server was reported or not.  We define metrics, like avail, for
these root types, I think.  At startup if the metric existed perhaps you
could assume it was already reported, otherwise you could send a "new
server" event.  Would that approach fly or be easier?

On 3/27/2017 12:40 PM, Joel Takvorian wrote:

For point 1., we can probably use some functions I wrote in the integration
tests, see there: https://github.com/jotak/hawkular-agent/blob/
inventory-strings/hawkular-agent-itest-util/src/main/
java/org/hawkular/agent/itest/util/ITestHelper.java

I assume you can build a canonical path? (The same "canonical path" than in
the existing inventory) If so, the method "getBlueprintFromCP" gives it to
you as an Optional blueprint.

On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com> wrote:

> <tl;dr>
>
> Need ideas on how we are to implement the following two things in the
> agent:
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I
> told you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event to the
> server about the new server EXCEPT if the server isn't really new at all
> (see 1. above)
>
> </tl;dr>
>
>
> ===
>
>
> This post is to open up a discussion on how we want to implement a new
> features in the agent.
>
> Joel is developing a new "inventory in metrics" feature:
> https://github.com/hawkular/hawkular-agent/pull/303
>
> This means the agent will be storing inventory directly into
> Hawkular-Metrics. Because of this, we need to figure out how to get events
> sent based on things happening in H-Metric's inventory so MiQ can do things
> with it (like put things in the timeline such as "new server discovered" or
> "new WAR was deployed").
>
> Jay looked at the code and the only thing that would be "missing" after
> this move of inventory into metrics is an event triggered when a new server
> is added to inventory. (When a new deployment is added, or a deployment is
> removed, the server is looking at command responses and generating events
> from that - so we don't lose anything by moving inventory into metrics).
>
> By "new server", what we mean is a new resource that has no parent
> resources (i.e. a "root resource"). This includes standalone WildFly
> Servers and domain Host Controllers.
>
> Right now, the agent starts with a "clean slate" when it starts up for the
> first time, or restarts. That means the agent's in-memory inventory graph
> is completely empty at startup - when discovery is run, the agent's
> internal inventory graph is filled in. After that, the agent just keeps the
> inventory graph up to date as it discovers new things coming and old things
> going away.
>
> We need the agent to know if it already stored its top level servers into
> H-Metrics inventory and if it did, not to generate any "new server event".
> But if the agent is brand new, and it never sent any top-level resources to
> H-Metrics inventory yet, it should now send a "new server" event to the
> server (the agent never sent events like this before).
>
> So there are two new things (assuming we keep the stuff Joel is doing -
> that is, we store inventory into H-Metrics):
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I
> told you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event
> (whatever this means - probably a REST API call somewhere) about the new
> server EXCEPT if the server isn't really new at all (see 1. above)
>
> We need to figure out how to implement 1. and 2. So we are soliciting
> thoughts on those two subjects.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>



_______________________________________________
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/20170328/cbbd2424/attachment.html 

From miburman at redhat.com  Tue Mar 28 06:10:02 2017
From: miburman at redhat.com (Michael Burman)
Date: Tue, 28 Mar 2017 13:10:02 +0300
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
	<CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
Message-ID: <42151499-4f9e-087e-240c-2917457fbf81@redhat.com>

Hi,

If you use TTL -1 in current Hawkular-Metrics, we will write without 
setting TTL information. At that point the table TTL will be used (if 
such is set).

   -  Micke


On 03/28/2017 11:36 AM, Joel Takvorian wrote:
> It could be interesting to have the possibility to deactivate TTL (for 
> instance by setting a negative value, without any change in the 
> existing API for that) but for the time being we could have the 
> workaround of setting an arbitrary high value, no?
>
> Concerning the time range, at some point I was using "fromEarliest: 
> true", " order: desc" and "limit:1" ... It seems that it could also be 
> used here.
>
> Joel
>
>
> Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com 
> <mailto:jsanda at redhat.com>> a ?crit :
>
>     My first thought was a string metric where data points are the
>     servers that get discovered. There are a couple things though that
>     I do not like about this. First, all data point queries in
>     hawkular-metrics have a date range. Having to use a date range
>     here seems a bit awkward. Secondly all data points in
>     hawkular-metrics expire. These does not seem like data that we
>     would want to expire.
>
>>     On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com
>>     <mailto:jshaughn at redhat.com>> wrote:
>>
>>
>>     i was thinking, perhaps it's not even necessary to involve
>>     inventory to know if the server was reported or not.  We define
>>     metrics, like avail, for these root types, I think.  At startup
>>     if the metric existed perhaps you could assume it was already
>>     reported, otherwise you could send a "new server" event.  Would
>>     that approach fly or be easier?
>>
>>     On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>>>     For point 1., we can probably use some functions I wrote in the
>>>     integration tests, see there:
>>>     https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java
>>>     <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
>>>
>>>
>>>     I assume you can build a canonical path? (The same "canonical
>>>     path" than in the existing inventory) If so, the method
>>>     "getBlueprintFromCP" gives it to you as an Optional blueprint.
>>>
>>>     On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli
>>>     <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>>>
>>>         <tl;dr>
>>>
>>>         Need ideas on how we are to implement the following two
>>>         things in the agent:
>>>
>>>         1. At startup, agent needs to ask H-Metrics "what top-level
>>>         servers have I told you about in an earlier life?"
>>>
>>>         2. When a new server is discovered, the agent should send an
>>>         event to the server about the new server EXCEPT if the
>>>         server isn't really new at all (see 1. above)
>>>
>>>         </tl;dr>
>>>
>>>
>>>         ===
>>>
>>>
>>>         This post is to open up a discussion on how we want to
>>>         implement a new features in the agent.
>>>
>>>         Joel is developing a new "inventory in metrics" feature:
>>>         https://github.com/hawkular/hawkular-agent/pull/303
>>>         <https://github.com/hawkular/hawkular-agent/pull/303>
>>>
>>>         This means the agent will be storing inventory directly into
>>>         Hawkular-Metrics. Because of this, we need to figure out how
>>>         to get events sent based on things happening in H-Metric's
>>>         inventory so MiQ can do things with it (like put things in
>>>         the timeline such as "new server discovered" or "new WAR was
>>>         deployed").
>>>
>>>         Jay looked at the code and the only thing that would be
>>>         "missing" after this move of inventory into metrics is an
>>>         event triggered when a new server is added to inventory.
>>>         (When a new deployment is added, or a deployment is removed,
>>>         the server is looking at command responses and generating
>>>         events from that - so we don't lose anything by moving
>>>         inventory into metrics).
>>>
>>>         By "new server", what we mean is a new resource that has no
>>>         parent resources (i.e. a "root resource"). This includes
>>>         standalone WildFly Servers and domain Host Controllers.
>>>
>>>         Right now, the agent starts with a "clean slate" when it
>>>         starts up for the first time, or restarts. That means the
>>>         agent's in-memory inventory graph is completely empty at
>>>         startup - when discovery is run, the agent's internal
>>>         inventory graph is filled in. After that, the agent just
>>>         keeps the inventory graph up to date as it discovers new
>>>         things coming and old things going away.
>>>
>>>         We need the agent to know if it already stored its top level
>>>         servers into H-Metrics inventory and if it did, not to
>>>         generate any "new server event". But if the agent is brand
>>>         new, and it never sent any top-level resources to H-Metrics
>>>         inventory yet, it should now send a "new server" event to
>>>         the server (the agent never sent events like this before).
>>>
>>>         So there are two new things (assuming we keep the stuff Joel
>>>         is doing - that is, we store inventory into H-Metrics):
>>>
>>>         1. At startup, agent needs to ask H-Metrics "what top-level
>>>         servers have I told you about in an earlier life?"
>>>
>>>         2. When a new server is discovered, the agent should send an
>>>         event (whatever this means - probably a REST API call
>>>         somewhere) about the new server EXCEPT if the server isn't
>>>         really new at all (see 1. above)
>>>
>>>         We need to figure out how to implement 1. and 2. So we are
>>>         soliciting thoughts on those two subjects.
>>>         _______________________________________________
>>>         hawkular-dev mailing list
>>>         hawkular-dev at lists.jboss.org
>>>         <mailto:hawkular-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>         <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     hawkular-dev mailing list
>>>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>     _______________________________________________ hawkular-dev
>>     mailing list hawkular-dev at lists.jboss.org
>>     <mailto:hawkular-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev> 
>     _______________________________________________ hawkular-dev
>     mailing list hawkular-dev at lists.jboss.org
>     <mailto:hawkular-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev> 
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

From mazz at redhat.com  Tue Mar 28 08:34:55 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Tue, 28 Mar 2017 08:34:55 -0400 (EDT)
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <42151499-4f9e-087e-240c-2917457fbf81@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
	<CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
	<42151499-4f9e-087e-240c-2917457fbf81@redhat.com>
Message-ID: <1264438023.15798815.1490704495074.JavaMail.zimbra@redhat.com>

how about make a value -2 meaning "no TTL at all - ignore even the table TTL"

----- Original Message -----
> Hi,
> 
> If you use TTL -1 in current Hawkular-Metrics, we will write without
> setting TTL information. At that point the table TTL will be used (if
> such is set).
> 
>    -  Micke
> 
> 
> On 03/28/2017 11:36 AM, Joel Takvorian wrote:
> > It could be interesting to have the possibility to deactivate TTL (for
> > instance by setting a negative value, without any change in the
> > existing API for that) but for the time being we could have the
> > workaround of setting an arbitrary high value, no?
> >
> > Concerning the time range, at some point I was using "fromEarliest:
> > true", " order: desc" and "limit:1" ... It seems that it could also be
> > used here.
> >
> > Joel
> >
> >
> > Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
> > <mailto:jsanda at redhat.com>> a ?crit :
> >
> >     My first thought was a string metric where data points are the
> >     servers that get discovered. There are a couple things though that
> >     I do not like about this. First, all data point queries in
> >     hawkular-metrics have a date range. Having to use a date range
> >     here seems a bit awkward. Secondly all data points in
> >     hawkular-metrics expire. These does not seem like data that we
> >     would want to expire.
> >
> >>     On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com
> >>     <mailto:jshaughn at redhat.com>> wrote:
> >>
> >>
> >>     i was thinking, perhaps it's not even necessary to involve
> >>     inventory to know if the server was reported or not.  We define
> >>     metrics, like avail, for these root types, I think.  At startup
> >>     if the metric existed perhaps you could assume it was already
> >>     reported, otherwise you could send a "new server" event.  Would
> >>     that approach fly or be easier?
> >>
> >>     On 3/27/2017 12:40 PM, Joel Takvorian wrote:
> >>>     For point 1., we can probably use some functions I wrote in the
> >>>     integration tests, see there:
> >>>     https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java
> >>>     <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
> >>>
> >>>
> >>>     I assume you can build a canonical path? (The same "canonical
> >>>     path" than in the existing inventory) If so, the method
> >>>     "getBlueprintFromCP" gives it to you as an Optional blueprint.
> >>>
> >>>     On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli
> >>>     <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
> >>>
> >>>         <tl;dr>
> >>>
> >>>         Need ideas on how we are to implement the following two
> >>>         things in the agent:
> >>>
> >>>         1. At startup, agent needs to ask H-Metrics "what top-level
> >>>         servers have I told you about in an earlier life?"
> >>>
> >>>         2. When a new server is discovered, the agent should send an
> >>>         event to the server about the new server EXCEPT if the
> >>>         server isn't really new at all (see 1. above)
> >>>
> >>>         </tl;dr>
> >>>
> >>>
> >>>         ===
> >>>
> >>>
> >>>         This post is to open up a discussion on how we want to
> >>>         implement a new features in the agent.
> >>>
> >>>         Joel is developing a new "inventory in metrics" feature:
> >>>         https://github.com/hawkular/hawkular-agent/pull/303
> >>>         <https://github.com/hawkular/hawkular-agent/pull/303>
> >>>
> >>>         This means the agent will be storing inventory directly into
> >>>         Hawkular-Metrics. Because of this, we need to figure out how
> >>>         to get events sent based on things happening in H-Metric's
> >>>         inventory so MiQ can do things with it (like put things in
> >>>         the timeline such as "new server discovered" or "new WAR was
> >>>         deployed").
> >>>
> >>>         Jay looked at the code and the only thing that would be
> >>>         "missing" after this move of inventory into metrics is an
> >>>         event triggered when a new server is added to inventory.
> >>>         (When a new deployment is added, or a deployment is removed,
> >>>         the server is looking at command responses and generating
> >>>         events from that - so we don't lose anything by moving
> >>>         inventory into metrics).
> >>>
> >>>         By "new server", what we mean is a new resource that has no
> >>>         parent resources (i.e. a "root resource"). This includes
> >>>         standalone WildFly Servers and domain Host Controllers.
> >>>
> >>>         Right now, the agent starts with a "clean slate" when it
> >>>         starts up for the first time, or restarts. That means the
> >>>         agent's in-memory inventory graph is completely empty at
> >>>         startup - when discovery is run, the agent's internal
> >>>         inventory graph is filled in. After that, the agent just
> >>>         keeps the inventory graph up to date as it discovers new
> >>>         things coming and old things going away.
> >>>
> >>>         We need the agent to know if it already stored its top level
> >>>         servers into H-Metrics inventory and if it did, not to
> >>>         generate any "new server event". But if the agent is brand
> >>>         new, and it never sent any top-level resources to H-Metrics
> >>>         inventory yet, it should now send a "new server" event to
> >>>         the server (the agent never sent events like this before).
> >>>
> >>>         So there are two new things (assuming we keep the stuff Joel
> >>>         is doing - that is, we store inventory into H-Metrics):
> >>>
> >>>         1. At startup, agent needs to ask H-Metrics "what top-level
> >>>         servers have I told you about in an earlier life?"
> >>>
> >>>         2. When a new server is discovered, the agent should send an
> >>>         event (whatever this means - probably a REST API call
> >>>         somewhere) about the new server EXCEPT if the server isn't
> >>>         really new at all (see 1. above)
> >>>
> >>>         We need to figure out how to implement 1. and 2. So we are
> >>>         soliciting thoughts on those two subjects.
> >>>         _______________________________________________
> >>>         hawkular-dev mailing list
> >>>         hawkular-dev at lists.jboss.org
> >>>         <mailto:hawkular-dev at lists.jboss.org>
> >>>         https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>         <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>>
> >>>
> >>>
> >>>
> >>>     _______________________________________________
> >>>     hawkular-dev mailing list
> >>>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> >>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>     _______________________________________________ hawkular-dev
> >>     mailing list hawkular-dev at lists.jboss.org
> >>     <mailto:hawkular-dev at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >     _______________________________________________ hawkular-dev
> >     mailing list hawkular-dev at lists.jboss.org
> >     <mailto:hawkular-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


From miburman at redhat.com  Tue Mar 28 09:04:27 2017
From: miburman at redhat.com (Michael Burman)
Date: Tue, 28 Mar 2017 16:04:27 +0300
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <1264438023.15798815.1490704495074.JavaMail.zimbra@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
	<CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
	<42151499-4f9e-087e-240c-2917457fbf81@redhat.com>
	<1264438023.15798815.1490704495074.JavaMail.zimbra@redhat.com>
Message-ID: <0338587e-47df-4a90-b8f6-6ac2eeb02900@redhat.com>

I don't think Cassandra supports that. If there's a table TTL, one needs 
to set a TTL to override the default expiry.

   - Micke


On 03/28/2017 03:34 PM, John Mazzitelli wrote:
> how about make a value -2 meaning "no TTL at all - ignore even the table TTL"
>
> ----- Original Message -----
>> Hi,
>>
>> If you use TTL -1 in current Hawkular-Metrics, we will write without
>> setting TTL information. At that point the table TTL will be used (if
>> such is set).
>>
>>     -  Micke
>>
>>
>> On 03/28/2017 11:36 AM, Joel Takvorian wrote:
>>> It could be interesting to have the possibility to deactivate TTL (for
>>> instance by setting a negative value, without any change in the
>>> existing API for that) but for the time being we could have the
>>> workaround of setting an arbitrary high value, no?
>>>
>>> Concerning the time range, at some point I was using "fromEarliest:
>>> true", " order: desc" and "limit:1" ... It seems that it could also be
>>> used here.
>>>
>>> Joel
>>>
>>>
>>> Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
>>> <mailto:jsanda at redhat.com>> a ?crit :
>>>
>>>      My first thought was a string metric where data points are the
>>>      servers that get discovered. There are a couple things though that
>>>      I do not like about this. First, all data point queries in
>>>      hawkular-metrics have a date range. Having to use a date range
>>>      here seems a bit awkward. Secondly all data points in
>>>      hawkular-metrics expire. These does not seem like data that we
>>>      would want to expire.
>>>
>>>>      On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com
>>>>      <mailto:jshaughn at redhat.com>> wrote:
>>>>
>>>>
>>>>      i was thinking, perhaps it's not even necessary to involve
>>>>      inventory to know if the server was reported or not.  We define
>>>>      metrics, like avail, for these root types, I think.  At startup
>>>>      if the metric existed perhaps you could assume it was already
>>>>      reported, otherwise you could send a "new server" event.  Would
>>>>      that approach fly or be easier?
>>>>
>>>>      On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>>>>>      For point 1., we can probably use some functions I wrote in the
>>>>>      integration tests, see there:
>>>>>      https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java
>>>>>      <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
>>>>>
>>>>>
>>>>>      I assume you can build a canonical path? (The same "canonical
>>>>>      path" than in the existing inventory) If so, the method
>>>>>      "getBlueprintFromCP" gives it to you as an Optional blueprint.
>>>>>
>>>>>      On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli
>>>>>      <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>>>>>
>>>>>          <tl;dr>
>>>>>
>>>>>          Need ideas on how we are to implement the following two
>>>>>          things in the agent:
>>>>>
>>>>>          1. At startup, agent needs to ask H-Metrics "what top-level
>>>>>          servers have I told you about in an earlier life?"
>>>>>
>>>>>          2. When a new server is discovered, the agent should send an
>>>>>          event to the server about the new server EXCEPT if the
>>>>>          server isn't really new at all (see 1. above)
>>>>>
>>>>>          </tl;dr>
>>>>>
>>>>>
>>>>>          ===
>>>>>
>>>>>
>>>>>          This post is to open up a discussion on how we want to
>>>>>          implement a new features in the agent.
>>>>>
>>>>>          Joel is developing a new "inventory in metrics" feature:
>>>>>          https://github.com/hawkular/hawkular-agent/pull/303
>>>>>          <https://github.com/hawkular/hawkular-agent/pull/303>
>>>>>
>>>>>          This means the agent will be storing inventory directly into
>>>>>          Hawkular-Metrics. Because of this, we need to figure out how
>>>>>          to get events sent based on things happening in H-Metric's
>>>>>          inventory so MiQ can do things with it (like put things in
>>>>>          the timeline such as "new server discovered" or "new WAR was
>>>>>          deployed").
>>>>>
>>>>>          Jay looked at the code and the only thing that would be
>>>>>          "missing" after this move of inventory into metrics is an
>>>>>          event triggered when a new server is added to inventory.
>>>>>          (When a new deployment is added, or a deployment is removed,
>>>>>          the server is looking at command responses and generating
>>>>>          events from that - so we don't lose anything by moving
>>>>>          inventory into metrics).
>>>>>
>>>>>          By "new server", what we mean is a new resource that has no
>>>>>          parent resources (i.e. a "root resource"). This includes
>>>>>          standalone WildFly Servers and domain Host Controllers.
>>>>>
>>>>>          Right now, the agent starts with a "clean slate" when it
>>>>>          starts up for the first time, or restarts. That means the
>>>>>          agent's in-memory inventory graph is completely empty at
>>>>>          startup - when discovery is run, the agent's internal
>>>>>          inventory graph is filled in. After that, the agent just
>>>>>          keeps the inventory graph up to date as it discovers new
>>>>>          things coming and old things going away.
>>>>>
>>>>>          We need the agent to know if it already stored its top level
>>>>>          servers into H-Metrics inventory and if it did, not to
>>>>>          generate any "new server event". But if the agent is brand
>>>>>          new, and it never sent any top-level resources to H-Metrics
>>>>>          inventory yet, it should now send a "new server" event to
>>>>>          the server (the agent never sent events like this before).
>>>>>
>>>>>          So there are two new things (assuming we keep the stuff Joel
>>>>>          is doing - that is, we store inventory into H-Metrics):
>>>>>
>>>>>          1. At startup, agent needs to ask H-Metrics "what top-level
>>>>>          servers have I told you about in an earlier life?"
>>>>>
>>>>>          2. When a new server is discovered, the agent should send an
>>>>>          event (whatever this means - probably a REST API call
>>>>>          somewhere) about the new server EXCEPT if the server isn't
>>>>>          really new at all (see 1. above)
>>>>>
>>>>>          We need to figure out how to implement 1. and 2. So we are
>>>>>          soliciting thoughts on those two subjects.
>>>>>          _______________________________________________
>>>>>          hawkular-dev mailing list
>>>>>          hawkular-dev at lists.jboss.org
>>>>>          <mailto:hawkular-dev at lists.jboss.org>
>>>>>          https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>          <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      _______________________________________________
>>>>>      hawkular-dev mailing list
>>>>>      hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>>      _______________________________________________ hawkular-dev
>>>>      mailing list hawkular-dev at lists.jboss.org
>>>>      <mailto:hawkular-dev at lists.jboss.org>
>>>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>      _______________________________________________ hawkular-dev
>>>      mailing list hawkular-dev at lists.jboss.org
>>>      <mailto:hawkular-dev at lists.jboss.org>
>>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev


From jsanda at redhat.com  Tue Mar 28 09:19:58 2017
From: jsanda at redhat.com (John Sanda)
Date: Tue, 28 Mar 2017 09:19:58 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <0338587e-47df-4a90-b8f6-6ac2eeb02900@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
	<CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
	<42151499-4f9e-087e-240c-2917457fbf81@redhat.com>
	<1264438023.15798815.1490704495074.JavaMail.zimbra@redhat.com>
	<0338587e-47df-4a90-b8f6-6ac2eeb02900@redhat.com>
Message-ID: <6DD079EE-9D57-4E54-809D-D0A61A092D60@redhat.com>

On Mar 28, 2017, at 9:04 AM, Michael Burman <miburman at redhat.com> wrote:
> 
> I don't think Cassandra supports that. If there's a table TTL, one needs 
> to set a TTL to override the default expiry.

Correct. I think different table that uses deletes might be a better option.

> 
>   - Micke
> 
> 
> On 03/28/2017 03:34 PM, John Mazzitelli wrote:
>> how about make a value -2 meaning "no TTL at all - ignore even the table TTL"
>> 
>> ----- Original Message -----
>>> Hi,
>>> 
>>> If you use TTL -1 in current Hawkular-Metrics, we will write without
>>> setting TTL information. At that point the table TTL will be used (if
>>> such is set).
>>> 
>>>    -  Micke
>>> 
>>> 
>>> On 03/28/2017 11:36 AM, Joel Takvorian wrote:
>>>> It could be interesting to have the possibility to deactivate TTL (for
>>>> instance by setting a negative value, without any change in the
>>>> existing API for that) but for the time being we could have the
>>>> workaround of setting an arbitrary high value, no?
>>>> 
>>>> Concerning the time range, at some point I was using "fromEarliest:
>>>> true", " order: desc" and "limit:1" ... It seems that it could also be
>>>> used here.
>>>> 
>>>> Joel
>>>> 
>>>> 
>>>> Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
>>>> <mailto:jsanda at redhat.com>> a ?crit :
>>>> 
>>>>     My first thought was a string metric where data points are the
>>>>     servers that get discovered. There are a couple things though that
>>>>     I do not like about this. First, all data point queries in
>>>>     hawkular-metrics have a date range. Having to use a date range
>>>>     here seems a bit awkward. Secondly all data points in
>>>>     hawkular-metrics expire. These does not seem like data that we
>>>>     would want to expire.
>>>> 
>>>>>     On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com
>>>>>     <mailto:jshaughn at redhat.com>> wrote:
>>>>> 
>>>>> 
>>>>>     i was thinking, perhaps it's not even necessary to involve
>>>>>     inventory to know if the server was reported or not.  We define
>>>>>     metrics, like avail, for these root types, I think.  At startup
>>>>>     if the metric existed perhaps you could assume it was already
>>>>>     reported, otherwise you could send a "new server" event.  Would
>>>>>     that approach fly or be easier?
>>>>> 
>>>>>     On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>>>>>>     For point 1., we can probably use some functions I wrote in the
>>>>>>     integration tests, see there:
>>>>>>     https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java
>>>>>>     <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
>>>>>> 
>>>>>> 
>>>>>>     I assume you can build a canonical path? (The same "canonical
>>>>>>     path" than in the existing inventory) If so, the method
>>>>>>     "getBlueprintFromCP" gives it to you as an Optional blueprint.
>>>>>> 
>>>>>>     On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli
>>>>>>     <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>>>>>> 
>>>>>>         <tl;dr>
>>>>>> 
>>>>>>         Need ideas on how we are to implement the following two
>>>>>>         things in the agent:
>>>>>> 
>>>>>>         1. At startup, agent needs to ask H-Metrics "what top-level
>>>>>>         servers have I told you about in an earlier life?"
>>>>>> 
>>>>>>         2. When a new server is discovered, the agent should send an
>>>>>>         event to the server about the new server EXCEPT if the
>>>>>>         server isn't really new at all (see 1. above)
>>>>>> 
>>>>>>         </tl;dr>
>>>>>> 
>>>>>> 
>>>>>>         ===
>>>>>> 
>>>>>> 
>>>>>>         This post is to open up a discussion on how we want to
>>>>>>         implement a new features in the agent.
>>>>>> 
>>>>>>         Joel is developing a new "inventory in metrics" feature:
>>>>>>         https://github.com/hawkular/hawkular-agent/pull/303
>>>>>>         <https://github.com/hawkular/hawkular-agent/pull/303>
>>>>>> 
>>>>>>         This means the agent will be storing inventory directly into
>>>>>>         Hawkular-Metrics. Because of this, we need to figure out how
>>>>>>         to get events sent based on things happening in H-Metric's
>>>>>>         inventory so MiQ can do things with it (like put things in
>>>>>>         the timeline such as "new server discovered" or "new WAR was
>>>>>>         deployed").
>>>>>> 
>>>>>>         Jay looked at the code and the only thing that would be
>>>>>>         "missing" after this move of inventory into metrics is an
>>>>>>         event triggered when a new server is added to inventory.
>>>>>>         (When a new deployment is added, or a deployment is removed,
>>>>>>         the server is looking at command responses and generating
>>>>>>         events from that - so we don't lose anything by moving
>>>>>>         inventory into metrics).
>>>>>> 
>>>>>>         By "new server", what we mean is a new resource that has no
>>>>>>         parent resources (i.e. a "root resource"). This includes
>>>>>>         standalone WildFly Servers and domain Host Controllers.
>>>>>> 
>>>>>>         Right now, the agent starts with a "clean slate" when it
>>>>>>         starts up for the first time, or restarts. That means the
>>>>>>         agent's in-memory inventory graph is completely empty at
>>>>>>         startup - when discovery is run, the agent's internal
>>>>>>         inventory graph is filled in. After that, the agent just
>>>>>>         keeps the inventory graph up to date as it discovers new
>>>>>>         things coming and old things going away.
>>>>>> 
>>>>>>         We need the agent to know if it already stored its top level
>>>>>>         servers into H-Metrics inventory and if it did, not to
>>>>>>         generate any "new server event". But if the agent is brand
>>>>>>         new, and it never sent any top-level resources to H-Metrics
>>>>>>         inventory yet, it should now send a "new server" event to
>>>>>>         the server (the agent never sent events like this before).
>>>>>> 
>>>>>>         So there are two new things (assuming we keep the stuff Joel
>>>>>>         is doing - that is, we store inventory into H-Metrics):
>>>>>> 
>>>>>>         1. At startup, agent needs to ask H-Metrics "what top-level
>>>>>>         servers have I told you about in an earlier life?"
>>>>>> 
>>>>>>         2. When a new server is discovered, the agent should send an
>>>>>>         event (whatever this means - probably a REST API call
>>>>>>         somewhere) about the new server EXCEPT if the server isn't
>>>>>>         really new at all (see 1. above)
>>>>>> 
>>>>>>         We need to figure out how to implement 1. and 2. So we are
>>>>>>         soliciting thoughts on those two subjects.
>>>>>>         _______________________________________________
>>>>>>         hawkular-dev mailing list
>>>>>>         hawkular-dev at lists.jboss.org
>>>>>>         <mailto:hawkular-dev at lists.jboss.org>
>>>>>>         https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>>         <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>     _______________________________________________
>>>>>>     hawkular-dev mailing list
>>>>>>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>>>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>>>     _______________________________________________ hawkular-dev
>>>>>     mailing list hawkular-dev at lists.jboss.org
>>>>>     <mailto:hawkular-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>>     _______________________________________________ hawkular-dev
>>>>     mailing list hawkular-dev at lists.jboss.org
>>>>     <mailto:hawkular-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>> 
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev



From jshaughn at redhat.com  Tue Mar 28 09:25:01 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Tue, 28 Mar 2017 09:25:01 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
Message-ID: <ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>


If we could just use existing metrics to make the determination we could 
avoid the TTL issue, I think.   If we went with something like below I'd 
just suggest a single metric definition with a tag for each server 
name.  Do metric defs suffer from TTL?

On 3/27/2017 11:36 PM, John Sanda wrote:
> My first thought was a string metric where data points are the servers 
> that get discovered. There are a couple things though that I do not 
> like about this. First, all data point queries in hawkular-metrics 
> have a date range. Having to use a date range here seems a bit 
> awkward. Secondly all data points in hawkular-metrics expire. These 
> does not seem like data that we would want to expire.
>
>> On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com 
>> <mailto:jshaughn at redhat.com>> wrote:
>>
>>
>> i was thinking, perhaps it's not even necessary to involve inventory 
>> to know if the server was reported or not.  We define metrics, like 
>> avail, for these root types, I think.  At startup if the metric 
>> existed perhaps you could assume it was already reported, otherwise 
>> you could send a "new server" event.  Would that approach fly or be 
>> easier?
>>
>> On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>>> For point 1., we can probably use some functions I wrote in the 
>>> integration tests, see there: 
>>> https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java 
>>>
>>>
>>> I assume you can build a canonical path? (The same "canonical path" 
>>> than in the existing inventory) If so, the method 
>>> "getBlueprintFromCP" gives it to you as an Optional blueprint.
>>>
>>> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com 
>>> <mailto:mazz at redhat.com>> wrote:
>>>
>>>     <tl;dr>
>>>
>>>     Need ideas on how we are to implement the following two things
>>>     in the agent:
>>>
>>>     1. At startup, agent needs to ask H-Metrics "what top-level
>>>     servers have I told you about in an earlier life?"
>>>
>>>     2. When a new server is discovered, the agent should send an
>>>     event to the server about the new server EXCEPT if the server
>>>     isn't really new at all (see 1. above)
>>>
>>>     </tl;dr>
>>>
>>>
>>>     ===
>>>
>>>
>>>     This post is to open up a discussion on how we want to implement
>>>     a new features in the agent.
>>>
>>>     Joel is developing a new "inventory in metrics" feature:
>>>     https://github.com/hawkular/hawkular-agent/pull/303
>>>     <https://github.com/hawkular/hawkular-agent/pull/303>
>>>
>>>     This means the agent will be storing inventory directly into
>>>     Hawkular-Metrics. Because of this, we need to figure out how to
>>>     get events sent based on things happening in H-Metric's
>>>     inventory so MiQ can do things with it (like put things in the
>>>     timeline such as "new server discovered" or "new WAR was deployed").
>>>
>>>     Jay looked at the code and the only thing that would be
>>>     "missing" after this move of inventory into metrics is an event
>>>     triggered when a new server is added to inventory. (When a new
>>>     deployment is added, or a deployment is removed, the server is
>>>     looking at command responses and generating events from that -
>>>     so we don't lose anything by moving inventory into metrics).
>>>
>>>     By "new server", what we mean is a new resource that has no
>>>     parent resources (i.e. a "root resource"). This includes
>>>     standalone WildFly Servers and domain Host Controllers.
>>>
>>>     Right now, the agent starts with a "clean slate" when it starts
>>>     up for the first time, or restarts. That means the agent's
>>>     in-memory inventory graph is completely empty at startup - when
>>>     discovery is run, the agent's internal inventory graph is filled
>>>     in. After that, the agent just keeps the inventory graph up to
>>>     date as it discovers new things coming and old things going away.
>>>
>>>     We need the agent to know if it already stored its top level
>>>     servers into H-Metrics inventory and if it did, not to generate
>>>     any "new server event". But if the agent is brand new, and it
>>>     never sent any top-level resources to H-Metrics inventory yet,
>>>     it should now send a "new server" event to the server (the agent
>>>     never sent events like this before).
>>>
>>>     So there are two new things (assuming we keep the stuff Joel is
>>>     doing - that is, we store inventory into H-Metrics):
>>>
>>>     1. At startup, agent needs to ask H-Metrics "what top-level
>>>     servers have I told you about in an earlier life?"
>>>
>>>     2. When a new server is discovered, the agent should send an
>>>     event (whatever this means - probably a REST API call somewhere)
>>>     about the new server EXCEPT if the server isn't really new at
>>>     all (see 1. above)
>>>
>>>     We need to figure out how to implement 1. and 2. So we are
>>>     soliciting thoughts on those two subjects.
>>>     _______________________________________________
>>>     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
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

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

From jtakvori at redhat.com  Tue Mar 28 09:25:39 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Tue, 28 Mar 2017 15:25:39 +0200
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <0338587e-47df-4a90-b8f6-6ac2eeb02900@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<CAJo5TFmnCy3Bjk6obZBOi4REE1EQjcU4W5tYjEDYBU_kFdm0aA@mail.gmail.com>
	<CAJo5TFmcYk6PHa5WHFAfjuhThBoeWMHu3yfRMjQT=0Tdxb76fg@mail.gmail.com>
	<CAJo5TFk5n4oFy6WrV14mDreusRB7O9OUfMKvB=fBV90Oj+XkUg@mail.gmail.com>
	<42151499-4f9e-087e-240c-2917457fbf81@redhat.com>
	<1264438023.15798815.1490704495074.JavaMail.zimbra@redhat.com>
	<0338587e-47df-4a90-b8f6-6ac2eeb02900@redhat.com>
Message-ID: <CAJo5TFmqzin83TbLOuw2M47hjhPqn3Wmvm=_jG+1tSYNUmPHFw@mail.gmail.com>

Maybe the longer-term solution would be a taggable key-value store? Either
generic or dedicated...

On Tue, Mar 28, 2017 at 3:04 PM, Michael Burman <miburman at redhat.com> wrote:

> I don't think Cassandra supports that. If there's a table TTL, one needs
> to set a TTL to override the default expiry.
>
>    - Micke
>
>
> On 03/28/2017 03:34 PM, John Mazzitelli wrote:
> > how about make a value -2 meaning "no TTL at all - ignore even the table
> TTL"
> >
> > ----- Original Message -----
> >> Hi,
> >>
> >> If you use TTL -1 in current Hawkular-Metrics, we will write without
> >> setting TTL information. At that point the table TTL will be used (if
> >> such is set).
> >>
> >>     -  Micke
> >>
> >>
> >> On 03/28/2017 11:36 AM, Joel Takvorian wrote:
> >>> It could be interesting to have the possibility to deactivate TTL (for
> >>> instance by setting a negative value, without any change in the
> >>> existing API for that) but for the time being we could have the
> >>> workaround of setting an arbitrary high value, no?
> >>>
> >>> Concerning the time range, at some point I was using "fromEarliest:
> >>> true", " order: desc" and "limit:1" ... It seems that it could also be
> >>> used here.
> >>>
> >>> Joel
> >>>
> >>>
> >>> Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
> >>> <mailto:jsanda at redhat.com>> a ?crit :
> >>>
> >>>      My first thought was a string metric where data points are the
> >>>      servers that get discovered. There are a couple things though that
> >>>      I do not like about this. First, all data point queries in
> >>>      hawkular-metrics have a date range. Having to use a date range
> >>>      here seems a bit awkward. Secondly all data points in
> >>>      hawkular-metrics expire. These does not seem like data that we
> >>>      would want to expire.
> >>>
> >>>>      On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <
> jshaughn at redhat.com
> >>>>      <mailto:jshaughn at redhat.com>> wrote:
> >>>>
> >>>>
> >>>>      i was thinking, perhaps it's not even necessary to involve
> >>>>      inventory to know if the server was reported or not.  We define
> >>>>      metrics, like avail, for these root types, I think.  At startup
> >>>>      if the metric existed perhaps you could assume it was already
> >>>>      reported, otherwise you could send a "new server" event.  Would
> >>>>      that approach fly or be easier?
> >>>>
> >>>>      On 3/27/2017 12:40 PM, Joel Takvorian wrote:
> >>>>>      For point 1., we can probably use some functions I wrote in the
> >>>>>      integration tests, see there:
> >>>>>      https://github.com/jotak/hawkular-agent/blob/inventory-
> strings/hawkular-agent-itest-util/src/main/java/org/
> hawkular/agent/itest/util/ITestHelper.java
> >>>>>      <https://github.com/jotak/hawkular-agent/blob/inventory-
> strings/hawkular-agent-itest-util/src/main/java/org/
> hawkular/agent/itest/util/ITestHelper.java>
> >>>>>
> >>>>>
> >>>>>      I assume you can build a canonical path? (The same "canonical
> >>>>>      path" than in the existing inventory) If so, the method
> >>>>>      "getBlueprintFromCP" gives it to you as an Optional blueprint.
> >>>>>
> >>>>>      On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli
> >>>>>      <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
> >>>>>
> >>>>>          <tl;dr>
> >>>>>
> >>>>>          Need ideas on how we are to implement the following two
> >>>>>          things in the agent:
> >>>>>
> >>>>>          1. At startup, agent needs to ask H-Metrics "what top-level
> >>>>>          servers have I told you about in an earlier life?"
> >>>>>
> >>>>>          2. When a new server is discovered, the agent should send an
> >>>>>          event to the server about the new server EXCEPT if the
> >>>>>          server isn't really new at all (see 1. above)
> >>>>>
> >>>>>          </tl;dr>
> >>>>>
> >>>>>
> >>>>>          ===
> >>>>>
> >>>>>
> >>>>>          This post is to open up a discussion on how we want to
> >>>>>          implement a new features in the agent.
> >>>>>
> >>>>>          Joel is developing a new "inventory in metrics" feature:
> >>>>>          https://github.com/hawkular/hawkular-agent/pull/303
> >>>>>          <https://github.com/hawkular/hawkular-agent/pull/303>
> >>>>>
> >>>>>          This means the agent will be storing inventory directly into
> >>>>>          Hawkular-Metrics. Because of this, we need to figure out how
> >>>>>          to get events sent based on things happening in H-Metric's
> >>>>>          inventory so MiQ can do things with it (like put things in
> >>>>>          the timeline such as "new server discovered" or "new WAR was
> >>>>>          deployed").
> >>>>>
> >>>>>          Jay looked at the code and the only thing that would be
> >>>>>          "missing" after this move of inventory into metrics is an
> >>>>>          event triggered when a new server is added to inventory.
> >>>>>          (When a new deployment is added, or a deployment is removed,
> >>>>>          the server is looking at command responses and generating
> >>>>>          events from that - so we don't lose anything by moving
> >>>>>          inventory into metrics).
> >>>>>
> >>>>>          By "new server", what we mean is a new resource that has no
> >>>>>          parent resources (i.e. a "root resource"). This includes
> >>>>>          standalone WildFly Servers and domain Host Controllers.
> >>>>>
> >>>>>          Right now, the agent starts with a "clean slate" when it
> >>>>>          starts up for the first time, or restarts. That means the
> >>>>>          agent's in-memory inventory graph is completely empty at
> >>>>>          startup - when discovery is run, the agent's internal
> >>>>>          inventory graph is filled in. After that, the agent just
> >>>>>          keeps the inventory graph up to date as it discovers new
> >>>>>          things coming and old things going away.
> >>>>>
> >>>>>          We need the agent to know if it already stored its top level
> >>>>>          servers into H-Metrics inventory and if it did, not to
> >>>>>          generate any "new server event". But if the agent is brand
> >>>>>          new, and it never sent any top-level resources to H-Metrics
> >>>>>          inventory yet, it should now send a "new server" event to
> >>>>>          the server (the agent never sent events like this before).
> >>>>>
> >>>>>          So there are two new things (assuming we keep the stuff Joel
> >>>>>          is doing - that is, we store inventory into H-Metrics):
> >>>>>
> >>>>>          1. At startup, agent needs to ask H-Metrics "what top-level
> >>>>>          servers have I told you about in an earlier life?"
> >>>>>
> >>>>>          2. When a new server is discovered, the agent should send an
> >>>>>          event (whatever this means - probably a REST API call
> >>>>>          somewhere) about the new server EXCEPT if the server isn't
> >>>>>          really new at all (see 1. above)
> >>>>>
> >>>>>          We need to figure out how to implement 1. and 2. So we are
> >>>>>          soliciting thoughts on those two subjects.
> >>>>>          _______________________________________________
> >>>>>          hawkular-dev mailing list
> >>>>>          hawkular-dev at lists.jboss.org
> >>>>>          <mailto:hawkular-dev at lists.jboss.org>
> >>>>>          https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>>>          <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>      _______________________________________________
> >>>>>      hawkular-dev mailing list
> >>>>>      hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.
> jboss.org>
> >>>>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>>>      _______________________________________________ hawkular-dev
> >>>>      mailing list hawkular-dev at lists.jboss.org
> >>>>      <mailto:hawkular-dev at lists.jboss.org>
> >>>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>>      _______________________________________________ hawkular-dev
> >>>      mailing list hawkular-dev at lists.jboss.org
> >>>      <mailto:hawkular-dev at lists.jboss.org>
> >>>      https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>>      <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> >>>
> >>> _______________________________________________
> >>> hawkular-dev mailing list
> >>> hawkular-dev at lists.jboss.org
> >>> https://lists.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/20170328/0855b5b7/attachment.html 

From jsanda at redhat.com  Tue Mar 28 10:09:14 2017
From: jsanda at redhat.com (John Sanda)
Date: Tue, 28 Mar 2017 10:09:14 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
Message-ID: <E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>

The metric definitions do not expire, but they need to be explicitly created for what you are suggesting to work. Even then we might run into problems. We are introducing a feature to purge metric definitions that have not received any data for some time. Unless we continue to periodically update the metrics used, we might run into problems.

> On Mar 28, 2017, at 9:25 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
> 
> 
> If we could just use existing metrics to make the determination we could avoid the TTL issue, I think.   If we went with something like below I'd just suggest a single metric definition with a tag for each server name.  Do metric defs suffer from TTL?
> 
> On 3/27/2017 11:36 PM, John Sanda wrote:
>> My first thought was a string metric where data points are the servers that get discovered. There are a couple things though that I do not like about this. First, all data point queries in hawkular-metrics have a date range. Having to use a date range here seems a bit awkward. Secondly all data points in hawkular-metrics expire. These does not seem like data that we would want to expire.
>> 
>>> On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com <mailto:jshaughn at redhat.com>> wrote:
>>> 
>>> 
>>> i was thinking, perhaps it's not even necessary to involve inventory to know if the server was reported or not.  We define metrics, like avail, for these root types, I think.  At startup if the metric existed perhaps you could assume it was already reported, otherwise you could send a "new server" event.  Would that approach fly or be easier?
>>> 
>>> On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>>>> For point 1., we can probably use some functions I wrote in the integration tests, see there: https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java>
>>>> 
>>>> I assume you can build a canonical path? (The same "canonical path" than in the existing inventory) If so, the method "getBlueprintFromCP" gives it to you as an Optional blueprint.
>>>> 
>>>> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com <mailto:mazz at redhat.com>> wrote:
>>>> <tl;dr>
>>>> 
>>>> Need ideas on how we are to implement the following two things in the agent:
>>>> 
>>>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"
>>>> 
>>>> 2. When a new server is discovered, the agent should send an event to the server about the new server EXCEPT if the server isn't really new at all (see 1. above)
>>>> 
>>>> </tl;dr>
>>>> 
>>>> 
>>>> ===
>>>> 
>>>> 
>>>> This post is to open up a discussion on how we want to implement a new features in the agent.
>>>> 
>>>> Joel is developing a new "inventory in metrics" feature: https://github.com/hawkular/hawkular-agent/pull/303 <https://github.com/hawkular/hawkular-agent/pull/303>
>>>> 
>>>> This means the agent will be storing inventory directly into Hawkular-Metrics. Because of this, we need to figure out how to get events sent based on things happening in H-Metric's inventory so MiQ can do things with it (like put things in the timeline such as "new server discovered" or "new WAR was deployed").
>>>> 
>>>> Jay looked at the code and the only thing that would be "missing" after this move of inventory into metrics is an event triggered when a new server is added to inventory. (When a new deployment is added, or a deployment is removed, the server is looking at command responses and generating events from that - so we don't lose anything by moving inventory into metrics).
>>>> 
>>>> By "new server", what we mean is a new resource that has no parent resources (i.e. a "root resource"). This includes standalone WildFly Servers and domain Host Controllers.
>>>> 
>>>> Right now, the agent starts with a "clean slate" when it starts up for the first time, or restarts. That means the agent's in-memory inventory graph is completely empty at startup - when discovery is run, the agent's internal inventory graph is filled in. After that, the agent just keeps the inventory graph up to date as it discovers new things coming and old things going away.
>>>> 
>>>> We need the agent to know if it already stored its top level servers into H-Metrics inventory and if it did, not to generate any "new server event". But if the agent is brand new, and it never sent any top-level resources to H-Metrics inventory yet, it should now send a "new server" event to the server (the agent never sent events like this before).
>>>> 
>>>> So there are two new things (assuming we keep the stuff Joel is doing - that is, we store inventory into H-Metrics):
>>>> 
>>>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told you about in an earlier life?"
>>>> 
>>>> 2. When a new server is discovered, the agent should send an event (whatever this means - probably a REST API call somewhere) about the new server EXCEPT if the server isn't really new at all (see 1. above)
>>>> 
>>>> We need to figure out how to implement 1. and 2. So we are soliciting thoughts on those two subjects.
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>>> 
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>> 
>> 
>> 
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> 
> _______________________________________________
> 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/20170328/a8fad509/attachment-0001.html 

From jtakvori at redhat.com  Tue Mar 28 10:43:52 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Tue, 28 Mar 2017 16:43:52 +0200
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
Message-ID: <CAJo5TFkwC6fYo8tA+_=fzN8zrJ7aSoo0qZtuY8=4qus+yvX=Pg@mail.gmail.com>

And btw I have the exact same problem with the inventory storage on metrics

On Tue, Mar 28, 2017 at 4:09 PM, John Sanda <jsanda at redhat.com> wrote:

> The metric definitions do not expire, but they need to be explicitly
> created for what you are suggesting to work. Even then we might run into
> problems. We are introducing a feature to purge metric definitions that
> have not received any data for some time. Unless we continue to
> periodically update the metrics used, we might run into problems.
>
> On Mar 28, 2017, at 9:25 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
>
>
> If we could just use existing metrics to make the determination we could
> avoid the TTL issue, I think.   If we went with something like below I'd
> just suggest a single metric definition with a tag for each server name.
> Do metric defs suffer from TTL?
>
> On 3/27/2017 11:36 PM, John Sanda wrote:
>
> My first thought was a string metric where data points are the servers
> that get discovered. There are a couple things though that I do not like
> about this. First, all data point queries in hawkular-metrics have a date
> range. Having to use a date range here seems a bit awkward. Secondly all
> data points in hawkular-metrics expire. These does not seem like data that
> we would want to expire.
>
> On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
>
>
> i was thinking, perhaps it's not even necessary to involve inventory to
> know if the server was reported or not.  We define metrics, like avail, for
> these root types, I think.  At startup if the metric existed perhaps you
> could assume it was already reported, otherwise you could send a "new
> server" event.  Would that approach fly or be easier?
>
> On 3/27/2017 12:40 PM, Joel Takvorian wrote:
>
> For point 1., we can probably use some functions I wrote in the
> integration tests, see there: https://github.com/
> jotak/hawkular-agent/blob/inventory-strings/hawkular-
> agent-itest-util/src/main/java/org/hawkular/agent/itest/
> util/ITestHelper.java
>
> I assume you can build a canonical path? (The same "canonical path" than
> in the existing inventory) If so, the method "getBlueprintFromCP" gives
> it to you as an Optional blueprint.
>
> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com> wrote:
>
>> <tl;dr>
>>
>> Need ideas on how we are to implement the following two things in the
>> agent:
>>
>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have
>> I told you about in an earlier life?"
>>
>> 2. When a new server is discovered, the agent should send an event to the
>> server about the new server EXCEPT if the server isn't really new at all
>> (see 1. above)
>>
>> </tl;dr>
>>
>>
>> ===
>>
>>
>> This post is to open up a discussion on how we want to implement a new
>> features in the agent.
>>
>> Joel is developing a new "inventory in metrics" feature:
>> https://github.com/hawkular/hawkular-agent/pull/303
>>
>> This means the agent will be storing inventory directly into
>> Hawkular-Metrics. Because of this, we need to figure out how to get events
>> sent based on things happening in H-Metric's inventory so MiQ can do things
>> with it (like put things in the timeline such as "new server discovered" or
>> "new WAR was deployed").
>>
>> Jay looked at the code and the only thing that would be "missing" after
>> this move of inventory into metrics is an event triggered when a new server
>> is added to inventory. (When a new deployment is added, or a deployment is
>> removed, the server is looking at command responses and generating events
>> from that - so we don't lose anything by moving inventory into metrics).
>>
>> By "new server", what we mean is a new resource that has no parent
>> resources (i.e. a "root resource"). This includes standalone WildFly
>> Servers and domain Host Controllers.
>>
>> Right now, the agent starts with a "clean slate" when it starts up for
>> the first time, or restarts. That means the agent's in-memory inventory
>> graph is completely empty at startup - when discovery is run, the agent's
>> internal inventory graph is filled in. After that, the agent just keeps the
>> inventory graph up to date as it discovers new things coming and old things
>> going away.
>>
>> We need the agent to know if it already stored its top level servers into
>> H-Metrics inventory and if it did, not to generate any "new server event".
>> But if the agent is brand new, and it never sent any top-level resources to
>> H-Metrics inventory yet, it should now send a "new server" event to the
>> server (the agent never sent events like this before).
>>
>> So there are two new things (assuming we keep the stuff Joel is doing -
>> that is, we store inventory into H-Metrics):
>>
>> 1. At startup, agent needs to ask H-Metrics "what top-level servers have
>> I told you about in an earlier life?"
>>
>> 2. When a new server is discovered, the agent should send an event
>> (whatever this means - probably a REST API call somewhere) about the new
>> server EXCEPT if the server isn't really new at all (see 1. above)
>>
>> We need to figure out how to implement 1. and 2. So we are soliciting
>> thoughts on those two subjects.
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
>
> _______________________________________________
> 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 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/20170328/1969db53/attachment.html 

From jtakvori at redhat.com  Wed Mar 29 04:35:13 2017
From: jtakvori at redhat.com (Joel Takvorian)
Date: Wed, 29 Mar 2017 10:35:13 +0200
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
Message-ID: <CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>

On Tue, Mar 28, 2017 at 4:09 PM, John Sanda <jsanda at redhat.com> wrote:

> We are introducing a feature to purge metric definitions that have not
> received any data for some time.
>
>
If I understand this PR [1], metrics are eligible for deletion only when
their data points have all expired. If it's true then fixing the TTL
problem also fixes the metrics expiration problem.

[1] https://github.com/hawkular/hawkular-metrics/pull/785
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170329/af8de7b0/attachment.html 

From jsanda at redhat.com  Wed Mar 29 08:29:11 2017
From: jsanda at redhat.com (John Sanda)
Date: Wed, 29 Mar 2017 08:29:11 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
	<CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
Message-ID: <209DD9E0-C655-494F-AD87-0EF94F9D024F@redhat.com>


> On Mar 29, 2017, at 4:35 AM, Joel Takvorian <jtakvori at redhat.com> wrote:
> 
> On Tue, Mar 28, 2017 at 4:09 PM, John Sanda <jsanda at redhat.com <mailto:jsanda at redhat.com>> wrote:
> We are introducing a feature to purge metric definitions that have not received any data for some time.
> 
> 
> If I understand this PR [1], metrics are eligible for deletion only when their data points have all expired. If it's true then fixing the TTL problem also fixes the metrics expiration problem.
> 
> [1] https://github.com/hawkular/hawkular-metrics/pull/785 <https://github.com/hawkular/hawkular-metrics/pull/785>
Prior to this PR we added support for metric deletion; however, deletion does not result in immediate deletion of data points. We still let data points in in the data_compressed table expire. We do this because one of the guidelines for using TimeWindowCompactionStrategy (TWCS) is to use a global TTL and not delete data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170329/fd95bb56/attachment-0001.html 

From hrupp at redhat.com  Wed Mar 29 09:22:52 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 29 Mar 2017 14:22:52 +0100
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <209DD9E0-C655-494F-AD87-0EF94F9D024F@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
	<CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
	<209DD9E0-C655-494F-AD87-0EF94F9D024F@redhat.com>
Message-ID: <95AF21FF-CD99-4EAB-AA45-73D91C46852C@redhat.com>

On 29 Mar 2017, at 13:29, John Sanda wrote:

> however, deletion does not result in immediate deletion of data 
> points. We still let data points in in the data_compressed table 
> expire. We do this because one of the guidelines for using 
> TimeWindowCompactionStrategy (TWCS) is to use a global TTL and not 
> delete data._______________________________________________

This needs to be well documented as this is not what you
expect when you delete metrics in an urgency to free up space.

From snegrea at redhat.com  Wed Mar 29 10:01:53 2017
From: snegrea at redhat.com (Stefan Negrea)
Date: Wed, 29 Mar 2017 09:01:53 -0500
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
	<CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
Message-ID: <CADt-fV9=CpSXk2pFAKzmjcK477xn2-eS4BEgzk6ETbLWqQ4=Yw@mail.gmail.com>

On Wed, Mar 29, 2017 at 3:35 AM, Joel Takvorian <jtakvori at redhat.com> wrote:

> On Tue, Mar 28, 2017 at 4:09 PM, John Sanda <jsanda at redhat.com> wrote:
>
>> We are introducing a feature to purge metric definitions that have not
>> received any data for some time.
>>
>>
>
One more important detail about the PR, we will not yet purge String metric
definitions. We will enable String purge in a future release.



> If I understand this PR [1], metrics are eligible for deletion only when
> their data points have all expired. If it's true then fixing the TTL
> problem also fixes the metrics expiration problem.
>
> [1] https://github.com/hawkular/hawkular-metrics/pull/785
>
> _______________________________________________
> 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/20170329/eeb3e654/attachment.html 

From jsanda at redhat.com  Wed Mar 29 10:22:04 2017
From: jsanda at redhat.com (John Sanda)
Date: Wed, 29 Mar 2017 10:22:04 -0400
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <95AF21FF-CD99-4EAB-AA45-73D91C46852C@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
	<CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
	<209DD9E0-C655-494F-AD87-0EF94F9D024F@redhat.com>
	<95AF21FF-CD99-4EAB-AA45-73D91C46852C@redhat.com>
Message-ID: <DA1EA502-763D-4F75-9A12-52873D4112FA@redhat.com>


> On Mar 29, 2017, at 9:22 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 29 Mar 2017, at 13:29, John Sanda wrote:
> 
>> however, deletion does not result in immediate deletion of data 
>> points. We still let data points in in the data_compressed table 
>> expire. We do this because one of the guidelines for using 
>> TimeWindowCompactionStrategy (TWCS) is to use a global TTL and not 
>> delete data._______________________________________________
> 
> This needs to be well documented as this is not what you
> expect when you delete metrics in an urgency to free up space.

Yes, it does. The API docs mention this. It needs to be included in the user guide as well. I have read that deleting data when using TWCS can actually cause it to hang around longer than it would if you wait for it to expire, potentially resulting in more space being used. If we really want to delete data vs just letting it expire, then we should not be using TWCS, but I really think we want TWCS as it is designed specifically for time series data. We are using TWCS with compressed data. A week?s worth of compressed data for a metric is going to be quite small.

I suppose we need a section on deletes and how it works. The only ways in Cassandra to immediately purge data are:

* drop table
* truncate table
* manually purge sstables

TWCS basically deletes an entire sstable when it determines it is safe to do so. 

From hrupp at redhat.com  Wed Mar 29 11:40:12 2017
From: hrupp at redhat.com (Heiko W.Rupp)
Date: Wed, 29 Mar 2017 16:40:12 +0100
Subject: [Hawkular-dev] agent "new server" event
In-Reply-To: <DA1EA502-763D-4F75-9A12-52873D4112FA@redhat.com>
References: <885676728.15015672.1490625609860.JavaMail.zimbra@redhat.com>
	<148032350.15045295.1490626857364.JavaMail.zimbra@redhat.com>
	<CAJo5TFmTXA_qN_z9=3hMx4dy0L=GEabqAkdHNb+Tity_6vWV=A@mail.gmail.com>
	<0f7ebbf7-f52b-8c69-2125-3523f411b806@redhat.com>
	<BFA46AC8-B765-444E-AB44-5EF6CFD762B6@redhat.com>
	<ba8f5ecd-9395-f000-9026-8071a58299b1@redhat.com>
	<E0607144-38B1-432C-B9DA-7534D950F10B@redhat.com>
	<CAJo5TFmzmMYexca9A=PMA=hcS8t8kX74MPGau-yRWWbHtL_X0A@mail.gmail.com>
	<209DD9E0-C655-494F-AD87-0EF94F9D024F@redhat.com>
	<95AF21FF-CD99-4EAB-AA45-73D91C46852C@redhat.com>
	<DA1EA502-763D-4F75-9A12-52873D4112FA@redhat.com>
Message-ID: <C5156022-41D5-46D3-9AC2-7E0A33876EB0@redhat.com>

On 29 Mar 2017, at 15:22, John Sanda wrote:

>> This needs to be well documented as this is not what you
>> expect when you delete metrics in an urgency to free up space.
>
> [..] It needs to be included in the user guide as well.

This is what I meant. Sorry for not being more clear.

From jshaughn at redhat.com  Fri Mar 31 13:38:22 2017
From: jshaughn at redhat.com (Jay Shaughnessy)
Date: Fri, 31 Mar 2017 13:38:22 -0400
Subject: [Hawkular-dev] Hawkular Alerting 1.6.0.Final is Available!
Message-ID: <43f25842-428a-fa0f-ab30-be5622d5c831@redhat.com>


The Hawkular Alerting team is happy to announce the release of Hawkular 
Alerting 1.6.0.Final. This release introduces several new features as 
well as some important fixes.


    Features

  * Extension for Aggregated Events Alerting
      o Sliding windows to aggregate events and perform robust condition
        evaluations.
      o See
        http://www.hawkular.org/community/docs/developer-guide/alerts.html#_events_aggregation_extension
  * Tag Query Language
      o Powerful tag search with a new tag query language.
      o See
        http://www.hawkular.org/community/docs/developer-guide/alerts.html#_tags
  * Integration with Elasticsearch
      o Extension for conditions that query Elasticsearch.
      o Action Plugin for writing back to Elasticsearch,
      o See
        http://www.hawkular.org/community/docs/developer-guide/alerts.html#_elasticsearch_integration
  * Watcher Support
      o Open a connection and stream new alerts or events filtered by
        robust criteria
      o See http://www.hawkular.org/docs/rest/rest-alerts.html#GET__watch
  * Hawkular Metrics Integration
      o New Metrics Group Trigger feature to track member triggers
        automatically
      o See
        http://www.hawkular.org/hawkular-metrics/docs/user-guide/#_metrics_group_triggers
  * New Tutorial
      o Easy on-boarding with docker-based tutorial. First 5 lessons
        available.
      o See
        http://www.hawkular.org/blog/2017/03/14/hawkular-alerting-tutorial.html


    Enhancements

  * REST Endpoints
      o New endpoints for trigger enable/disable
      o Set all group trigger conditions, regardless of their triggerMode
  * Action TimeConstraints can now tie the constraint to a specific TimeZone
  * Support group members on Import.


    Fixes

  * [HWKALERTS-222 <https://issues.jboss.org/browse/HWKALERTS-222>] -
    Cassalog schema updates are lacking verification functions
  * [HWKALERTS-223 <https://issues.jboss.org/browse/HWKALERTS-223>] -
    Propagate Listener events on cluster scenarios
  * [HWKALERTS-227 <https://issues.jboss.org/browse/HWKALERTS-227>] -
    Schema bootstrap skip should handle failures and server shutdowns
  * [HWKALERTS-229 <https://issues.jboss.org/browse/HWKALERTS-229>] -
    Setting the conditions for group trigger ignores the condition
    triggerMode and follows only the triggerMode in the path parameters
  * [HWKALERTS-234 <https://issues.jboss.org/browse/HWKALERTS-234>] -
    MissingCondition handling needs to consider trigger mode
  * [HWKALERTS-243 <https://issues.jboss.org/browse/HWKALERTS-243>] -
    DefinitionsEvents might have a wrong order on import operations
  * [HWKALERTS-249 <https://issues.jboss.org/browse/HWKALERTS-249>] -
    Schema installation on multi Cassandra node cluster may fail



*Hawkular Alerting 1.6.0.Final is available:*

  * Immediately as a standalone distribution
  * Soon as part of Hawkular Metrics 0.26.0.Final
      o In Hawkular Services for ManageIQ
      o In OpenShift Online


For more details about this release: 
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12333585

http://www.hawkular.org/
http://www.hawkular.org/community/docs/developer-guide/alerts.html
http://www.hawkular.org/docs/rest/rest-alerts.html

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

#hawkular on freenode

Hawkular Alerting 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/20170331/8dafdd82/attachment-0001.html