Error

From lponce at redhat.com Mon Nov 2 03:26:37 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 2 Nov 2015 03:26:37 -0500 (EST) Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: References: <536565134.40626954.1445848010233.JavaMail.zimbra@redhat.com> <562F6E0F.2000908@redhat.com> <56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> Message-ID: <864275227.384348.1446452797498.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Anton Hughes" > To: "Discussions around Hawkular development" > Sent: Friday, October 30, 2015 2:16:29 PM > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > Coming back to my original question - and based on some further thinking and > reading of the Hawkular website, I have the following thoughts. > > On the Hawkular website, it is written: > > > > For who ? > There are primarly (BTW - this is spelled incorrect) two types of users. > Users who wants a toolkit to do server/ system monitoring in general, for > them we provide a rich REST API to store metrics, trigger alerts and manage > an inventory of resources > Users who want a full-fledge admin console to monitor and manage middleware > servers (Currently, only WildFly is supported) > I've highlighted the general area that I am most interested - and I think > many others would be too. > Please take a quick look at http://martinfowler.com/eaaDev/EventSourcing.html > . Event Sourcing places emphasis on events of interest - in the Shipping > example in this link the interesting events are: > > > * Ship Arrives > * Ship Departs > > To be able store (store metrics?) and react (trigger alert) in this example > would be very beneficial in many situations. > > I hope this helps to illustrates my use-case. > Hi Anton, Thanks for giving feedback and illustrate this interesting use case. We are finishing the Events feature inside the Hawkular Alerts component and I think that it can work for your requeriments. Once development is in a state to be used I will add some examples following your use case (and publish them on the blog). I hope that might helps. Lucas > On 29 October 2015 at 14:34, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > > > Anton, yes, it can be a little confusing. The Hawkular project is an > end-to-end monitoring and management tool focused on Red Hat software. Today > it basically offers a Wildfly agent for discovering and managing app > servers, their hosted apps, and all of the things that make up those apps. > What is can handle grows with every release. Hawkular leverages a bunch of > components to perform that job. There is HK-Inventory to represent a network > of inventories resources (like an app server, a datasource, a jvm, etc), > HK-Metrics as a Cassandra-backed time-series store, HK-Alerts as a > Drools-backed alerting tool, HK-Accounts as a KeyCloak backed > multi-tenant/auth/authz tool, HK-Console for UI, HK-Bus for a comm backbone, > etc.. > > Some of the HK components, namely HK-Metrics and HK-Alerts support standalone > deployment outside of Hawkular. They are named Hawkular-Metrics and > Hawkular-Alerts because they have been developed as part of the Hawkular > project, but they can be used independently. Hope that helps... > > > On 10/29/2015 9:16 AM, Anton Hughes wrote: > > > > > On 29 October 2015 at 14:12, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > Metrics and Alerts can both be used outside of the Hawkular framework so > really you can store any metric you like, or alert on basically any data you > like. As for Events, the next release of Hawkular Alerts (0.6.0) will > include a new Events feature that you may find interesting. Whereas Alerts > are relatively rare, typically involve human interaction, and run through a > simple life-cycle; Events are likely much more numerous, representing any > sort of happening that a client wants to persist. The interesting thing > about Events in HK-Alerts is that they can be inserted directly via API or > can be generated via Trigger, like an Alert. And Events can also be used as > Trigger conditions, to contribute to further Alert or Event generation. > > Thanks Jay - this sounds really cool! > > I have heard a few times now that hawkular components can be used outside of > the hawkular framework. What exactly is the hawkular framework? As an > outsider I am learning about Hawkular and its features. There is good > documentation on the features, but the underlying framework, not so much. > > Also, regarding documentation, I could not find how to store any 'metric' or > data. Specifically, I am looking to store not just a metric but a pojo. > > > > > -- > Anton Hughes > > > > _______________________________________________ > hawkular-dev mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > -- > Anton Hughes > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Nov 2 04:06:13 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 2 Nov 2015 10:06:13 +0100 Subject: [Hawkular-dev] the name of our hawkular agent/wildfly monitor/feed is confusing - I'm fixing it In-Reply-To: <1298262702.39404099.1446246136758.JavaMail.zimbra@redhat.com> References: <280652770.39402500.1446245912220.JavaMail.zimbra@redhat.com> <1298262702.39404099.1446246136758.JavaMail.zimbra@redhat.com> Message-ID: +1 On Sat, Oct 31, 2015 at 12:02 AM, John Mazzitelli wrote: > As I'm writing code and docs and javadocs all around, I realize that the > name of our "agent" is utterly confused. We need to fix this or we will > eventually confuse users/customers. > > Right now in code, or comments, or docs, or just in talking, the names of > the "agent" have been at one time or another: > > agent > wildfly monitor > wildfly hawkular feed > wildfly monitor agent > wildfly extension > wildfly agent module > wildfly agent > etc. etc. etc. > > Over the weekend, I'm going to start renaming this so it is consistent > across the board. > > It will be called "Hawkular WildFly Agent" > > This will affect maven artifact names moving forward. But we need to fix > this now, because its confusing ME. I can only imagine the confusion when > people start to ask "what do you call the hawkular thing that monitors > Wildfly?" > _______________________________________________ > 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/20151102/d39306d7/attachment.html From ah at tradeworks.io Mon Nov 2 05:43:41 2015 From: ah at tradeworks.io (Anton Hughes) Date: Mon, 2 Nov 2015 11:43:41 +0100 Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: <864275227.384348.1446452797498.JavaMail.zimbra@redhat.com> References: <536565134.40626954.1445848010233.JavaMail.zimbra@redhat.com> <562F6E0F.2000908@redhat.com> <56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> <864275227.384348.1446452797498.JavaMail.zimbra@redhat.com> Message-ID: Thanks Lucas Sounds really great! Much appreciated! On 2 November 2015 at 09:26, Lucas Ponce wrote: > > > ----- Original Message ----- > > From: "Anton Hughes" > > To: "Discussions around Hawkular development" < > hawkular-dev at lists.jboss.org> > > Sent: Friday, October 30, 2015 2:16:29 PM > > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > > > Coming back to my original question - and based on some further thinking > and > > reading of the Hawkular website, I have the following thoughts. > > > > On the Hawkular website, it is written: > > > > > > > > For who ? > > There are primarly (BTW - this is spelled incorrect) two types of users. > > Users who wants a toolkit to do server/ system monitoring in general, for > > them we provide a rich REST API to store metrics, trigger alerts and > manage > > an inventory of resources > > Users who want a full-fledge admin console to monitor and manage > middleware > > servers (Currently, only WildFly is supported) > > I've highlighted the general area that I am most interested - and I think > > many others would be too. > > Please take a quick look at > http://martinfowler.com/eaaDev/EventSourcing.html > > . Event Sourcing places emphasis on events of interest - in the Shipping > > example in this link the interesting events are: > > > > > > * Ship Arrives > > * Ship Departs > > > > To be able store (store metrics?) and react (trigger alert) in this > example > > would be very beneficial in many situations. > > > > I hope this helps to illustrates my use-case. > > > > Hi Anton, > > Thanks for giving feedback and illustrate this interesting use case. > > We are finishing the Events feature inside the Hawkular Alerts component > and I think that it can work for your requeriments. > > Once development is in a state to be used I will add some examples > following your use case (and publish them on the blog). > > I hope that might helps. > > Lucas > > > > On 29 October 2015 at 14:34, Jay Shaughnessy < jshaughn at redhat.com > > wrote: > > > > > > > > > > Anton, yes, it can be a little confusing. The Hawkular project is an > > end-to-end monitoring and management tool focused on Red Hat software. > Today > > it basically offers a Wildfly agent for discovering and managing app > > servers, their hosted apps, and all of the things that make up those > apps. > > What is can handle grows with every release. Hawkular leverages a bunch > of > > components to perform that job. There is HK-Inventory to represent a > network > > of inventories resources (like an app server, a datasource, a jvm, etc), > > HK-Metrics as a Cassandra-backed time-series store, HK-Alerts as a > > Drools-backed alerting tool, HK-Accounts as a KeyCloak backed > > multi-tenant/auth/authz tool, HK-Console for UI, HK-Bus for a comm > backbone, > > etc.. > > > > Some of the HK components, namely HK-Metrics and HK-Alerts support > standalone > > deployment outside of Hawkular. They are named Hawkular-Metrics and > > Hawkular-Alerts because they have been developed as part of the Hawkular > > project, but they can be used independently. Hope that helps... > > > > > > On 10/29/2015 9:16 AM, Anton Hughes wrote: > > > > > > > > > > On 29 October 2015 at 14:12, Jay Shaughnessy < jshaughn at redhat.com > > wrote: > > > > > > Metrics and Alerts can both be used outside of the Hawkular framework so > > really you can store any metric you like, or alert on basically any data > you > > like. As for Events, the next release of Hawkular Alerts (0.6.0) will > > include a new Events feature that you may find interesting. Whereas > Alerts > > are relatively rare, typically involve human interaction, and run > through a > > simple life-cycle; Events are likely much more numerous, representing any > > sort of happening that a client wants to persist. The interesting thing > > about Events in HK-Alerts is that they can be inserted directly via API > or > > can be generated via Trigger, like an Alert. And Events can also be used > as > > Trigger conditions, to contribute to further Alert or Event generation. > > > > Thanks Jay - this sounds really cool! > > > > I have heard a few times now that hawkular components can be used > outside of > > the hawkular framework. What exactly is the hawkular framework? As an > > outsider I am learning about Hawkular and its features. There is good > > documentation on the features, but the underlying framework, not so much. > > > > Also, regarding documentation, I could not find how to store any > 'metric' or > > data. Specifically, I am looking to store not just a metric but a pojo. > > > > > > > > > > -- > > Anton Hughes > > > > > > > > _______________________________________________ > > hawkular-dev mailing list hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > -- > > Anton Hughes > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151102/d8693ad1/attachment-0001.html From mwringe at redhat.com Mon Nov 2 09:24:22 2015 From: mwringe at redhat.com (Matthew Wringe) Date: Mon, 2 Nov 2015 09:24:22 -0500 (EST) Subject: [Hawkular-dev] Openshift Origin release candidate 1 is now available .... In-Reply-To: <1980897020.87133257.1446221972775.JavaMail.zimbra@redhat.com> References:

<1068488704.31642424.1446220647971.JavaMail.zimbra@redhat.com> <1980897020.87133257.1446221972775.JavaMail.zimbra@redhat.com> Message-ID: <2033393592.1256542.1446474262167.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Michael Foley" > To: "Matthew Mahoney" , "Viet Nguyen" , "Matthew Wringe" > , "Peter Ruan" , "Thomas Heute" , "John Sanda" > , "Stefan Negrea" , hawkular-dev at lists.jboss.org > Cc: "Richa Marwaha" > Sent: Friday, October 30, 2015 12:19:32 PM > Subject: Openshift Origin release candidate 1 is now available .... > > Hi, > > Openshift Origin Release Candidate 1 is now available. > > Unfortunately, Metrics is not in this release candidate ...and will be in the > next version 1.0.8, which I presume will be Release Candidate 2. >From the v1.0.7 release notes, it looks like metrics is already in there, at least for the console work : https://github.com/openshift/origin/releases/tag/v1.0.7 The only other things would be the containers, but those live outside of the OpenShift code base (https://github.com/openshift/origin-metrics) so it makes things a bit tricky in terms of syncing releases. I guess we should have built images under the openshift docker hub account and tagged them with the v1.0.7 version. Since the Console work is already in v1.0.7, and we have our own containers, I can't see why we can't start testing with v1.0.7/RC1-1.1 > So ...when Release Candidate 2 becomes available ... we will have to test > extremely quickly ..as GA is scheduled for November 19th. > > Here's a strawman of the QE Plan: > > > > * When Openshift 3.1 Release Candidate 2 is available (I think it is > November 9th ...from looking at the document from the OSE PM call) ...we > need to jump right on this. > * We have a 5-point QE Plan ... but with just 10 days to test ...I don't > think we will make enough progress with automation in that limited > amount of time. > * Let's focus on a manual qualification ... > > > * a visual inspection of the Openshift Admin Console to see if > metrics from Hawk-metrics are appearing > * re-execute the few testcases we have (ie, the curl command ... and > visually inspect the data) > * > If there is an issue detected, we will need fast turnaround time from > Hawk-Metrics developers. Please. * QE Deliverable is a documented > testcase execution run in Polarion, and a QE Sign-off document ...so I can > communicate what was done and the test results. > > > Regards, > > Michael Foley > QE Supervisor, Middleware QE > > ----- Forwarded Message ----- > From: "Clayton Coleman" > To: "aos-devel" > Sent: Thursday, October 29, 2015 12:27:14 PM > Subject: Re: [aos-devel] v1.0.7 is out for download (release candidate 1 for > Origin 1.1) > > FYI > > On Thu, Oct 29, 2015 at 2:26 PM, Clayton Coleman wrote: > > v1.0.7 has been tagged, pushed to the Docker Hub, and uploaded to > > GitHub. The release notes are here > > https://github.com/openshift/origin/releases/tag/v1.0.7 > > > > This is the first release candidate for Origin 1.1. There are a ton > > of new features, a massive amount of new UI, and lots of exciting new > > features. > > > > Some features are still in the process of being merged (Jobs, > > Horizontal Pod Autoscaler, Metrics, Logging) - expect to see them in > > v1.0.8 > > > > Please note that v1beta3 is now no longer supported in the UI, and you > > will need to change your master config to use a different storage > > version if you are still using v1beta3 (old data will continue to > > work). If you hit any issues upgrading your clusters, please let us > > know! > > > From mfoley at redhat.com Mon Nov 2 09:33:48 2015 From: mfoley at redhat.com (Michael Foley) Date: Mon, 2 Nov 2015 09:33:48 -0500 (EST) Subject: [Hawkular-dev] Openshift Origin release candidate 1 is now available .... In-Reply-To: <2033393592.1256542.1446474262167.JavaMail.zimbra@redhat.com> References:

