From gbrown at redhat.com Tue Mar 1 03:34:54 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 03:34:54 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56CF5D7C.9030706@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> Message-ID: <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> Hi Peter, I've done a quick test with latest snapshot of BTM in hawkular master, and the integration feature pack seems to be working fine. Just wanted to confirm there were no other changes you wanted to do before I released BTM? Regards Gary ----- Original Message ----- > Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you > indeed might consider waiting for the new accounts FP and then remove > the files that you copied from hawkular-accounts-feature-pack as made > possible by the new FP plugin that is available via Parent 36. I am just > doing the same thing in commons. I can show you the result when I it is > ready to give you some guidance. -- P > > On 2016-02-25 17:58, Gary Brown wrote: > > Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will need > > to do another release? > > > > ----- Original Message ----- > >> Hi *, > >> > >> There are two new parent releases 36 and 37. > >> > >> Version 36 contains some usual lib and plugin upgrades [1] and should be > >> applicable smoothly in all Hawkular components. I already have some PRs > >> ready. You do not need to do anything unless you need to proceed quickly. > >> Parent 36 should be used in Hawkular 1.0.0.Alpha11. > >> > >> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to > >> need adaptations in components, most notably in Inventory. Feel free to > >> start experimenting with Hawkular Parent 37. > >> > >> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > >> > >> Best, > >> > >> Peter > >> > >> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 > >> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Tue Mar 1 03:42:18 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Mar 2016 09:42:18 +0100 Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> Message-ID: <56D555EA.6040909@redhat.com> Hi Gary, On 2016-03-01 09:34, Gary Brown wrote: > Hi Peter, > > I've done a quick test with latest snapshot of BTM in hawkular master, and the integration feature pack seems to be working fine. Just wanted to confirm there were no other changes you wanted to do before I released BTM? No, only Parent 36 and the related cosmetics. Feel free to release now. -- P > Regards > Gary > > ----- Original Message ----- >> Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you >> indeed might consider waiting for the new accounts FP and then remove >> the files that you copied from hawkular-accounts-feature-pack as made >> possible by the new FP plugin that is available via Parent 36. I am just >> doing the same thing in commons. I can show you the result when I it is >> ready to give you some guidance. -- P >> >> On 2016-02-25 17:58, Gary Brown wrote: >>> Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will need >>> to do another release? >>> >>> ----- Original Message ----- >>>> Hi *, >>>> >>>> There are two new parent releases 36 and 37. >>>> >>>> Version 36 contains some usual lib and plugin upgrades [1] and should be >>>> applicable smoothly in all Hawkular components. I already have some PRs >>>> ready. You do not need to do anything unless you need to proceed quickly. >>>> Parent 36 should be used in Hawkular 1.0.0.Alpha11. >>>> >>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to >>>> need adaptations in components, most notably in Inventory. Feel free to >>>> start experimenting with Hawkular Parent 37. >>>> >>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. >>>> >>>> Best, >>>> >>>> Peter >>>> >>>> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 >>>> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Mar 1 03:52:40 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 01 Mar 2016 09:52:40 +0100 Subject: [Hawkular-dev] "Matter" support in Hawkular Message-ID: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> Hi, [ I picked "Matter" on purpose in the subject, as the other term (E.) is too much overloaded. ] ManageIQ has Events (going forward I call them ME), that are similar to our Alerts. There are some event parsers that take incoming data and then forward it into the MiQ events system, where automatic actions can be triggered Now we have a pretty similar concept with our alerts. For ME on metrics, MiQ pulls the metrics and the provider integration creates the ME on them. I wonder if for other purposes we can use our existing alerts subsystem with some "canned alerts", that translate input into such MiQ-Events and forward them into MiQ. With "canned" I mean that those are not set up via UI, but rather we have "trigger templates" that are applied each time a new resource of a given type is added to inventory. This implies that those templates can only work on things that do not have a variable threshold like system going up/down, WildFly reporting "reload needed" and so on. While it would be certainly possible to implement this at the level of emitting inventory "matters" and metric "matters" and so on I think having that central piece of logic to do it - could be better to handle. From gbrown at redhat.com Tue Mar 1 04:02:17 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 04:02:17 -0500 (EST) Subject: [Hawkular-dev] "Matter" support in Hawkular In-Reply-To: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> References: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> Message-ID: <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> Although having "out of the box" canned triggers defined, it may also still be good to provide users with a customisation mechanism to define their own alert triggers - which create "events" for MiQ to consume and react to. Users could just use the REST APIs - but still may be more user friendly to offer some form of UI. This shouldn't be an issue, if it is considered configuration/customisation of the provider? Regards Gary ----- Original Message ----- > Hi, > > [ I picked "Matter" on purpose in the subject, as the other term (E.) is > too much overloaded. ] > > ManageIQ has Events (going forward I call them ME), that are similar to > our Alerts. > There are some event parsers that take incoming data and then forward it > into the > MiQ events system, where automatic actions can be triggered > > Now we have a pretty similar concept with our alerts. > > For ME on metrics, MiQ pulls the metrics and the provider integration > creates > the ME on them. > > I wonder if for other purposes we can use our existing alerts subsystem > with some "canned alerts", that translate input into such MiQ-Events and > forward them into MiQ. > With "canned" I mean that those are not set up via UI, but rather we > have "trigger templates" that are applied each time a new resource of a > given type is added to inventory. > This implies that those templates can only work on things that do not > have > a variable threshold like system going up/down, WildFly reporting > "reload > needed" and so on. > > While it would be certainly possible to implement this at the level of > emitting > inventory "matters" and metric "matters" and so on I think having that > central > piece of logic to do it - could be better to handle. > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Tue Mar 1 04:11:57 2016 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 1 Mar 2016 04:11:57 -0500 (EST) Subject: [Hawkular-dev] "Matter" support in Hawkular In-Reply-To: <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> References: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> Message-ID: <201249311.2181713.1456823517117.JavaMail.zimbra@redhat.com> I think the point is where this concept belongs (MiQ or the provider, or somewhere in the middle). I see valid that a provider have events that are forwarded to MiQ. As it is commented, these events can go from different degree of complexities (from quite simple, or even more complicated, with rules to generate this). How to configure/manage this on the provider is the key, as Gary comments, possible options could be REST only, or even UI. My point is that we are introducing a new concept in MiQ which is the application point of view, so, perhaps the whole Policy mechanism of MiQ is not enough to offer the richness that an application point of view from middleware perspective needs, so having the way to define these events in the provider is ok. Lucas ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Tuesday, March 1, 2016 10:02:17 AM > Subject: Re: [Hawkular-dev] "Matter" support in Hawkular > > Although having "out of the box" canned triggers defined, it may also still > be good to provide users with a customisation mechanism to define their own > alert triggers - which create "events" for MiQ to consume and react to. > > Users could just use the REST APIs - but still may be more user friendly to > offer some form of UI. This shouldn't be an issue, if it is considered > configuration/customisation of the provider? > > Regards > Gary > > ----- Original Message ----- > > Hi, > > > > [ I picked "Matter" on purpose in the subject, as the other term (E.) is > > too much overloaded. ] > > > > ManageIQ has Events (going forward I call them ME), that are similar to > > our Alerts. > > There are some event parsers that take incoming data and then forward it > > into the > > MiQ events system, where automatic actions can be triggered > > > > Now we have a pretty similar concept with our alerts. > > > > For ME on metrics, MiQ pulls the metrics and the provider integration > > creates > > the ME on them. > > > > I wonder if for other purposes we can use our existing alerts subsystem > > with some "canned alerts", that translate input into such MiQ-Events and > > forward them into MiQ. > > With "canned" I mean that those are not set up via UI, but rather we > > have "trigger templates" that are applied each time a new resource of a > > given type is added to inventory. > > This implies that those templates can only work on things that do not > > have > > a variable threshold like system going up/down, WildFly reporting > > "reload > > needed" and so on. > > > > While it would be certainly possible to implement this at the level of > > emitting > > inventory "matters" and metric "matters" and so on I think having that > > central > > piece of logic to do it - could be better to handle. > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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 Mar 1 04:30:45 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 01 Mar 2016 10:30:45 +0100 Subject: [Hawkular-dev] "Matter" support in Hawkular In-Reply-To: <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> References: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> Message-ID: <9B02B6E8-5378-42FE-AC6D-59D2EBC85296@redhat.com> On 1 Mar 2016, at 10:02, Gary Brown wrote: > Although having "out of the box" canned triggers defined, it may also > still be good to provide users with a customisation mechanism to > define their own alert triggers - which create "events" for MiQ to > consume and react to. I think this depends on the use case you want to address. We need to make sure not to confuse users with basically two places in the UI to set up "alerts" - one in the provider integration and one in the 'automate' and 'control' sections of the MiQ UI. Actually before sending my original mail I had a section about configuring some details of those canned triggers via e.g. a config file. > Users could just use the REST APIs - but still may be more user > friendly to offer some form of UI. This shouldn't be an issue, if it > is considered configuration/customisation of the provider? Yes. If it is clearly not duplicating the treatment of the MiQ-events that already exists and rather configures the way the provider initially sets up the translation from Hawkular-internals to MiQ-Events. From gbrown at redhat.com Tue Mar 1 04:40:39 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 04:40:39 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56D555EA.6040909@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> <56D555EA.6040909@redhat.com> Message-ID: <1731055353.26235926.1456825239274.JavaMail.zimbra@redhat.com> Spoke too soon - I hadn't set hawkular master to use parent 36, or updated commons/accounts. Currently the artifacts are being put in different locations in the modules folder. Console is not showing up. Any suggestion for how to proceed? Looks like BTM is dependent upon console being updated as well. Regards Gary ----- Original Message ----- > Hi Gary, > > On 2016-03-01 09:34, Gary Brown wrote: > > Hi Peter, > > > > I've done a quick test with latest snapshot of BTM in hawkular master, and > > the integration feature pack seems to be working fine. Just wanted to > > confirm there were no other changes you wanted to do before I released > > BTM? > > No, only Parent 36 and the related cosmetics. Feel free to release now. -- P > > > Regards > > Gary > > > > ----- Original Message ----- > >> Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you > >> indeed might consider waiting for the new accounts FP and then remove > >> the files that you copied from hawkular-accounts-feature-pack as made > >> possible by the new FP plugin that is available via Parent 36. I am just > >> doing the same thing in commons. I can show you the result when I it is > >> ready to give you some guidance. -- P > >> > >> On 2016-02-25 17:58, Gary Brown wrote: > >>> Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will > >>> need > >>> to do another release? > >>> > >>> ----- Original Message ----- > >>>> Hi *, > >>>> > >>>> There are two new parent releases 36 and 37. > >>>> > >>>> Version 36 contains some usual lib and plugin upgrades [1] and should be > >>>> applicable smoothly in all Hawkular components. I already have some PRs > >>>> ready. You do not need to do anything unless you need to proceed > >>>> quickly. > >>>> Parent 36 should be used in Hawkular 1.0.0.Alpha11. > >>>> > >>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to > >>>> need adaptations in components, most notably in Inventory. Feel free to > >>>> start experimenting with Hawkular Parent 37. > >>>> > >>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > >>>> > >>>> Best, > >>>> > >>>> Peter > >>>> > >>>> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 > >>>> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Tue Mar 1 05:21:49 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 05:21:49 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <1731055353.26235926.1456825239274.JavaMail.zimbra@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> <56D555EA.6040909@redhat.com> <1731055353.26235926.1456825239274.JavaMail.zimbra@redhat.com> Message-ID: <1853557335.26243674.1456827709954.JavaMail.zimbra@redhat.com> Hi Peter If all of the artifacts in the modules/org/hawkular...../nest/deployments folder are moved under modules/system/layers/..., then it worked fine. So I will change the location of the integrated feature pack (including where it places the console bits), assuming that these will be relocated once hawkular is moved to parent 36 etc. Regards Gary ----- Original Message ----- > Spoke too soon - I hadn't set hawkular master to use parent 36, or updated > commons/accounts. > > Currently the artifacts are being put in different locations in the modules > folder. Console is not showing up. > > Any suggestion for how to proceed? Looks like BTM is dependent upon console > being updated as well. > > Regards > Gary > > ----- Original Message ----- > > Hi Gary, > > > > On 2016-03-01 09:34, Gary Brown wrote: > > > Hi Peter, > > > > > > I've done a quick test with latest snapshot of BTM in hawkular master, > > > and > > > the integration feature pack seems to be working fine. Just wanted to > > > confirm there were no other changes you wanted to do before I released > > > BTM? > > > > No, only Parent 36 and the related cosmetics. Feel free to release now. -- > > P > > > > > Regards > > > Gary > > > > > > ----- Original Message ----- > > >> Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you > > >> indeed might consider waiting for the new accounts FP and then remove > > >> the files that you copied from hawkular-accounts-feature-pack as made > > >> possible by the new FP plugin that is available via Parent 36. I am just > > >> doing the same thing in commons. I can show you the result when I it is > > >> ready to give you some guidance. -- P > > >> > > >> On 2016-02-25 17:58, Gary Brown wrote: > > >>> Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will > > >>> need > > >>> to do another release? > > >>> > > >>> ----- Original Message ----- > > >>>> Hi *, > > >>>> > > >>>> There are two new parent releases 36 and 37. > > >>>> > > >>>> Version 36 contains some usual lib and plugin upgrades [1] and should > > >>>> be > > >>>> applicable smoothly in all Hawkular components. I already have some > > >>>> PRs > > >>>> ready. You do not need to do anything unless you need to proceed > > >>>> quickly. > > >>>> Parent 36 should be used in Hawkular 1.0.0.Alpha11. > > >>>> > > >>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed > > >>>> to > > >>>> need adaptations in components, most notably in Inventory. Feel free > > >>>> to > > >>>> start experimenting with Hawkular Parent 37. > > >>>> > > >>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > > >>>> > > >>>> Best, > > >>>> > > >>>> Peter > > >>>> > > >>>> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 > > >>>> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 > > >>>> _______________________________________________ > > >>>> hawkular-dev mailing list > > >>>> hawkular-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > >>>> > > >>> _______________________________________________ > > >>> hawkular-dev mailing list > > >>> hawkular-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > >>> > > >> > > >> _______________________________________________ > > >> hawkular-dev mailing list > > >> hawkular-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > >> > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Tue Mar 1 05:39:32 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Mar 2016 11:39:32 +0100 Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <1853557335.26243674.1456827709954.JavaMail.zimbra@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> <56D555EA.6040909@redhat.com> <1731055353.26235926.1456825239274.JavaMail.zimbra@redhat.com> <1853557335.26243674.1456827709954.JavaMail.zimbra@redhat.com> Message-ID: <56D57164.7090200@redhat.com> Hi Gary, where can I see the changes you speak about? -- P On 2016-03-01 11:21, Gary Brown wrote: > Hi Peter > > If all of the artifacts in the modules/org/hawkular...../nest/deployments folder are moved under modules/system/layers/..., then it worked fine. So I will change the location of the integrated feature pack (including where it places the console bits), assuming that these will be relocated once hawkular is moved to parent 36 etc. > > Regards > Gary > > ----- Original Message ----- >> Spoke too soon - I hadn't set hawkular master to use parent 36, or updated >> commons/accounts. >> >> Currently the artifacts are being put in different locations in the modules >> folder. Console is not showing up. >> >> Any suggestion for how to proceed? Looks like BTM is dependent upon console >> being updated as well. >> >> Regards >> Gary >> >> ----- Original Message ----- >>> Hi Gary, >>> >>> On 2016-03-01 09:34, Gary Brown wrote: >>>> Hi Peter, >>>> >>>> I've done a quick test with latest snapshot of BTM in hawkular master, >>>> and >>>> the integration feature pack seems to be working fine. Just wanted to >>>> confirm there were no other changes you wanted to do before I released >>>> BTM? >>> >>> No, only Parent 36 and the related cosmetics. Feel free to release now. -- >>> P >>> >>>> Regards >>>> Gary >>>> >>>> ----- Original Message ----- >>>>> Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you >>>>> indeed might consider waiting for the new accounts FP and then remove >>>>> the files that you copied from hawkular-accounts-feature-pack as made >>>>> possible by the new FP plugin that is available via Parent 36. I am just >>>>> doing the same thing in commons. I can show you the result when I it is >>>>> ready to give you some guidance. -- P >>>>> >>>>> On 2016-02-25 17:58, Gary Brown wrote: >>>>>> Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will >>>>>> need >>>>>> to do another release? >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Hi *, >>>>>>> >>>>>>> There are two new parent releases 36 and 37. >>>>>>> >>>>>>> Version 36 contains some usual lib and plugin upgrades [1] and should >>>>>>> be >>>>>>> applicable smoothly in all Hawkular components. I already have some >>>>>>> PRs >>>>>>> ready. You do not need to do anything unless you need to proceed >>>>>>> quickly. >>>>>>> Parent 36 should be used in Hawkular 1.0.0.Alpha11. >>>>>>> >>>>>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed >>>>>>> to >>>>>>> need adaptations in components, most notably in Inventory. Feel free >>>>>>> to >>>>>>> start experimenting with Hawkular Parent 37. >>>>>>> >>>>>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 >>>>>>> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 >>>>>>> _______________________________________________ >>>>>>> hawkular-dev mailing list >>>>>>> hawkular-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Tue Mar 1 05:47:29 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 05:47:29 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56D57164.7090200@redhat.com> References: <56CF3146.8020508@redhat.com> <2135739364.24719822.1456419482007.JavaMail.zimbra@redhat.com> <56CF5D7C.9030706@redhat.com> <672378673.26229631.1456821294767.JavaMail.zimbra@redhat.com> <56D555EA.6040909@redhat.com> <1731055353.26235926.1456825239274.JavaMail.zimbra@redhat.com> <1853557335.26243674.1456827709954.JavaMail.zimbra@redhat.com> <56D57164.7090200@redhat.com> Message-ID: <899950072.26245886.1456829249120.JavaMail.zimbra@redhat.com> https://github.com/hawkular/hawkular-btm/commit/92f76b1af49c485e50f5f60e3b9ee9a4a1f876c0 ----- Original Message ----- > Hi Gary, where can I see the changes you speak about? -- P > > On 2016-03-01 11:21, Gary Brown wrote: > > Hi Peter > > > > If all of the artifacts in the modules/org/hawkular...../nest/deployments > > folder are moved under modules/system/layers/..., then it worked fine. So > > I will change the location of the integrated feature pack (including where > > it places the console bits), assuming that these will be relocated once > > hawkular is moved to parent 36 etc. > > > > Regards > > Gary > > > > ----- Original Message ----- > >> Spoke too soon - I hadn't set hawkular master to use parent 36, or updated > >> commons/accounts. > >> > >> Currently the artifacts are being put in different locations in the > >> modules > >> folder. Console is not showing up. > >> > >> Any suggestion for how to proceed? Looks like BTM is dependent upon > >> console > >> being updated as well. > >> > >> Regards > >> Gary > >> > >> ----- Original Message ----- > >>> Hi Gary, > >>> > >>> On 2016-03-01 09:34, Gary Brown wrote: > >>>> Hi Peter, > >>>> > >>>> I've done a quick test with latest snapshot of BTM in hawkular master, > >>>> and > >>>> the integration feature pack seems to be working fine. Just wanted to > >>>> confirm there were no other changes you wanted to do before I released > >>>> BTM? > >>> > >>> No, only Parent 36 and the related cosmetics. Feel free to release now. > >>> -- > >>> P > >>> > >>>> Regards > >>>> Gary > >>>> > >>>> ----- Original Message ----- > >>>>> Hi Gary, seeing that you extend the hawkular-accounts-feature-pack, you > >>>>> indeed might consider waiting for the new accounts FP and then remove > >>>>> the files that you copied from hawkular-accounts-feature-pack as made > >>>>> possible by the new FP plugin that is available via Parent 36. I am > >>>>> just > >>>>> doing the same thing in commons. I can show you the result when I it is > >>>>> ready to give you some guidance. -- P > >>>>> > >>>>> On 2016-02-25 17:58, Gary Brown wrote: > >>>>>> Ah :( - just released BTM 0.7.1.Final on parent 35. So I guess I will > >>>>>> need > >>>>>> to do another release? > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> Hi *, > >>>>>>> > >>>>>>> There are two new parent releases 36 and 37. > >>>>>>> > >>>>>>> Version 36 contains some usual lib and plugin upgrades [1] and should > >>>>>>> be > >>>>>>> applicable smoothly in all Hawkular components. I already have some > >>>>>>> PRs > >>>>>>> ready. You do not need to do anything unless you need to proceed > >>>>>>> quickly. > >>>>>>> Parent 36 should be used in Hawkular 1.0.0.Alpha11. > >>>>>>> > >>>>>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed > >>>>>>> to > >>>>>>> need adaptations in components, most notably in Inventory. Feel free > >>>>>>> to > >>>>>>> start experimenting with Hawkular Parent 37. > >>>>>>> > >>>>>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 > >>>>>>> [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 > >>>>>>> _______________________________________________ > >>>>>>> hawkular-dev mailing list > >>>>>>> hawkular-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> hawkular-dev mailing list > >>>>>> hawkular-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> hawkular-dev mailing list > >>>>> hawkular-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>>> > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>> > >>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Tue Mar 1 07:48:23 2016 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Mar 2016 07:48:23 -0500 (EST) Subject: [Hawkular-dev] Hawkular BTM 0.7.2.Final released In-Reply-To: <1323506937.26266988.1456836255334.JavaMail.zimbra@redhat.com> Message-ID: <1037264165.26267869.1456836503351.JavaMail.zimbra@redhat.com> Hi The main purpose of this release is to provide integration of BTM into the main Hawkular project. I'd like to especially thank Alexandre Mendonca and Gabriel Cardoso for their great contributions to improving the UI! Regards Gary From tsegismo at redhat.com Tue Mar 1 08:27:07 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 1 Mar 2016 14:27:07 +0100 Subject: [Hawkular-dev] Hawkular BTM 0.7.2.Final released In-Reply-To: <1037264165.26267869.1456836503351.JavaMail.zimbra@redhat.com> References: <1037264165.26267869.1456836503351.JavaMail.zimbra@redhat.com> Message-ID: <56D598AB.3030105@redhat.com> Congrats guys! Le 01/03/2016 13:48, Gary Brown a ?crit : > Hi > > The main purpose of this release is to provide integration of BTM into the main Hawkular project. > > I'd like to especially thank Alexandre Mendonca and Gabriel Cardoso for their great contributions to improving the UI! > > Regards > Gary > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Tue Mar 1 09:05:06 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 1 Mar 2016 09:05:06 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56CF3146.8020508@redhat.com> References: <56CF3146.8020508@redhat.com> Message-ID: <402087101.34170690.1456841106448.JavaMail.zimbra@redhat.com> > > Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to > need adaptations in components, most notably in Inventory. Feel free to > start experimenting with Hawkular Parent 37. > > Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > Hawkular Metrics currently does not support C* 3.3 and there are no plans to retroactively update any previous releases to support C* 3.x. I am not sure what is the basis for the information in the last sentence. Thank you, Stefan Negrea From snegrea at redhat.com Tue Mar 1 09:05:10 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 1 Mar 2016 09:05:10 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56CF3146.8020508@redhat.com> References: <56CF3146.8020508@redhat.com> Message-ID: <457223548.34170706.1456841110676.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Thursday, February 25, 2016 10:52:22 AM > Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) > > Hi *, > > There are two new parent releases 36 and 37. > > Version 36 contains some usual lib and plugin upgrades [1] and should be > applicable smoothly in all Hawkular components. I already have some PRs > ready. You do not need to do anything unless you need to proceed quickly. > Parent 36 should be used in Hawkular 1.0.0.Alpha11. > > Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to > need adaptations in components, most notably in Inventory. Feel free to > start experimenting with Hawkular Parent 37. > > Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > > Best, > > Peter > > [1] https://github.com/hawkular/hawkular-parent-pom/commits/36 > [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Tue Mar 1 09:31:08 2016 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Tue, 1 Mar 2016 09:31:08 -0500 Subject: [Hawkular-dev] "Matter" support in Hawkular In-Reply-To: <201249311.2181713.1456823517117.JavaMail.zimbra@redhat.com> References: <7EF7499F-3BC8-4D1F-BFFE-610E8FDD7834@redhat.com> <1085476951.26232178.1456822937187.JavaMail.zimbra@redhat.com> <201249311.2181713.1456823517117.JavaMail.zimbra@redhat.com> Message-ID: <56D5A7AC.9040408@redhat.com> From what I've seen so far MiQ has a bunch of pre-defined events (MEs). On first look, these MEs seem mostly relevant to VMs/Cloud providers and maybe not so much to a MW manager. It is, I think, possible to define custom events for a provider, like the hawkular provider. Importantly, I think you can only send MiQ an event that it knows about. So, any sort of ad-hoc generation of Hawkular events (HEs) may not be a good fit, or there may need to be some "catch-all" pre-defined ME to which they all map. I do think it makes sense that the Hawkular provider define some custom MEs that are more specific to application monitoring. Yesterday I started experimenting and am trying to generate deployment events (failures and successes) in MiQ. How these get to MiQ is an implementation detail of our provider but it could very well make sense to use H Alerts to generate HEs that then get pulled (I'm not sure yet how this happens, I think it is a pull) as MEs, via the gem via a fetch using the H Alerts rest API. In other words, use H Alerts' as our provider impl for HE handling. It already has robust handling for events, whether trigger generated or injected via the API. So generate/feed all events into, and then fetch them via, H Alerts. This does not even require any trigger definitions, or any alert generation, until or unless we need it. Just use the already existing HE apis. This is exactly how the deployment eventing works. We capture the deployment response via the command gateway listener, which then converts the response into an event. That event would then make its way from an HE to an ME via the hawkular provider. As an aside, we already have migrated all of Hawkular's trigger definitions to the server so all of the old triggers are already in headless hawkular. Whether we need any of them is unclear. For example, an alert based on a failed deployment would likely no longer be useful in hawkular, instead it would probably be defined as an alert in MiQ, based on the Failed Deployment ME. On 3/1/2016 4:11 AM, Lucas Ponce wrote: > I think the point is where this concept belongs (MiQ or the provider, or somewhere in the middle). > > I see valid that a provider have events that are forwarded to MiQ. > > As it is commented, these events can go from different degree of complexities (from quite simple, or even more complicated, with rules to generate this). > > How to configure/manage this on the provider is the key, as Gary comments, possible options could be REST only, or even UI. > > My point is that we are introducing a new concept in MiQ which is the application point of view, so, perhaps the whole Policy mechanism of MiQ is not enough to offer the richness that an application point of view from middleware perspective needs, so having the way to define these events in the provider is ok. > > Lucas > > ----- Original Message ----- >> From: "Gary Brown" >> To: "Discussions around Hawkular development" >> Sent: Tuesday, March 1, 2016 10:02:17 AM >> Subject: Re: [Hawkular-dev] "Matter" support in Hawkular >> >> Although having "out of the box" canned triggers defined, it may also still >> be good to provide users with a customisation mechanism to define their own >> alert triggers - which create "events" for MiQ to consume and react to. >> >> Users could just use the REST APIs - but still may be more user friendly to >> offer some form of UI. This shouldn't be an issue, if it is considered >> configuration/customisation of the provider? >> >> Regards >> Gary >> >> ----- Original Message ----- >>> Hi, >>> >>> [ I picked "Matter" on purpose in the subject, as the other term (E.) is >>> too much overloaded. ] >>> >>> ManageIQ has Events (going forward I call them ME), that are similar to >>> our Alerts. >>> There are some event parsers that take incoming data and then forward it >>> into the >>> MiQ events system, where automatic actions can be triggered >>> >>> Now we have a pretty similar concept with our alerts. >>> >>> For ME on metrics, MiQ pulls the metrics and the provider integration >>> creates >>> the ME on them. >>> >>> I wonder if for other purposes we can use our existing alerts subsystem >>> with some "canned alerts", that translate input into such MiQ-Events and >>> forward them into MiQ. >>> With "canned" I mean that those are not set up via UI, but rather we >>> have "trigger templates" that are applied each time a new resource of a >>> given type is added to inventory. >>> This implies that those templates can only work on things that do not >>> have >>> a variable threshold like system going up/down, WildFly reporting >>> "reload >>> needed" and so on. >>> >>> While it would be certainly possible to implement this at the level of >>> emitting >>> inventory "matters" and metric "matters" and so on I think having that >>> central >>> piece of logic to do it - could be better to handle. >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.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/20160301/73316557/attachment-0001.html From ppalaga at redhat.com Tue Mar 1 09:38:53 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Mar 2016 15:38:53 +0100 Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <402087101.34170690.1456841106448.JavaMail.zimbra@redhat.com> References: <56CF3146.8020508@redhat.com> <402087101.34170690.1456841106448.JavaMail.zimbra@redhat.com> Message-ID: <56D5A97D.2010900@redhat.com> Hi Stefan, inline... On 2016-03-01 15:05, Stefan Negrea wrote: > >> >> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to >> need adaptations in components, most notably in Inventory. Feel free to >> start experimenting with Hawkular Parent 37. >> >> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. >> > > Hawkular Metrics currently does not support C* 3.3 and there are no plans to retroactively update any previous releases to support C* 3.x. I am not sure what is the basis for the information in the last sentence. Sorry for the confusion, I had improper info about which OpenShift version is c* 3.3 targeting. Apparently, c* 3.3 targets OpenShift 3.3. Thanks, -- P > > Thank you, > Stefan Negrea > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Tue Mar 1 10:44:23 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 1 Mar 2016 10:44:23 -0500 (EST) Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <56D5A97D.2010900@redhat.com> References: <56CF3146.8020508@redhat.com> <402087101.34170690.1456841106448.JavaMail.zimbra@redhat.com> <56D5A97D.2010900@redhat.com> Message-ID: <1576345469.34211982.1456847063755.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Tuesday, March 1, 2016 8:38:53 AM > Subject: Re: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) > > Hi Stefan, inline... > > On 2016-03-01 15:05, Stefan Negrea wrote: > > > >> > >> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to > >> need adaptations in components, most notably in Inventory. Feel free to > >> start experimenting with Hawkular Parent 37. > >> > >> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. > >> > > > > Hawkular Metrics currently does not support C* 3.3 and there are no plans > > to retroactively update any previous releases to support C* 3.x. I am not > > sure what is the basis for the information in the last sentence. > > Sorry for the confusion, I had improper info about which OpenShift > version is c* 3.3 targeting. Apparently, c* 3.3 targets OpenShift 3.3. This is not accurate either; I am not aware of any final decisions regarding C* upgrades at this time. > > Thanks, > > -- P > > > > > Thank you, > > Stefan Negrea > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Tue Mar 1 11:32:24 2016 From: jsanda at redhat.com (John Sanda) Date: Tue, 1 Mar 2016 11:32:24 -0500 Subject: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) In-Reply-To: <1576345469.34211982.1456847063755.JavaMail.zimbra@redhat.com> References: <56CF3146.8020508@redhat.com> <402087101.34170690.1456841106448.JavaMail.zimbra@redhat.com> <56D5A97D.2010900@redhat.com> <1576345469.34211982.1456847063755.JavaMail.zimbra@redhat.com> Message-ID: > On Mar 1, 2016, at 10:44 AM, Stefan Negrea wrote: > > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Tuesday, March 1, 2016 8:38:53 AM >> Subject: Re: [Hawkular-dev] Parent releases 36 (usual upgrades) and 37 (Cassandra 3.3) >> >> Hi Stefan, inline... >> >> On 2016-03-01 15:05, Stefan Negrea wrote: >>> >>>> >>>> Version 37 upgrades to Cassandra 3.3 and Driver 3.0.0 and is supposed to >>>> need adaptations in components, most notably in Inventory. Feel free to >>>> start experimenting with Hawkular Parent 37. >>>> >>>> Cassandra 3.3 was chosen to be the version for OpenShift 3.2. >>>> >>> >>> Hawkular Metrics currently does not support C* 3.3 and there are no plans >>> to retroactively update any previous releases to support C* 3.x. I am not >>> sure what is the basis for the information in the last sentence. >> >> Sorry for the confusion, I had improper info about which OpenShift >> version is c* 3.3 targeting. Apparently, c* 3.3 targets OpenShift 3.3. > > > This is not accurate either; I am not aware of any final decisions regarding C* upgrades at this time. We are currently on Cassandra 2.2.2. I think we want to move to 3.x sooner than later so that we can start getting familiar with the changes and to start developing performance baselines. Any performance testing we do right now loses a lot of its value once we move to 3.x. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160301/defaae02/attachment.html From k.krish at yahoo.com Tue Mar 1 13:14:16 2016 From: k.krish at yahoo.com (k.krish at yahoo.com) Date: Tue, 1 Mar 2016 18:14:16 +0000 (UTC) Subject: [Hawkular-dev] GSOC - 2016 Hawkular-Android Client References: <334535182.1282891.1456856056118.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <334535182.1282891.1456856056118.JavaMail.yahoo@mail.yahoo.com> Dear All, I am Krishna, I am currently pursuing my Masters in Computing at NUS - National University of Singapore. I came across the project Hawkular-Android Client and I am very much interested in working on the project. I have participated and completed the GSOC - 2015 Program with the community Syslog-ng Project. I have developed a Syslog-ng Server monitoring application for Android.? The link for the project - GSOC 2015 ?-?https://github.com/Krishna41/Syslog-ng-Monitor-Android I have also created a UI Testing Project with Robotium Framework. Test Project Link -?https://github.com/Krishna41/Syslog-ng-Monitor-Android-Test I kindly request you all to guide me provide suggestions for moving forward. I am very much excited and looking forward to working with JBoss Community. Thanks and Regards,Krishna. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160301/2be9d33a/attachment.html From hrupp at redhat.com Tue Mar 1 15:12:16 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 01 Mar 2016 21:12:16 +0100 Subject: [Hawkular-dev] ManageIQ / Hawkular - some questions In-Reply-To: <186540211.22665975.1455880695139.JavaMail.zimbra@redhat.com> References: <186540211.22665975.1455880695139.JavaMail.zimbra@redhat.com> Message-ID: Hi, sorry for not having responded earlier (and this email was laying written but not sent in my outbox too :-( ) > Some my preliminar doubts (perhaps this was discussed in a different > thread, so please, point me to that if I missed it): > > * Where will be stored metrics and inventory ? > > That info should live in the provider (owner of that information) and > copied to ManageIQ repository ? Or on Yes. MiQ will pull that via the provider integration code. > the contrary, ManageIQ will be the owner of that info and the provider > is a technical cache. While it is a cache, it is also the authoritative source. > * How information of the providers is collected ? > > In some preliminary meeting I understood that agents or whatever > mechanism that collects information of the middleware domain should be > sent to the provider. Is this Yes > valid ? or the architecture is that in the future all agents should be > managed directly into ManageIQ ? No. Please look at figure 1 of http://www.hawkular.org/blog/2016/02/22/hawkular-manage-iq.html > I guess that this is some kind of hybrid architecture as there will be > always external provider (thinking on Amazon or other domain) that is > managed by ManageIQ but the provider is the owner of the info. Yes. > model, I'm sure that Amazon cloud will have their own alerting > definitions, perhaps an hybrid approach can be used here). Yes. The question is of course how to drive it. At least for some of the alerts you need a UI to set them up. And having 2 places inside the MiQ UI that set up 2 different kinds of alerts could be seen as confusing. What would certainly good is to be have "canned" alerts e.g. for resource going up/down, WildFly needing a reload and a few others where the notification would result into injecting a MiQ event into MiQ for further processing. > * Roles > > Are we going to provide strong role profiles ? for example a > middleware role, that only can see the Middleware information without > any access to cloud/infrastructure. You mean in MiQ? That needs to be decided. I think hiding some of their stuff for newbie users could be helpful. On the other hand, the knowledge MiQ provides for the OS-level (be it real, virtual, containerized) and our knowledge of the application level is a pretty strong combination. > How API should work in this case ? All API should be proxied/routed by > ManageIQ or accesing to the provider That is my understanding. > API is valid ? (Again, thinking on external providers like Amazon > makes me wonder what is the goal of this). From hrupp at redhat.com Tue Mar 1 15:21:55 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 01 Mar 2016 21:21:55 +0100 Subject: [Hawkular-dev] GSOC - 2016 Hawkular-Android Client In-Reply-To: <334535182.1282891.1456856056118.JavaMail.yahoo@mail.yahoo.com> References: <334535182.1282891.1456856056118.JavaMail.yahoo.ref@mail.yahoo.com> <334535182.1282891.1456856056118.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hey Krishna, for Hawkular we require possible students to contribute some non-trivial code (i.e. more than just fixing a typo) in order to be considered. Apart from that you should probably best check out Hawkular and build it and also build the Android client to get a feel. Then when the student submissions start on March 14th, you should submit a proposal with a detailed time line on when you want to achieve what. To get started you can use a pre-built hawkular server and only build the Android client from source. The current master version of Hawkular (will be released soonish) has such a generic inventory browser to walk through the inventory graphs and then pick metrics to chart. That can probably also help in getting started with the thinking of the Android idea. Hth for the start Heiko From jsanda at redhat.com Tue Mar 1 23:02:33 2016 From: jsanda at redhat.com (John Sanda) Date: Tue, 1 Mar 2016 23:02:33 -0500 Subject: [Hawkular-dev] Upgrading Hawkular Metrics to Cassandra 3.x Message-ID: Since Hawkular is still primarily in development mode upgrading dependencies, including databases, is fairly painless. Metrics 0.8.0 however was included in OpenShift 3.1, which means upgrading Cassandra in Metrics is going to be more involved than upgrading the parent pom and upgrading our dev environments, e.g., changing ccm cluster. The following is a brief description of the steps that need to be performed, Run nodetool drain Shut down the node Back up configuration and data files Install new version of Cassandra Apply configuration changes (from old version) to new version. This would include files like cassandra.yaml, cassandra-env.sh, etc. Start the node Run nodetool upgradesstables Repeat for each node in the cluster These steps can be performed as a rolling upgrade; however, no application schema changes should be made until the upgrade is complete and until cluster reports schema agreement. With respect to OpenShift, how much of this needs to be automated? Matt, can you share some insights here? I would like to figure out sooner rather than later how much work we think is involved. Thanks - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160301/23ac9d67/attachment.html From mwringe at redhat.com Wed Mar 2 09:14:16 2016 From: mwringe at redhat.com (Matt Wringe) Date: Wed, 2 Mar 2016 09:14:16 -0500 (EST) Subject: [Hawkular-dev] Upgrading Hawkular Metrics to Cassandra 3.x In-Reply-To: References: Message-ID: <1773912235.34877671.1456928056209.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "John Sanda" > To: "Discussions around Hawkular development" > Cc: "Matt Wringe" > Sent: Tuesday, March 1, 2016 11:02:33 PM > Subject: Upgrading Hawkular Metrics to Cassandra 3.x > > Since Hawkular is still primarily in development mode upgrading dependencies, > including databases, is fairly painless. Metrics 0.8.0 however was included > in OpenShift 3.1, which means upgrading Cassandra in Metrics is going to be > more involved than upgrading the parent pom and upgrading our dev > environments, e.g., changing ccm cluster. The following is a brief > description of the steps that need to be performed, > > > Run nodetool drain > Shut down the node > Back up configuration and data files > Install new version of Cassandra > Apply configuration changes (from old version) to new version. This would > include files like cassandra.yaml, cassandra-env.sh, etc. > Start the node > Run nodetool upgradesstables > Repeat for each node in the cluster > > These steps can be performed as a rolling upgrade; however, no application > schema changes should be made until the upgrade is complete and until > cluster reports schema agreement. > > With respect to OpenShift, how much of this needs to be automated? Matt, can > you share some insights here? I would like to figure out sooner rather than > later how much work we think is involved. If we can automate all of it or parts of it, we should really try and do that. If we can't then we need documentation going over all the steps required and testing to make sure that it all still functions properly. This could be a tricky task to get done right, you will probably want to get started on that sooner rather than later. From jsanda at redhat.com Wed Mar 2 10:43:58 2016 From: jsanda at redhat.com (John Sanda) Date: Wed, 2 Mar 2016 10:43:58 -0500 Subject: [Hawkular-dev] Upgrading Hawkular Metrics to Cassandra 3.x In-Reply-To: <1773912235.34877671.1456928056209.JavaMail.zimbra@redhat.com> References: <1773912235.34877671.1456928056209.JavaMail.zimbra@redhat.com> Message-ID: <2257BCC5-1FC6-47AF-BBB3-3D9F5BB0BC34@redhat.com> > On Mar 2, 2016, at 9:14 AM, Matt Wringe wrote: > > ----- Original Message ----- >> From: "John Sanda" >> To: "Discussions around Hawkular development" >> Cc: "Matt Wringe" >> Sent: Tuesday, March 1, 2016 11:02:33 PM >> Subject: Upgrading Hawkular Metrics to Cassandra 3.x >> >> Since Hawkular is still primarily in development mode upgrading dependencies, >> including databases, is fairly painless. Metrics 0.8.0 however was included >> in OpenShift 3.1, which means upgrading Cassandra in Metrics is going to be >> more involved than upgrading the parent pom and upgrading our dev >> environments, e.g., changing ccm cluster. The following is a brief >> description of the steps that need to be performed, >> >> >> Run nodetool drain >> Shut down the node >> Back up configuration and data files >> Install new version of Cassandra >> Apply configuration changes (from old version) to new version. This would >> include files like cassandra.yaml, cassandra-env.sh, etc. >> Start the node >> Run nodetool upgradesstables >> Repeat for each node in the cluster >> >> These steps can be performed as a rolling upgrade; however, no application >> schema changes should be made until the upgrade is complete and until >> cluster reports schema agreement. >> >> With respect to OpenShift, how much of this needs to be automated? Matt, can >> you share some insights here? I would like to figure out sooner rather than >> later how much work we think is involved. > > If we can automate all of it or parts of it, we should really try and do that. If we can't then we need documentation going over all the steps required and testing to make sure that it all still functions properly. > > This could be a tricky task to get done right, you will probably want to get started on that sooner rather than later. The more we need to automate, the more involved and complicated it is going to be. Updating cassandra.yaml isn?t too bad because we use yaml parse to make changes; however, yaml parsers do not preserve comments so we will lose all comments in cassandra.yaml which is unfortunate because they are an important source of documentation. I am not sure that we can programmatically update cassandra-env.sh since it does not have a structured format. In RHQ we essentially replaced cassandra-env.sh with a properties file so that we could use our configuration subsystem to manage it. Note that it did not have to be a properties file, just a structured format. Everything was done in Java since we had to support both Windows and Linux platforms. We should be able to use shell scripts here which will make things a lot easier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160302/a363dd32/attachment.html From mfoley at redhat.com Wed Mar 2 14:57:46 2016 From: mfoley at redhat.com (Michael Foley) Date: Wed, 2 Mar 2016 14:57:46 -0500 (EST) Subject: [Hawkular-dev] Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Message-ID: <1012422390.35072232.1456948666502.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, March 2, 2016, 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/20160302/67bb601a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 7708 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160302/67bb601a/attachment-0001.bin From gbrown at redhat.com Thu Mar 3 03:10:59 2016 From: gbrown at redhat.com (Gary Brown) Date: Thu, 3 Mar 2016 03:10:59 -0500 (EST) Subject: [Hawkular-dev] Status Report - Week 9 2015 In-Reply-To: <1908332116.27052832.1456992178461.JavaMail.zimbra@redhat.com> Message-ID: <669701928.27054916.1456992659398.JavaMail.zimbra@redhat.com> Accomplishments and key updates: - HWKBTM-342 Fix minor formatting inconsistency between BTM standalone and Hawkular integration UI for the APM page. Also integrated UI dropdown defaults were incorrect on the APM page. - Test and released 0.7.1.FInal of BTM, and merged HWKBTM-312 to integrate BTM into Hawkular. - Test and release BTM 0.7.2.Final with changes required by parent 36 (relocation of modules artifacts). - Completed work on HWKBTM-268 to derive communication (latency) information and provide a REST endpoint for obtaining graph nodes/links for creating a graphical representation of the communication between distributed services. - HWKBTM-353 When obtaining communication details, need to identify the initial fragment as a client (previously based on same uri as the consumer) - ENTESB-5040 Work with GSS to investigate and fix RTGov/Swyd classpath conflict around drools - Trying out node.js as possible next instrumentation environment. Found an interesting project (https://github.com/ValYouW/njsTrace) that can instrument a nodejs app - quite flexible but doesn't give access to all the information we would require, but demonstrates the approach that can be taken to achieve the desired results Next steps: - HWKBTM-340 More accurately calculate the completion time across a business txn with multiple fragments. - More node.js investigation as a background task Risks: - none Asks for Thomas: - none From snegrea at redhat.com Thu Mar 3 09:14:57 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Thu, 3 Mar 2016 09:14:57 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics 0.13.0 - Release In-Reply-To: <543160943.35100216.1457013553602.JavaMail.zimbra@redhat.com> Message-ID: <70879638.35105863.1457014497437.JavaMail.zimbra@redhat.com> Hello Everybody, I am happy to announce release 0.13.0 of Hawkular Metrics. This release is anchored by Hawkular integration enhancements, under-the-cover refactorings and fixes, and a new bulk data generation tool. Here is a list of major changes in this release: 1) Data Generation Tool * A new tool that generates bulk metrics data to be used in performance and load testing. * It generates directly Cassandra data files (SSTables), which leads to a very fast generation process for large amounts of metrics data. * For more details: https://github.com/hawkular/hawkular-metrics/tree/master/data-generator (HWKMETRICS-355) 2) Receive Metrics via Hawkular Bus * When deployed within Hawkular distribution, the project now accepts metrics via the Hawkular Bus; until now only the REST API had support for Metrics insertion. * Hawkular Metrics currently support publishing of newly inserted metrics to the bus and receiving metrics via the bus. * For more details: HWKMETRICS-347, HWKMETRICS-352 3) Sorted Stacked Metrics Results * When requesting stacked metrics aggregation the results are now ordered (HWKMETRICS-353) 4) External Integrations * Heapster sink now divides storing to multiple calls. This is an improvement over the initial implementation that had one REST API call per metric (HWKMETRICS-290) * ptrans now works with a Hawkular Metrics instance protected by Hawkular Accounts via Hawkular distribution (HWKMETRICS-342) * Grafana integration via Influxdb compatible end-point allows connections to a Hawkular Metrics instance protected by Hawkular Accounts via Hawkular distribution (HWKMETRICS-343) Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.13.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/12329530 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 A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer From mazz at redhat.com Thu Mar 3 09:31:01 2016 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 3 Mar 2016 09:31:01 -0500 (EST) Subject: [Hawkular-dev] bug in agent - inventory bulk payload bad? In-Reply-To: References: Message-ID: <1944188543.4736903.1457015461356.JavaMail.zimbra@redhat.com> Jirka - did you file an agent JIRA on this? This is code that was working in the past (no one has touched it for a while AFAIK) so I'm not sure what broke. Sounds like it has to do with that bulk payload builder in the agent. ----- Forwarded Message ----- > From: "Jiri Kremser" > * bulk insert that is done by the agent reports some relationships > multiple times (it's a bug on Agent side), I made the inventory immune to > this so that only the first record is taken into consideration and the rest > is ignored (holds for entities as well as relationships) From ppalaga at redhat.com Wed Mar 9 16:37:24 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 9 Mar 2016 22:37:24 +0100 Subject: [Hawkular-dev] Alpha 11 - Are you ready? In-Reply-To: <56D05849.5080501@redhat.com> References: <56CF3402.90804@redhat.com> <56D03265.2020109@redhat.com> <56D038A9.7030507@redhat.com> <56D03B0C.6080106@redhat.com> <56D04A7B.6090907@redhat.com> <56D05849.5080501@redhat.com> Message-ID: <56E09794.3050800@redhat.com> Hi *, looks like we have all components in place in Hawkular master - the most recent being Alerts 1.0.2.Final, BTM 0.7.4.Final and Agent 0.17.0.Final. I'll release M11 tomorrow morning CET unless somebody vetoes. Thanks, Peter On 2016-02-26 14:51, Jay Shaughnessy wrote: > > We will release alerts only if this is a required dep version change, > otherwise the current release is fine for alpha11. Let me know. > > On 2/26/2016 7:52 AM, Juraci Paix?o Kr?hling wrote: >> On 26.02.2016 12:46, Thomas Segismont wrote: >>> Sorry, it seems I was rather unclear. The Metrics team *will* release >>> Metrics 0.13. I was talking about the commit needed in Hawkular master >>> branch to update the Metrics version property. >> Oh, that. I'll take care of it, don't worry :) >> >> - Juca. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Thu Mar 10 07:16:22 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 10 Mar 2016 13:16:22 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 Message-ID: <56E16596.70005@redhat.com> Hi *, The new version 38 [1] brings just two minor changes: * upgrade to hawkular-build-tools 15 that now contans apidoc.groovy [3] script for generating REST API documentation from swagger by Pavol. * Move gmavenplus-plugin executions to a dedicated profile so that it is not active by default and the build can run faster for all projects which do not contain any Groovy code [4]. Projects that contain Groovy code will have to activate the plugin by adding true to their properties. Note that the previous Parent version 37 contained upgrades to Cassandra 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. I have a PR [5] ready that upgrades to Parent 38 and c* 3.3 in Commons. According to Juca, no major problems are expected in Accounts, while it is fully unclear if Titan will be ready to work with c* 3.3 in Inventory. Best, Peter [1] https://github.com/hawkular/hawkular-parent-pom/commits/38 [2] https://github.com/hawkular/hawkular-parent-pom/commits/37 [3] https://github.com/hawkular/hawkular-build-tools/commit/ec64970d15821d2d9c806424ebd759549ee777d6 [4] https://github.com/hawkular/hawkular-parent-pom/commit/72381084614a5dde95bf8f8a16409dd503c68413#diff-600376dffeb79835ede4a0b285078036R1157 [5] https://github.com/hawkular/hawkular-commons/pull/53 From hrupp at redhat.com Thu Mar 10 07:45:19 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 10 Mar 2016 13:45:19 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: <56E16596.70005@redhat.com> References: <56E16596.70005@redhat.com> Message-ID: On 10 Mar 2016, at 13:16, Peter Palaga wrote: > Note that the previous Parent version 37 contained upgrades to Cassandra > 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. Question - should we try to directly jump to 3.4, as it adds some secondary indexes for text search (iirc) something we may want to have sooner and later and we would skip one (schema) update cycle that way? But of course John Sanda needs to tell if that jump is feasible at all. Heiko From ppalaga at redhat.com Thu Mar 10 08:47:54 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 10 Mar 2016 14:47:54 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: References: <56E16596.70005@redhat.com> Message-ID: <56E17B0A.5040500@redhat.com> Hi Heiko, inline... On 2016-03-10 13:45, Heiko W.Rupp wrote: > On 10 Mar 2016, at 13:16, Peter Palaga wrote: > >> Note that the previous Parent version 37 contained upgrades to Cassandra >> 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. > > Question - should we try to directly jump to 3.4 I wanted to wait for jsanda with that question. -- P > , as it adds some > secondary indexes for text search (iirc) something we may want > to have sooner and later and we would skip one (schema) update > cycle that way? > > But of course John Sanda needs to tell if that jump is feasible at all. > > Heiko > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From miburman at redhat.com Thu Mar 10 09:01:09 2016 From: miburman at redhat.com (Michael Burman) Date: Thu, 10 Mar 2016 09:01:09 -0500 (EST) Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: References: <56E16596.70005@redhat.com> Message-ID: <628399710.52980068.1457618469102.JavaMail.zimbra@redhat.com> Hi, Yes, we should jump directly to 3.4 after waiting for a moment to see if the release is viable (Cassandra project has released a couple of DOA releases in the past). The SASI indexes are something we have use for in the query-language department. - Micke ----- Original Message ----- From: "Heiko W.Rupp" To: "Discussions around Hawkular development" Sent: Thursday, March 10, 2016 2:45:19 PM Subject: Re: [Hawkular-dev] Hawkular Parent 38 On 10 Mar 2016, at 13:16, Peter Palaga wrote: > Note that the previous Parent version 37 contained upgrades to Cassandra > 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. Question - should we try to directly jump to 3.4, as it adds some secondary indexes for text search (iirc) something we may want to have sooner and later and we would skip one (schema) update cycle that way? But of course John Sanda needs to tell if that jump is feasible at all. Heiko _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From ploffay at redhat.com Thu Mar 10 09:01:09 2016 From: ploffay at redhat.com (Pavol Loffay) Date: Thu, 10 Mar 2016 15:01:09 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: <56E17B0A.5040500@redhat.com> References: <56E16596.70005@redhat.com> <56E17B0A.5040500@redhat.com> Message-ID: Hi, *That apidoc.groovy is originally from Metrics and reused in Inventory and Datamining. I will submit PR to use it directly from build-tools. Pavol On Thu, Mar 10, 2016 at 2:47 PM, Peter Palaga wrote: > Hi Heiko, inline... > > On 2016-03-10 13:45, Heiko W.Rupp wrote: > > On 10 Mar 2016, at 13:16, Peter Palaga wrote: > > > >> Note that the previous Parent version 37 contained upgrades to Cassandra > >> 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. > > > > Question - should we try to directly jump to 3.4 > > I wanted to wait for jsanda with that question. -- P > > > , as it adds some > > secondary indexes for text search (iirc) something we may want > > to have sooner and later and we would skip one (schema) update > > cycle that way? > > > > But of course John Sanda needs to tell if that jump is feasible at all. > > > > Heiko > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160310/a6b30396/attachment-0001.html From tsegismo at redhat.com Thu Mar 10 09:10:26 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 10 Mar 2016 15:10:26 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: References: <56E16596.70005@redhat.com> <56E17B0A.5040500@redhat.com> Message-ID: <56E18052.4070206@redhat.com> Le 10/03/2016 15:01, Pavol Loffay a ?crit : > Hi, > > *That apidoc.groovy is originally from Metrics and reused in Inventory Thanks Pavol ;-) > and Datamining. > I will submit PR to use it directly from build-tools. > It is great to share it. Can you please make sure that the mechanism used to inject a static Asciidoc header still works after your changes? > > Pavol > > On Thu, Mar 10, 2016 at 2:47 PM, Peter Palaga > wrote: > > Hi Heiko, inline... > > On 2016-03-10 13:45, Heiko W.Rupp wrote: > > On 10 Mar 2016, at 13:16, Peter Palaga wrote: > > > >> Note that the previous Parent version 37 contained upgrades to Cassandra > >> 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 yet. > > > > Question - should we try to directly jump to 3.4 > > I wanted to wait for jsanda with that question. -- P > > > , as it adds some > > secondary indexes for text search (iirc) something we may want > > to have sooner and later and we would skip one (schema) update > > cycle that way? > > > > But of course John Sanda needs to tell if that jump is feasible > at all. > > > > Heiko > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ploffay at redhat.com Thu Mar 10 09:18:06 2016 From: ploffay at redhat.com (Pavol Loffay) Date: Thu, 10 Mar 2016 15:18:06 +0100 Subject: [Hawkular-dev] Hawkular Parent 38 In-Reply-To: <56E18052.4070206@redhat.com> References: <56E16596.70005@redhat.com> <56E17B0A.5040500@redhat.com> <56E18052.4070206@redhat.com> Message-ID: On Thu, Mar 10, 2016 at 3:10 PM, Thomas Segismont wrote: > Le 10/03/2016 15:01, Pavol Loffay a ?crit : > > Hi, > > > > *That apidoc.groovy is originally from Metrics and reused in Inventory > > Thanks Pavol ;-) > > > and Datamining. > > I will submit PR to use it directly from build-tools. > > > > It is great to share it. Can you please make sure that the mechanism > used to inject a static Asciidoc header still works after your changes? > > Yes, I will check it. > > > > Pavol > > > > On Thu, Mar 10, 2016 at 2:47 PM, Peter Palaga > > wrote: > > > > Hi Heiko, inline... > > > > On 2016-03-10 13:45, Heiko W.Rupp wrote: > > > On 10 Mar 2016, at 13:16, Peter Palaga wrote: > > > > > >> Note that the previous Parent version 37 contained upgrades to > Cassandra > > >> 3.3 and Driver 3.0.0. It looks like no component upgraded to v37 > yet. > > > > > > Question - should we try to directly jump to 3.4 > > > > I wanted to wait for jsanda with that question. -- P > > > > > , as it adds some > > > secondary indexes for text search (iirc) something we may want > > > to have sooner and later and we would skip one (schema) update > > > cycle that way? > > > > > > But of course John Sanda needs to tell if that jump is feasible > > at all. > > > > > > Heiko > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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/20160310/457b8f34/attachment.html From hrupp at redhat.com Fri Mar 11 11:55:58 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 11 Mar 2016 17:55:58 +0100 Subject: [Hawkular-dev] [Metrics] How to react on low disk? Message-ID: Hey, so for Hawkular-metrics (and Hawkular) we store the data in a Cassandra database that puts files on a disk, which can get full earlier than expected (and usually on week-ends). And when the disk is full, Metrics does not like it. What can we do in this case? I could imagine that on the C* nodes we run a script that uses df to figure out the available space and tries to run some compaction if space gets tight. Of course that does not solve the issue per se, but should give some air to breathe. Right now I fear we are not able to reduce the ttl of a metric/tenant on the fly and have metrics do the right thing - at least if I understood yak correctly. That script should possibly also send an email to an admin. In case that we run Hawkular-full, we can determine the disk space and feed that into Hawkular for Alerts to pick it up and then have the machinery trigger the compaction and send the email. From anton.okolnychyi at gmail.com Sat Mar 12 17:52:14 2016 From: anton.okolnychyi at gmail.com (Anton Okolnychyi) Date: Sun, 13 Mar 2016 00:52:14 +0200 Subject: [Hawkular-dev] [GSOC 2016], "Hawkular-agent for vert.x" Message-ID: Hi, all! My name is Anton Okolnychyi. I am keen on participating in GSOC 2016. That's why I am trying to gather relevant information to write a nice proposal for a "Hawkular-agent for vert.x" project on GSoC 2016. Thanks to Thomas Segismont for his initial advice. I have analyzed the existing functionality of the vertx-hawkular-metrics module, its current features, and architecture. In addition, I have investigated Hawkular's REST APIs of Metrics and Inventory services. Currently, the vertx-hawkular-metrics module reports only to the Metrics service. The idea that is available in the scope of GSOC 2016 is to enhance vertx-hawkular-metrics' capabilities. In particular, enable reporting to the Inventory service of Hawkular. As a result of my research, I have some questions. It would be great if someone can answer them. 1. Since the main goal of the project is to actually enable reporting to the Inventory service, one should come up with an appropriate graph architecture of Inventory which should contain resources(vertices), relationships between them(edges) and optionally assigned metrics to each resource (I am aware of many to many relationships here). The vertx-hawkular-metrics module currently has metrics that cover the following: datagram/udp, event bus, tcp, http client, http server. That's why one can define the corresponding resources for these metrics in the Inventory (e.g. Event Bus, Net Client, HTTP Client, Datagram socket, HTTP Server, Net Server etc.). Will that make sense? Am I going in the right direction? Alternatively, we can define a resource that will cover several metrics at once. If you have anything that is important to include as a resource in the Inventory, please, share that with me. 2. The vertx-hawkular-metrics module collects only counters and gauges and reports them via the POST request to /metrics/data (correct me if I am wrong). Would it make sense/be interesting to also handle some availability metrics? The Hawkular API allows to do that and the current architecture of the vertx-hawkular-metrics is flexible enough to integrate a new metric type quite easily. Probably, this question should be asked on the vertx-dev list. But if someone knows the answer or has any possible applications/suggestions in mind I would be glad to hear. Thanks in advance! Any help is highly appreciated! Sincerely, Anton Okolnychyi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160313/54dc86fb/attachment.html From auszon3 at gmail.com Sun Mar 13 01:08:25 2016 From: auszon3 at gmail.com (Austin Kuo) Date: Sun, 13 Mar 2016 06:08:25 +0000 Subject: [Hawkular-dev] Questions about Inventory in agent Message-ID: Hi, all. This is Austin. I've been trying to understand how the inventory in agent works. As far as I understand, an inventory is a graph, and the agent sends the graph to the hawkular server with some kind of format. Such that the hawkular server can answer queries with the data that the agent sends. I have a few of questions: 1. What are the various protocols for(dmr, jmx, platform)? 2. And there's Resource and ResourceType, each of them holds a graph, what's the relation between them? Are they isomorphic and each node of ResouceType annotates the corresponding Resource node? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160313/38aa09f9/attachment.html From hrupp at redhat.com Sun Mar 13 05:56:08 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Sun, 13 Mar 2016 10:56:08 +0100 Subject: [Hawkular-dev] Criteria for a trigger to show in alert center? Message-ID: <50807E57-B889-46D7-B03F-42196A11EDF5@redhat.com> Hey, so I've created a trigger via the rest-api, that is also correctly firing. But I don't see it in the alert center. What are the criteria for a trigger to show up there? Is that currently limited to resources of type wildfly and its children? From hrupp at redhat.com Sun Mar 13 08:43:55 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Sun, 13 Mar 2016 13:43:55 +0100 Subject: [Hawkular-dev] Questions about Inventory in agent In-Reply-To: References: Message-ID: <4517D4A8-8507-440C-9464-97E55BB13761@redhat.com> Hey, > 1. What are the various protocols for(dmr, jmx, platform)? That is mostly on how to obtain the data. Dmr is some Wildlfy-internal protocol, that is detyped and can be accessed from external with some sort of rest-api. Jmx are the java management extensions and can be used to talk to remote java vms and obtain management information from there. > 2. And there's Resource and ResourceType, each of them holds a graph, > what's the relation between them? Are they isomorphic and each node of > ResouceType annotates the corresponding Resource node? No. It is rather the relation of class (=ResourceType) and its instantiated object (=Resource). Check e.g. the Datasources where you have one ResourceType "DataSource" and multiple datasources of this type like HawkularDS and KeycloakDS From lponce at redhat.com Sun Mar 13 18:19:16 2016 From: lponce at redhat.com (Lucas Ponce) Date: Sun, 13 Mar 2016 18:19:16 -0400 (EDT) Subject: [Hawkular-dev] Checkstyle rules In-Reply-To: <1005525721.8909737.1457907410879.JavaMail.zimbra@redhat.com> Message-ID: <2090711197.8910413.1457907556416.JavaMail.zimbra@redhat.com> Hello, If new checkstyle rules are introduced like this: Using the '.*' form of import should be avoided - org.hawkular.alerts.actions.api.*. I am not to enter in a discussion if this is valid or not, but please, then also modify the IDEs helpers or document the change in the settings of the two main IDEs used in the project. Some IDEs by default uses the .* import when there is a number of imports. A documentation in the settings will save time. Thanks, Lucas From ppalaga at redhat.com Mon Mar 14 05:57:51 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 14 Mar 2016 10:57:51 +0100 Subject: [Hawkular-dev] Checkstyle rules In-Reply-To: <2090711197.8910413.1457907556416.JavaMail.zimbra@redhat.com> References: <2090711197.8910413.1457907556416.JavaMail.zimbra@redhat.com> Message-ID: <56E68B1F.60902@redhat.com> Hi Lucas, I am not aware of any recent change in this area. Indeed, looking into the history of the checkstyle.xml file shows that the rule is there since the very beginning on Oct 27, 2014: https://github.com/hawkular/hawkular-build-tools/blame/master/build-tools/src/main/resources/hawkular-checkstyle/checkstyle.xml#L44 So there is a mismatch between checkstyle and IJ config, right? Would somebody please fix it? Thanks, Peter On 2016-03-13 23:19, Lucas Ponce wrote: > Hello, > > If new checkstyle rules are introduced like this: > > Using the '.*' form of import should be avoided - org.hawkular.alerts.actions.api.*. > > I am not to enter in a discussion if this is valid or not, but please, then also modify the IDEs helpers or document the change in the settings of the two main IDEs used in the project. > > Some IDEs by default uses the .* import when there is a number of imports. > > A documentation in the settings will save time. > > Thanks, > Lucas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Mon Mar 14 06:01:19 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 14 Mar 2016 11:01:19 +0100 Subject: [Hawkular-dev] Questions about Inventory in agent In-Reply-To: <4517D4A8-8507-440C-9464-97E55BB13761@redhat.com> References: <4517D4A8-8507-440C-9464-97E55BB13761@redhat.com> Message-ID: <56E68BEF.3080409@redhat.com> Hi Austin, On 2016-03-13 13:43, Heiko W.Rupp wrote: > Hey, > >> 1. What are the various protocols for(dmr, jmx, platform)? > > That is mostly on how to obtain the data. Dmr is some > Wildlfy-internal protocol, that is detyped and can be > accessed from external with some sort of rest-api. > Jmx are the java management extensions and can be > used to talk to remote java vms and obtain management > information from there. Yes, the various protocols are ways how the Agent is able to both discover resources and also collect metrics about them. -- Peter >> 2. And there's Resource and ResourceType, each of them holds a graph, >> what's the relation between them? Are they isomorphic and each node of >> ResouceType annotates the corresponding Resource node? > > No. It is rather the relation of class (=ResourceType) and > its instantiated object (=Resource). Check e.g. the Datasources > where you have one ResourceType "DataSource" and multiple > datasources of this type like HawkularDS and KeycloakDS > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From auszon3 at gmail.com Mon Mar 14 06:35:59 2016 From: auszon3 at gmail.com (Austin Kuo) Date: Mon, 14 Mar 2016 10:35:59 +0000 Subject: [Hawkular-dev] Questions about Inventory in agent In-Reply-To: <56E68BEF.3080409@redhat.com> References: <4517D4A8-8507-440C-9464-97E55BB13761@redhat.com> <56E68BEF.3080409@redhat.com> Message-ID: Many thanks to Heiko for giving such a clear example of classes and objects and Peter for elaboration. :) On Mon, Mar 14, 2016 at 6:01 PM Peter Palaga wrote: > Hi Austin, > > On 2016-03-13 13:43, Heiko W.Rupp wrote: > > Hey, > > > >> 1. What are the various protocols for(dmr, jmx, platform)? > > > > That is mostly on how to obtain the data. Dmr is some > > Wildlfy-internal protocol, that is detyped and can be > > accessed from external with some sort of rest-api. > > Jmx are the java management extensions and can be > > used to talk to remote java vms and obtain management > > information from there. > > Yes, the various protocols are ways how the Agent is able to both > discover resources and also collect metrics about them. > > -- Peter > > >> 2. And there's Resource and ResourceType, each of them holds a > graph, > >> what's the relation between them? Are they isomorphic and each node > of > >> ResouceType annotates the corresponding Resource node? > > > > No. It is rather the relation of class (=ResourceType) and > > its instantiated object (=Resource). Check e.g. the Datasources > > where you have one ResourceType "DataSource" and multiple > > datasources of this type like HawkularDS and KeycloakDS > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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/20160314/8dcc004f/attachment.html From lkrejci at redhat.com Mon Mar 14 06:42:13 2016 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 14 Mar 2016 11:42:13 +0100 Subject: [Hawkular-dev] Questions about Inventory in agent In-Reply-To: References: <4517D4A8-8507-440C-9464-97E55BB13761@redhat.com> <56E68BEF.3080409@redhat.com> Message-ID: <56E69585.1010301@redhat.com> In case you haven't found it already, hawkular.org contains a little bit of documentation on various types of entities inventory understands and how they are organized: http://www.hawkular.org/docs/components/inventory/index.html On 03/14/2016 11:35 AM, Austin Kuo wrote: > Many thanks to Heiko for giving such a clear example of classes and objects > and Peter for elaboration. :) > > On Mon, Mar 14, 2016 at 6:01 PM Peter Palaga wrote: > >> Hi Austin, >> >> On 2016-03-13 13:43, Heiko W.Rupp wrote: >>> Hey, >>> >>>> 1. What are the various protocols for(dmr, jmx, platform)? >>> >>> That is mostly on how to obtain the data. Dmr is some >>> Wildlfy-internal protocol, that is detyped and can be >>> accessed from external with some sort of rest-api. >>> Jmx are the java management extensions and can be >>> used to talk to remote java vms and obtain management >>> information from there. >> >> Yes, the various protocols are ways how the Agent is able to both >> discover resources and also collect metrics about them. >> >> -- Peter >> >>>> 2. And there's Resource and ResourceType, each of them holds a >> graph, >>>> what's the relation between them? Are they isomorphic and each node >> of >>>> ResouceType annotates the corresponding Resource node? >>> >>> No. It is rather the relation of class (=ResourceType) and >>> its instantiated object (=Resource). Check e.g. the Datasources >>> where you have one ResourceType "DataSource" and multiple >>> datasources of this type like HawkularDS and KeycloakDS >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Lukas Krejci From jshaughn at redhat.com Mon Mar 14 10:30:49 2016 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 14 Mar 2016 10:30:49 -0400 Subject: [Hawkular-dev] Criteria for a trigger to show in alert center? In-Reply-To: <50807E57-B889-46D7-B03F-42196A11EDF5@redhat.com> References: <50807E57-B889-46D7-B03F-42196A11EDF5@redhat.com> Message-ID: <56E6CB19.5000109@redhat.com> Hi Heiko, There are more than a few "hooks" required to have an alert show up up in the alert center. The AC is not completely generic, suffice it to say that the UI "knows" about all of the current alert types. To display alerts not intimately tied to a resource we should likely discuss. Perhaps we could have a short meeting and then post results here. I think it would be helpful to look at some code. On 3/13/2016 5:56 AM, Heiko W.Rupp wrote: > Hey, > > so I've created a trigger via the rest-api, that is also > correctly firing. But I don't see it in the alert center. > What are the criteria for a trigger to show up there? > Is that currently limited to resources of type wildfly > and its children? > _______________________________________________ > 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/20160314/88abe12e/attachment.html From hrupp at redhat.com Mon Mar 14 11:17:29 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 14 Mar 2016 16:17:29 +0100 Subject: [Hawkular-dev] Criteria for a trigger to show in alert center? In-Reply-To: <56E6CB19.5000109@redhat.com> References: <50807E57-B889-46D7-B03F-42196A11EDF5@redhat.com> <56E6CB19.5000109@redhat.com> Message-ID: <5B4F14E5-7F47-43AA-9B92-5A0A7138F251@redhat.com> On 14 Mar 2016, at 15:30, Jay Shaughnessy wrote: > alert show up up in the alert center. The AC is not completely > generic, suffice it to say that the UI "knows" about all of the > current alert types. To display alerts Ah ok. > not intimately tied to a resource we should likely discuss. Perhaps > we could have a short meeting and then The alerts themselves are luckily shown in the overview :) > post results here. I think it would be helpful to look at some code. It is probably not too urgent. I though if I need to e.g. supply additional data to the resource type or trigger definition when setting up the triggers in the first place. Thanks Heiko From jshaughn at redhat.com Mon Mar 14 13:24:02 2016 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 14 Mar 2016 13:24:02 -0400 Subject: [Hawkular-dev] Criteria for a trigger to show in alert center? In-Reply-To: <5B4F14E5-7F47-43AA-9B92-5A0A7138F251@redhat.com> References: <50807E57-B889-46D7-B03F-42196A11EDF5@redhat.com> <56E6CB19.5000109@redhat.com> <5B4F14E5-7F47-43AA-9B92-5A0A7138F251@redhat.com> Message-ID: <56E6F3B2.9040403@redhat.com> Heiko, if you look at the context and tags oin place for the current triggers perhaps you can get the behavior you want. ping me if you want to pursue. On 3/14/2016 11:17 AM, Heiko W.Rupp wrote: > On 14 Mar 2016, at 15:30, Jay Shaughnessy wrote: >> alert show up up in the alert center. The AC is not completely >> generic, suffice it to say that the UI "knows" about all of the >> current alert types. To display alerts > Ah ok. > >> not intimately tied to a resource we should likely discuss. Perhaps >> we could have a short meeting and then > The alerts themselves are luckily shown in the overview :) > >> post results here. I think it would be helpful to look at some code. > It is probably not too urgent. I though if I need to e.g. > supply additional data to the resource type or > trigger definition when setting up the triggers in the > first place. > > Thanks > Heiko > _______________________________________________ > 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/20160314/35dc83ff/attachment.html From snegrea at redhat.com Tue Mar 15 16:00:12 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 15 Mar 2016 16:00:12 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <1638502579.39546104.1458068819083.JavaMail.zimbra@redhat.com> Message-ID: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> Hello Everybody, Hawkular Metrics contributors have been working for the past few weeks on a roadmap for the upcoming year. The goal is to give clarity on the project direction, serve as a planning tool for releases, and show our strong commitment to open source. The project and community are enjoying excellent growth. A maturing code base, an ever growing set of integrations, and consistent community contributions are ingredients that make this project successful and also an indication of the future. For those not familiar with Hawkular Metrics, the project is a high performance and high availability storage engine for large volume metric data. The project uses Cassandra as a storage engine because of its flexible data model well suited for time-series data storage and linear scalability with no single point of failure. Here is the roadmap: 1) Cassandra 3.x * The 3.x release of Cassandra is maturing, making the perfect timing for the project to transition from current 2.2.x line * Expect this transition to happen rather soon since work is already in progress (driver updates, and a schema management tool) 2) Pre-computed aggregates * Needed to support long term data storage and retrieval for high volume metrics * Single metrics roll-ups are also the foundation for pre-computed multi-metric aggregations, that goal is to work on this subsequent to single metric roll-ups 3) Metric Enhancements * Histogram metrics are fairly common in other time series databases. The plan is to add histogram metrics as a sub-metric to existing gauge metrics, analogous to what counter-rate metrics are counter metrics. It is common to do the calculations need for the histogram on the client side, but there are a lot of advantages to push the calculations to the server. * Add support for metrics baselines; automatically computed server-side and stored * Implement an Apdex score, similar purpose to baselines, but based on the open standard 4) Native Grafana integration * Grafana integration is important for Hawkular Metrics due to lack of a dedicated UI. Currently Grafana integration works through an InfluxDB compatibility layer that has obvious disadvantages (maintaining compatibility with InfluxDB, limited set of features based on the InfluxDB capability). * A native Grafana provider will be easier to maintain and expose the full feature set of Hawkular Metrics 5) Developer Support * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Casasndra cluster just to test or write integration code 6) Import & Export Data APIs * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). 7) ElasticSearch integration * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. Thank you, Stefan Negrea Software Engineer From hrupp at redhat.com Wed Mar 16 04:03:16 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 16 Mar 2016 09:03:16 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> Message-ID: <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> Hey Stefan, On 15 Mar 2016, at 21:00, Stefan Negrea wrote: > * Add support for metrics baselines; automatically computed > server-side and stored How? What is the algorithm behind? Please remember that the algorithm from RHQ is/was flawed. > 7) ElasticSearch integration > * An optional integration with Elastic Search for tasks beyond the > capability of Cassandra. > * Basic examples for this are whole tenant searches and aggregation > of text based data, such as tags, events, and even availability. How do we deal with the data nodes of ES? Where do the events of "aggregation of events" come from and are stored? What does "whole tenant searches" mean? -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht M?nchen HRB 153243 Gesch?ftsf?hrer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From ppalaga at redhat.com Wed Mar 16 05:36:33 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 16 Mar 2016 10:36:33 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> Message-ID: <56E92921.3080506@redhat.com> Hi Stefan, > 5) Developer Support > * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort > * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Cassandra cluster just to test or write integration code Does this mean that this distro will contain the Embedded Cassandra from Hawkular Commons? Has anybody already thought of which auth variant will be present there in the distro? (a) Accounts (b) none? And actually an equivalent question is which metrics war will be used in the distro? - (a) hawkular-metrics-component.war or (b) hawkular-metric-rest.war? I volunteer to prepare the distro. Thanks, Peter > 6) Import & Export Data APIs > * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. > * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). > > 7) ElasticSearch integration > * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. > * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. > > > If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. > > > 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 tsegismo at redhat.com Wed Mar 16 05:51:33 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 16 Mar 2016 10:51:33 +0100 Subject: [Hawkular-dev] [GSOC 2016], "Hawkular-agent for vert.x" In-Reply-To: References: Message-ID: <56E92CA5.6030709@redhat.com> Hi Anton, You will find my answers inline. Le 12/03/2016 23:52, Anton Okolnychyi a ?crit : > Hi, all! > > My name is Anton Okolnychyi. I am keen on participating in GSOC 2016. > That's why I am; trying to gather relevant information to write a nice > proposal for a "Hawkular-agent for vert.x" project on GSoC 2016. > > Thanks to Thomas Segismont for his initial advice. I have analyzed the > existing functionality of the vertx-hawkular-metrics module, its current > features, and architecture. In addition, I have investigated Hawkular's > REST APIs of Metrics and Inventory services. Currently, the > vertx-hawkular-metrics module reports only to the Metrics service. The > idea that is available in the scope of GSOC 2016 is to enhance > vertx-hawkular-metrics' capabilities. In particular, enable reporting to > the Inventory service of Hawkular. Exactly. > > As a result of my research, I have some questions. It would be great if > someone can answer them. > > 1. Since the main goal of the project is to actually enable reporting to > the Inventory service, one should come up with an appropriate graph > architecture of Inventory which should contain resources(vertices), > relationships between them(edges) and optionally assigned metrics to > each resource (I am aware of many to many relationships here). The > vertx-hawkular-metrics module currently has metrics that cover the > following: datagram/udp, event bus, tcp, http client, http server. > That's why one can define the corresponding resources for these metrics > in the Inventory (e.g. Event Bus, Net Client, HTTP Client, Datagram > socket, HTTP Server, Net Server etc.). Will that make sense? Am I going > in the right direction? Alternatively, we can define a resource that > will cover several metrics at once. If you have anything that is > important to include as a resource in the Inventory, please, share that > with me. I believe your model is correct: Event bus resource has event bus metrics NetClient resource has NetClient metrics ... etc We might want to have event bus handlers as separate resources with their own metrics. > > 2. The vertx-hawkular-metrics module collects only counters and gauges > and reports them via the POST request to /metrics/data (correct me if I > am wrong). Would it make sense/be interesting to also handle some > availability metrics? The Hawkular API allows to do that and the current > architecture of the vertx-hawkular-metrics is flexible enough to > integrate a new metric type quite easily. Probably, this question should > be asked on the vertx-dev list. But if someone knows the answer or has > any possible applications/suggestions in mind I would be glad to hear. I can definitely answer that as I wrote the vertx-hawkular-metrics module :) It would make sense to add availability metrics as well, yes. I didn't include them in the current implementation because to me, they make sense when you report to inventory as well. Otherwise it is not clear what a resource is (and why it would be up/down/etc...). > > Thanks in advance! Any help is highly appreciated! Thank you for your interest! > > Sincerely, > Anton Okolnychyi > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Wed Mar 16 06:29:57 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 16 Mar 2016 11:29:57 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <56E92921.3080506@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> Message-ID: <56E935A5.2080603@redhat.com> Le 16/03/2016 10:36, Peter Palaga a ?crit : > Hi Stefan, > >> 5) Developer Support >> * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort >> * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Cassandra cluster just to test or write integration code > > Does this mean that this distro will contain the Embedded Cassandra from > Hawkular Commons? Yes > > Has anybody already thought of which auth variant will be present there > in the distro? (a) Accounts (b) none? Short answer: b Long answer: So far the default auth mechanism is none. I hope in the future we can get to a basic builtin auth support in Metrics. In any case, I believe a time series database should not come bundled with an IDM server. > And actually an equivalent question is which metrics war will be used in > the distro? - (a) hawkular-metrics-component.war or (b) > hawkular-metric-rest.war? Equivalent answer, b :) > > I volunteer to prepare the distro. Actually there's a PR ready https://github.com/hawkular/hawkular-metrics/pull/469 Feel free to submit any comment. > > Thanks, > > Peter > >> 6) Import & Export Data APIs >> * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. >> * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). >> >> 7) ElasticSearch integration >> * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. >> * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. >> >> >> If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. >> >> >> 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 tsegismo at redhat.com Wed Mar 16 06:52:43 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 16 Mar 2016 11:52:43 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> Message-ID: <56E93AFB.6040701@redhat.com> Le 15/03/2016 21:00, Stefan Negrea a ?crit : > Hello Everybody, > > Hawkular Metrics contributors have been working for the past few weeks on a roadmap for the upcoming year. The goal is to give clarity on the project direction, serve as a planning tool for releases, and show our strong commitment to open source. > > The project and community are enjoying excellent growth. A maturing code base, an ever growing set of integrations, and consistent community contributions are ingredients that make this project successful and also an indication of the future. > > For those not familiar with Hawkular Metrics, the project is a high performance and high availability storage engine for large volume metric data. The project uses Cassandra as a storage engine because of its flexible data model well suited for time-series data storage and linear scalability with no single point of failure. > > > Here is the roadmap: > > 1) Cassandra 3.x > * The 3.x release of Cassandra is maturing, making the perfect timing for the project to transition from current 2.2.x line > * Expect this transition to happen rather soon since work is already in progress (driver updates, and a schema management tool) > > 2) Pre-computed aggregates > * Needed to support long term data storage and retrieval for high volume metrics > * Single metrics roll-ups are also the foundation for pre-computed multi-metric aggregations, that goal is to work on this subsequent to single metric roll-ups > > 3) Metric Enhancements > * Histogram metrics are fairly common in other time series databases. The plan is to add histogram metrics as a sub-metric to existing gauge metrics, analogous to what counter-rate metrics are counter metrics. It is common to do the calculations need for the histogram on the client side, but there are a lot of advantages to push the calculations to the server. +1 > * Add support for metrics baselines; automatically computed server-side and stored > * Implement an Apdex score, similar purpose to baselines, but based on the open standard > > 4) Native Grafana integration > * Grafana integration is important for Hawkular Metrics due to lack of a dedicated UI. Currently Grafana integration works through an InfluxDB compatibility layer that has obvious disadvantages (maintaining compatibility with InfluxDB, limited set of features based on the InfluxDB capability). > * A native Grafana provider will be easier to maintain and expose the full feature set of Hawkular Metrics +1000 It is important because Grafana is a *widely* used tool and we must provide a first class experience when connecting Grafana to Hawkular Metrics. Lack of dedicated UI just reinforce this need. > > 5) Developer Support > * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort > * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Casasndra cluster just to test or write integration code > +1 > 6) Import & Export Data APIs > * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. > * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). > > 7) ElasticSearch integration > * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. > * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. > I'm reluctant to introduce a new dependency for the use cases listed above. Has the new support for text based index in C* 3.x been explored? Why isn't it enough? Also, the container already comes with Infinispan which also has text index support. > > If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. > > > 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 rishabh.makhija07 at gmail.com Wed Mar 16 09:01:39 2016 From: rishabh.makhija07 at gmail.com (Rishabh Makhija) Date: Wed, 16 Mar 2016 18:31:39 +0530 Subject: [Hawkular-dev] GSoC 2016 Message-ID: Hi, I am Rishabh Makhija, CSE undergrad student from Bharati Vidyapeeth's College of Engineering, India. I would like to work on Improving existing Hawkular-Android client. I have previous experience of working on Android as a core developer at ownCloud-android and wordPress-android (http://www.github.com/rishabh7m). Can someone help me with listing introductory bugs to work on? My project mentors are Heiko Rupp and Thomas Segismont but there is no contact information provided on the site. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160316/d9484ff7/attachment.html From jsanda at redhat.com Wed Mar 16 09:27:21 2016 From: jsanda at redhat.com (John Sanda) Date: Wed, 16 Mar 2016 09:27:21 -0400 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> Message-ID: > On Mar 16, 2016, at 4:03 AM, Heiko W.Rupp wrote: > > Hey Stefan, > > On 15 Mar 2016, at 21:00, Stefan Negrea wrote: > >> * Add support for metrics baselines; automatically computed >> server-side and stored > > How? What is the algorithm behind? Please remember that the > algorithm from RHQ is/was flawed. The algorithm was indeed flawed, but I think the feature could be a big one. For those not familiar, in RHQ we used averages. http://apmblog.dynatrace.com/2012/11/14/why-averages-suck-and-percentiles-are-great/ is a nice article that explains why using averages is not good. I think that adding support for a histogram metric type that is calculated on the server gets a lot of what we need. > >> 7) ElasticSearch integration >> * An optional integration with Elastic Search for tasks beyond the >> capability of Cassandra. >> * Basic examples for this are whole tenant searches and aggregation >> of text based data, such as tags, events, and even availability. > > How do we deal with the data nodes of ES? Where do > the events of "aggregation of events" come from and > are stored? > What does "whole tenant searches" mean? > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Paul Argiry, Charles Cachera, Michael Cunningham, > Michael O'Neill > _______________________________________________ > 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/20160316/d2c35111/attachment.html From jsanda at redhat.com Wed Mar 16 09:31:29 2016 From: jsanda at redhat.com (John Sanda) Date: Wed, 16 Mar 2016 09:31:29 -0400 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <56E93AFB.6040701@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E93AFB.6040701@redhat.com> Message-ID: <4C34888E-4513-45C9-A255-049945853CD3@redhat.com> > On Mar 16, 2016, at 6:52 AM, Thomas Segismont wrote: > > Le 15/03/2016 21:00, Stefan Negrea a ?crit : >> Hello Everybody, >> >> Hawkular Metrics contributors have been working for the past few weeks on a roadmap for the upcoming year. The goal is to give clarity on the project direction, serve as a planning tool for releases, and show our strong commitment to open source. >> >> The project and community are enjoying excellent growth. A maturing code base, an ever growing set of integrations, and consistent community contributions are ingredients that make this project successful and also an indication of the future. >> >> For those not familiar with Hawkular Metrics, the project is a high performance and high availability storage engine for large volume metric data. The project uses Cassandra as a storage engine because of its flexible data model well suited for time-series data storage and linear scalability with no single point of failure. >> >> >> Here is the roadmap: >> >> 1) Cassandra 3.x >> * The 3.x release of Cassandra is maturing, making the perfect timing for the project to transition from current 2.2.x line >> * Expect this transition to happen rather soon since work is already in progress (driver updates, and a schema management tool) >> >> 2) Pre-computed aggregates >> * Needed to support long term data storage and retrieval for high volume metrics >> * Single metrics roll-ups are also the foundation for pre-computed multi-metric aggregations, that goal is to work on this subsequent to single metric roll-ups >> >> 3) Metric Enhancements >> * Histogram metrics are fairly common in other time series databases. The plan is to add histogram metrics as a sub-metric to existing gauge metrics, analogous to what counter-rate metrics are counter metrics. It is common to do the calculations need for the histogram on the client side, but there are a lot of advantages to push the calculations to the server. > > +1 > >> * Add support for metrics baselines; automatically computed server-side and stored >> * Implement an Apdex score, similar purpose to baselines, but based on the open standard >> >> 4) Native Grafana integration >> * Grafana integration is important for Hawkular Metrics due to lack of a dedicated UI. Currently Grafana integration works through an InfluxDB compatibility layer that has obvious disadvantages (maintaining compatibility with InfluxDB, limited set of features based on the InfluxDB capability). >> * A native Grafana provider will be easier to maintain and expose the full feature set of Hawkular Metrics > > +1000 > > It is important because Grafana is a *widely* used tool and we must > provide a first class experience when connecting Grafana to Hawkular > Metrics. Lack of dedicated UI just reinforce this need. > >> >> 5) Developer Support >> * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort >> * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Casasndra cluster just to test or write integration code >> > > +1 > >> 6) Import & Export Data APIs >> * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. >> * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). >> >> 7) ElasticSearch integration >> * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. >> * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. >> > > I'm reluctant to introduce a new dependency for the use cases listed > above. Has the new support for text based index in C* 3.x been explored? > Why isn't it enough? Also, the container already comes with Infinispan > which also has text index support. > The key part is that it is optional. I think we already have some pretty nice tag filtering, but if we want a lot more search capabilities, then I think looking at integration with ES or similar tools makes sense. This would need to be a pluggable layer with our current impl being the default. > > >> >> If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. >> >> >> Thank you, >> Stefan Negrea >> >> Software Engineer >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160316/a8dc6784/attachment-0001.html From tsegismo at redhat.com Wed Mar 16 09:44:04 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 16 Mar 2016 14:44:04 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <4C34888E-4513-45C9-A255-049945853CD3@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E93AFB.6040701@redhat.com> <4C34888E-4513-45C9-A255-049945853CD3@redhat.com> Message-ID: <56E96324.9010501@redhat.com> Le 16/03/2016 14:31, John Sanda a ?crit : >>> >> >> I'm reluctant to introduce a new dependency for the use cases listed >> above. Has the new support for text based index in C* 3.x been explored? >> Why isn't it enough? Also, the container already comes with Infinispan >> which also has text index support. >> > > The key part is that it is optional. I think we already have some pretty > nice tag filtering, but if we want a lot more search capabilities, then > I think looking at integration with ES or similar tools makes sense. > This would need to be a pluggable layer with our current impl being the > default. I understood that it would be optional. I'm not convinced though that we couldn't offer these new capabilities with the tools the container and Cassandra already provide. That is why I would like to know if these solutions have been explored, and why it wouldn't work. From snegrea at redhat.com Wed Mar 16 12:42:03 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Wed, 16 Mar 2016 12:42:03 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> Message-ID: <865476305.39829578.1458146523965.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Heiko W.Rupp" > To: "Discussions around Hawkular development" > Sent: Wednesday, March 16, 2016 3:03:16 AM > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > > Hey Stefan, > > On 15 Mar 2016, at 21:00, Stefan Negrea wrote: > > > * Add support for metrics baselines; automatically computed > > server-side and stored > > How? What is the algorithm behind? Please remember that the > algorithm from RHQ is/was flawed. There is no preliminary design for this feature. Right now it is only on the roadmap and we will open the design discussions when we start implementing it. > > > 7) ElasticSearch integration > > * An optional integration with Elastic Search for tasks beyond the > > capability of Cassandra. > > * Basic examples for this are whole tenant searches and aggregation > > of text based data, such as tags, events, and even availability. > > How do we deal with the data nodes of ES? Where do > the events of "aggregation of events" come from and > are stored? > What does "whole tenant searches" mean? The "events" word was mistakenly included there. "Whole tenant searches" - all the relevant data for a tenant searchable in the context of that tenant, I listed tags and availability as examples. > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Paul Argiry, Charles Cachera, Michael Cunningham, > Michael O'Neill > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Wed Mar 16 12:47:48 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Wed, 16 Mar 2016 12:47:48 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <56E92921.3080506@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> Message-ID: <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Peter Palaga" > To: hawkular-dev at lists.jboss.org > Sent: Wednesday, March 16, 2016 4:36:33 AM > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > > Hi Stefan, > > > 5) Developer Support > > * Provide a Hawkular Metrics distribution with all components needed for > > third-party developers to get a developer environment running with > > minimal effort > > * An easy-to-use and all-inclusive distribution will avoid having > > platform developers configure Wildfly server and a Cassandra cluster > > just to test or write integration code > > Does this mean that this distro will contain the Embedded Cassandra from > Hawkular Commons? That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. > > Has anybody already thought of which auth variant will be present there > in the distro? (a) Accounts (b) none? The default Hawkular Metrics auth will be used; which means Accounts is not part of it. > And actually an equivalent question is which metrics war will be used in > the distro? - (a) hawkular-metrics-component.war or (b) > hawkular-metric-rest.war? > > I volunteer to prepare the distro. Thanks for the offer. John Sanda is already working on this. Please reach out to him to see how you can help. > > Thanks, > > Peter > > > 6) Import & Export Data APIs > > * The project already provides a growing set of APIs for querying metric > > data, but there are scenarios that require bulk data export into > > another system for further analysis. And vice-versa, import large > > amounts of data from another system for longer term storage and > > aggregation by Hawkular Metrics. > > * The goal is to provide APIs optimized for bulk importing or exporting > > data. Tools need to be both fast and easy to use, with the primary use > > case of moving a large amounts data well beyond the capability of > > current REST interface (eg. moving 100GB of data). > > > > 7) ElasticSearch integration > > * An optional integration with Elastic Search for tasks beyond the > > capability of Cassandra. > > * Basic examples for this are whole tenant searches and aggregation of > > text based data, such as tags, events, and even availability. > > > > > > If you have any other suggestion or would like to contribute to the > > project, please contact me; feedback is more than welcomed. > > > > > > 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 snegrea at redhat.com Wed Mar 16 12:58:29 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Wed, 16 Mar 2016 12:58:29 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <56E93AFB.6040701@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E93AFB.6040701@redhat.com> Message-ID: <2065578250.39832364.1458147509140.JavaMail.zimbra@redhat.com> > > 7) ElasticSearch integration > > * An optional integration with Elastic Search for tasks beyond the > > capability of Cassandra. > > * Basic examples for this are whole tenant searches and aggregation of > > text based data, such as tags, events, and even availability. > > > > I'm reluctant to introduce a new dependency for the use cases listed > above. Has the new support for text based index in C* 3.x been explored? > Why isn't it enough? Also, the container already comes with Infinispan > which also has text index support. > This will be an optional integration like it is mentioned; I would not want to add a strong/required dependency to ElasticSearch. But it is too early to known the exact details since we did not even start working on it. Also, the roadmap is more or less ordered in terms of priority/importance and this the last item. By the time we get to this we will get a much better idea of the feature set and will definitely explore a few avenues to implement it. From mithomps at redhat.com Wed Mar 16 13:57:49 2016 From: mithomps at redhat.com (mike thompson) Date: Wed, 16 Mar 2016 10:57:49 -0700 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> Message-ID: <9D6CDCE5-A03F-4748-B194-2C419D2E2704@redhat.com> I didn?t see any mention of streaming metrics. I know this is something that we had discussed. Since we already have observables in Metrics, opening up a web socket and streaming the metrics updates seems like a natural fit and capability that few solutions currently have to offer. Also, providing an Rx.js consumer on the hawkular charts side would allows to chart in real-time metrics with minimal bandwidth (especially with dashboards and NOCs) > On 15 Mar 2016, at 13:00, Stefan Negrea wrote: > > Hello Everybody, > > Hawkular Metrics contributors have been working for the past few weeks on a roadmap for the upcoming year. The goal is to give clarity on the project direction, serve as a planning tool for releases, and show our strong commitment to open source. > > The project and community are enjoying excellent growth. A maturing code base, an ever growing set of integrations, and consistent community contributions are ingredients that make this project successful and also an indication of the future. > > For those not familiar with Hawkular Metrics, the project is a high performance and high availability storage engine for large volume metric data. The project uses Cassandra as a storage engine because of its flexible data model well suited for time-series data storage and linear scalability with no single point of failure. > > > Here is the roadmap: > > 1) Cassandra 3.x > * The 3.x release of Cassandra is maturing, making the perfect timing for the project to transition from current 2.2.x line > * Expect this transition to happen rather soon since work is already in progress (driver updates, and a schema management tool) > > 2) Pre-computed aggregates > * Needed to support long term data storage and retrieval for high volume metrics > * Single metrics roll-ups are also the foundation for pre-computed multi-metric aggregations, that goal is to work on this subsequent to single metric roll-ups > > 3) Metric Enhancements > * Histogram metrics are fairly common in other time series databases. The plan is to add histogram metrics as a sub-metric to existing gauge metrics, analogous to what counter-rate metrics are counter metrics. It is common to do the calculations need for the histogram on the client side, but there are a lot of advantages to push the calculations to the server. > * Add support for metrics baselines; automatically computed server-side and stored > * Implement an Apdex score, similar purpose to baselines, but based on the open standard > > 4) Native Grafana integration > * Grafana integration is important for Hawkular Metrics due to lack of a dedicated UI. Currently Grafana integration works through an InfluxDB compatibility layer that has obvious disadvantages (maintaining compatibility with InfluxDB, limited set of features based on the InfluxDB capability). > * A native Grafana provider will be easier to maintain and expose the full feature set of Hawkular Metrics > > 5) Developer Support > * Provide a Hawkular Metrics distribution with all components needed for third-party developers to get a developer environment running with minimal effort > * An easy-to-use and all-inclusive distribution will avoid having platform developers configure Wildfly server and a Casasndra cluster just to test or write integration code > > 6) Import & Export Data APIs > * The project already provides a growing set of APIs for querying metric data, but there are scenarios that require bulk data export into another system for further analysis. And vice-versa, import large amounts of data from another system for longer term storage and aggregation by Hawkular Metrics. > * The goal is to provide APIs optimized for bulk importing or exporting data. Tools need to be both fast and easy to use, with the primary use case of moving a large amounts data well beyond the capability of current REST interface (eg. moving 100GB of data). > > 7) ElasticSearch integration > * An optional integration with Elastic Search for tasks beyond the capability of Cassandra. > * Basic examples for this are whole tenant searches and aggregation of text based data, such as tags, events, and even availability. > > > If you have any other suggestion or would like to contribute to the project, please contact me; feedback is more than welcomed. > > > 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 mfoley at redhat.com Wed Mar 16 14:56:22 2016 From: mfoley at redhat.com (Michael Foley) Date: Wed, 16 Mar 2016 14:56:22 -0400 (EDT) Subject: [Hawkular-dev] Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Message-ID: <244414997.41353399.1458154581436.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, March 16, 2016, 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/20160316/9c879bc9/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 7735 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160316/9c879bc9/attachment-0001.bin From hrupp at redhat.com Thu Mar 17 04:15:12 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 17 Mar 2016 09:15:12 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <2065578250.39832364.1458147509140.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E93AFB.6040701@redhat.com> <2065578250.39832364.1458147509140.JavaMail.zimbra@redhat.com> Message-ID: <92A4DACB-D32E-4105-92A5-5A6BFB5EE2BC@redhat.com> On 16 Mar 2016, at 17:58, Stefan Negrea wrote: > This will be an optional integration like it is mentioned; I would not > want to add a strong/required dependency to ElasticSearch. But it is > too early to known the exact details since we did not even start > working on Could you then (also for the roadmap post) Reword those (also the baselining) into "Investigate and potentially .." to indicate that "it is too early to known the exact details " ? From miburman at redhat.com Thu Mar 17 05:34:45 2016 From: miburman at redhat.com (Michael Burman) Date: Thu, 17 Mar 2016 05:34:45 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> Message-ID: <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> Hi, Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. - Micke ----- Original Message ----- From: "Stefan Negrea" To: "Discussions around Hawkular development" Sent: Wednesday, March 16, 2016 6:47:48 PM Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > Does this mean that this distro will contain the Embedded Cassandra from > Hawkular Commons? That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. From miburman at redhat.com Thu Mar 17 05:38:44 2016 From: miburman at redhat.com (Michael Burman) Date: Thu, 17 Mar 2016 05:38:44 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <9D6CDCE5-A03F-4748-B194-2C419D2E2704@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <9D6CDCE5-A03F-4748-B194-2C419D2E2704@redhat.com> Message-ID: <619251612.63801185.1458207524069.JavaMail.zimbra@redhat.com> Hi, +1 on this feature, we really should revisit the websocket API and make it work (for agent communication, for UI, etc). - Micke ----- Original Message ----- From: "mike thompson" To: "Discussions around Hawkular development" Sent: Wednesday, March 16, 2016 7:57:49 PM Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap I didn?t see any mention of streaming metrics. I know this is something that we had discussed. Since we already have observables in Metrics, opening up a web socket and streaming the metrics updates seems like a natural fit and capability that few solutions currently have to offer. Also, providing an Rx.js consumer on the hawkular charts side would allows to chart in real-time metrics with minimal bandwidth (especially with dashboards and NOCs) From tsegismo at redhat.com Thu Mar 17 05:44:30 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 17 Mar 2016 10:44:30 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> Message-ID: <56EA7C7E.3060705@redhat.com> Just to be sure we're on the same page, I believe here developer == user, who would like to try out Metrics in a development environment. While I agree providing him/her with a 'clean the mess' command would be best, I think this distro is a nice step forward. Le 17/03/2016 10:34, Michael Burman a ?crit : > Hi, > > Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. > > - Micke > > ----- Original Message ----- > From: "Stefan Negrea" > To: "Discussions around Hawkular development" > Sent: Wednesday, March 16, 2016 6:47:48 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > >> Does this mean that this distro will contain the Embedded Cassandra from >> Hawkular Commons? > > That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Thu Mar 17 07:07:00 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 17 Mar 2016 12:07:00 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <619251612.63801185.1458207524069.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <9D6CDCE5-A03F-4748-B194-2C419D2E2704@redhat.com> <619251612.63801185.1458207524069.JavaMail.zimbra@redhat.com> Message-ID: <56EA8FD4.4050405@redhat.com> I think adding *some* websocket support would be nice. Some meaning limited feature set for relevant use cases (like the one pointed out by Mike). Not the whole REST API duplication you're referring to. Plus a limited feature set can be implemented in a reasonable amount of time. That is quite important given that pre-computed aggregates/downsampling should get most of our bandwith IMO. Le 17/03/2016 10:38, Michael Burman a ?crit : > Hi, > > +1 on this feature, we really should revisit the websocket API and make it work (for agent communication, for UI, etc). > > - Micke > > ----- Original Message ----- > From: "mike thompson" > To: "Discussions around Hawkular development" > Sent: Wednesday, March 16, 2016 7:57:49 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > > > I didn?t see any mention of streaming metrics. I know this is something that we had discussed. Since we already have observables in Metrics, opening up a web socket and streaming the metrics updates seems like a natural fit and capability that few solutions currently have to offer. > Also, providing an Rx.js consumer on the hawkular charts side would allows to chart in real-time metrics with minimal bandwidth (especially with dashboards and NOCs) > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Thu Mar 17 08:08:44 2016 From: jsanda at redhat.com (John Sanda) Date: Thu, 17 Mar 2016 08:08:44 -0400 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> Message-ID: I think that this is a viable option for someone who just wants to explore Hawkular Metrics. It frees the person from the burden of having to worry about installing Cassandra. I agree that ccm is the best tool for development, but it can be a pain to install. I have started looking into home brew packaging since many ManageIQ devs are on Mac OS X and because they asked for it. There is already a home brew package for ccm as well. Here?s what I would like to do. Create a Hawkular Metrics package that depends on ccm. That distro of Hawkular Metrics can include endpoints for controlling/using ccm via the ccm bridge available with the DataStax driver. The first step though is a distro with embedded Cassandra so that people can more easily explore Hawkular Metrics with ManageIQ. > On Mar 17, 2016, at 5:34 AM, Michael Burman wrote: > > Hi, > > Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. > > - Micke > > ----- Original Message ----- > From: "Stefan Negrea" > To: "Discussions around Hawkular development" > Sent: Wednesday, March 16, 2016 6:47:48 PM > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > >> Does this mean that this distro will contain the Embedded Cassandra from >> Hawkular Commons? > > That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Thu Mar 17 10:15:31 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 17 Mar 2016 15:15:31 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> Message-ID: <56EABC03.4050107@redhat.com> +1 for a Python package in pip I had thought about this actually, and if I recall correctly the brew formula for ccm simply installs the Python package. We could do the same. Then we would have a nice way to quickly setup (and throw away) a test environment, not only on MacOS but on all platforms (recent versions of Python include pip, even on Windows). Le 17/03/2016 13:08, John Sanda a ?crit : > I think that this is a viable option for someone who just wants to explore Hawkular Metrics. It frees the person from the burden of having to worry about installing Cassandra. I agree that ccm is the best tool for development, but it can be a pain to install. I have started looking into home brew packaging since many ManageIQ devs are on Mac OS X and because they asked for it. There is already a home brew package for ccm as well. > > Here?s what I would like to do. Create a Hawkular Metrics package that depends on ccm. That distro of Hawkular Metrics can include endpoints for controlling/using ccm via the ccm bridge available with the DataStax driver. The first step though is a distro with embedded Cassandra so that people can more easily explore Hawkular Metrics with ManageIQ. > >> On Mar 17, 2016, at 5:34 AM, Michael Burman wrote: >> >> Hi, >> >> Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. >> >> - Micke >> >> ----- Original Message ----- >> From: "Stefan Negrea" >> To: "Discussions around Hawkular development" >> Sent: Wednesday, March 16, 2016 6:47:48 PM >> Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap >> >>> Does this mean that this distro will contain the Embedded Cassandra from >>> Hawkular Commons? >> >> That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Thu Mar 17 11:26:06 2016 From: jsanda at redhat.com (John Sanda) Date: Thu, 17 Mar 2016 11:26:06 -0400 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <56EABC03.4050107@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> <56EABC03.4050107@redhat.com> Message-ID: <978BCB02-3A48-4FC2-8237-9820A36F45C0@redhat.com> I am not working on a package in pip. I am focusing specifically on home brew because it was requested by ManageIQ. > On Mar 17, 2016, at 10:15 AM, Thomas Segismont wrote: > > +1 for a Python package in pip > > I had thought about this actually, and if I recall correctly the brew > formula for ccm simply installs the Python package. > > We could do the same. Then we would have a nice way to quickly setup > (and throw away) a test environment, not only on MacOS but on all > platforms (recent versions of Python include pip, even on Windows). > > > > Le 17/03/2016 13:08, John Sanda a ?crit : >> I think that this is a viable option for someone who just wants to explore Hawkular Metrics. It frees the person from the burden of having to worry about installing Cassandra. I agree that ccm is the best tool for development, but it can be a pain to install. I have started looking into home brew packaging since many ManageIQ devs are on Mac OS X and because they asked for it. There is already a home brew package for ccm as well. >> >> Here?s what I would like to do. Create a Hawkular Metrics package that depends on ccm. That distro of Hawkular Metrics can include endpoints for controlling/using ccm via the ccm bridge available with the DataStax driver. The first step though is a distro with embedded Cassandra so that people can more easily explore Hawkular Metrics with ManageIQ. >> >>> On Mar 17, 2016, at 5:34 AM, Michael Burman wrote: >>> >>> Hi, >>> >>> Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. >>> >>> - Micke >>> >>> ----- Original Message ----- >>> From: "Stefan Negrea" >>> To: "Discussions around Hawkular development" >>> Sent: Wednesday, March 16, 2016 6:47:48 PM >>> Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap >>> >>>> Does this mean that this distro will contain the Embedded Cassandra from >>>> Hawkular Commons? >>> >>> That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Thu Mar 17 11:42:00 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 17 Mar 2016 16:42:00 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <978BCB02-3A48-4FC2-8237-9820A36F45C0@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <56E92921.3080506@redhat.com> <145208236.39830578.1458146868414.JavaMail.zimbra@redhat.com> <1355898570.63800147.1458207285306.JavaMail.zimbra@redhat.com> <56EABC03.4050107@redhat.com> <978BCB02-3A48-4FC2-8237-9820A36F45C0@redhat.com> Message-ID: <56EAD048.2000707@redhat.com> Got you. But a pip package would make the tool useful to developers on all platforms, including (and not just) MacOS/homebrew users. Le 17/03/2016 16:26, John Sanda a ?crit : > I am not working on a package in pip. I am focusing specifically on home brew because it was requested by ManageIQ. > >> On Mar 17, 2016, at 10:15 AM, Thomas Segismont wrote: >> >> +1 for a Python package in pip >> >> I had thought about this actually, and if I recall correctly the brew >> formula for ccm simply installs the Python package. >> >> We could do the same. Then we would have a nice way to quickly setup >> (and throw away) a test environment, not only on MacOS but on all >> platforms (recent versions of Python include pip, even on Windows). >> >> >> >> Le 17/03/2016 13:08, John Sanda a ?crit : >>> I think that this is a viable option for someone who just wants to explore Hawkular Metrics. It frees the person from the burden of having to worry about installing Cassandra. I agree that ccm is the best tool for development, but it can be a pain to install. I have started looking into home brew packaging since many ManageIQ devs are on Mac OS X and because they asked for it. There is already a home brew package for ccm as well. >>> >>> Here?s what I would like to do. Create a Hawkular Metrics package that depends on ccm. That distro of Hawkular Metrics can include endpoints for controlling/using ccm via the ccm bridge available with the DataStax driver. The first step though is a distro with embedded Cassandra so that people can more easily explore Hawkular Metrics with ManageIQ. >>> >>>> On Mar 17, 2016, at 5:34 AM, Michael Burman wrote: >>>> >>>> Hi, >>>> >>>> Why is this is considered a good developer support version? We lack all the tools to make for example clean installation quickly (unlike say ccm clear && ccm start && ./standalone.sh), which is probably what many integration developers would need as they keep enhancing their data model (tags they use for searching, metricIds etc). This sort of package really needs tools like "reset-the-whole-thing". Reinstalling from zip isn't that. >>>> >>>> - Micke >>>> >>>> ----- Original Message ----- >>>> From: "Stefan Negrea" >>>> To: "Discussions around Hawkular development" >>>> Sent: Wednesday, March 16, 2016 6:47:48 PM >>>> Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap >>>> >>>>> Does this mean that this distro will contain the Embedded Cassandra from >>>>> Hawkular Commons? >>>> >>>> That is the goal, to bundle Embedded Cassandra + Metrics Web API + Wildfly 10 into a single deliverable. >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.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 anuj1708 at gmail.com Thu Mar 17 14:40:31 2016 From: anuj1708 at gmail.com (Anuj Garg) Date: Fri, 18 Mar 2016 00:10:31 +0530 Subject: [Hawkular-dev] Ambiguity in behaviour of token generated by token page in web UI Message-ID: I was working on fetching data for different personas. At that time I am facing that key/secret pair generated by /secret-store/v1/tokens/create is being able to respond according to Hawkular-Persona provided in the header. But One generated by "Create Token" on token page is not able to work that way. I have tried only on resources till yet though. http://pastebin.com/Rp9idM7s I am providing Persona of created org which should have returned empty list but proving the resource URLs which are present in first Persona. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160318/0452ddeb/attachment.html From ppalaga at redhat.com Fri Mar 18 07:41:52 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 18 Mar 2016 12:41:52 +0100 Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle Message-ID: <56EBE980.1010301@redhat.com> Hi *, I have sent the PR [1] to remove the Line length rule from checkstyle altogether. Based on the feedback collected through the dev survey, this seems to be the most annoying rule. I propose to keep the max line line length of 120 chars as an informal recommendation, that would also stay present in the IDE settings as we have them now. Does anybody want to veto? Thanks, Peter [1] https://github.com/hawkular/hawkular-build-tools/pull/24 From snegrea at redhat.com Fri Mar 18 10:26:24 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Fri, 18 Mar 2016 10:26:24 -0400 (EDT) Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle In-Reply-To: <56EBE980.1010301@redhat.com> References: <56EBE980.1010301@redhat.com> Message-ID: <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> Hello Everybody, Just had a brief chat with Peter. The main problem with that rule is not its application for actual code lines, I think almost everybody liked that. 99% of the frustration came from commented code not formatted to length by the IDEs. The classic example is having a line with 120 characters of Java code, the developer decides to test something by commenting out this line; the commenting takes 3 extra characters for a total of 123 characters. The IDE does not re-format to length and now there is a build error. >From my discussions with Peter there is no way to apply this rule selectively (eg. do not enforce line length for Java comments). So making the rule optional until that option is available (if it will ever be available) is the only way to remove the source collective of frustration. Peter, I second your proposal. Thank you! Stefan ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Friday, March 18, 2016 6:41:52 AM > Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle > > Hi *, > > I have sent the PR [1] to remove the Line length rule from checkstyle > altogether. Based on the feedback collected through the dev survey, this > seems to be the most annoying rule. > > I propose to keep the max line line length of 120 chars as an informal > recommendation, that would also stay present in the IDE settings as we > have them now. > > Does anybody want to veto? > > Thanks, > > Peter > > [1] https://github.com/hawkular/hawkular-build-tools/pull/24 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Fri Mar 18 10:48:26 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 18 Mar 2016 15:48:26 +0100 Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle In-Reply-To: <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> References: <56EBE980.1010301@redhat.com> <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> Message-ID: On 18 Mar 2016, at 15:26, Stefan Negrea wrote: > IDEs. The classic example is having a line with 120 characters of Java > code, the developer decides to test something by commenting out this > line; the commenting takes 3 extra characters for a total of 123 > characters. The IDE does not re-format to length and now there is a > build error. Exactly - that was my pain point over the year From tsegismo at redhat.com Fri Mar 18 10:52:52 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 18 Mar 2016 15:52:52 +0100 Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle In-Reply-To: References: <56EBE980.1010301@redhat.com> <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> Message-ID: <56EC1644.9080605@redhat.com> Le 18/03/2016 15:48, Heiko W.Rupp a ?crit : > On 18 Mar 2016, at 15:26, Stefan Negrea wrote: > >> IDEs. The classic example is having a line with 120 characters of Java >> code, the developer decides to test something by commenting out this >> line; the commenting takes 3 extra characters for a total of 123 >> characters. The IDE does not re-format to length and now there is a >> build error. > > Exactly - that was my pain point over the year Not sure about Eclipse but Intellij has an option to reformat comments From hrupp at redhat.com Fri Mar 18 12:10:58 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 18 Mar 2016 17:10:58 +0100 Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle In-Reply-To: <56EC1644.9080605@redhat.com> References: <56EBE980.1010301@redhat.com> <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> <56EC1644.9080605@redhat.com> Message-ID: <3A7D9A8E-1EF3-4F9F-BFBB-89DF60C6C98A@redhat.com> On 18 Mar 2016, at 15:52, Thomas Segismont wrote: > Le 18/03/2016 15:48, Heiko W.Rupp a ?crit : >> On 18 Mar 2016, at 15:26, Stefan Negrea wrote: >> >>> IDEs. The classic example is having a line with 120 characters of Java >>> code, the developer decides to test something by commenting out this >>> line; the commenting takes 3 extra characters for a total of 123 >>> characters. The IDE does not re-format to length and now there is a >>> build error. >> >> Exactly - that was my pain point over the year > > Not sure about Eclipse but Intellij has an option to reformat comments Which I don't want when just commenting out one bad line when trying things. This whole checkstyle / license / ... machinery is great for the moment just before the changes are going out your computer to co-workers. Before you should be able to roundtrip as fast as possible From tsegismo at redhat.com Fri Mar 18 12:37:57 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 18 Mar 2016 17:37:57 +0100 Subject: [Hawkular-dev] Line length rule to be removed from Checkstyle In-Reply-To: <3A7D9A8E-1EF3-4F9F-BFBB-89DF60C6C98A@redhat.com> References: <56EBE980.1010301@redhat.com> <1259444835.40403871.1458311184057.JavaMail.zimbra@redhat.com> <56EC1644.9080605@redhat.com> <3A7D9A8E-1EF3-4F9F-BFBB-89DF60C6C98A@redhat.com> Message-ID: <56EC2EE5.8080408@redhat.com> Le 18/03/2016 17:10, Heiko W.Rupp a ?crit : > On 18 Mar 2016, at 15:52, Thomas Segismont wrote: > >> Le 18/03/2016 15:48, Heiko W.Rupp a ?crit : >>> On 18 Mar 2016, at 15:26, Stefan Negrea wrote: >>> >>>> IDEs. The classic example is having a line with 120 characters of Java >>>> code, the developer decides to test something by commenting out this >>>> line; the commenting takes 3 extra characters for a total of 123 >>>> characters. The IDE does not re-format to length and now there is a >>>> build error. >>> >>> Exactly - that was my pain point over the year >> >> Not sure about Eclipse but Intellij has an option to reformat comments > > Which I don't want when just commenting out one bad line > when trying things. > > This whole checkstyle / license / ... machinery is great for the moment > just before the changes are going out your computer to co-workers. > Before you should be able to roundtrip as fast as possible Just wanted to share as it works well for me. The code snippet is reformatted but then I can open the diff revert this small part. From oneosmar89 at gmail.com Sat Mar 19 14:27:28 2016 From: oneosmar89 at gmail.com (Rodrigo Osmar Garcete) Date: Sat, 19 Mar 2016 15:27:28 -0300 Subject: [Hawkular-dev] Error when trying to connect to the server Hawcular Message-ID: Hi everyone I am interested in this idea: Improve Existing Hawkular-Android client. I have experience in Java and Android. I have already hawkular-android-client on my Android Studio, but not connect to the Web Admin. My client version is 1.0.0 Alpha3 and sever is 1.0.0 Alpha9. I am on a local network from my laptop and phone android. I try connect to the URL 192.168.0.106 with por 18080 from hawcular-android-client I get the following error in my console: 03-19 15:24:17.167 30343-31518/org.hawkular.client.android E/HttpRestProvider? Error on POST of http://192.168.0.106:18080/secret-store/v1/tokens/create java.net.ConnectException: failed to connect to /192.168.0.106 (port 18080): connect failed: ECONNREFUSED (Connection refused) at libcore.io.IoBridge.connect(IoBridge.java:114) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459) at java.net.Socket.connect(Socket.java:872) at libcore.net.http.HttpConnection.(HttpConnection.java:76) at libcore.net.http.HttpConnection.(HttpConnection.java:50) at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340) at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87) at libcore.net.http.HttpConnection.connect(HttpConnection.java:128) at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:315) at libcore.net.http.HttpEngine.connect(HttpEngine.java:310) at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:289) at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:239) at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:80) at libcore.net.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:188) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.addBodyRequest(HttpRestProvider.java:220) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:148) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:135) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:117) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:105) at android.os.AsyncTask$2.call(AsyncTask.java:287) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) at java.util.concurrent.FutureTask.run(FutureTask.java:137) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569) at java.lang.Thread.run(Thread.java:864) Caused by: libcore.io.ErrnoException: connect failed: ECONNREFUSED (Connection refused) at libcore.io.Posix.connect(Native Method) at libcore.io.BlockGuardOs.connect(BlockGuardOs.java:85) at libcore.io.IoBridge.connectErrno(IoBridge.java:127) at libcore.io.IoBridge.connect(IoBridge.java:112) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459) at java.net.Socket.connect(Socket.java:872) at libcore.net.http.HttpConnection.(HttpConnection.java:76) at libcore.net.http.HttpConnection.(HttpConnection.java:50) at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340) at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87) at libcore.net.http.HttpConnection.connect(HttpConnection.java:128) at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:315) at libcore.net.http.HttpEngine.connect(HttpEngine.java:310) at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:289) at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:239) at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:80) at libcore.net.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:188) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.addBodyRequest(HttpRestProvider.java:220) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:148) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:135) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:117) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:105) at android.os.AsyncTask$2.call(AsyncTask.java:287) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) at java.util.concurrent.FutureTask.run(FutureTask.java:137) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569) at java.lang.Thread.run(Thread.java:864) 03-19 15:24:17.167 30343-31518/org.hawkular.client.android D/SecretStoreAuthzModule? SecretStoreAuthzModule 03-19 15:24:17.187 30343-30343/org.hawkular.client.android D/LoginActivity? Authorization failed. java.lang.RuntimeException: java.net.ConnectException: failed to connect to /192.168.0.106 (port 18080): connect failed: ECONNREFUSED (Connection refused) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:153) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:135) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:117) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:105) at android.os.AsyncTask$2.call(AsyncTask.java:287) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) at java.util.concurrent.FutureTask.run(FutureTask.java:137) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569) at java.lang.Thread.run(Thread.java:864) Caused by: java.net.ConnectException: failed to connect to / 192.168.0.106 (port 18080): connect failed: ECONNREFUSED (Connection refused) at libcore.io.IoBridge.connect(IoBridge.java:114) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459) at java.net.Socket.connect(Socket.java:872) at libcore.net.http.HttpConnection.(HttpConnection.java:76) at libcore.net.http.HttpConnection.(HttpConnection.java:50) at libcore.net.http.HttpConnection$Address.connect(HttpConnection.java:340) at libcore.net.http.HttpConnectionPool.get(HttpConnectionPool.java:87) at libcore.net.http.HttpConnection.connect(HttpConnection.java:128) at libcore.net.http.HttpEngine.openSocketConnection(HttpEngine.java:315) at libcore.net.http.HttpEngine.connect(HttpEngine.java:310) at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:289) at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:239) at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:80) at libcore.net.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:188) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.addBodyRequest(HttpRestProvider.java:220) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:148) at org.jboss.aerogear.android.pipe.http.HttpRestProvider.post(HttpRestProvider.java:135) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:117) at org.hawkular.client.android.auth.SecretStoreAuthzModule$2.doInBackground(SecretStoreAuthzModule.java:105) at android.os.AsyncTask$2.call(AsyncTask.java:287) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) at java.util.concurrent.FutureTask.run(FutureTask.java:137) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569) at java.lang.Thread.run(Thread.java:864) Caused by: libcore.io.ErrnoException: connect failed: ECONNREFUSED (Connection refused) at libcore.io.Posix.connect(Native Method) at libcore.io.BlockGuardOs.connect(BlockGuardOs.java:85) at libcore.io.IoBridge.connectErrno(IoBridge.java:127) at libcore.io.IoBridge.connect(IoBridge.java:112) Someone can lend a hand with this Rodrigo Garcete -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160319/d91fb804/attachment-0001.html From jpkroehling at redhat.com Mon Mar 21 04:25:20 2016 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Mon, 21 Mar 2016 09:25:20 +0100 Subject: [Hawkular-dev] Ambiguity in behaviour of token generated by token page in web UI In-Reply-To: References: Message-ID: <56EFAFF0.7000103@redhat.com> I'm not sure I got what the problem is, but a token is always related to a persona, be it the real user, be it an organization. You can't set a Hawkular-Persona on a request with tokens, as the token itself stores the "Hawkular-Persona" used when the token was created (defaults to the actual user). So, if you want to have multiple personas on the android client, you have to have multiple tokens stored locally, one for each persona. - Juca. On 17.03.2016 19:40, Anuj Garg wrote: > I was working on fetching data for different personas. At that time I am > facing that key/secret pair generated by /secret-store/v1/tokens/create > is being able to respond according to Hawkular-Persona provided in the > header. > But One generated by "Create Token" on token page is not able to work > that way. I have tried only on resources till yet though. > http://pastebin.com/Rp9idM7s > I am providing Persona of created org which should have returned empty > list but proving the resource URLs which are present in first Persona. > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From anuj1708 at gmail.com Mon Mar 21 04:45:15 2016 From: anuj1708 at gmail.com (Anuj Garg) Date: Mon, 21 Mar 2016 14:15:15 +0530 Subject: [Hawkular-dev] Ambiguity in behaviour of token generated by token page in web UI In-Reply-To: <56EFAFF0.7000103@redhat.com> References: <56EFAFF0.7000103@redhat.com> Message-ID: Thanks But still the doubt remain is why token created with /secret-store/v1/tokens/create is allowing to do so. On 21 Mar 2016 1:55 pm, "Juraci Paix?o Kr?hling" wrote: > I'm not sure I got what the problem is, but a token is always related to > a persona, be it the real user, be it an organization. You can't set a > Hawkular-Persona on a request with tokens, as the token itself stores > the "Hawkular-Persona" used when the token was created (defaults to the > actual user). So, if you want to have multiple personas on the android > client, you have to have multiple tokens stored locally, one for each > persona. > > - Juca. > > On 17.03.2016 19:40, Anuj Garg wrote: > > I was working on fetching data for different personas. At that time I am > > facing that key/secret pair generated by /secret-store/v1/tokens/create > > is being able to respond according to Hawkular-Persona provided in the > > header. > > But One generated by "Create Token" on token page is not able to work > > that way. I have tried only on resources till yet though. > > http://pastebin.com/Rp9idM7s > > I am providing Persona of created org which should have returned empty > > list but proving the resource URLs which are present in first Persona. > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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/20160321/141d9fbb/attachment.html From jpkroehling at redhat.com Mon Mar 21 05:39:21 2016 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Mon, 21 Mar 2016 10:39:21 +0100 Subject: [Hawkular-dev] Ambiguity in behaviour of token generated by token page in web UI In-Reply-To: References: <56EFAFF0.7000103@redhat.com> Message-ID: <56EFC149.9040601@redhat.com> Probably a bug :) The UI call the REST endpoint, so, it should be possible to reproduce the issue only with REST calls. If you are able to reproduce it, let me know and I'll add a test/fix. - Juca. On 21.03.2016 09:45, Anuj Garg wrote: > Thanks > But still the doubt remain is why token created with > /secret-store/v1/tokens/create is allowing to do so. > > On 21 Mar 2016 1:55 pm, "Juraci Paix?o Kr?hling" > wrote: > > I'm not sure I got what the problem is, but a token is always related to > a persona, be it the real user, be it an organization. You can't set a > Hawkular-Persona on a request with tokens, as the token itself stores > the "Hawkular-Persona" used when the token was created (defaults to the > actual user). So, if you want to have multiple personas on the android > client, you have to have multiple tokens stored locally, one for each > persona. > > - Juca. > > On 17.03.2016 19:40, Anuj Garg wrote: > > I was working on fetching data for different personas. At that > time I am > > facing that key/secret pair generated by > /secret-store/v1/tokens/create > > is being able to respond according to Hawkular-Persona provided > in the > > header. > > But One generated by "Create Token" on token page is not able to work > > that way. I have tried only on resources till yet though. > > http://pastebin.com/Rp9idM7s > > I am providing Persona of created org which should have returned > empty > > list but proving the resource URLs which are present in first > Persona. > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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 ploffay at redhat.com Mon Mar 21 11:37:07 2016 From: ploffay at redhat.com (Pavol Loffay) Date: Mon, 21 Mar 2016 16:37:07 +0100 Subject: [Hawkular-dev] Hawkular Metrics - Roadmap In-Reply-To: <865476305.39829578.1458146523965.JavaMail.zimbra@redhat.com> References: <413049653.39563987.1458072012360.JavaMail.zimbra@redhat.com> <6421618E-8FC9-4164-9357-11705FB02B69@redhat.com> <865476305.39829578.1458146523965.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Mar 16, 2016 at 5:42 PM, Stefan Negrea wrote: > > > ----- Original Message ----- > > From: "Heiko W.Rupp" > > To: "Discussions around Hawkular development" < > hawkular-dev at lists.jboss.org> > > Sent: Wednesday, March 16, 2016 3:03:16 AM > > Subject: Re: [Hawkular-dev] Hawkular Metrics - Roadmap > > > > Hey Stefan, > > > > On 15 Mar 2016, at 21:00, Stefan Negrea wrote: > > > > > * Add support for metrics baselines; automatically computed > > > server-side and stored > > > > How? What is the algorithm behind? Please remember that the > > algorithm from RHQ is/was flawed. > > There is no preliminary design for this feature. Right now it is only on > the roadmap and we will open the design discussions when we start > implementing it. > Hey, could you please put me into discussion on this feature. I think I can contribute here. > > > > > 7) ElasticSearch integration > > > * An optional integration with Elastic Search for tasks beyond the > > > capability of Cassandra. > > > * Basic examples for this are whole tenant searches and aggregation > > > of text based data, such as tags, events, and even availability. > > > > How do we deal with the data nodes of ES? Where do > > the events of "aggregation of events" come from and > > are stored? > > What does "whole tenant searches" mean? > > The "events" word was mistakenly included there. "Whole tenant searches" - > all the relevant data for a tenant searchable in the context of that > tenant, I listed tags and availability as examples. > > > > > -- > > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > > Handelsregister: Amtsgericht M?nchen HRB 153243 > > Gesch?ftsf?hrer: Paul Argiry, Charles Cachera, Michael Cunningham, > > Michael O'Neill > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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/20160321/4e570e6c/attachment.html From mazz at redhat.com Mon Mar 21 17:40:23 2016 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 21 Mar 2016 17:40:23 -0400 (EDT) Subject: [Hawkular-dev] agent PR needs peer review In-Reply-To: <454672949.12735399.1458596238663.JavaMail.zimbra@redhat.com> Message-ID: <290071129.12739538.1458596423955.JavaMail.zimbra@redhat.com> PR: https://github.com/hawkular/hawkular-agent/pull/161 JIRA: https://issues.jboss.org/browse/HWKAGENT-63 When the agent starts up, if it doesn't know its tenant ID yet, it has to ask Hawkular-Accounts for it. But if the Hawkular Server isn't up yet, the agent will die during startup. This PR addresses that issue by having the agent perform some retries. This will give a bit more fault-tolerance to the agent should a hawkular server be down when the agent starts up. From ppalaga at redhat.com Tue Mar 22 05:09:46 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 22 Mar 2016 10:09:46 +0100 Subject: [Hawkular-dev] agent PR needs peer review In-Reply-To: <290071129.12739538.1458596423955.JavaMail.zimbra@redhat.com> References: <290071129.12739538.1458596423955.JavaMail.zimbra@redhat.com> Message-ID: <56F10BDA.3080807@redhat.com> Hi Mazz, I replied on the PR. -- P On 2016-03-21 22:40, John Mazzitelli wrote: > PR: https://github.com/hawkular/hawkular-agent/pull/161 > JIRA: https://issues.jboss.org/browse/HWKAGENT-63 > > When the agent starts up, if it doesn't know its tenant ID yet, it has to ask Hawkular-Accounts for it. But if the Hawkular Server isn't up yet, the agent will die during startup. This PR addresses that issue by having the agent perform some retries. This will give a bit more fault-tolerance to the agent should a hawkular server be down when the agent starts up. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mfoley at redhat.com Wed Mar 23 09:17:49 2016 From: mfoley at redhat.com (Michael Foley) Date: Wed, 23 Mar 2016 09:17:49 -0400 (EDT) Subject: [Hawkular-dev] Cancelled: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Message-ID: <1191916039.45190188.1458739068910.JavaMail.zimbra@redhat.com> You have been removed from the attendee list by the organizer. -----Original Invite----- 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: 3:00:00 PM - 3:30:00 PM GMT -05:00 US/Canada Eastern [MODIFIED] Recurrence : Every 1 week(s) on No end date Effective Sep 9, 2015 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; jkandasa 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/20160323/2c949a8c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3033 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160323/2c949a8c/attachment-0001.bin From mazz at redhat.com Wed Mar 23 09:28:03 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 23 Mar 2016 09:28:03 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <1889403374.13502328.1458738754330.JavaMail.zimbra@redhat.com> Message-ID: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> This is for Matt, but figured post here for public consumption. The question was asked yesterday, "Can we use the Hawkular WildFly Agent to monitor other things other than WildFly?" I gave one answer, but forgot there is a second alternative. ==== The first answer that I gave is that you can use the Hawkular Wildfly Agent to collect JMX data via Jolokia interface. There is an integration in the agent that lets you define your resource and metric metadata and your JMX/Jolokia servers. As an example, see here: https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 You define where your JMX servers are via the managed server like this: OK, that's the JMX integration. Maybe useful, maybe not. But I mention it just in case. ==== The second alternative I forgot to mention was the ability for any component running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that proxy that store inventory and metrics into the Hawkular Server. There is an example WAR module in the agent git repo that demonstrates how to obtain the proxy via JNDI and how to store inventory and metrics - see here: https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi This is just a simple WAR with a servlet. But it shows how a component can get the agent proxy via JNDI here: https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 Here's code that shows the servlet doing things like sending metrics, avail, and creating resources: https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java No one is using this yet. So there may be issues I am not aware of, but we have integration tests that show this working. This was put together with the anticipation of someone asking for this capability - that is, "can the agent be used to collect metrics for other things other than WildFly". Essentially, this just gives you a skeleton Java agent that you can extend to collect your own metrics and inventory. So you can write a WAR or EAR, deploy it in any WildFly that has an agent subsystem, and your EAR/WAR can be used as an "agent" for your custom stuff. Again, maybe useful, maybe not. But I mention it just in case. From mwringe at redhat.com Wed Mar 23 09:47:36 2016 From: mwringe at redhat.com (Matt Wringe) Date: Wed, 23 Mar 2016 09:47:36 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> Message-ID: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "John Mazzitelli" > To: "Discussions around Hawkular development" > Sent: Wednesday, March 23, 2016 9:28:03 AM > Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent > > This is for Matt, but figured post here for public consumption. > > The question was asked yesterday, "Can we use the Hawkular WildFly Agent to > monitor other things other than WildFly?" My question should have been more: "Do we have plans to have other Agents than just the WildFly one" For me, being able to gather metrics from a WildFly server is really awesome, but when I am dealing with multiple systems I am going to want to be able to manage all those metrics in the same place. Currently its possible for a user to custom write their own component to interface with the Hawkular Metrics server, but in this case it seems like we are asking all our users to continuously write their own agents. Which is not very user friendly and causes a bunch of duplication of effort. It would be awesome to be able to provide more agents that would be simple to setup and configure for different systems. If I am mostly running a bunch of different Java application, including WildFly, its going to be really tough to convince me to use Hawkular if its only going to monitor a subset of my systems. I would be much better off using Jolokia or something similar which can monitor all or most of my applications. > > I gave one answer, but forgot there is a second alternative. > > ==== > > The first answer that I gave is that you can use the Hawkular Wildfly Agent > to collect JMX data via Jolokia interface. There is an integration in the > agent that lets you define your resource and metric metadata and your > JMX/Jolokia servers. As an example, see here: > https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 > > You define where your JMX servers are via the managed server > like this: > > resourceTypeSets="MainJMX,MemoryPoolJMX" > url="http://localhost:8080/jolokia-war"/> > > OK, that's the JMX integration. Maybe useful, maybe not. But I mention it > just in case. Having the agent running in an EAP instance be able to monitor other jolokia end points is cool. But I don't really understand why this isn't a more standalone java application. I would think it would be much more useful to be able to have a standalone java agent which could run on the same system which is exposing the jolokia endpoint. Say I am only running Tomcat servers and I don't want to run Wildfly just to be able to gather the metrics from Tomcat. > ==== > > The second alternative I forgot to mention was the ability for any component > running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that > proxy that store inventory and metrics into the Hawkular Server. > > There is an example WAR module in the agent git repo that demonstrates how to > obtain the proxy via JNDI and how to store inventory and metrics - see here: > https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi > > This is just a simple WAR with a servlet. But it shows how a component can > get the agent proxy via JNDI here: > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 > > Here's code that shows the servlet doing things like sending metrics, avail, > and creating resources: > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java > > No one is using this yet. So there may be issues I am not aware of, but we > have integration tests that show this working. > > This was put together with the anticipation of someone asking for this > capability - that is, "can the agent be used to collect metrics for other > things other than WildFly". Essentially, this just gives you a skeleton Java > agent that you can extend to collect your own metrics and inventory. So you > can write a WAR or EAR, deploy it in any WildFly that has an agent > subsystem, and your EAR/WAR can be used as an "agent" for your custom stuff. > > Again, maybe useful, maybe not. But I mention it just in case. Being able to expose custom metrics is extremely important. Awesome that we have the ability to do that with the agent currently :) From mazz at redhat.com Wed Mar 23 10:03:55 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 23 Mar 2016 10:03:55 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: <283104424.13523724.1458741835922.JavaMail.zimbra@redhat.com> > "Do we have plans to have other Agents than just the WildFly one" > > For me, being able to gather metrics from a WildFly server is really awesome, > but when I am dealing with multiple systems I am going to want to be able to > manage all those metrics in the same place. I'm thinking about writing a Python agent API - something like an Python skeleton or something where someone can take a the Hawkular Python API and build around it to collect all metrics without having to do so in a Java VM. > Currently its possible for a user to custom write their own component to > interface with the Hawkular Metrics server, but in this case it seems like > we are asking all our users to continuously write their own agents. Which is > not very user friendly and causes a bunch of duplication of effort. > It would be awesome to be able to provide more agents that would be simple to > setup and configure for different systems. Which is why I think having a Python agent API would be useful. No need to run a heavyweight Java app like you would with the Hawkular WildFly Agent. I know someone (Thomas S?) is writing a vert.x agent. I don't know what other efforts are ongoing to write other agents. > If I am mostly running a bunch of different Java application, including > WildFly, its going to be really tough to convince me to use Hawkular if its > only going to monitor a subset of my systems. I would be much better off > using Jolokia or something similar which can monitor all or most of my > applications. If all or most of your applications are exposing data via Jolokia, no reason why you can't use the same Hawkular WildFly Agent. You can configure one individual Hawkular WildFly Agent to collect data from multiple WildFlys AND multiple Jolokia endpoints (which may or may not be WildFly servers - the agent don't care - as long as its talking to a Jolokia endpoint that's good enough for the agent. It would be a Tomcat server or whatever - if its got Jolokia, the Hawkular WildFly Agent will monitor it.) Of course, it would be a standalone Java app running along side of all of these ... i.e. would NOT be running inside of your Tomcat apps... which is your next point... > Having the agent running in an EAP instance be able to monitor other jolokia > end points is cool. But I don't really understand why this isn't a more > standalone java application. I would think it would be much more useful to > be able to have a standalone java agent which could run on the same system > which is exposing the jolokia endpoint. Say I am only running Tomcat servers > and I don't want to run Wildfly just to be able to gather the metrics from > Tomcat. Yeah, in this case, sounds like you want an embeddable Java agent. Funny - because we had this in RHQ/JON, but no one cared for it, no one wanted it, no one asked for it :) So we dropped that a long time ago. When we built the Hawkular Agent, we took that past experience and said, "why should we write a standalone agent when no one wants it? Just write a WildFly subsystem and run it directly in WildFly and we get a Java container with a CLI for free." :-) From miburman at redhat.com Wed Mar 23 10:29:39 2016 From: miburman at redhat.com (Michael Burman) Date: Wed, 23 Mar 2016 10:29:39 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <283104424.13523724.1458741835922.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <283104424.13523724.1458741835922.JavaMail.zimbra@redhat.com> Message-ID: <3362450.66847503.1458743379155.JavaMail.zimbra@redhat.com> Hi, You mean something like this? https://github.com/burmanm/gather_agent (Python Agent writing to RHQ Metrics with pluggable inputs). I actually used this code in one IoT platform to read statistics from one device and write them to one server. There's lots of similar projects though which are more full featured (like Diamond). These are very easy to extend, for example Golang is terrible in that sense. - Micke ----- Original Message ----- From: "John Mazzitelli" To: "Matt Wringe" , "Discussions around Hawkular development" Sent: Wednesday, March 23, 2016 4:03:55 PM Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent > "Do we have plans to have other Agents than just the WildFly one" > > For me, being able to gather metrics from a WildFly server is really awesome, > but when I am dealing with multiple systems I am going to want to be able to > manage all those metrics in the same place. I'm thinking about writing a Python agent API - something like an Python skeleton or something where someone can take a the Hawkular Python API and build around it to collect all metrics without having to do so in a Java VM. > Currently its possible for a user to custom write their own component to > interface with the Hawkular Metrics server, but in this case it seems like > we are asking all our users to continuously write their own agents. Which is > not very user friendly and causes a bunch of duplication of effort. > It would be awesome to be able to provide more agents that would be simple to > setup and configure for different systems. Which is why I think having a Python agent API would be useful. No need to run a heavyweight Java app like you would with the Hawkular WildFly Agent. I know someone (Thomas S?) is writing a vert.x agent. I don't know what other efforts are ongoing to write other agents. > If I am mostly running a bunch of different Java application, including > WildFly, its going to be really tough to convince me to use Hawkular if its > only going to monitor a subset of my systems. I would be much better off > using Jolokia or something similar which can monitor all or most of my > applications. If all or most of your applications are exposing data via Jolokia, no reason why you can't use the same Hawkular WildFly Agent. You can configure one individual Hawkular WildFly Agent to collect data from multiple WildFlys AND multiple Jolokia endpoints (which may or may not be WildFly servers - the agent don't care - as long as its talking to a Jolokia endpoint that's good enough for the agent. It would be a Tomcat server or whatever - if its got Jolokia, the Hawkular WildFly Agent will monitor it.) Of course, it would be a standalone Java app running along side of all of these ... i.e. would NOT be running inside of your Tomcat apps... which is your next point... > Having the agent running in an EAP instance be able to monitor other jolokia > end points is cool. But I don't really understand why this isn't a more > standalone java application. I would think it would be much more useful to > be able to have a standalone java agent which could run on the same system > which is exposing the jolokia endpoint. Say I am only running Tomcat servers > and I don't want to run Wildfly just to be able to gather the metrics from > Tomcat. Yeah, in this case, sounds like you want an embeddable Java agent. Funny - because we had this in RHQ/JON, but no one cared for it, no one wanted it, no one asked for it :) So we dropped that a long time ago. When we built the Hawkular Agent, we took that past experience and said, "why should we write a standalone agent when no one wants it? Just write a WildFly subsystem and run it directly in WildFly and we get a Java container with a CLI for free." :-) _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From mazz at redhat.com Wed Mar 23 10:36:48 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 23 Mar 2016 10:36:48 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <3362450.66847503.1458743379155.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <283104424.13523724.1458741835922.JavaMail.zimbra@redhat.com> <3362450.66847503.1458743379155.JavaMail.zimbra@redhat.com> Message-ID: <847465802.13535256.1458743808555.JavaMail.zimbra@redhat.com> Yeah! You should publicize that. People are asking for different agents like this. ----- Original Message ----- > Hi, > > You mean something like this? https://github.com/burmanm/gather_agent (Python > Agent writing to RHQ Metrics with pluggable inputs). I actually used this > code in one IoT platform to read statistics from one device and write them > to one server. > > There's lots of similar projects though which are more full featured (like > Diamond). These are very easy to extend, for example Golang is terrible in > that sense. > > - Micke > > ----- Original Message ----- > From: "John Mazzitelli" > To: "Matt Wringe" , "Discussions around Hawkular > development" > Sent: Wednesday, March 23, 2016 4:03:55 PM > Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java > agent > > > "Do we have plans to have other Agents than just the WildFly one" > > > > For me, being able to gather metrics from a WildFly server is really > > awesome, > > but when I am dealing with multiple systems I am going to want to be able > > to > > manage all those metrics in the same place. > > I'm thinking about writing a Python agent API - something like an Python > skeleton or something where someone can take a the Hawkular Python API and > build around it to collect all metrics without having to do so in a Java VM. > > > Currently its possible for a user to custom write their own component to > > interface with the Hawkular Metrics server, but in this case it seems like > > we are asking all our users to continuously write their own agents. Which > > is > > not very user friendly and causes a bunch of duplication of effort. > > It would be awesome to be able to provide more agents that would be simple > > to > > setup and configure for different systems. > > Which is why I think having a Python agent API would be useful. No need to > run a heavyweight Java app like you would with the Hawkular WildFly Agent. > > I know someone (Thomas S?) is writing a vert.x agent. > > I don't know what other efforts are ongoing to write other agents. > > > If I am mostly running a bunch of different Java application, including > > WildFly, its going to be really tough to convince me to use Hawkular if its > > only going to monitor a subset of my systems. I would be much better off > > using Jolokia or something similar which can monitor all or most of my > > applications. > > If all or most of your applications are exposing data via Jolokia, no reason > why you can't use the same Hawkular WildFly Agent. > > You can configure one individual Hawkular WildFly Agent to collect data from > multiple WildFlys AND multiple Jolokia endpoints (which may or may not be > WildFly servers - the agent don't care - as long as its talking to a Jolokia > endpoint that's good enough for the agent. It would be a Tomcat server or > whatever - if its got Jolokia, the Hawkular WildFly Agent will monitor it.) > > Of course, it would be a standalone Java app running along side of all of > these ... i.e. would NOT be running inside of your Tomcat apps... which is > your next point... > > > Having the agent running in an EAP instance be able to monitor other > > jolokia > > end points is cool. But I don't really understand why this isn't a more > > standalone java application. I would think it would be much more useful to > > be able to have a standalone java agent which could run on the same system > > which is exposing the jolokia endpoint. Say I am only running Tomcat > > servers > > and I don't want to run Wildfly just to be able to gather the metrics from > > Tomcat. > > Yeah, in this case, sounds like you want an embeddable Java agent. Funny - > because we had this in RHQ/JON, but no one cared for it, no one wanted it, > no one asked for it :) So we dropped that a long time ago. When we built the > Hawkular Agent, we took that past experience and said, "why should we write > a standalone agent when no one wants it? Just write a WildFly subsystem and > run it directly in WildFly and we get a Java container with a CLI for free." > :-) > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jdoyle at redhat.com Wed Mar 23 12:03:48 2016 From: jdoyle at redhat.com (John Doyle) Date: Wed, 23 Mar 2016 12:03:48 -0400 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Mar 23, 2016 at 9:47 AM, Matt Wringe wrote: > ----- Original Message ----- > > From: "John Mazzitelli" > > To: "Discussions around Hawkular development" < > hawkular-dev at lists.jboss.org> > > Sent: Wednesday, March 23, 2016 9:28:03 AM > > Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java > agent > > > > This is for Matt, but figured post here for public consumption. > > > > The question was asked yesterday, "Can we use the Hawkular WildFly Agent > to > > monitor other things other than WildFly?" > > My question should have been more: > > "Do we have plans to have other Agents than just the WildFly one" > We have not discussed it because all of our efforts are around Wildly for now, but we will need an agent for Fuse at some point. IDK if a jolokia is the right answer for that platform or not. > > For me, being able to gather metrics from a WildFly server is really > awesome, but when I am dealing with multiple systems I am going to want to > be able to manage all those metrics in the same place. > > Currently its possible for a user to custom write their own component to > interface with the Hawkular Metrics server, but in this case it seems like > we are asking all our users to continuously write their own agents. Which > is not very user friendly and causes a bunch of duplication of effort. > > It would be awesome to be able to provide more agents that would be simple > to setup and configure for different systems. > > If I am mostly running a bunch of different Java application, including > WildFly, its going to be really tough to convince me to use Hawkular if its > only going to monitor a subset of my systems. I would be much better off > using Jolokia or something similar which can monitor all or most of my > applications. > > > > > I gave one answer, but forgot there is a second alternative. > > > > ==== > > > > The first answer that I gave is that you can use the Hawkular Wildfly > Agent > > to collect JMX data via Jolokia interface. There is an integration in the > > agent that lets you define your resource and metric metadata and your > > JMX/Jolokia servers. As an example, see here: > > > https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 > > > > You define where your JMX servers are via the managed server > > like this: > > > > > resourceTypeSets="MainJMX,MemoryPoolJMX" > > url="http://localhost:8080/jolokia-war"/> > > > > OK, that's the JMX integration. Maybe useful, maybe not. But I mention it > > just in case. > > Having the agent running in an EAP instance be able to monitor other > jolokia end points is cool. But I don't really understand why this isn't a > more standalone java application. I would think it would be much more > useful to be able to have a standalone java agent which could run on the > same system which is exposing the jolokia endpoint. Say I am only running > Tomcat servers and I don't want to run Wildfly just to be able to gather > the metrics from Tomcat. > > > ==== > > > > The second alternative I forgot to mention was the ability for any > component > > running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that > > proxy that store inventory and metrics into the Hawkular Server. > > > > There is an example WAR module in the agent git repo that demonstrates > how to > > obtain the proxy via JNDI and how to store inventory and metrics - see > here: > > > https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi > > > > This is just a simple WAR with a servlet. But it shows how a component > can > > get the agent proxy via JNDI here: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 > > > > Here's code that shows the servlet doing things like sending metrics, > avail, > > and creating resources: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java > > > > No one is using this yet. So there may be issues I am not aware of, but > we > > have integration tests that show this working. > > > > This was put together with the anticipation of someone asking for this > > capability - that is, "can the agent be used to collect metrics for other > > things other than WildFly". Essentially, this just gives you a skeleton > Java > > agent that you can extend to collect your own metrics and inventory. So > you > > can write a WAR or EAR, deploy it in any WildFly that has an agent > > subsystem, and your EAR/WAR can be used as an "agent" for your custom > stuff. > > > > Again, maybe useful, maybe not. But I mention it just in case. > > Being able to expose custom metrics is extremely important. Awesome that > we have the ability to do that with the agent currently :) > _______________________________________________ > 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/20160323/b6281678/attachment-0001.html From hrupp at redhat.com Wed Mar 23 13:20:00 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 23 Mar 2016 17:20:00 +0000 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> Message-ID: On 23 Mar 2016, at 13:28, John Mazzitelli wrote: > The question was asked yesterday, "Can we use the Hawkular WildFly > Agent to monitor other things other than WildFly?" Can we be a bit more precise here - we have a lot of feeds that just feed into metrics, but completely ignore inventory. The wf-agent does both. We have ptrans that only feeds into metrics and you need to later know what you are looking for. On the Ruby side we have support for inventory in the Gem, which I have described here: http://pilhuhn.blogspot.com/2016/02/send-iot-data-to-hawkular-full.html For the vert.x agent we have GSoC proposals to add inventory functionality. For things like Fuse etc. I believe we always need inventory. Just pumping metrics from left to right is not enough. From hrupp at redhat.com Wed Mar 23 13:39:35 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 23 Mar 2016 17:39:35 +0000 Subject: [Hawkular-dev] Adafruit IO metrics dashboard Message-ID: <9521E597-A5EB-457A-BD67-B1E5ADBEA4FC@redhat.com> io.Adafruit is a service where Adafruit customers can throw their IoT data at. they have a blog and are moving to C* backend apparently https://io.adafruit.com/blog/ From tsegismo at redhat.com Thu Mar 24 05:27:50 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 24 Mar 2016 10:27:50 +0100 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: Hi Matt, Answers inline 2016-03-23 14:47 GMT+01:00 Matt Wringe : > ----- Original Message ----- > > From: "John Mazzitelli" > > To: "Discussions around Hawkular development" < > hawkular-dev at lists.jboss.org> > > Sent: Wednesday, March 23, 2016 9:28:03 AM > > Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java > agent > > > > This is for Matt, but figured post here for public consumption. > > > > The question was asked yesterday, "Can we use the Hawkular WildFly Agent > to > > monitor other things other than WildFly?" > > My question should have been more: > > "Do we have plans to have other Agents than just the WildFly one" > Here is the list of reporters I know we're working on: - hawkular-agent - vertx-hawkular-metrics - heapster plugin - ptrans - all language clients (hawkular-go, hawkular-ruby, ... etc) There is a JIRA in Metrics for a Node plugin. > > For me, being able to gather metrics from a WildFly server is really > awesome, but when I am dealing with multiple systems I am going to want to > be able to manage all those metrics in the same place. > > Currently its possible for a user to custom write their own component to > interface with the Hawkular Metrics server, but in this case it seems like > we are asking all our users to continuously write their own agents. Which > is not very user friendly and causes a bunch of duplication of effort. > This is not true. Many development platforms have plugins to report data over the Graphite text protocol. The goal of the ptrans project is to allow reuse of existing monitoring infrastructure by forwarding data sent over widely used monitoring network protocols to the Metrics HTTP interface. > > It would be awesome to be able to provide more agents that would be simple > to setup and configure for different systems. > We already have a few projects (see above) but obviously there's a limit in the number of reporters the core team can maintain. ptrans lets us benefit from a wide ecosystem of independent metric collectors. > > If I am mostly running a bunch of different Java application, including > WildFly, its going to be really tough to convince me to use Hawkular if its > only going to monitor a subset of my systems. I would be much better off > using Jolokia or something similar which can monitor all or most of my > applications. > Correct me if I'm wrong, but Jolokia is not a collection system. It is an HTTP adaptor around JMX. I would argue that a great majority of Java applications either: - collect monitoring data with home-built systems and publish to JMX - collect monitoring data with Dropwizard Metrics In the former case, user can combine jmxtrans(or embedded jmxtrans) with ptrans. In the latter, Dropwizard can be configured to send data over the Graphite protocol to ptrans. > > > > > I gave one answer, but forgot there is a second alternative. > > > > ==== > > > > The first answer that I gave is that you can use the Hawkular Wildfly > Agent > > to collect JMX data via Jolokia interface. There is an integration in the > > agent that lets you define your resource and metric metadata and your > > JMX/Jolokia servers. As an example, see here: > > > https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 > > > > You define where your JMX servers are via the managed server > > like this: > > > > > resourceTypeSets="MainJMX,MemoryPoolJMX" > > url="http://localhost:8080/jolokia-war"/> > > > > OK, that's the JMX integration. Maybe useful, maybe not. But I mention it > > just in case. > > Having the agent running in an EAP instance be able to monitor other > jolokia end points is cool. But I don't really understand why this isn't a > more standalone java application. I would think it would be much more > useful to be able to have a standalone java agent which could run on the > same system which is exposing the jolokia endpoint. Say I am only running > Tomcat servers and I don't want to run Wildfly just to be able to gather > the metrics from Tomcat. > > > ==== > > > > The second alternative I forgot to mention was the ability for any > component > > running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that > > proxy that store inventory and metrics into the Hawkular Server. > > > > There is an example WAR module in the agent git repo that demonstrates > how to > > obtain the proxy via JNDI and how to store inventory and metrics - see > here: > > > https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi > > > > This is just a simple WAR with a servlet. But it shows how a component > can > > get the agent proxy via JNDI here: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 > > > > Here's code that shows the servlet doing things like sending metrics, > avail, > > and creating resources: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java > > > > No one is using this yet. So there may be issues I am not aware of, but > we > > have integration tests that show this working. > > > > This was put together with the anticipation of someone asking for this > > capability - that is, "can the agent be used to collect metrics for other > > things other than WildFly". Essentially, this just gives you a skeleton > Java > > agent that you can extend to collect your own metrics and inventory. So > you > > can write a WAR or EAR, deploy it in any WildFly that has an agent > > subsystem, and your EAR/WAR can be used as an "agent" for your custom > stuff. > > > > Again, maybe useful, maybe not. But I mention it just in case. > > Being able to expose custom metrics is extremely important. Awesome that > we have the ability to do that with the agent currently :) > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -- Thomas Segismont JBoss ON Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160324/8f4c6ef3/attachment.html From tsegismo at redhat.com Thu Mar 24 05:35:43 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 24 Mar 2016 10:35:43 +0100 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: Sorry missed that part: 2016-03-23 14:47 GMT+01:00 Matt Wringe : > Having the agent running in an EAP instance be able to monitor other > jolokia end points is cool. But I don't really understand why this isn't a > more standalone java application. I would think it would be much more > useful to be able to have a standalone java agent which could run on the > same system which is exposing the jolokia endpoint. Say I am only running > Tomcat servers and I don't want to run Wildfly just to be able to gather > the metrics from Tomcat. A lot of people in the Java community use JMXTrans or embedded JMXTrans to monitor Tomcat. As mentioned previously, JMXTrans can send data to ptrans over the Graphite protocol. I have all the setup details and article ready since last summer HWKMETRICS-158 Write an article to explain how to use Metrics + JMXTrans + Grafana to monitor Tomcat application I did not publish because I wanted to create a video and then my attention was brought to other things. It's a shame. I will fix this soon. https://issues.jboss.org/browse/HWKMETRICS-158 -- Thomas Segismont JBoss ON Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160324/2260666c/attachment.html From tsegismo at redhat.com Thu Mar 24 05:37:18 2016 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 24 Mar 2016 10:37:18 +0100 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: Sorry missed that part: 2016-03-23 14:47 GMT+01:00 Matt Wringe : > Having the agent running in an EAP instance be able to monitor other > jolokia end points is cool. But I don't really understand why this isn't a > more standalone java application. I would think it would be much more > useful to be able to have a standalone java agent which could run on the > same system which is exposing the jolokia endpoint. Say I am only running > Tomcat servers and I don't want to run Wildfly just to be able to gather > the metrics from Tomcat. A lot of people in the Java community use JMXTrans or embedded JMXTrans to monitor Tomcat. As mentioned previously, JMXTrans can send data to ptrans over the Graphite protocol. I have all the setup details and article ready since last summer HWKMETRICS-158 Write an article to explain how to use Metrics + JMXTrans + Grafana to monitor Tomcat application I did not publish because I wanted to create a video and then my attention was brought to other things. It's a shame. I will fix this. https://issues.jboss.org/browse/HWKMETRICS-158 -- Thomas Segismont JBoss ON Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160324/73c8744a/attachment-0001.html From hrupp at redhat.com Thu Mar 24 06:12:12 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 24 Mar 2016 10:12:12 +0000 Subject: [Hawkular-dev] Fwd: [aerogear-dev] Artemis bug on WildFly-10 References: Message-ID: Also as FYI in case we see something similar. > From: Matthias Wessendorf > To: AeroGear Developer Mailing List > Subject: [aerogear-dev] Artemis bug on WildFly-10 > Date: Thu, 24 Mar 2016 00:42:46 +0100 > > Hi, > > more as a FYI.... > > I am in the process of updating our Docker -DEV image to WF/10 (see > [1]), > and I noticed a bug in Artemis: > > > Caused by: javax.jms.JMSException: Failed to create session factory > at > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727) > at > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233) > at > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229) > at > org.jboss.aerogear.unifiedpush.message.util.JmsClient$JmsReceiver.from(JmsClient.java:173) > ... 172 more > Caused by: > ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT > message=AMQ119013: Timed out waiting to receive cluster topology. > Group:null] > at > org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:813) > at > org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724) > ... 175 more > Now, this issue is addressed by > https://issues.apache.org/jira/browse/ARTEMIS-385 and fixed in > ActiveMQ-Artemis 1.3.0 (unreleased), but WildFly 10.x is (currently) > on > their 1.1.0 version. > > Worth to mention; I think I am unable to reproduce this directly on my > Mac, > just w/ CentOS7 and WF-10 (via ), using this image: > https://github.com/jboss-dockerfiles/wildfly/tree/10.0.0.Final > > > Cheers, > Matthias > > [1] https://github.com/matzew/dockerfiles/tree/WF_10_ups_120 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From hrupp at redhat.com Thu Mar 24 08:50:49 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 24 Mar 2016 12:50:49 +0000 Subject: [Hawkular-dev] Test coverage Message-ID: <357F1BAF-78E7-4C38-8276-031DE869872C@redhat.com> Hey, I think we should start looking at and recording test coverage of our various Hawkular artifacts and also "enforce" them like failing pull-requests when coverage is going below a certain threshold. We should have done that long time ago, but better late then never ;-) Heiko From jshaughn at redhat.com Mon Mar 28 10:59:05 2016 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 28 Mar 2016 10:59:05 -0400 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> Message-ID: <56F946B9.9030707@redhat.com> I think we should limit ourselves to the Wildfly/EAP agent that we're already working on, as EAP hosted app monitoring/mgmt is our bread and butter. Past that we should provide infrastructure to help others hook into the MW MIQ support. So basically, what we're doing so far seems good to me. As attractive as it is to have one agent allow many feeds to "plugin" we need to be wary of trying to have a single agent/feed do too much, or we'll end up with the RHQ scenario of an agent that is too heavy. And from a dev standpoint, like miq, we should in general leave the feeds to be impl'd by those that want (or are required) to supply data/inventory, in the way that they see fit. That community effort will validate and improve our infrastructure, and help us maintain focus on the core. On 3/24/2016 5:27 AM, Thomas Segismont wrote: > Hi Matt, > > Answers inline > > 2016-03-23 14:47 GMT+01:00 Matt Wringe >: > > ----- Original Message ----- > > From: "John Mazzitelli" > > > To: "Discussions around Hawkular development" > > > > Sent: Wednesday, March 23, 2016 9:28:03 AM > > Subject: [Hawkular-dev] using hawkular wildfly agent as a custom > java agent > > > > This is for Matt, but figured post here for public consumption. > > > > The question was asked yesterday, "Can we use the Hawkular > WildFly Agent to > > monitor other things other than WildFly?" > > My question should have been more: > > "Do we have plans to have other Agents than just the WildFly one" > > > > Here is the list of reporters I know we're working on: > - hawkular-agent > - vertx-hawkular-metrics > - heapster plugin > - ptrans > - all language clients (hawkular-go, hawkular-ruby, ... etc) > > There is a JIRA in Metrics for a Node plugin. > > > For me, being able to gather metrics from a WildFly server is > really awesome, but when I am dealing with multiple systems I am > going to want to be able to manage all those metrics in the same > place. > > Currently its possible for a user to custom write their own > component to interface with the Hawkular Metrics server, but in > this case it seems like we are asking all our users to > continuously write their own agents. Which is not very user > friendly and causes a bunch of duplication of effort. > > > This is not true. Many development platforms have plugins to report > data over the Graphite text protocol. The goal of the ptrans project > is to allow reuse of existing monitoring infrastructure by forwarding > data sent over widely used monitoring network protocols to the Metrics > HTTP interface. > > > It would be awesome to be able to provide more agents that would > be simple to setup and configure for different systems. > > > We already have a few projects (see above) but obviously there's a > limit in the number of reporters the core team can maintain. ptrans > lets us benefit from a wide ecosystem of independent metric collectors. > > > If I am mostly running a bunch of different Java application, > including WildFly, its going to be really tough to convince me to > use Hawkular if its only going to monitor a subset of my systems. > I would be much better off using Jolokia or something similar > which can monitor all or most of my applications. > > > Correct me if I'm wrong, but Jolokia is not a collection system. It is > an HTTP adaptor around JMX. I would argue that a great majority of > Java applications either: > - collect monitoring data with home-built systems and publish to JMX > - collect monitoring data with Dropwizard Metrics > > In the former case, user can combine jmxtrans(or embedded jmxtrans) > with ptrans. In the latter, Dropwizard can be configured to send data > over the Graphite protocol to ptrans. > > > > > > I gave one answer, but forgot there is a second alternative. > > > > ==== > > > > The first answer that I gave is that you can use the Hawkular > Wildfly Agent > > to collect JMX data via Jolokia interface. There is an > integration in the > > agent that lets you define your resource and metric metadata and > your > > JMX/Jolokia servers. As an example, see here: > > > https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 > > > > You define where your JMX servers are via the > managed server > > like this: > > > > > resourceTypeSets="MainJMX,MemoryPoolJMX" > > url="http://localhost:8080/jolokia-war"/> > > > > OK, that's the JMX integration. Maybe useful, maybe not. But I > mention it > > just in case. > > Having the agent running in an EAP instance be able to monitor > other jolokia end points is cool. But I don't really understand > why this isn't a more standalone java application. I would think > it would be much more useful to be able to have a standalone java > agent which could run on the same system which is exposing the > jolokia endpoint. Say I am only running Tomcat servers and I don't > want to run Wildfly just to be able to gather the metrics from Tomcat. > > > ==== > > > > The second alternative I forgot to mention was the ability for > any component > > running in WildFly to obtain a Hawkular Agent proxy via JNDI and > use that > > proxy that store inventory and metrics into the Hawkular Server. > > > > There is an example WAR module in the agent git repo that > demonstrates how to > > obtain the proxy via JNDI and how to store inventory and metrics > - see here: > > > https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi > > > > This is just a simple WAR with a servlet. But it shows how a > component can > > get the agent proxy via JNDI here: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 > > > > Here's code that shows the servlet doing things like sending > metrics, avail, > > and creating resources: > > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java > > > > No one is using this yet. So there may be issues I am not aware > of, but we > > have integration tests that show this working. > > > > This was put together with the anticipation of someone asking > for this > > capability - that is, "can the agent be used to collect metrics > for other > > things other than WildFly". Essentially, this just gives you a > skeleton Java > > agent that you can extend to collect your own metrics and > inventory. So you > > can write a WAR or EAR, deploy it in any WildFly that has an agent > > subsystem, and your EAR/WAR can be used as an "agent" for your > custom stuff. > > > > Again, maybe useful, maybe not. But I mention it just in case. > > Being able to expose custom metrics is extremely important. > Awesome that we have the ability to do that with the agent > currently :) > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > -- > Thomas Segismont > JBoss ON Engineering Team > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160328/64a9f2ed/attachment-0001.html From jsanda at redhat.com Mon Mar 28 11:39:09 2016 From: jsanda at redhat.com (John Sanda) Date: Mon, 28 Mar 2016 11:39:09 -0400 Subject: [Hawkular-dev] schema change management Message-ID: <5B3A3FBB-7CD5-4D7C-8D68-6C674AEC33C1@redhat.com> I have been working on introducing schema change management in Hawkular Metrics. The big challenge lies in how to support various upgrade scenarios. The work is being done in https://issues.jboss.org/browse/HWKMETRICS-361 and there is a lengthy comment that summarizes how we will handle upgrade scenarios. I wanted to share as this will hopefully be useful and applicable outside of metrics. - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160328/b463e079/attachment.html From snegrea at redhat.com Tue Mar 29 11:19:15 2016 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 29 Mar 2016 10:19:15 -0500 Subject: [Hawkular-dev] Hawkular Metrics 0.14.0 - Release Message-ID: Hello Everybody, I am happy to announce release 0.14.0 of Hawkular Metrics. This release is anchored by the launch of a developer oriented distribution to help developers that integrate with Hawkular Metrics. Here is a list of major changes in this release: 1) Developer Distribution * First release of a Hawkular Metrics distribution oriented towards developers that integrate with Hawkular Metrics * This is an all inclusive distribution that developers can just download and run to easily test integration code * The distribution is available in two flavors : - Hawkular Metrics Web API + Wildfly 10 (requires an external C* cluster) - Hawkular Metrics Web APi + Wildfly 10 + Embedded Cassandra Server * The second distribution is available for installation on OS X via brew $ brew tap hawkular/hawkular $ brew install hawkular-metrics-ec * To download and use on other platforms: - Web API + WildFly 10 - http://red.ht/1LX4aUH - Web API + WildFly 10 + Embedded Cassandra - http://red.ht/1RxaI9i * For more details: HWKMETRICS-364, HWKMETRICS-366 2) Upgraded Cassandra Driver * The Cassandra driver has been update to version 3.0.0 * This is part of the planned upgrade to Cassandra 3.x * For more details: HWKMETRICS-359 3) RxJava Improvements * Resolved an issue where the RX computation threads could block while iterating over data results * For more details: HWKMETRICS-357 Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.14.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/12329845 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 A big "Thank you" goes to John Sanda, Thomas Segismont, Matt Wringe, Mike Thompson, Michael Burman, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160329/317adef8/attachment.html From mazz at redhat.com Tue Mar 29 12:11:14 2016 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 29 Mar 2016 12:11:14 -0400 (EDT) Subject: [Hawkular-dev] ruby-to-py In-Reply-To: <1872341775.15255995.1459267871635.JavaMail.zimbra@redhat.com> Message-ID: <554520962.15255997.1459267874048.JavaMail.zimbra@redhat.com> The ruby client is getting a lot of work and seems to be coming into shape. What are the chances of us being able to take that ruby client and "copy" it to make a python client so we can have both ruby and py support? From mwringe at redhat.com Wed Mar 30 10:23:23 2016 From: mwringe at redhat.com (Matt Wringe) Date: Wed, 30 Mar 2016 10:23:23 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <56F946B9.9030707@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <56F946B9.9030707@redhat.com> Message-ID: <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jay Shaughnessy" > To: hawkular-dev at lists.jboss.org > Sent: Monday, March 28, 2016 10:59:05 AM > Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent > > > I think we should limit ourselves to the Wildfly/EAP agent that we're already > working on, as EAP hosted app monitoring/mgmt is our bread and butter. Past Except this assumption is not necessarily correct. Hawkular, at least Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. We are using Hawkular-Metrics in OpenShift (https://github.com/openshift/origin-metrics) and there are other potential integration points that are being looking into. If we only want to handle the Wildfly/EAP case, then we really need to take a good look and determine if these other integrations make sense or not. Otherwise we should really start to look beyond just Wildfly/EAP so that these integration can be handled better. > that we should provide infrastructure to help others hook into the MW MIQ > support. So basically, what we're doing so far seems good to me. As > attractive as it is to have one agent allow many feeds to "plugin" we need > to be wary of trying to have a single agent/feed do too much, or we'll end > up with the RHQ scenario of an agent that is too heavy. And from a dev > standpoint, like miq, we should in general leave the feeds to be impl'd by > those that want (or are required) to supply data/inventory, in the way that > they see fit. That community effort will validate and improve our > infrastructure, and help us maintain focus on the core. > > > On 3/24/2016 5:27 AM, Thomas Segismont wrote: > > > > Hi Matt, > > Answers inline > > 2016-03-23 14:47 GMT+01:00 Matt Wringe < mwringe at redhat.com > : > > > ----- Original Message ----- > > From: "John Mazzitelli" < mazz at redhat.com > > > To: "Discussions around Hawkular development" < > > hawkular-dev at lists.jboss.org > > > Sent: Wednesday, March 23, 2016 9:28:03 AM > > Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent > > > > This is for Matt, but figured post here for public consumption. > > > > The question was asked yesterday, "Can we use the Hawkular WildFly Agent to > > monitor other things other than WildFly?" > > My question should have been more: > > "Do we have plans to have other Agents than just the WildFly one" > > > Here is the list of reporters I know we're working on: > - hawkular-agent > - vertx-hawkular-metrics > - heapster plugin > - ptrans > - all language clients (hawkular-go, hawkular-ruby, ... etc) > > There is a JIRA in Metrics for a Node plugin. > > > > For me, being able to gather metrics from a WildFly server is really awesome, > but when I am dealing with multiple systems I am going to want to be able to > manage all those metrics in the same place. > > Currently its possible for a user to custom write their own component to > interface with the Hawkular Metrics server, but in this case it seems like > we are asking all our users to continuously write their own agents. Which is > not very user friendly and causes a bunch of duplication of effort. > > This is not true. Many development platforms have plugins to report data over > the Graphite text protocol. The goal of the ptrans project is to allow reuse > of existing monitoring infrastructure by forwarding data sent over widely > used monitoring network protocols to the Metrics HTTP interface. > > > > It would be awesome to be able to provide more agents that would be simple to > setup and configure for different systems. > > We already have a few projects (see above) but obviously there's a limit in > the number of reporters the core team can maintain. ptrans lets us benefit > from a wide ecosystem of independent metric collectors. > > > > If I am mostly running a bunch of different Java application, including > WildFly, its going to be really tough to convince me to use Hawkular if its > only going to monitor a subset of my systems. I would be much better off > using Jolokia or something similar which can monitor all or most of my > applications. > > Correct me if I'm wrong, but Jolokia is not a collection system. It is an > HTTP adaptor around JMX. I would argue that a great majority of Java > applications either: > - collect monitoring data with home-built systems and publish to JMX > - collect monitoring data with Dropwizard Metrics > > In the former case, user can combine jmxtrans(or embedded jmxtrans) with > ptrans. In the latter, Dropwizard can be configured to send data over the > Graphite protocol to ptrans. > > > > > > > I gave one answer, but forgot there is a second alternative. > > > > ==== > > > > The first answer that I gave is that you can use the Hawkular Wildfly Agent > > to collect JMX data via Jolokia interface. There is an integration in the > > agent that lets you define your resource and metric metadata and your > > JMX/Jolokia servers. As an example, see here: > > https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa560d568cd114afdec/hawkular-wildfly-agent-feature-pack/src/main/resources/subsystem-templates/hawkular-wildfly-agent.xml#L736-L817 > > > > You define where your JMX servers are via the managed server > > like this: > > > > > resourceTypeSets="MainJMX,MemoryPoolJMX" > > url=" http://localhost:8080/jolokia-war "/> > > > > OK, that's the JMX integration. Maybe useful, maybe not. But I mention it > > just in case. > > Having the agent running in an EAP instance be able to monitor other jolokia > end points is cool. But I don't really understand why this isn't a more > standalone java application. I would think it would be much more useful to > be able to have a standalone java agent which could run on the same system > which is exposing the jolokia endpoint. Say I am only running Tomcat servers > and I don't want to run Wildfly just to be able to gather the metrics from > Tomcat. > > > ==== > > > > The second alternative I forgot to mention was the ability for any > > component > > running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that > > proxy that store inventory and metrics into the Hawkular Server. > > > > There is an example WAR module in the agent git repo that demonstrates how > > to > > obtain the proxy via JNDI and how to store inventory and metrics - see > > here: > > https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi > > > > This is just a simple WAR with a servlet. But it shows how a component can > > get the agent proxy via JNDI here: > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/HawkularWildFlyAgentProvider.java#L32-L35 > > > > Here's code that shows the servlet doing things like sending metrics, > > avail, > > and creating resources: > > > > https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-agent-itest-parent/hawkular-wildfly-agent-example-jndi/src/main/java/org/hawkular/agent/example/MyAppServlet.java > > > > No one is using this yet. So there may be issues I am not aware of, but we > > have integration tests that show this working. > > > > This was put together with the anticipation of someone asking for this > > capability - that is, "can the agent be used to collect metrics for other > > things other than WildFly". Essentially, this just gives you a skeleton > > Java > > agent that you can extend to collect your own metrics and inventory. So you > > can write a WAR or EAR, deploy it in any WildFly that has an agent > > subsystem, and your EAR/WAR can be used as an "agent" for your custom > > stuff. > > > > Again, maybe useful, maybe not. But I mention it just in case. > > Being able to expose custom metrics is extremely important. Awesome that we > have the ability to do that with the agent currently :) > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > -- > Thomas Segismont > JBoss ON Engineering Team > > > _______________________________________________ > hawkular-dev mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Wed Mar 30 10:50:48 2016 From: jsanda at redhat.com (John Sanda) Date: Wed, 30 Mar 2016 10:50:48 -0400 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <56F946B9.9030707@redhat.com> <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> Message-ID: > On Mar 30, 2016, at 10:23 AM, Matt Wringe wrote: > > ----- Original Message ----- >> From: "Jay Shaughnessy" > >> To: hawkular-dev at lists.jboss.org >> Sent: Monday, March 28, 2016 10:59:05 AM >> Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent >> >> >> I think we should limit ourselves to the Wildfly/EAP agent that we're already >> working on, as EAP hosted app monitoring/mgmt is our bread and butter. Past > > Except this assumption is not necessarily correct. Hawkular, at least Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. > > We are using Hawkular-Metrics in OpenShift (https://github.com/openshift/origin-metrics ) and there are other potential integration points that are being looking into. If we only want to handle the Wildfly/EAP case, then we really need to take a good look and determine if these other integrations make sense or not. Otherwise we should really start to look beyond just Wildfly/EAP so that these integration can be handled better. We are actively working on other integration efforts, so we definitely need to look beyond WildFly/EAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160330/92e9ecc4/attachment-0001.html From jshaughn at redhat.com Wed Mar 30 12:00:46 2016 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Wed, 30 Mar 2016 12:00:46 -0400 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <56F946B9.9030707@redhat.com> <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> Message-ID: <56FBF82E.6080700@redhat.com> On 3/30/2016 10:50 AM, John Sanda wrote: > >> On Mar 30, 2016, at 10:23 AM, Matt Wringe > > wrote: >> >> ----- Original Message ----- >>> From: "Jay Shaughnessy" >> > >>> To:hawkular-dev at lists.jboss.org >>> Sent: Monday, March 28, 2016 10:59:05 AM >>> Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom >>> java agent >>> >>> >>> I think we should limit ourselves to the Wildfly/EAP agent that >>> we're already >>> working on, as EAP hosted app monitoring/mgmt is our bread and >>> butter. Past >> >> Except this assumption is not necessarily correct. Hawkular, at least >> Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. >> >> We are using Hawkular-Metrics in OpenShift >> (https://github.com/openshift/origin-metrics) and there are other >> potential integration points that are being looking into. If we only >> want to handle the Wildfly/EAP case, then we really need to take a >> good look and determine if these other integrations make sense or >> not. Otherwise we should really start to look beyond just Wildfly/EAP >> so that these integration can be handled better. > > We are actively working on other integration efforts, so we definitely > need to look beyond WildFly/EAP. What I'm cautioning against is trying to build all feeds ourselves. In RHQ we used a lot of manpower to build and maintain a lot of agent plugins. There is goodness in providing interfaces and infrastructure that make integrating as easy as possible, and then trying to avoid doing all of the integration work as well. This is the model that is working for miq. We have two things going on here, one is the team charter to provide middleware mgmt via manageiq, using hawkular as the provider. We'll need agents/feeds to hook up to hawkular to report inventory and metrics which then make their way to miq. We've got the WFly/EAP agent and that seems like the likely place to invest the most for MW mgmt. Then we've got H Metrics, which to some degree has a life of its own. Certainly the integrations with metrics are important and as I said before, I think we're already doing the right things, and just like hawkular overall, making integration easy is our biggest win because it will allow others to build their own feeds. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160330/2ac4b55a/attachment.html From mazz at redhat.com Wed Mar 30 12:42:50 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 30 Mar 2016 12:42:50 -0400 (EDT) Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <56FBF82E.6080700@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <56F946B9.9030707@redhat.com> <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> <56FBF82E.6080700@redhat.com> Message-ID: <1314871370.15689484.1459356170185.JavaMail.zimbra@redhat.com> > We are actively working on other integration efforts, so we definitely need > to look beyond WildFly/EAP. > > What I'm cautioning against is trying to build all feeds ourselves. In RHQ we > used a lot of manpower to build and maintain a lot of agent plugins. There > is goodness in providing interfaces and infrastructure that make integrating > as easy as possible, and then trying to avoid doing all of the integration > work as well. This is the model that is working for miq. This is why I'm looking at eventually building a python agent (similar to the Hawkular WildFly Agent but more pluggable to support custom managed resources). This would be more than the clients we have today - the clients we have today (ruby client for example) just exposes an API to talk to Hawkular Metrics, Inventory, etc. I want an extensible agent that provides a way for you to do what our RHQ plugins did - just write code that collects the metrics, inventory, executes ops and the agent will provide an infrastructure around it. At least, that's my plan. Who knows what people tell me to do next week :) From jsanda at redhat.com Wed Mar 30 13:36:39 2016 From: jsanda at redhat.com (John Sanda) Date: Wed, 30 Mar 2016 13:36:39 -0400 Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent In-Reply-To: <56FBF82E.6080700@redhat.com> References: <1872722933.13510108.1458739683638.JavaMail.zimbra@redhat.com> <485115850.45251676.1458740856269.JavaMail.zimbra@redhat.com> <56F946B9.9030707@redhat.com> <1939159780.49113188.1459347803497.JavaMail.zimbra@redhat.com> <56FBF82E.6080700@redhat.com> Message-ID: <0E554AE7-33E2-44E2-80C2-C38F1B234768@redhat.com> > On Mar 30, 2016, at 12:00 PM, Jay Shaughnessy wrote: > > > > On 3/30/2016 10:50 AM, John Sanda wrote: >> >>> On Mar 30, 2016, at 10:23 AM, Matt Wringe < mwringe at redhat.com > wrote: >>> >>> ----- Original Message ----- >>>> From: "Jay Shaughnessy" < jshaughn at redhat.com > >>>> To: hawkular-dev at lists.jboss.org >>>> Sent: Monday, March 28, 2016 10:59:05 AM >>>> Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent >>>> >>>> >>>> I think we should limit ourselves to the Wildfly/EAP agent that we're already >>>> working on, as EAP hosted app monitoring/mgmt is our bread and butter. Past >>> >>> Except this assumption is not necessarily correct. Hawkular, at least Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. >>> >>> We are using Hawkular-Metrics in OpenShift ( https://github.com/openshift/origin-metrics ) and there are other potential integration points that are being looking into. If we only want to handle the Wildfly/EAP case, then we really need to take a good look and determine if these other integrations make sense or not. Otherwise we should really start to look beyond just Wildfly/EAP so that these integration can be handled better. >> >> We are actively working on other integration efforts, so we definitely need to look beyond WildFly/EAP. > > What I'm cautioning against is trying to build all feeds ourselves. In RHQ we used a lot of manpower to build and maintain a lot of agent plugins. There is goodness in providing interfaces and infrastructure that make integrating as easy as possible, and then trying to avoid doing all of the integration work as well. This is the model that is working for miq. > > We have two things going on here, one is the team charter to provide middleware mgmt via manageiq, using hawkular as the provider. We'll need agents/feeds to hook up to hawkular to report inventory and metrics which then make their way to miq. We've got the WFly/EAP agent and that seems like the likely place to invest the most for MW mgmt. Then we've got H Metrics, which to some degree has a life of its own. Certainly the integrations with metrics are important and as I said before, I think we're already doing the right things, and just like hawkular overall, making integration easy is our biggest win because it will allow others to build their own feeds. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev I agree that we are doing the right thing by providing APIs to make integration easier; however it common, reoccurring question is about clients that build on top of those APIs. Considering that these questions keep coming up, I think we need to try to provide a better answer beyond simply providing APIs. I do not think this necessarily means we need to invest a lot in building client libraries. There are plenty of client libraries/tools we can look at, and things like ptrans really help with the integration. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160330/37f31c23/attachment-0001.html