<1068488704.31642424.1446220647971.JavaMail.zimbra@redhat.com> <1980897020.87133257.1446221972775.JavaMail.zimbra@redhat.com> <2033393592.1256542.1446474262167.JavaMail.zimbra@redhat.com> <1585621712.1279220.1446474828181.JavaMail.zimbra@redhat.com> <656748377.1301725.1446475340057.JavaMail.zimbra@redhat.com> Message-ID: <1205778294.1334674.1446476282455.JavaMail.zimbra@redhat.com> Matt Mahoney ... for the Wednesday call ... can you add an agenda item, as follows: -Review and clarify the actual testcases we are performing for OSE 3.1 GA? Thanks, Michael ----- Original Message ----- From: "Matthew Wringe" To: "Michael Foley" Cc: "Matthew Mahoney" , "Viet Nguyen" , "Peter Ruan" , "Thomas Heute" , "John Sanda" , "Stefan Negrea" , hawkular-dev at lists.jboss.org, "Richa Marwaha" Sent: Monday, November 2, 2015 9:42:20 AM Subject: Re: Openshift Origin release candidate 1 is now available .... ----- Original Message ----- > From: "Michael Foley" > To: "Matthew Wringe" > Cc: "Matthew Mahoney" , "Viet Nguyen" , "Peter Ruan" , > "Thomas Heute" , "John Sanda" , "Stefan Negrea" , > hawkular-dev at lists.jboss.org, "Richa Marwaha" > Sent: Monday, November 2, 2015 9:33:48 AM > Subject: Re: Openshift Origin release candidate 1 is now available .... > > Excellent, thank you for clarifying this! > > May I ask: can you please document or otherwise provide information so we can > use OSE 3.1 RC1 ...and sync with the appropriate Hawk-Metrics containers > living outside of the RC1? I agree, this would allow some testing to occur > prior to RC2. > > Follow-up question: is there something that needs to be done for RC2 to > complete the integration of Hawk-Metrics into OSE 3.1 RC2? I am not sure. From my understanding metrics is meant to be installed on top of OpenShift and not something which comes working out of the box. It actually can't be installed out of the box since it relies on externally configured services (such as DNS resolution for the route, and NFS or another storage system). For OSE 3.1 RC2, the only thing I can think of would be to have the docker images built and tagged with a specific version as well as having all the updated documentation. I am not sure what other integration would be needed. > Michael > > ----- Original Message ----- > > From: "Matthew Wringe" > To: "Michael Foley" > Cc: "Matthew Mahoney" , "Viet Nguyen" > , "Peter Ruan" , "Thomas Heute" > , "John Sanda" , "Stefan Negrea" > , hawkular-dev at lists.jboss.org, "Richa Marwaha" > > Sent: Monday, November 2, 2015 9:24:22 AM > Subject: Re: Openshift Origin release candidate 1 is now available .... > > ----- Original Message ----- > > From: "Michael Foley" > > To: "Matthew Mahoney" , "Viet Nguyen" > > , "Matthew Wringe" > > , "Peter Ruan" , "Thomas Heute" > > , "John Sanda" > > , "Stefan Negrea" , > > hawkular-dev at lists.jboss.org > > Cc: "Richa Marwaha" > > Sent: Friday, October 30, 2015 12:19:32 PM > > Subject: Openshift Origin release candidate 1 is now available .... > > > > Hi, > > > > Openshift Origin Release Candidate 1 is now available. > > > > Unfortunately, Metrics is not in this release candidate ...and will be in > > the > > next version 1.0.8, which I presume will be Release Candidate 2. > > From the v1.0.7 release notes, it looks like metrics is already in there, at > least for the console work : > https://github.com/openshift/origin/releases/tag/v1.0.7 > > The only other things would be the containers, but those live outside of the > OpenShift code base (https://github.com/openshift/origin-metrics) so it > makes things a bit tricky in terms of syncing releases. I guess we should > have built images under the openshift docker hub account and tagged them > with the v1.0.7 version. > > Since the Console work is already in v1.0.7, and we have our own containers, > I can't see why we can't start testing with v1.0.7/RC1-1.1 > > > So ...when Release Candidate 2 becomes available ... we will have to test > > extremely quickly ..as GA is scheduled for November 19th. > > > > Here's a strawman of the QE Plan: > > > > > > > > * When Openshift 3.1 Release Candidate 2 is available (I think it is > > November 9th ...from looking at the document from the OSE PM call) ...we > > need to jump right on this. > > * We have a 5-point QE Plan ... but with just 10 days to test ...I don't > > think we will make enough progress with automation in that limited > > amount of time. > > * Let's focus on a manual qualification ... > > > > > > * a visual inspection of the Openshift Admin Console to see if > > metrics from Hawk-metrics are appearing > > * re-execute the few testcases we have (ie, the curl command ... and > > visually inspect the data) > > * > > If there is an issue detected, we will need fast turnaround time from > > Hawk-Metrics developers. Please. * QE Deliverable is a documented > > testcase execution run in Polarion, and a QE Sign-off document ...so I can > > communicate what was done and the test results. > > > > > > Regards, > > > > Michael Foley > > QE Supervisor, Middleware QE > > > > ----- Forwarded Message ----- > > From: "Clayton Coleman" > > To: "aos-devel" > > Sent: Thursday, October 29, 2015 12:27:14 PM > > Subject: Re: [aos-devel] v1.0.7 is out for download (release candidate 1 > > for > > Origin 1.1) > > > > FYI > > > > On Thu, Oct 29, 2015 at 2:26 PM, Clayton Coleman > > wrote: > > > v1.0.7 has been tagged, pushed to the Docker Hub, and uploaded to > > > GitHub. The release notes are here > > > https://github.com/openshift/origin/releases/tag/v1.0.7 > > > > > > This is the first release candidate for Origin 1.1. There are a ton > > > of new features, a massive amount of new UI, and lots of exciting new > > > features. > > > > > > Some features are still in the process of being merged (Jobs, > > > Horizontal Pod Autoscaler, Metrics, Logging) - expect to see them in > > > v1.0.8 > > > > > > Please note that v1beta3 is now no longer supported in the UI, and you > > > will need to change your master config to use a different storage > > > version if you are still using v1beta3 (old data will continue to > > > work). If you hit any issues upgrading your clusters, please let us > > > know! > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151102/71b4eee0/attachment.html From lkrejci at redhat.com Mon Nov 2 08:40:38 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 02 Nov 2015 14:40:38 +0100 Subject: [Hawkular-dev] the name of our hawkular agent/wildfly monitor/feed is confusing - I'm fixing it In-Reply-To: References: <280652770.39402500.1446245912220.JavaMail.zimbra@redhat.com> <1298262702.39404099.1446246136758.JavaMail.zimbra@redhat.com> Message-ID: <24941216.gh8RE9o1ex@localhost.localdomain> So does this mean the "feeds" in inventory should be renamed to "agents", too? I thought that we wanted to move away from using the word agent but frankly I don't care too much. On Monday, November 02, 2015 10:06:13 Thomas Heute wrote: > +1 > > On Sat, Oct 31, 2015 at 12:02 AM, John Mazzitelli wrote: > > As I'm writing code and docs and javadocs all around, I realize that the > > name of our "agent" is utterly confused. We need to fix this or we will > > eventually confuse users/customers. > > > > Right now in code, or comments, or docs, or just in talking, the names of > > the "agent" have been at one time or another: > > > > agent > > wildfly monitor > > wildfly hawkular feed > > wildfly monitor agent > > wildfly extension > > wildfly agent module > > wildfly agent > > etc. etc. etc. > > > > Over the weekend, I'm going to start renaming this so it is consistent > > across the board. > > > > It will be called "Hawkular WildFly Agent" > > > > This will affect maven artifact names moving forward. But we need to fix > > this now, because its confusing ME. I can only imagine the confusion when > > people start to ask "what do you call the hawkular thing that monitors > > Wildfly?" > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev From mfoley at redhat.com Mon Nov 2 11:54:50 2015 From: mfoley at redhat.com (Michael Foley) Date: Mon, 2 Nov 2015 11:54:50 -0500 (EST) Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <14183882.1695783.1446482952447.JavaMail.zimbra@redhat.com> Message-ID: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Hi, Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! Valerii brings a lot of experience as a software engineer, tools developer, and QE Engineer. We are very happy to have him on JON/Hawkular QE! Valerii will be contributing to areas such as: * Legacy JON patch stream * regression testing, * test automation execution * ON_QA bug verification * upgrade testing * testcase migration to Polarion * Hawkular testing * UI automation, * REST API automation, * Performance CI * Hawk-Metrics integration into Openshift * and maintaining the Continuous Delivery Pipleline for Hawkular We have a lot of work to do ...so we are very happy to have Valerii with us. Please be welcoming and helpful. Email = vsorokin at redhat.com . And can be found on IRC as vsorokin. Regards, Michael Foley QE Supervisor, Middleware BU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151102/f1a97f1a/attachment.html From hrupp at redhat.com Mon Nov 2 12:32:06 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 02 Nov 2015 18:32:06 +0100 Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Message-ID: <56D0E13F-29E3-4DEE-B2D9-3AE0BDC416CC@redhat.com> On 2 Nov 2015, at 17:54, Michael Foley wrote: > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! Welcome Valerii ! Where are you located? From mazz at redhat.com Mon Nov 2 13:24:01 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 2 Nov 2015 13:24:01 -0500 (EST) Subject: [Hawkular-dev] the name of our hawkular agent/wildfly monitor/feed is confusing - I'm fixing it In-Reply-To: <24941216.gh8RE9o1ex@localhost.localdomain> References: <280652770.39402500.1446245912220.JavaMail.zimbra@redhat.com> <1298262702.39404099.1446246136758.JavaMail.zimbra@redhat.com> <24941216.gh8RE9o1ex@localhost.localdomain> Message-ID: <803455796.1133188.1446488641927.JavaMail.zimbra@redhat.com> We still call things "feeds". To me, feeds are a superset - they are ANYTHING that are clients to Hawkular (shell scripts, python apps, cron jobs) and this includes more fully-featured agents. The Hawkular WildFly Agent is something that runs inside of Wildfly as an extension subsystem. Its a type of feed. We could have called it Hawkular WildFly Feed, but frankly, I think that would have made people look at it crosseyed too. People know what a management agent is; "feed" not so much. So, an agent is a type of feed - its a more fully featured hawkular feed. That's my story and I'm sticking to it. :) ----- Original Message ----- > So does this mean the "feeds" in inventory should be renamed to "agents", > too? > > I thought that we wanted to move away from using the word agent but frankly I > don't care too much. > > On Monday, November 02, 2015 10:06:13 Thomas Heute wrote: > > +1 > > > > On Sat, Oct 31, 2015 at 12:02 AM, John Mazzitelli wrote: > > > As I'm writing code and docs and javadocs all around, I realize that the > > > name of our "agent" is utterly confused. We need to fix this or we will > > > eventually confuse users/customers. > > > > > > Right now in code, or comments, or docs, or just in talking, the names of > > > the "agent" have been at one time or another: > > > > > > agent > > > wildfly monitor > > > wildfly hawkular feed > > > wildfly monitor agent > > > wildfly extension > > > wildfly agent module > > > wildfly agent > > > etc. etc. etc. > > > > > > Over the weekend, I'm going to start renaming this so it is consistent > > > across the board. > > > > > > It will be called "Hawkular WildFly Agent" > > > > > > This will affect maven artifact names moving forward. But we need to fix > > > this now, because its confusing ME. I can only imagine the confusion when > > > people start to ask "what do you call the hawkular thing that monitors > > > Wildfly?" > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Mon Nov 2 17:28:58 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 2 Nov 2015 17:28:58 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics 0.9.0 - Release & Beyond In-Reply-To: <725703957.44011096.1444757119588.JavaMail.zimbra@redhat.com> Message-ID: <1444190753.1752564.1446503338035.JavaMail.zimbra@redhat.com> Hello Everybody, I am happy to announce that release 0.9.0 of Hawkular Metrics was published on Friday. This is a regular schedule release anchored by integration enhancements for Hawkular project via Hawkular Bus. Here is a list of major changes in this release: 1) Hawkular integration * When deployed within Hawkular, the project now publishes metrics insertion events on the Hawkular Bus for consumption by interested parties (HWKMETRICS-83, HWKMETRICS-10) * Added support for publishing large amounts of events (HWKMETRICS-315) 2) Improved tag query * It is now possible to query metrics by tag via respective metric type end-points: /gauges, /counters, /availability (HWKMETRICS-317) 3) InfluxDB compatibility * Added millisecond unit support (HWKMETRICS-32) Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.9.0 JBoss Nexus Maven artifacts: http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/ Jira release tracker: https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12328458 Hawkular Metrics Clients * Ruby: https://github.com/hawkular/hawkular-client-ruby * Python: https://github.com/hawkular/hawkular-client-python * Go: https://github.com/hawkular/hawkular-client-go Hawkular Metrics 0.10.0 & Beyond: 1) Continuous agggregation - this has been a long term project goal and we are getting closer with refining the requirements and infrastructure 2) Improved docker and kubernetes support - this is a long term goal for the project 3) Improved tag support - to add bulk tag operations and tag queries 4) Improved aggregate downsampling for multiple metrics - the project has now a base with recently added stacking and uniform support; the goal is to expand the aggregation methods 5) Improved integration of Hawkular Metrics and Hawkular Alerts - this will be added the our long term development goals with the initial integration phase part of the release scheduled at the end of November. Keep and eye on both projects and the mailing list for more announcements. A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer From mfoley at redhat.com Mon Nov 2 18:39:29 2015 From: mfoley at redhat.com (Michael Foley) Date: Mon, 2 Nov 2015 18:39:29 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics 0.9.0 - Release & Beyond In-Reply-To: <1444190753.1752564.1446503338035.JavaMail.zimbra@redhat.com> References: <1444190753.1752564.1446503338035.JavaMail.zimbra@redhat.com> Message-ID: <311888600.2362899.1446507569708.JavaMail.zimbra@redhat.com> Hi, This is great news! Congratulations all! So since Hawk-Metrics is consumed by Openshift 3.1 ....and Openshift 3.1 is 17 days from GA ..... please help me understand this release a bit more. I am curious now how this Hawk-Metrics release stream relates to the Openshift stream. Is it? Hawk-Metrics Version Openshift Version 0.8.0 3.1 0.9.0 3.1.1?? Or ... is there no direct intersection of the Hawk-Metrics release stream and the Openshift stream ... because there exists the Openshift Origin Metrics project ? [ https://github.com/openshift/origin-metrics ] The reason I ask is the use-case around patching Hawk-Metrics for Openshift 3.1. Visualize this perhaps unlikely scenario, ...a bug is found in Hawk-Metrics in Openshift 3.1 that we need to address. * there is a bug or defect in Hawk-Metrics (presumably version 0.8.0?) as it exists in Openshift Origin Metrics and Openshift 3.1 GA. * we need to supply a fix, ASAP * is this bug fix coming from Origin Metrics? Hawk-Metrics version 0.8.0? Hawk-Metrics 0.9.0? * what version of Hawk-Metrics would development put the fix in? What version of Hawk-Metrics would QE use to perform the qualification of this fix? * is what is in Openshift Origin Metrics ... is that code Hawk-Metrics 0.8.0 final? Or was that something else? Is that code in Orign Metrics ...the integration point with OSE... updated when you update Hawk-Metrics? I just want to understand this a bit more ...how these projects are coupled ... as the answer is important to the continued support and new feature development of metrics as it relates to the 1 consumer of Hawk-Metrics ...OSE 3.1. More generally, I would like to understand how this stream of Hawk-Metric releases is related to the OSE stream ... what the plan is there ...particularly as it relates to our ability to deliver qualified fixes to OSE in a timely manner. Second topic ... One thing that has been incredibly useful on Hawkular releases is the developer demo (thank you, thank you, thank you). The developer demo has had many benefits including: * it shows the new features * transparency * it helps QE engage * it helps other teams who may use this feature, engage As a suggestion, is it possible you could consider performing a developer demo for each release? I think it would be of great value to those consuming the release, or who may want to consume the release. I would imagine the consumers of Hawk-Metrics would love to see the new features. I know ...as a QE ... that seeing the new features is invaluable first step in testing them. Third, on a more pragmatic note ... it would be great if ... on each release ...... we could document or share information regarding: * No performance regressions. We now have Performance CI in place on Hawk-Metrics ...and I think it would be of great value to show documented evidence that there is no performance regression in the release. * OSE Integration ... that this release is compatible with OSE ...and does not cause a major breakage. Again ... congratulations on yet another release! Well done! Regards, Michael Foley QE Supervisor, Middleware BU ----- Original Message ----- From: "Stefan Negrea" To: "Discussions around Hawkular development" Sent: Monday, November 2, 2015 5:28:58 PM Subject: Hawkular Metrics 0.9.0 - Release & Beyond Hello Everybody, I am happy to announce that release 0.9.0 of Hawkular Metrics was published on Friday. This is a regular schedule release anchored by integration enhancements for Hawkular project via Hawkular Bus. Here is a list of major changes in this release: 1) Hawkular integration * When deployed within Hawkular, the project now publishes metrics insertion events on the Hawkular Bus for consumption by interested parties (HWKMETRICS-83, HWKMETRICS-10) * Added support for publishing large amounts of events (HWKMETRICS-315) 2) Improved tag query * It is now possible to query metrics by tag via respective metric type end-points: /gauges, /counters, /availability (HWKMETRICS-317) 3) InfluxDB compatibility * Added millisecond unit support (HWKMETRICS-32) Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.9.0 JBoss Nexus Maven artifacts: http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/ Jira release tracker: https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12328458 Hawkular Metrics Clients * Ruby: https://github.com/hawkular/hawkular-client-ruby * Python: https://github.com/hawkular/hawkular-client-python * Go: https://github.com/hawkular/hawkular-client-go Hawkular Metrics 0.10.0 & Beyond: 1) Continuous agggregation - this has been a long term project goal and we are getting closer with refining the requirements and infrastructure 2) Improved docker and kubernetes support - this is a long term goal for the project 3) Improved tag support - to add bulk tag operations and tag queries 4) Improved aggregate downsampling for multiple metrics - the project has now a base with recently added stacking and uniform support; the goal is to expand the aggregation methods 5) Improved integration of Hawkular Metrics and Hawkular Alerts - this will be added the our long term development goals with the initial integration phase part of the release scheduled at the end of November. Keep and eye on both projects and the mailing list for more announcements. A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151102/0ab9fd20/attachment.html From theute at redhat.com Tue Nov 3 03:00:26 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 3 Nov 2015 09:00:26 +0100 Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <56D0E13F-29E3-4DEE-B2D9-3AE0BDC416CC@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> <56D0E13F-29E3-4DEE-B2D9-3AE0BDC416CC@redhat.com> Message-ID: Welcome Valerii ! On Mon, Nov 2, 2015 at 6:32 PM, Heiko W.Rupp wrote: > On 2 Nov 2015, at 17:54, Michael Foley wrote: > > > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! > > Welcome Valerii ! > > Where are you located? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151103/7b3c2985/attachment.html From gbrown at redhat.com Tue Nov 3 03:02:08 2015 From: gbrown at redhat.com (Gary Brown) Date: Tue, 3 Nov 2015 03:02:08 -0500 (EST) Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Message-ID: <1523932660.1322728.1446537728050.JavaMail.zimbra@redhat.com> Welcome to the team Valerii. Regards Gary ----- Original Message ----- > Hi, > > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! > > Valerii brings a lot of experience as a software engineer, tools developer, > and QE Engineer. We are very happy to have him on JON/Hawkular QE! > > Valerii will be contributing to areas such as: > > > > * Legacy JON patch stream > > > * regression testing, > * test automation execution > * ON_QA bug verification > * upgrade testing > * testcase migration to Polarion > * > Hawkular testing > > * UI automation, > * REST API automation, > * Performance CI > * Hawk-Metrics integration into Openshift > * and maintaining the Continuous Delivery Pipleline for Hawkular > > We have a lot of work to do ...so we are very happy to have Valerii with us. > > Please be welcoming and helpful. Email = vsorokin at redhat.com . And can be > found on IRC as vsorokin. > > Regards, > > Michael Foley > QE Supervisor, Middleware BU > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Tue Nov 3 03:20:14 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 3 Nov 2015 09:20:14 +0100 Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Message-ID: <56386E3E.9030204@redhat.com> Welcome! On 11/02/2015 05:54 PM, Michael Foley wrote: > Hi, > > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! > > Valerii brings a lot of experience as a software engineer, tools > developer, and QE Engineer. We are very happy to have him on > JON/Hawkular QE! > > Valerii will be contributing to areas such as: > > * Legacy JON patch stream > o regression testing, > o test automation execution > o ON_QA bug verification > o upgrade testing > o testcase migration to Polarion > * Hawkular testing > o UI automation, > o REST API automation, > o Performance CI > o Hawk-Metrics integration into Openshift > o and maintaining the Continuous Delivery Pipleline for Hawkular > > > We have a lot of work to do ...so we are very happy to have Valerii with > us. > > Please be welcoming and helpful. Email = vsorokin at redhat.com > . And can be found on IRC as vsorokin. > > Regards, > > Michael Foley > QE Supervisor, Middleware BU > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Tue Nov 3 03:48:56 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 3 Nov 2015 03:48:56 -0500 (EST) Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Message-ID: <566497201.1424561.1446540536891.JavaMail.zimbra@redhat.com> Welcome Valerii ! ----- Original Message ----- > From: "Michael Foley" > To: hawkular-dev at lists.jboss.org, "ON Team" , "jon-qa-list" > Cc: "Valerii Sorokin" > Sent: Monday, November 2, 2015 5:54:50 PM > Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! > > Hi, > > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! > > Valerii brings a lot of experience as a software engineer, tools developer, > and QE Engineer. We are very happy to have him on JON/Hawkular QE! > > Valerii will be contributing to areas such as: > > > > * Legacy JON patch stream > > > * regression testing, > * test automation execution > * ON_QA bug verification > * upgrade testing > * testcase migration to Polarion > * > Hawkular testing > > * UI automation, > * REST API automation, > * Performance CI > * Hawk-Metrics integration into Openshift > * and maintaining the Continuous Delivery Pipleline for Hawkular > > We have a lot of work to do ...so we are very happy to have Valerii with us. > > Please be welcoming and helpful. Email = vsorokin at redhat.com . And can be > found on IRC as vsorokin. > > Regards, > > Michael Foley > QE Supervisor, Middleware BU > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Tue Nov 3 07:29:03 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 3 Nov 2015 13:29:03 +0100 Subject: [Hawkular-dev] Accounts on Cassandra In-Reply-To: <562F5B30.5030302@redhat.com> References: <562F5B30.5030302@redhat.com> Message-ID: <5638A88F.4020602@redhat.com> Team, On 10/27/2015 12:08 PM, Juraci Paix?o Kr?hling wrote: > Cassandra changes will be applied to 1.1.0.Final. All changes from > 1.1.0.Final and on will be backported to 1.0.x *up to the next MS*. If > everything goes right for the next MS, I'll stop maintaining 1.0.x. I just submitted PRs for the following components: Alerts https://github.com/hawkular/hawkular-alerts/pull/117 BTM https://github.com/hawkular/hawkular-btm/pull/221 Command Gateway https://github.com/hawkular/hawkular-command-gateway/pull/29 Inventory https://github.com/hawkular/hawkular-inventory/pull/188 I'd please ask you to review and merge them today or, at most, tomorrow, as I'll be out from Friday for about a week. After that, we'll be close to the next MS date, so, I'd rather have this feature fully merged soon, so that we have enough time for testing it. Once those are merged, a PR for Agent will be sent, with updated versions of Command Gateway and Accounts. After that, a PR will be sent to Hawkular with the src-deps tag for the merged PRs. Please, let me know if your component has a "blocker" that would cause failures on Hawkular if its current master + PR is used there. - Juca. From mithomps at redhat.com Tue Nov 3 09:50:40 2015 From: mithomps at redhat.com (mike thompson) Date: Tue, 3 Nov 2015 06:50:40 -0800 Subject: [Hawkular-dev] Welcome Valerii Sorokin to JON/Hawkular QE! In-Reply-To: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> References: <211088827.1712889.1446483290723.JavaMail.zimbra@redhat.com> Message-ID: <887D4F54-29EF-4B45-993C-AB2C7413C9FC@redhat.com> Welcome Aboard Valerii! ? Mike > On 2 Nov 2015, at 08:54, Michael Foley wrote: > > Hi, > > Please join me in welcoming Valerii Sorokin to JON/Hawkular QE! > > Valerii brings a lot of experience as a software engineer, tools developer, and QE Engineer. We are very happy to have him on JON/Hawkular QE! > > Valerii will be contributing to areas such as: > > Legacy JON patch stream > regression testing, > test automation execution > ON_QA bug verification > upgrade testing > testcase migration to Polarion > Hawkular testing > UI automation, > REST API automation, > Performance CI > Hawk-Metrics integration into Openshift > and maintaining the Continuous Delivery Pipleline for Hawkular > > We have a lot of work to do ...so we are very happy to have Valerii with us. > > Please be welcoming and helpful. Email = vsorokin at redhat.com . And can be found on IRC as vsorokin. > > Regards, > > Michael Foley > QE Supervisor, Middleware BU > > _______________________________________________ > 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/20151103/2a0db1b0/attachment.html From mmahoney at redhat.com Tue Nov 3 14:55:58 2015 From: mmahoney at redhat.com (Matthew Mahoney) Date: Tue, 3 Nov 2015 14:55:58 -0500 (EST) Subject: [Hawkular-dev] Demo.hawkular.org Is Available In-Reply-To: <1559612519.2599740.1446580433245.JavaMail.zimbra@redhat.com> Message-ID: <1810440359.2601077.1446580558919.JavaMail.zimbra@redhat.com> FYI: While LOTE (livingontheedge.hawkular.org) continues to be down due to TravisCI build issues, http://demo.hawkular.org/ is available and is deployed with Hawkular Snapshot-6 Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151103/b8063066/attachment.html From jpkroehling at redhat.com Wed Nov 4 05:13:19 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 4 Nov 2015 11:13:19 +0100 Subject: [Hawkular-dev] Accounts 1.1.0.Final released Message-ID: <5639DA3F.1030907@redhat.com> Team, Alerts and BTM have requested a release of Accounts with the latest changes, so, here it is: Accounts 1.1.0.Final is now released. The bump in the version reflects the move of Accounts from using an RDBMS to Cassandra. I expect it to still have a few bugs here and there, so, there might be a 1.1.1.Final version before the next milestone. - Juca. From lkrejci at redhat.com Wed Nov 4 08:56:54 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Wed, 04 Nov 2015 14:56:54 +0100 Subject: [Hawkular-dev] the name of our hawkular agent/wildfly monitor/feed is confusing - I'm fixing it In-Reply-To: <803455796.1133188.1446488641927.JavaMail.zimbra@redhat.com> References: <280652770.39402500.1446245912220.JavaMail.zimbra@redhat.com> <24941216.gh8RE9o1ex@localhost.localdomain> <803455796.1133188.1446488641927.JavaMail.zimbra@redhat.com> Message-ID: <1642128.DczFBBomse@localhost.localdomain> +1 On Monday, November 02, 2015 13:24:01 John Mazzitelli wrote: > We still call things "feeds". To me, feeds are a superset - they are > ANYTHING that are clients to Hawkular (shell scripts, python apps, cron > jobs) and this includes more fully-featured agents. > > The Hawkular WildFly Agent is something that runs inside of Wildfly as an > extension subsystem. Its a type of feed. We could have called it Hawkular > WildFly Feed, but frankly, I think that would have made people look at it > crosseyed too. People know what a management agent is; "feed" not so much. > > So, an agent is a type of feed - its a more fully featured hawkular feed. > > That's my story and I'm sticking to it. :) > > ----- Original Message ----- > > > So does this mean the "feeds" in inventory should be renamed to "agents", > > too? > > > > I thought that we wanted to move away from using the word agent but > > frankly I don't care too much. > > > > On Monday, November 02, 2015 10:06:13 Thomas Heute wrote: > > > +1 > > > > > > On Sat, Oct 31, 2015 at 12:02 AM, John Mazzitelli wrote: > > > > As I'm writing code and docs and javadocs all around, I realize that > > > > the > > > > name of our "agent" is utterly confused. We need to fix this or we > > > > will > > > > eventually confuse users/customers. > > > > > > > > Right now in code, or comments, or docs, or just in talking, the names > > > > of > > > > the "agent" have been at one time or another: > > > > > > > > agent > > > > wildfly monitor > > > > wildfly hawkular feed > > > > wildfly monitor agent > > > > wildfly extension > > > > wildfly agent module > > > > wildfly agent > > > > etc. etc. etc. > > > > > > > > Over the weekend, I'm going to start renaming this so it is consistent > > > > across the board. > > > > > > > > It will be called "Hawkular WildFly Agent" > > > > > > > > This will affect maven artifact names moving forward. But we need to > > > > fix > > > > this now, because its confusing ME. I can only imagine the confusion > > > > when > > > > people start to ask "what do you call the hawkular thing that monitors > > > > Wildfly?" > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.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 mfoley at redhat.com Wed Nov 4 14:54:38 2015 From: mfoley at redhat.com (Michael Foley) Date: Wed, 4 Nov 2015 14:54:38 -0500 (EST) Subject: [Hawkular-dev] Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Message-ID: <1637419441.6117032.1446666878577.JavaMail.zimbra@redhat.com> A single instance of the following meeting has been modified: Subject: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Organizer: "Michael Foley" Location: Bluejeans http://www.bluejeans.com/mfoley51 Time: Wednesday, November 4, 2015, 3:00:00 PM - 3:30:00 PM GMT -05:00 US/Canada Eastern Required: pruan at redhat.com; mmahoney at redhat.com; vnguyen at redhat.com; snegrea at redhat.com; jsanda at redhat.com; mwringe at redhat.com Optional: jon-qa-list at redhat.com; jboss-on-team at redhat.com; hawkular-dev at lists.jboss.org *~*~*~*~*~*~*~*~*~* Hi, Let's have a discussion and planning session on testing Openshift & Hawkular Integration! Let's use this etherpad to coordinate the discussion -->> http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning 5 Point Plan for Openshift 3.1 GA * Unit tests .... owned by Hawk-Metrics developers * Integration tests ... owned by Hawk-Metrics developers and Hawk-Metrics QE * Performance CI on Hawk-Metrics (this one is actually new and was not discussed on Wednesday , but I now see it makes sense) * Functional Integration tests on Hawk-Metrics latest + Openshift Origin latest * Funtional/UI .... Cucumber/Ruby tests ...owned by Openshift QE * Functional/Rest ... Cucumber/Ruby tests ... owned by Openshift QE * Performance & Scalability .... owned by Openshift QE Regards, Michael Foley QE Supervisor, Middleware BU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151104/011243b2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 7714 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151104/011243b2/attachment-0001.bin From tsegismo at redhat.com Wed Nov 4 15:01:42 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 4 Nov 2015 21:01:42 +0100 Subject: [Hawkular-dev] the name of our hawkular agent/wildfly monitor/feed is confusing - I'm fixing it In-Reply-To: <803455796.1133188.1446488641927.JavaMail.zimbra@redhat.com> References: <280652770.39402500.1446245912220.JavaMail.zimbra@redhat.com> <1298262702.39404099.1446246136758.JavaMail.zimbra@redhat.com> <24941216.gh8RE9o1ex@localhost.localdomain> <803455796.1133188.1446488641927.JavaMail.zimbra@redhat.com> Message-ID: <563A6426.4080006@redhat.com> In case it was not obvious, a feed could also be the application itself, or an embedded agent. Le 02/11/2015 19:24, John Mazzitelli a ?crit : > We still call things "feeds". To me, feeds are a superset - they are ANYTHING that are clients to Hawkular (shell scripts, python apps, cron jobs) and this includes more fully-featured agents. > > The Hawkular WildFly Agent is something that runs inside of Wildfly as an extension subsystem. Its a type of feed. We could have called it Hawkular WildFly Feed, but frankly, I think that would have made people look at it crosseyed too. People know what a management agent is; "feed" not so much. > > So, an agent is a type of feed - its a more fully featured hawkular feed. > > That's my story and I'm sticking to it. :) > > ----- Original Message ----- >> So does this mean the "feeds" in inventory should be renamed to "agents", >> too? >> >> I thought that we wanted to move away from using the word agent but frankly I >> don't care too much. >> >> On Monday, November 02, 2015 10:06:13 Thomas Heute wrote: >>> +1 >>> >>> On Sat, Oct 31, 2015 at 12:02 AM, John Mazzitelli wrote: >>>> As I'm writing code and docs and javadocs all around, I realize that the >>>> name of our "agent" is utterly confused. We need to fix this or we will >>>> eventually confuse users/customers. >>>> >>>> Right now in code, or comments, or docs, or just in talking, the names of >>>> the "agent" have been at one time or another: >>>> >>>> agent >>>> wildfly monitor >>>> wildfly hawkular feed >>>> wildfly monitor agent >>>> wildfly extension >>>> wildfly agent module >>>> wildfly agent >>>> etc. etc. etc. >>>> >>>> Over the weekend, I'm going to start renaming this so it is consistent >>>> across the board. >>>> >>>> It will be called "Hawkular WildFly Agent" >>>> >>>> This will affect maven artifact names moving forward. But we need to fix >>>> this now, because its confusing ME. I can only imagine the confusion when >>>> people start to ask "what do you call the hawkular thing that monitors >>>> Wildfly?" >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Thu Nov 5 05:43:43 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 5 Nov 2015 11:43:43 +0100 Subject: [Hawkular-dev] Accounts versions Message-ID: <563B32DF.7030604@redhat.com> Team, TL;DR: use 1.1.1.Final for the next MS. If it breaks, use 1.0.18.Final. I'll be out for about a week and unfortunately, I was not able yet to get the PRs updating Accounts to the Cassandra version into all projects. Because of that, I decided to release 1.0.x, in case Accounts breaks something that can't be worked around during my absence. If that's the case, then please use the following version: 1.0.18.Final . It's the non-Cassandra version and should be almost the same version as the last MS. I also fixed a bug in the way that Cassandra session is handled for the secret store, and did a new release: 1.1.1.Final. This is the one that should go into the next MS (for now, at least). As this does not affect the dependent modules, I'll not be sending PRs around this time. I hope to be able to get the remaining PRs merged today. - Juca. From mfoley at redhat.com Thu Nov 5 10:40:03 2015 From: mfoley at redhat.com (Michael Foley) Date: Thu, 5 Nov 2015 10:40:03 -0500 (EST) Subject: [Hawkular-dev] Hawk-Metrics Performance & Scalability Message-ID: <667498852.7267499.1446738003491.JavaMail.zimbra@redhat.com> The following is a new meeting request: Subject: Hawk-Metrics Performance & Scalability Organizer: "Michael Foley" Location: http://www.bluejeans.com/mfoley51 Time: 9:30:00 AM - 10:00:00 AM GMT -05:00 US/Canada Eastern Recurrence : Every Tuesday No end date Effective Nov 10, 2015 Required: fbrychta at redhat.com; snegrea at redhat.com; mmahoney at redhat.com; vnguyen at redhat.com; hrupp at redhat.com Optional: hawkular-dev at lists.jboss.org *~*~*~*~*~*~*~*~*~* Hi, I would like to have a quick 30 minute weekly call focusing on Hawk-Metrics performance. The agenda is flexible, but let's start with this: Goal: Detect Performance Problems Prior to OSE Integration * discuss/resolve performance regressions in pull requests, resetting baselines, * discuss linear scalability of Hawk-Metrics * define the test design or test activities to ascertain answers to this question Note: I can change the time to something else that works for everyone who is interested in this agenda. Regards, Michael Foley QE Supervisor, Middleware BU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151105/079e7713/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4418 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151105/079e7713/attachment.bin From mfoley at redhat.com Thu Nov 5 10:43:26 2015 From: mfoley at redhat.com (Michael Foley) Date: Thu, 5 Nov 2015 10:43:26 -0500 (EST) Subject: [Hawkular-dev] Cancelled: Hawk-Metrics Performance & Scalability Message-ID: <1019453503.7277991.1446738206216.JavaMail.zimbra@redhat.com> You have been removed from the attendee list by the organizer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151105/2a171c2c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1178 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151105/2a171c2c/attachment.bin From snegrea at redhat.com Thu Nov 5 18:01:54 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Thu, 5 Nov 2015 18:01:54 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <972601148.5877334.1446763815868.JavaMail.zimbra@redhat.com> Message-ID: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> Hello Everybody, I want to open the discussion around the design and implementation for the Hawkular Metrics and Hawkular Alerts integration. I created a document with the scope and objectives for Phase 0. It is called Phase 0 because this should be a proof of concept of the type of functionality to be delivered in the future with a scope of getting early feedback on our ideas. The goal is to deliver this phase in Hawkular Metrics 0.10.0, and have something implemented in the next 2 weeks. I've had discussions with developers on both teams and updated the document based on those discussions. My goal was to first refine the ideas to a coherent state before publishing a first draft. I am now opening the document and the discussion to the entire Hawkular community. The one point where we need additional help is highlighted in red with a bigger font in the document. Please feel free to comment in the document, reply to this email, or contact me (stefan_n) on #hawkular on freenode. If you do not have access to the document please email me privately and will grant access. Any and all the feedback is more than welcomed. Link: https://docs.google.com/document/d/1PwOGGysO0ppc2VPl80i4ye9pZI-Ugd4gObzQ5GFid4Y Thank you, Stefan Negrea Software Engineer From mazz at redhat.com Thu Nov 5 19:40:29 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 5 Nov 2015 19:40:29 -0500 (EST) Subject: [Hawkular-dev] nest circular dep In-Reply-To: <964116682.3992383.1446770405848.JavaMail.zimbra@redhat.com> Message-ID: <1254219724.3992573.1446770429512.JavaMail.zimbra@redhat.com> Well, I found the nest dependency circularity that I was sure was around :) hawkular-agent has itests that builds a distro using nest. But you can't get the nest until you build kettle. And you can't build kettle until you build the agent. And 'round and 'round we go. We need to pull the nest out of kettle and put it somewhere else. For now, I'm just going to have a dependency on an older bus version to pick up the nest. From mazz at redhat.com Thu Nov 5 20:14:32 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 5 Nov 2015 20:14:32 -0500 (EST) Subject: [Hawkular-dev] -SRC- deps and releases In-Reply-To: <666666438.4003352.1446772341366.JavaMail.zimbra@redhat.com> Message-ID: <880035138.4003592.1446772472574.JavaMail.zimbra@redhat.com> I need to release agent prior to this big refactoring going in master. So I'm trying to get that done tonight. Also, Tristan is doing work with the agent and needs to pull it in but getting errors. https://gist.github.com/tristantarrant/f20de03390acc15d663b Notice the failure to resolve the -SRC- dependency: "failed to resolve artifact org.hawkular.cmdgw:hawkular-command-gateway-api:jar:0.10.2.Final-SRC-revision-06aa579bd1b9658cf82af6cfedef6365ecf03e8c: Could not find artifact org.hawkular.cmdgw:hawkular-command-gateway-api:jar:0.10.2.Final-SRC-revision-06aa579bd1b9658cf82af6cfedef6365ecf03e8c in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public-jboss/)" I actually got rid of that dep, however, I need inventory 0.8.0.Final and that isn't released yet. So my agent only has a -SRC- dep on it. But if I release agent with a -SRC- dep in it, will that be consumable by someone outside of hawkular? If this is going to be a problem, is it possible to get an inventory release out ASAP so I can get agent released without -SRC- dep? From tsegismo at redhat.com Fri Nov 6 03:17:59 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 6 Nov 2015 09:17:59 +0100 Subject: [Hawkular-dev] Cassandra with "almost" ElasticSearch features Message-ID: <563C6237.7010202@redhat.com> Apple open sources this: https://twitter.com/doanduyhai/status/662392241865015297 From hrupp at redhat.com Mon Nov 9 02:05:00 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 08:05:00 +0100 Subject: [Hawkular-dev] [Alert] parameters to resolve Message-ID: <018D47DB-05B3-4214-B064-56BDB3060317@redhat.com> Hey, according to http://www.hawkular.org/docs/rest/rest-alerts.html#_alert_handling I do not need to provide query params to resolve an alert. When I do method: put uri: http://jdoe:password at localhost:8080/hawkular/alerts/resolve/28026b36-8fe4-4332-84c8-524e173a68bf-snert~Local_jvm_garba-1446977734134 I get the following error back: Hawkular::HawkularException: Internal error: java.lang.IllegalArgumentException: Note must have non-null user and text ./lib/Hawkular.rb:141:in `handle_fault' ./lib/Hawkular.rb:62:in `rescue in http_put' ./lib/Hawkular.rb:56:in `http_put' What am I doing wrong? From hrupp at redhat.com Mon Nov 9 02:09:00 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 08:09:00 +0100 Subject: [Hawkular-dev] [Alerts] trigger comparator in one go? Message-ID: <6CEAFCC2-18AE-4879-9C16-BF93502D1099@redhat.com> Hey, when I call GET /triggers or GET /triggers/{id} I get a hash with basically this information: http://www.hawkular.org/docs/rest/rest-alerts.html#Trigger Inside the context I have the resource it triggers on, the metric it triggers on, the triggerType, but not the comparator or the value to compare. Looks like I need to get /triggers/{id}/conditions and also /dampenings separately to get those values Is there an api call / parameter, where I can get all data for a single trigger including dampening, conditions and so on ? From hrupp at redhat.com Mon Nov 9 02:10:00 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 08:10:00 +0100 Subject: [Hawkular-dev] REST-api and hyperlinks Message-ID: <2D920EBE-2137-42CF-B93C-1432DE4E1BE1@redhat.com> Hey, one cool trait of RESTful apis, which we all use every day hundreds of times is the hyperlinking of data - we click on links in the web browser. I think that would be pretty good for our apis as well. To take alerts as an example (see my other mail) I can go like GET /triggers/{id} to get a trigger with some data. Now to learn about the conditions I need to browse to the docs to potentially find out that I can get them at /triggers/{id}/conditions It would be good if we would add for each resource a "Links" section like: links: [ { rel='dampening' href=http://blabla/hawkular/alerts/triggers/{id}/dampening }, { rel='conditions' href=http://blabla/hawkular/alerts/triggers/{id}/conditions } ] This way it is relatively easy to follow those for humans, but also machines. From hrupp at redhat.com Mon Nov 9 02:11:00 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 08:11:00 +0100 Subject: [Hawkular-dev] Inventory model change? Message-ID: Hey, I saw this on irc: [2015-11-06T21:19:27+0100] I was going to update kettle, but that's broken if pulling in the latest agent and inventory. looks like we'll need to get the UI to know that feeds are no longer under environment We have clients that use subsystems like inventory today - internal like pinger and UI and also external ones. If we make such changes we need to communicate them here so that everyone knows about them. And not only what has changed, but also something like a list of previous->new and when it applies (e.g. is in inv-0.8.15 and will be in Hawkular-1.0.7 With our rest apis, we should perhaps even transparently redirect requests to give old clients time to transition to the new model / api / endpoints. From lponce at redhat.com Mon Nov 9 03:12:02 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 9 Nov 2015 03:12:02 -0500 (EST) Subject: [Hawkular-dev] [Alert] parameters to resolve In-Reply-To: <018D47DB-05B3-4214-B064-56BDB3060317@redhat.com> References: <018D47DB-05B3-4214-B064-56BDB3060317@redhat.com> Message-ID: <1348501014.5406714.1447056722417.JavaMail.zimbra@redhat.com> It seems some missing update in the documentation. Let me check and respond later. Thanks for bringing it. As a temporal workaround, meanwhile I take a look on it, there are several tests that can be used to compare with your code: https://github.com/hawkular/hawkular-ui-services/blob/master/src/rest/hawkRest-alert-provider.spec.rest.js These are used for ui-services, but can be used as an example of how to interact with the API. Lucas ----- Original Message ----- > From: "Heiko W.Rupp" > To: "Discussions around Hawkular development" > Sent: Monday, November 9, 2015 8:05:00 AM > Subject: [Hawkular-dev] [Alert] parameters to resolve > > Hey, > > according to > http://www.hawkular.org/docs/rest/rest-alerts.html#_alert_handling I do > not > need to provide query params to resolve an alert. > > When I do > method: put > uri: > http://jdoe:password at localhost:8080/hawkular/alerts/resolve/28026b36-8fe4-4332-84c8-524e173a68bf-snert~Local_jvm_garba-1446977734134 > > I get the following error back: > > Hawkular::HawkularException: Internal error: > java.lang.IllegalArgumentException: Note must have non-null user and > text > ./lib/Hawkular.rb:141:in `handle_fault' > ./lib/Hawkular.rb:62:in `rescue in http_put' > ./lib/Hawkular.rb:56:in `http_put' > > What am I doing wrong? > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Mon Nov 9 03:16:49 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 9 Nov 2015 03:16:49 -0500 (EST) Subject: [Hawkular-dev] [Alerts] trigger comparator in one go? In-Reply-To: <6CEAFCC2-18AE-4879-9C16-BF93502D1099@redhat.com> References: <6CEAFCC2-18AE-4879-9C16-BF93502D1099@redhat.com> Message-ID: <538475051.5408020.1447057009148.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Heiko W.Rupp" > To: "Discussions around Hawkular development" > Sent: Monday, November 9, 2015 8:09:00 AM > Subject: [Hawkular-dev] [Alerts] trigger comparator in one go? > > Hey, > > when I call GET /triggers or GET /triggers/{id} > > I get a hash with basically this information: > > http://www.hawkular.org/docs/rest/rest-alerts.html#Trigger > > Inside the context I have the resource it triggers on, the metric > it triggers on, the triggerType, but not the comparator or the value to > compare. > > Looks like I need to get /triggers/{id}/conditions and also /dampenings > separately to get those values Correct This is done by design as Trigger : Conditions can have a 1:N relation, so in most cases get all information is not needed. > > Is there an api call / parameter, where I can get all data for a single > trigger including dampening, conditions and so on ? Not yet. We have discussed that we might have use cases like this and it could be interesting to have one. Lucas > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Mon Nov 9 03:49:21 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 9 Nov 2015 03:49:21 -0500 (EST) Subject: [Hawkular-dev] [Alert] parameters to resolve In-Reply-To: <1348501014.5406714.1447056722417.JavaMail.zimbra@redhat.com> References: <018D47DB-05B3-4214-B064-56BDB3060317@redhat.com> <1348501014.5406714.1447056722417.JavaMail.zimbra@redhat.com> Message-ID: <1246567193.5425646.1447058961953.JavaMail.zimbra@redhat.com> Hi Heiko, It seems a small bug in the empty verification parameters. Please, can you send me more details of your test and version used ( I guess Alpha6 ). Off-list or just in a JIRA and I will verify if this is fixed in master of if it is needed an additional fix. Thanks, Lucas ----- Original Message ----- > From: "Lucas Ponce" > To: "Discussions around Hawkular development" > Sent: Monday, November 9, 2015 9:12:02 AM > Subject: Re: [Hawkular-dev] [Alert] parameters to resolve > > It seems some missing update in the documentation. > > Let me check and respond later. > > Thanks for bringing it. > > As a temporal workaround, meanwhile I take a look on it, there are several > tests that can be used to compare with your code: > > https://github.com/hawkular/hawkular-ui-services/blob/master/src/rest/hawkRest-alert-provider.spec.rest.js > > These are used for ui-services, but can be used as an example of how to > interact with the API. > > Lucas > > ----- Original Message ----- > > From: "Heiko W.Rupp" > > To: "Discussions around Hawkular development" > > > > Sent: Monday, November 9, 2015 8:05:00 AM > > Subject: [Hawkular-dev] [Alert] parameters to resolve > > > > Hey, > > > > according to > > http://www.hawkular.org/docs/rest/rest-alerts.html#_alert_handling I do > > not > > need to provide query params to resolve an alert. > > > > When I do > > method: put > > uri: > > http://jdoe:password at localhost:8080/hawkular/alerts/resolve/28026b36-8fe4-4332-84c8-524e173a68bf-snert~Local_jvm_garba-1446977734134 > > > > I get the following error back: > > > > Hawkular::HawkularException: Internal error: > > java.lang.IllegalArgumentException: Note must have non-null user and > > text > > ./lib/Hawkular.rb:141:in `handle_fault' > > ./lib/Hawkular.rb:62:in `rescue in http_put' > > ./lib/Hawkular.rb:56:in `http_put' > > > > What am I doing wrong? > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Mon Nov 9 08:25:13 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 9 Nov 2015 08:25:13 -0500 Subject: [Hawkular-dev] [Alert] parameters to resolve In-Reply-To: <1246567193.5425646.1447058961953.JavaMail.zimbra@redhat.com> References: <018D47DB-05B3-4214-B064-56BDB3060317@redhat.com> <1348501014.5406714.1447056722417.JavaMail.zimbra@redhat.com> <1246567193.5425646.1447058961953.JavaMail.zimbra@redhat.com> Message-ID: <56409EB9.2060202@redhat.com> I'm fairly sure this is already fixed in master, it should not be necessary to add a note when acking or resolving. I think I saw this and fixed it "in passing". On 11/9/2015 3:49 AM, Lucas Ponce wrote: > Hi Heiko, > > It seems a small bug in the empty verification parameters. > > Please, can you send me more details of your test and version used ( I guess Alpha6 ). > > Off-list or just in a JIRA and I will verify if this is fixed in master of if it is needed an additional fix. > > Thanks, > Lucas > > ----- Original Message ----- >> From: "Lucas Ponce" >> To: "Discussions around Hawkular development" >> Sent: Monday, November 9, 2015 9:12:02 AM >> Subject: Re: [Hawkular-dev] [Alert] parameters to resolve >> >> It seems some missing update in the documentation. >> >> Let me check and respond later. >> >> Thanks for bringing it. >> >> As a temporal workaround, meanwhile I take a look on it, there are several >> tests that can be used to compare with your code: >> >> https://github.com/hawkular/hawkular-ui-services/blob/master/src/rest/hawkRest-alert-provider.spec.rest.js >> >> These are used for ui-services, but can be used as an example of how to >> interact with the API. >> >> Lucas >> >> ----- Original Message ----- >>> From: "Heiko W.Rupp" >>> To: "Discussions around Hawkular development" >>> >>> Sent: Monday, November 9, 2015 8:05:00 AM >>> Subject: [Hawkular-dev] [Alert] parameters to resolve >>> >>> Hey, >>> >>> according to >>> http://www.hawkular.org/docs/rest/rest-alerts.html#_alert_handling I do >>> not >>> need to provide query params to resolve an alert. >>> >>> When I do >>> method: put >>> uri: >>> http://jdoe:password at localhost:8080/hawkular/alerts/resolve/28026b36-8fe4-4332-84c8-524e173a68bf-snert~Local_jvm_garba-1446977734134 >>> >>> I get the following error back: >>> >>> Hawkular::HawkularException: Internal error: >>> java.lang.IllegalArgumentException: Note must have non-null user and >>> text >>> ./lib/Hawkular.rb:141:in `handle_fault' >>> ./lib/Hawkular.rb:62:in `rescue in http_put' >>> ./lib/Hawkular.rb:56:in `http_put' >>> >>> What am I doing wrong? >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.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/20151109/db0843d2/attachment-0001.html From lkrejci at redhat.com Mon Nov 9 09:45:15 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 09 Nov 2015 15:45:15 +0100 Subject: [Hawkular-dev] Inventory model change? In-Reply-To: References: Message-ID: <12265333.cptFodU7cs@localhost.localdomain> There's a couple of things involved: 1) The inventory 0.8.0 release was done late on Friday upon Mazz's request. So we haven't had time to send PRs to affected projects - in the end I managed to patch agent to conform to 0.8.0 on Fri but the UI has been patched only today. 2) I relied more than I probably should have on Jirka being both UI and Inv person so I knew UI will get a proper treatment to become compatible. 3) This was long overdue and promised from the beginning ("feed should only need to remember its ID mantra"), so I was eager to get it in. 4) I concentrate more on having the agent working than on producing some detailed release notes (and I've been on that today - trying to summarize the changes in some comprehensible package). I would probably summarize all that to "Don't release on Friday afternoon" :) On Monday, November 09, 2015 08:11:00 Heiko W.Rupp wrote: > Hey, > > I saw this on irc: > [2015-11-06T21:19:27+0100] I was going to update kettle, but > that's broken if pulling in the > latest agent and inventory. looks like we'll need to get the UI to > know that feeds are no longer under > environment > > We have clients that use subsystems like inventory today - internal like > pinger > and UI and also external ones. > > If we make such changes we need to communicate them here so that > everyone knows about them. And not only what has changed, but also > something like a list of previous->new and when it applies (e.g. is in > inv-0.8.15 and > will be in Hawkular-1.0.7 > > With our rest apis, we should perhaps even transparently redirect > requests > to give old clients time to transition to the new model / api / > endpoints. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From mazz at redhat.com Mon Nov 9 09:49:05 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 9 Nov 2015 09:49:05 -0500 (EST) Subject: [Hawkular-dev] Inventory model change? In-Reply-To: <12265333.cptFodU7cs@localhost.localdomain> References: <12265333.cptFodU7cs@localhost.localdomain> Message-ID: <333457357.5601291.1447080545925.JavaMail.zimbra@redhat.com> > I would probably summarize all that to "Don't release on Friday afternoon" :) ADDENDUM: ... Unless Mazz asks for it ;) From tsegismo at redhat.com Mon Nov 9 10:16:48 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 9 Nov 2015 16:16:48 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> Message-ID: <5640B8E0.4000009@redhat.com> Hi, Phase 0 is already implemented: - Metrics can receive data over HTTP - Metrics can publish inserted data to the bus - Webhooks can be created/configured via the Alerts API - Alerts is able to consume data from the bus I can't see why we need to expose an endpoint in Metrics API to setup a set of conditions in Alerts. The Alerts API does the job. Do you already know the use cases for Phase 1? Regards, Thomas Le 06/11/2015 00:01, Stefan Negrea a ?crit : > Hello Everybody, > > I want to open the discussion around the design and implementation for the Hawkular Metrics and Hawkular Alerts integration. I created a document with the scope and objectives for Phase 0. It is called Phase 0 because this should be a proof of concept of the type of functionality to be delivered in the future with a scope of getting early feedback on our ideas. The goal is to deliver this phase in Hawkular Metrics 0.10.0, and have something implemented in the next 2 weeks. > > I've had discussions with developers on both teams and updated the document based on those discussions. My goal was to first refine the ideas to a coherent state before publishing a first draft. I am now opening the document and the discussion to the entire Hawkular community. > > The one point where we need additional help is highlighted in red with a bigger font in the document. > > Please feel free to comment in the document, reply to this email, or contact me (stefan_n) on #hawkular on freenode. If you do not have access to the document please email me privately and will grant access. Any and all the feedback is more than welcomed. > > > Link: https://docs.google.com/document/d/1PwOGGysO0ppc2VPl80i4ye9pZI-Ugd4gObzQ5GFid4Y > > > Thank you, > Stefan Negrea > > Software Engineer > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Mon Nov 9 10:48:31 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 9 Nov 2015 10:48:31 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640B8E0.4000009@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> Message-ID: <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> Hello, That document uses what is already implemented as a base. Phase 0 (a prototype phase) should take the current implementation to the next level. All the things in the document where logical increments to what we have today. The goal was to have a quick Phase 0 to build something that we can get feedback on. As for the requirements, there are no requirement and there will probably be very little requirements. There is no external entity to give us some requirements at this stage. If you consider that what is proposed in the document is wrong, I open to suggestions. However, I caution against inaction or slow action. Whatever we do should follow two basic principles: 1) Fast phase, 2-3 weeks of development 2) Build something simple that enables more complicated features in the future More replies inline below .... Thank you, Stefan ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Monday, November 9, 2015 9:16:48 AM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > Hi, > > Phase 0 is already implemented: > - Metrics can receive data over HTTP > - Metrics can publish inserted data to the bus > - Webhooks can be created/configured via the Alerts API > - Alerts is able to consume data from the bus That is not what the document states as goals for Phase 0. As the document is written what you described is a prerequisite for Phase 0. > > I can't see why we need to expose an endpoint in Metrics API to setup a > set of conditions in Alerts. The Alerts API does the job. Disconnected APIs are not an integrated solutions. Just as an example, the are issues with the maturity of the APIs on both ends. Until we go through the exercise of trying to integrate the two in a user facing feature we will not see the differences or be able to provide something meaningful to users. > > Do you already know the use cases for Phase 1? There are no requirements, and probably there will be no requirements in the next month (or even more). That is not the way to approach this. > > Regards, > Thomas > > > Le 06/11/2015 00:01, Stefan Negrea a ?crit : > > Hello Everybody, > > > > I want to open the discussion around the design and implementation for the > > Hawkular Metrics and Hawkular Alerts integration. I created a document > > with the scope and objectives for Phase 0. It is called Phase 0 because > > this should be a proof of concept of the type of functionality to be > > delivered in the future with a scope of getting early feedback on our > > ideas. The goal is to deliver this phase in Hawkular Metrics 0.10.0, and > > have something implemented in the next 2 weeks. > > > > I've had discussions with developers on both teams and updated the document > > based on those discussions. My goal was to first refine the ideas to a > > coherent state before publishing a first draft. I am now opening the > > document and the discussion to the entire Hawkular community. > > > > The one point where we need additional help is highlighted in red with a > > bigger font in the document. > > > > Please feel free to comment in the document, reply to this email, or > > contact me (stefan_n) on #hawkular on freenode. If you do not have access > > to the document please email me privately and will grant access. Any and > > all the feedback is more than welcomed. > > > > > > Link: > > https://docs.google.com/document/d/1PwOGGysO0ppc2VPl80i4ye9pZI-Ugd4gObzQ5GFid4Y > > > > > > Thank you, > > Stefan Negrea > > > > Software Engineer > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Mon Nov 9 11:39:05 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 9 Nov 2015 11:39:05 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> Message-ID: <5D8E5D75-3270-4C57-B540-377B1487856E@redhat.com> I am working on a prototype that I would like to demo/discuss on Wednesday, probably during the regularly scheduled metrics meeting. I have work in branches that creates a WildFly 10 distro that includes only H-Metrics and H-Alerts. I have an integration test that creates a trigger for a metric, pushes data for that metric, and verifies that an alert is fired. I am starting to work on another, interesting scenario in which I query for a metric and the result includes any alerts that have fired. My changes are in the following branches, https://github.com/jsanda/hawkular-metrics/tree/alerts-integration https://github.com/jsanda/hawkular-alerts/tree/metrics-integration https://github.com/jsanda/hawkular-bus/tree/metrics+alerts > > On Nov 9, 2015, at 10:48 AM, Stefan Negrea wrote: > > Hello, > > That document uses what is already implemented as a base. Phase 0 (a prototype phase) should take the current implementation to the next level. All the things in the document where logical increments to what we have today. The goal was to have a quick Phase 0 to build something that we can get feedback on. > > As for the requirements, there are no requirement and there will probably be very little requirements. There is no external entity to give us some requirements at this stage. If you consider that what is proposed in the document is wrong, I open to suggestions. However, I caution against inaction or slow action. > > Whatever we do should follow two basic principles: > 1) Fast phase, 2-3 weeks of development > 2) Build something simple that enables more complicated features in the future > > > More replies inline below .... > > > Thank you, > Stefan > > > ----- Original Message ----- >> From: "Thomas Segismont" > >> To: hawkular-dev at lists.jboss.org >> Sent: Monday, November 9, 2015 9:16:48 AM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> Hi, >> >> Phase 0 is already implemented: >> - Metrics can receive data over HTTP >> - Metrics can publish inserted data to the bus >> - Webhooks can be created/configured via the Alerts API >> - Alerts is able to consume data from the bus > > That is not what the document states as goals for Phase 0. As the document is written what you described is a prerequisite for Phase 0. > >> >> I can't see why we need to expose an endpoint in Metrics API to setup a >> set of conditions in Alerts. The Alerts API does the job. > > Disconnected APIs are not an integrated solutions. Just as an example, the are issues with the maturity of the APIs on both ends. Until we go through the exercise of trying to integrate the two in a user facing feature we will not see the differences or be able to provide something meaningful to users. > >> >> Do you already know the use cases for Phase 1? > > There are no requirements, and probably there will be no requirements in the next month (or even more). That is not the way to approach this. > >> >> Regards, >> Thomas >> >> >> Le 06/11/2015 00:01, Stefan Negrea a ?crit : >>> Hello Everybody, >>> >>> I want to open the discussion around the design and implementation for the >>> Hawkular Metrics and Hawkular Alerts integration. I created a document >>> with the scope and objectives for Phase 0. It is called Phase 0 because >>> this should be a proof of concept of the type of functionality to be >>> delivered in the future with a scope of getting early feedback on our >>> ideas. The goal is to deliver this phase in Hawkular Metrics 0.10.0, and >>> have something implemented in the next 2 weeks. >>> >>> I've had discussions with developers on both teams and updated the document >>> based on those discussions. My goal was to first refine the ideas to a >>> coherent state before publishing a first draft. I am now opening the >>> document and the discussion to the entire Hawkular community. >>> >>> The one point where we need additional help is highlighted in red with a >>> bigger font in the document. >>> >>> Please feel free to comment in the document, reply to this email, or >>> contact me (stefan_n) on #hawkular on freenode. If you do not have access >>> to the document please email me privately and will grant access. Any and >>> all the feedback is more than welcomed. >>> >>> >>> Link: >>> https://docs.google.com/document/d/1PwOGGysO0ppc2VPl80i4ye9pZI-Ugd4gObzQ5GFid4Y >>> >>> >>> Thank you, >>> Stefan Negrea >>> >>> Software Engineer >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151109/d56e36ac/attachment-0001.html From tsegismo at redhat.com Mon Nov 9 11:43:26 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 9 Nov 2015 17:43:26 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> Message-ID: <5640CD2E.3070500@redhat.com> Le 09/11/2015 16:48, Stefan Negrea a ?crit : > Hello, > > That document uses what is already implemented as a base. Phase 0 (a prototype phase) should take the current implementation to the next level. All the things in the document where logical increments to what we have today. The goal was to have a quick Phase 0 to build something that we can get feedback on. The use case detailed in the example is already possible with a Hawkular server. I don't understand what taking the "current implementation to the next level" means. > > As for the requirements, there are no requirement and there will probably be very little requirements. There is no external entity to give us some requirements at this stage. If you consider that what is proposed in the document is wrong, I open to suggestions. However, I caution against inaction or slow action. > The use case detailed in the document is fine. But there's no need to prototype an integration if it already exists. > Whatever we do should follow two basic principles: > 1) Fast phase, 2-3 weeks of development > 2) Build something simple that enables more complicated features in the future > I have yet to see a feature which requires to rebuild a new integration mechanism. > > More replies inline below .... > > > Thank you, > Stefan > > > ----- Original Message ----- >> From: "Thomas Segismont" >> To: hawkular-dev at lists.jboss.org >> Sent: Monday, November 9, 2015 9:16:48 AM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> Hi, >> >> Phase 0 is already implemented: >> - Metrics can receive data over HTTP >> - Metrics can publish inserted data to the bus >> - Webhooks can be created/configured via the Alerts API >> - Alerts is able to consume data from the bus > > That is not what the document states as goals for Phase 0. As the document is written what you described is a prerequisite for Phase 0. From Google docs: "This document has two parts. First are the details about how to exchange data between the two services. And then, there is a description of a simple feature that can showcase the integration." 1. Data exchange between the two services is already implemented. 2. The user facing feature is already possible with a Hawkular server. So phase 0 is over. Period. > >> >> I can't see why we need to expose an endpoint in Metrics API to setup a >> set of conditions in Alerts. The Alerts API does the job. > > Disconnected APIs are not an integrated solutions. Just as an example, the are issues with the maturity of the APIs on both ends. Until we go through the exercise of trying to integrate the two in a user facing feature we will not see the differences or be able to provide something meaningful to users. What does disconnected mean? That they are not implemented by the same software component? In this case it's not a problem. The webhook API won't be more mature because it's re-written from Alerts into Metrics. Maybe I missed your point. Integration of Alerts and Metrics has been demonstrated and used this very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no attendee (other than Juca) did notice there was 2 software components behind the service. Truth is the scenario described in the document lacks an integration test. I believe this could be added to: https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test > >> >> Do you already know the use cases for Phase 1? > > There are no requirements, and probably there will be no requirements in the next month (or even more). That is not the way to approach this. From my POV, the way to approach this is to write documentation and tests for all the awesome features which already work but people (including in our community) aren't aware of. From snegrea at redhat.com Mon Nov 9 12:10:38 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 9 Nov 2015 12:10:38 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640CD2E.3070500@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> Message-ID: <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> Hello Thomas, So far there is no concrete proposal, only why things should not be done; which equates to inaction. I am not the most imaginative person on the planet so I might fail on that front, but I think the plan that I proposed had some cohesion and it was forward looking. Here is a good course of action: 1) Propose something new; completely new or partially new 2) Get the majority of the group (Metrics + Alerts teams) to agree on the path 3) Create the plan to accomplish it and lead the group to implement the plan Thank you, Stefan Negrea ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Monday, November 9, 2015 10:43:26 AM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > Le 09/11/2015 16:48, Stefan Negrea a ?crit : > > Hello, > > > > That document uses what is already implemented as a base. Phase 0 (a > > prototype phase) should take the current implementation to the next level. > > All the things in the document where logical increments to what we have > > today. The goal was to have a quick Phase 0 to build something that we can > > get feedback on. > > The use case detailed in the example is already possible with a Hawkular > server. > > I don't understand what taking the "current implementation to the next > level" means. > > > > > As for the requirements, there are no requirement and there will probably > > be very little requirements. There is no external entity to give us some > > requirements at this stage. If you consider that what is proposed in the > > document is wrong, I open to suggestions. However, I caution against > > inaction or slow action. > > > > The use case detailed in the document is fine. But there's no need to > prototype an integration if it already exists. > > > Whatever we do should follow two basic principles: > > 1) Fast phase, 2-3 weeks of development > > 2) Build something simple that enables more complicated features in the > > future > > > > I have yet to see a feature which requires to rebuild a new integration > mechanism. > > > > > More replies inline below .... > > > > > > Thank you, > > Stefan > > > > > > ----- Original Message ----- > >> From: "Thomas Segismont" > >> To: hawkular-dev at lists.jboss.org > >> Sent: Monday, November 9, 2015 9:16:48 AM > >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > >> > >> Hi, > >> > >> Phase 0 is already implemented: > >> - Metrics can receive data over HTTP > >> - Metrics can publish inserted data to the bus > >> - Webhooks can be created/configured via the Alerts API > >> - Alerts is able to consume data from the bus > > > > That is not what the document states as goals for Phase 0. As the document > > is written what you described is a prerequisite for Phase 0. > > From Google docs: > "This document has two parts. First are the details about how to > exchange data between the two services. And then, there is a description > of a simple feature that can showcase the integration." > > 1. Data exchange between the two services is already implemented. > 2. The user facing feature is already possible with a Hawkular server. > > So phase 0 is over. Period. > > > > >> > >> I can't see why we need to expose an endpoint in Metrics API to setup a > >> set of conditions in Alerts. The Alerts API does the job. > > > > Disconnected APIs are not an integrated solutions. Just as an example, the > > are issues with the maturity of the APIs on both ends. Until we go through > > the exercise of trying to integrate the two in a user facing feature we > > will not see the differences or be able to provide something meaningful to > > users. > > What does disconnected mean? That they are not implemented by the same > software component? In this case it's not a problem. > > The webhook API won't be more mature because it's re-written from Alerts > into Metrics. Maybe I missed your point. > > Integration of Alerts and Metrics has been demonstrated and used this > very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no > attendee (other than Juca) did notice there was 2 software components > behind the service. > > Truth is the scenario described in the document lacks an integration > test. I believe this could be added to: > https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test > > > > >> > >> Do you already know the use cases for Phase 1? > > > > There are no requirements, and probably there will be no requirements in > > the next month (or even more). That is not the way to approach this. > > From my POV, the way to approach this is to write documentation and > tests for all the awesome features which already work but people > (including in our community) aren't aware of. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Mon Nov 9 12:48:05 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 9 Nov 2015 18:48:05 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> Message-ID: <5640DC55.5050902@redhat.com> Le 09/11/2015 18:10, Stefan Negrea a ?crit : > Hello Thomas, > > So far there is no concrete proposal, only why things should not be done; which equates to inaction. I am not the most imaginative person on the planet so I might fail on that front, but I think the plan that I proposed had some cohesion and it was forward looking. > > > Here is a good course of action: > 1) Propose something new; completely new or partially new > 2) Get the majority of the group (Metrics + Alerts teams) to agree on the path > 3) Create the plan to accomplish it and lead the group to implement the plan I understand the goals of your proposal. I'm simply opposed to re-writing what already exists, unless it is proven that it is broken. Given the stress you rightfully put on moving fast, improving the existing system seems like a reasonable approach. Now maybe you didn't know the features are already there, but they are. > > > Thank you, > Stefan Negrea > > ----- Original Message ----- >> From: "Thomas Segismont" >> To: hawkular-dev at lists.jboss.org >> Sent: Monday, November 9, 2015 10:43:26 AM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> Le 09/11/2015 16:48, Stefan Negrea a ?crit : >>> Hello, >>> >>> That document uses what is already implemented as a base. Phase 0 (a >>> prototype phase) should take the current implementation to the next level. >>> All the things in the document where logical increments to what we have >>> today. The goal was to have a quick Phase 0 to build something that we can >>> get feedback on. >> >> The use case detailed in the example is already possible with a Hawkular >> server. >> >> I don't understand what taking the "current implementation to the next >> level" means. >> >>> >>> As for the requirements, there are no requirement and there will probably >>> be very little requirements. There is no external entity to give us some >>> requirements at this stage. If you consider that what is proposed in the >>> document is wrong, I open to suggestions. However, I caution against >>> inaction or slow action. >>> >> >> The use case detailed in the document is fine. But there's no need to >> prototype an integration if it already exists. >> >>> Whatever we do should follow two basic principles: >>> 1) Fast phase, 2-3 weeks of development >>> 2) Build something simple that enables more complicated features in the >>> future >>> >> >> I have yet to see a feature which requires to rebuild a new integration >> mechanism. >> >>> >>> More replies inline below .... >>> >>> >>> Thank you, >>> Stefan >>> >>> >>> ----- Original Message ----- >>>> From: "Thomas Segismont" >>>> To: hawkular-dev at lists.jboss.org >>>> Sent: Monday, November 9, 2015 9:16:48 AM >>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>>> >>>> Hi, >>>> >>>> Phase 0 is already implemented: >>>> - Metrics can receive data over HTTP >>>> - Metrics can publish inserted data to the bus >>>> - Webhooks can be created/configured via the Alerts API >>>> - Alerts is able to consume data from the bus >>> >>> That is not what the document states as goals for Phase 0. As the document >>> is written what you described is a prerequisite for Phase 0. >> >> From Google docs: >> "This document has two parts. First are the details about how to >> exchange data between the two services. And then, there is a description >> of a simple feature that can showcase the integration." >> >> 1. Data exchange between the two services is already implemented. >> 2. The user facing feature is already possible with a Hawkular server. >> >> So phase 0 is over. Period. >> >>> >>>> >>>> I can't see why we need to expose an endpoint in Metrics API to setup a >>>> set of conditions in Alerts. The Alerts API does the job. >>> >>> Disconnected APIs are not an integrated solutions. Just as an example, the >>> are issues with the maturity of the APIs on both ends. Until we go through >>> the exercise of trying to integrate the two in a user facing feature we >>> will not see the differences or be able to provide something meaningful to >>> users. >> >> What does disconnected mean? That they are not implemented by the same >> software component? In this case it's not a problem. >> >> The webhook API won't be more mature because it's re-written from Alerts >> into Metrics. Maybe I missed your point. >> >> Integration of Alerts and Metrics has been demonstrated and used this >> very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no >> attendee (other than Juca) did notice there was 2 software components >> behind the service. >> >> Truth is the scenario described in the document lacks an integration >> test. I believe this could be added to: >> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test >> >>> >>>> >>>> Do you already know the use cases for Phase 1? >>> >>> There are no requirements, and probably there will be no requirements in >>> the next month (or even more). That is not the way to approach this. >> >> From my POV, the way to approach this is to write documentation and >> tests for all the awesome features which already work but people >> (including in our community) aren't aware of. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Mon Nov 9 14:53:52 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 20:53:52 +0100 Subject: [Hawkular-dev] Inventory model change? In-Reply-To: <12265333.cptFodU7cs@localhost.localdomain> References: <12265333.cptFodU7cs@localhost.localdomain> Message-ID: <95B6788D-DAB5-44E4-BCD0-FF7EB7D206FA@redhat.com> On 9 Nov 2015, at 15:45, Lukas Krejci wrote: > There's a couple of things involved: > > 1) The inventory 0.8.0 release was done late on Friday upon Mazz's > request. So > we haven't had time to send PRs to affected projects - in The point is probably, that we can not do that anymore in the future - we will have clients that we will not know about it. > > 4) I concentrate more on having the agent working than on producing > some > detailed release notes (and I've been on that today - I am not really asking for release notes, but rather some rules on how to change by code base to get going again. From hrupp at redhat.com Mon Nov 9 14:55:39 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 09 Nov 2015 20:55:39 +0100 Subject: [Hawkular-dev] Inventory model change? In-Reply-To: <95B6788D-DAB5-44E4-BCD0-FF7EB7D206FA@redhat.com> References: <12265333.cptFodU7cs@localhost.localdomain> <95B6788D-DAB5-44E4-BCD0-FF7EB7D206FA@redhat.com> Message-ID: <14FD3D60-E74B-4F5C-AB50-3C778317938A@redhat.com> On 9 Nov 2015, at 20:53, Heiko W.Rupp wrote: > On 9 Nov 2015, at 15:45, Lukas Krejci wrote: > >> There's a couple of things involved: >> >> 1) The inventory 0.8.0 release was done late on Friday upon Mazz's >> request. So >> we haven't had time to send PRs to affected projects - in > > The point is probably, that we can not do that anymore > in the future - we will have clients that we will not know > about it. >> >> 4) I concentrate more on having the agent working than on producing >> some >> detailed release notes (and I've been on that today - > > I am not really asking for release notes, but rather some > rules on how to change by code base to get going again. And "Look at tests in xyz-foobar" will not be the solution here. From jshaughn at redhat.com Mon Nov 9 17:51:47 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 9 Nov 2015 17:51:47 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640DC55.5050902@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> Message-ID: <56412383.1060406@redhat.com> I guess what Stefan is trying to figure out is whether it makes sense and is useful to have Metrics use Alerts basically as a 3rd party tool, such that a potential Metrics client can focus on using Metrics and not worry about interacting with Alerts directly. The proposal to me looks like an attempt to identify one of possibly many Metrics "events" that a user may be interesting in setting up for notification, in this case via a webhook. So here we have proposed a MetricReported event (or was it MetricValueChanged?). I don't know exactly what other events would be useful, but perhaps there are a lot of Metrics happenings that a client may want to be notified of. It's not necessarily true that a client could do this by using the two tools independently, if in fact Metrics is adding hooks in its own processing to identify these "listenable events". But I don't get the feeling this is the proposal on the table, at least not for this first proposal. Instead, I think to handle MetricReported the idea may have been to just create a trigger that looks for the specific metric data coming in and to fire an alert. In which case it is perhaps not as useful to have Metrics set it up, but it's still maybe a step towards Metrics coming up with some sort of useful API that would leverage Alerts for its impl. As for deployment, it seems to me that a prepackaged Metrics+Alerts+Bus, that could [eventually] be replicated/clustered, would be good. It could handle use cases where data is persisted and then pushed to the bus (like in hawkular), and then filtered and grabbed by alerts via a topic consumer. And it could handle REST interaction. And it could offer the ability to leverage co-located clients as well. By the way, there is still the integration component I put together a while ago, that is completely independent of this discussion. It's an external alerter that is both a client of metrics and alerts, and generates alerts based on the results of aggregate queries performed against metrics. On 11/9/2015 12:48 PM, Thomas Segismont wrote: > Le 09/11/2015 18:10, Stefan Negrea a ?crit : >> Hello Thomas, >> >> So far there is no concrete proposal, only why things should not be done; which equates to inaction. I am not the most imaginative person on the planet so I might fail on that front, but I think the plan that I proposed had some cohesion and it was forward looking. >> >> >> Here is a good course of action: >> 1) Propose something new; completely new or partially new >> 2) Get the majority of the group (Metrics + Alerts teams) to agree on the path >> 3) Create the plan to accomplish it and lead the group to implement the plan > I understand the goals of your proposal. I'm simply opposed to > re-writing what already exists, unless it is proven that it is broken. > > Given the stress you rightfully put on moving fast, improving the > existing system seems like a reasonable approach. > > Now maybe you didn't know the features are already there, but they are. > >> >> Thank you, >> Stefan Negrea >> >> ----- Original Message ----- >>> From: "Thomas Segismont" >>> To: hawkular-dev at lists.jboss.org >>> Sent: Monday, November 9, 2015 10:43:26 AM >>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>> >>> Le 09/11/2015 16:48, Stefan Negrea a ?crit : >>>> Hello, >>>> >>>> That document uses what is already implemented as a base. Phase 0 (a >>>> prototype phase) should take the current implementation to the next level. >>>> All the things in the document where logical increments to what we have >>>> today. The goal was to have a quick Phase 0 to build something that we can >>>> get feedback on. >>> The use case detailed in the example is already possible with a Hawkular >>> server. >>> >>> I don't understand what taking the "current implementation to the next >>> level" means. >>> >>>> As for the requirements, there are no requirement and there will probably >>>> be very little requirements. There is no external entity to give us some >>>> requirements at this stage. If you consider that what is proposed in the >>>> document is wrong, I open to suggestions. However, I caution against >>>> inaction or slow action. >>>> >>> The use case detailed in the document is fine. But there's no need to >>> prototype an integration if it already exists. >>> >>>> Whatever we do should follow two basic principles: >>>> 1) Fast phase, 2-3 weeks of development >>>> 2) Build something simple that enables more complicated features in the >>>> future >>>> >>> I have yet to see a feature which requires to rebuild a new integration >>> mechanism. >>> >>>> More replies inline below .... >>>> >>>> >>>> Thank you, >>>> Stefan >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Thomas Segismont" >>>>> To: hawkular-dev at lists.jboss.org >>>>> Sent: Monday, November 9, 2015 9:16:48 AM >>>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>>>> >>>>> Hi, >>>>> >>>>> Phase 0 is already implemented: >>>>> - Metrics can receive data over HTTP >>>>> - Metrics can publish inserted data to the bus >>>>> - Webhooks can be created/configured via the Alerts API >>>>> - Alerts is able to consume data from the bus >>>> That is not what the document states as goals for Phase 0. As the document >>>> is written what you described is a prerequisite for Phase 0. >>> From Google docs: >>> "This document has two parts. First are the details about how to >>> exchange data between the two services. And then, there is a description >>> of a simple feature that can showcase the integration." >>> >>> 1. Data exchange between the two services is already implemented. >>> 2. The user facing feature is already possible with a Hawkular server. >>> >>> So phase 0 is over. Period. >>> >>>>> I can't see why we need to expose an endpoint in Metrics API to setup a >>>>> set of conditions in Alerts. The Alerts API does the job. >>>> Disconnected APIs are not an integrated solutions. Just as an example, the >>>> are issues with the maturity of the APIs on both ends. Until we go through >>>> the exercise of trying to integrate the two in a user facing feature we >>>> will not see the differences or be able to provide something meaningful to >>>> users. >>> What does disconnected mean? That they are not implemented by the same >>> software component? In this case it's not a problem. >>> >>> The webhook API won't be more mature because it's re-written from Alerts >>> into Metrics. Maybe I missed your point. >>> >>> Integration of Alerts and Metrics has been demonstrated and used this >>> very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no >>> attendee (other than Juca) did notice there was 2 software components >>> behind the service. >>> >>> Truth is the scenario described in the document lacks an integration >>> test. I believe this could be added to: >>> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test >>> >>>>> Do you already know the use cases for Phase 1? >>>> There are no requirements, and probably there will be no requirements in >>>> the next month (or even more). That is not the way to approach this. >>> From my POV, the way to approach this is to write documentation and >>> tests for all the awesome features which already work but people >>> (including in our community) aren't aware of. >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From snegrea at redhat.com Mon Nov 9 18:33:25 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 9 Nov 2015 18:33:25 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640DC55.5050902@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> Message-ID: <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Monday, November 9, 2015 11:48:05 AM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > > Le 09/11/2015 18:10, Stefan Negrea a ?crit : > > Hello Thomas, > > > > So far there is no concrete proposal, only why things should not be done; > > which equates to inaction. I am not the most imaginative person on the > > planet so I might fail on that front, but I think the plan that I proposed > > had some cohesion and it was forward looking. > > > > > > Here is a good course of action: > > 1) Propose something new; completely new or partially new > > 2) Get the majority of the group (Metrics + Alerts teams) to agree on the > > path > > 3) Create the plan to accomplish it and lead the group to implement the > > plan > > I understand the goals of your proposal. I'm simply opposed to > re-writing what already exists, unless it is proven that it is broken. I never said something is broken. The document is meant to be an iteration over what we have today. More precisely, contains two proposals for moving forward with an unified communication channel. And also there is a proposal for a new feature. I asked for feedback on those two communication methods to adopt one; with the goal to support the newly proposed feature. The current implementation is not broken for the current use cases (the integration in Hawkular). But that is not the point, and neither did I claim that is broken. It's not about fixing something that is broken but about creating something new. Just one example, a distributed environment with multiple Metrics and Alerts deployments will just not work with what is there today. And that was discussed thoroughly prior to making the document public. Thomas, you are yet to propose an alternative Phase 1 (or 0); or even changes to the current document. > > Given the stress you rightfully put on moving fast, improving the > existing system seems like a reasonable approach. > > Now maybe you didn't know the features are already there, but they are. I know that you know that I know about the current state of the features. To reiterate, I am looking for a positive path forward. > > > > > > > Thank you, > > Stefan Negrea > > > > ----- Original Message ----- > >> From: "Thomas Segismont" > >> To: hawkular-dev at lists.jboss.org > >> Sent: Monday, November 9, 2015 10:43:26 AM > >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > >> > >> Le 09/11/2015 16:48, Stefan Negrea a ?crit : > >>> Hello, > >>> > >>> That document uses what is already implemented as a base. Phase 0 (a > >>> prototype phase) should take the current implementation to the next > >>> level. > >>> All the things in the document where logical increments to what we have > >>> today. The goal was to have a quick Phase 0 to build something that we > >>> can > >>> get feedback on. > >> > >> The use case detailed in the example is already possible with a Hawkular > >> server. > >> > >> I don't understand what taking the "current implementation to the next > >> level" means. > >> > >>> > >>> As for the requirements, there are no requirement and there will probably > >>> be very little requirements. There is no external entity to give us some > >>> requirements at this stage. If you consider that what is proposed in the > >>> document is wrong, I open to suggestions. However, I caution against > >>> inaction or slow action. > >>> > >> > >> The use case detailed in the document is fine. But there's no need to > >> prototype an integration if it already exists. > >> > >>> Whatever we do should follow two basic principles: > >>> 1) Fast phase, 2-3 weeks of development > >>> 2) Build something simple that enables more complicated features in the > >>> future > >>> > >> > >> I have yet to see a feature which requires to rebuild a new integration > >> mechanism. > >> > >>> > >>> More replies inline below .... > >>> > >>> > >>> Thank you, > >>> Stefan > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Thomas Segismont" > >>>> To: hawkular-dev at lists.jboss.org > >>>> Sent: Monday, November 9, 2015 9:16:48 AM > >>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > >>>> > >>>> Hi, > >>>> > >>>> Phase 0 is already implemented: > >>>> - Metrics can receive data over HTTP > >>>> - Metrics can publish inserted data to the bus > >>>> - Webhooks can be created/configured via the Alerts API > >>>> - Alerts is able to consume data from the bus > >>> > >>> That is not what the document states as goals for Phase 0. As the > >>> document > >>> is written what you described is a prerequisite for Phase 0. > >> > >> From Google docs: > >> "This document has two parts. First are the details about how to > >> exchange data between the two services. And then, there is a description > >> of a simple feature that can showcase the integration." > >> > >> 1. Data exchange between the two services is already implemented. > >> 2. The user facing feature is already possible with a Hawkular server. > >> > >> So phase 0 is over. Period. > >> > >>> > >>>> > >>>> I can't see why we need to expose an endpoint in Metrics API to setup a > >>>> set of conditions in Alerts. The Alerts API does the job. > >>> > >>> Disconnected APIs are not an integrated solutions. Just as an example, > >>> the > >>> are issues with the maturity of the APIs on both ends. Until we go > >>> through > >>> the exercise of trying to integrate the two in a user facing feature we > >>> will not see the differences or be able to provide something meaningful > >>> to > >>> users. > >> > >> What does disconnected mean? That they are not implemented by the same > >> software component? In this case it's not a problem. > >> > >> The webhook API won't be more mature because it's re-written from Alerts > >> into Metrics. Maybe I missed your point. > >> > >> Integration of Alerts and Metrics has been demonstrated and used this > >> very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no > >> attendee (other than Juca) did notice there was 2 software components > >> behind the service. > >> > >> Truth is the scenario described in the document lacks an integration > >> test. I believe this could be added to: > >> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test > >> > >>> > >>>> > >>>> Do you already know the use cases for Phase 1? > >>> > >>> There are no requirements, and probably there will be no requirements in > >>> the next month (or even more). That is not the way to approach this. > >> > >> From my POV, the way to approach this is to write documentation and > >> tests for all the awesome features which already work but people > >> (including in our community) aren't aware of. > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.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 Mon Nov 9 21:43:12 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 9 Nov 2015 21:43:12 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> Message-ID: > > I never said something is broken. The document is meant to be an iteration over what we have today. More precisely, contains two proposals for moving forward with an unified communication channel. And also there is a proposal for a new feature. I asked for feedback on those two communication methods to adopt one; with the goal to support the newly proposed feature. > > The current implementation is not broken for the current use cases (the integration in Hawkular). But that is not the point, and neither did I claim that is broken. It's not about fixing something that is broken but about creating something new. Just one example, a distributed environment with multiple Metrics and Alerts deployments will just not work with what is there today. And that was discussed thoroughly prior to making the document public. > Can you elaborate on why what is in place today will not work with a distributed environment with multiple Metrics and Alerts deployments? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151109/3d91ccba/attachment.html From mazz at redhat.com Tue Nov 10 00:57:55 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 10 Nov 2015 00:57:55 -0500 (EST) Subject: [Hawkular-dev] do not use hawkular-agent master branch right now Message-ID: <44905429.6024413.1447135075372.JavaMail.zimbra@redhat.com> FYI: do not attempt to use a master build of the hawkular agent right now. It is massively broken. Only use the currently released agent (0.12.0.Final). From hrupp at redhat.com Tue Nov 10 02:43:26 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 10 Nov 2015 08:43:26 +0100 Subject: [Hawkular-dev] Version endpoint for components Message-ID: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> Hey, I think it would be good for all components that have a REST interface to have a /version endpoint that responds on GET and which returns - the tag (e.g. 0.8.1.Final or 0.3.44-SNAPSHOT or 1.2.3-src-dep-0xcafebabe)) - the git hash they are built from (less needed for .Final) So that clients can easily verify what version they have as peer. From lponce at redhat.com Tue Nov 10 04:02:31 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 10 Nov 2015 04:02:31 -0500 (EST) Subject: [Hawkular-dev] Version endpoint for components In-Reply-To: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> References: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> Message-ID: <1303676218.6136774.1447146151663.JavaMail.zimbra@redhat.com> +1 I will prepare one for alerts. ----- Original Message ----- > From: "Heiko W.Rupp" > To: "Discussions around Hawkular development" > Sent: Tuesday, November 10, 2015 8:43:26 AM > Subject: [Hawkular-dev] Version endpoint for components > > Hey, > > I think it would be good for all components that have a REST interface > to have a /version endpoint that responds on GET and which returns > - the tag (e.g. 0.8.1.Final or 0.3.44-SNAPSHOT or 1.2.3-src-dep-0xcafebabe)) > - the git hash they are built from (less needed for .Final) > > So that clients can easily verify what version they have as peer. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Tue Nov 10 04:04:44 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 10 Nov 2015 04:04:44 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> Message-ID: <334030095.6137445.1447146284724.JavaMail.zimbra@redhat.com> > > Given the stress you rightfully put on moving fast, improving the > > existing system seems like a reasonable approach. > > > > Now maybe you didn't know the features are already there, but they are. > > I know that you know that I know about the current state of the features. To > reiterate, I am looking for a positive path forward. > Guys, This only can be resolved with a duel: https://www.youtube.com/watch?v=OqL0kMdXbbU :-) Lucas From tsegismo at redhat.com Tue Nov 10 05:48:21 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 11:48:21 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56412383.1060406@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <56412383.1060406@redhat.com> Message-ID: <5641CB75.9040801@redhat.com> Thanks Jay for the detailed explanation. More inline. Le 09/11/2015 23:51, Jay Shaughnessy a ?crit : > > I guess what Stefan is trying to figure out is whether it makes sense > and is useful to have Metrics use Alerts basically as a 3rd party tool, > such that a potential Metrics client can focus on using Metrics and not > worry about interacting with Alerts directly. The proposal to me looks > like an attempt to identify one of possibly many Metrics "events" that a > user may be interesting in setting up for notification, in this case via > a webhook. So here we have proposed a MetricReported event (or was it > MetricValueChanged?). I don't know exactly what other events would be > useful, but perhaps there are a lot of Metrics happenings that a client > may want to be notified of. It's not necessarily true that a client > could do this by using the two tools independently, if in fact Metrics > is adding hooks in its own processing to identify these "listenable > events". But I don't get the feeling this is the proposal on the table, > at least not for this first proposal. Instead, I think to handle > MetricReported the idea may have been to just create a trigger that > looks for the specific metric data coming in and to fire an alert. In > which case it is perhaps not as useful to have Metrics set it up, but > it's still maybe a step towards Metrics coming up with some sort of > useful API that would leverage Alerts for its impl. It makes sense to combine the features of the individual components: it is the goal of Hawkular! If it's not clear for users that Hawkular implements the case above, then we have a problem in documentation/advertisement of the solution. If documentation/advertisement does not fix the issue, then we should start thinking about the way the capability is exposed to the user. But in any case, I fail to see how rebuilding the messaging integration layer, or maintaining two different kinds of integration in parallel would help. That said, anything which provides new capabilities or improves the user experience is welcome. > > As for deployment, it seems to me that a prepackaged Metrics+Alerts+Bus, > that could [eventually] be replicated/clustered, would be good. It > could handle use cases where data is persisted and then pushed to the > bus (like in hawkular), and then filtered and grabbed by alerts via a > topic consumer. And it could handle REST interaction. And it could > offer the ability to leverage co-located clients as well. Packaging/deployment is not an issue for me. Hawkular does not necessarily have to be deployed as an all in one package. Is there anything which prevents users to deploy Alerts and Metrics alone in different Nest instances? > > By the way, there is still the integration component I put together a > while ago, that is completely independent of this discussion. It's an > external alerter that is both a client of metrics and alerts, and > generates alerts based on the results of aggregate queries performed > against metrics. > > > On 11/9/2015 12:48 PM, Thomas Segismont wrote: >> Le 09/11/2015 18:10, Stefan Negrea a ?crit : >>> Hello Thomas, >>> >>> So far there is no concrete proposal, only why things should not be done; which equates to inaction. I am not the most imaginative person on the planet so I might fail on that front, but I think the plan that I proposed had some cohesion and it was forward looking. >>> >>> >>> Here is a good course of action: >>> 1) Propose something new; completely new or partially new >>> 2) Get the majority of the group (Metrics + Alerts teams) to agree on the path >>> 3) Create the plan to accomplish it and lead the group to implement the plan >> I understand the goals of your proposal. I'm simply opposed to >> re-writing what already exists, unless it is proven that it is broken. >> >> Given the stress you rightfully put on moving fast, improving the >> existing system seems like a reasonable approach. >> >> Now maybe you didn't know the features are already there, but they are. >> >>> >>> Thank you, >>> Stefan Negrea >>> >>> ----- Original Message ----- >>>> From: "Thomas Segismont" >>>> To: hawkular-dev at lists.jboss.org >>>> Sent: Monday, November 9, 2015 10:43:26 AM >>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>>> >>>> Le 09/11/2015 16:48, Stefan Negrea a ?crit : >>>>> Hello, >>>>> >>>>> That document uses what is already implemented as a base. Phase 0 (a >>>>> prototype phase) should take the current implementation to the next level. >>>>> All the things in the document where logical increments to what we have >>>>> today. The goal was to have a quick Phase 0 to build something that we can >>>>> get feedback on. >>>> The use case detailed in the example is already possible with a Hawkular >>>> server. >>>> >>>> I don't understand what taking the "current implementation to the next >>>> level" means. >>>> >>>>> As for the requirements, there are no requirement and there will probably >>>>> be very little requirements. There is no external entity to give us some >>>>> requirements at this stage. If you consider that what is proposed in the >>>>> document is wrong, I open to suggestions. However, I caution against >>>>> inaction or slow action. >>>>> >>>> The use case detailed in the document is fine. But there's no need to >>>> prototype an integration if it already exists. >>>> >>>>> Whatever we do should follow two basic principles: >>>>> 1) Fast phase, 2-3 weeks of development >>>>> 2) Build something simple that enables more complicated features in the >>>>> future >>>>> >>>> I have yet to see a feature which requires to rebuild a new integration >>>> mechanism. >>>> >>>>> More replies inline below .... >>>>> >>>>> >>>>> Thank you, >>>>> Stefan >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Thomas Segismont" >>>>>> To: hawkular-dev at lists.jboss.org >>>>>> Sent: Monday, November 9, 2015 9:16:48 AM >>>>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>>>>> >>>>>> Hi, >>>>>> >>>>>> Phase 0 is already implemented: >>>>>> - Metrics can receive data over HTTP >>>>>> - Metrics can publish inserted data to the bus >>>>>> - Webhooks can be created/configured via the Alerts API >>>>>> - Alerts is able to consume data from the bus >>>>> That is not what the document states as goals for Phase 0. As the document >>>>> is written what you described is a prerequisite for Phase 0. >>>> From Google docs: >>>> "This document has two parts. First are the details about how to >>>> exchange data between the two services. And then, there is a description >>>> of a simple feature that can showcase the integration." >>>> >>>> 1. Data exchange between the two services is already implemented. >>>> 2. The user facing feature is already possible with a Hawkular server. >>>> >>>> So phase 0 is over. Period. >>>> >>>>>> I can't see why we need to expose an endpoint in Metrics API to setup a >>>>>> set of conditions in Alerts. The Alerts API does the job. >>>>> Disconnected APIs are not an integrated solutions. Just as an example, the >>>>> are issues with the maturity of the APIs on both ends. Until we go through >>>>> the exercise of trying to integrate the two in a user facing feature we >>>>> will not see the differences or be able to provide something meaningful to >>>>> users. >>>> What does disconnected mean? That they are not implemented by the same >>>> software component? In this case it's not a problem. >>>> >>>> The webhook API won't be more mature because it's re-written from Alerts >>>> into Metrics. Maybe I missed your point. >>>> >>>> Integration of Alerts and Metrics has been demonstrated and used this >>>> very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no >>>> attendee (other than Juca) did notice there was 2 software components >>>> behind the service. >>>> >>>> Truth is the scenario described in the document lacks an integration >>>> test. I believe this could be added to: >>>> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test >>>> >>>>>> Do you already know the use cases for Phase 1? >>>>> There are no requirements, and probably there will be no requirements in >>>>> the next month (or even more). That is not the way to approach this. >>>> From my POV, the way to approach this is to write documentation and >>>> tests for all the awesome features which already work but people >>>> (including in our community) aren't aware of. >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Tue Nov 10 05:51:23 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 11:51:23 +0100 Subject: [Hawkular-dev] Version endpoint for components In-Reply-To: <1303676218.6136774.1447146151663.JavaMail.zimbra@redhat.com> References: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> <1303676218.6136774.1447146151663.JavaMail.zimbra@redhat.com> Message-ID: <5641CC2B.3060509@redhat.com> We have the /status endpoint already in Metrics for this purpose. Le 10/11/2015 10:02, Lucas Ponce a ?crit : > +1 > > I will prepare one for alerts. > > ----- Original Message ----- >> From: "Heiko W.Rupp" >> To: "Discussions around Hawkular development" >> Sent: Tuesday, November 10, 2015 8:43:26 AM >> Subject: [Hawkular-dev] Version endpoint for components >> >> Hey, >> >> I think it would be good for all components that have a REST interface >> to have a /version endpoint that responds on GET and which returns >> - the tag (e.g. 0.8.1.Final or 0.3.44-SNAPSHOT or 1.2.3-src-dep-0xcafebabe)) >> - the git hash they are built from (less needed for .Final) >> >> So that clients can easily verify what version they have as peer. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Nov 10 06:17:16 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 10 Nov 2015 12:17:16 +0100 Subject: [Hawkular-dev] Version endpoint for components In-Reply-To: <5641CC2B.3060509@redhat.com> References: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> <1303676218.6136774.1447146151663.JavaMail.zimbra@redhat.com> <5641CC2B.3060509@redhat.com> Message-ID: <64BE91A4-4AF5-49FF-912F-28A4E8915640@redhat.com> On 10 Nov 2015, at 11:51, Thomas Segismont wrote: > We have the /status endpoint already in Metrics for this purpose. Yep, that looks pretty good: '{"MetricsService":"STARTING", "Implementation-Version":"0.9.0.Final-SRC-revision-9080fcfbe40a66ce8143c477b5d6f8fbadeecf3a", "Built-From-Git-SHA1":"9080fcfbe40a66ce8143c477b5d6f8fbadeecf3a"}' We need to make sure that all the components use the same keys, which may either require to add a "status" to the above or to rename the "MetricsService" to "status" or similar. From tsegismo at redhat.com Tue Nov 10 07:10:12 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 13:10:12 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> Message-ID: <5641DEA4.5010605@redhat.com> Le 10/11/2015 00:33, Stefan Negrea a ?crit : > I never said something is broken. The document is meant to be an iteration over what we have today. More precisely, contains two proposals for moving forward with an unified communication channel. And also there is a proposal for a new feature. I asked for feedback on those two communication methods to adopt one; with the goal to support the newly proposed feature. > > The current implementation is not broken for the current use cases (the integration in Hawkular). But that is not the point, and neither did I claim that is broken. It's not about fixing something that is broken but about creating something new. Just one example, a distributed environment with multiple Metrics and Alerts deployments will just not work with what is there today. And that was discussed thoroughly prior to making the document public. > > Thomas, you are yet to propose an alternative Phase 1 (or 0); or even changes to the current document. Stefan I have read the document carefully, I can't give my opinion on a plan or propose an alternative if I don't get its fundamental motivations. I wish they had been discussed here before any plan is made up. I am trying to figure out why Hawkular is not the Metrics + Alerts integration which is looked for. It seems like a legitimate questioning to me, considering: - the plan described in the document involves creating a new component integration mechanism - the feature used as an illustration is already implemented in Hawkular From your last reply, it seems that this fundamental problem is the assumption that different component (Metrics, Alerts) and broker instances in a distributed environment will not work. Why wouldn't it? If there are other motivations, I would like to hear them. From snegrea at redhat.com Tue Nov 10 11:25:18 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 11:25:18 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> Message-ID: <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> > > Can you elaborate on why what is in place today will not work with a > distributed environment with multiple Metrics and Alerts deployments? The user-facing feature proposed in the document will require request-reply communication with endpoints in Alerts. Also, there is the part about introducing a filtering mechanism for publishing only metrics of interest to Alerts. This also requires request-reply communication between the two services; the end-points are not implemented in any of the services but I do not see a reason not to make them in public REST API. So just for Phase 0, we will need a good number (5 or 6) of request-reply operations exposed over the communication channel. I am 100% sure in Phase 1 we will come up with some more features and will require more request-reply operations, so we might as well extend this to the all the public API in Phase 0. A goal for Phase 0 as stated in the document is to extend the public API currently in place in both service over the communication channel that we chose. There are two proposals in the document and both can achieve this: 1) Collocate one Metrics and one Alert instance in every single jvm (or container) and then make use of the existing public REST API over the local interface to communicate between the two components. a) No changes to the code in either service, just invoke the local public API interface of the other service when required to communicate. b) Publishing of metrics insertion events will happen over the REST interface too; no longer use JMS. c) Distribution and load-balancing is done at the component level. For example: if Alerts needs to distribute the load across all the nodes deployed, it will be doing with its own mechanism. d) The challenge here is backpressure and availability of services. The expectation is that the collocated services will be able to handle the load that goes from one instance to the other. 2) Use JMS as the communication channel and then publish the REST API over JMS. And by "publishing the REST API over JMS", I mean making every single public end-point available over the JMS channel so there is no need in future phase to tinker with this. If we put in place a generic solution, we will never have to touch this again and we will have the side-effect of never having to think what is available between the two services; we will just focus on building features. a) No changes to the way metric insertion events are published, they will keep going over JMS. Future event types will go over JMS too. b) Metrics and Alerts components talk over JMS exclusively; the request-reply communication will most likely happen over temporary queue. c) The bus will facilitate some (or all) of the load distribution between components. c) The challenge with this approach is how to publish the public API over JMS. It's actually easy and I have a prototype, so it's just a matter of exploring more and finding a reasonable solution. We could also do a hybrid: collocated services, keep JMS for metric insertion events, everything else over local REST calls. After this long introduction, there are three main reasons the current solution needs improvements: 1) Addressability -> the current solution does not work in the distributed environment because there is no clear way how to access the public API of the services deployed. Let's say the installation spread across 5 containers. How can I make a public API call from a Metrics instance to an Alerts instance. There is no directory to know where the Alerts or Metrics instances are deployed. 2) Load distribution -> there is no clear way on how the load distribution works or who is responsible for it. 3) Availability of the existing public API -> There is no reason to implement a new API just for the purposes of communicating between the components. Given that we strive for this micro-service architecture, the one and single public API should be the main method for communicating between components for request-reply. We might need to extend what we have but the public API should be front and centre. So if we use JMS or HTTP (or both, or UDP, or any other method), the public API interface should be available over all the channels. Sure there might be difference on how to make a request in JMS vs HTTP (one with temporary queues, and the other with direct http connections) but the functionality should be identical. Thank you, Stefan > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Tue Nov 10 11:52:06 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 11:52:06 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56412383.1060406@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <56412383.1060406@redhat.com> Message-ID: <1368592762.8461209.1447174326427.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jay Shaughnessy" > To: hawkular-dev at lists.jboss.org > Sent: Monday, November 9, 2015 4:51:47 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > > I guess what Stefan is trying to figure out is whether it makes sense > and is useful to have Metrics use Alerts basically as a 3rd party tool, > such that a potential Metrics client can focus on using Metrics and not > worry about interacting with Alerts directly. The proposal to me looks > like an attempt to identify one of possibly many Metrics "events" that a > user may be interesting in setting up for notification, in this case via > a webhook. So here we have proposed a MetricReported event (or was it > MetricValueChanged?). I don't know exactly what other events would be > useful, but perhaps there are a lot of Metrics happenings that a client > may want to be notified of. It's not necessarily true that a client > could do this by using the two tools independently, if in fact Metrics > is adding hooks in its own processing to identify these "listenable > events". But I don't get the feeling this is the proposal on the table, > at least not for this first proposal. Instead, I think to handle > MetricReported the idea may have been to just create a trigger that > looks for the specific metric data coming in and to fire an alert. In > which case it is perhaps not as useful to have Metrics set it up, but > it's still maybe a step towards Metrics coming up with some sort of > useful API that would leverage Alerts for its impl. Interesting idea to have other event types, not just metric insertions; that is definitely something to explore. You are correct, the goal of this phase is not explore those ideas, but this is a required precursor. We need to make a first attempt on inter-component communication. > > As for deployment, it seems to me that a prepackaged Metrics+Alerts+Bus, > that could [eventually] be replicated/clustered, would be good. It > could handle use cases where data is persisted and then pushed to the > bus (like in hawkular), and then filtered and grabbed by alerts via a > topic consumer. And it could handle REST interaction. And it could > offer the ability to leverage co-located clients as well. Excellent point! That is the exact goal, to deliver a Metrics+Alerts package that can be used in environments where other features of Hawkular are not relevant. And vice-versa, there might be features implemented by this combined package that will never ever be relevant to Hawkular. We afford this kind of flexibility because of the microservice approach we took. That is why the decision to split everything into components was made, right? > > By the way, there is still the integration component I put together a > while ago, that is completely independent of this discussion. It's an > external alerter that is both a client of metrics and alerts, and > generates alerts based on the results of aggregate queries performed > against metrics. I would prefer to port all that functionality to the architecture we decide through these discussions. > > > On 11/9/2015 12:48 PM, Thomas Segismont wrote: > > Le 09/11/2015 18:10, Stefan Negrea a ?crit : > >> Hello Thomas, > >> > >> So far there is no concrete proposal, only why things should not be done; > >> which equates to inaction. I am not the most imaginative person on the > >> planet so I might fail on that front, but I think the plan that I > >> proposed had some cohesion and it was forward looking. > >> > >> > >> Here is a good course of action: > >> 1) Propose something new; completely new or partially new > >> 2) Get the majority of the group (Metrics + Alerts teams) to agree on the > >> path > >> 3) Create the plan to accomplish it and lead the group to implement the > >> plan > > I understand the goals of your proposal. I'm simply opposed to > > re-writing what already exists, unless it is proven that it is broken. > > > > Given the stress you rightfully put on moving fast, improving the > > existing system seems like a reasonable approach. > > > > Now maybe you didn't know the features are already there, but they are. > > > >> > >> Thank you, > >> Stefan Negrea > >> > >> ----- Original Message ----- > >>> From: "Thomas Segismont" > >>> To: hawkular-dev at lists.jboss.org > >>> Sent: Monday, November 9, 2015 10:43:26 AM > >>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > >>> > >>> Le 09/11/2015 16:48, Stefan Negrea a ?crit : > >>>> Hello, > >>>> > >>>> That document uses what is already implemented as a base. Phase 0 (a > >>>> prototype phase) should take the current implementation to the next > >>>> level. > >>>> All the things in the document where logical increments to what we have > >>>> today. The goal was to have a quick Phase 0 to build something that we > >>>> can > >>>> get feedback on. > >>> The use case detailed in the example is already possible with a Hawkular > >>> server. > >>> > >>> I don't understand what taking the "current implementation to the next > >>> level" means. > >>> > >>>> As for the requirements, there are no requirement and there will > >>>> probably > >>>> be very little requirements. There is no external entity to give us some > >>>> requirements at this stage. If you consider that what is proposed in the > >>>> document is wrong, I open to suggestions. However, I caution against > >>>> inaction or slow action. > >>>> > >>> The use case detailed in the document is fine. But there's no need to > >>> prototype an integration if it already exists. > >>> > >>>> Whatever we do should follow two basic principles: > >>>> 1) Fast phase, 2-3 weeks of development > >>>> 2) Build something simple that enables more complicated features in the > >>>> future > >>>> > >>> I have yet to see a feature which requires to rebuild a new integration > >>> mechanism. > >>> > >>>> More replies inline below .... > >>>> > >>>> > >>>> Thank you, > >>>> Stefan > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Thomas Segismont" > >>>>> To: hawkular-dev at lists.jboss.org > >>>>> Sent: Monday, November 9, 2015 9:16:48 AM > >>>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase > >>>>> 0 > >>>>> > >>>>> Hi, > >>>>> > >>>>> Phase 0 is already implemented: > >>>>> - Metrics can receive data over HTTP > >>>>> - Metrics can publish inserted data to the bus > >>>>> - Webhooks can be created/configured via the Alerts API > >>>>> - Alerts is able to consume data from the bus > >>>> That is not what the document states as goals for Phase 0. As the > >>>> document > >>>> is written what you described is a prerequisite for Phase 0. > >>> From Google docs: > >>> "This document has two parts. First are the details about how to > >>> exchange data between the two services. And then, there is a description > >>> of a simple feature that can showcase the integration." > >>> > >>> 1. Data exchange between the two services is already implemented. > >>> 2. The user facing feature is already possible with a Hawkular server. > >>> > >>> So phase 0 is over. Period. > >>> > >>>>> I can't see why we need to expose an endpoint in Metrics API to setup a > >>>>> set of conditions in Alerts. The Alerts API does the job. > >>>> Disconnected APIs are not an integrated solutions. Just as an example, > >>>> the > >>>> are issues with the maturity of the APIs on both ends. Until we go > >>>> through > >>>> the exercise of trying to integrate the two in a user facing feature we > >>>> will not see the differences or be able to provide something meaningful > >>>> to > >>>> users. > >>> What does disconnected mean? That they are not implemented by the same > >>> software component? In this case it's not a problem. > >>> > >>> The webhook API won't be more mature because it's re-written from Alerts > >>> into Metrics. Maybe I missed your point. > >>> > >>> Integration of Alerts and Metrics has been demonstrated and used this > >>> very afternoon at Devoxx by Cl?ment in the vertx workshop. I'd bet no > >>> attendee (other than Juca) did notice there was 2 software components > >>> behind the service. > >>> > >>> Truth is the scenario described in the document lacks an integration > >>> test. I believe this could be added to: > >>> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test > >>> > >>>>> Do you already know the use cases for Phase 1? > >>>> There are no requirements, and probably there will be no requirements in > >>>> the next month (or even more). That is not the way to approach this. > >>> From my POV, the way to approach this is to write documentation and > >>> tests for all the awesome features which already work but people > >>> (including in our community) aren't aware of. > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.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 Nov 10 12:09:08 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 10 Nov 2015 12:09:08 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> Message-ID: <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> > On Nov 10, 2015, at 11:25 AM, Stefan Negrea wrote: > >> >> Can you elaborate on why what is in place today will not work with a >> distributed environment with multiple Metrics and Alerts deployments? > > The user-facing feature proposed in the document will require request-reply communication with endpoints in Alerts. Also, there is the part about introducing a filtering mechanism for publishing only metrics of interest to Alerts. This also requires request-reply communication between the two services; the end-points are not implemented in any of the services but I do not see a reason not to make them in public REST API. > > So just for Phase 0, we will need a good number (5 or 6) of request-reply operations exposed over the communication channel. I am 100% sure in Phase 1 we will come up with some more features and will require more request-reply operations, so we might as well extend this to the all the public API in Phase 0. A goal for Phase 0 as stated in the document is to extend the public API currently in place in both service over the communication channel that we chose. > > There are two proposals in the document and both can achieve this: > 1) Collocate one Metrics and one Alert instance in every single jvm (or container) and then make use of the existing public REST API over the local interface to communicate between the two components. > a) No changes to the code in either service, just invoke the local public API interface of the other service when required to communicate. There should be no changes to the service implementations regardless of how components communicate. When changes were recently made in H-Metrics to push data onto the bus, there was no change in the service, just changes to support forwarding data to other interested parties. Some sort of changes will be necessary to forward data, regardless of whether we forward data using the REST API, JMS, or something else. > b) Publishing of metrics insertion events will happen over the REST interface too; no longer use JMS. > c) Distribution and load-balancing is done at the component level. For example: if Alerts needs to distribute the load across all the nodes deployed, it will be doing with its own mechanism. > d) The challenge here is backpressure and availability of services. The expectation is that the collocated services will be able to handle the load that goes from one instance to the other. Sorry, but I think that is a naive expectation. We are talking about a distributed environment in which we want to be scalable. That to me means expect and plan for failure not *if* but *when*, so please tell me how we handle load/backpressure when do everything, including inter-component communication, via REST. I suspect we will end up implementing functionality already provided by messaging systems. > > 2) Use JMS as the communication channel and then publish the REST API over JMS. And by "publishing the REST API over JMS", I mean making every single public end-point available over the JMS channel so there is no need in future phase to tinker with this. If we put in place a generic solution, we will never have to touch this again and we will have the side-effect of never having to think what is available between the two services; we will just focus on building features. > a) No changes to the way metric insertion events are published, they will keep going over JMS. Future event types will go over JMS too. > b) Metrics and Alerts components talk over JMS exclusively; the request-reply communication will most likely happen over temporary queue. > c) The bus will facilitate some (or all) of the load distribution between components. > c) The challenge with this approach is how to publish the public API over JMS. It's actually easy and I have a prototype, so it's just a matter of exploring more and finding a reasonable solution. > > We could also do a hybrid: collocated services, keep JMS for metric insertion events, everything else over local REST calls. > > > After this long introduction, there are three main reasons the current solution needs improvements: > > 1) Addressability -> the current solution does not work in the distributed environment because there is no clear way how to access the public API of the services deployed. Let's say the installation spread across 5 containers. How can I make a public API call from a Metrics instance to an Alerts instance. There is no directory to know where the Alerts or Metrics instances are deployed. Addressability is provided by the messaging system. There is no need for a directory. You just to need to communicate with the messaging server/broker. Beyond that there are a lot of features around addressability and routing such as message selectors, message grouping, hierarchical topics, and more. > 2) Load distribution -> there is no clear way on how the load distribution works or who is responsible for it. Again, this is largely handled by the messaging system. Multiple consumers take messages from a queue where each message corresponds to work to be done. > 3) Availability of the existing public API -> There is no reason to implement a new API just for the purposes of communicating between the components. Given that we strive for this micro-service architecture, the one and single public API should be the main method for communicating between components for request-reply. I do not think it is a given that we strive for a micro-service architecture. It might make more sense in an OpenShift environment, but I don?t think it necessarily does in general. > We might need to extend what we have but the public API should be front and centre. So if we use JMS or HTTP (or both, or UDP, or any other method), the public API interface should be available over all the channels. Sure there might be difference on how to make a request in JMS vs HTTP (one with temporary queues, and the other with direct http connections) but the functionality should be identical. I don?t know that I agree with this. Suppose we decide to offer an API for inserting metric data over UDP to support really high throughput situations. Are you suggesting for example that the operations we provide via REST for reading metric data should also be available via the UDP API? And since the motivation for a UDP API is performance/throughput, we might event want to a more compact request format than JSON. Lastly and most importantly, if you want push for an alternative communication mechanism between components in H-Metrics and H-Alerts, then you push for the same across all of Hawkular because it does not make to have to support two different mechanisms. From snegrea at redhat.com Tue Nov 10 12:57:20 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 12:57:20 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> Message-ID: <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> The goal of this phase is to explore a few possibilities, come up with a decent solution, prototype and get feedback. I know there are flaws in all the proposals, otherwise we would have selected one already. I would like to refocus the discussion on working towards a concrete proposal to implement. > > > > There are two proposals in the document and both can achieve this: > > 1) Collocate one Metrics and one Alert instance in every single jvm (or > > container) and then make use of the existing public REST API over the > > local interface to communicate between the two components. > > a) No changes to the code in either service, just invoke the local public > > API interface of the other service when required to communicate. > > There should be no changes to the service implementations regardless of how > components communicate. When changes were recently made in H-Metrics to push > data onto the bus, there was no change in the service, just changes to > support forwarding data to other interested parties. Some sort of changes > will be necessary to forward data, regardless of whether we forward data > using the REST API, JMS, or something else. I would like to avoid as much as possible having fragmented public APIs for a component. With so many components, that will be our nemesis. Think about publishing those APIs in a 1.0 release and having to maintain them, deprecate them, and fix them. If we can keep a single unified public interface into a service, we will be able to spend time focused on features, not on maintenance. A single public API is much better than having special purpose APIs over different channels. I do not want to have to answer questions like, "is the tenant-id required when I insert metrics over JMS?", or "what is the request structure for querying metrics over UDP?". Now, realistically we will have to optimize for performance, hence idea of the "fireshose" as described in the document. But selecting to move something to the "firehose" should be a concious decision made for very specific reasons; the default should be public published API. > > > b) Publishing of metrics insertion events will happen over the REST > > interface too; no longer use JMS. > > c) Distribution and load-balancing is done at the component level. For > > example: if Alerts needs to distribute the load across all the nodes > > deployed, it will be doing with its own mechanism. > > d) The challenge here is backpressure and availability of services. The > > expectation is that the collocated services will be able to handle the > > load that goes from one instance to the other. > > Sorry, but I think that is a naive expectation. We are talking about a > distributed environment in which we want to be scalable. That to me means > expect and plan for failure not *if* but *when*, so please tell me how we > handle load/backpressure when do everything, including inter-component > communication, via REST. I suspect we will end up implementing functionality > already provided by messaging systems. But here is another more simpler to look based on the first proposal. Since there are multiple instances deployed, the expectation is that there will be a proxy in front of them. If the proxy is round-robin (or any other load balancing technique), that means any particular M+A instance will get hit randomly. If one of them fails, the user will have a failure returned, and then retry the request which will be routed to a different server. We add logic to note and count these failures in a M+A instance and shut it down after it reaches a threshold. >From the discussions with Alerts folks, there are plans to implement a load distribution mechanism only for their purpose. Metrics is stateless at this stage and from the early designs will most like implement a different load distribution mechanism. So what does the bus add? Communication redundancy? We can have the user retry a failed attempt if a particular M+A instance is no longer viable. So the inconvenience here is the user might have to retry an operation. While we gain on the API front by using a single public API that is well known, documented, and tested. Trade-offs, trade-offs ... > > > > > 2) Use JMS as the communication channel and then publish the REST API over > > JMS. And by "publishing the REST API over JMS", I mean making every single > > public end-point available over the JMS channel so there is no need in > > future phase to tinker with this. If we put in place a generic solution, > > we will never have to touch this again and we will have the side-effect of > > never having to think what is available between the two services; we will > > just focus on building features. > > a) No changes to the way metric insertion events are published, they will > > keep going over JMS. Future event types will go over JMS too. > > b) Metrics and Alerts components talk over JMS exclusively; the > > request-reply communication will most likely happen over temporary queue. > > c) The bus will facilitate some (or all) of the load distribution between > > components. > > c) The challenge with this approach is how to publish the public API over > > JMS. It's actually easy and I have a prototype, so it's just a matter of > > exploring more and finding a reasonable solution. > > > > We could also do a hybrid: collocated services, keep JMS for metric > > insertion events, everything else over local REST calls. > > > > > > After this long introduction, there are three main reasons the current > > solution needs improvements: > > > > 1) Addressability -> the current solution does not work in the distributed > > environment because there is no clear way how to access the public API of > > the services deployed. Let's say the installation spread across 5 > > containers. How can I make a public API call from a Metrics instance to an > > Alerts instance. There is no directory to know where the Alerts or Metrics > > instances are deployed. > > Addressability is provided by the messaging system. There is no need for a > directory. You just to need to communicate with the messaging server/broker. > Beyond that there are a lot of features around addressability and routing > such as message selectors, message grouping, hierarchical topics, and more. Both solutions solve this in a form or another; it's about the trade-offs and what choices to make. > > > 2) Load distribution -> there is no clear way on how the load distribution > > works or who is responsible for it. > > Again, this is largely handled by the messaging system. Multiple consumers > take messages from a queue where each message corresponds to work to be > done. JMS solves load distribution for messaging, nothing more. But as a tread-off we will need to make the public API available over JMS if we are to go with the second proposal. > > > 3) Availability of the existing public API -> There is no reason to > > implement a new API just for the purposes of communicating between the > > components. Given that we strive for this micro-service architecture, the > > one and single public API should be the main method for communicating > > between components for request-reply. > > I do not think it is a given that we strive for a micro-service architecture. > It might make more sense in an OpenShift environment, but I don?t think it > necessarily does in general. > > > > We might need to extend what we have but the public API should be front and > > centre. So if we use JMS or HTTP (or both, or UDP, or any other method), > > the public API interface should be available over all the channels. Sure > > there might be difference on how to make a request in JMS vs HTTP (one > > with temporary queues, and the other with direct http connections) but the > > functionality should be identical. > > I don?t know that I agree with this. Suppose we decide to offer an API for > inserting metric data over UDP to support really high throughput situations. > Are you suggesting for example that the operations we provide via REST for > reading metric data should also be available via the UDP API? And since the > motivation for a UDP API is performance/throughput, we might event want to a > more compact request format than JSON. As I said early, unless this particular API is upgraded to "firehose", it should have an identical structure as the HTTP REST counter-part. The emphasis here is "structure", such as routing address, request content, and response content. For example, if tenant-id is required on one it should be required on both. > > Lastly and most importantly, if you want push for an alternative > communication mechanism between components in H-Metrics and H-Alerts, then > you push for the same across all of Hawkular because it does not make to > have to support two different mechanisms. I do not understand this contention point. The alternatives on the table are JMS and REST over HTTP. Both of these are in Hawkular today. All what the document proposes up to this point is to take one of those alternatives and deliver more functional on top of that foundation (I outlined in my previous email the differences between alternatives). I also mentioned in my previous email the hybrid approach: collocated services, keep JMS for metric insertion events, keep all the other inter-component communication over local REST calls (it's a mix between 1 and 2 above). That is exactly Hawkular with an extension to add needed pieces, such as event filtering and implementing the features purposed in the document. Do you see even this proposal a departure from the current Hawkular architecture? > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Tue Nov 10 13:09:59 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 10 Nov 2015 13:09:59 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> Message-ID: <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> It is a little bit hard to jump into this long threads but interesting. I am going to describe my thoughts if that can help (or not) into this discussion. I think before to get into low level details, it is good to discuss perhaps in some high level motivations as ThomasS commented, and that might help to check in we are everyone in the same page. Today (if I am not wrong) we have three/four main scenarios where our efforts are driven: - A standalone use of Hawkular Metrics (mainly for OpenShift). - Hawkular, a integrated project of several components/subproject (bus,accounts,metrics,alerts,inventory,agent,ui,new ones). - Hawkular BTM (not sure if this will be consumed as part of Hawkular as add-on, or a variant). - Hawkular DataMining module (not sure if this will be consumed as part of Hawkular as add-on, or a variant). It happens as our components are decoupled and can be consumed separately, so it could be valid if the same user that is using metrics in standalone can add alerts too to work together, but probably that user is not interested in the full Hawkular solution as it has developed its own security, feeds and inventory frameworks (or any combination). So, for me, a legitimate question could be: "how easy it can be to put two components working together?". That I think is what we are discussing here. So, if a user can deploy a metrics.war and alerts.war in the deployments folder on a standard wildfly server, that could be interesting an attractive for everyone (or at least that I think is our main motivation for this discussion). And it can be worth to study what we need to do this, if we might have some limitation in terms of scalability (if any, which is something read but not discussed in deep, several strong statements about architecture but that needs to be ellaborated). If at the end, we reach to a conclusion that communication between components needs an extra effort, I have my conclusion clear: we need to go through Hawkular, not replicating things, or in other words, focus all efforst in a single solution that can be used in several scenarios. From jsanda at redhat.com Tue Nov 10 13:31:49 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 10 Nov 2015 13:31:49 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> Message-ID: <4C09E818-48BD-4182-BAC8-BBAC828F53FA@redhat.com> > On Nov 10, 2015, at 1:09 PM, Lucas Ponce wrote: > > It is a little bit hard to jump into this long threads but interesting. > > I am going to describe my thoughts if that can help (or not) into this discussion. > > I think before to get into low level details, it is good to discuss perhaps in some high level motivations as ThomasS commented, and that might help to check in we are everyone in the same page. > > Today (if I am not wrong) we have three/four main scenarios where our efforts are driven: > > - A standalone use of Hawkular Metrics (mainly for OpenShift). > > - Hawkular, a integrated project of several components/subproject (bus,accounts,metrics,alerts,inventory,agent,ui,new ones). > > - Hawkular BTM (not sure if this will be consumed as part of Hawkular as add-on, or a variant). > > - Hawkular DataMining module (not sure if this will be consumed as part of Hawkular as add-on, or a variant). > > It happens as our components are decoupled and can be consumed separately, so it could be valid if the same user that is using metrics in standalone can add alerts too to work together, but probably that user is not interested in the full Hawkular solution as it has developed its own security, feeds and inventory frameworks (or any combination). > > So, for me, a legitimate question could be: "how easy it can be to put two components working together?". > > That I think is what we are discussing here. > > So, if a user can deploy a metrics.war and alerts.war in the deployments folder on a standard wildfly server, that could be interesting an attractive for everyone (or at least that I think is our main motivation for this discussion). I will provide a demo/code review of this tomorrow during the weekly metrics meeting. From jsanda at redhat.com Tue Nov 10 13:47:46 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 10 Nov 2015 13:47:46 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> Message-ID: > On Nov 10, 2015, at 12:57 PM, Stefan Negrea wrote: > > > The goal of this phase is to explore a few possibilities, come up with a decent solution, prototype and get feedback. I know there are flaws in all the proposals, otherwise we would have selected one already. I would like to refocus the discussion on working towards a concrete proposal to implement. > >>> >>> There are two proposals in the document and both can achieve this: >>> 1) Collocate one Metrics and one Alert instance in every single jvm (or >>> container) and then make use of the existing public REST API over the >>> local interface to communicate between the two components. >>> a) No changes to the code in either service, just invoke the local public >>> API interface of the other service when required to communicate. >> >> There should be no changes to the service implementations regardless of how >> components communicate. When changes were recently made in H-Metrics to push >> data onto the bus, there was no change in the service, just changes to >> support forwarding data to other interested parties. Some sort of changes >> will be necessary to forward data, regardless of whether we forward data >> using the REST API, JMS, or something else. > > I would like to avoid as much as possible having fragmented public APIs for a component. With so many components, that will be our nemesis. Think about publishing those APIs in a 1.0 release and having to maintain them, deprecate them, and fix them. If we can keep a single unified public interface into a service, we will be able to spend time focused on features, not on maintenance. A single public API is much better than having special purpose APIs over different channels. I do not want to have to answer questions like, "is the tenant-id required when I insert metrics over JMS?", or "what is the request structure for querying metrics over UDP?". > > Now, realistically we will have to optimize for performance, hence idea of the "fireshose" as described in the document. But selecting to move something to the "firehose" should be a concious decision made for very specific reasons; the default should be public published API. > >> >>> b) Publishing of metrics insertion events will happen over the REST >>> interface too; no longer use JMS. >>> c) Distribution and load-balancing is done at the component level. For >>> example: if Alerts needs to distribute the load across all the nodes >>> deployed, it will be doing with its own mechanism. >>> d) The challenge here is backpressure and availability of services. The >>> expectation is that the collocated services will be able to handle the >>> load that goes from one instance to the other. >> >> Sorry, but I think that is a naive expectation. We are talking about a >> distributed environment in which we want to be scalable. That to me means >> expect and plan for failure not *if* but *when*, so please tell me how we >> handle load/backpressure when do everything, including inter-component >> communication, via REST. I suspect we will end up implementing functionality >> already provided by messaging systems. > > But here is another more simpler to look based on the first proposal. Since there are multiple instances deployed, the expectation is that there will be a proxy in front of them. If the proxy is round-robin (or any other load balancing technique), that means any particular M+A instance will get hit randomly. If one of them fails, the user will have a failure returned, and then retry the request which will be routed to a different server. We add logic to note and count these failures in a M+A instance and shut it down after it reaches a threshold. > > From the discussions with Alerts folks, there are plans to implement a load distribution mechanism only for their purpose. Metrics is stateless at this stage and from the early designs will most like implement a different load distribution mechanism. So what does the bus add? Communication redundancy? We can have the user retry a failed attempt if a particular M+A instance is no longer viable. > > So the inconvenience here is the user might have to retry an operation. While we gain on the API front by using a single public API that is well known, documented, and tested. Trade-offs, trade-offs ... > >> >>> >>> 2) Use JMS as the communication channel and then publish the REST API over >>> JMS. And by "publishing the REST API over JMS", I mean making every single >>> public end-point available over the JMS channel so there is no need in >>> future phase to tinker with this. If we put in place a generic solution, >>> we will never have to touch this again and we will have the side-effect of >>> never having to think what is available between the two services; we will >>> just focus on building features. >>> a) No changes to the way metric insertion events are published, they will >>> keep going over JMS. Future event types will go over JMS too. >>> b) Metrics and Alerts components talk over JMS exclusively; the >>> request-reply communication will most likely happen over temporary queue. >>> c) The bus will facilitate some (or all) of the load distribution between >>> components. >>> c) The challenge with this approach is how to publish the public API over >>> JMS. It's actually easy and I have a prototype, so it's just a matter of >>> exploring more and finding a reasonable solution. >>> >>> We could also do a hybrid: collocated services, keep JMS for metric >>> insertion events, everything else over local REST calls. >>> >>> >>> After this long introduction, there are three main reasons the current >>> solution needs improvements: >>> >>> 1) Addressability -> the current solution does not work in the distributed >>> environment because there is no clear way how to access the public API of >>> the services deployed. Let's say the installation spread across 5 >>> containers. How can I make a public API call from a Metrics instance to an >>> Alerts instance. There is no directory to know where the Alerts or Metrics >>> instances are deployed. >> >> Addressability is provided by the messaging system. There is no need for a >> directory. You just to need to communicate with the messaging server/broker. >> Beyond that there are a lot of features around addressability and routing >> such as message selectors, message grouping, hierarchical topics, and more. > > > Both solutions solve this in a form or another; it's about the trade-offs and what choices to make. > >> >>> 2) Load distribution -> there is no clear way on how the load distribution >>> works or who is responsible for it. >> >> Again, this is largely handled by the messaging system. Multiple consumers >> take messages from a queue where each message corresponds to work to be >> done. > > JMS solves load distribution for messaging, nothing more. But as a tread-off we will need to make the public API available over JMS if we are to go with the second proposal. > >> >>> 3) Availability of the existing public API -> There is no reason to >>> implement a new API just for the purposes of communicating between the >>> components. Given that we strive for this micro-service architecture, the >>> one and single public API should be the main method for communicating >>> between components for request-reply. >> >> I do not think it is a given that we strive for a micro-service architecture. >> It might make more sense in an OpenShift environment, but I don?t think it >> necessarily does in general. >> >> >>> We might need to extend what we have but the public API should be front and >>> centre. So if we use JMS or HTTP (or both, or UDP, or any other method), >>> the public API interface should be available over all the channels. Sure >>> there might be difference on how to make a request in JMS vs HTTP (one >>> with temporary queues, and the other with direct http connections) but the >>> functionality should be identical. >> >> I don?t know that I agree with this. Suppose we decide to offer an API for >> inserting metric data over UDP to support really high throughput situations. >> Are you suggesting for example that the operations we provide via REST for >> reading metric data should also be available via the UDP API? And since the >> motivation for a UDP API is performance/throughput, we might event want to a >> more compact request format than JSON. > > As I said early, unless this particular API is upgraded to "firehose", it should have an identical structure as the HTTP REST counter-part. The emphasis here is "structure", such as routing address, request content, and response content. For example, if tenant-id is required on one it should be required on both. > >> >> Lastly and most importantly, if you want push for an alternative >> communication mechanism between components in H-Metrics and H-Alerts, then >> you push for the same across all of Hawkular because it does not make to >> have to support two different mechanisms. > > I do not understand this contention point. The alternatives on the table are JMS and REST over HTTP. Both of these are in Hawkular today. All what the document proposes up to this point is to take one of those alternatives and deliver more functional on top of that foundation (I outlined in my previous email the differences between alternatives). > > I also mentioned in my previous email the hybrid approach: collocated services, keep JMS for metric insertion events, keep all the other inter-component communication over local REST calls (it's a mix between 1 and 2 above). That is exactly Hawkular with an extension to add needed pieces, such as event filtering and implementing the features purposed in the document. Do you see even this proposal a departure from the current Hawkular architecture? Yes, I do see the proposals as a departure from the current Hawkuar architecture which I think is the most important aspect of the whole discussion. Let?s review the current state of Hawkular with respect to the discussion. The public APIs in Hawkular are the REST APIs. The REST APIs are the only ?supported? public APIs. Components and services in Hawkular communicate with each other via the bus, i.e., JMS. To the best of my knowledge,the APIs we implement over JMS are for internal communication between components running in the Hawkular server (regardless of whether those components are co-located in or separate processes). I am not aware of any other plans, discussions, etc., to have the all of the REST API also expose via JMS. Based on these things, it does seem like your proposals are a departure from the current architecture. From snegrea at redhat.com Tue Nov 10 13:56:44 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 13:56:44 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> Message-ID: <33395880.8554291.1447181804508.JavaMail.zimbra@redhat.com> > >> > >> Lastly and most importantly, if you want push for an alternative > >> communication mechanism between components in H-Metrics and H-Alerts, then > >> you push for the same across all of Hawkular because it does not make to > >> have to support two different mechanisms. > > > > I do not understand this contention point. The alternatives on the table > > are JMS and REST over HTTP. Both of these are in Hawkular today. All what > > the document proposes up to this point is to take one of those > > alternatives and deliver more functional on top of that foundation (I > > outlined in my previous email the differences between alternatives). > > > > I also mentioned in my previous email the hybrid approach: collocated > > services, keep JMS for metric insertion events, keep all the other > > inter-component communication over local REST calls (it's a mix between 1 > > and 2 above). That is exactly Hawkular with an extension to add needed > > pieces, such as event filtering and implementing the features purposed in > > the document. Do you see even this proposal a departure from the current > > Hawkular architecture? > > Yes, I do see the proposals as a departure from the current Hawkuar > architecture which I think is the most important aspect of the whole > discussion. Let?s review the current state of Hawkular with respect to the > discussion. The public APIs in Hawkular are the REST APIs. The REST APIs are > the only ?supported? public APIs. Components and services in Hawkular > communicate with each other via the bus, i.e., JMS. To the best of my > knowledge,the APIs we implement over JMS are for internal communication > between components running in the Hawkular server (regardless of whether > those components are co-located in or separate processes). I am not aware of > any other plans, discussions, etc., to have the all of the REST API also > expose via JMS. Based on these things, it does seem like your proposals are > a departure from the current architecture. Can you then please walk through how to implement the feature proposed in the document? I can see how it can be done in both proposals I put in the document. I think you might have a different alternative. Do you mind explaining the alternative and walking through the design and implementation? From lponce at redhat.com Tue Nov 10 13:58:06 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 10 Nov 2015 13:58:06 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> Message-ID: <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> > The public APIs in Hawkular are the REST APIs. The REST APIs are > the only ?supported? public APIs. As far as I remember, there was a discussion that Java API is also "supported". That was main reason we tried to unify naming of packaging. For example, all org.hawkular..api packages should be considered also "supportable". So, communication via Java API should be feasible. From jsanda at redhat.com Tue Nov 10 14:08:16 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 10 Nov 2015 14:08:16 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> Message-ID: > On Nov 10, 2015, at 1:58 PM, Lucas Ponce wrote: > > >> The public APIs in Hawkular are the REST APIs. The REST APIs are >> the only ?supported? public APIs. > > As far as I remember, there was a discussion that Java API is also "supported". > > That was main reason we tried to unify naming of packaging. > > For example, all org.hawkular..api packages should be considered also "supportable". > > So, communication via Java API should be feasible. > > I guess this is something that should be discussed and clearly communicated. I have been under the impression, and maybe it is in part due to how things were done in RHQ, that internal Java API could change freely between releases. Users and 3rd party clients are free to use those APIs but at your own risk with respect to backwards compatibility. From snegrea at redhat.com Tue Nov 10 14:09:59 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 14:09:59 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> Message-ID: <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Lucas Ponce" > To: "Discussions around Hawkular development" > Sent: Tuesday, November 10, 2015 12:58:06 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > > > The public APIs in Hawkular are the REST APIs. The REST APIs are > > the only ?supported? public APIs. > > As far as I remember, there was a discussion that Java API is also > "supported". > > That was main reason we tried to unify naming of packaging. > > For example, all org.hawkular..api packages should be considered > also "supportable". > > So, communication via Java API should be feasible. That is an option as long as it works in a distributed environment (think containers and different JVMs; would Java API work there? and how?) and the same interface that is currently exposed on the public REST API is available. > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Tue Nov 10 14:19:30 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 10 Nov 2015 14:19:30 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> Message-ID: <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> > > > > So, communication via Java API should be feasible. > > That is an option as long as it works in a distributed environment (think > containers and different JVMs; would Java API work there? and how?) and the > same interface that is currently exposed on the public REST API is > available. > I'm not thinking as a general option. But I have a wildfly server with metrics.war and alerts.war and mycomponent.war as client under same deployment, why I can't use Java API and I need to use REST between them ? EJB clients are also possible but this was not introduced before and I don't want to do it. But in the first scenario, looking for a user that wants to add its code colocated, the Java API should be the easy one. From ah at tradeworks.io Tue Nov 10 15:00:23 2015 From: ah at tradeworks.io (Anton Hughes) Date: Tue, 10 Nov 2015 21:00:23 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> Message-ID: Hi all Firstly, apologies if this thread is intended for Redhat staff only. My development background is primarily in .net - and so I am writing here to suggest using this instead - joking! chez. But, while working with .net, microsoft release the Windows Communication Foundation framework - basically a framework for abstracting the different messaging systems - how messages are sent over the wire, or in proc - from the implementation. For the past 5 years I have been almost exclusively working in Java and was delighted to see similar concepts in Jboss Switchyard and Apache Camel. In particular, Switchyard allows for a service to be exposed to the world via multiple bindings easily. Camel is also an excellent choice. Personally I would love to see communication to Hawkular using Apache Kafka! Adding a kafak binding in either Switchyard or Camel is a breeze! When it comes to choosing a messaging implementation, I have good success in choosing frameworks that focus on integration and abstracting the specific messaging type. In my company, when we have discussions of should we use rest or jms - we tend to say yes - the answer is in the question. We need a system that easily supports both, and more. If this discussion arises now, it will surely arise again - therefore make the choice of easy integration. Abstract away how the message is sent to being simply a configuration. Kind regards On 10 November 2015 at 20:19, Lucas Ponce wrote: > > > > > > So, communication via Java API should be feasible. > > > > That is an option as long as it works in a distributed environment (think > > containers and different JVMs; would Java API work there? and how?) and > the > > same interface that is currently exposed on the public REST API is > > available. > > > > I'm not thinking as a general option. > > But I have a wildfly server with metrics.war and alerts.war and > mycomponent.war as client under same deployment, why I can't use Java API > and I need to use REST between them ? > > EJB clients are also possible but this was not introduced before and I > don't want to do it. > > But in the first scenario, looking for a user that wants to add its code > colocated, the Java API should be the easy one. > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151110/3765bdb9/attachment.html From ah at tradeworks.io Tue Nov 10 15:03:38 2015 From: ah at tradeworks.io (Anton Hughes) Date: Tue, 10 Nov 2015 21:03:38 +0100 Subject: [Hawkular-dev] REST-api and hyperlinks In-Reply-To: <2D920EBE-2137-42CF-B93C-1432DE4E1BE1@redhat.com> References: <2D920EBE-2137-42CF-B93C-1432DE4E1BE1@redhat.com> Message-ID: This sounds similar to https://en.wikipedia.org/wiki/HATEOAS On 9 November 2015 at 08:10, Heiko W.Rupp wrote: > Hey, > > one cool trait of RESTful apis, which we all use every day hundreds of > times > is the hyperlinking of data - we click on links in the web browser. > > I think that would be pretty good for our apis as well. > To take alerts as an example (see my other mail) > > I can go like GET /triggers/{id} to get a trigger with some data. > Now to learn about the conditions I need to browse to the docs > to potentially find out that I can get them at /triggers/{id}/conditions > > It would be good if we would add for each resource a "Links" section > like: > > links: [ > { > rel='dampening' > href=http://blabla/hawkular/alerts/triggers/{id}/dampening > }, > { > rel='conditions' > href=http://blabla/hawkular/alerts/triggers/{id}/conditions > } > ] > > This way it is relatively easy to follow those for humans, but also > machines. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151110/82304081/attachment-0001.html From hrupp at redhat.com Tue Nov 10 15:15:26 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 10 Nov 2015 21:15:26 +0100 Subject: [Hawkular-dev] REST-api and hyperlinks In-Reply-To: References: <2D920EBE-2137-42CF-B93C-1432DE4E1BE1@redhat.com> Message-ID: On 10 Nov 2015, at 21:03, Anton Hughes wrote: > This sounds similar to https://en.wikipedia.org/wiki/HATEOAS Exactly! From snegrea at redhat.com Tue Nov 10 15:54:05 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 15:54:05 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> Message-ID: <1003145189.8597634.1447188845876.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Anton Hughes" > To: "Discussions around Hawkular development" > Sent: Tuesday, November 10, 2015 2:00:23 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > Hi all > > Firstly, apologies if this thread is intended for Redhat staff only. Thanks for replying. This is not an RH only discussion. This is a public mailing list and feedback like yours is really important to us. > > My development background is primarily in .net - and so I am writing here to > suggest using this instead - joking! chez. > But, while working with .net, microsoft release the Windows Communication > Foundation framework - basically a framework for abstracting the different > messaging systems - how messages are sent over the wire, or in proc - from > the implementation. > > For the past 5 years I have been almost exclusively working in Java and was > delighted to see similar concepts in Jboss Switchyard and Apache Camel. In > particular, Switchyard allows for a service to be exposed to the world via > multiple bindings easily. Camel is also an excellent choice. > > Personally I would love to see communication to Hawkular using Apache Kafka! > Adding a kafak binding in either Switchyard or Camel is a breeze! > > When it comes to choosing a messaging implementation, I have good success in > choosing frameworks that focus on integration and abstracting the specific > messaging type. In my company, when we have discussions of should we use > rest or jms - we tend to say yes - the answer is in the question. We need a > system that easily supports both, and more. My proposal is to have a single public API. I am advocating that if we decide to also support component level communication over JMS at this time, then the structure (functionality exposed, request requirements, and response) of that exchange should be identical with what we currently published for REST over HTTP. And if I understand correctly what you are saying, the concept is <>. > > If this discussion arises now, it will surely arise again - therefore make > the choice of easy integration. Abstract away how the message is sent to > being simply a configuration. That is one of the reasons why I keep pushing for a single public API. The hot transport right now is REST over HTTP. If we are committed to a single public API, not only that API will get better and better over time (because it is the only one used and published) but we can also find ways to leverage it over other channels. > > Kind regards > > On 10 November 2015 at 20:19, Lucas Ponce < lponce at redhat.com > wrote: > > > > > > > > So, communication via Java API should be feasible. > > > > That is an option as long as it works in a distributed environment (think > > containers and different JVMs; would Java API work there? and how?) and the > > same interface that is currently exposed on the public REST API is > > available. > > > > I'm not thinking as a general option. > > But I have a wildfly server with metrics.war and alerts.war and > mycomponent.war as client under same deployment, why I can't use Java API > and I need to use REST between them ? > > EJB clients are also possible but this was not introduced before and I don't > want to do it. > > But in the first scenario, looking for a user that wants to add its code > colocated, the Java API should be the easy one. > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > -- > Anton Hughes > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ah at tradeworks.io Tue Nov 10 15:57:38 2015 From: ah at tradeworks.io (Anton Hughes) Date: Tue, 10 Nov 2015 21:57:38 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1003145189.8597634.1447188845876.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> <1003145189.8597634.1447188845876.JavaMail.zimbra@redhat.com> Message-ID: On 10 November 2015 at 21:54, Stefan Negrea wrote: > The hot transport right now is REST over HTTP. I would say this is a must have. And - I am revealing my age with this - one of the benefits of soap is its self-documenting feature - the wsdl. From my experience REST must have good documentation. From this perspective I recommend swagger. -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151110/772f461b/attachment.html From tsegismo at redhat.com Tue Nov 10 16:06:33 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 22:06:33 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> Message-ID: <56425C59.1020404@redhat.com> Le 10/11/2015 18:09, John Sanda a ?crit : >> After this long introduction, there are three main reasons the current solution needs improvements: >> > >> >1) Addressability -> the current solution does not work in the distributed environment because there is no clear way how to access the public API of the services deployed. Let's say the installation spread across 5 containers. How can I make a public API call from a Metrics instance to an Alerts instance. There is no directory to know where the Alerts or Metrics instances are deployed. > Addressability is provided by the messaging system. There is no need for a directory. You just to need to communicate with the messaging server/broker. Beyond that there are a lot of features around addressability and routing such as message selectors, message grouping, hierarchical topics, and more. +1 > >> >2) Load distribution -> there is no clear way on how the load distribution works or who is responsible for it. > Again, this is largely handled by the messaging system. Multiple consumers take messages from a queue where each message corresponds to work to be done. > Right, load distribution is a feature of the messaging system. As for HTTP load balancing, there is hardware and software dedicated to this, I would avoid building an HTTP load balancer into the project. >> >3) Availability of the existing public API -> There is no reason to implement a new API just for the purposes of communicating between the components. Given that we strive for this micro-service architecture, the one and single public API should be the main method for communicating between components for request-reply. > I do not think it is a given that we strive for a micro-service architecture. It might make more sense in an OpenShift environment, but I don?t think it necessarily does in general. > > >> >We might need to extend what we have but the public API should be front and centre. So if we use JMS or HTTP (or both, or UDP, or any other method), the public API interface should be available over all the channels. Sure there might be difference on how to make a request in JMS vs HTTP (one with temporary queues, and the other with direct http connections) but the functionality should be identical. > I don?t know that I agree with this. Suppose we decide to offer an API for inserting metric data over UDP to support really high throughput situations. Are you suggesting for example that the operations we provide via REST for reading metric data should also be available via the UDP API? And since the motivation for a UDP API is performance/throughput, we might event want to a more compact request format than JSON. > > Lastly and most importantly, if you want push for an alternative communication mechanism between components in H-Metrics and H-Alerts, then you push for the same across all of Hawkular because it does not make to have to support two different mechanisms. The public API (JSON over HTTP) is how the users must interact with the Hawkular platform. It is the unique entry point for the users. It's has been agreed during the project inception to make Hawkular components talk to each other via the bus. It is not a trivial change to break this assumption: everything the bus provides (see above) will need to be re-implemented. That is why I am opposed to the change, unless it is proven that it is a limitation. From tsegismo at redhat.com Tue Nov 10 16:28:11 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 22:28:11 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> Message-ID: <5642616B.7020901@redhat.com> Le 10/11/2015 19:09, Lucas Ponce a ?crit : > It is a little bit hard to jump into this long threads but interesting. > > I am going to describe my thoughts if that can help (or not) into this discussion. > > I think before to get into low level details, it is good to discuss perhaps in some high level motivations as ThomasS commented, and that might help to check in we are everyone in the same page. > > Today (if I am not wrong) we have three/four main scenarios where our efforts are driven: > > - A standalone use of Hawkular Metrics (mainly for OpenShift). > > - Hawkular, a integrated project of several components/subproject (bus,accounts,metrics,alerts,inventory,agent,ui,new ones). > > - Hawkular BTM (not sure if this will be consumed as part of Hawkular as add-on, or a variant). > > - Hawkular DataMining module (not sure if this will be consumed as part of Hawkular as add-on, or a variant). > > It happens as our components are decoupled and can be consumed separately, so it could be valid if the same user that is using metrics in standalone can add alerts too to work together, but probably that user is not interested in the full Hawkular solution as it has developed its own security, feeds and inventory frameworks (or any combination). Right. We need to make sure that, as Hawkular evolves, Alerts and Metrics continue to work together, even when other components are not involved (including accounts and Keycloack). > > So, for me, a legitimate question could be: "how easy it can be to put two components working together?". > > That I think is what we are discussing here. > > So, if a user can deploy a metrics.war and alerts.war in the deployments folder on a standard wildfly server, that could be interesting an attractive for everyone (or at least that I think is our main motivation for this discussion). > > And it can be worth to study what we need to do this, if we might have some limitation in terms of scalability > (if any, which is something read but not discussed in deep, several strong statements about architecture but that needs to be ellaborated). > > If at the end, we reach to a conclusion that communication between components needs an extra effort, I have my conclusion clear: we need to go through Hawkular, not replicating things, or in other words, focus all efforst in a single solution that can be used in several scenarios. As part of the migration to Wildfly 10, we will get rid of the ActiveMQ resource adapter and use the messaging capabilities offered in the container. So yes, when the migration is over, deploying Alerts + Metrics will be a matter of copying the archives to the deployments folder. From snegrea at redhat.com Tue Nov 10 16:36:54 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 16:36:54 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56425C59.1020404@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> Message-ID: <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> Thomas, I will ask the same thing I asked John earlier. Can you then please walk through how to implement the feature proposed in the document? I can see how it can be done in the proposals I put in the document and discussed so far. But looks like you might have a different alternative. Do you mind explaining the alternative and walking through the design and implementation? ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Tuesday, November 10, 2015 3:06:33 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > Le 10/11/2015 18:09, John Sanda a ?crit : > >> After this long introduction, there are three main reasons the current > >> solution needs improvements: > >> > > >> >1) Addressability -> the current solution does not work in the > >> >distributed environment because there is no clear way how to access the > >> >public API of the services deployed. Let's say the installation spread > >> >across 5 containers. How can I make a public API call from a Metrics > >> >instance to an Alerts instance. There is no directory to know where the > >> >Alerts or Metrics instances are deployed. > > Addressability is provided by the messaging system. There is no need for a > > directory. You just to need to communicate with the messaging > > server/broker. Beyond that there are a lot of features around > > addressability and routing such as message selectors, message grouping, > > hierarchical topics, and more. > > +1 > > > > >> >2) Load distribution -> there is no clear way on how the load > >> >distribution works or who is responsible for it. > > Again, this is largely handled by the messaging system. Multiple consumers > > take messages from a queue where each message corresponds to work to be > > done. > > > > Right, load distribution is a feature of the messaging system. As for > HTTP load balancing, there is hardware and software dedicated to this, I > would avoid building an HTTP load balancer into the project. > > >> >3) Availability of the existing public API -> There is no reason to > >> >implement a new API just for the purposes of communicating between the > >> >components. Given that we strive for this micro-service architecture, > >> >the one and single public API should be the main method for > >> >communicating between components for request-reply. > > I do not think it is a given that we strive for a micro-service > > architecture. It might make more sense in an OpenShift environment, but I > > don?t think it necessarily does in general. > > > > > >> >We might need to extend what we have but the public API should be front > >> >and centre. So if we use JMS or HTTP (or both, or UDP, or any other > >> >method), the public API interface should be available over all the > >> >channels. Sure there might be difference on how to make a request in JMS > >> >vs HTTP (one with temporary queues, and the other with direct http > >> >connections) but the functionality should be identical. > > I don?t know that I agree with this. Suppose we decide to offer an API for > > inserting metric data over UDP to support really high throughput > > situations. Are you suggesting for example that the operations we provide > > via REST for reading metric data should also be available via the UDP API? > > And since the motivation for a UDP API is performance/throughput, we might > > event want to a more compact request format than JSON. > > > > Lastly and most importantly, if you want push for an alternative > > communication mechanism between components in H-Metrics and H-Alerts, then > > you push for the same across all of Hawkular because it does not make to > > have to support two different mechanisms. > > > The public API (JSON over HTTP) is how the users must interact with the > Hawkular platform. It is the unique entry point for the users. > > > It's has been agreed during the project inception to make Hawkular > components talk to each other via the bus. It is not a trivial change to > break this assumption: everything the bus provides (see above) will need > to be re-implemented. > That is why I am opposed to the change, unless it is proven that it is a > limitation. > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Tue Nov 10 16:59:08 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 10 Nov 2015 16:59:08 -0500 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> Message-ID: I do not think that proposing a feature is justification for a major departure from the overall architecture. If it were, I am sure some devs would be proposing new features on a regular basis :) > On Nov 10, 2015, at 4:36 PM, Stefan Negrea wrote: > > > > Thomas, I will ask the same thing I asked John earlier. Can you then please walk through how to implement the feature proposed in the document? I can see how it can be done in the proposals I put in the document and discussed so far. But looks like you might have a different alternative. Do you mind explaining the alternative and walking through the design and implementation? > > > > ----- Original Message ----- >> From: "Thomas Segismont" >> To: hawkular-dev at lists.jboss.org >> Sent: Tuesday, November 10, 2015 3:06:33 PM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> Le 10/11/2015 18:09, John Sanda a ?crit : >>>> After this long introduction, there are three main reasons the current >>>> solution needs improvements: >>>>> >>>>> 1) Addressability -> the current solution does not work in the >>>>> distributed environment because there is no clear way how to access the >>>>> public API of the services deployed. Let's say the installation spread >>>>> across 5 containers. How can I make a public API call from a Metrics >>>>> instance to an Alerts instance. There is no directory to know where the >>>>> Alerts or Metrics instances are deployed. >>> Addressability is provided by the messaging system. There is no need for a >>> directory. You just to need to communicate with the messaging >>> server/broker. Beyond that there are a lot of features around >>> addressability and routing such as message selectors, message grouping, >>> hierarchical topics, and more. >> >> +1 >> >>> >>>>> 2) Load distribution -> there is no clear way on how the load >>>>> distribution works or who is responsible for it. >>> Again, this is largely handled by the messaging system. Multiple consumers >>> take messages from a queue where each message corresponds to work to be >>> done. >>> >> >> Right, load distribution is a feature of the messaging system. As for >> HTTP load balancing, there is hardware and software dedicated to this, I >> would avoid building an HTTP load balancer into the project. >> >>>>> 3) Availability of the existing public API -> There is no reason to >>>>> implement a new API just for the purposes of communicating between the >>>>> components. Given that we strive for this micro-service architecture, >>>>> the one and single public API should be the main method for >>>>> communicating between components for request-reply. >>> I do not think it is a given that we strive for a micro-service >>> architecture. It might make more sense in an OpenShift environment, but I >>> don?t think it necessarily does in general. >>> >>> >>>>> We might need to extend what we have but the public API should be front >>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other >>>>> method), the public API interface should be available over all the >>>>> channels. Sure there might be difference on how to make a request in JMS >>>>> vs HTTP (one with temporary queues, and the other with direct http >>>>> connections) but the functionality should be identical. >>> I don?t know that I agree with this. Suppose we decide to offer an API for >>> inserting metric data over UDP to support really high throughput >>> situations. Are you suggesting for example that the operations we provide >>> via REST for reading metric data should also be available via the UDP API? >>> And since the motivation for a UDP API is performance/throughput, we might >>> event want to a more compact request format than JSON. >>> >>> Lastly and most importantly, if you want push for an alternative >>> communication mechanism between components in H-Metrics and H-Alerts, then >>> you push for the same across all of Hawkular because it does not make to >>> have to support two different mechanisms. >> >> >> The public API (JSON over HTTP) is how the users must interact with the >> Hawkular platform. It is the unique entry point for the users. >> >> >> It's has been agreed during the project inception to make Hawkular >> components talk to each other via the bus. It is not a trivial change to >> break this assumption: everything the bus provides (see above) will need >> to be re-implemented. >> That is why I am opposed to the change, unless it is proven that it is a >> limitation. >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Tue Nov 10 17:09:15 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 10 Nov 2015 23:09:15 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> Message-ID: <56426B0B.9030800@redhat.com> - Start a Hawkular server - Use the REST resources under /hawkular/alerts to create a trigger for 'my_fancy_gauge' - Use the REST resources under /hawkular/alerts to create an external condition (my understanding is that such a condition will always evaluate to true if data is received) - Use the REST resources under /hawkular/alerts to create a webhook action - Use the REST resources under /hawkular/metrics to publish data Le 10/11/2015 22:36, Stefan Negrea a ?crit : > > > Thomas, I will ask the same thing I asked John earlier. Can you then please walk through how to implement the feature proposed in the document? I can see how it can be done in the proposals I put in the document and discussed so far. But looks like you might have a different alternative. Do you mind explaining the alternative and walking through the design and implementation? > > > > ----- Original Message ----- >> From: "Thomas Segismont" >> To: hawkular-dev at lists.jboss.org >> Sent: Tuesday, November 10, 2015 3:06:33 PM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> Le 10/11/2015 18:09, John Sanda a ?crit : >>>> After this long introduction, there are three main reasons the current >>>> solution needs improvements: >>>>> >>>>> 1) Addressability -> the current solution does not work in the >>>>> distributed environment because there is no clear way how to access the >>>>> public API of the services deployed. Let's say the installation spread >>>>> across 5 containers. How can I make a public API call from a Metrics >>>>> instance to an Alerts instance. There is no directory to know where the >>>>> Alerts or Metrics instances are deployed. >>> Addressability is provided by the messaging system. There is no need for a >>> directory. You just to need to communicate with the messaging >>> server/broker. Beyond that there are a lot of features around >>> addressability and routing such as message selectors, message grouping, >>> hierarchical topics, and more. >> >> +1 >> >>> >>>>> 2) Load distribution -> there is no clear way on how the load >>>>> distribution works or who is responsible for it. >>> Again, this is largely handled by the messaging system. Multiple consumers >>> take messages from a queue where each message corresponds to work to be >>> done. >>> >> >> Right, load distribution is a feature of the messaging system. As for >> HTTP load balancing, there is hardware and software dedicated to this, I >> would avoid building an HTTP load balancer into the project. >> >>>>> 3) Availability of the existing public API -> There is no reason to >>>>> implement a new API just for the purposes of communicating between the >>>>> components. Given that we strive for this micro-service architecture, >>>>> the one and single public API should be the main method for >>>>> communicating between components for request-reply. >>> I do not think it is a given that we strive for a micro-service >>> architecture. It might make more sense in an OpenShift environment, but I >>> don?t think it necessarily does in general. >>> >>> >>>>> We might need to extend what we have but the public API should be front >>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other >>>>> method), the public API interface should be available over all the >>>>> channels. Sure there might be difference on how to make a request in JMS >>>>> vs HTTP (one with temporary queues, and the other with direct http >>>>> connections) but the functionality should be identical. >>> I don?t know that I agree with this. Suppose we decide to offer an API for >>> inserting metric data over UDP to support really high throughput >>> situations. Are you suggesting for example that the operations we provide >>> via REST for reading metric data should also be available via the UDP API? >>> And since the motivation for a UDP API is performance/throughput, we might >>> event want to a more compact request format than JSON. >>> >>> Lastly and most importantly, if you want push for an alternative >>> communication mechanism between components in H-Metrics and H-Alerts, then >>> you push for the same across all of Hawkular because it does not make to >>> have to support two different mechanisms. >> >> >> The public API (JSON over HTTP) is how the users must interact with the >> Hawkular platform. It is the unique entry point for the users. >> >> >> It's has been agreed during the project inception to make Hawkular >> components talk to each other via the bus. It is not a trivial change to >> break this assumption: everything the bus provides (see above) will need >> to be re-implemented. >> That is why I am opposed to the change, unless it is proven that it is a >> limitation. >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Tue Nov 10 17:20:06 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 17:20:06 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> Message-ID: <1276794346.8626155.1447194005998.JavaMail.zimbra@redhat.com> Hello, Thanks for all the feedback so far. At this time, the best course is to withdraw the proposal altogether. My hope was that we will progress in a positive direction. If I take an impartial look at where this discussion is going I do not see a positive outcome and neither do I see alternative suggestions for any of the points in the document. I will leave the document available for the next few days, but will close access at the end of the week. Again, thanks for all the feedback. Thank you, Stefan From snegrea at redhat.com Tue Nov 10 17:23:36 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 10 Nov 2015 17:23:36 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56426B0B.9030800@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> <56426B0B.9030800@redhat.com> Message-ID: <1802963815.8626834.1447194216703.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Tuesday, November 10, 2015 4:09:15 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > > - Start a Hawkular server > - Use the REST resources under /hawkular/alerts to create a trigger for > 'my_fancy_gauge' > - Use the REST resources under /hawkular/alerts to create an external > condition (my understanding is that such a condition will always > evaluate to true if data is received) > - Use the REST resources under /hawkular/alerts to create a webhook action > - Use the REST resources under /hawkular/metrics to publish data I was afraid of that answer. That was neither the spirit nor the intent of the proposal. > > > Le 10/11/2015 22:36, Stefan Negrea a ?crit : > > > > > > Thomas, I will ask the same thing I asked John earlier. Can you then please > > walk through how to implement the feature proposed in the document? I can > > see how it can be done in the proposals I put in the document and > > discussed so far. But looks like you might have a different alternative. > > Do you mind explaining the alternative and walking through the design and > > implementation? > > > > > > > > ----- Original Message ----- > >> From: "Thomas Segismont" > >> To: hawkular-dev at lists.jboss.org > >> Sent: Tuesday, November 10, 2015 3:06:33 PM > >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 > >> > >> Le 10/11/2015 18:09, John Sanda a ?crit : > >>>> After this long introduction, there are three main reasons the current > >>>> solution needs improvements: > >>>>> > >>>>> 1) Addressability -> the current solution does not work in the > >>>>> distributed environment because there is no clear way how to access the > >>>>> public API of the services deployed. Let's say the installation spread > >>>>> across 5 containers. How can I make a public API call from a Metrics > >>>>> instance to an Alerts instance. There is no directory to know where the > >>>>> Alerts or Metrics instances are deployed. > >>> Addressability is provided by the messaging system. There is no need for > >>> a > >>> directory. You just to need to communicate with the messaging > >>> server/broker. Beyond that there are a lot of features around > >>> addressability and routing such as message selectors, message grouping, > >>> hierarchical topics, and more. > >> > >> +1 > >> > >>> > >>>>> 2) Load distribution -> there is no clear way on how the load > >>>>> distribution works or who is responsible for it. > >>> Again, this is largely handled by the messaging system. Multiple > >>> consumers > >>> take messages from a queue where each message corresponds to work to be > >>> done. > >>> > >> > >> Right, load distribution is a feature of the messaging system. As for > >> HTTP load balancing, there is hardware and software dedicated to this, I > >> would avoid building an HTTP load balancer into the project. > >> > >>>>> 3) Availability of the existing public API -> There is no reason to > >>>>> implement a new API just for the purposes of communicating between the > >>>>> components. Given that we strive for this micro-service architecture, > >>>>> the one and single public API should be the main method for > >>>>> communicating between components for request-reply. > >>> I do not think it is a given that we strive for a micro-service > >>> architecture. It might make more sense in an OpenShift environment, but I > >>> don?t think it necessarily does in general. > >>> > >>> > >>>>> We might need to extend what we have but the public API should be front > >>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other > >>>>> method), the public API interface should be available over all the > >>>>> channels. Sure there might be difference on how to make a request in > >>>>> JMS > >>>>> vs HTTP (one with temporary queues, and the other with direct http > >>>>> connections) but the functionality should be identical. > >>> I don?t know that I agree with this. Suppose we decide to offer an API > >>> for > >>> inserting metric data over UDP to support really high throughput > >>> situations. Are you suggesting for example that the operations we provide > >>> via REST for reading metric data should also be available via the UDP > >>> API? > >>> And since the motivation for a UDP API is performance/throughput, we > >>> might > >>> event want to a more compact request format than JSON. > >>> > >>> Lastly and most importantly, if you want push for an alternative > >>> communication mechanism between components in H-Metrics and H-Alerts, > >>> then > >>> you push for the same across all of Hawkular because it does not make to > >>> have to support two different mechanisms. > >> > >> > >> The public API (JSON over HTTP) is how the users must interact with the > >> Hawkular platform. It is the unique entry point for the users. > >> > >> > >> It's has been agreed during the project inception to make Hawkular > >> components talk to each other via the bus. It is not a trivial change to > >> break this assumption: everything the bus provides (see above) will need > >> to be re-implemented. > >> That is why I am opposed to the change, unless it is proven that it is a > >> limitation. > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Wed Nov 11 03:17:09 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 09:17:09 +0100 Subject: [Hawkular-dev] Dieter Rams and Johnathan Ive talk on Design Message-ID: https://www.youtube.com/watch?v=zaLMOSWAwdw From lponce at redhat.com Wed Nov 11 03:28:15 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 11 Nov 2015 03:28:15 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5642616B.7020901@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> <5642616B.7020901@redhat.com> Message-ID: <827597175.6783025.1447230495468.JavaMail.zimbra@redhat.com> > > If at the end, we reach to a conclusion that communication between > > components needs an extra effort, I have my conclusion clear: we need to > > go through Hawkular, not replicating things, or in other words, focus all > > efforst in a single solution that can be used in several scenarios. > > As part of the migration to Wildfly 10, we will get rid of the ActiveMQ > resource adapter and use the messaging capabilities offered in the > container. So yes, when the migration is over, deploying Alerts + > Metrics will be a matter of copying the archives to the deployments folder. +1 That's an important point: to make easy to deploy, when more standards resources it uses from the app server the better, IMO. From lponce at redhat.com Wed Nov 11 03:39:47 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 11 Nov 2015 03:39:47 -0500 (EST) Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: References: <536565134.40626954.1445848010233.JavaMail.zimbra@redhat.com> <562F6E0F.2000908@redhat.com> <56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> Message-ID: <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> Hi Anton, We have integrated the Events feature in hawkular-alerts master branch: https://github.com/hawkular/hawkular-alerts You can follow the hawkular-alerts doc to build and test the component: http://www.hawkular.org/docs/components/alerts/index.html We will release a 0.6.0.Final version shortly. I have prepared some "HelloWorld" examples to show how to use Events on this repo: https://github.com/lucasponce/hawkular-examples/tree/master/events I want alto to publish a blog post once the release is out with more demo but I didn't want to delay my response to this topic without any feedback. The examples are using plain bash scripts over the REST API to show basic features. Don't hesitate to ask or give feedback, here, github, irc or event JIRA if you find something broken. Thanks, Lucas ----- Original Message ----- > From: "Anton Hughes" > To: "Discussions around Hawkular development" > Sent: Friday, October 30, 2015 2:16:29 PM > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > Coming back to my original question - and based on some further thinking and > reading of the Hawkular website, I have the following thoughts. > > On the Hawkular website, it is written: > > > > For who ? > There are primarly (BTW - this is spelled incorrect) two types of users. > Users who wants a toolkit to do server/ system monitoring in general, for > them we provide a rich REST API to store metrics, trigger alerts and manage > an inventory of resources > Users who want a full-fledge admin console to monitor and manage middleware > servers (Currently, only WildFly is supported) > I've highlighted the general area that I am most interested - and I think > many others would be too. > Please take a quick look at http://martinfowler.com/eaaDev/EventSourcing.html > . Event Sourcing places emphasis on events of interest - in the Shipping > example in this link the interesting events are: > > > * Ship Arrives > * Ship Departs > > To be able store (store metrics?) and react (trigger alert) in this example > would be very beneficial in many situations. > > I hope this helps to illustrates my use-case. > > On 29 October 2015 at 14:34, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > > > Anton, yes, it can be a little confusing. The Hawkular project is an > end-to-end monitoring and management tool focused on Red Hat software. Today > it basically offers a Wildfly agent for discovering and managing app > servers, their hosted apps, and all of the things that make up those apps. > What is can handle grows with every release. Hawkular leverages a bunch of > components to perform that job. There is HK-Inventory to represent a network > of inventories resources (like an app server, a datasource, a jvm, etc), > HK-Metrics as a Cassandra-backed time-series store, HK-Alerts as a > Drools-backed alerting tool, HK-Accounts as a KeyCloak backed > multi-tenant/auth/authz tool, HK-Console for UI, HK-Bus for a comm backbone, > etc.. > > Some of the HK components, namely HK-Metrics and HK-Alerts support standalone > deployment outside of Hawkular. They are named Hawkular-Metrics and > Hawkular-Alerts because they have been developed as part of the Hawkular > project, but they can be used independently. Hope that helps... > > > On 10/29/2015 9:16 AM, Anton Hughes wrote: > > > > > On 29 October 2015 at 14:12, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > Metrics and Alerts can both be used outside of the Hawkular framework so > really you can store any metric you like, or alert on basically any data you > like. As for Events, the next release of Hawkular Alerts (0.6.0) will > include a new Events feature that you may find interesting. Whereas Alerts > are relatively rare, typically involve human interaction, and run through a > simple life-cycle; Events are likely much more numerous, representing any > sort of happening that a client wants to persist. The interesting thing > about Events in HK-Alerts is that they can be inserted directly via API or > can be generated via Trigger, like an Alert. And Events can also be used as > Trigger conditions, to contribute to further Alert or Event generation. > > Thanks Jay - this sounds really cool! > > I have heard a few times now that hawkular components can be used outside of > the hawkular framework. What exactly is the hawkular framework? As an > outsider I am learning about Hawkular and its features. There is good > documentation on the features, but the underlying framework, not so much. > > Also, regarding documentation, I could not find how to store any 'metric' or > data. Specifically, I am looking to store not just a metric but a pojo. > > > > > -- > Anton Hughes > > > > _______________________________________________ > hawkular-dev mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > -- > Anton Hughes > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Wed Nov 11 03:46:25 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 11 Nov 2015 03:46:25 -0500 (EST) Subject: [Hawkular-dev] Hawkular BTM 0.5.0.Final released with JBoss Ticket Monster app demo In-Reply-To: <766654409.5272342.1447231370046.JavaMail.zimbra@redhat.com> Message-ID: <262031570.5276718.1447231585616.JavaMail.zimbra@redhat.com> Hi I'm pleased to announce the release of version 0.5.0.Final of the Hawkular Business Transaction Management project. A description of the new features, and the distribution, can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.5.0.Final A demo of this version of BTM, being used to monitor the JBoss Ticket Monster application, can be found here: https://vimeo.com/145283731 Regards Gary From lponce at redhat.com Wed Nov 11 03:49:16 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 11 Nov 2015 03:49:16 -0500 (EST) Subject: [Hawkular-dev] Hawkular BTM 0.5.0.Final released with JBoss Ticket Monster app demo In-Reply-To: <262031570.5276718.1447231585616.JavaMail.zimbra@redhat.com> References: <262031570.5276718.1447231585616.JavaMail.zimbra@redhat.com> Message-ID: <1729571009.6789463.1447231756354.JavaMail.zimbra@redhat.com> Really cool. +1 Gary ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Wednesday, November 11, 2015 9:46:25 AM > Subject: [Hawkular-dev] Hawkular BTM 0.5.0.Final released with JBoss Ticket Monster app demo > > Hi > > I'm pleased to announce the release of version 0.5.0.Final of the Hawkular > Business Transaction Management project. > > A description of the new features, and the distribution, can be found here: > https://github.com/hawkular/hawkular-btm/releases/tag/0.5.0.Final > > A demo of this version of BTM, being used to monitor the JBoss Ticket Monster > application, can be found here: https://vimeo.com/145283731 > > Regards > Gary > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Wed Nov 11 04:22:29 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 11 Nov 2015 10:22:29 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1802963815.8626834.1447194216703.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> <203254447.8610519.1447191414641.JavaMail.zimbra@redhat.com> <56426B0B.9030800@redhat.com> <1802963815.8626834.1447194216703.JavaMail.zimbra@redhat.com> Message-ID: <564308D5.3020103@redhat.com> Come on Stefan, you knew the answer, as you knew that I know that you know... etc the state of features. I never said Hawkular (currently) offers a single method like the one described in the proposal. I said adding such a new method is not a justification for creating a new Hawkular components integration. And I have yet to see a non fabricated example for this important assumption change. By the way, I suspect it wouldn't be very hard to implement the method in the Alerts component so that all the process below is automatically setup for you. Eventually, I have asked for the spirit/answer/motivations of the proposal. The answer was "the current implementation will not work". I believe it is obvious that it does. Le 10/11/2015 23:23, Stefan Negrea a ?crit : > > > ----- Original Message ----- >> From: "Thomas Segismont" >> To: hawkular-dev at lists.jboss.org >> Sent: Tuesday, November 10, 2015 4:09:15 PM >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >> >> - Start a Hawkular server >> - Use the REST resources under /hawkular/alerts to create a trigger for >> 'my_fancy_gauge' >> - Use the REST resources under /hawkular/alerts to create an external >> condition (my understanding is that such a condition will always >> evaluate to true if data is received) >> - Use the REST resources under /hawkular/alerts to create a webhook action >> - Use the REST resources under /hawkular/metrics to publish data > > I was afraid of that answer. That was neither the spirit nor the intent of the proposal. > >> >> >> Le 10/11/2015 22:36, Stefan Negrea a ?crit : >>> >>> >>> Thomas, I will ask the same thing I asked John earlier. Can you then please >>> walk through how to implement the feature proposed in the document? I can >>> see how it can be done in the proposals I put in the document and >>> discussed so far. But looks like you might have a different alternative. >>> Do you mind explaining the alternative and walking through the design and >>> implementation? >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Thomas Segismont" >>>> To: hawkular-dev at lists.jboss.org >>>> Sent: Tuesday, November 10, 2015 3:06:33 PM >>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 >>>> >>>> Le 10/11/2015 18:09, John Sanda a ?crit : >>>>>> After this long introduction, there are three main reasons the current >>>>>> solution needs improvements: >>>>>>> >>>>>>> 1) Addressability -> the current solution does not work in the >>>>>>> distributed environment because there is no clear way how to access the >>>>>>> public API of the services deployed. Let's say the installation spread >>>>>>> across 5 containers. How can I make a public API call from a Metrics >>>>>>> instance to an Alerts instance. There is no directory to know where the >>>>>>> Alerts or Metrics instances are deployed. >>>>> Addressability is provided by the messaging system. There is no need for >>>>> a >>>>> directory. You just to need to communicate with the messaging >>>>> server/broker. Beyond that there are a lot of features around >>>>> addressability and routing such as message selectors, message grouping, >>>>> hierarchical topics, and more. >>>> >>>> +1 >>>> >>>>> >>>>>>> 2) Load distribution -> there is no clear way on how the load >>>>>>> distribution works or who is responsible for it. >>>>> Again, this is largely handled by the messaging system. Multiple >>>>> consumers >>>>> take messages from a queue where each message corresponds to work to be >>>>> done. >>>>> >>>> >>>> Right, load distribution is a feature of the messaging system. As for >>>> HTTP load balancing, there is hardware and software dedicated to this, I >>>> would avoid building an HTTP load balancer into the project. >>>> >>>>>>> 3) Availability of the existing public API -> There is no reason to >>>>>>> implement a new API just for the purposes of communicating between the >>>>>>> components. Given that we strive for this micro-service architecture, >>>>>>> the one and single public API should be the main method for >>>>>>> communicating between components for request-reply. >>>>> I do not think it is a given that we strive for a micro-service >>>>> architecture. It might make more sense in an OpenShift environment, but I >>>>> don?t think it necessarily does in general. >>>>> >>>>> >>>>>>> We might need to extend what we have but the public API should be front >>>>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other >>>>>>> method), the public API interface should be available over all the >>>>>>> channels. Sure there might be difference on how to make a request in >>>>>>> JMS >>>>>>> vs HTTP (one with temporary queues, and the other with direct http >>>>>>> connections) but the functionality should be identical. >>>>> I don?t know that I agree with this. Suppose we decide to offer an API >>>>> for >>>>> inserting metric data over UDP to support really high throughput >>>>> situations. Are you suggesting for example that the operations we provide >>>>> via REST for reading metric data should also be available via the UDP >>>>> API? >>>>> And since the motivation for a UDP API is performance/throughput, we >>>>> might >>>>> event want to a more compact request format than JSON. >>>>> >>>>> Lastly and most importantly, if you want push for an alternative >>>>> communication mechanism between components in H-Metrics and H-Alerts, >>>>> then >>>>> you push for the same across all of Hawkular because it does not make to >>>>> have to support two different mechanisms. >>>> >>>> >>>> The public API (JSON over HTTP) is how the users must interact with the >>>> Hawkular platform. It is the unique entry point for the users. >>>> >>>> >>>> It's has been agreed during the project inception to make Hawkular >>>> components talk to each other via the bus. It is not a trivial change to >>>> break this assumption: everything the bus provides (see above) will need >>>> to be re-implemented. >>>> That is why I am opposed to the change, unless it is proven that it is a >>>> limitation. >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Wed Nov 11 04:52:05 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 10:52:05 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640B8E0.4000009@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> Message-ID: <5E244291-C342-429A-8781-38ACDA26F855@redhat.com> On 9 Nov 2015, at 16:16, Thomas Segismont wrote: > Hi, > > Phase 0 is already implemented: > - Metrics can receive data over HTTP > - Metrics can publish inserted data to the bus > - Webhooks can be created/configured via the Alerts API On top, the bus (if used as topic) can support an arbitrary number of consumers to be informed of new metric values when they come in. Metrics does not need new code, does not open outbound connections to potentially slower (than metrics) consumers etc. From hrupp at redhat.com Wed Nov 11 04:53:50 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 10:53:50 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5640DC55.5050902@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> Message-ID: <481478EF-2F24-432C-8715-A843622B6307@redhat.com> On 9 Nov 2015, at 18:48, Thomas Segismont wrote: > opposed to > re-writing what already exists, unless it is proven that it is broken. +1 and even then we should see if fixing is better than re-writing from scratch which can induce new/other issues. > Given the stress you rightfully put on moving fast, improving the > existing system seems like a reasonable approach. +1 From hrupp at redhat.com Wed Nov 11 04:55:46 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 10:55:46 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56412383.1060406@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <56412383.1060406@redhat.com> Message-ID: <9E1B950B-B0DD-43CA-88A2-423AEEF6EF69@redhat.com> On 9 Nov 2015, at 23:51, Jay Shaughnessy wrote: > and is useful to have Metrics use Alerts basically as a 3rd party tool, > such that a potential Metrics client can focus on using Metrics and not > worry about interacting with Alerts directly. The I am not convinced that a client talking to /hawkular/metrics/triggers has an advantage over the use of /hawkular/alerts/triggers From hrupp at redhat.com Wed Nov 11 05:07:08 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:07:08 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> Message-ID: <35F195DD-E3AF-49B9-B073-63312B32E87F@redhat.com> On 10 Nov 2015, at 17:25, Stefan Negrea wrote: > The user-facing feature proposed in the document will require > request-reply communication with endpoints in Alerts. Also, there is > the part about introducing a filtering mechanism for publishing only > metrics of interest to Alerts. This also requires request-reply So this is where the meat starts - we feel like we may need this filter. And this is something that is independent on any communication channel and/or co-location of/between the two involved entities. having alerts inform metrics of a potential filter can even be done via REST while at the same time the data itself flows via messaging (in which case we need to be careful not to filter out metrics that other consumers may want). > So just for Phase 0, we will need a good number (5 or 6) of > request-reply operations exposed over the Can you elaborate about those endpoints? What are the semantics of each? > 2) Use JMS as the communication channel and then publish the REST API > over JMS. And by "publishing the REST API over JMS", I mean making > every single public end-point available over the JMS channel so there > is no need in Why would that be needed? Having data distributed over messaging does not mean the control needs to be over messaging too. In fact, messaging is an internal detail, while outside clients should always talk to our REST endpoints. > generic solution, we will never have to touch this again ;-) > > 1) Addressability -> the current solution does not work in the > distributed environment because there is no clear way how to access > the public API of the services deployed. Let's say the installation > spread across 5 containers. How can I make a public API call from a > Metrics instance to an Alerts instance. There is no directory to know > where the Alerts or Metrics instances are deployed. That can be solved by such a directory service and then HATEOAS > 2) Load distribution -> there is no clear way on how the load > distribution works or who is responsible for it. And just replacing the internal messaging by rest-calls between alerts and metrics is solving this how? > 3) Availability of the existing public API -> There is no reason to > implement a new API just for the purposes of communicating between the > components. Given that we strive for this micro-service architecture, > the one and single public API should be the main method for > communicating between components for request-reply. We might need to > extend what we have but the public API should be front and centre. So > if we use JMS or HTTP (or http://de.slideshare.net/ewolff/rest-vs-messaging-for-microservices may be interesting in this context. From hrupp at redhat.com Wed Nov 11 05:10:09 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:10:09 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> Message-ID: <07688CF5-D116-4B02-9B80-76CB3729E581@redhat.com> On 10 Nov 2015, at 18:09, John Sanda wrote: > inter-component communication, via REST. I suspect we will end up > implementing functionality already provided by messaging systems. +1 >> 2) Load distribution -> there is no clear way on how the load >> distribution works or who is responsible for it. > > Again, this is largely handled by the messaging system. Multiple > consumers take messages from a queue where each message corresponds to > work to be done. +1 > Lastly and most importantly, if you want push for an alternative > communication mechanism between components in H-Metrics and H-Alerts, > then you push for the same across all of Hawkular because it does not > make to have to support two different mechanisms. I absolutely agree From hrupp at redhat.com Wed Nov 11 05:13:15 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:13:15 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> Message-ID: <4B06F3AD-892F-4B10-8004-ADBA921F7FF3@redhat.com> On 10 Nov 2015, at 18:57, Stefan Negrea wrote: > JMS solves load distribution for messaging, nothing more. But as a > tread-off we will need to make the public API available over JMS if we > are to go with the second proposal. I may be slow here, but what public api do you want to expose over the bus and for whom? How is the view from a client (take a Ruby program)? From hrupp at redhat.com Wed Nov 11 05:24:08 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:24:08 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <90470995.6531937.1447178999806.JavaMail.zimbra@redhat.com> Message-ID: <1F22B2F8-B11A-46D4-8D91-4B0F4755A38C@redhat.com> On 10 Nov 2015, at 19:09, Lucas Ponce wrote: > - A standalone use of Hawkular Metrics (mainly for OpenShift). Which may add alerts in the future, which was the trigger for this whole discussion. > > - Hawkular, a integrated project of several components/subproject > (bus,accounts,metrics,alerts,inventory,agent,ui,new ones). > > - Hawkular BTM (not sure if this will be consumed as part of Hawkular > as add-on, or a variant). This will for sure add into Hawkular-all at some point in time. > - Hawkular DataMining module (not sure if this will be consumed as > part of Hawkular as add-on, or a variant). As with BTM - DataMining is about prediction of potential bad conditions and in the future possibly also about root cause analysis. > It happens as our components are decoupled and can be consumed > separately, so it could be valid if the same user that is using > metrics in standalone can add alerts too to work together, but > probably that user is not interested in the full Hawkular solution as > it has developed its own security, feeds and inventory frameworks (or > any combination). At the moment this is a SEP to me [1]. We need to care about that OpenShift thingy and Hawkular-all. > So, if a user can deploy a metrics.war and alerts.war in the > deployments folder on a standard wildfly server, that could be > interesting an attractive for everyone (or at least that I think is > our main motivation for this discussion). Which will most possibly be possible when Hawkular is rebased to WF 10 where we will use the embedded AMQ-Artemis broker. > have my conclusion clear: we need to go through Hawkular, not > replicating things, or in other words, focus all efforst in a single > solution that can be used in several scenarios. +1 [1] http://hitchhikers.wikia.com/wiki/Somebody_Else's_Problem_field From hrupp at redhat.com Wed Nov 11 05:27:36 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:27:36 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> Message-ID: <0DE20277-F168-4A7F-A297-2EF0907AC08D@redhat.com> On 10 Nov 2015, at 19:47, John Sanda wrote: > Components and services in Hawkular communicate with each other via > the bus, i.e., JMS. To the best of my knowledge,the APIs we implement > over JMS are for internal communication between components running in > the Hawkular server (regardless of whether those components are Is that really true? Data (metrics,..) is flowing via JMS inside the server. UI is talking REST to the components. Agent is talking REST too. What internal apis over JMS do you have in mind? From hrupp at redhat.com Wed Nov 11 05:32:07 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:32:07 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> Message-ID: On 10 Nov 2015, at 21:00, Anton Hughes wrote: > Firstly, apologies if this thread is intended for Redhat staff only. Not at all - in this case it would not be on a public mailing list :-) In contrary this is out in the open to get more eyes like yours :) > - therefore make > the choice of easy integration. Abstract away how the Yes. Ease of integration is/was the main driver for the REST-api, as the can be talked to from virtually any programming language and OS out there. From hrupp at redhat.com Wed Nov 11 05:33:58 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:33:58 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <1003145189.8597634.1447188845876.JavaMail.zimbra@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <817807657.8500916.1447178240465.JavaMail.zimbra@redhat.com> <1074470133.6560723.1447181886326.JavaMail.zimbra@redhat.com> <1734652863.8559084.1447182599281.JavaMail.zimbra@redhat.com> <288997362.6565995.1447183170631.JavaMail.zimbra@redhat.com> <1003145189.8597634.1447188845876.JavaMail.zimbra@redhat.com> Message-ID: <55573495-91A8-4D90-9421-1FDB7D317FD1@redhat.com> On 10 Nov 2015, at 21:54, Stefan Negrea wrote: > That is one of the reasons why I keep pushing for a single public API. > The hot transport right now is REST over HTTP. If we are committed to > a single public API, not only that API will get better and better over > time (because it is the only one used and published) but we can also > find ways to leverage it over other channels. And still having a single public API does not force us to do all *internal* Java methods calls via REST as well. From hrupp at redhat.com Wed Nov 11 05:36:45 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 11:36:45 +0100 Subject: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 In-Reply-To: <56425C59.1020404@redhat.com> References: <1782187612.5886463.1446764514607.JavaMail.zimbra@redhat.com> <5640B8E0.4000009@redhat.com> <588152212.7926302.1447084111931.JavaMail.zimbra@redhat.com> <5640CD2E.3070500@redhat.com> <966667432.7978526.1447089038604.JavaMail.zimbra@redhat.com> <5640DC55.5050902@redhat.com> <1513612352.8113501.1447112005772.JavaMail.zimbra@redhat.com> <739238901.8448591.1447172718368.JavaMail.zimbra@redhat.com> <5B19621D-DC97-4C1D-8467-EBF878AACD52@redhat.com> <56425C59.1020404@redhat.com> Message-ID: <4C9C6047-D6A6-4D89-AEEE-4185C987466C@redhat.com> On 10 Nov 2015, at 22:06, Thomas Segismont wrote: > dedicated to this, I > would avoid building an HTTP load balancer into the project. Are you sure? I am certain that Apache and F5 and all those guys did not get it right ;-) > The public API (JSON over HTTP) is how the users must interact with > the > Hawkular platform. It is the unique entry point for the users. > > It's has been agreed during the project inception to make Hawkular > components talk to each other via the bus. It is not a trivial change > to > break this assumption: everything the bus provides (see above) will > need > to be re-implemented. > That is why I am opposed to the change, unless it is proven that it is > a > limitation. And even if Alerts tells metrics "Hey don't send me OS crap, that is boring" via REST does not imply that the individual data points can't be forwarded via messaging (or vice-versa) From lponce at redhat.com Wed Nov 11 06:51:15 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 11 Nov 2015 06:51:15 -0500 (EST) Subject: [Hawkular-dev] [hawkular-ui-services] Tests broken In-Reply-To: <1860758486.6896005.1447242510630.JavaMail.zimbra@redhat.com> Message-ID: <1699774078.6896998.1447242675153.JavaMail.zimbra@redhat.com> Hi, some of tests of ui-services are broken against hawkular/master, in particular: gulp rest:alert gulp rest:inventory I am investigating on alert if this is something introduced in the project, or it has to do with hawkular/master environment. I wonder if there is some way to automate this (as it is complex), but in the meanwhile, I think it could be good if before to send a PR we validate that the tests are ok. That could help to trace where the issue could be introduced. Thanks, Lucas From jkremser at redhat.com Wed Nov 11 07:42:39 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Wed, 11 Nov 2015 07:42:39 -0500 (EST) Subject: [Hawkular-dev] versioning schema In-Reply-To: <456110151.5674615.1447245021176.JavaMail.zimbra@redhat.com> Message-ID: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> Hello, I'd like to ask about the policy we want to use for the versioning schema. I've raised a PR [1] that will check the project version and fails the build if it's wrong. This should catch the releases with malformed versions. It's aligned with the JBoss project versioning [2], however, it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good point in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can be also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when releasing, we add the Final/Alpha, etc. Looking into wildfly repo, they use the former method. Is this what we want? I personally consider the latter method more natural and we use it in the inventory, despite the fact the hawkular/hawkular uses the x.y.z.AlphaN-SNAPSHOT. jk [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 [2]: https://developer.jboss.org/wiki/JBossProjectVersioning From jkremser at redhat.com Wed Nov 11 07:47:29 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Wed, 11 Nov 2015 07:47:29 -0500 (EST) Subject: [Hawkular-dev] [hawkular-ui-services] Tests broken In-Reply-To: <1699774078.6896998.1447242675153.JavaMail.zimbra@redhat.com> References: <1699774078.6896998.1447242675153.JavaMail.zimbra@redhat.com> Message-ID: <1638625754.5684739.1447246049705.JavaMail.zimbra@redhat.com> Hi Lukas, I had the same issue, the problem was with the Auth{N|Z}, namely CORS. From some strange reason the 2772 port was not white-listed for the hawkular-accounts-backend client in the Keycloak. I've added it in the auth console and it worked. With this 2 days old PR https://github.com/hawkular/hawkular-ui-services/pull/63 I had all the tests passing against the latest inventory. tests for metrics just work, because there is no hawkular accounts involved, afaik jk ----- Original Message ----- | From: "Lucas Ponce" | To: "Discussions around Hawkular development" | Sent: Wednesday, 11 November, 2015 12:51:15 PM | Subject: [Hawkular-dev] [hawkular-ui-services] Tests broken | | Hi, | | some of tests of ui-services are broken against hawkular/master, in | particular: | | gulp rest:alert | gulp rest:inventory | | I am investigating on alert if this is something introduced in the project, | or it has to do with hawkular/master environment. | | I wonder if there is some way to automate this (as it is complex), but in the | meanwhile, I think it could be good if before to send a PR we validate that | the tests are ok. | | That could help to trace where the issue could be introduced. | | Thanks, | Lucas | _______________________________________________ | hawkular-dev mailing list | hawkular-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/hawkular-dev | From jkremser at redhat.com Wed Nov 11 07:56:01 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Wed, 11 Nov 2015 07:56:01 -0500 (EST) Subject: [Hawkular-dev] [hawkular-ui-services] Tests broken In-Reply-To: <1638625754.5684739.1447246049705.JavaMail.zimbra@redhat.com> References: <1699774078.6896998.1447242675153.JavaMail.zimbra@redhat.com> <1638625754.5684739.1447246049705.JavaMail.zimbra@redhat.com> Message-ID: <1883829697.5688813.1447246561483.JavaMail.zimbra@redhat.com> Hi, the port that should be white-listed is this one 9876 (the default port on which the PhantomJS runs) not the 2772, that was mistake. you can replicate by: curl -ivX GET -u jdoe:password -H "Origin: http://127.0.0.1:9876" -H "Content-Type: application/json" -H "Accept: application/json" 'http://localhost:8080/hawkular/accounts/personas/current' | less here is PR btw: https://github.com/hawkular/hawkular/pull/643 jk ----- Original Message ----- | From: "Jiri Kremser" | To: "Discussions around Hawkular development" | Sent: Wednesday, 11 November, 2015 1:47:29 PM | Subject: Re: [Hawkular-dev] [hawkular-ui-services] Tests broken | | Hi Lukas, | | I had the same issue, the problem was with the Auth{N|Z}, namely CORS. From | some strange reason the 2772 port was not white-listed for the | hawkular-accounts-backend client in the Keycloak. I've added it in the | auth console and it worked. With this 2 days old PR | https://github.com/hawkular/hawkular-ui-services/pull/63 I had all the | tests passing against the latest inventory. | | tests for metrics just work, because there is no hawkular accounts involved, | afaik | | | jk | | ----- Original Message ----- | | From: "Lucas Ponce" | | To: "Discussions around Hawkular development" | | | | Sent: Wednesday, 11 November, 2015 12:51:15 PM | | Subject: [Hawkular-dev] [hawkular-ui-services] Tests broken | | | | Hi, | | | | some of tests of ui-services are broken against hawkular/master, in | | particular: | | | | gulp rest:alert | | gulp rest:inventory | | | | I am investigating on alert if this is something introduced in the project, | | or it has to do with hawkular/master environment. | | | | I wonder if there is some way to automate this (as it is complex), but in | | the | | meanwhile, I think it could be good if before to send a PR we validate that | | the tests are ok. | | | | That could help to trace where the issue could be introduced. | | | | Thanks, | | Lucas | | _______________________________________________ | | hawkular-dev mailing list | | hawkular-dev at lists.jboss.org | | https://lists.jboss.org/mailman/listinfo/hawkular-dev | | | _______________________________________________ | hawkular-dev mailing list | hawkular-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/hawkular-dev | From mazz at redhat.com Wed Nov 11 08:57:36 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 11 Nov 2015 08:57:36 -0500 (EST) Subject: [Hawkular-dev] versioning schema In-Reply-To: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> Message-ID: <159510705.6960208.1447250256816.JavaMail.zimbra@redhat.com> I like and use x.y.z.Final-SNAPSHOT if only because the mvn release plugin sets that all automatically for you. You just hit at the prompts and go. If you use x.y.x-SNAPSHOT you have to remember to change the value of the version at the mvn release plugin prompt, which can lead to typos/fat-fingering the version string ;) Make it easy on ourselves - just use x.y.z.ABC-SNAPSHOT - and let the mvn release plugin automatically determine the versions for us. ----- Original Message ----- > Hello, > I'd like to ask about the policy we want to use for the versioning schema. > I've raised a PR [1] that will check the project version and fails the > build if it's wrong. This should catch the releases with malformed > versions. It's aligned with the JBoss project versioning [2], however, > it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good point > in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can be > also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when releasing, we > add the Final/Alpha, etc. > > Looking into wildfly repo, they use the former method. Is this what we want? > I personally consider the latter method more natural and we use it in the > inventory, despite the fact the hawkular/hawkular uses the > x.y.z.AlphaN-SNAPSHOT. > > jk > > > [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 > [2]: https://developer.jboss.org/wiki/JBossProjectVersioning > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Wed Nov 11 09:36:30 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 11 Nov 2015 15:36:30 +0100 Subject: [Hawkular-dev] versioning schema In-Reply-To: <159510705.6960208.1447250256816.JavaMail.zimbra@redhat.com> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> <159510705.6960208.1447250256816.JavaMail.zimbra@redhat.com> Message-ID: <63FEF80E-45CF-4E4C-A23D-8EA607D7C758@redhat.com> The mentioned link does not mention .Final-SNAPSHOT anywhere. Either x.y.z-SNAPSHOT (which has other issues, as discussed) or x.y.z-Final. (but then it does not even mention SNAPSHOT :-). On 11 Nov 2015, at 14:57, John Mazzitelli wrote: > I like and use x.y.z.Final-SNAPSHOT if only because the mvn release > plugin sets that all automatically for you. You just hit at > the prompts and go. If you use x.y.x-SNAPSHOT you have to remember to > change the value of the version at the mvn release plugin prompt, > which can lead to typos/fat-fingering the version string ;) > > Make it easy on ourselves - just use x.y.z.ABC-SNAPSHOT - and let the > mvn release plugin automatically determine the versions for us. > > ----- Original Message ----- >> Hello, >> I'd like to ask about the policy we want to use for the versioning >> schema. >> I've raised a PR [1] that will check the project version and fails >> the >> build if it's wrong. This should catch the releases with malformed >> versions. It's aligned with the JBoss project versioning [2], >> however, >> it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good >> point >> in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can >> be >> also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when >> releasing, we >> add the Final/Alpha, etc. >> >> Looking into wildfly repo, they use the former method. Is this what >> we want? >> I personally consider the latter method more natural and we use it in >> the >> inventory, despite the fact the hawkular/hawkular uses the >> x.y.z.AlphaN-SNAPSHOT. >> >> jk >> >> >> [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 >> [2]: https://developer.jboss.org/wiki/JBossProjectVersioning >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht M?nchen HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters From gcardoso at redhat.com Wed Nov 11 09:54:46 2015 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Wed, 11 Nov 2015 12:54:46 -0200 Subject: [Hawkular-dev] Dieter Rams and Johnathan Ive talk on Design In-Reply-To: References: Message-ID: Interesting! Actually it seems that many Apple designs were inspired in Braun designs: http://www.cultofmac.com/188753/the-braun-products-that-inspired-apples-iconic-designs-gallery/ > On Nov 11, 2015, at 6:17 AM, Heiko W.Rupp wrote: > > > https://www.youtube.com/watch?v=zaLMOSWAwdw > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev Gabriel Cardoso UX designer @ Red Hat From mazz at redhat.com Wed Nov 11 20:52:52 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 11 Nov 2015 20:52:52 -0500 (EST) Subject: [Hawkular-dev] hawkular wildfly agent master branch is working again In-Reply-To: <1181528871.7216378.1447292950755.JavaMail.zimbra@redhat.com> Message-ID: <1413053646.7217393.1447293172334.JavaMail.zimbra@redhat.com> The master branch of the agent is working again. From theute at redhat.com Thu Nov 12 05:29:32 2015 From: theute at redhat.com (Thomas Heute) Date: Thu, 12 Nov 2015 11:29:32 +0100 Subject: [Hawkular-dev] Hawkular goodies / swag Message-ID: I'd like to open the discussion to *anyone* on something light: Hawkular Goodies ;) I would like to get some goodies to give away at conferences, for contributors... I would like to have something that is not going to the trash right away, something you would want to have (and doesn't cost a fortune ;)). I am personally not fond of T-shirts as we usually get many at conferences unless the design is really fun/original. So please make your proposals and then we can vote, we may end with 2 results, cheaper to spread more/slightly more expensive for special occasions. Maybe you saw/received something fun/useful in the past. Example of something original: Atlassian socks: https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 Don't be shy :) If we go to the end with your idea, you would definitely get the first item ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151112/f3643e7b/attachment.html From ah at tradeworks.io Thu Nov 12 05:41:58 2015 From: ah at tradeworks.io (Anton Hughes) Date: Thu, 12 Nov 2015 11:41:58 +0100 Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> References: <536565134.40626954.1445848010233.JavaMail.zimbra@redhat.com> <562F6E0F.2000908@redhat.com> <56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> Message-ID: Thanks Lucas! This looks really great! I will give this some solid testing and let you know how it goes. One nice feature would be to add swagger documentation to your rest api. However, your current documentation looks really good! Kind regards On 11 November 2015 at 09:39, Lucas Ponce wrote: > Hi Anton, > > We have integrated the Events feature in hawkular-alerts master branch: > > https://github.com/hawkular/hawkular-alerts > > You can follow the hawkular-alerts doc to build and test the component: > > http://www.hawkular.org/docs/components/alerts/index.html > > We will release a 0.6.0.Final version shortly. > > I have prepared some "HelloWorld" examples to show how to use Events on > this repo: > > https://github.com/lucasponce/hawkular-examples/tree/master/events > > I want alto to publish a blog post once the release is out with more demo > but I didn't want to delay my response to this topic without any feedback. > > The examples are using plain bash scripts over the REST API to show basic > features. > > Don't hesitate to ask or give feedback, here, github, irc or event JIRA if > you find something broken. > > Thanks, > Lucas > > ----- Original Message ----- > > From: "Anton Hughes" > > To: "Discussions around Hawkular development" < > hawkular-dev at lists.jboss.org> > > Sent: Friday, October 30, 2015 2:16:29 PM > > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > > > Coming back to my original question - and based on some further thinking > and > > reading of the Hawkular website, I have the following thoughts. > > > > On the Hawkular website, it is written: > > > > > > > > For who ? > > There are primarly (BTW - this is spelled incorrect) two types of users. > > Users who wants a toolkit to do server/ system monitoring in general, for > > them we provide a rich REST API to store metrics, trigger alerts and > manage > > an inventory of resources > > Users who want a full-fledge admin console to monitor and manage > middleware > > servers (Currently, only WildFly is supported) > > I've highlighted the general area that I am most interested - and I think > > many others would be too. > > Please take a quick look at > http://martinfowler.com/eaaDev/EventSourcing.html > > . Event Sourcing places emphasis on events of interest - in the Shipping > > example in this link the interesting events are: > > > > > > * Ship Arrives > > * Ship Departs > > > > To be able store (store metrics?) and react (trigger alert) in this > example > > would be very beneficial in many situations. > > > > I hope this helps to illustrates my use-case. > > > > On 29 October 2015 at 14:34, Jay Shaughnessy < jshaughn at redhat.com > > wrote: > > > > > > > > > > Anton, yes, it can be a little confusing. The Hawkular project is an > > end-to-end monitoring and management tool focused on Red Hat software. > Today > > it basically offers a Wildfly agent for discovering and managing app > > servers, their hosted apps, and all of the things that make up those > apps. > > What is can handle grows with every release. Hawkular leverages a bunch > of > > components to perform that job. There is HK-Inventory to represent a > network > > of inventories resources (like an app server, a datasource, a jvm, etc), > > HK-Metrics as a Cassandra-backed time-series store, HK-Alerts as a > > Drools-backed alerting tool, HK-Accounts as a KeyCloak backed > > multi-tenant/auth/authz tool, HK-Console for UI, HK-Bus for a comm > backbone, > > etc.. > > > > Some of the HK components, namely HK-Metrics and HK-Alerts support > standalone > > deployment outside of Hawkular. They are named Hawkular-Metrics and > > Hawkular-Alerts because they have been developed as part of the Hawkular > > project, but they can be used independently. Hope that helps... > > > > > > On 10/29/2015 9:16 AM, Anton Hughes wrote: > > > > > > > > > > On 29 October 2015 at 14:12, Jay Shaughnessy < jshaughn at redhat.com > > wrote: > > > > > > Metrics and Alerts can both be used outside of the Hawkular framework so > > really you can store any metric you like, or alert on basically any data > you > > like. As for Events, the next release of Hawkular Alerts (0.6.0) will > > include a new Events feature that you may find interesting. Whereas > Alerts > > are relatively rare, typically involve human interaction, and run > through a > > simple life-cycle; Events are likely much more numerous, representing any > > sort of happening that a client wants to persist. The interesting thing > > about Events in HK-Alerts is that they can be inserted directly via API > or > > can be generated via Trigger, like an Alert. And Events can also be used > as > > Trigger conditions, to contribute to further Alert or Event generation. > > > > Thanks Jay - this sounds really cool! > > > > I have heard a few times now that hawkular components can be used > outside of > > the hawkular framework. What exactly is the hawkular framework? As an > > outsider I am learning about Hawkular and its features. There is good > > documentation on the features, but the underlying framework, not so much. > > > > Also, regarding documentation, I could not find how to store any > 'metric' or > > data. Specifically, I am looking to store not just a metric but a pojo. > > > > > > > > > > -- > > Anton Hughes > > > > > > > > _______________________________________________ > > hawkular-dev mailing list hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > -- > > Anton Hughes > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151112/a8800eaf/attachment-0001.html From lponce at redhat.com Thu Nov 12 06:57:10 2015 From: lponce at redhat.com (Lucas Ponce) Date: Thu, 12 Nov 2015 06:57:10 -0500 (EST) Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: References:

<56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> Message-ID: <1192430245.7375870.1447329430473.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Anton Hughes" > To: "Discussions around Hawkular development" > Sent: Thursday, November 12, 2015 11:41:58 AM > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > Thanks Lucas! > > This looks really great! > > I will give this some solid testing and let you know how it goes. > > One nice feature would be to add swagger documentation to your rest api. > However, your current documentation looks really good! > We have some documentation http://www.hawkular.org/docs/rest/rest-alerts.html but this is a point we want to improve when we have some slot between releases. If there is something wrong/broken, please, don't hesitate to comment (or if it's clear, feel free to open a JIRA and we'll work on it). Thanks, Lucas > Kind regards > > On 11 November 2015 at 09:39, Lucas Ponce < lponce at redhat.com > wrote: > > > Hi Anton, > > We have integrated the Events feature in hawkular-alerts master branch: > > https://github.com/hawkular/hawkular-alerts > > You can follow the hawkular-alerts doc to build and test the component: > > http://www.hawkular.org/docs/components/alerts/index.html > > We will release a 0.6.0.Final version shortly. > > I have prepared some "HelloWorld" examples to show how to use Events on this > repo: > > https://github.com/lucasponce/hawkular-examples/tree/master/events > > I want alto to publish a blog post once the release is out with more demo but > I didn't want to delay my response to this topic without any feedback. > > The examples are using plain bash scripts over the REST API to show basic > features. > > Don't hesitate to ask or give feedback, here, github, irc or event JIRA if > you find something broken. > > Thanks, > Lucas > > ----- Original Message ----- > > From: "Anton Hughes" < ah at tradeworks.io > > > To: "Discussions around Hawkular development" < > > hawkular-dev at lists.jboss.org > > > Sent: Friday, October 30, 2015 2:16:29 PM > > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > > > Coming back to my original question - and based on some further thinking > > and > > reading of the Hawkular website, I have the following thoughts. > > > > On the Hawkular website, it is written: > > > > > > > > For who ? > > There are primarly (BTW - this is spelled incorrect) two types of users. > > Users who wants a toolkit to do server/ system monitoring in general, for > > them we provide a rich REST API to store metrics, trigger alerts and manage > > an inventory of resources > > Users who want a full-fledge admin console to monitor and manage middleware > > servers (Currently, only WildFly is supported) > > I've highlighted the general area that I am most interested - and I think > > many others would be too. > > Please take a quick look at > > http://martinfowler.com/eaaDev/EventSourcing.html > > . Event Sourcing places emphasis on events of interest - in the Shipping > > example in this link the interesting events are: > > > > > > * Ship Arrives > > * Ship Departs > > > > To be able store (store metrics?) and react (trigger alert) in this example > > would be very beneficial in many situations. > > > > I hope this helps to illustrates my use-case. > > > > On 29 October 2015 at 14:34, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > > > > > > > > Anton, yes, it can be a little confusing. The Hawkular project is an > > end-to-end monitoring and management tool focused on Red Hat software. > > Today > > it basically offers a Wildfly agent for discovering and managing app > > servers, their hosted apps, and all of the things that make up those apps. > > What is can handle grows with every release. Hawkular leverages a bunch of > > components to perform that job. There is HK-Inventory to represent a > > network > > of inventories resources (like an app server, a datasource, a jvm, etc), > > HK-Metrics as a Cassandra-backed time-series store, HK-Alerts as a > > Drools-backed alerting tool, HK-Accounts as a KeyCloak backed > > multi-tenant/auth/authz tool, HK-Console for UI, HK-Bus for a comm > > backbone, > > etc.. > > > > Some of the HK components, namely HK-Metrics and HK-Alerts support > > standalone > > deployment outside of Hawkular. They are named Hawkular-Metrics and > > Hawkular-Alerts because they have been developed as part of the Hawkular > > project, but they can be used independently. Hope that helps... > > > > > > On 10/29/2015 9:16 AM, Anton Hughes wrote: > > > > > > > > > > On 29 October 2015 at 14:12, Jay Shaughnessy < jshaughn at redhat.com > wrote: > > > > > > Metrics and Alerts can both be used outside of the Hawkular framework so > > really you can store any metric you like, or alert on basically any data > > you > > like. As for Events, the next release of Hawkular Alerts (0.6.0) will > > include a new Events feature that you may find interesting. Whereas Alerts > > are relatively rare, typically involve human interaction, and run through a > > simple life-cycle; Events are likely much more numerous, representing any > > sort of happening that a client wants to persist. The interesting thing > > about Events in HK-Alerts is that they can be inserted directly via API or > > can be generated via Trigger, like an Alert. And Events can also be used as > > Trigger conditions, to contribute to further Alert or Event generation. > > > > Thanks Jay - this sounds really cool! > > > > I have heard a few times now that hawkular components can be used outside > > of > > the hawkular framework. What exactly is the hawkular framework? As an > > outsider I am learning about Hawkular and its features. There is good > > documentation on the features, but the underlying framework, not so much. > > > > Also, regarding documentation, I could not find how to store any 'metric' > > or > > data. Specifically, I am looking to store not just a metric but a pojo. > > > > > > > > > > -- > > Anton Hughes > > > > > > > > _______________________________________________ > > hawkular-dev mailing list hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > -- > > Anton Hughes > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > -- > Anton Hughes > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ah at tradeworks.io Thu Nov 12 07:20:29 2015 From: ah at tradeworks.io (Anton Hughes) Date: Thu, 12 Nov 2015 13:20:29 +0100 Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: <1192430245.7375870.1447329430473.JavaMail.zimbra@redhat.com> References:

<56321B22.8010509@redhat.com> <5632204A.8050305@redhat.com> <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> <1192430245.7375870.1447329430473.JavaMail.zimbra@redhat.com> Message-ID: Thanks Lucas On 12 November 2015 at 12:57, Lucas Ponce wrote: > but this is a point we want to improve when we have some slot between > releases. > > If there is something wrong/broken, please, don't hesitate to comment (or > if it's clear, feel free to open a JIRA and we'll work on it). > Well perhaps I can help too? I think this project is particularly interesting and so I would be keen on getting more involved. -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151112/cccaaef6/attachment.html From lponce at redhat.com Thu Nov 12 07:32:43 2015 From: lponce at redhat.com (Lucas Ponce) Date: Thu, 12 Nov 2015 07:32:43 -0500 (EST) Subject: [Hawkular-dev] Is this an applicable use-case for Hawkular In-Reply-To: References:

<5632204A.8050305@redhat.com> <370012563.6787499.1447231187705.JavaMail.zimbra@redhat.com> <1192430245.7375870.1447329430473.JavaMail.zimbra@redhat.com> Message-ID: <979973421.7392695.1447331563440.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Anton Hughes" > To: "Discussions around Hawkular development" > Sent: Thursday, November 12, 2015 1:20:29 PM > Subject: Re: [Hawkular-dev] Is this an applicable use-case for Hawkular > > Thanks Lucas > On 12 November 2015 at 12:57, Lucas Ponce < lponce at redhat.com > wrote: > > > > but this is a point we want to improve when we have some slot between > releases. > > If there is something wrong/broken, please, don't hesitate to comment (or if > it's clear, feel free to open a JIRA and we'll work on it). > Well perhaps I can help too? I think this project is particularly interesting > and so I would be keen on getting more involved. > > Of course :-). Our projects are hosted on github and PR on code, documentation or examples are most welcome. Thanks ! Lucas > > > -- > Anton Hughes > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lkrejci at redhat.com Thu Nov 12 10:52:20 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Thu, 12 Nov 2015 16:52:20 +0100 Subject: [Hawkular-dev] Inventory model change? In-Reply-To: <14FD3D60-E74B-4F5C-AB50-3C778317938A@redhat.com> References: <95B6788D-DAB5-44E4-BCD0-FF7EB7D206FA@redhat.com> <14FD3D60-E74B-4F5C-AB50-3C778317938A@redhat.com> Message-ID: <2619198.QdGdz6CiJc@localhost.localdomain> On Monday, November 09, 2015 20:55:39 Heiko W.Rupp wrote: > On 9 Nov 2015, at 20:53, Heiko W.Rupp wrote: > > On 9 Nov 2015, at 15:45, Lukas Krejci wrote: > >> There's a couple of things involved: > >> > >> 1) The inventory 0.8.0 release was done late on Friday upon Mazz's > >> request. So > >> we haven't had time to send PRs to affected projects - in > > > > The point is probably, that we can not do that anymore > > in the future - we will have clients that we will not know > > about it. > > > >> 4) I concentrate more on having the agent working than on producing > >> some > >> detailed release notes (and I've been on that today - > > > > I am not really asking for release notes, but rather some > > rules on how to change by code base to get going again. > > And "Look at tests in xyz-foobar" will not be the solution here. Once we get to the point where we're feature complete we can and should think about API stability. At least with inventory we're not there by a long shot so I am not particularly willing to trade API clarity for "stability" of sub-par APIs that we produce and change as we go along. I'm not talking about changes for changes' sake but about substantial changes to the model that evolves as we iron out our usecases and workflows. While I 100% agree with you that we should communicate the changes and provide migration guide (if not automatic forwarding to new APIs where possible), I personally don't think we're at the point in the project's life where we can afford that burden. I personally don't have time to do that that wouldn't be better spent by burning some of the ever growing backlog of stuff to be done on inventory so that it can become at least partially usable by clients. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From lkrejci at redhat.com Thu Nov 12 10:53:57 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Thu, 12 Nov 2015 16:53:57 +0100 Subject: [Hawkular-dev] Version endpoint for components In-Reply-To: <64BE91A4-4AF5-49FF-912F-28A4E8915640@redhat.com> References: <4E8E8F25-AECE-4370-90B5-AFBD693ED6AF@redhat.com> <5641CC2B.3060509@redhat.com> <64BE91A4-4AF5-49FF-912F-28A4E8915640@redhat.com> Message-ID: <1879170.43gj1c73LX@localhost.localdomain> https://github.com/hawkular/hawkular-commons/pull/22 On Tuesday, November 10, 2015 12:17:16 Heiko W.Rupp wrote: > On 10 Nov 2015, at 11:51, Thomas Segismont wrote: > > We have the /status endpoint already in Metrics for this purpose. > > Yep, that looks pretty good: > > '{"MetricsService":"STARTING", > > "Implementation-Version":"0.9.0.Final-SRC-revision-9080fcfbe40a66ce8143c477b > 5d6f8fbadeecf3a", > "Built-From-Git-SHA1":"9080fcfbe40a66ce8143c477b5d6f8fbadeecf3a"}' > > We need to make sure that all the components use the same keys, > which may either require to add a "status" to the above or to rename > the "MetricsService" to "status" or similar. > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From theute at redhat.com Thu Nov 12 11:24:07 2015 From: theute at redhat.com (Thomas Heute) Date: Thu, 12 Nov 2015 17:24:07 +0100 Subject: [Hawkular-dev] WF10 Message-ID: Just a quick note that next week release won't be rebased on WildFly 10, the main blocker is that Keycloak doesn't run on WF10 and we depend on it. So we'll release on top of WF9, hopefully the release after will be on WF10 Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151112/f625abc1/attachment.html From jshaughn at redhat.com Thu Nov 12 16:37:48 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Thu, 12 Nov 2015 16:37:48 -0500 Subject: [Hawkular-dev] Hawkular Alerts 0.6.0.Final Released! Message-ID: <564506AC.3060606@redhat.com> Hawkular Alerts 0.6.0.Final has been Released! * Event Support This major new feature incorporates Events into Hawkular Alerts. Events: * Are more lightweight than Alerts * Record things of interest * Can be injected via an API call * Can be generated via a Trigger * Can have actions performed on them (for Trigger-generated Events) * Can be used as Trigger conditions For more on Events there is some general information here (more to come): http://www.hawkular.org/docs/dev/alerts.html And Lucas provides some great examples here: https://github.com/lucasponce/hawkular-examples/tree/master/events * WebHooks Action Plugin Hawkular Alerts 0.6.0.Final introduces a new Action plugin for WebHook notifications. There have been some changes to the REST endpoints as we refine the model. Of course there are fixes and minor enhancements as well. A Jira Summary for the release is here: * https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12328590 The next scheduled release is 0.7.0, targeted for December 9, 2015. Hawkular Alerts Team Jay Shaughnessy (jshaughn at redhat.com) Lucas Ponce (lponce at redhat.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151112/7356c6c5/attachment-0001.html From gbrown at redhat.com Fri Nov 13 03:40:00 2015 From: gbrown at redhat.com (Gary Brown) Date: Fri, 13 Nov 2015 03:40:00 -0500 (EST) Subject: [Hawkular-dev] Hawkular Alerts 0.6.0.Final Released! In-Reply-To: <564506AC.3060606@redhat.com> References: <564506AC.3060606@redhat.com> Message-ID: <1532004646.6215835.1447404000678.JavaMail.zimbra@redhat.com> Congratulations! ----- Original Message ----- > > Hawkular Alerts 0.6.0.Final has been Released! * Event Support > > > This major new feature incorporates Events into Hawkular Alerts. Events: > > > * Are more lightweight than Alerts > * Record things of interest > * Can be injected via an API call > * Can be generated via a Trigger > * Can have actions performed on them (for Trigger-generated Events) > * Can be used as Trigger conditions > > > For more on Events there is some general information here (more to come): > > > http://www.hawkular.org/docs/dev/alerts.html > > > And Lucas provides some great examples here: > > > https://github.com/lucasponce/hawkular-examples/tree/master/events > > * WebHooks Action Plugin > > > Hawkular Alerts 0.6.0.Final introduces a new Action plugin for WebHook > notifications. > There have been some changes to the REST endpoints as we refine the model. > > > Of course there are fixes and minor enhancements as well. A Jira Summary for > the release is here: > > > * > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12328590 > > The next scheduled release is 0.7.0, targeted for December 9, 2015. > > Hawkular Alerts Team > Jay Shaughnessy ( jshaughn at redhat.com ) > Lucas Ponce ( lponce at redhat.com ) > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Fri Nov 13 04:53:42 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 13 Nov 2015 10:53:42 +0100 Subject: [Hawkular-dev] Hawkular Alerts 0.6.0.Final Released! In-Reply-To: <564506AC.3060606@redhat.com> References: <564506AC.3060606@redhat.com> Message-ID: <5645B326.3000508@redhat.com> Awesome! Congrats! Le 12/11/2015 22:37, Jay Shaughnessy a ?crit : > > Hawkular Alerts 0.6.0.Final has been Released! > > > * Event Support > > This major new feature incorporates Events into Hawkular Alerts. Events: > > * Are more lightweight than Alerts > * Record things of interest > * Can be injected via an API call > * Can be generated via a Trigger > * Can have actions performed on them (for Trigger-generated Events) > * Can be used as Trigger conditions > > For more on Events there is some general information here (more to come): > > http://www.hawkular.org/docs/dev/alerts.html > > And Lucas provides some great examples here: > > https://github.com/lucasponce/hawkular-examples/tree/master/events > > > * WebHooks Action Plugin > > Hawkular Alerts 0.6.0.Final introduces a new Action plugin for WebHook > notifications. > > There have been some changes to the REST endpoints as we refine the model. > > > Of course there are fixes and minor enhancements as well. A Jira > Summary for the release is here: > > * https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&version=12328590 > > > The next scheduled release is 0.7.0, targeted for December 9, 2015. > > Hawkular Alerts Team > Jay Shaughnessy (jshaughn at redhat.com) > Lucas Ponce (lponce at redhat.com) > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Fri Nov 13 05:54:07 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Fri, 13 Nov 2015 11:54:07 +0100 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: References: Message-ID: <5645C14F.5050100@redhat.com> I personally like branded USB drives. We could even pre-image them with a specific version of Hawkular, so that people could just boot it up for testing or evaluation. And of course, stickers! The jBPM team has a set of them with different messages, from powerful quotes about "business processes" to funny messages. - Juca. On 12.11.2015 11:29, Thomas Heute wrote: > I'd like to open the discussion to *anyone* on something light: Hawkular > Goodies ;) > > I would like to get some goodies to give away at conferences, for > contributors... > > I would like to have something that is not going to the trash right > away, something you would want to have (and doesn't cost a fortune ;)). > > I am personally not fond of T-shirts as we usually get many at > conferences unless the design is really fun/original. > > So please make your proposals and then we can vote, we may end with 2 > results, cheaper to spread more/slightly more expensive for special > occasions. > Maybe you saw/received something fun/useful in the past. > > Example of something original: > Atlassian socks: > https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 > > > Don't be shy :) > > If we go to the end with your idea, you would definitely get the first > item ;) > > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ah at tradeworks.io Fri Nov 13 09:04:27 2015 From: ah at tradeworks.io (Anton Hughes) Date: Fri, 13 Nov 2015 15:04:27 +0100 Subject: [Hawkular-dev] Question about Alerts examples Message-ID: Hi all I have been studying https://github.com/lucasponce/hawkular-examples/tree/master/events - and I have a question. In the example documentation, I cannot see how an trigger and conditions are related. I would expect there to be some reference between these objects. Thanks -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151113/82385cf3/attachment.html From jshaughn at redhat.com Fri Nov 13 09:05:47 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Fri, 13 Nov 2015 09:05:47 -0500 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: References: Message-ID: <5645EE3B.7040700@redhat.com> A small magnifying glass seems like a Hawkular-ish thing, and I always find them useful. Like this one: http://www.officedepot.com/a/products/786365/Carson-MagniFlip-Magnifier On 11/12/2015 5:29 AM, Thomas Heute wrote: > I'd like to open the discussion to *anyone* on something light: > Hawkular Goodies ;) > > I would like to get some goodies to give away at conferences, for > contributors... > > I would like to have something that is not going to the trash right > away, something you would want to have (and doesn't cost a fortune ;)). > > I am personally not fond of T-shirts as we usually get many at > conferences unless the design is really fun/original. > > So please make your proposals and then we can vote, we may end with 2 > results, cheaper to spread more/slightly more expensive for special > occasions. > Maybe you saw/received something fun/useful in the past. > > Example of something original: > Atlassian socks: > https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 > > > Don't be shy :) > > If we go to the end with your idea, you would definitely get the first > item ;) > > > > > > _______________________________________________ > 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/20151113/3a5ac785/attachment.html From jshaughn at redhat.com Fri Nov 13 09:11:18 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Fri, 13 Nov 2015 09:11:18 -0500 Subject: [Hawkular-dev] Inventory model change? In-Reply-To: <2619198.QdGdz6CiJc@localhost.localdomain> References: <95B6788D-DAB5-44E4-BCD0-FF7EB7D206FA@redhat.com> <14FD3D60-E74B-4F5C-AB50-3C778317938A@redhat.com> <2619198.QdGdz6CiJc@localhost.localdomain> Message-ID: <5645EF86.90600@redhat.com> re. > Once we get to the point where we're feature complete we can and should think > about API stability. At least with inventory we're not there by a long shot so > I am not particularly willing to trade API clarity for "stability" of sub-par > APIs that we produce and change as we go along. > > I'm not talking about changes for changes' sake but about substantial changes > to the model that evolves as we iron out our usecases and workflows. > > While I 100% agree with you that we should communicate the changes and provide > migration guide (if not automatic forwarding to new APIs where possible), I > personally don't think we're at the point in the project's life where we can > afford that burden. I personally don't have time to do that that wouldn't be > better spent by burning some of the ever growing backlog of stuff to be done > on inventory so that it can become at least partially usable by clients. +1, we need to take advantage of this window where back compat is not overly required and use cases continue to become solidified. Of course don't go ten steps back to go one step forward. As with everything, make good trade-offs and don't hang out to dry the folks using your stuff. From theute at redhat.com Fri Nov 13 09:13:41 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 13 Nov 2015 15:13:41 +0100 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: <5645EE3B.7040700@redhat.com> References: <5645EE3B.7040700@redhat.com> Message-ID: On Fri, Nov 13, 2015 at 3:05 PM, Jay Shaughnessy wrote: > > A small magnifying glass seems like a Hawkular-ish thing, and I always > find them useful. Like this one: > http://www.officedepot.com/a/products/786365/Carson-MagniFlip-Magnifier > When I use the link I see a magnifying glass but not the one you were talking about :) http://snag.gy/gM9IG.jpg But searching for "Carson Magniflip Magnifier" works Thanks ! Thomas > > > > On 11/12/2015 5:29 AM, Thomas Heute wrote: > > I'd like to open the discussion to *anyone* on something light: Hawkular > Goodies ;) > > I would like to get some goodies to give away at conferences, for > contributors... > > I would like to have something that is not going to the trash right away, > something you would want to have (and doesn't cost a fortune ;)). > > I am personally not fond of T-shirts as we usually get many at conferences > unless the design is really fun/original. > > So please make your proposals and then we can vote, we may end with 2 > results, cheaper to spread more/slightly more expensive for special > occasions. > Maybe you saw/received something fun/useful in the past. > > Example of something original: > Atlassian socks: > https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 > > > Don't be shy :) > > If we go to the end with your idea, you would definitely get the first > item ;) > > > > > > _______________________________________________ > hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151113/3989c305/attachment-0001.html From mazz at redhat.com Fri Nov 13 09:20:09 2015 From: mazz at redhat.com (John Mazzitelli) Date: Fri, 13 Nov 2015 09:20:09 -0500 (EST) Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: <5645C14F.5050100@redhat.com> References: <5645C14F.5050100@redhat.com> Message-ID: <1316782933.8151263.1447424409692.JavaMail.zimbra@redhat.com> Branded USB drives would be nice, but probably expensive. But if you could swing it, that's what I would vote for. ----- Original Message ----- > I personally like branded USB drives. We could even pre-image them with > a specific version of Hawkular, so that people could just boot it up for > testing or evaluation. And of course, stickers! The jBPM team has a set > of them with different messages, from powerful quotes about "business > processes" to funny messages. > > - Juca. > > On 12.11.2015 11:29, Thomas Heute wrote: > > I'd like to open the discussion to *anyone* on something light: Hawkular > > Goodies ;) > > > > I would like to get some goodies to give away at conferences, for > > contributors... > > > > I would like to have something that is not going to the trash right > > away, something you would want to have (and doesn't cost a fortune ;)). > > > > I am personally not fond of T-shirts as we usually get many at > > conferences unless the design is really fun/original. > > > > So please make your proposals and then we can vote, we may end with 2 > > results, cheaper to spread more/slightly more expensive for special > > occasions. > > Maybe you saw/received something fun/useful in the past. > > > > Example of something original: > > Atlassian socks: > > https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 > > > > > > Don't be shy :) > > > > If we go to the end with your idea, you would definitely get the first > > item ;) > > > > > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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 gcardoso at redhat.com Fri Nov 13 09:37:16 2015 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Fri, 13 Nov 2015 12:37:16 -0200 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: <1316782933.8151263.1447424409692.JavaMail.zimbra@redhat.com> References: <5645C14F.5050100@redhat.com> <1316782933.8151263.1447424409692.JavaMail.zimbra@redhat.com> Message-ID: Brainstorming: - USB ventilator: http://www.amazon.com/ARCTIC-USB-Powered-Portable-Solution-Gooseneck/dp/B003XN24GY/ref=sr_1_5?s=pc&ie=UTF8&qid=1447425151&sr=1-5&keywords=usb+fan (good for summer) - USB beverage warmer: http://www.amazon.com/New-Coffee-Beverage-Warmer-Heater/dp/B004P15KAK/ref=sr_1_7?s=pc&ie=UTF8&qid=1447425044&sr=1-7&keywords=usb+beverage+warmer (good for winter) - USB hub: http://www.dx.com/p/ssk-shu024-usb-2-0-4-port-hi-speed-usb-hub-for-portable-hard-disk-drive-orange-394348#.VkX1GYTWFp8 Gabriel > On Nov 13, 2015, at 12:20 PM, John Mazzitelli wrote: > > Branded USB drives would be nice, but probably expensive. But if you could swing it, that's what I would vote for. > > ----- Original Message ----- >> I personally like branded USB drives. We could even pre-image them with >> a specific version of Hawkular, so that people could just boot it up for >> testing or evaluation. And of course, stickers! The jBPM team has a set >> of them with different messages, from powerful quotes about "business >> processes" to funny messages. >> >> - Juca. >> >> On 12.11.2015 11:29, Thomas Heute wrote: >>> I'd like to open the discussion to *anyone* on something light: Hawkular >>> Goodies ;) >>> >>> I would like to get some goodies to give away at conferences, for >>> contributors... >>> >>> I would like to have something that is not going to the trash right >>> away, something you would want to have (and doesn't cost a fortune ;)). >>> >>> I am personally not fond of T-shirts as we usually get many at >>> conferences unless the design is really fun/original. >>> >>> So please make your proposals and then we can vote, we may end with 2 >>> results, cheaper to spread more/slightly more expensive for special >>> occasions. >>> Maybe you saw/received something fun/useful in the past. >>> >>> Example of something original: >>> Atlassian socks: >>> https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 >>> >>> >>> Don't be shy :) >>> >>> If we go to the end with your idea, you would definitely get the first >>> item ;) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.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 Gabriel Cardoso UX designer @ Red Hat From theute at redhat.com Fri Nov 13 09:41:59 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 13 Nov 2015 15:41:59 +0100 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: References: <5645C14F.5050100@redhat.com> <1316782933.8151263.1447424409692.JavaMail.zimbra@redhat.com> Message-ID: Nice ideas ! On Fri, Nov 13, 2015 at 3:37 PM, Gabriel Cardoso wrote: > Brainstorming: > > - USB ventilator: > http://www.amazon.com/ARCTIC-USB-Powered-Portable-Solution-Gooseneck/dp/B003XN24GY/ref=sr_1_5?s=pc&ie=UTF8&qid=1447425151&sr=1-5&keywords=usb+fan > (good for summer) > - USB beverage warmer: > http://www.amazon.com/New-Coffee-Beverage-Warmer-Heater/dp/B004P15KAK/ref=sr_1_7?s=pc&ie=UTF8&qid=1447425044&sr=1-7&keywords=usb+beverage+warmer > (good for winter) > - USB hub: > http://www.dx.com/p/ssk-shu024-usb-2-0-4-port-hi-speed-usb-hub-for-portable-hard-disk-drive-orange-394348#.VkX1GYTWFp8 > > Gabriel > > > > On Nov 13, 2015, at 12:20 PM, John Mazzitelli wrote: > > > > Branded USB drives would be nice, but probably expensive. But if you > could swing it, that's what I would vote for. > > > > ----- Original Message ----- > >> I personally like branded USB drives. We could even pre-image them with > >> a specific version of Hawkular, so that people could just boot it up for > >> testing or evaluation. And of course, stickers! The jBPM team has a set > >> of them with different messages, from powerful quotes about "business > >> processes" to funny messages. > >> > >> - Juca. > >> > >> On 12.11.2015 11:29, Thomas Heute wrote: > >>> I'd like to open the discussion to *anyone* on something light: > Hawkular > >>> Goodies ;) > >>> > >>> I would like to get some goodies to give away at conferences, for > >>> contributors... > >>> > >>> I would like to have something that is not going to the trash right > >>> away, something you would want to have (and doesn't cost a fortune ;)). > >>> > >>> I am personally not fond of T-shirts as we usually get many at > >>> conferences unless the design is really fun/original. > >>> > >>> So please make your proposals and then we can vote, we may end with 2 > >>> results, cheaper to spread more/slightly more expensive for special > >>> occasions. > >>> Maybe you saw/received something fun/useful in the past. > >>> > >>> Example of something original: > >>> Atlassian socks: > >>> > https://twitter.com/tgrall/status/664728176266997760?utm_source=fb&utm_medium=fb&utm_campaign=tgrall&utm_content=664728176266997760 > >>> > >>> > >>> Don't be shy :) > >>> > >>> If we go to the end with your idea, you would definitely get the first > >>> item ;) > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.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 > > Gabriel Cardoso > UX designer @ Red Hat > > > > > _______________________________________________ > 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/20151113/3d57f8b1/attachment.html From ploffay at redhat.com Fri Nov 13 09:46:32 2015 From: ploffay at redhat.com (Pavol Loffay) Date: Fri, 13 Nov 2015 15:46:32 +0100 Subject: [Hawkular-dev] Hawkular goodies / swag In-Reply-To: References: <5645C14F.5050100@redhat.com> <1316782933.8151263.1447424409692.JavaMail.zimbra@redhat.com> Message-ID: - Led Torch, could be nice and useful: http://shop.theaa.com/files/B0958-9-LED-TORCH.jpg - Tea mug http://www.qualitylogoproducts.com/custom-mugs/11-oz.-coffee-mug-superextralarge-278668.jpg