From artur.dryomov at gmail.com Mon Jun 1 01:39:03 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 1 Jun 2015 08:39:03 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report Message-ID: Hi everyone, This year I am working on the Hawkular Android application as part of the Google Summer of Code 2015 program. The last week I spent of familiarization with the project and its key terms. With the help of public Hawkular servers, the Docker image and snapshots I looked at the API and experimented a bit to understand how things actually work. As a result I?ve created a wiki page [1] with the brief overview of key Hawkular terms. In the process I?ve opened a very first Hawkular issue regarding Docker image [2]. As a result of better understanding what is what I?ve created a very rough mockup of the UI [3] which I?ve also sent to the design team. Hopefully after a review of functions and design I can proceed with the development itself. There is some source code already [4] but mostly it is just a basic project structure, it is almost useless to the end user at this point. I would like to start the development process this week. Of course it will require a better understanding of what actually should be done ? I?ve tried to clarify this with creating the mockup. I think a basic authentication plus resources fetching is a good bet to work on even without clear requirements, so it can be started right away. Probably I should prepare a script to fill a Hawkular instance with some sample information ? in Python or just plain cURL. If anyone has something like that ? that will be a great help. I was advised to look at the test scenario [5] as a departure point but maybe someone of you have a similar thing locally. Regards, Artur. [1]: https://github.com/hawkular/android-client/wiki/Overview [2]: https://issues.jboss.org/browse/HAWKULAR-268 [3]: https://github.com/hawkular/android-client/wiki/Design [4]: https://github.com/hawkular/android-client [5]: https://github.com/hawkular/hawkular/blob/65f2573987890b1ffd4460e3449fb02b348816ea/modules/end-to-end-test/src/test/groovy/org/hawkular/integration/test/Scenario1ITest.groovy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150601/7f11d4d6/attachment.html From artur.dryomov at gmail.com Mon Jun 1 01:44:07 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 1 Jun 2015 08:44:07 +0300 Subject: [Hawkular-dev] OAuth Documentation Message-ID: Hi everyone, Is there any documentation regarding the OAuth authentication method to the Hawkular server? At moment I am using the basic authentication method and it works well, but probably OAuth is a better thing to do. Thanks, Artur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150601/390fc250/attachment.html From jpkroehling at redhat.com Mon Jun 1 03:15:03 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Mon, 01 Jun 2015 09:15:03 +0200 Subject: [Hawkular-dev] OAuth Documentation In-Reply-To: References: Message-ID: <556C0677.6000803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Artur, We use Keycloak to secure the access to the backend components. You can check the Keycloak's documentation at the following location: http://keycloak.github.io/docs/userguide/html_single/index.html If you have any questions about it, let me know. - - Juca. On 06/01/2015 07:44 AM, Artur Dryomov wrote: > Hi everyone, > > Is there any documentation regarding the OAuth authentication > method to the Hawkular server? At moment I am using the basic > authentication method and it works well, but probably OAuth is a > better thing to do. > > Thanks, Artur. > > > _______________________________________________ hawkular-dev > mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVbAZ3AAoJECKM1e+fkPrX+lQH/j7svhwvynZHuYUVqtS8KPc3 NDUu/cf3iS3a5FUpiQrCDiDzgnBs4CYU184m4RgRLbFXr4JXRWNQQA8odQINc+07 v6xsmWgDnbqBITgYuwiKU75hy5t5qWrFVSEgATdMjZpvRBi0kzR/24XRvG+NcpFb 1kD8clMHC8DLMEKHs3vTTcMCH7OEA+HK3Q9dopKRVUbpFyMKyfBQmTKvestdws22 GSnpKfnG/gNGj4t91gp3gcDmVw0O6l5uOS9ZwH7sciBl4g6FfiywoAay8JEuGLU8 3IFrekQN598HI7eQuUP9bIuT7dOevaJ9bY3WcLsmuuXgfQvrydvxeUFf47Izehw= =5Lis -----END PGP SIGNATURE----- From hrupp at redhat.com Mon Jun 1 03:51:30 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 01 Jun 2015 09:51:30 +0200 Subject: [Hawkular-dev] Release instructions Message-ID: <75DF4A22-7881-4DAD-9A54-ECF8F4B68C06@redhat.com> Hey, Triggered by https://github.com/hawkular/hawkular-accounts/pull/30/files Can we please agree on one maven profile for all Hawkular components that is used to create a release? I think that otherwise people less versed in a certain component that need to craft a release will just miss the right profiles. -Pdistribution certainly sounds like a good candidate. Heiko From jpkroehling at redhat.com Mon Jun 1 03:59:08 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Mon, 01 Jun 2015 09:59:08 +0200 Subject: [Hawkular-dev] Release instructions In-Reply-To: <75DF4A22-7881-4DAD-9A54-ECF8F4B68C06@redhat.com> References: <75DF4A22-7881-4DAD-9A54-ECF8F4B68C06@redhat.com> Message-ID: <556C10CC.70807@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Being tracked here: https://issues.jboss.org/browse/HAWKULAR-287 On 06/01/2015 09:51 AM, Heiko W.Rupp wrote: > Hey, > > Triggered by > https://github.com/hawkular/hawkular-accounts/pull/30/files > > Can we please agree on one maven profile for all Hawkular > components that is used to create a release? I think that otherwise > people less versed in a certain component that need to craft a > release will just miss the right profiles. > > -Pdistribution certainly sounds like a good candidate. We have the "-Pdistribution" on Accounts, but it has a different semantic. I'd suggest to either activate all the required profiles for releasing by default, disabling them if we pass a "-Pdev", *or*, by having a "-Prelease". - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVbBDMAAoJECKM1e+fkPrXLFUIAJTpNi+LKbn2r3WI+CaWRkWq H5nOGJn2z3Ozs2nU6Zw4LZoFMTKbT3fS4diWiwCz/Du8sG0P9ONqC/TI4sli2fYq vIP/hBNGX38UKVkSFn1/+SOJzBRjgbPNDok+S6dB6LWOaPwoix3pmUYsDOEacAIZ vG7iHR5UUGfprOcd15ZGTwAGFk4wzxUMlv6x7aL3luZ+2pS6kjDWPrOVQHPBmIDr TTnh90mtNy0U3toPfg120tZvMSryf6aXoM2JAMAssiqLi4y37X8KLl9tiT34s2tb pjDwlSRmFHhUrgLlWej1GYz7CNTf265UWXRpCO3RkC6CAvyZ0QRL9k+9qiFEXYg= =vEgX -----END PGP SIGNATURE----- From hrupp at redhat.com Mon Jun 1 04:04:53 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 01 Jun 2015 10:04:53 +0200 Subject: [Hawkular-dev] Release instructions In-Reply-To: <556C10CC.70807@redhat.com> References: <75DF4A22-7881-4DAD-9A54-ECF8F4B68C06@redhat.com> <556C10CC.70807@redhat.com> Message-ID: On 1 Jun 2015, at 9:59, Juraci Paix?o Kr?hling wrote: > Being tracked here: https://issues.jboss.org/browse/HAWKULAR-287 > having a "-Prelease". I agree that -Prelease is much better than what I wrote before. From theute at redhat.com Mon Jun 1 04:16:19 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 01 Jun 2015 10:16:19 +0200 Subject: [Hawkular-dev] Release instructions In-Reply-To: References: <75DF4A22-7881-4DAD-9A54-ECF8F4B68C06@redhat.com> <556C10CC.70807@redhat.com> Message-ID: <556C14D3.5090509@redhat.com> Additionally I *think* it should be added to the release plugin to avoid issues where we forget to specify the profile: release http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html and +1 on -Prelease, it's the "industry standard" I think Thomas On 06/01/2015 10:04 AM, Heiko W.Rupp wrote: > On 1 Jun 2015, at 9:59, Juraci Paix?o Kr?hling wrote: > >> Being tracked here: https://issues.jboss.org/browse/HAWKULAR-287 > >> having a "-Prelease". > > I agree that -Prelease is much better than what I wrote before. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Jun 1 04:39:13 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 01 Jun 2015 10:39:13 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: References: Message-ID: <556C1A31.9060907@redhat.com> Great to see progress ! One thing that I haven't seen which can have a direct impact, is to display the push messages: http://www.hawkular.org/blog/2015/04/09/alert-notifiers-for-mobile-devices.html Displaying the notification and opening a screen with detail of an alert would be good. Looking at: https://cloud.githubusercontent.com/assets/200401/7881453/bc1d1866-060b-11e5-81bc-b6662d344952.png I have few comments: - I am not sure about the authentication flow, user should first authenticate and then somewhere in the interface he should be able to switch tenant (*if* he has several). I guess a good place would be the top entry of the side menu. - Environment can be ignored for now, it won't be in the admin console for a while. In the end, I think you could end up with a single screen, with server Host+Port, login name and Password. - I don't think we need the metric table, graph are way more useful. - Resources at the moment are URLs or Servers. You would need to list them. Thanks again ! Thomas On 06/01/2015 07:39 AM, Artur Dryomov wrote: > Hi everyone, > > This year I am working on the Hawkular Android application as part of > the Google Summer of Code 2015 program. > > The last week I spent of familiarization with the project and its key > terms. With the help of public Hawkular servers, the Docker image and > snapshots I looked at the API and experimented a bit to understand how > things actually work. As a result I?ve created a wiki page [1] with the > brief overview of key Hawkular terms. In the process I?ve opened a very > first Hawkular issue regarding Docker image [2]. As a result of better > understanding what is what I?ve created a very rough mockup of the UI > [3] which I?ve also sent to the design team. Hopefully after a review of > functions and design I can proceed with the development itself. There is > some source code already [4] but mostly it is just a basic project > structure, it is almost useless to the end user at this point. > > I would like to start the development process this week. Of course it > will require a better understanding of what actually should be done ? > I?ve tried to clarify this with creating the mockup. I think a basic > authentication plus resources fetching is a good bet to work on even > without clear requirements, so it can be started right away. Probably I > should prepare a script to fill a Hawkular instance with some sample > information ? in Python or just plain cURL. If anyone has something like > that ? that will be a great help. I was advised to look at the test > scenario [5] as a departure point but maybe someone of you have a > similar thing locally. > > Regards, > Artur. > > [1]: https://github.com/hawkular/android-client/wiki/Overview > [2]: https://issues.jboss.org/browse/HAWKULAR-268 > [3]: https://github.com/hawkular/android-client/wiki/Design > [4]: https://github.com/hawkular/android-client > [5]: > https://github.com/hawkular/hawkular/blob/65f2573987890b1ffd4460e3449fb02b348816ea/modules/end-to-end-test/src/test/groovy/org/hawkular/integration/test/Scenario1ITest.groovy > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Mon Jun 1 09:26:20 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 01 Jun 2015 15:26:20 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? Message-ID: <556C5D7C.2090101@redhat.com> Hi *, I see it as a good occasion to remove the JBoss snapshots repository [1] from hawkular-parent, once all version.org.hawkular.* props [2] become "-SNAPSHOT"-less in hawkular master. Is there anybody against this? Thanks, Peter [1] https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 From tsegismo at redhat.com Mon Jun 1 09:43:40 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 01 Jun 2015 15:43:40 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <556C5D7C.2090101@redhat.com> References: <556C5D7C.2090101@redhat.com> Message-ID: <556C618C.5040200@redhat.com> But then we won't be able to work with a component SNAPSHOT unless we built it, correct? In this case, I'm not sure I like the idea. Le 01/06/2015 15:26, Peter Palaga a ?crit : > Hi *, > > I see it as a good occasion to remove the JBoss snapshots repository [1] > from hawkular-parent, once all version.org.hawkular.* props [2] become > "-SNAPSHOT"-less in hawkular master. > > Is there anybody against this? > > Thanks, > > Peter > > [1] > https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 > > [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Mon Jun 1 09:46:04 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 1 Jun 2015 09:46:04 -0400 (EDT) Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <556C5D7C.2090101@redhat.com> References: <556C5D7C.2090101@redhat.com> Message-ID: <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> I am not sure, but this could trigger again about where to place integration tests for a components. At the moment, we have a balance for limited-integration tests for a component: - In alerts we have an optional profile, that downloads hawkular-dist, assemble component-snapshot to test, and run limited REST tests. - If we move these tests to hawkular, then we need to release, before to test, what I don't see it's a benefit. So, I would not remove yet the snapshot, until we can discuss this from all the angles after the MVP. My 2 cents. Thx, Lucas ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Monday, June 1, 2015 3:26:20 PM > Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? > > Hi *, > > I see it as a good occasion to remove the JBoss snapshots repository [1] > from hawkular-parent, once all version.org.hawkular.* props [2] become > "-SNAPSHOT"-less in hawkular master. > > Is there anybody against this? > > Thanks, > > Peter > > [1] > https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 > > [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Mon Jun 1 10:23:59 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 01 Jun 2015 16:23:59 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <556C618C.5040200@redhat.com> References: <556C5D7C.2090101@redhat.com> <556C618C.5040200@redhat.com> Message-ID: <556C6AFF.8040005@redhat.com> On 2015-06-01 15:43, Thomas Segismont wrote: > But then we won't be able to work with a component SNAPSHOT unless we > built it, correct? Yes, that is the option I prefer myself. But there is a couple of intermediate options: * you add the snapshots repo in your settings.xml * we keep snapshots in hawkular-parent in a dedicated "snapshots" profile that will be off by default -- P > In this case, I'm not sure I like the idea. > > Le 01/06/2015 15:26, Peter Palaga a ?crit : >> Hi *, >> >> I see it as a good occasion to remove the JBoss snapshots repository [1] >> from hawkular-parent, once all version.org.hawkular.* props [2] become >> "-SNAPSHOT"-less in hawkular master. >> >> Is there anybody against this? >> >> Thanks, >> >> Peter >> >> [1] >> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >> >> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >> _______________________________________________ >> 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 Mon Jun 1 10:34:03 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 01 Jun 2015 16:34:03 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> References: <556C5D7C.2090101@redhat.com> <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> Message-ID: <556C6D5B.4080402@redhat.com> Hi Lucas, I can see the problem, but would not adding the snapshots repo to your integration test profile solve the problem? -- P On 2015-06-01 15:46, Lucas Ponce wrote: > I am not sure, but this could trigger again about where to place integration tests for a components. > > At the moment, we have a balance for limited-integration tests for a component: > > - In alerts we have an optional profile, that downloads hawkular-dist, assemble component-snapshot to test, and run limited REST tests. > > - If we move these tests to hawkular, then we need to release, before to test, what I don't see it's a benefit. > > So, I would not remove yet the snapshot, until we can discuss this from all the angles after the MVP. > > My 2 cents. > > Thx, > Lucas > > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Monday, June 1, 2015 3:26:20 PM >> Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? >> >> Hi *, >> >> I see it as a good occasion to remove the JBoss snapshots repository [1] >> from hawkular-parent, once all version.org.hawkular.* props [2] become >> "-SNAPSHOT"-less in hawkular master. >> >> Is there anybody against this? >> >> Thanks, >> >> Peter >> >> [1] >> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >> >> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Mon Jun 1 10:35:03 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 1 Jun 2015 10:35:03 -0400 (EDT) Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <556C6AFF.8040005@redhat.com> References: <556C5D7C.2090101@redhat.com> <556C618C.5040200@redhat.com> <556C6AFF.8040005@redhat.com> Message-ID: <423548960.8572904.1433169303184.JavaMail.zimbra@redhat.com> I like not having my settings.xml messed up with project-specific settings. I like Peter's suggestion of: * we keep snapshots in hawkular-parent in a dedicated "snapshots" profile that will be off by default If you want to pull down a snapshot, you have to explicitly ask for it with something (-Psnapshots or whatever). You can put THAT in your settings.xml if you want it, but at least it won't be required. ----- Original Message ----- > On 2015-06-01 15:43, Thomas Segismont wrote: > > But then we won't be able to work with a component SNAPSHOT unless we > > built it, correct? > > Yes, that is the option I prefer myself. > > But there is a couple of intermediate options: > > * you add the snapshots repo in your settings.xml > * we keep snapshots in hawkular-parent in a dedicated "snapshots" > profile that will be off by default > > -- P > > > In this case, I'm not sure I like the idea. > > > > Le 01/06/2015 15:26, Peter Palaga a ?crit : > >> Hi *, > >> > >> I see it as a good occasion to remove the JBoss snapshots repository [1] > >> from hawkular-parent, once all version.org.hawkular.* props [2] become > >> "-SNAPSHOT"-less in hawkular master. > >> > >> Is there anybody against this? > >> > >> Thanks, > >> > >> Peter > >> > >> [1] > >> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 > >> > >> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 > >> _______________________________________________ > >> 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 Mon Jun 1 11:09:24 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 01 Jun 2015 17:09:24 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <423548960.8572904.1433169303184.JavaMail.zimbra@redhat.com> References: <556C5D7C.2090101@redhat.com> <556C618C.5040200@redhat.com> <556C6AFF.8040005@redhat.com> <423548960.8572904.1433169303184.JavaMail.zimbra@redhat.com> Message-ID: <556C75A4.5040705@redhat.com> Sounds good Le 01/06/2015 16:35, John Mazzitelli a ?crit : > I like not having my settings.xml messed up with project-specific settings. > > I like Peter's suggestion of: > > * we keep snapshots in hawkular-parent in a dedicated "snapshots" profile that will be off by default > > If you want to pull down a snapshot, you have to explicitly ask for it with something (-Psnapshots or whatever). > > You can put THAT in your settings.xml if you want it, but at least it won't be required. > > ----- Original Message ----- >> On 2015-06-01 15:43, Thomas Segismont wrote: >>> But then we won't be able to work with a component SNAPSHOT unless we >>> built it, correct? >> >> Yes, that is the option I prefer myself. >> >> But there is a couple of intermediate options: >> >> * you add the snapshots repo in your settings.xml >> * we keep snapshots in hawkular-parent in a dedicated "snapshots" >> profile that will be off by default >> >> -- P >> >>> In this case, I'm not sure I like the idea. >>> >>> Le 01/06/2015 15:26, Peter Palaga a ?crit : >>>> Hi *, >>>> >>>> I see it as a good occasion to remove the JBoss snapshots repository [1] >>>> from hawkular-parent, once all version.org.hawkular.* props [2] become >>>> "-SNAPSHOT"-less in hawkular master. >>>> >>>> Is there anybody against this? >>>> >>>> Thanks, >>>> >>>> Peter >>>> >>>> [1] >>>> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >>>> >>>> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Mon Jun 1 11:10:14 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 01 Jun 2015 11:10:14 -0400 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? In-Reply-To: <423548960.8572904.1433169303184.JavaMail.zimbra@redhat.com> References: <556C5D7C.2090101@redhat.com> <556C618C.5040200@redhat.com> <556C6AFF.8040005@redhat.com> <423548960.8572904.1433169303184.JavaMail.zimbra@redhat.com> Message-ID: <556C75D6.3000706@redhat.com> +1, the profile is a good idea but I think we should hold off on any infrastructure changes until after the M1 deadline. It's just a few days more and I don't think we can afford even minor delays due to infra confusion. On 6/1/2015 10:35 AM, John Mazzitelli wrote: > I like not having my settings.xml messed up with project-specific settings. > > I like Peter's suggestion of: > > * we keep snapshots in hawkular-parent in a dedicated "snapshots" profile that will be off by default > > If you want to pull down a snapshot, you have to explicitly ask for it with something (-Psnapshots or whatever). > > You can put THAT in your settings.xml if you want it, but at least it won't be required. > > ----- Original Message ----- >> On 2015-06-01 15:43, Thomas Segismont wrote: >>> But then we won't be able to work with a component SNAPSHOT unless we >>> built it, correct? >> Yes, that is the option I prefer myself. >> >> But there is a couple of intermediate options: >> >> * you add the snapshots repo in your settings.xml >> * we keep snapshots in hawkular-parent in a dedicated "snapshots" >> profile that will be off by default >> >> -- P >> >>> In this case, I'm not sure I like the idea. >>> >>> Le 01/06/2015 15:26, Peter Palaga a ?crit : >>>> Hi *, >>>> >>>> I see it as a good occasion to remove the JBoss snapshots repository [1] >>>> from hawkular-parent, once all version.org.hawkular.* props [2] become >>>> "-SNAPSHOT"-less in hawkular master. >>>> >>>> Is there anybody against this? >>>> >>>> Thanks, >>>> >>>> Peter >>>> >>>> [1] >>>> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >>>> >>>> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >>>> _______________________________________________ >>>> 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/20150601/95529a99/attachment.html From theute at redhat.com Mon Jun 1 14:35:07 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 01 Jun 2015 20:35:07 +0200 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? --> Integration tests In-Reply-To: <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> References: <556C5D7C.2090101@redhat.com> <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> Message-ID: <556CA5DB.80202@redhat.com> This is a different debate than SNAPSHOT repo in/out the parent, but this is IMO important: On 06/01/2015 03:46 PM, Lucas Ponce wrote: > I am not sure, but this could trigger again about where to place integration tests for a components. > > At the moment, we have a balance for limited-integration tests for a component: > > - In alerts we have an optional profile, that downloads hawkular-dist, assemble component-snapshot to test, and run limited REST tests. As I said, this is incorrect, you shouldn't create such dependency circles even for tests. And as a matter of fact Alerts has tagged releases with dependencies on a SNAPSHOT https://github.com/hawkular/hawkular-alerts/blob/0.0.4/pom.xml The release plugin should have complained. The only certitude is that *at the point of the release* the tests passed, Hawkular may still change and by the time Hawkular is released with that version of Alerts it may fail the same integration tests -> Bad > - If we move these tests to hawkular, then we need to release, before to test, what I don't see it's a benefit. This is the minimum you can do to have a proper release: 1 - release alerts, make sure they pass the unit tests 2 - upgrade hawkular to use that version of alerts 3 - release hawkular with the integration tests, if they fail at this point you may need to re-release alerts but at least you know for sure that the integration tests passed when you did the release. There are several improvements that can be made that are more or less costly to avoid "wrong" release of components: - Before you tag alerts, I would recommend that you test Hawkular with a locally built SNAPSHOT of Alerts, that reduce the risk of a re-release of alerts - Do release:perform of the components and don't close on Nexus, upgrade hawkular to use the new tagged version (and add the staging repo in your local settings.xml) test, release Hawkular and close/publish all the Nexus repo "at once". (I think you can even do the release:prepare and not push the tag so that you can freely retag until the tests pass, and when you push the binaries you can also push the sources tags). > > So, I would not remove yet the snapshot, until we can discuss this from all the angles after the MVP. > > My 2 cents. > > Thx, > Lucas > > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Monday, June 1, 2015 3:26:20 PM >> Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? >> >> Hi *, >> >> I see it as a good occasion to remove the JBoss snapshots repository [1] >> from hawkular-parent, once all version.org.hawkular.* props [2] become >> "-SNAPSHOT"-less in hawkular master. >> >> Is there anybody against this? >> >> Thanks, >> >> Peter >> >> [1] >> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >> >> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Mon Jun 1 18:06:20 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 01 Jun 2015 18:06:20 -0400 Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? --> Integration tests In-Reply-To: <556CA5DB.80202@redhat.com> References: <556C5D7C.2090101@redhat.com> <932329126.8529794.1433166364178.JavaMail.zimbra@redhat.com> <556CA5DB.80202@redhat.com> Message-ID: <556CD75C.3080305@redhat.com> On 6/1/2015 2:35 PM, Thomas Heute wrote: > This is a different debate than SNAPSHOT repo in/out the parent, but > this is IMO important: > > On 06/01/2015 03:46 PM, Lucas Ponce wrote: >> I am not sure, but this could trigger again about where to place integration tests for a components. >> >> At the moment, we have a balance for limited-integration tests for a component: >> >> - In alerts we have an optional profile, that downloads hawkular-dist, assemble component-snapshot to test, and run limited REST tests. > As I said, this is incorrect, you shouldn't create such dependency > circles even for tests. > > And as a matter of fact Alerts has tagged releases with dependencies on > a SNAPSHOT > https://github.com/hawkular/hawkular-alerts/blob/0.0.4/pom.xml > The release plugin should have complained. We're aware that this isn't optimal. The release plugin does not fail because the dependency is in a profile that is only active for rest api integration tests. We could not depend on a versioned release of hawkular dist because it doesn't exist, in fact it depends on a versioned release of hawkular-alerts so the circular aspect made it impossible. These rest api integration tests are actually component-level i-tests imo, and the integration aspect is only that of a running container for alert's rest API, and Hawkular dist suffices as it provides the Cassandra and Hawkular Accounts hooks. I do agree that higher-level integration tests, hawkular-level, should not live in the component's repo. As it stands, we don't have that level of itest. > The only certitude is that *at the point of the release* the tests > passed, Hawkular may still change and by the time Hawkular is released > with that version of Alerts it may fail the same integration tests -> Bad Not really, because in this case it doesn't so much depend on hawkular but rather the components already in dist. But I do see your point in general. > >> - If we move these tests to hawkular, then we need to release, before to test, what I don't see it's a benefit. > This is the minimum you can do to have a proper release: > 1 - release alerts, make sure they pass the unit tests > 2 - upgrade hawkular to use that version of alerts > 3 - release hawkular with the integration tests, if they fail at this > point you may need to re-release alerts but at least you know for sure > that the integration tests passed when you did the release. It's still feasible to move alerts' current rest api tests to hawkular, but even if this is required, the timing was not good to make such a change. > > There are several improvements that can be made that are more or less > costly to avoid "wrong" release of components: > > - Before you tag alerts, I would recommend that you test Hawkular with > a locally built SNAPSHOT of Alerts, that reduce the risk of a re-release > of alerts Sure. As it stands the integration of versioned alerts into hawkular went pretty smoothly. The only respin was due to the accounts packaging issues that surfaced, which was a more general issue. > - Do release:perform of the components and don't close on Nexus, > upgrade hawkular to use the new tagged version (and add the staging repo > in your local settings.xml) test, release Hawkular and close/publish all > the Nexus repo "at once". (I think you can even do the release:prepare > and not push the tag so that you can freely retag until the tests pass, > and when you push the binaries you can also push the sources tags) > > > >> So, I would not remove yet the snapshot, until we can discuss this from all the angles after the MVP. >> >> My 2 cents. >> >> Thx, >> Lucas >> >> >> >> ----- Original Message ----- >>> From: "Peter Palaga" >>> To: "Discussions around Hawkular development" >>> Sent: Monday, June 1, 2015 3:26:20 PM >>> Subject: [Hawkular-dev] When to remove snapshots maven repo from parent? >>> >>> Hi *, >>> >>> I see it as a good occasion to remove the JBoss snapshots repository [1] >>> from hawkular-parent, once all version.org.hawkular.* props [2] become >>> "-SNAPSHOT"-less in hawkular master. >>> >>> Is there anybody against this? >>> >>> Thanks, >>> >>> Peter >>> >>> [1] >>> https://github.com/hawkular/hawkular-parent-pom/blob/b4daf82bd3b9d98c34fcd871cef3a0783b8c29de/pom.xml#L773-L783 >>> >>> [2] https://github.com/hawkular/hawkular/blob/master/pom.xml#L87-L96 >>> _______________________________________________ >>> 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 artur.dryomov at gmail.com Tue Jun 2 02:25:57 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 2 Jun 2015 09:25:57 +0300 Subject: [Hawkular-dev] OAuth Documentation In-Reply-To: <556C0677.6000803@redhat.com> References: <556C0677.6000803@redhat.com> Message-ID: Just a note to self and anyone who will have the same issue. It seems like only relative to server address redirect URLs are supported via default Hawkular configuration [1]. I. e. OAuth redirect to " http://localhost/oauth-callback" will not work, only " http://hawkular-server-address.link/oauth-callback" will do the trick. I was confused for a while because all AeroGear examples set it to " http://localhost" and that?s it. [1]: https://github.com/hawkular/hawkular-accounts/blob/70e6db131368248d0e586f9b28b7a4eb71a18b64/dist/src/main/resources/standalone/configuration/hawkular-realm.json#L98 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150602/1ffdedc3/attachment-0001.html From artur.dryomov at gmail.com Tue Jun 2 02:35:36 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 2 Jun 2015 09:35:36 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: <556C1A31.9060907@redhat.com> References: <556C1A31.9060907@redhat.com> Message-ID: Hi Thomas, > Displaying the notification and opening a screen with detail of an alert > would be good. > Yep, it will be there. > I am not sure about the authentication flow, user should first > authenticate and then somewhere in the interface he should be able to > switch tenant (*if* he has several). I guess a good place would be the > top entry of the side menu. > Sorry for not making it clear ? it will be done almost exactly as you are saying. User will be available to add multiple servers and tenants. It will be done via the same flow. There is a spinner at the top of the drawer menu which will allow to select the necessary one. Basically it will be very similar to Google Mail and Google Play apps. > Environment can be ignored for now, it won't be in the admin console > for a while. In the end, I think you could end up with a single screen, > with server Host+Port, login name and Password. > Actually I already switched to OAuth, so there will be host input, port input, tenants spinner and "Authorize" button. > I don't think we need the metric table, graph are way more useful. > Not everything can be presented via a graph ? HTTP status codes for example. > Resources at the moment are URLs or Servers. You would need to list > them. > It is already in the mockup ? the resources screen just below the screen with a drawer. If I understood you correctly of course. Thanks! Artur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150602/47c3adfe/attachment.html From jkremser at redhat.com Tue Jun 2 07:03:41 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Tue, 2 Jun 2015 07:03:41 -0400 (EDT) Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: References: Message-ID: <1455832543.7683782.1433243021154.JavaMail.zimbra@redhat.com> | Probably I should prepare a | script to fill a Hawkular instance with some sample information ? in Python | or just plain cURL. If anyone has something like that ? that will be a great | help. I was advised to look at the test scenario [5] as a departure point | but maybe someone of you have a similar thing locally. Hi, here are some curls I use: https://gist.github.com/Jiri-Kremser/8db9087086541358f227 If you want to know what is happening when you click on `Add Url` in UI you can look here: https://github.com/hawkular/hawkular/blob/46fefefed1c3e232147d61ad1a4fc906e737a295/ui/console/src/main/scripts/plugins/metrics/plugins/metrics/ts/addUrlPage.ts#L86:L171 Since inventory 0.0.4 (I think) it's not necessary to create a tenant, environment and resource type with metric types. It's good for looking at the flow the actual rest calls used there are defined in the separate repo here: https://github.com/hawkular/hawkular-ui-services/tree/master/src/rest Currently, there is no need to create a tenant or environment, the tenant is inferred and created from the auth used with the REST request and it's the same as the persona uuid, environment defaults to `test` and we also pre-create 1 resource type called `URL` with 2 metric types. If interested, the code is here: https://github.com/hawkular/hawkular-inventory/blob/11109543f4204870233967124b579cd1aaab27fb/hawkular-integrated-inventory-rest/src/main/java/org/hawkular/integrated/inventory/TemporaryHacks.java#L57 You probably know about the REST docs http://www.hawkular.org/docs/rest/rest-{metrics|inventory|alerts|btm}.html jk From jkremser at redhat.com Tue Jun 2 07:53:28 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Tue, 2 Jun 2015 07:53:28 -0400 (EDT) Subject: [Hawkular-dev] On the way to the M1 release ... In-Reply-To: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> References: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> Message-ID: <1443978534.7711282.1433246008712.JavaMail.zimbra@redhat.com> update: HAWKULAR-255 - resolved HWKINVENT-45 - resolved (UI deletes the metrics before the resource) | > Hey, | > | > I see those things that need (at least) to be done/fixed for the next | > Wed release: | > | > - pinger does not respond to deletions (HAWKULAR-235/-263) | In master now | | - pinger is hardcoded to send to localhost -> Peter working on it. | HAWKULAR-106 | | > - inventory does not delete metrics on resource deletion HWKINVENT-45 | > (if INV can not make it, can UI send the delete metrics requests ?) | > - duplicate URL addition HAWKULAR-255 | > - alerts is not multi-tenant yet (PR is sent, but may be too | > disruptive | > ?) HWKALERTS-40 | > -- Add url fails across tenants for same url (HAWKULAR-277 contains a | > possible solution) | | > -- marking alerts as resolved (needs above PR for the backend) | ==> probably too much work on UI side => add checkboxes for | "resolved" | | > - working pagination | ==> HAWKULAR-247 is meant and now marked as resolved | | > - working availability charts | > | > - move everything on non-snapshot releases | > - update / write documentation on hawkular.org | > | | > As we will most probably not have full app servers functionality, | > we should disable that tab so that users are not confused by it | > and re-enable and work on it after the release. | > Similar for the embedded agent. | | We will decide that on monday. | | > | > Can we please concentrate on the above (and what else is needed that | > is | > not yet on the list) to get | > the release out? | > _______________________________________________ | > hawkular-dev mailing list | > hawkular-dev at lists.jboss.org | > https://lists.jboss.org/mailman/listinfo/hawkular-dev | _______________________________________________ | hawkular-dev mailing list | hawkular-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/hawkular-dev | From jkremser at redhat.com Tue Jun 2 07:54:21 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Tue, 2 Jun 2015 07:54:21 -0400 (EDT) Subject: [Hawkular-dev] On the way to the M1 release ... In-Reply-To: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> References: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> Message-ID: <2117985592.7711361.1433246061934.JavaMail.zimbra@redhat.com> oh and HAWKULAR-277 is done too sry for spam ----- Original Message ----- | From: "Heiko W.Rupp" | To: "Discussions around Hawkular development" | Sent: Thursday, 28 May, 2015 4:58:54 PM | Subject: Re: [Hawkular-dev] On the way to the M1 release ... | | Small update | | On 28 May 2015, at 13:09, Heiko W.Rupp wrote: | | > Hey, | > | > I see those things that need (at least) to be done/fixed for the next | > Wed release: | > | > - pinger does not respond to deletions (HAWKULAR-235/-263) | In master now | | - pinger is hardcoded to send to localhost -> Peter working on it. | HAWKULAR-106 | | > - inventory does not delete metrics on resource deletion HWKINVENT-45 | > (if INV can not make it, can UI send the delete metrics requests ?) | > - duplicate URL addition HAWKULAR-255 | > - alerts is not multi-tenant yet (PR is sent, but may be too | > disruptive | > ?) HWKALERTS-40 | > -- Add url fails across tenants for same url (HAWKULAR-277 contains a | > possible solution) | | > -- marking alerts as resolved (needs above PR for the backend) | ==> probably too much work on UI side => add checkboxes for | "resolved" | | > - working pagination | ==> HAWKULAR-247 is meant and now marked as resolved | | > - working availability charts | > | > - move everything on non-snapshot releases | > - update / write documentation on hawkular.org | > | | > As we will most probably not have full app servers functionality, | > we should disable that tab so that users are not confused by it | > and re-enable and work on it after the release. | > Similar for the embedded agent. | | We will decide that on monday. | | > | > Can we please concentrate on the above (and what else is needed that | > is | > not yet on the list) to get | > the release out? | > _______________________________________________ | > hawkular-dev mailing list | > hawkular-dev at lists.jboss.org | > https://lists.jboss.org/mailman/listinfo/hawkular-dev | _______________________________________________ | hawkular-dev mailing list | hawkular-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/hawkular-dev | From artur.dryomov at gmail.com Tue Jun 2 08:07:14 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 2 Jun 2015 15:07:14 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: <1455832543.7683782.1433243021154.JavaMail.zimbra@redhat.com> References: <1455832543.7683782.1433243021154.JavaMail.zimbra@redhat.com> Message-ID: Hey Jiri, That?s a lot of links! In a good way of course. Thank you, I?ll read it through, looks very useful. Artur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150602/1505ffd5/attachment.html From hrupp at redhat.com Tue Jun 2 08:49:53 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 02 Jun 2015 14:49:53 +0200 Subject: [Hawkular-dev] On the way to the M1 release ... In-Reply-To: <1443978534.7711282.1433246008712.JavaMail.zimbra@redhat.com> References: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> <1443978534.7711282.1433246008712.JavaMail.zimbra@redhat.com> Message-ID: Hi, for the release, Stefan will do all the Maven-magic. Please make sure he has what he needs. It is important to make sure we do not have -SNAPSHOTS in it. So try to do a release of your component by *today EOB* latest. Looking at the hawkular-pom, the last (and biggest reminder) is Metrics - Peter takes care for Pinger, AvailCreator and e2e test to lift to 0.3.4 - Rumors say that work on UI to lift to 0.3.4 is too heavy - We currently run against 0.3.2-SNAPSHOT. The build is from April 22nd and can be identified incl. --> we could tag/branch and release 0.3.2 from here, to use it with M1 and then switch over to 0.3.4 afterwards. Release version will be 1.0.0-Alpha1 For the UI side we will support URLs and also App Server list, but no details (so link needs to be disabled). Avail data point computation seem wrong: https://issues.jboss.org/browse/HAWKULAR-295, a possible fix is available. On 2 Jun 2015, at 13:53, Jiri Kremser wrote: > update: > HAWKULAR-255 - resolved > HWKINVENT-45 - resolved (UI deletes the metrics before the resource) Very good. > > > > | > Hey, > | > > | > I see those things that need (at least) to be done/fixed for the > next > | > Wed release: > | > > | > - pinger does not respond to deletions (HAWKULAR-235/-263) > | In master now > | > | - pinger is hardcoded to send to localhost -> Peter working on it. > | HAWKULAR-106 > | > | > - inventory does not delete metrics on resource deletion > HWKINVENT-45 > | > (if INV can not make it, can UI send the delete metrics requests > ?) > | > - duplicate URL addition HAWKULAR-255 > | > - alerts is not multi-tenant yet (PR is sent, but may be too > | > disruptive > | > ?) HWKALERTS-40 > | > -- Add url fails across tenants for same url (HAWKULAR-277 > contains a > | > possible solution) > | > | > -- marking alerts as resolved (needs above PR for the backend) > | ==> probably too much work on UI side => add checkboxes for > | "resolved" > | > | > - working pagination > | ==> HAWKULAR-247 is meant and now marked as resolved > | > | > - working availability charts > | > > | > - move everything on non-snapshot releases > | > - update / write documentation on hawkular.org > | > > | > | > As we will most probably not have full app servers functionality, > | > we should disable that tab so that users are not confused by it > | > and re-enable and work on it after the release. > | > Similar for the embedded agent. > | > | We will decide that on monday. > | > | > > | > Can we please concentrate on the above (and what else is needed > that > | > is > | > not yet on the list) to get > | > the release out? > | > _______________________________________________ > | > hawkular-dev mailing list > | > hawkular-dev at lists.jboss.org > | > https://lists.jboss.org/mailman/listinfo/hawkular-dev > | _______________________________________________ > | hawkular-dev mailing list > | hawkular-dev at lists.jboss.org > | https://lists.jboss.org/mailman/listinfo/hawkular-dev > | > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From theute at redhat.com Tue Jun 2 09:03:48 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 02 Jun 2015 15:03:48 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: References: <556C1A31.9060907@redhat.com> Message-ID: <556DA9B4.9010103@redhat.com> On 06/02/2015 08:35 AM, Artur Dryomov wrote: > Hi Thomas, > > Displaying the notification and opening a screen with detail of an alert > would be good. > > > Yep, it will be there. Nice > > I am not sure about the authentication flow, user should first > authenticate and then somewhere in the interface he should be able to > switch tenant (*if* he has several). I guess a good place would be the > top entry of the side menu. > > > Sorry for not making it clear ? it will be done almost exactly as you > are saying. User will be available to add multiple servers and tenants. > It will be done via the same flow. There is a spinner at the top of the > drawer menu which will allow to select the necessary one. Basically it > will be very similar to Google Mail and Google Play apps. Ok > > Environment can be ignored for now, it won't be in the admin console > for a while. In the end, I think you could end up with a single screen, > with server Host+Port, login name and Password. > > > Actually I already switched to OAuth, so there will be host input, port > input, tenants spinner and "Authorize" button. Ok > > I don't think we need the metric table, graph are way more useful. > > > Not everything can be presented via a graph ? HTTP status codes for example. Do we need that ? For the admin console we actually translate codes into Up/Down and just show this. > > Resources at the moment are URLs or Servers. You would need to list > them. > > > It is already in the mockup ? the resources screen just below the screen > with a drawer. If I understood you correctly of course. There you will list all URLs/Servers ? (I thought it was a name of a category in the mockup) Thomas > > Thanks! > Artur. > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Tue Jun 2 16:51:45 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 2 Jun 2015 23:51:45 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report In-Reply-To: <556DA9B4.9010103@redhat.com> References: <556C1A31.9060907@redhat.com> <556DA9B4.9010103@redhat.com> Message-ID: > > Do we need that ? For the admin console we actually translate codes into > Up/Down and just show this. > Well, that?s even better. Not sure how it will work from the API side, but good to know. > There you will list all URLs/Servers ? (I thought it was a name of a > category in the mockup) > As I saw it. Resource Types (URL, Server, etc.) ? Metrics (status code, status duration) ? Metric (status duration table / graph for example). But you gave me an idea to take a look at my Overview document [1] again. I?ll need to display not only resource types, but resources themselves, so good catch! Probably it can be done via another screen but it is getting too many of them. Maybe I should display resources as list sections and resources as a primary list contents. This is getting tricky, I don?t like the idea of deep screen hierarchy :-? [1]: https://github.com/hawkular/android-client/wiki/Overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150602/bab53d6d/attachment.html From mithomps at redhat.com Tue Jun 2 21:31:46 2015 From: mithomps at redhat.com (mike thompson) Date: Tue, 2 Jun 2015 18:31:46 -0700 Subject: [Hawkular-dev] Hawkular Accounts admin help Message-ID: Are there any admins for Hawkular accounts that can commit the latest Hawkular Logo updates. Gabriel has added the Hawkular logos to the login screen via: https://github.com/hawkular/hawkular-accounts/pull/31 It would be great to have some kind of Hawkular Logos in the M1 release (or else we won?t have any). ?Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150602/b9800f8d/attachment.html From snegrea at redhat.com Tue Jun 2 21:57:42 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 2 Jun 2015 21:57:42 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Accounts admin help In-Reply-To: References: Message-ID: <700714739.7685921.1433296662873.JavaMail.zimbra@redhat.com> Hello, PR merged. Thank you, Stefan ----- Original Message ----- > From: "mike thompson" > To: "Discussions around Hawkular development" > Sent: Tuesday, June 2, 2015 8:31:46 PM > Subject: [Hawkular-dev] Hawkular Accounts admin help > > Are there any admins for Hawkular accounts that can commit the latest > Hawkular Logo updates. > > Gabriel has added the Hawkular logos to the login screen via: > > https://github.com/hawkular/hawkular-accounts/pull/31 > > > It would be great to have some kind of Hawkular Logos in the M1 release (or > else we won?t have any). > > ?Mike > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 3 02:35:50 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 03 Jun 2015 08:35:50 +0200 Subject: [Hawkular-dev] Hawkular Accounts admin help In-Reply-To: References: Message-ID: <556EA046.5050700@redhat.com> We would need to re-release Account (and to be fully proper, release components that depend on it). It's ok without the logo, let's keep the ball rolling. Thomas On 06/03/2015 03:31 AM, mike thompson wrote: > Are there any admins for Hawkular accounts that can commit the latest > Hawkular Logo updates. > > Gabriel has added the Hawkular logos to the login screen via: > > https://github.com/hawkular/hawkular-accounts/pull/31 > > > It would be great to have some kind of Hawkular Logos in the M1 release > (or else we won?t have any). > > ?Mike > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 3 11:07:21 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 03 Jun 2015 17:07:21 +0200 Subject: [Hawkular-dev] On the way to the M1 release ... In-Reply-To: References: <6A6A7AED-1BAB-41FD-A343-2BE85990653B@redhat.com> <1443978534.7711282.1433246008712.JavaMail.zimbra@redhat.com> Message-ID: <556F1829.50400@redhat.com> On 06/02/2015 02:49 PM, Heiko W.Rupp wrote: > Hi, > > for the release, Stefan will do all the Maven-magic. Please make sure he > has what he needs. > > > Release version will be 1.0.0-Alpha1 It's actually 1.0.0.Alpha1 https://developer.jboss.org/wiki/JBossProjectVersioning If anyone knows a blocker bug, please speak up now. There are 4 open PR on Hawkular itself at the time of writing, do we need any ? https://github.com/hawkular/hawkular/pulls Thomas From theute at redhat.com Wed Jun 3 16:05:58 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 03 Jun 2015 22:05:58 +0200 Subject: [Hawkular-dev] Hawkular 1.0.0.Alpha1: The first release ! Message-ID: <556F5E26.4060106@redhat.com> We have just uploaded our first release, this is a quick note to share the news and file locations, a blog post will follow tomorrow on http://www.hawkular.org/blog.html Anyway here are the URLs: http://download.jboss.org/hawkular/hawkular/1.0.0.Alpha1/hawkular-dist-1.0.0.Alpha1.tar.gz http://download.jboss.org/hawkular/hawkular/1.0.0.Alpha1/hawkular-dist-1.0.0.Alpha1.zip Congrats to the team, the goal is to do frequent releases, the next one is scheduled in 4 weeks, we have a lot of application server data that is collected but not exposed in the UI, expect to see some of that + some other new features. If you want to help there are plenty of tasks to choose from: https://issues.jboss.org/browse/HAWKULAR Thomas From ppalaga at redhat.com Thu Jun 4 05:49:34 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 04 Jun 2015 11:49:34 +0200 Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? Message-ID: <55701F2E.90202@redhat.com> Hi *, I am just improving the log output in Pinger and Availability Creator [1] and I found out that one can define a LogMessage containing all the details of a thrown exception (incl error message and stack trace) like this: @LogMessage(level = Logger.Level.ERROR) @Message(id = 5007, value = "Could not send a message to the bus") void eCouldNotSendMessage(@Cause Throwable e); Indeed, messages like this can be seen in Bus, Agent and Inventory, but nowhere else. Are there some reasons for *not* using this @Cause message style at all? It is clear that not every thrown exception needs to clutter the log with its stack trace. But generally, things that are supposed to work in all cases and situations (like sending messages to bus) should be logged incl. stack traces, should they not? Thanks, Peter [1] https://issues.jboss.org/browse/HAWKULAR-309 From aakaruce at iitr.ac.in Thu Jun 4 06:07:13 2015 From: aakaruce at iitr.ac.in (Aakarsh Agarwal) Date: Thu, 04 Jun 2015 15:37:13 +0530 Subject: [Hawkular-dev] Hawkular-pluggable data processors for metrics: Weekly Report In-Reply-To: <73a0a3423439.557021bc@iitr.ac.in> References: <72f0f0e01285.55701d70@iitr.ac.in> <7380db4053f2.55701dad@iitr.ac.in> <7300b95d4630.55701dea@iitr.ac.in> <73a0f7fb69a0.55701e29@iitr.ac.in> <72a0c48f295d.55701e67@iitr.ac.in> <72f0cd1840d9.55701ea3@iitr.ac.in> <7350c1ef4b04.55701ee0@iitr.ac.in> <730085bb69dd.55701f1d@iitr.ac.in> <730083f036ec.55701f5a@iitr.ac.in> <72b0fa512083.55701f97@iitr.ac.in> <7310805798d.55701fd5@iitr.ac.in> <72a0e6d37d3.55702014@iitr.ac.in> <7350aa7d1d65.55702051@iitr.ac.in> <73a0a3423439.557021bc@iitr.ac.in> Message-ID: <72b0fa2a2087.557070a9@iitr.ac.in> Hi all, I am currently working on the Hawkular Metrics repository as part of the Google Summer of Code 2015 program and this is to update the progress of my project. I spent the last week familiarizing myself with the existing Hawkular Metrics repo on github and some of its code. As of now, I have created a new git repo on my github profile which intends to implement a simple plugin interface using 5 basic statistical algorithms. These are - Minimum?of the entered data set. Maximum?of the entered data set. Average?of the entered data set. Mode?of the entered data set. Standard Deviation?of the entered data set. The link to this git repo is - https://github.com/Akki5/hawkular_plugin This is just initial draft for the interface to be implemented. Here, StatisticalAlgo.java is the interface and other named java classes are the classes implementing the interface. PluginDemo.java is the test class. At the moment, everything in the code is hardcoded and static in nature which will later be converted for dynamic usage. The next step requires following listed work to be done - Use maven to build the project. Use Classloader for all classes?implementing StatisticalAlgo. Require input from user as to which plugin is to be used. Regards, Aakarsh Agarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150604/f59dca57/attachment.html From ppalaga at redhat.com Thu Jun 4 08:49:41 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 04 Jun 2015 14:49:41 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? Message-ID: <55704965.5060208@redhat.com> Hi *, I hope I am not the only one who finds that there is a lot of uninteresting messages in the log which can be made hidden by default. I propose to add the following lines to standalone xml files for both dev and production profiles: Is this too much hiding or maybe somebody has even more candidates for suppressing? Thanks, Peter From mazz at redhat.com Thu Jun 4 08:51:07 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 4 Jun 2015 08:51:07 -0400 (EDT) Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? In-Reply-To: <55701F2E.90202@redhat.com> References: <55701F2E.90202@redhat.com> Message-ID: <1060808060.10665219.1433422267447.JavaMail.zimbra@redhat.com> The discussions we had a few months ago around using these logging annotations was that anything that is logged at INFO, WARN or ERROR level will be via this jboss logging annotation mechanism. TRACE or DEBUG we can just use logger debugf and tracef directly without putting the messages in those logger classes with the annotations. Of course, usually when you have a Throwable, you are logging at least at the WARN level, so yeah, use these annotations for that kind of thing (as a general rule). ----- Original Message ----- > Hi *, > > I am just improving the log output in Pinger and Availability Creator > [1] and I found out that one can define a LogMessage containing all the > details of a thrown exception (incl error message and stack trace) like > this: > > @LogMessage(level = Logger.Level.ERROR) > @Message(id = 5007, value = "Could not send a message to the bus") > void eCouldNotSendMessage(@Cause Throwable e); > > Indeed, messages like this can be seen in Bus, Agent and Inventory, but > nowhere else. > > Are there some reasons for *not* using this @Cause message style at all? > > It is clear that not every thrown exception needs to clutter the log > with its stack trace. But generally, things that are supposed to work in > all cases and situations (like sending messages to bus) should be logged > incl. stack traces, should they not? > > Thanks, > > Peter > > [1] https://issues.jboss.org/browse/HAWKULAR-309 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Thu Jun 4 08:53:09 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 4 Jun 2015 08:53:09 -0400 (EDT) Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <55704965.5060208@redhat.com> References: <55704965.5060208@redhat.com> Message-ID: <348639978.10666154.1433422389476.JavaMail.zimbra@redhat.com> I personally am OK with this. Though most of these are related to Hawkular-Metrics and I don't work much in that code base. So this is a question for the folks that develop Metrics - they might need to see those categories at INFO level. ----- Original Message ----- > Hi *, > > I hope I am not the only one who finds that there is a lot of > uninteresting messages in the log which can be made hidden by default. > > I propose to add the following lines to standalone xml files for both > dev and production profiles: > > > > > > > > > > > > > > > > > > Is this too much hiding or maybe somebody has even more candidates for > suppressing? > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From vrockai at redhat.com Thu Jun 4 08:56:04 2015 From: vrockai at redhat.com (Viliam Rockai) Date: Thu, 4 Jun 2015 08:56:04 -0400 (EDT) Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <55704965.5060208@redhat.com> References: <55704965.5060208@redhat.com> Message-ID: <831193501.10869934.1433422564296.JavaMail.zimbra@redhat.com> +1 on the log tidy-up. There's too much information in the log right now and important warnings/errors could be easily "lost" in the debug debris. ----- Original Message ----- From: "Peter Palaga" To: "Discussions around Hawkular development" Sent: Thursday, June 4, 2015 2:49:41 PM Subject: [Hawkular-dev] Which logging categories can be hidden by default? Hi *, I hope I am not the only one who finds that there is a lot of uninteresting messages in the log which can be made hidden by default. I propose to add the following lines to standalone xml files for both dev and production profiles: Is this too much hiding or maybe somebody has even more candidates for suppressing? Thanks, Peter _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From ppalaga at redhat.com Thu Jun 4 08:57:38 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 04 Jun 2015 14:57:38 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <55704965.5060208@redhat.com> References: <55704965.5060208@redhat.com> Message-ID: <55704B42.5050906@redhat.com> BTW, this little change belongs to the same topic: https://github.com/hawkular/hawkular-metrics/pull/242 -- P On 2015-06-04 14:49, Peter Palaga wrote: > Hi *, > > I hope I am not the only one who finds that there is a lot of > uninteresting messages in the log which can be made hidden by default. > > I propose to add the following lines to standalone xml files for both > dev and production profiles: > > > > > > > > > > > > > > > > > > Is this too much hiding or maybe somebody has even more candidates for > suppressing? > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Thu Jun 4 09:02:01 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 04 Jun 2015 15:02:01 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <348639978.10666154.1433422389476.JavaMail.zimbra@redhat.com> References: <55704965.5060208@redhat.com> <348639978.10666154.1433422389476.JavaMail.zimbra@redhat.com> Message-ID: <55704C49.3080102@redhat.com> On 2015-06-04 14:53, John Mazzitelli wrote: > > I personally am OK with this. Though most of these are related to > Hawkular-Metrics and I don't work much in that code base. So this is > a question for the folks that develop Metrics - they might need to > see those categories at INFO level. Yes, they are free to set those back to INFO for their running instances and the rest of the world does not need to suffer ;) -- P > > ----- Original Message ----- >> Hi *, >> >> I hope I am not the only one who finds that there is a lot of >> uninteresting messages in the log which can be made hidden by default. >> >> I propose to add the following lines to standalone xml files for both >> dev and production profiles: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Is this too much hiding or maybe somebody has even more candidates for >> suppressing? >> >> Thanks, >> >> Peter >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Thu Jun 4 12:20:49 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 04 Jun 2015 18:20:49 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <55704965.5060208@redhat.com> References: <55704965.5060208@redhat.com> Message-ID: <55707AE1.3000706@redhat.com> Le 04/06/2015 14:49, Peter Palaga a ?crit : > Hi *, > > I hope I am not the only one who finds that there is a lot of > uninteresting messages in the log which can be made hidden by default. > > I propose to add the following lines to standalone xml files for both > dev and production profiles: > > > > > > > > > > > > > > > > What are the lines you're trying to get rid of? In Metrics, I only see these: 18:16:36,136 INFO [com.datastax.driver.core.policies.DCAwareRoundRobinPolicy] (metricsservice-lifecycle-thread) Using data-center name 'datacenter1' for DCAwareRoundRobinPolicy (if this is incorrect, please provide the correct datacenter name with DCAwareRoundRobinPolicy constructor) 18:16:36,137 INFO [com.datastax.driver.core.Cluster] (metricsservice-lifecycle-thread) New Cassandra host /127.0.0.1:9042 added Which I think are useful, just as: 18:16:19,517 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080 Or: 18:16:20,574 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management > > Is this too much hiding or maybe somebody has even more candidates for > suppressing? > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Thu Jun 4 16:25:59 2015 From: jsanda at redhat.com (John Sanda) Date: Thu, 4 Jun 2015 16:25:59 -0400 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <55707AE1.3000706@redhat.com> References: <55704965.5060208@redhat.com> <55707AE1.3000706@redhat.com> Message-ID: <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> With respect to Cassandra and the driver, I prefer to leave INFO level logging enabled for development. Collectively we do not have much experience with Cassandra. And considering we are using newer versions than were used in RHQ, we have even less experience. While the log messages might be a bit noisy, they can also be very helpful with the learning process. > On Jun 4, 2015, at 12:20 PM, Thomas Segismont wrote: > > Le 04/06/2015 14:49, Peter Palaga a ?crit : >> Hi *, >> >> I hope I am not the only one who finds that there is a lot of >> uninteresting messages in the log which can be made hidden by default. >> >> I propose to add the following lines to standalone xml files for both >> dev and production profiles: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > What are the lines you're trying to get rid of? In Metrics, I only see > these: > > 18:16:36,136 INFO > [com.datastax.driver.core.policies.DCAwareRoundRobinPolicy] > (metricsservice-lifecycle-thread) Using data-center name 'datacenter1' > for DCAwareRoundRobinPolicy (if this is incorrect, please provide the > correct datacenter name with DCAwareRoundRobinPolicy constructor) > 18:16:36,137 INFO [com.datastax.driver.core.Cluster] > (metricsservice-lifecycle-thread) New Cassandra host /127.0.0.1:9042 added > > Which I think are useful, just as: > > 18:16:19,517 INFO [org.wildfly.extension.undertow] (MSC service thread > 1-8) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080 > > Or: > > 18:16:20,574 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: > Http management interface listening on http://127.0.0.1:9990/management > >> >> Is this too much hiding or maybe somebody has even more candidates for >> suppressing? >> >> Thanks, >> >> Peter >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From ppalaga at redhat.com Thu Jun 4 16:37:18 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 04 Jun 2015 22:37:18 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> References: <55704965.5060208@redhat.com> <55707AE1.3000706@redhat.com> <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> Message-ID: <5570B6FE.20409@redhat.com> Thanks for the feedback. OK, let's have Cassandra and driver explicitly there with INFO, so that folks not needing to see their INFO can easily replace with WARN. So the present proposal is FWIW, I started to use xmlstarlet command to adjust the logging levels in standalone.xml just before starting a freshly built hawkular: yum install -y xmlstarlet xmlstarlet ed --inplace --ps -N "l=urn:jboss:domain:logging:2.0" \ --update "//l:logger[@category='com.datastax.driver']/l:level/@name" \ --value INFO \ standalone/configuration/standalone-itest.xml -- P On 2015-06-04 22:25, John Sanda wrote: > With respect to Cassandra and the driver, I prefer to leave INFO level logging enabled for development. Collectively we do not have much experience with Cassandra. And considering we are using newer versions than were used in RHQ, we have even less experience. While the log messages might be a bit noisy, they can also be very helpful with the learning process. > >> On Jun 4, 2015, at 12:20 PM, Thomas Segismont wrote: >> >> Le 04/06/2015 14:49, Peter Palaga a ?crit : >>> Hi *, >>> >>> I hope I am not the only one who finds that there is a lot of >>> uninteresting messages in the log which can be made hidden by default. >>> >>> I propose to add the following lines to standalone xml files for both >>> dev and production profiles: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> What are the lines you're trying to get rid of? In Metrics, I only see >> these: >> >> 18:16:36,136 INFO >> [com.datastax.driver.core.policies.DCAwareRoundRobinPolicy] >> (metricsservice-lifecycle-thread) Using data-center name 'datacenter1' >> for DCAwareRoundRobinPolicy (if this is incorrect, please provide the >> correct datacenter name with DCAwareRoundRobinPolicy constructor) >> 18:16:36,137 INFO [com.datastax.driver.core.Cluster] >> (metricsservice-lifecycle-thread) New Cassandra host /127.0.0.1:9042 added >> >> Which I think are useful, just as: >> >> 18:16:19,517 INFO [org.wildfly.extension.undertow] (MSC service thread >> 1-8) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080 >> >> Or: >> >> 18:16:20,574 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: >> Http management interface listening on http://127.0.0.1:9990/management >> >>> >>> Is this too much hiding or maybe somebody has even more candidates for >>> suppressing? >>> >>> Thanks, >>> >>> Peter >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Thu Jun 4 16:46:52 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 4 Jun 2015 16:46:52 -0400 (EDT) Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <5570B6FE.20409@redhat.com> References: <55704965.5060208@redhat.com> <55707AE1.3000706@redhat.com> <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> <5570B6FE.20409@redhat.com> Message-ID: <2110001857.11116036.1433450812759.JavaMail.zimbra@redhat.com> we could always use sysprops - that way no need for things like xmlstartlet just to tweek logging at startup. So for example: So you can now just do this: standalone.sh -Dhawkular.logging.org.apache.cassandra=WARN or you can make it generic: so you can change blocks of categories with standalone.sh -Dhawkular.logging.level=WARN ----- Original Message ----- > Thanks for the feedback. OK, let's have Cassandra and driver explicitly > there with INFO, so that folks not needing to see their INFO can easily > replace with WARN. > > So the present proposal is > > > > > > > > > > > > > > > > > > > FWIW, I started to use xmlstarlet command to adjust the logging levels > in standalone.xml just before starting a freshly built hawkular: > > yum install -y xmlstarlet > xmlstarlet ed --inplace --ps -N "l=urn:jboss:domain:logging:2.0" \ > --update "//l:logger[@category='com.datastax.driver']/l:level/@name" \ > --value INFO \ > standalone/configuration/standalone-itest.xml > > -- P > > > On 2015-06-04 22:25, John Sanda wrote: > > With respect to Cassandra and the driver, I prefer to leave INFO level > > logging enabled for development. Collectively we do not have much > > experience with Cassandra. And considering we are using newer versions > > than were used in RHQ, we have even less experience. While the log > > messages might be a bit noisy, they can also be very helpful with the > > learning process. > > > >> On Jun 4, 2015, at 12:20 PM, Thomas Segismont wrote: > >> > >> Le 04/06/2015 14:49, Peter Palaga a ?crit : > >>> Hi *, > >>> > >>> I hope I am not the only one who finds that there is a lot of > >>> uninteresting messages in the log which can be made hidden by default. > >>> > >>> I propose to add the following lines to standalone xml files for both > >>> dev and production profiles: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> What are the lines you're trying to get rid of? In Metrics, I only see > >> these: > >> > >> 18:16:36,136 INFO > >> [com.datastax.driver.core.policies.DCAwareRoundRobinPolicy] > >> (metricsservice-lifecycle-thread) Using data-center name 'datacenter1' > >> for DCAwareRoundRobinPolicy (if this is incorrect, please provide the > >> correct datacenter name with DCAwareRoundRobinPolicy constructor) > >> 18:16:36,137 INFO [com.datastax.driver.core.Cluster] > >> (metricsservice-lifecycle-thread) New Cassandra host /127.0.0.1:9042 added > >> > >> Which I think are useful, just as: > >> > >> 18:16:19,517 INFO [org.wildfly.extension.undertow] (MSC service thread > >> 1-8) JBAS017519: Undertow HTTP listener default listening on > >> /127.0.0.1:8080 > >> > >> Or: > >> > >> 18:16:20,574 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: > >> Http management interface listening on http://127.0.0.1:9990/management > >> > >>> > >>> Is this too much hiding or maybe somebody has even more candidates for > >>> suppressing? > >>> > >>> Thanks, > >>> > >>> Peter > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > 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 Jun 4 16:56:10 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 04 Jun 2015 22:56:10 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <5570B6FE.20409@redhat.com> References: <55704965.5060208@redhat.com> <55707AE1.3000706@redhat.com> <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> <5570B6FE.20409@redhat.com> Message-ID: <5570BB6A.1000000@redhat.com> > xmlstarlet rofl From lkrejci at redhat.com Fri Jun 5 08:25:00 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Fri, 5 Jun 2015 08:25:00 -0400 (EDT) Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? In-Reply-To: <55701F2E.90202@redhat.com> References: <55701F2E.90202@redhat.com> Message-ID: <364873995.11414121.1433507100091.JavaMail.zimbra@redhat.com> I think the reason for NOT exposing causes is that end users are usually not interested in them. On the other hand they can provide additional diagnostic information so devs are interested ;) The default formatters in wfly have the %E parameter which will include the stacktrace in the log message if you provide one but at least for me, having the log filled with stacktraces just defeats the purpose of a log, because it becomes nearly unintelligible. Of course, you can reconfigure your loggers and handlers to use different formatters at different occasions so "log mess" is not an argument against using @Cause's in your log messages but IMHO the defaults in Wfly are at least problematic because they expose the mess. Btw. your email got me completely on a tangent yesterday and I ended up with https://github.com/jboss-logging/jboss-logging-tools/pull/31 which I fear is going to get rejected but I still think it is at least partially a good idea ;) Lukas ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Thursday, 4 June, 2015 11:49:34 AM > Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? > > Hi *, > > I am just improving the log output in Pinger and Availability Creator > [1] and I found out that one can define a LogMessage containing all the > details of a thrown exception (incl error message and stack trace) like > this: > > @LogMessage(level = Logger.Level.ERROR) > @Message(id = 5007, value = "Could not send a message to the bus") > void eCouldNotSendMessage(@Cause Throwable e); > > Indeed, messages like this can be seen in Bus, Agent and Inventory, but > nowhere else. > > Are there some reasons for *not* using this @Cause message style at all? > > It is clear that not every thrown exception needs to clutter the log > with its stack trace. But generally, things that are supposed to work in > all cases and situations (like sending messages to bus) should be logged > incl. stack traces, should they not? > > Thanks, > > Peter > > [1] https://issues.jboss.org/browse/HAWKULAR-309 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Fri Jun 5 09:10:49 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 05 Jun 2015 15:10:49 +0200 Subject: [Hawkular-dev] Alpha1 is out, en route for Alpha2, Alpha3... Message-ID: <55719FD9.4000805@redhat.com> Thank you for the hard work on Alpha 1 release. The next prioritized topics would be: - More Wildfly monitoring. The WF agent expose quite some metrics now, only a few of those are currently displayed in the UI In particular: - HAWKULAR-217 [1] App Server Detail - JVM Metrics Tab - HAWKULAR-218 [2] App Server Detail - Web Metrics Tab - HAWKULAR-220 [3] App Server Detail - Deployments Metrics Tab - Some Wildfly operations (part of HAWKULAR-220) - "HAWKULAR-130 [4] Multiple alerts for a single issue" is close to my heart as I find it annoying --> It doesn't have to be solved by the UI team AFAIK, the UI shouldn't change (much). - More integration tests (move them ?) - ... Beside the UI, there are quite a few things to add or start to think about if you look at the mockups [5] - inventory filtering/searching if that's not yet done, this was not implemented as part of Alpha1 UI AFAIK - actions on deployments (Enable/disable/redeploy/(add/remove)) -> this is a new area, we should start now, it may not make it (all) for Alpha 2 - some metrics aggregation (Active sessions for all webapps of a single WF server for instance) - ... PS: Mockups attached to JIRAs are not correct Thomas [1] https://issues.jboss.org/browse/HAWKULAR-217 [2] https://issues.jboss.org/browse/HAWKULAR-218 [3] https://issues.jboss.org/browse/HAWKULAR-220 [4] https://issues.jboss.org/browse/HAWKULAR-130 [5] https://docs.google.com/document/d/1kLOGUyajyMsZuJoUxrLJkOzIyQb1V_r4JHj99JaaBQg/edit#heading=h.15cp8q2tgxok (Unfortunately this doc which adds more details is not accessible outside Red Hat employees) From jshaughn at redhat.com Fri Jun 5 09:11:06 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Fri, 05 Jun 2015 09:11:06 -0400 Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? In-Reply-To: <364873995.11414121.1433507100091.JavaMail.zimbra@redhat.com> References: <55701F2E.90202@redhat.com> <364873995.11414121.1433507100091.JavaMail.zimbra@redhat.com> Message-ID: <55719FEA.6030703@redhat.com> Customers are not interested and it erodes confidence. Unless you want a support case to result from that stack trace you probably don't want a stack trace. In your example I don't think I'd want to see a stack trace as a connection issue is often caused by mundane reasons (server not up). Of course, there are times when a trace would be super valuable. I'm also not against additional information (like a trace) being provided when debug is enabled. On 6/5/2015 8:25 AM, Lukas Krejci wrote: > I think the reason for NOT exposing causes is that end users are usually not interested in > them. > > On the other hand they can provide additional diagnostic information so devs are interested > ;) > > The default formatters in wfly have the %E parameter which will include the stacktrace in > the log message if you provide one but at least for me, having the log filled with > stacktraces just defeats the purpose of a log, because it becomes nearly unintelligible. > > Of course, you can reconfigure your loggers and handlers to use different formatters at > different occasions so "log mess" is not an argument against using @Cause's in your > log messages but IMHO the defaults in Wfly are at least problematic because they expose > the mess. > > Btw. your email got me completely on a tangent yesterday and I ended up with > https://github.com/jboss-logging/jboss-logging-tools/pull/31 which I fear is going to get > rejected but I still think it is at least partially a good idea ;) > > Lukas > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Thursday, 4 June, 2015 11:49:34 AM >> Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? >> >> Hi *, >> >> I am just improving the log output in Pinger and Availability Creator >> [1] and I found out that one can define a LogMessage containing all the >> details of a thrown exception (incl error message and stack trace) like >> this: >> >> @LogMessage(level = Logger.Level.ERROR) >> @Message(id = 5007, value = "Could not send a message to the bus") >> void eCouldNotSendMessage(@Cause Throwable e); >> >> Indeed, messages like this can be seen in Bus, Agent and Inventory, but >> nowhere else. >> >> Are there some reasons for *not* using this @Cause message style at all? >> >> It is clear that not every thrown exception needs to clutter the log >> with its stack trace. But generally, things that are supposed to work in >> all cases and situations (like sending messages to bus) should be logged >> incl. stack traces, should they not? >> >> Thanks, >> >> Peter >> >> [1] https://issues.jboss.org/browse/HAWKULAR-309 >> _______________________________________________ >> 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/20150605/f0676922/attachment.html From ppalaga at redhat.com Fri Jun 5 09:15:29 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 05 Jun 2015 15:15:29 +0200 Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? In-Reply-To: <364873995.11414121.1433507100091.JavaMail.zimbra@redhat.com> References: <55701F2E.90202@redhat.com> <364873995.11414121.1433507100091.JavaMail.zimbra@redhat.com> Message-ID: <5571A0F1.7080508@redhat.com> On 2015-06-05 14:25, Lukas Krejci wrote: > I think the reason for NOT exposing causes is that end users are usually not interested in > them. > > On the other hand they can provide additional diagnostic information so devs are interested > ;) Yeah, I'll keep adding causes only in situations when there is a real heavyweight malfunction. > The default formatters in wfly have the %E parameter which will include the stacktrace in > the log message if you provide one but at least for me, having the log filled with > stacktraces just defeats the purpose of a log, because it becomes nearly unintelligible. > > Of course, you can reconfigure your loggers and handlers to use different formatters at > different occasions so "log mess" is not an argument against using @Cause's in your > log messages but IMHO the defaults in Wfly are at least problematic because they expose > the mess. The existence of %E is a new info for me. Thanks for bringing it up! > Btw. your email got me completely on a tangent yesterday and I ended up with > https://github.com/jboss-logging/jboss-logging-tools/pull/31 which I fear is going to get > rejected but I still think it is at least partially a good idea ;) That is an interesting idea. Good luck! -- P > Lukas > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Thursday, 4 June, 2015 11:49:34 AM >> Subject: [Hawkular-dev] Reasons not to use org.jboss.logging.annotations.Cause at all? >> >> Hi *, >> >> I am just improving the log output in Pinger and Availability Creator >> [1] and I found out that one can define a LogMessage containing all the >> details of a thrown exception (incl error message and stack trace) like >> this: >> >> @LogMessage(level = Logger.Level.ERROR) >> @Message(id = 5007, value = "Could not send a message to the bus") >> void eCouldNotSendMessage(@Cause Throwable e); >> >> Indeed, messages like this can be seen in Bus, Agent and Inventory, but >> nowhere else. >> >> Are there some reasons for *not* using this @Cause message style at all? >> >> It is clear that not every thrown exception needs to clutter the log >> with its stack trace. But generally, things that are supposed to work in >> all cases and situations (like sending messages to bus) should be logged >> incl. stack traces, should they not? >> >> Thanks, >> >> Peter >> >> [1] https://issues.jboss.org/browse/HAWKULAR-309 >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Fri Jun 5 10:02:58 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 05 Jun 2015 16:02:58 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp Message-ID: <5571AC12.7000403@redhat.com> Hi everyone, While doing some testing for Grafana/Metrics integration, I found that if you don't supply a timestamp when you send data points to Metrics, they all get stored with timesptamp=0. This not right. In such situations, Influx saves the point with the server timestamp. We could also reply with 400 Bad Request. My preference goes to the latter. Any thoughts? I'll file a JIRA when we agree on a solution. Regards, Thomas From ppalaga at redhat.com Fri Jun 5 10:09:28 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 05 Jun 2015 16:09:28 +0200 Subject: [Hawkular-dev] Mocking HTTP Server Message-ID: <5571AD98.8000801@redhat.com> Hi *, it happened today: http://perfcake.org/ - one of the sites we unit-test Pinger against is down and therefore the tests are failing. Can anybody recommend a solution for mocking an HTTP Server? http://wiremock.org/ is the first result on Google and I am going to have a look at it. Thanks, Peter From theute at redhat.com Fri Jun 5 10:12:32 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 05 Jun 2015 16:12:32 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp In-Reply-To: <5571AC12.7000403@redhat.com> References: <5571AC12.7000403@redhat.com> Message-ID: <5571AE50.2040304@redhat.com> On 06/05/2015 04:02 PM, Thomas Segismont wrote: > Hi everyone, > > While doing some testing for Grafana/Metrics integration, I found that > if you don't supply a timestamp when you send data points to Metrics, > they all get stored with timesptamp=0. This not right. > > In such situations, Influx saves the point with the server timestamp. We > could also reply with 400 Bad Request. My preference goes to the latter. Agreed that reporting that it's wrong seems better that silently use some other value. But would we still have a simple way to explicitly use server timestamp ? Might be useful when you are unsure that the client machine has the right time and not care about some small time difference. Thomas > > Any thoughts? > > I'll file a JIRA when we agree on a solution. > > Regards, > Thomas > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Fri Jun 5 10:13:42 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Fri, 5 Jun 2015 17:13:42 +0300 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: <5571AD98.8000801@redhat.com> References: <5571AD98.8000801@redhat.com> Message-ID: Hi Peter, OkHttp has one [1], maybe not exactly what you want though. Artur. [1]: https://github.com/square/okhttp/tree/master/mockwebserver -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150605/f9d9f217/attachment.html From mithomps at redhat.com Fri Jun 5 10:17:14 2015 From: mithomps at redhat.com (mike thompson) Date: Fri, 5 Jun 2015 07:17:14 -0700 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: <5571AD98.8000801@redhat.com> References: <5571AD98.8000801@redhat.com> Message-ID: Peter, Based on our needs, QE has created one. A web-fixture to simulate down sites so we can test availability. Thanks Viet! Attaching the recent message from Viet... I'm pleased to announce first version of the Web Test Fixture is up and running. It's a web server (nginx) running inside Docker that can simulate a specific HTTP response code as well simple cron-like availability. Please let me know whether this is useful for Hawkular URL monitoring and what you want to see next. For example, a. simulate slow response time, b. cycle between http status codes, etc. Viet Nguyen ----- Example usage: [1] Launch a web fixture docker run -d -p 8999:8080 hawkularqe/web-fixture # get custom http code (replace 503 with any valid status code) curl -I http://localhost:8999/http?return=503 --> HTTP/1.1 503 Service Temporarily Unavailable [2] Launch a mostly-available fixture - server goes offline for 10 seconds every minute docker run -p 8999:8080 -e "DURATION=50s" -e "CRON_EXP=* * * * *" hawkularqe/web-fixture [1] and [2] in the example above are also running on public OS1: 1. http://209.132.179.82:50001 2. http://209.132.179.82:50002 Github: https://github.com/Hawkular-QE/web-fixture > On 5 Jun 2015, at 07:09, Peter Palaga wrote: > > Hi *, > > it happened today: http://perfcake.org/ - one of the sites we unit-test > Pinger against is down and therefore the tests are failing. > > Can anybody recommend a solution for mocking an HTTP Server? > > http://wiremock.org/ is the first result on Google and I am going to > have a look at it. > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150605/a2e36f1d/attachment.html From jsanda at redhat.com Fri Jun 5 10:19:00 2015 From: jsanda at redhat.com (John Sanda) Date: Fri, 5 Jun 2015 10:19:00 -0400 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: <5571AD98.8000801@redhat.com> References: <5571AD98.8000801@redhat.com> Message-ID: On Jun 5, 2015, at 10:09 AM, Peter Palaga wrote: > > Hi *, > > it happened today: http://perfcake.org/ - one of the sites we unit-test > Pinger against is down and therefore the tests are failing. > > Can anybody recommend a solution for mocking an HTTP Server? If you want more of an integration test, what about just running an HTTP server in a separate thread? > > http://wiremock.org/ is the first result on Google and I am going to > have a look at it. > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From mithomps at redhat.com Fri Jun 5 10:25:58 2015 From: mithomps at redhat.com (mike thompson) Date: Fri, 5 Jun 2015 07:25:58 -0700 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: References: <5571AD98.8000801@redhat.com> Message-ID: <98094FD0-75D6-45B3-A7B5-701A1EEDCF9C@redhat.com> Another solution is to use a node.js lib called: https://github.com/basicallydan/interfake That works quite well with creating fake responses and statuses (i.e., 404, 500). And you can even script the responses together to simulate a real server with dependent multi-page flows. ? Mike > On 5 Jun 2015, at 07:13, Artur Dryomov wrote: > > Hi Peter, > > OkHttp has one [1], maybe not exactly what you want though. > > Artur. > > [1]: https://github.com/square/okhttp/tree/master/mockwebserver _______________________________________________ > 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/20150605/e18cfa5d/attachment.html From jsanda at redhat.com Fri Jun 5 11:03:33 2015 From: jsanda at redhat.com (John Sanda) Date: Fri, 5 Jun 2015 11:03:33 -0400 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: References: <5571AD98.8000801@redhat.com> Message-ID: > On Jun 5, 2015, at 10:19 AM, John Sanda wrote: > > On Jun 5, 2015, at 10:09 AM, Peter Palaga wrote: >> >> Hi *, >> >> it happened today: http://perfcake.org/ - one of the sites we unit-test >> Pinger against is down and therefore the tests are failing. >> >> Can anybody recommend a solution for mocking an HTTP Server? > > If you want more of an integration test, what about just running an HTTP server in a separate thread? Here is a simple example using Vert.x with Groovy, //---------------------------------------------------------------------------------------------------- @Test void pingServer() { HttpServerOptions options = new HttpServerOptions(port: 7575) HttpServer server = Vertx.vertx().createHttpServer(options).requestHandler { request -> request.response().putHeader('Content-Type', "text/plain").setStatusCode(200).end("test") } server.listen() RESTClient client = new RESTClient("http://localhost:7575", "text/plain") def response = client.get(path: "/") assertEquals(200, response.status) server.close() } //---------------------------------------------------------------------------------------------------- IMO this is a lot easier than relying on an external server. And it is much simpler to control the server behavior. > >> >> http://wiremock.org/ is the first result on Google and I am going to >> have a look at it. >> >> Thanks, >> >> Peter >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Fri Jun 5 11:46:07 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 05 Jun 2015 17:46:07 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp In-Reply-To: <5571AE50.2040304@redhat.com> References: <5571AC12.7000403@redhat.com> <5571AE50.2040304@redhat.com> Message-ID: <5571C43F.3080506@redhat.com> Le 05/06/2015 16:12, Thomas Heute a ?crit : > > > On 06/05/2015 04:02 PM, Thomas Segismont wrote: >> Hi everyone, >> >> While doing some testing for Grafana/Metrics integration, I found that >> if you don't supply a timestamp when you send data points to Metrics, >> they all get stored with timesptamp=0. This not right. >> >> In such situations, Influx saves the point with the server timestamp. We >> could also reply with 400 Bad Request. My preference goes to the latter. > > Agreed that reporting that it's wrong seems better that silently use > some other value. > > But would we still have a simple way to explicitly use server timestamp ? > Might be useful when you are unsure that the client machine has the > right time and not care about some small time difference. > Adding a flag (-Dhawkular.metrics.useServerTimestamp) to switch between failing requests and using a server timestamp would do the trick. In any case it's important we insist that users should make sure all machines times are synchronized. > Thomas > >> >> Any thoughts? >> >> I'll file a JIRA when we agree on a solution. >> >> Regards, >> Thomas >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Fri Jun 5 11:48:17 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 05 Jun 2015 17:48:17 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp In-Reply-To: <5571C43F.3080506@redhat.com> References: <5571AC12.7000403@redhat.com> <5571AE50.2040304@redhat.com> <5571C43F.3080506@redhat.com> Message-ID: <5571C4C1.1060909@redhat.com> Le 05/06/2015 17:46, Thomas Segismont a ?crit : > -Dhawkular.metrics.useServerTimestamp Just an example name, from the top of my head. Feel free to suggest something else. From ppalaga at redhat.com Fri Jun 5 11:50:07 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 05 Jun 2015 17:50:07 +0200 Subject: [Hawkular-dev] Mocking HTTP Server In-Reply-To: References: <5571AD98.8000801@redhat.com> Message-ID: <5571C52F.4010005@redhat.com> Thanks John and others for ideas. Indeed, doing this with Vertex seems to be very elegant. Anyway, wiremock seems to be the winner for both its built-in and easy to use HTTPS support and the fact that it provides a JUnit rule that starts and stops the HTTP(s) service around the tests as needed. Here is the PR: https://github.com/hawkular/hawkular/pull/193 Thanks again, Peter On 2015-06-05 17:03, John Sanda wrote: > >> On Jun 5, 2015, at 10:19 AM, John Sanda wrote: >> >> On Jun 5, 2015, at 10:09 AM, Peter Palaga wrote: >>> >>> Hi *, >>> >>> it happened today: http://perfcake.org/ - one of the sites we unit-test >>> Pinger against is down and therefore the tests are failing. >>> >>> Can anybody recommend a solution for mocking an HTTP Server? >> >> If you want more of an integration test, what about just running an HTTP server in a separate thread? > > Here is a simple example using Vert.x with Groovy, > > //---------------------------------------------------------------------------------------------------- > @Test > void pingServer() { > HttpServerOptions options = new HttpServerOptions(port: 7575) > HttpServer server = Vertx.vertx().createHttpServer(options).requestHandler { request -> > request.response().putHeader('Content-Type', "text/plain").setStatusCode(200).end("test") > } > server.listen() > > RESTClient client = new RESTClient("http://localhost:7575", "text/plain") > def response = client.get(path: "/") > > assertEquals(200, response.status) > > server.close() > } > //---------------------------------------------------------------------------------------------------- > > IMO this is a lot easier than relying on an external server. And it is much simpler to control the server behavior. >> >>> >>> http://wiremock.org/ is the first result on Google and I am going to >>> have a look at it. >>> >>> Thanks, >>> >>> Peter >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Fri Jun 5 14:00:00 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 05 Jun 2015 20:00:00 +0200 Subject: [Hawkular-dev] Which logging categories can be hidden by default? In-Reply-To: <2110001857.11116036.1433450812759.JavaMail.zimbra@redhat.com> References: <55704965.5060208@redhat.com> <55707AE1.3000706@redhat.com> <91114B2D-4D79-4417-A3F4-B09B14AD7789@redhat.com> <5570B6FE.20409@redhat.com> <2110001857.11116036.1433450812759.JavaMail.zimbra@redhat.com> Message-ID: <5571E3A0.1090402@redhat.com> I actually had the idea with sysprops which I also found quite good but I was not brave enough to propose yet another way to pollute the pure standalone.sh ;) Here is the PR that I leave open for comments for a couple of days: https://github.com/hawkular/hawkular/pull/192 -- P On 2015-06-04 22:46, John Mazzitelli wrote: > we could always use sysprops - that way no need for things like xmlstartlet just to tweek logging at startup. So for example: > > > > > > So you can now just do this: > > standalone.sh -Dhawkular.logging.org.apache.cassandra=WARN > > or you can make it generic: > > > > > > > > > so you can change blocks of categories with > > standalone.sh -Dhawkular.logging.level=WARN > > ----- Original Message ----- >> Thanks for the feedback. OK, let's have Cassandra and driver explicitly >> there with INFO, so that folks not needing to see their INFO can easily >> replace with WARN. >> >> So the present proposal is >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> FWIW, I started to use xmlstarlet command to adjust the logging levels >> in standalone.xml just before starting a freshly built hawkular: >> >> yum install -y xmlstarlet >> xmlstarlet ed --inplace --ps -N "l=urn:jboss:domain:logging:2.0" \ >> --update "//l:logger[@category='com.datastax.driver']/l:level/@name" \ >> --value INFO \ >> standalone/configuration/standalone-itest.xml >> >> -- P >> >> >> On 2015-06-04 22:25, John Sanda wrote: >>> With respect to Cassandra and the driver, I prefer to leave INFO level >>> logging enabled for development. Collectively we do not have much >>> experience with Cassandra. And considering we are using newer versions >>> than were used in RHQ, we have even less experience. While the log >>> messages might be a bit noisy, they can also be very helpful with the >>> learning process. >>> >>>> On Jun 4, 2015, at 12:20 PM, Thomas Segismont wrote: >>>> >>>> Le 04/06/2015 14:49, Peter Palaga a ?crit : >>>>> Hi *, >>>>> >>>>> I hope I am not the only one who finds that there is a lot of >>>>> uninteresting messages in the log which can be made hidden by default. >>>>> >>>>> I propose to add the following lines to standalone xml files for both >>>>> dev and production profiles: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> What are the lines you're trying to get rid of? In Metrics, I only see >>>> these: >>>> >>>> 18:16:36,136 INFO >>>> [com.datastax.driver.core.policies.DCAwareRoundRobinPolicy] >>>> (metricsservice-lifecycle-thread) Using data-center name 'datacenter1' >>>> for DCAwareRoundRobinPolicy (if this is incorrect, please provide the >>>> correct datacenter name with DCAwareRoundRobinPolicy constructor) >>>> 18:16:36,137 INFO [com.datastax.driver.core.Cluster] >>>> (metricsservice-lifecycle-thread) New Cassandra host /127.0.0.1:9042 added >>>> >>>> Which I think are useful, just as: >>>> >>>> 18:16:19,517 INFO [org.wildfly.extension.undertow] (MSC service thread >>>> 1-8) JBAS017519: Undertow HTTP listener default listening on >>>> /127.0.0.1:8080 >>>> >>>> Or: >>>> >>>> 18:16:20,574 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: >>>> Http management interface listening on http://127.0.0.1:9990/management >>>> >>>>> >>>>> Is this too much hiding or maybe somebody has even more candidates for >>>>> suppressing? >>>>> >>>>> Thanks, >>>>> >>>>> Peter >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Jun 8 03:05:20 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 08 Jun 2015 09:05:20 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp In-Reply-To: <5571C43F.3080506@redhat.com> References: <5571AC12.7000403@redhat.com> <5571AE50.2040304@redhat.com> <5571C43F.3080506@redhat.com> Message-ID: <55753EB0.4010103@redhat.com> On 06/05/2015 05:46 PM, Thomas Segismont wrote: > Le 05/06/2015 16:12, Thomas Heute a ?crit : >> >> >> On 06/05/2015 04:02 PM, Thomas Segismont wrote: >>> Hi everyone, >>> >>> While doing some testing for Grafana/Metrics integration, I found that >>> if you don't supply a timestamp when you send data points to Metrics, >>> they all get stored with timesptamp=0. This not right. >>> >>> In such situations, Influx saves the point with the server timestamp. We >>> could also reply with 400 Bad Request. My preference goes to the latter. >> >> Agreed that reporting that it's wrong seems better that silently use >> some other value. >> >> But would we still have a simple way to explicitly use server timestamp ? >> Might be useful when you are unsure that the client machine has the >> right time and not care about some small time difference. >> > > Adding a flag (-Dhawkular.metrics.useServerTimestamp) to switch between > failing requests and using a server timestamp would do the trick. > > In any case it's important we insist that users should make sure all > machines times are synchronized. I was thinking for an individual request, not server wide. Thomas > > >> Thomas >> >>> >>> Any thoughts? >>> >>> I'll file a JIRA when we agree on a solution. >>> >>> Regards, >>> Thomas >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mvecera at redhat.com Fri Jun 5 18:04:56 2015 From: mvecera at redhat.com (Martin Vecera) Date: Fri, 5 Jun 2015 18:04:56 -0400 (EDT) Subject: [Hawkular-dev] Mocking HTTP(S) Server In-Reply-To: <691809012.11736171.1433541660533.JavaMail.zimbra@redhat.com> Message-ID: <557044639.11736578.1433541896000.JavaMail.zimbra@redhat.com> Hello Peter, do you have an idea when did that happen? The site is up and running. We do not have any plans to shut it down or do any maintenance mode. It might be that the response took too long. Nevertheless, there was a very good reason why I used this site in your unit tests. Every other mock/test site I used was allowed to use HTTP as a backup. So even if I asked for HTTPS, if I refused the certificate, the test passed. So make sure you update the test to check that this is not happening. Regards, Martin P.S.: Please CC me, I am not subscribed to your list. > Hi *, > > it happened today: http://perfcake.org/ - one of the sites we unit-test > Pinger against is down and therefore the tests are failing. > > Can anybody recommend a solution for mocking an HTTP Server? > > http://wiremock.org/ is the first result on Google and I am going to > have a look at it. > > Thanks, > > Peter -- Martin Ve?e?a Middleware QE Manager External no. +420 532 294 112 Internal no. 8262112 IRC: mvecera #brno #jbossqa Calendar: https://www.google.com/calendar/b/1/embed?src=mvecera at redhat.com&ctz=Europe/Prague From artur.dryomov at gmail.com Mon Jun 8 03:27:10 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 8 Jun 2015 10:27:10 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #2 Message-ID: Hi everyone, This year I am working on the Hawkular Android application as part of the Google Summer of Code 2015 program. I?ve spent the last week on the application development and writing a script which will allow me to populate a Hawkular instance with sample data. The application itself [1] at this point can use a custom server URL. After pressing a button you will see an OAuth dialog which will allow you to login using your Hawkular credentials. This step will automatically redirect you to the resource types screen. AeroGear did a great job with the authorization process ? seems like all necessary headers are set without any additional cost from my side. Regarding the fun part ? the application got a fancy theme in red and orange colors based on the official logo. The icon is there as well. You can take a look at some screenshots [2]. With the help from various Hawkular modules source code and useful links from Jiri Kremser I?ve created a gist with HTTPie [3] commands [4]. My goal was to populate a server from the ground up ? from tenants to metric data. Unfortunately I?m having some issues with it. ? First. I am able to create a tenant but if I try to create an environment on it ? the response gives me 403 Forbidden. At the same time creating an environment for a tenant from "/inventory/tenant" is flawless. Maybe it is somehow related to metrics-inventory communication. Inventory has a single tenant, metrics can have multiple. I see no ability to set an active tenant for the inventory using the API. ? Second. Seems like I?m adding data to metrics the wrong way. It is created without any issues, but I cannot see it from the query. This week I would like work on those areas implementing rest of Inventory screens for the application and fixing and expanding the script to get something to display at the application :-) If someone has a real-world example of multiple resources, metrics and metrics-related data ? it will be a great help. Have a nice week! Artur. [1]: https://github.com/hawkular/android-client [2]: https://github.com/hawkular/android-client/pull/5 [3]: http://httpie.org/ [4]: https://gist.github.com/ming13/e7ebab69028adaa7dea4 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150608/f552dd42/attachment.html From ppalaga at redhat.com Mon Jun 8 04:25:12 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 08 Jun 2015 10:25:12 +0200 Subject: [Hawkular-dev] Mocking HTTP(S) Server In-Reply-To: <557044639.11736578.1433541896000.JavaMail.zimbra@redhat.com> References: <557044639.11736578.1433541896000.JavaMail.zimbra@redhat.com> Message-ID: <55755168.2080103@redhat.com> Ahoj Martine, thanks for the info. More inline... On 2015-06-06 00:04, Martin Vecera wrote: > Hello Peter, > > do you have an idea when did that happen? The site is up and running. > We do not have any plans to shut it down or do any maintenance mode. > It might be that the response took too long. I do not remember if I was getting timeouts or something else. Nevertheless, a fix based on wiremock is in place now: https://github.com/hawkular/hawkular/commit/d4d7012f2c68a69d17619aea6a9b49338d427549 > Nevertheless, there was a very good reason why I used this site in > your unit tests. Every other mock/test site I used was allowed to use > HTTP as a backup. So even if I asked for HTTPS, if I refused the > certificate, the test passed. So make sure you update the test to > check that this is not happening. If I refuse all certs by returning false here https://github.com/hawkular/hawkular/blob/1d8fd2bc06ed3893e4e3bad0c8289838d6bd3e52/modules/pinger/src/main/java/org/hawkular/component/pinger/Pinger.java#L66 the SSL test fails. That is a proof that wiremock is not doing the HTTPS fallback to HTTP, is it not? -- P > Regards, Martin > > P.S.: Please CC me, I am not subscribed to your list. > >> Hi *, >> >> it happened today: http://perfcake.org/ - one of the sites we >> unit-test Pinger against is down and therefore the tests are >> failing. >> >> Can anybody recommend a solution for mocking an HTTP Server? >> >> http://wiremock.org/ is the first result on Google and I am going >> to have a look at it. >> >> Thanks, >> >> Peter > > > -- Martin Ve?e?a Middleware QE Manager External no. +420 532 294 112 > Internal no. 8262112 IRC: mvecera #brno #jbossqa > > Calendar: > https://www.google.com/calendar/b/1/embed?src=mvecera at redhat.com&ctz=Europe/Prague > From ppalaga at redhat.com Mon Jun 8 05:53:01 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 08 Jun 2015 11:53:01 +0200 Subject: [Hawkular-dev] Avoiding JBoss Nexus UI with nexus-staging-maven-plugin Message-ID: <557565FD.1050001@redhat.com> Hi *, In build tools, I could just successfully perform a CLI-only release without needing to visit JBoss Nexus GUI. The setup was fairly easy, done in these two commits: [1] [2]. However, initially it did not work properly, as far as the child-parent link was not there in hawkular-build-tools module. After I added it back in [3] the release started to work properly. As some of you showed interest in this CLI-only release process, we should agree on a way how to bring this into hawkular-parent. My proposal is to introduce nexus-staging-maven-plugin in a dedicated profile (let's call it "release-gui-less") that would (at least initially) be off by default. This would allow the interested folks to use it while there would be no change for those ones who are OK with the present setup. Any comments? Thanks, Peter [1] https://github.com/hawkular/hawkular-build-tools/commit/b48133af85de156f3f7e14a68cab48704d81cb16 [2] https://github.com/hawkular/hawkular-build-tools/commit/bfe907f31ed4c4afbe9a6745303d48feda2a60f9 [3] https://github.com/hawkular/hawkular-build-tools/commit/9647bc123b44babc2e9df47ac2af9611de6596ef From gbrown at redhat.com Mon Jun 8 06:01:35 2015 From: gbrown at redhat.com (Gary Brown) Date: Mon, 8 Jun 2015 06:01:35 -0400 (EDT) Subject: [Hawkular-dev] Avoiding JBoss Nexus UI with nexus-staging-maven-plugin In-Reply-To: <557565FD.1050001@redhat.com> References: <557565FD.1050001@redhat.com> Message-ID: <1481893356.11052105.1433757695659.JavaMail.zimbra@redhat.com> +1 to separate profile - if we then get to situation where everyone is happy after using it for a while, then could be made default. ----- Original Message ----- > Hi *, > > In build tools, I could just successfully perform a CLI-only release > without needing to visit JBoss Nexus GUI. The setup was fairly easy, > done in these two commits: [1] [2]. > However, initially it did not work properly, as far as the child-parent > link was not there in hawkular-build-tools module. After I added it back > in [3] the release started to work properly. > > As some of you showed interest in this CLI-only release process, we > should agree on a way how to bring this into hawkular-parent. > > My proposal is to introduce nexus-staging-maven-plugin in a dedicated > profile (let's call it "release-gui-less") that would (at least > initially) be off by default. This would allow the interested folks to > use it while there would be no change for those ones who are OK with the > present setup. Any comments? > > Thanks, > > Peter > > [1] > https://github.com/hawkular/hawkular-build-tools/commit/b48133af85de156f3f7e14a68cab48704d81cb16 > > [2] > https://github.com/hawkular/hawkular-build-tools/commit/bfe907f31ed4c4afbe9a6745303d48feda2a60f9 > > [3] > https://github.com/hawkular/hawkular-build-tools/commit/9647bc123b44babc2e9df47ac2af9611de6596ef > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Mon Jun 8 08:40:03 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 08 Jun 2015 14:40:03 +0200 Subject: [Hawkular-dev] [Metrics] What should we do with requests to save data points without a timestamp In-Reply-To: <55753EB0.4010103@redhat.com> References: <5571AC12.7000403@redhat.com> <5571AE50.2040304@redhat.com> <5571C43F.3080506@redhat.com> <55753EB0.4010103@redhat.com> Message-ID: <55758D23.7050200@redhat.com> Le 08/06/2015 09:05, Thomas Heute a ?crit : >> >Adding a flag (-Dhawkular.metrics.useServerTimestamp) to switch between >> >failing requests and using a server timestamp would do the trick. >> > >> >In any case it's important we insist that users should make sure all >> >machines times are synchronized. > I was thinking for an individual request, not server wide. Then the switch would be a new header, like: === Hawkular-UseServerTimestamp: true === Nice idea. From mvecera at redhat.com Mon Jun 8 09:17:25 2015 From: mvecera at redhat.com (Martin Vecera) Date: Mon, 8 Jun 2015 09:17:25 -0400 (EDT) Subject: [Hawkular-dev] Mocking HTTP(S) Server In-Reply-To: <55755168.2080103@redhat.com> References: <557044639.11736578.1433541896000.JavaMail.zimbra@redhat.com> <55755168.2080103@redhat.com> Message-ID: <20874592.12291629.1433769445526.JavaMail.zimbra@redhat.com> Hello, this looks like an elegant solution. One check with Wireshark just to be double-sure would not be bad but it is likely to confirm you are correct ;-) @M. ----- Original Message ----- From: "Peter Palaga" To: "Martin Vecera" , hawkular-dev at lists.jboss.org Sent: Monday, June 8, 2015 10:25:12 AM Subject: Re: Mocking HTTP(S) Server Ahoj Martine, thanks for the info. More inline... On 2015-06-06 00:04, Martin Vecera wrote: > Hello Peter, > > do you have an idea when did that happen? The site is up and running. > We do not have any plans to shut it down or do any maintenance mode. > It might be that the response took too long. I do not remember if I was getting timeouts or something else. Nevertheless, a fix based on wiremock is in place now: https://github.com/hawkular/hawkular/commit/d4d7012f2c68a69d17619aea6a9b49338d427549 > Nevertheless, there was a very good reason why I used this site in > your unit tests. Every other mock/test site I used was allowed to use > HTTP as a backup. So even if I asked for HTTPS, if I refused the > certificate, the test passed. So make sure you update the test to > check that this is not happening. If I refuse all certs by returning false here https://github.com/hawkular/hawkular/blob/1d8fd2bc06ed3893e4e3bad0c8289838d6bd3e52/modules/pinger/src/main/java/org/hawkular/component/pinger/Pinger.java#L66 the SSL test fails. That is a proof that wiremock is not doing the HTTPS fallback to HTTP, is it not? -- P > Regards, Martin > > P.S.: Please CC me, I am not subscribed to your list. > >> Hi *, >> >> it happened today: http://perfcake.org/ - one of the sites we >> unit-test Pinger against is down and therefore the tests are >> failing. >> >> Can anybody recommend a solution for mocking an HTTP Server? >> >> http://wiremock.org/ is the first result on Google and I am going >> to have a look at it. >> >> Thanks, >> >> Peter > > > -- Martin Ve?e?a Middleware QE Manager External no. +420 532 294 112 > Internal no. 8262112 IRC: mvecera #brno #jbossqa > > Calendar: > https://www.google.com/calendar/b/1/embed?src=mvecera at redhat.com&ctz=Europe/Prague > From mwringe at redhat.com Mon Jun 8 09:47:16 2015 From: mwringe at redhat.com (Matt Wringe) Date: Mon, 08 Jun 2015 09:47:16 -0400 Subject: [Hawkular-dev] Container Tests Message-ID: <55759CE4.7070603@redhat.com> Currently we are not doing any tests for the Hawkular Metrics docker images and kubernetes configurations. This is something we really need to address. We are currently using Travis which doesn't provide a nice solution for this space. Fabric8 has a good setup for testing kubernetes components with their Continuous Delivery suite (which uses Jenkins), but requires a machine to be setup running docker (+ OpenShift) to deploy its suite of docker images. With a fabric8 continuous delivery setup, we can also remove the docker hub automated builds and build them as part of maven build. This would allow us to: 1) only publish docker images if the test suites pass on them (with docker hub we would have to publish the images first and then run tests). 2) to manage all the code in one spot without having to modify it in multiple locations (currently its managed in 3 different github repos which need to be synced together). 3) have a lot more control over images and how they are tagged. Currently docker hub is restrictive in how we handle this. [Note: we would still be publishing out images to docker hub for others to consume, we would just be pushing the images that our test suite builds rather than ones build in docker hub itself. It also means we can publish to other repositories if we wish] Anyone know if we have any machines available to setup an environment for these types of tests? We could move the container stuff out of Hawkular Metrics and into its own git repository (which might make sense, since the Cassandra stuff is not necessarily metrics specific). This would mean that we don't need to move all the tests over to Jenkins and we could keep the current Metrics tests in the same CI. Or it could be configured to only build the docker images and not all of Metrics (via profiles). Anyone have any thoughts on this? Thanks, Matt From ppalaga at redhat.com Mon Jun 8 09:56:46 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 08 Jun 2015 15:56:46 +0200 Subject: [Hawkular-dev] Container Tests In-Reply-To: <55759CE4.7070603@redhat.com> References: <55759CE4.7070603@redhat.com> Message-ID: <55759F1E.4090007@redhat.com> > we have any machines available to setup an environment > for these types of tests? Torii maybe? -- P On 2015-06-08 15:47, Matt Wringe wrote: > Currently we are not doing any tests for the Hawkular Metrics docker > images and kubernetes configurations. This is something we really need > to address. > > We are currently using Travis which doesn't provide a nice solution for > this space. Fabric8 has a good setup for testing kubernetes components > with their Continuous Delivery suite (which uses Jenkins), but requires > a machine to be setup running docker (+ OpenShift) to deploy its suite > of docker images. > > With a fabric8 continuous delivery setup, we can also remove the docker > hub automated builds and build them as part of maven build. This would > allow us to: > 1) only publish docker images if the test suites pass on them (with > docker hub we would have to publish the images first and then run tests). > 2) to manage all the code in one spot without having to modify it in > multiple locations (currently its managed in 3 different github repos > which need to be synced together). > 3) have a lot more control over images and how they are tagged. > Currently docker hub is restrictive in how we handle this. > > [Note: we would still be publishing out images to docker hub for others > to consume, we would just be pushing the images that our test suite > builds rather than ones build in docker hub itself. It also means we can > publish to other repositories if we wish] > > Anyone know if we have any machines available to setup an environment > for these types of tests? > > We could move the container stuff out of Hawkular Metrics and into its > own git repository (which might make sense, since the Cassandra stuff is > not necessarily metrics specific). This would mean that we don't need to > move all the tests over to Jenkins and we could keep the current Metrics > tests in the same CI. > > Or it could be configured to only build the docker images and not all of > Metrics (via profiles). > > Anyone have any thoughts on this? > > Thanks, > > Matt > > > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From brmeyer at redhat.com Mon Jun 8 10:10:25 2015 From: brmeyer at redhat.com (Brett Meyer) Date: Mon, 8 Jun 2015 10:10:25 -0400 (EDT) Subject: [Hawkular-dev] Mocking HTTP(S) Server In-Reply-To: <20874592.12291629.1433769445526.JavaMail.zimbra@redhat.com> References: <557044639.11736578.1433541896000.JavaMail.zimbra@redhat.com> <55755168.2080103@redhat.com> <20874592.12291629.1433769445526.JavaMail.zimbra@redhat.com> Message-ID: <1202898778.13694560.1433772625913.JavaMail.zimbra@redhat.com> FWIW, what about embedded Jetty or Undertow? ----- Original Message ----- > From: "Martin Vecera" > To: "Peter Palaga" > Cc: hawkular-dev at lists.jboss.org > Sent: Monday, June 8, 2015 9:17:25 AM > Subject: Re: [Hawkular-dev] Mocking HTTP(S) Server > > Hello, > > this looks like an elegant solution. One check with Wireshark just to be > double-sure would not be bad but it is likely to confirm you are correct ;-) > > @M. > > ----- Original Message ----- > From: "Peter Palaga" > To: "Martin Vecera" , hawkular-dev at lists.jboss.org > Sent: Monday, June 8, 2015 10:25:12 AM > Subject: Re: Mocking HTTP(S) Server > > Ahoj Martine, thanks for the info. More inline... > > On 2015-06-06 00:04, Martin Vecera wrote: > > Hello Peter, > > > > do you have an idea when did that happen? The site is up and running. > > We do not have any plans to shut it down or do any maintenance mode. > > It might be that the response took too long. > > I do not remember if I was getting timeouts or something else. > Nevertheless, a fix based on wiremock is in place now: > https://github.com/hawkular/hawkular/commit/d4d7012f2c68a69d17619aea6a9b49338d427549 > > > Nevertheless, there was a very good reason why I used this site in > > your unit tests. Every other mock/test site I used was allowed to use > > HTTP as a backup. So even if I asked for HTTPS, if I refused the > > certificate, the test passed. So make sure you update the test to > > check that this is not happening. > > If I refuse all certs by returning false here > https://github.com/hawkular/hawkular/blob/1d8fd2bc06ed3893e4e3bad0c8289838d6bd3e52/modules/pinger/src/main/java/org/hawkular/component/pinger/Pinger.java#L66 > the SSL test fails. That is a proof that wiremock is not doing the HTTPS > fallback to HTTP, is it not? > > -- P > > > Regards, Martin > > > > P.S.: Please CC me, I am not subscribed to your list. > > > >> Hi *, > >> > >> it happened today: http://perfcake.org/ - one of the sites we > >> unit-test Pinger against is down and therefore the tests are > >> failing. > >> > >> Can anybody recommend a solution for mocking an HTTP Server? > >> > >> http://wiremock.org/ is the first result on Google and I am going > >> to have a look at it. > >> > >> Thanks, > >> > >> Peter > > > > > > -- Martin Ve?e?a Middleware QE Manager External no. +420 532 294 112 > > Internal no. 8262112 IRC: mvecera #brno #jbossqa > > > > Calendar: > > https://www.google.com/calendar/b/1/embed?src=mvecera at redhat.com&ctz=Europe/Prague > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Mon Jun 8 12:27:52 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 8 Jun 2015 12:27:52 -0400 (EDT) Subject: [Hawkular-dev] resource config and operations In-Reply-To: <418683607.12527865.1433780483128.JavaMail.zimbra@redhat.com> Message-ID: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> I am working in my own branch, but am about to introduce resource configuration and operations to the resource type metadata. This was in part due to the UI folks needing the hostname to show in the GUI. I wanted to let people know what this looks like - speak now if you see problems. The resourceType will now have as part of its attached metadata a list named "resourceConfiguration" which consists of config property types (today, there is only "name" associated with resource config property types, but you can envision other things like "dataType" (for boolean, integers, etc)). There is also a list of operations (today, consists of only a name and optional "operationName"). The JSON for resourceType looks like this inside inventory (this is for the top level "WildFly Server" type): "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", "id": "WildFly Server", "version": "0.1", "properties": { "name": "WildFly Server", "operations": [ { "name": "Reload Server", "operationName": "reload" } ], "resourceConfiguration": [ { "name": "Hostname" }, { "name": "Max Heap" }, { "name": "Version" } ] } A resource of this type would look like: "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", "environment": "test", "feed": "mazztower", "id": "[Local Host~/]", "type": <<>>, "properties": { "name": "WildFly Server [Local Host] [mazztower]", "resourceConfiguration": [ { "name": "Version", "value": "8.2.0.Final" }, { "name": "Hostname", "value": "mazztower" }, { "name": "Max Heap", "value": "477626368" } ] } From jsanda at redhat.com Mon Jun 8 13:03:54 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 8 Jun 2015 13:03:54 -0400 Subject: [Hawkular-dev] resource config and operations In-Reply-To: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> References: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> Message-ID: <01F7E111-F63E-4E55-AD2B-7D281D95F6B2@redhat.com> What are the distinctions between config, trait, and metric? > On Jun 8, 2015, at 12:27 PM, John Mazzitelli wrote: > > I am working in my own branch, but am about to introduce resource configuration and operations to the resource type metadata. This was in part due to the UI folks needing the hostname to show in the GUI. > > I wanted to let people know what this looks like - speak now if you see problems. > > The resourceType will now have as part of its attached metadata a list named "resourceConfiguration" which consists of config property types (today, there is only "name" associated with resource config property types, but you can envision other things like "dataType" (for boolean, integers, etc)). > > There is also a list of operations (today, consists of only a name and optional "operationName"). > > The JSON for resourceType looks like this inside inventory (this is for the top level "WildFly Server" type): > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "id": "WildFly Server", > "version": "0.1", > "properties": > { > "name": "WildFly Server", > "operations": > [ > { > "name": "Reload Server", > "operationName": "reload" > } > ], > "resourceConfiguration": > [ > { > "name": "Hostname" > }, > { > "name": "Max Heap" > }, > { > "name": "Version" > } > ] > } > > A resource of this type would look like: > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "environment": "test", > "feed": "mazztower", > "id": "[Local Host~/]", > "type": <<>>, > "properties": > { > "name": "WildFly Server [Local Host] [mazztower]", > "resourceConfiguration": > [ > { > "name": "Version", > "value": "8.2.0.Final" > }, > { > "name": "Hostname", > "value": "mazztower" > }, > { > "name": "Max Heap", > "value": "477626368" > } > ] > } > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From mazz at redhat.com Mon Jun 8 13:08:44 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 8 Jun 2015 13:08:44 -0400 (EDT) Subject: [Hawkular-dev] resource config and operations In-Reply-To: <01F7E111-F63E-4E55-AD2B-7D281D95F6B2@redhat.com> References: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> <01F7E111-F63E-4E55-AD2B-7D281D95F6B2@redhat.com> Message-ID: <1809341380.12564838.1433783324367.JavaMail.zimbra@redhat.com> there is no distinction between config or trait in this new stuff. In this new stuff, they are one and the same. I store these values inside inventory, not metrics. Have we come up with a design for traits? Are they handled separately and distinctly in inventory and h-metrics? Metrics are different. Metric definitions and Metric Types definitions are first-class concepts and are stored in inventory separately (resource types have explicit relationships to metric types, and resources have explicit relationships to metrics). There is no such thing for configuration properties. So I store config props definitions as properties directly on the resource type and config prop values directly on the resource as properties (these are stored in inventory). The metric data (the actual values collected) are obviously stored in h-metrics. ----- Original Message ----- > What are the distinctions between config, trait, and metric? > > > On Jun 8, 2015, at 12:27 PM, John Mazzitelli wrote: > > > > I am working in my own branch, but am about to introduce resource > > configuration and operations to the resource type metadata. This was in > > part due to the UI folks needing the hostname to show in the GUI. > > > > I wanted to let people know what this looks like - speak now if you see > > problems. > > > > The resourceType will now have as part of its attached metadata a list > > named "resourceConfiguration" which consists of config property types > > (today, there is only "name" associated with resource config property > > types, but you can envision other things like "dataType" (for boolean, > > integers, etc)). > > > > There is also a list of operations (today, consists of only a name and > > optional "operationName"). > > > > The JSON for resourceType looks like this inside inventory (this is for the > > top level "WildFly Server" type): > > > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > > "id": "WildFly Server", > > "version": "0.1", > > "properties": > > { > > "name": "WildFly Server", > > "operations": > > [ > > { > > "name": "Reload Server", > > "operationName": "reload" > > } > > ], > > "resourceConfiguration": > > [ > > { > > "name": "Hostname" > > }, > > { > > "name": "Max Heap" > > }, > > { > > "name": "Version" > > } > > ] > > } > > > > A resource of this type would look like: > > > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > > "environment": "test", > > "feed": "mazztower", > > "id": "[Local Host~/]", > > "type": <<>>, > > "properties": > > { > > "name": "WildFly Server [Local Host] [mazztower]", > > "resourceConfiguration": > > [ > > { > > "name": "Version", > > "value": "8.2.0.Final" > > }, > > { > > "name": "Hostname", > > "value": "mazztower" > > }, > > { > > "name": "Max Heap", > > "value": "477626368" > > } > > ] > > } > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > From lkrejci at redhat.com Tue Jun 9 04:15:21 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 09 Jun 2015 10:15:21 +0200 Subject: [Hawkular-dev] resource config and operations In-Reply-To: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> References: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> Message-ID: <13402399.6FQ8ryjJW7@localhost.localdomain> I am not 100% sure it is a good idea to store maps or other "rich" types as property values in inventory as that may have influence on their indexability or (altogether the ability to persist such objects). There are for sure performance implications for doing so but we need to wait for those until we have Titan running in dist. The in-memory database we're using atm should be taken with a grain of salt for any supported features - for one - transactions are only simulated using locks and property values are just java-serialized. On Monday, June 08, 2015 12:27:52 John Mazzitelli wrote: > I am working in my own branch, but am about to introduce resource > configuration and operations to the resource type metadata. This was in > part due to the UI folks needing the hostname to show in the GUI. > > I wanted to let people know what this looks like - speak now if you see > problems. > > The resourceType will now have as part of its attached metadata a list named > "resourceConfiguration" which consists of config property types (today, > there is only "name" associated with resource config property types, but > you can envision other things like "dataType" (for boolean, integers, > etc)). > > There is also a list of operations (today, consists of only a name and > optional "operationName"). > > The JSON for resourceType looks like this inside inventory (this is for the > top level "WildFly Server" type): > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "id": "WildFly Server", > "version": "0.1", > "properties": > { > "name": "WildFly Server", > "operations": > [ > { > "name": "Reload Server", > "operationName": "reload" > } > ], > "resourceConfiguration": > [ > { > "name": "Hostname" > }, > { > "name": "Max Heap" > }, > { > "name": "Version" > } > ] > } > > A resource of this type would look like: > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "environment": "test", > "feed": "mazztower", > "id": "[Local Host~/]", > "type": <<>>, > "properties": > { > "name": "WildFly Server [Local Host] [mazztower]", > "resourceConfiguration": > [ > { > "name": "Version", > "value": "8.2.0.Final" > }, > { > "name": "Hostname", > "value": "mazztower" > }, > { > "name": "Max Heap", > "value": "477626368" > } > ] > } > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From mazz at redhat.com Tue Jun 9 06:38:53 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 9 Jun 2015 06:38:53 -0400 (EDT) Subject: [Hawkular-dev] resource config and operations In-Reply-To: <13402399.6FQ8ryjJW7@localhost.localdomain> References: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> <13402399.6FQ8ryjJW7@localhost.localdomain> Message-ID: <289568046.12870061.1433846333006.JavaMail.zimbra@redhat.com> > I am not 100% sure it is a good idea to store maps or other "rich" types as > property values in inventory as that may have influence on their indexability > or (altogether the ability to persist such objects). > > There are for sure performance implications for doing so but we need to wait If this is true, then I *strongly* recommend you change the inventory API. Because in all the inventory Blueprint objects that I've seen, they define properties as a Map of Objects: @JsonProperty("properties") Map properties) When I saw this (and with lack of javadoc :)) I took this to mean I can store whatever I want (and I took this to mean it is *OK* to store whatever I want). If we want to discourage (or even not allow) the use of storing rich types, then that API should be changed, to something like: @JsonProperty("properties") Map properties) From theute at redhat.com Tue Jun 9 07:13:07 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 09 Jun 2015 13:13:07 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ Message-ID: <5576CA43.8010004@redhat.com> FYI I just requested to be added to http://www.jboss.org/docker/ This is the docker source that I propose and should move to the official GitHub Repo: https://github.com/theute/hawkular-docker-jbossorg/ We probably want to reduce the amount of docker containers we make available through various channels and Dockerfiles we maintain but that one is an important one. Thomas From hrupp at redhat.com Tue Jun 9 07:24:33 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 09 Jun 2015 13:24:33 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576CA43.8010004@redhat.com> References: <5576CA43.8010004@redhat.com> Message-ID: On 9 Jun 2015, at 13:13, Thomas Heute wrote: > I just requested to be added to http://www.jboss.org/docker/ > This is the docker source that I propose and should move to the official > GitHub Repo: > https://github.com/theute/hawkular-docker-jbossorg/ Sorry, Hawkular.org does not accept readme.md files :-> On a more serious note: the main question is probably how do we build it from the specific tag - just via mvn docker:build and then upload to dockerhub? Do I understand correctly, that those images are released together with the respective .zip/.tgz releases coming from a tag / milestone version? Heiko From theute at redhat.com Tue Jun 9 07:48:11 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 09 Jun 2015 13:48:11 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: References: <5576CA43.8010004@redhat.com> Message-ID: <5576D27B.2090605@redhat.com> On 06/09/2015 01:24 PM, Heiko W.Rupp wrote: > On 9 Jun 2015, at 13:13, Thomas Heute wrote: > >> I just requested to be added to http://www.jboss.org/docker/ >> This is the docker source that I propose and should move to the official >> GitHub Repo: >> https://github.com/theute/hawkular-docker-jbossorg/ > > Sorry, Hawkular.org does not accept readme.md files :-> It follows the https://github.com/jboss-dockerfiles/hawkular standards :) > On a more serious note: the main question is probably > how do we build it from the specific tag - just via mvn docker:build > and then upload to dockerhub? AFAIK, I push to https://github.com/jboss-dockerfiles/hawkular and the rest is handled > Do I understand correctly, that those images are released together > with the respective .zip/.tgz releases coming from a tag / milestone version? Right, that's the idea. See other projects: https://github.com/jboss-dockerfiles Thomas > > Heiko > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Jun 9 09:22:45 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 09 Jun 2015 15:22:45 +0200 Subject: [Hawkular-dev] resource config and operations In-Reply-To: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> References: <1893310119.12529488.1433780872365.JavaMail.zimbra@redhat.com> Message-ID: On 8 Jun 2015, at 18:27, John Mazzitelli wrote: > I am working in my own branch, but am about to introduce resource > configuration and operations to the resource type metadata. This was > in part due to the UI folks needing the hostname to show in the GUI. > > I wanted to let people know what this looks like - speak now if you > see problems. > > The resourceType will now have as part of its attached metadata a list > named "resourceConfiguration" which consists of config property types > (today, there is only "name" associated with resource config property > types, but you can envision other things like "dataType" (for boolean, > integers, etc)). > > There is also a list of operations (today, consists of only a name and > optional "operationName"). > > The JSON for resourceType looks like this inside inventory (this is > for the top level "WildFly Server" type): > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "id": "WildFly Server", Are we sure that for the same thing (e.g. 'WildFly 8.2") we want to have potentially different and/or duplicate definitions per tenant? > "version": "0.1", > "properties": > { > "name": "WildFly Server", > "operations": > [ > { > "name": "Reload Server", > "operationName": "reload" We need to add some security level to each operation from the very start. None vs required may be enough though. > } > ], > "resourceConfiguration": > [ > { > "name": "Hostname" > }, > { > "name": "Max Heap" > }, > { > "name": "Version" > } > ] > } > > A resource of this type would look like: > > "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf", > "environment": "test", > "feed": "mazztower", > "id": "[Local Host~/]", > "type": <<>>, Is that a "link" or embedded? From mwringe at redhat.com Tue Jun 9 09:29:56 2015 From: mwringe at redhat.com (Matt Wringe) Date: Tue, 09 Jun 2015 09:29:56 -0400 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576D27B.2090605@redhat.com> References: <5576CA43.8010004@redhat.com> <5576D27B.2090605@redhat.com> Message-ID: <5576EA54.8040107@redhat.com> I believe what is happening here is that they are using the Docker Hub automated build system with that particular github repo. This will be similar to the same setup we have right now with docker hub. I don't know who in this case sets up things like build hooks, if its the jboss-dockerfiles account holder of if we also have some permissions granted. We do not want to have to update a file in that github account everytime we build a new snaphot :) So we need to setup the automation like we currently have. The docker hub automated builds are not something I think we should be looking into at all. It lacks basic features and doesn't work nicely with normal workflows. We will not be able to: - build our own docker images - tag particular images - run tests on the images before they are published (publishing first and then being able to run tests is a backwards approach) - automatically update versions when a new release happens (this requires a bunch of extra manual steps in multiple locations) - keep things synchronized with kubernetes applications - keep most of the docker build artifacts, configurations and tests in the same place. - have an nice developer experience. For the all-in-one Hawkular I guess since someone else is looking into that I don't have to worry too much about it, but for our metrics containers I do not want them using the automated build approach. - Matt On 09/06/15 07:48 AM, Thomas Heute wrote: > > On 06/09/2015 01:24 PM, Heiko W.Rupp wrote: >> On 9 Jun 2015, at 13:13, Thomas Heute wrote: >> >>> I just requested to be added to http://www.jboss.org/docker/ >>> This is the docker source that I propose and should move to the official >>> GitHub Repo: >>> https://github.com/theute/hawkular-docker-jbossorg/ >> Sorry, Hawkular.org does not accept readme.md files :-> > It follows the https://github.com/jboss-dockerfiles/hawkular standards :) > >> On a more serious note: the main question is probably >> how do we build it from the specific tag - just via mvn docker:build >> and then upload to dockerhub? > AFAIK, I push to https://github.com/jboss-dockerfiles/hawkular and the > rest is handled > >> Do I understand correctly, that those images are released together >> with the respective .zip/.tgz releases coming from a tag / milestone version? > Right, that's the idea. See other projects: > https://github.com/jboss-dockerfiles > > Thomas > > >> 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 From theute at redhat.com Tue Jun 9 09:34:20 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 09 Jun 2015 15:34:20 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576EA54.8040107@redhat.com> References: <5576CA43.8010004@redhat.com> <5576D27B.2090605@redhat.com> <5576EA54.8040107@redhat.com> Message-ID: <5576EB5C.2050508@redhat.com> On 06/09/2015 03:29 PM, Matt Wringe wrote: > I believe what is happening here is that they are using the Docker Hub > automated build system with that particular github repo. > > This will be similar to the same setup we have right now with docker > hub. I don't know who in this case sets up things like build hooks, if > its the jboss-dockerfiles account holder of if we also have some > permissions granted. We do not want to have to update a file in that > github account everytime we build a new snaphot :) So we need to setup > the automation like we currently have. That particular repo is for tagged release AFAIK. This is what is promoted on http://www.jboss.org/docker/ I got confirmation that the only thing we have to do is push a change on https://github.com/jboss-dockerfiles/hawkular and images will end up here: https://registry.hub.docker.com/repos/jboss/ If the FROM changes, it will also rebuild our image AFAIK Thomas > The docker hub automated builds are not something I think we should be > looking into at all. It lacks basic features and doesn't work nicely > with normal workflows. > > We will not be able to: > > - build our own docker images > > - tag particular images > > - run tests on the images before they are published (publishing first > and then being able to run tests is a backwards approach) > > - automatically update versions when a new release happens (this > requires a bunch of extra manual steps in multiple locations) > > - keep things synchronized with kubernetes applications > > - keep most of the docker build artifacts, configurations and tests in > the same place. > > - have an nice developer experience. > > For the all-in-one Hawkular I guess since someone else is looking into > that I don't have to worry too much about it, but for our metrics > containers I do not want them using the automated build approach. > > - Matt > > On 09/06/15 07:48 AM, Thomas Heute wrote: >> >> On 06/09/2015 01:24 PM, Heiko W.Rupp wrote: >>> On 9 Jun 2015, at 13:13, Thomas Heute wrote: >>> >>>> I just requested to be added to http://www.jboss.org/docker/ >>>> This is the docker source that I propose and should move to the official >>>> GitHub Repo: >>>> https://github.com/theute/hawkular-docker-jbossorg/ >>> Sorry, Hawkular.org does not accept readme.md files :-> >> It follows the https://github.com/jboss-dockerfiles/hawkular standards :) >> >>> On a more serious note: the main question is probably >>> how do we build it from the specific tag - just via mvn docker:build >>> and then upload to dockerhub? >> AFAIK, I push to https://github.com/jboss-dockerfiles/hawkular and the >> rest is handled >> >>> Do I understand correctly, that those images are released together >>> with the respective .zip/.tgz releases coming from a tag / milestone version? >> Right, that's the idea. See other projects: >> https://github.com/jboss-dockerfiles >> >> Thomas >> >> >>> 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 mwringe at redhat.com Tue Jun 9 09:45:01 2015 From: mwringe at redhat.com (Matt Wringe) Date: Tue, 09 Jun 2015 09:45:01 -0400 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576EB5C.2050508@redhat.com> References: <5576CA43.8010004@redhat.com> <5576D27B.2090605@redhat.com> <5576EA54.8040107@redhat.com> <5576EB5C.2050508@redhat.com> Message-ID: <5576EDDD.1080304@redhat.com> On 09/06/15 09:34 AM, Thomas Heute wrote: > > On 06/09/2015 03:29 PM, Matt Wringe wrote: >> I believe what is happening here is that they are using the Docker Hub >> automated build system with that particular github repo. >> >> This will be similar to the same setup we have right now with docker >> hub. I don't know who in this case sets up things like build hooks, if >> its the jboss-dockerfiles account holder of if we also have some >> permissions granted. We do not want to have to update a file in that >> github account everytime we build a new snaphot :) So we need to setup >> the automation like we currently have. > That particular repo is for tagged release AFAIK. > This is what is promoted on http://www.jboss.org/docker/ Ah, ok, so it works a bit better with tagged releases. But when what happens with our current snapshot releases? I guess we still need to keep them under our Hawkular account, which means we have multiple docker hub accounts hosting similar images? > > I got confirmation that the only thing we have to do is push a change on > https://github.com/jboss-dockerfiles/hawkular and images will end up here: > https://registry.hub.docker.com/repos/jboss/ > > If the FROM changes, it will also rebuild our image AFAIK > > Thomas > >> The docker hub automated builds are not something I think we should be >> looking into at all. It lacks basic features and doesn't work nicely >> with normal workflows. >> >> We will not be able to: >> >> - build our own docker images >> >> - tag particular images >> >> - run tests on the images before they are published (publishing first >> and then being able to run tests is a backwards approach) >> >> - automatically update versions when a new release happens (this >> requires a bunch of extra manual steps in multiple locations) >> >> - keep things synchronized with kubernetes applications >> >> - keep most of the docker build artifacts, configurations and tests in >> the same place. >> >> - have an nice developer experience. >> >> For the all-in-one Hawkular I guess since someone else is looking into >> that I don't have to worry too much about it, but for our metrics >> containers I do not want them using the automated build approach. >> >> - Matt >> >> On 09/06/15 07:48 AM, Thomas Heute wrote: >>> On 06/09/2015 01:24 PM, Heiko W.Rupp wrote: >>>> On 9 Jun 2015, at 13:13, Thomas Heute wrote: >>>> >>>>> I just requested to be added to http://www.jboss.org/docker/ >>>>> This is the docker source that I propose and should move to the official >>>>> GitHub Repo: >>>>> https://github.com/theute/hawkular-docker-jbossorg/ >>>> Sorry, Hawkular.org does not accept readme.md files :-> >>> It follows the https://github.com/jboss-dockerfiles/hawkular standards :) >>> >>>> On a more serious note: the main question is probably >>>> how do we build it from the specific tag - just via mvn docker:build >>>> and then upload to dockerhub? >>> AFAIK, I push to https://github.com/jboss-dockerfiles/hawkular and the >>> rest is handled >>> >>>> Do I understand correctly, that those images are released together >>>> with the respective .zip/.tgz releases coming from a tag / milestone version? >>> Right, that's the idea. See other projects: >>> https://github.com/jboss-dockerfiles >>> >>> Thomas >>> >>> >>>> 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 From theute at redhat.com Tue Jun 9 09:54:21 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 09 Jun 2015 15:54:21 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576EDDD.1080304@redhat.com> References: <5576CA43.8010004@redhat.com> <5576D27B.2090605@redhat.com> <5576EA54.8040107@redhat.com> <5576EB5C.2050508@redhat.com> <5576EDDD.1080304@redhat.com> Message-ID: <5576F00D.3060701@redhat.com> On 06/09/2015 03:45 PM, Matt Wringe wrote: > On 09/06/15 09:34 AM, Thomas Heute wrote: >> >> On 06/09/2015 03:29 PM, Matt Wringe wrote: >>> I believe what is happening here is that they are using the Docker Hub >>> automated build system with that particular github repo. >>> >>> This will be similar to the same setup we have right now with docker >>> hub. I don't know who in this case sets up things like build hooks, if >>> its the jboss-dockerfiles account holder of if we also have some >>> permissions granted. We do not want to have to update a file in that >>> github account everytime we build a new snaphot :) So we need to setup >>> the automation like we currently have. >> That particular repo is for tagged release AFAIK. >> This is what is promoted on http://www.jboss.org/docker/ > > Ah, ok, so it works a bit better with tagged releases. But when what > happens with our current snapshot releases? I guess we still need to > keep them under our Hawkular account, which means we have multiple > docker hub accounts hosting similar images? yes that's a risk, we can talk to Marek Goldmann about it. Thomas > >> >> I got confirmation that the only thing we have to do is push a change on >> https://github.com/jboss-dockerfiles/hawkular and images will end up here: >> https://registry.hub.docker.com/repos/jboss/ >> >> If the FROM changes, it will also rebuild our image AFAIK >> >> Thomas >> >>> The docker hub automated builds are not something I think we should be >>> looking into at all. It lacks basic features and doesn't work nicely >>> with normal workflows. >>> >>> We will not be able to: >>> >>> - build our own docker images >>> >>> - tag particular images >>> >>> - run tests on the images before they are published (publishing first >>> and then being able to run tests is a backwards approach) >>> >>> - automatically update versions when a new release happens (this >>> requires a bunch of extra manual steps in multiple locations) >>> >>> - keep things synchronized with kubernetes applications >>> >>> - keep most of the docker build artifacts, configurations and tests in >>> the same place. >>> >>> - have an nice developer experience. >>> >>> For the all-in-one Hawkular I guess since someone else is looking into >>> that I don't have to worry too much about it, but for our metrics >>> containers I do not want them using the automated build approach. >>> >>> - Matt >>> >>> On 09/06/15 07:48 AM, Thomas Heute wrote: >>>> On 06/09/2015 01:24 PM, Heiko W.Rupp wrote: >>>>> On 9 Jun 2015, at 13:13, Thomas Heute wrote: >>>>> >>>>>> I just requested to be added to http://www.jboss.org/docker/ >>>>>> This is the docker source that I propose and should move to the official >>>>>> GitHub Repo: >>>>>> https://github.com/theute/hawkular-docker-jbossorg/ >>>>> Sorry, Hawkular.org does not accept readme.md files :-> >>>> It follows the https://github.com/jboss-dockerfiles/hawkular standards :) >>>> >>>>> On a more serious note: the main question is probably >>>>> how do we build it from the specific tag - just via mvn docker:build >>>>> and then upload to dockerhub? >>>> AFAIK, I push to https://github.com/jboss-dockerfiles/hawkular and the >>>> rest is handled >>>> >>>>> Do I understand correctly, that those images are released together >>>>> with the respective .zip/.tgz releases coming from a tag / milestone version? >>>> Right, that's the idea. See other projects: >>>> https://github.com/jboss-dockerfiles >>>> >>>> Thomas >>>> >>>> >>>>> 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 > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Jun 9 10:08:53 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 09 Jun 2015 16:08:53 +0200 Subject: [Hawkular-dev] http://www.jboss.org/docker/ In-Reply-To: <5576F00D.3060701@redhat.com> References: <5576CA43.8010004@redhat.com> <5576D27B.2090605@redhat.com> <5576EA54.8040107@redhat.com> <5576EB5C.2050508@redhat.com> <5576EDDD.1080304@redhat.com> <5576F00D.3060701@redhat.com> Message-ID: <4E1F50AB-BC2C-4043-A867-745CD5B02E14@redhat.com> On 9 Jun 2015, at 15:54, Thomas Heute wrote: > On 06/09/2015 03:45 PM, Matt Wringe wrote: >> happens with our current snapshot releases? I guess we still need to >> keep them under our Hawkular account, which means we have multiple >> docker hub accounts hosting similar images? > > yes that's a risk, we can talk to Marek Goldmann about it. I think we should keep the snapshot ones as this is what is used for looking at the day by day changes We just need to make clear (docs) that jboss/hawkular is "stable" and "hawkular/hawkular" is moving dev snapshot that may or may not work. From gbrown at redhat.com Tue Jun 9 10:09:06 2015 From: gbrown at redhat.com (Gary Brown) Date: Tue, 9 Jun 2015 10:09:06 -0400 (EDT) Subject: [Hawkular-dev] BTM agent relationship with Hawkular agent In-Reply-To: <1715611046.11904080.1433858242487.JavaMail.zimbra@redhat.com> Message-ID: <1191714059.11922977.1433858946833.JavaMail.zimbra@redhat.com> Hi On the team call just now, Heiko raised a question about whether the BTM agent could work with the Hawkular agent. So thought I would start this discussion thread to see what the potential options are. I currently see two issues: 1) The BTM agent must be configured on the jvm command line as a "-javaagent" to install ByteMan for instrumentation purposes. This is instantiated before the JBoss modules (and therefore subsystems etc) are initialised. 2) The hawkular agent won't necessarily be installed in all monitored servers, and instead remotely monitor some. The BTM agent would need to be installed in all servers where business transactions are executing. One type of integration that may be possible is in terms of delivering the captured business transaction information to the backend? i.e. the BTM agent locally reports it to the Hawkular agent as a relay? Thoughts? Regards Gary From hrupp at redhat.com Tue Jun 9 11:47:36 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 09 Jun 2015 17:47:36 +0200 Subject: [Hawkular-dev] Resourcetype again Message-ID: <6859E673-FB75-4957-BE7F-6966ED5203DA@redhat.com> Hey, we have said that we do no longer want the very strict resource types that we had in RHQ. We also identified that we need resource types to define capabilities like metric types with their units etc. The newest addition now are operations and resource config. I believe that for a certain kind of resource - e.g. "WildFly 8.2", that "we" manage we should not have the agent/feed supply the types, but Hawkular should do so. A user may still decide to extend that to supply its own data, but we need to be careful when dealing with it. For security relevant things we can not let the client/feed just provide resource type data, as otherwise it is too easy to work around checks. For WildFly there are a bunch of RBAC roles [1,2] that need to map to what we (will) have in Hawkular, which we may define as just what WildFly has. In fact that will be beneficial, as users will already know how WildFly RBAC works and can apply it to Hawkular. Plus if the user already has its org members in a central KeyCloak with role mappings, we can hook up to that instance and get the mappings "for free". Now for operations on WildFly (not only the classic RHQ-operations, but also modifying resource config), RBAC in WildFly is "hiding" whole sub-trees, but also (iiuc) individual attributes if you do not have the right role: role=SuperUser: [standalone at localhost:9990 /] cd /core-service=management/access [standalone at localhost:9990 access] ls audit authorization role=Monitor: [standalone at localhost:9990 /] cd /core-service=management/access [standalone at localhost:9990 access] ls audit With enough privileges it is possible to see the access definitions under /core-service=management/access=authorization/constraint=* While it is possible for WildFly to obtain the security levels (automatically) from the WildFly Metadata, we still need to find a good way to add this information into our resource types, as the UI may need to react to them and not show a restart button for user that only has the Monitoring role. In theory we could just issue the operation with the user perms and see it fail on WildFly side, but that is certainly not user-friendly and thus not desired. For other kinds of resource like Tomcat we probably need to encode the roles to the best of our knowledge. Heiko [1] http://blog.arungupta.me/role-based-access-control-wildfly-8/ [2] http://www.dzone.com/articles/configuring-rbac-jboss-eap-and From brmeyer at redhat.com Tue Jun 9 22:17:21 2015 From: brmeyer at redhat.com (Brett Meyer) Date: Tue, 9 Jun 2015 22:17:21 -0400 (EDT) Subject: [Hawkular-dev] Fwd: Artificer 1.0.0.Beta1 released, beta testers needed In-Reply-To: <293225617.14910001.1433902626390.JavaMail.zimbra@redhat.com> References: <293225617.14910001.1433902626390.JavaMail.zimbra@redhat.com> Message-ID: <328080308.14910022.1433902641401.JavaMail.zimbra@redhat.com> ----- Forwarded Message ----- From: "Brett Meyer" To: "The Core" Sent: Tuesday, June 9, 2015 10:17:06 PM Subject: Artificer 1.0.0.Beta1 released, beta testers needed Artificer 1.0.0.Beta1 is finally out. If any of you would be willing to help as beta testers, I'd sincerely appreciate it! Contact me off list. Thanks! From theute at redhat.com Wed Jun 10 03:56:13 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 10 Jun 2015 09:56:13 +0200 Subject: [Hawkular-dev] i18n Message-ID: <5577ED9D.2010703@redhat.com> While we would like, we may not have full i18n by the time of the 1.0.0.GA. That said, this needs to be taken into account now for some aspects as we don't want to have to break API or even worse do some schema update to enable i18n in a later version. So please think of this when you deal with human-facing strings like alert emails templates, some inventory or metrics metadata maybe ? For the strings in the UI itself, I leave it to the developer, since we do frequent changes in the UI it may be faster to deal with i18n at once later. For the strings that are directly taken from a component it would make sense to raise a JIRA if that is not i18nized yet. Thomas From tsegismo at redhat.com Wed Jun 10 06:11:52 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 10 Jun 2015 12:11:52 +0200 Subject: [Hawkular-dev] i18n In-Reply-To: <5577ED9D.2010703@redhat.com> References: <5577ED9D.2010703@redhat.com> Message-ID: <55780D68.4080306@redhat.com> Two things come to my mind: logging and REST API errors. * IIUC JBoss logging supports i18n. Am I wrong? * Should we extend the error code pattern from logging (HAWKULAR10055) to error responses, and have internationalized messages for them? Le 10/06/2015 09:56, Thomas Heute a ?crit : > > While we would like, we may not have full i18n by the time of the 1.0.0.GA. > > That said, this needs to be taken into account now for some aspects as > we don't want to have to break API or even worse do some schema update > to enable i18n in a later version. > > So please think of this when you deal with human-facing strings like > alert emails templates, some inventory or metrics metadata maybe ? > > For the strings in the UI itself, I leave it to the developer, since we > do frequent changes in the UI it may be faster to deal with i18n at once > later. > For the strings that are directly taken from a component it would make > sense to raise a JIRA if that is not i18nized yet. > > Thomas > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 10 06:34:01 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 10 Jun 2015 12:34:01 +0200 Subject: [Hawkular-dev] i18n In-Reply-To: <55780D68.4080306@redhat.com> References: <5577ED9D.2010703@redhat.com> <55780D68.4080306@redhat.com> Message-ID: <55781299.4070407@redhat.com> On 06/10/2015 12:11 PM, Thomas Segismont wrote: > Two things come to my mind: logging and REST API errors. > > * IIUC JBoss logging supports i18n. Am I wrong? yes AFAIk it supports it, this is why we use an ID. > > * Should we extend the error code pattern from logging (HAWKULAR10055) > to error responses, and have internationalized messages for them? Could be a good thing, but the worry is more for end-users than developers. Thomas > > Le 10/06/2015 09:56, Thomas Heute a ?crit : >> >> While we would like, we may not have full i18n by the time of the 1.0.0.GA. >> >> That said, this needs to be taken into account now for some aspects as >> we don't want to have to break API or even worse do some schema update >> to enable i18n in a later version. >> >> So please think of this when you deal with human-facing strings like >> alert emails templates, some inventory or metrics metadata maybe ? >> >> For the strings in the UI itself, I leave it to the developer, since we >> do frequent changes in the UI it may be faster to deal with i18n at once >> later. >> For the strings that are directly taken from a component it would make >> sense to raise a JIRA if that is not i18nized yet. >> >> Thomas >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Wed Jun 10 06:56:27 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 10 Jun 2015 12:56:27 +0200 Subject: [Hawkular-dev] New or noteworthy in hawkular-parent 15 Message-ID: <557817DB.9010202@redhat.com> Hi *, New or noteworthy in hawkular-parent 15 [1]: * JBoss Snapshots Maven repository is off by default. You'll need to use -Psnapshots to activate it * You can try a GUI-less release with mvn -Prelease-guiless release:clean release:prepare release:perform * com.datastax.cassandra:cassandra-driver-core is managed in parent I have sent a PR with an upgrade to parent 15 to the following projects. Please let me know if some project is missing. hawkular-alerts hawkular-agent hawkular-bus hawkular-btm hawkular-commons hawkular-inventory hawkular-metrics hawkular-accounts hawkular Best wishes, Peter [1] https://github.com/hawkular/hawkular-parent-pom/commits/15 From tsegismo at redhat.com Wed Jun 10 06:59:20 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 10 Jun 2015 12:59:20 +0200 Subject: [Hawkular-dev] i18n In-Reply-To: <55781299.4070407@redhat.com> References: <5577ED9D.2010703@redhat.com> <55780D68.4080306@redhat.com> <55781299.4070407@redhat.com> Message-ID: <55781888.5060400@redhat.com> Le 10/06/2015 12:34, Thomas Heute a ?crit : > > On 06/10/2015 12:11 PM, Thomas Segismont wrote: >> >Two things come to my mind: logging and REST API errors. >> > >> >* IIUC JBoss logging supports i18n. Am I wrong? > yes AFAIk it supports it, this is why we use an ID. Perfect > >> > >> >* Should we extend the error code pattern from logging (HAWKULAR10055) >> >to error responses, and have internationalized messages for them? > Could be a good thing, but the worry is more for end-users than developers. Wouldn't an internationalized error response be useful to UI developers? From theute at redhat.com Wed Jun 10 07:07:04 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 10 Jun 2015 13:07:04 +0200 Subject: [Hawkular-dev] i18n In-Reply-To: <55781888.5060400@redhat.com> References: <5577ED9D.2010703@redhat.com> <55780D68.4080306@redhat.com> <55781299.4070407@redhat.com> <55781888.5060400@redhat.com> Message-ID: <55781A58.6090001@redhat.com> On 06/10/2015 12:59 PM, Thomas Segismont wrote: > Le 10/06/2015 12:34, Thomas Heute a ?crit : >> >> On 06/10/2015 12:11 PM, Thomas Segismont wrote: >>>> Two things come to my mind: logging and REST API errors. >>>> >>>> * IIUC JBoss logging supports i18n. Am I wrong? >> yes AFAIk it supports it, this is why we use an ID. > > Perfect > >> >>>> >>>> * Should we extend the error code pattern from logging (HAWKULAR10055) >>>> to error responses, and have internationalized messages for them? >> Could be a good thing, but the worry is more for end-users than developers. > > Wouldn't an internationalized error response be useful to UI developers? I guess it depends if the message ends up on the console as-is. Thomas > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Wed Jun 10 09:11:03 2015 From: jsanda at redhat.com (John Sanda) Date: Wed, 10 Jun 2015 09:11:03 -0400 Subject: [Hawkular-dev] Cassandra changes Message-ID: <4945DA44-2602-4A72-8C9F-2BD249B6B20E@redhat.com> Yesterday Stefan finished up the work to move the embedded Cassandra modules out of h-metrics and into h-commons. The version has also been upgraded to 2.1.5. This should not any affect any code. Lastly the driver is now in the parent pom and has also been upgraded to 2.1.6. My apologies for the late notice. In the future I will send out the info in advance of the changes. Thanks - John From lkrejci at redhat.com Wed Jun 10 10:35:35 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Wed, 10 Jun 2015 16:35:35 +0200 Subject: [Hawkular-dev] Resourcetype again In-Reply-To: <6859E673-FB75-4957-BE7F-6966ED5203DA@redhat.com> References: <6859E673-FB75-4957-BE7F-6966ED5203DA@redhat.com> Message-ID: <12258003.x1941inYKH@localhost.localdomain> On Tuesday, June 09, 2015 17:47:36 Heiko W.Rupp wrote: > Hey, > > we have said that we do no longer want the very strict resource types > that > we had in RHQ. We also identified that we need resource types to define > capabilities like metric types with their units etc. The newest addition > now > are operations and resource config. > > I believe that for a certain kind of resource - e.g. "WildFly 8.2", that > "we" manage > we should not have the agent/feed supply the types, but Hawkular should > do so. > A user may still decide to extend that to supply its own data, but we > need to be > careful when dealing with it. This can be the first capability that the agents can declare. Even today, nothing prevents anyone with enough permissions to create the resource types a priori in the inventory. A glue component could listen on the bus and if it sees a new tenant created, it can add the to-be-predefined resource and metric types. We already have a crude "proof-of-concept" of this way of doing things with our "TemporaryHacks" class that adds the resource types needed for pinger automagically. TemporaryHacks is in the REST API overlay and therefore has direct access to the classloader and CDI "environment" of the REST API and thus can do this using the low level API calls. There is a question whether the glue component should be written in the same way as TemporaryHacks - using low level API and circumventing any auth or if it should be made a true remote component with the implication that it needs to authenticate against inventory's REST API. IMHO, we will need to figure out how auth will work in the distributed scenario anyway - either by for example having some "trusted" interface which would not be available externally but could be used by the distributed hawkular components or maybe by just really requiring every component having controlled access. I am for the latter even if it means more work because it will provide the users with the ability to lock down the perms of individual components which is good to minimize the impact in case of security breach in one of the distributed components. > > For security relevant things we can not let the client/feed just provide > resource > type data, as otherwise it is too easy to work around checks. > This could be another agent capability - to support SSO - the auth token would flow all the way down from the browser to the agent which would execute the operation as the user on the managed resource. Not sure how feasible this is but it sounds nice ;) > For WildFly there are a bunch of RBAC roles [1,2] that need to map to > what > we (will) have in Hawkular, which we may define as just what WildFly > has. I think we do that - roles in accounts are the same as roles in Wildfly. > In fact that will be beneficial, as users will already know how WildFly > RBAC works > and can apply it to Hawkular. Plus if the user already has its org > members in > a central KeyCloak with role mappings, we can hook up to that instance > and get the mappings "for free". > > Now for operations on WildFly (not only the classic RHQ-operations, but > also modifying > resource config), RBAC in WildFly is "hiding" whole sub-trees, but also > (iiuc) individual attributes > if you do not have the right role: > > role=SuperUser: > > [standalone at localhost:9990 /] cd /core-service=management/access > [standalone at localhost:9990 access] ls > audit authorization > > role=Monitor: > > [standalone at localhost:9990 /] cd /core-service=management/access > [standalone at localhost:9990 access] ls > audit > > With enough privileges it is possible to see the access definitions > under /core-service=management/access=authorization/constraint=* > > While it is possible for WildFly to obtain the security levels > (automatically) > from the WildFly Metadata, we still need to find a good way to add this > information > into our resource types, as the UI may need to react to them and not > show a > restart button for user that only has the Monitoring role. If these constraints are configurable then I think resource type is not the right place to have them. IMHO they would better fit into the resources themselves. > In theory we > could > just issue the operation with the user perms and see it fail on WildFly > side, but that > is certainly not user-friendly and thus not desired. > > For other kinds of resource like Tomcat we probably need to encode the > roles > to the best of our knowledge. > > Heiko > > > [1] http://blog.arungupta.me/role-based-access-control-wildfly-8/ > [2] http://www.dzone.com/articles/configuring-rbac-jboss-eap-and > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From lkrejci at redhat.com Thu Jun 11 09:39:38 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Thu, 11 Jun 2015 15:39:38 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 Message-ID: <3679046.Q0CT4NcL9M@localhost.localdomain> Hi all, I just wanted to let you know about the breaking change in the upcoming Inventory 0.1.0. Following the suite of metrics, inventory will no longer support the tenantID in the URL and will solely rely on Hawkular accounts to hand it the tenantID to use - i.e. it will be the tenant of the currently logged in user or of the persona passed in using the "Hawkular-Persona" header. Cheers, Lukas From lponce at redhat.com Thu Jun 11 10:17:18 2015 From: lponce at redhat.com (Lucas Ponce) Date: Thu, 11 Jun 2015 10:17:18 -0400 (EDT) Subject: [Hawkular-dev] Lightweight pub/sub Topic implemented over JGroups In-Reply-To: <1921437146.510907.1434032132141.JavaMail.zimbra@redhat.com> Message-ID: <1664472284.511547.1434032238255.JavaMail.zimbra@redhat.com> Hi, Bela commented that there is a very interesting use case of a pub/sub bus based on JGroups for scenarios where latency is very important and there are not transactions/persistence requeriments. https://github.com/belaban/pubsub I've taken a look on it and I think it was interesting. Lucas From mazz at redhat.com Thu Jun 11 10:26:59 2015 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 11 Jun 2015 10:26:59 -0400 (EDT) Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <3679046.Q0CT4NcL9M@localhost.localdomain> References: <3679046.Q0CT4NcL9M@localhost.localdomain> Message-ID: <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> I thought it was Hawkular-Tenant, not Hawkular-Persona. I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 The name "Hawkular-Persona" is a new one to me. ----- Original Message ----- > Hi all, > > I just wanted to let you know about the breaking change in the upcoming > Inventory 0.1.0. > > Following the suite of metrics, inventory will no longer support the tenantID > in the URL and will solely rely on Hawkular accounts to hand it the tenantID > to use - i.e. it will be the tenant of the currently logged in user or of the > persona passed in using the "Hawkular-Persona" header. > > Cheers, > > Lukas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Thu Jun 11 12:36:46 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 11 Jun 2015 18:36:46 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> Message-ID: <5579B91E.1090907@redhat.com> There is a branch for the integration of Inventory 0.1.0 https://github.com/hawkular/hawkular/tree/inventory-next -- P On 11/06/15 16:26, John Mazzitelli wrote: > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 > > The name "Hawkular-Persona" is a new one to me. > > ----- Original Message ----- >> Hi all, >> >> I just wanted to let you know about the breaking change in the upcoming >> Inventory 0.1.0. >> >> Following the suite of metrics, inventory will no longer support the tenantID >> in the URL and will solely rely on Hawkular accounts to hand it the tenantID >> to use - i.e. it will be the tenant of the currently logged in user or of the >> persona passed in using the "Hawkular-Persona" header. >> >> Cheers, >> >> Lukas >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Thu Jun 11 13:18:43 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Thu, 11 Jun 2015 13:18:43 -0400 (EDT) Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> Message-ID: <1915032514.12650191.1434043123139.JavaMail.zimbra@redhat.com> Hello, I hope we standardize on Hawkular-Tenant at service level. The concept of the persona is narrow and accounts specific. While we are mapping now personas to tenants that could change in the future. Also, the concepts of tenant and multi-tenancy are easier to document and understand by external consumers. If/when the individual services are decoupled and consumed by other projects or independently, there is no extra documentation needed to explain the multi-tenant capability. Thank you, Stefan ----- Original Message ----- > From: "John Mazzitelli" > To: "Discussions around Hawkular development" > Sent: Thursday, June 11, 2015 9:26:59 AM > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 > > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 > > The name "Hawkular-Persona" is a new one to me. > > ----- Original Message ----- > > Hi all, > > > > I just wanted to let you know about the breaking change in the upcoming > > Inventory 0.1.0. > > > > Following the suite of metrics, inventory will no longer support the > > tenantID > > in the URL and will solely rely on Hawkular accounts to hand it the > > tenantID > > to use - i.e. it will be the tenant of the currently logged in user or of > > the > > persona passed in using the "Hawkular-Persona" header. > > > > Cheers, > > > > Lukas > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Fri Jun 12 09:56:10 2015 From: lponce at redhat.com (Lucas Ponce) Date: Fri, 12 Jun 2015 09:56:10 -0400 (EDT) Subject: [Hawkular-dev] Alert email templates In-Reply-To: <983636771.1178661.1434116432669.JavaMail.zimbra@redhat.com> Message-ID: <4494911.1191165.1434117370861.JavaMail.zimbra@redhat.com> Hello, In hawkular-alerts, the "plugins" are responsible to "deliver" the alert information into different ways, for example, an email, mobile, snmp or whatever plugable architecture. The email is the main plugin configured in hawkular and today is very simple, it just have the basic architecture to receive the message and send a simple message. We are working to improve this architecture so the plugins will receive the full alert content and it will process it to writte a formatted message. The requeriments would be that a plugin can have a "default" template that can combine alert data to process a final email before to send. But the plugin can be configure to have several templates, for example, by tenant, localization (i18n), or even destination (for example, the email for technical recipients would be more verbose than for a CTO). So, the requeriments where I'm working on are the following: - Default template (if no one exists). - Add new templates dynamically to be used by tenant, localization (i18n) or destination. - Plain / HTML formats. I'm working for these requeriments for M2, but I would like to share these ideas to see if we are not missing anything important and we are in the same page. Also it can be interesting if we can have some idea for the template (plain text and html - if needed- ). Thanks, Lucas From hrupp at redhat.com Fri Jun 12 10:00:39 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 12 Jun 2015 16:00:39 +0200 Subject: [Hawkular-dev] Fwd: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result References: <557AD735.5020907@redhat.com> Message-ID: <0A366E91-2EA3-44F3-9C61-E8C6B5282C95@redhat.com> This sounds interesting as it would also be something like our computed resource state with some simple form of "alerting" behind it. Forwarded message: > From: David M. Lloyd > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] Wildfly start-up as service script depends > on console log to determinate start result > Date: Fri, 12 Jun 2015 07:57:25 -0500 > > This is yet another good use case for an idea I proposed at the last > couple developer meeting: the idea of configurable "availability" > services, where you add a configuration which says "when these > components and/or configured services are available, perform this > action" where the action might be to notify a load balancer, perform a > notification to humans, or even drop a file to the filesystem (which > would be directly useful to this use case). > > Note (in case someone thinks this is a great idea and runs out to > implement it right away) that when I say "configured services" I do > not > mean MSC service names; more like management capabilities where you > have > a constrained namespace and each subsystem can contribute services to > this category. > > Also note that Java 9 adds limited support for signalling unrelated > processes, though at the moment on UNIX the signals are basically > limited to TERM and KILL. > > On 06/12/2015 07:06 AM, Jason T. Greene wrote: >> >>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry >>> wrote: >>> >>> So, what purpose is this fulfilling? >>> >>> 2) How does other software solve this problem? If it's solving a >>> valid >>> problem, it seems like there would be a typical solution. >> >> The classic UNIX solution is that the daemon forks and returns, >> dropping a PID file of its child to disk, after it is done >> initializing and exits with an error code when there is a problem. >> >> Systemd added other approaches, where a daemon can signal systemd >> directly, or it can use dbus to send a message. >> >> The former can't be done efficiently in Java because it doesn't have >> a pure fork(), only an exec. Although it would be possible to emulate >> with an exec with an unacceptable hit to boot time. The latter >> options are too Linux specific. >> >> I think the best solution would be for us to add a signaling >> mechanism specifically for this purpose. We could use sun.misc.Signal >> (potentially an issue on Java 9), or we could exec the kill command >> to signal a process. >> >> We could also use a specially status file (e.g standalone.sh >> --start-status-file=blah) for a script to monitor. >> >> Thoughts? >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From lkrejci at redhat.com Fri Jun 12 10:02:52 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Fri, 12 Jun 2015 16:02:52 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <1915032514.12650191.1434043123139.JavaMail.zimbra@redhat.com> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> <1915032514.12650191.1434043123139.JavaMail.zimbra@redhat.com> Message-ID: <16486159.mZBUAu4MgK@localhost.localdomain> On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: > Hello, > > I hope we standardize on Hawkular-Tenant at service level. The concept of > the persona is narrow and accounts specific. While we are mapping now > personas to tenants that could change in the future. > > Also, the concepts of tenant and multi-tenancy are easier to document and > understand by external consumers. If/when the individual services are > decoupled and consumed by other projects or independently, there is no > extra documentation needed to explain the multi-tenant capability. > > I actually hope for quite the opposite ;) I hope we standardize on Hawkular Accounts providing auth and (help with) authz and the rest of the components using that info. Alerts and Inventory already do that. I hope Metrics will join soon. You are right that "Hawkular-Persona" is a header that "suggests" authentication rather than multi-tenancy, but that's exactly how it is used in inventory and alerts - we use accounts primarily for authentication. The fact that tenant = persona is not really that important and in fact if we decide in the future that tenant != persona, we might introduce another header, Hawkular-Tenant most probably, that will override the behavior we currently support by equating the auth and multi-tenancy (which btw. makes a lot of sense, at least for now). Metrics currently does not offer any form of authentication as far as I am aware, so an important part of the multi-tenancy picture is missing from it. IMHO the situation in inventory and alerts is much better now in that regard - we delegate the tenant creation/updates, permission grants, etc. to accounts, let it figure out what the user performing a request is in any way it chooses (basic auth, oauth, optionally override default persona with the Hawkular- Persona header, if deemed necessary) and use that to perform security checks. As a user of the current Hawkular I would find it weird to have to specify my creds/token, potentially a persona overriding header AND a tenant header if, as it is right now, the tenant id and the persona id would always be the same. I know that metrics are special and have to function outside of Hawkular, too, but when inside Hawkular, IMHO, they should blend in and not require special treatment - most of all when applying security. If you figure out a way of blending in Hawkular AND functioning on your own nicely, it'd be nice if the rest of us could reuse that solution. But at least for inventory, there is not direct requirement to run outside of Hawkular. > Thank you, > Stefan > > ----- Original Message ----- > > > From: "John Mazzitelli" > > To: "Discussions around Hawkular development" > > Sent: Thursday, June 11, 2015 9:26:59 AM > > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming > > Inventory 0.1.0 > > > > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > > > I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 > > > > The name "Hawkular-Persona" is a new one to me. > > > > ----- Original Message ----- > > > > > Hi all, > > > > > > I just wanted to let you know about the breaking change in the upcoming > > > Inventory 0.1.0. > > > > > > Following the suite of metrics, inventory will no longer support the > > > tenantID > > > in the URL and will solely rely on Hawkular accounts to hand it the > > > tenantID > > > to use - i.e. it will be the tenant of the currently logged in user or > > > of > > > the > > > persona passed in using the "Hawkular-Persona" header. > > > > > > Cheers, > > > > > > Lukas > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From theute at redhat.com Fri Jun 12 11:07:50 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 12 Jun 2015 17:07:50 +0200 Subject: [Hawkular-dev] Alert email templates In-Reply-To: <4494911.1191165.1434117370861.JavaMail.zimbra@redhat.com> References: <4494911.1191165.1434117370861.JavaMail.zimbra@redhat.com> Message-ID: <557AF5C6.8000602@redhat.com> On 06/12/2015 03:56 PM, Lucas Ponce wrote: > Hello, > > In hawkular-alerts, the "plugins" are responsible to "deliver" the alert information into different ways, for example, an email, mobile, snmp or whatever plugable architecture. > > The email is the main plugin configured in hawkular and today is very simple, it just have the basic architecture to receive the message and send a simple message. > > We are working to improve this architecture so the plugins will receive the full alert content and it will process it to writte a formatted message. > > The requeriments would be that a plugin can have a "default" template that can combine alert data to process a final email before to send. > > But the plugin can be configure to have several templates, for example, by tenant, localization (i18n), or even destination (for example, the email for technical recipients would be more verbose than for a CTO). I would simplify l18n and destination into "user preferences". It should be up to the end user to decide his preferred language (in the UI and Email) and the level of information he wants (if any). That said this can be used inside the template or a convention in the template name, but adding 2 parameters (with defaults) in the template name makes it tricky, and I would just keep i18n there. The verbosity should be a template parameter. In mustache words: {{#verbose?}} I am verbose ! {{/verbose?}} But we may need various templates for various kind of alerts (machine down != machine slow) > So, the requeriments where I'm working on are the following: > > - Default template (if no one exists). > - Add new templates dynamically to be used by tenant, localization (i18n) or destination. > - Plain / HTML formats. > > I'm working for these requeriments for M2, but I would like to share these ideas to see if we are not missing anything important and we are in the same page. > > Also it can be interesting if we can have some idea for the template (plain text and html - if needed- ). Ideally it should be customizable like this, this is targetted to a URL availability issue: From: {{fromEmail}} To: {{toEmail}} Subject: New Hawkular alert for {{resourceFullName} - {{alertId}} Body: {{firstName}} {{lastName}} This message might need your attention. {{resourceFullName} URL has been reported down since {{time}}. See the alert details at: {{alertLink}} Best regards, The hawk of Hawkular If we can't we'll have to remain generic, something like this: From: {{fromEmail}} To: {{toEmail}} Subject: New Hawkular alert for {{resourceFullName} - {{alertId}} Body: {{firstName}} {{lastName}} {{resourceFullName} has triggered an alert and needs your attention. See the alert details at: {{alertLink}} Best regards, The hawk of Hawkular (and similar in HTML format) ---------------------------- That said, we should also send an email when the alert gets resolved (by itself), bonus point if In-Reply-To can be correctly set for the same alert... Thomas > > Thanks, > Lucas > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Fri Jun 12 11:39:15 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Fri, 12 Jun 2015 11:39:15 -0400 (EDT) Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <16486159.mZBUAu4MgK@localhost.localdomain> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> <1915032514.12650191.1434043123139.JavaMail.zimbra@redhat.com> <16486159.mZBUAu4MgK@localhost.localdomain> Message-ID: <842123470.13266991.1434123555418.JavaMail.zimbra@redhat.com> Hello Lukas, You are conflating two concepts in a bad way. First is multi-tenancy and second is authentication. It just happens now the path of least resistance is to couple the concepts. The requirements for each might change over time, so coupling them straight in the design will have negative effects. Here is how Metrics approaches this: 1) 'Hawkular-Tenant' header is the tenant differentiator 2) 'Hawkular-Tenant' validation and verification is not yet defined 3) For now use a naive approach that accepts and trusts any incoming values 4) When Hawkular Accounts has the authentication filter ready, Metrics will defer decisions to Accounts. All the logic will be contained in a single filter. Some of the logic will be to map an Accounts concept (the strong guess is Persona) to 'Hawkular-Tenant'. 5) Any other service will go through a similar process as in step 4; see below ... The process to integrate Metrics into another project: 1) Find the authentication mechanism (algorithm, service, database, etc.) 2) Create a filter to integrate with the authentication source 3) Validate & verify using the external source and then translate to 'Hawkular-Tenant' My proposal revolves around keeping the individual service architecture and design clean with regards to multi-tenancy. If you do not see any value in that for Hawkular Inventory then this discussion does not benefit your project. Thank you, Stefan ----- Original Message ----- > From: "Lukas Krejci" > To: hawkular-dev at lists.jboss.org > Sent: Friday, June 12, 2015 9:02:52 AM > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 > > On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: > > Hello, > > > > I hope we standardize on Hawkular-Tenant at service level. The concept of > > the persona is narrow and accounts specific. While we are mapping now > > personas to tenants that could change in the future. > > > > Also, the concepts of tenant and multi-tenancy are easier to document and > > understand by external consumers. If/when the individual services are > > decoupled and consumed by other projects or independently, there is no > > extra documentation needed to explain the multi-tenant capability. > > > > > > I actually hope for quite the opposite ;) I hope we standardize on Hawkular > Accounts providing auth and (help with) authz and the rest of the components > using that info. Alerts and Inventory already do that. I hope Metrics will > join soon. > > You are right that "Hawkular-Persona" is a header that "suggests" > authentication rather than multi-tenancy, but that's exactly how it is used > in > inventory and alerts - we use accounts primarily for authentication. > > The fact that tenant = persona is not really that important and in fact if we > decide in the future that tenant != persona, we might introduce another > header, Hawkular-Tenant most probably, that will override the behavior we > currently support by equating the auth and multi-tenancy (which btw. makes a > lot of sense, at least for now). > > Metrics currently does not offer any form of authentication as far as I am > aware, so an important part of the multi-tenancy picture is missing from it. > > IMHO the situation in inventory and alerts is much better now in that regard > - > we delegate the tenant creation/updates, permission grants, etc. to accounts, > let it figure out what the user performing a request is in any way it chooses > (basic auth, oauth, optionally override default persona with the Hawkular- > Persona header, if deemed necessary) and use that to perform security checks. > > As a user of the current Hawkular I would find it weird to have to specify my > creds/token, potentially a persona overriding header AND a tenant header if, > as it is right now, the tenant id and the persona id would always be the > same. > > I know that metrics are special and have to function outside of Hawkular, > too, > but when inside Hawkular, IMHO, they should blend in and not require special > treatment - most of all when applying security. > > If you figure out a way of blending in Hawkular AND functioning on your own > nicely, it'd be nice if the rest of us could reuse that solution. But at > least > for inventory, there is not direct requirement to run outside of Hawkular. > > > Thank you, > > Stefan > > > > ----- Original Message ----- > > > > > From: "John Mazzitelli" > > > To: "Discussions around Hawkular development" > > > Sent: Thursday, June 11, 2015 9:26:59 AM > > > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming > > > Inventory 0.1.0 > > > > > > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > > > > > I used Hawkular-Tenant header name in my changes to support metrics 0.3.5 > > > > > > The name "Hawkular-Persona" is a new one to me. > > > > > > ----- Original Message ----- > > > > > > > Hi all, > > > > > > > > I just wanted to let you know about the breaking change in the upcoming > > > > Inventory 0.1.0. > > > > > > > > Following the suite of metrics, inventory will no longer support the > > > > tenantID > > > > in the URL and will solely rely on Hawkular accounts to hand it the > > > > tenantID > > > > to use - i.e. it will be the tenant of the currently logged in user or > > > > of > > > > the > > > > persona passed in using the "Hawkular-Persona" header. > > > > > > > > Cheers, > > > > > > > > Lukas > > > > > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Fri Jun 12 16:45:29 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Fri, 12 Jun 2015 16:45:29 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1851714849.13386277.1434139284357.JavaMail.zimbra@redhat.com> Message-ID: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> Hello Everybody, Had some great conversations and feedback this week about the release process for Hawkular Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics will implement starting next release (expected as soon as next week). Release Process: 1) Use semver as the versioning standard (http://semver.org/) 2) A scheduled release: a) is a planned release, with a set of significant changes b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) c) gets a dedicated branch from master d) gets tagged on the branch e) gets full release notes, JIRA, email communication, blog f) bits are published to JBoss Nexus and Github 3) A patch release a) needed to address urgent bugs or regression between scheduled releases b) is an increment in the PATCH version (eg. 0.4.2) c) no dedicated branch, patches are applied to the branch of a 'scheduled release' d) gets tagged on the working branch e) no release notes, blog posts, or similar communication; the only official communication will be a list of JIRAs fixed f) bits published to JBoss Nexus and Github g) all the code fixes will be applied retroactively to master Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The 'patch releases' will be created on a need basis and only if there are JIRAs reported against the 'scheduled release' or 'patch release' that need to be addressed before the next 'scheduled release'. One goal with the patch releases is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they will continue to get published from the code in the master branch. It would be great if all the projects converge on a similar process. I recognize that due to different maturity levels that might not be practical now for everybody, but it would be huge win for the entire Hawkular to make even small steps in the same direction. Thank you, Stefan Negrea Software Engineer From artur.dryomov at gmail.com Mon Jun 15 02:16:58 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 15 Jun 2015 09:16:58 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 Message-ID: Hi everyone, This year I am working on the Hawkular Android application as part of the Google Summer of Code 2015 program. I?ve spent the last week mostly on the Inventory-related expansion. The application [1] was able to list only resource types a week ago. Today it can list resources, metrics and metric data chart is coming soon [2]. The chart itself is not very universal at this point ? there is no range selection and it is pretty useless for HTTP status codes for example. But hopefully with upcoming Metrics version it will change for the best. With the help of Peter Palaga we got a proper Checkstyle and License checks hooked up to Travis, which is very useful [3]. We also moved the GitHub project from ?hawkular/android-client? to ?hawkular/hawkular-android-client? for consistency. This week I would like to work on Alerts. This will include a simple listing with resolve ability and push notifications as well. Some work was already done regarding the push area [4]. I haven?t found the source code for the Hawkugear experimental application. Is it possible to get it somewhere? Probably I?m looking for Thomas Segismont who is the author of the original post. Anyway ? ping me if you have it :-) Have a nice week! Artur. [1]: https://github.com/hawkular/hawkular-android-client [2]: https://github.com/hawkular/hawkular-android-client/pull/12 [3]: https://github.com/hawkular/hawkular-android-client/pull/8 [4]: http://www.hawkular.org/blog/2015/04/09/alert-notifiers-for-mobile-devices.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150615/a20295f9/attachment.html From gbrown at redhat.com Mon Jun 15 02:46:20 2015 From: gbrown at redhat.com (Gary Brown) Date: Mon, 15 Jun 2015 02:46:20 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> Message-ID: <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> Hi Stefan ----- Original Message ----- > Hello Everybody, > > Had some great conversations and feedback this week about the release process > for Hawkular Metrics. A few ideas emerged and this email is a summary of the > process Hawkular Metrics will implement starting next release (expected as > soon as next week). > > Release Process: > 1) Use semver as the versioning standard (http://semver.org/) The jboss/redhat convention also requires a qualifier, CR, Alpha, Final etc. > 2) A scheduled release: > a) is a planned release, with a set of significant changes > b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) > c) gets a dedicated branch from master > d) gets tagged on the branch > e) gets full release notes, JIRA, email communication, blog > f) bits are published to JBoss Nexus and Github Don't think we should create a branch for the sake of it - if required (i.e. for a patch) then can be created from the tag. > 3) A patch release > a) needed to address urgent bugs or regression between scheduled releases > b) is an increment in the PATCH version (eg. 0.4.2) > c) no dedicated branch, patches are applied to the branch of a 'scheduled > release' > d) gets tagged on the working branch > e) no release notes, blog posts, or similar communication; the only > official communication will be a list of JIRAs fixed > f) bits published to JBoss Nexus and Github > g) all the code fixes will be applied retroactively to master Not sure we are meant to release artifacts for patches? I thought patches are only for product. Community would need to build from source if they required these releases. Regards Gary > > > Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The > 'patch releases' will be created on a need basis and only if there are JIRAs > reported against the 'scheduled release' or 'patch release' that need to be > addressed before the next 'scheduled release'. One goal with the patch > releases is to avoid publish a huge number of them in a short amount of time > (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they > will continue to get published from the code in the master branch. > > > It would be great if all the projects converge on a similar process. I > recognize that due to different maturity levels that might not be practical > now for everybody, but it would be huge win for the entire Hawkular to make > even small steps in the same direction. > > > > Thank you, > Stefan Negrea > > Software Engineer > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Jun 15 03:07:21 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 15 Jun 2015 09:07:21 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: References: Message-ID: <557E79A9.6050904@redhat.com> This looks very promising, let us know once you have an apk build that we can easily try out on our phones. Thanks, Thomas. On 06/15/2015 08:16 AM, Artur Dryomov wrote: > Hi everyone, > > This year I am working on the Hawkular Android application as part of > the Google Summer of Code 2015 program. > > I?ve spent the last week mostly on the Inventory-related expansion. > > The application [1] was able to list only resource types a week ago. > Today it can list resources, metrics and metric data chart is coming > soon [2]. The chart itself is not very universal at this point ? there > is no range selection and it is pretty useless for HTTP status codes for > example. But hopefully with upcoming Metrics version it will change for > the best. With the help of Peter Palaga we got a proper Checkstyle and > License checks hooked up to Travis, which is very useful [3]. We also > moved the GitHub project from ?hawkular/android-client? to > ?hawkular/hawkular-android-client? for consistency. > > This week I would like to work on Alerts. This will include a simple > listing with resolve ability and push notifications as well. Some work > was already done regarding the push area [4]. I haven?t found the source > code for the Hawkugear experimental application. Is it possible to get > it somewhere? Probably I?m looking for Thomas Segismont who is the > author of the original post. Anyway ? ping me if you have it :-) > > Have a nice week! > Artur. > > [1]: https://github.com/hawkular/hawkular-android-client > [2]: https://github.com/hawkular/hawkular-android-client/pull/12 > [3]: https://github.com/hawkular/hawkular-android-client/pull/8 > [4]: > http://www.hawkular.org/blog/2015/04/09/alert-notifiers-for-mobile-devices.html > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Mon Jun 15 03:18:13 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 15 Jun 2015 10:18:13 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: <557E79A9.6050904@redhat.com> References: <557E79A9.6050904@redhat.com> Message-ID: You can build it yourself if you wish ? it is very simple [1]. It is still far far away from everyday use though. [1]: https://github.com/hawkular/hawkular-android-client#building -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150615/649fc878/attachment.html From theute at redhat.com Mon Jun 15 03:22:21 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 15 Jun 2015 09:22:21 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: References: <557E79A9.6050904@redhat.com> Message-ID: <557E7D2D.8020404@redhat.com> Android SDK, is really the thing that I wish not to install :) Thomas On 06/15/2015 09:18 AM, Artur Dryomov wrote: > You can build it yourself if you wish ? it is very simple [1]. It is > still far far away from everyday use though. > > [1]: https://github.com/hawkular/hawkular-android-client#building > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Mon Jun 15 03:25:25 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 15 Jun 2015 10:25:25 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: <557E7D2D.8020404@redhat.com> References: <557E79A9.6050904@redhat.com> <557E7D2D.8020404@redhat.com> Message-ID: It will be downloaded locally to ?${HOME}/.android-sdk? by default, without any octopus arms spreading around your system ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150615/0e5ad5f2/attachment.html From theute at redhat.com Mon Jun 15 03:44:54 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 15 Jun 2015 09:44:54 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> Message-ID: <557E8276.4060101@redhat.com> On 06/12/2015 10:45 PM, Stefan Negrea wrote: > Hello Everybody, > > Had some great conversations and feedback this week about the release process for Hawkular Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics will implement starting next release (expected as soon as next week). > > Release Process: > 1) Use semver as the versioning standard (http://semver.org/) > 2) A scheduled release: > a) is a planned release, with a set of significant changes > b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) > c) gets a dedicated branch from master > d) gets tagged on the branch > e) gets full release notes, JIRA, email communication, blog > f) bits are published to JBoss Nexus and Github > 3) A patch release > a) needed to address urgent bugs or regression between scheduled releases > b) is an increment in the PATCH version (eg. 0.4.2) > c) no dedicated branch, patches are applied to the branch of a 'scheduled release' > d) gets tagged on the working branch > e) no release notes, blog posts, or similar communication; the only official communication will be a list of JIRAs fixed > f) bits published to JBoss Nexus and Github > g) all the code fixes will be applied retroactively to master > > > Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The 'patch releases' will be created on a need basis and only if there are JIRAs reported against the 'scheduled release' or 'patch release' that need to be addressed before the next 'scheduled release'. One goal with the patch releases is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they will continue to get published from the code in the master branch. > > > It would be great if all the projects converge on a similar process. I recognize that due to different maturity levels that might not be practical now for everybody, but it would be huge win for the entire Hawkular to make even small steps in the same direction. Standardization of some aspects have already been defined, for JBoss projects as a whole. I said it many times, but the first one is: https://developer.jboss.org/wiki/JBossProjectVersioning Thomas > > > Thank you, > Stefan Negrea > > Software Engineer > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Mon Jun 15 03:55:30 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 15 Jun 2015 09:55:30 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: <557E79A9.6050904@redhat.com> References: <557E79A9.6050904@redhat.com> Message-ID: <2029FF2C-6EB3-4FE3-A07F-0ABE49E85B07@redhat.com> On 15 Jun 2015, at 9:07, Thomas Heute wrote: > This looks very promising, let us know once you have an apk build that > we can easily try out on our phones. You can try this one: https://dl.dropboxusercontent.com/u/21627069/android-client-heiko-debug.apk that I built on my machine. Works on Lolipop on my OpO There is a login screen issue https://issues.jboss.org/browse/KEYCLOAK-1444 that needs to be solved by Keycloak - I had a longer discussion on Friday about this in #aerogear From ppalaga at redhat.com Mon Jun 15 04:19:24 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 15 Jun 2015 10:19:24 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> Message-ID: <557E8A8C.80507@redhat.com> Hi Stefan, thanks for informing us how you will be doing things. It would be nice to hear more about your motivations for these particular decisions - see my "why"s inline. On 15/06/15 08:46, Gary Brown wrote: > Hi Stefan > > ----- Original Message ----- >> Hello Everybody, >> >> Had some great conversations and feedback this week about the release process >> for Hawkular Metrics. A few ideas emerged and this email is a summary of the >> process Hawkular Metrics will implement starting next release (expected as >> soon as next week). >> >> Release Process: >> 1) Use semver as the versioning standard (http://semver.org/) > > The jboss/redhat convention also requires a qualifier, CR, Alpha, Final etc. +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if not JBoss Versioning then why not? >> 2) A scheduled release: >> a) is a planned release, with a set of significant changes >> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) >> c) gets a dedicated branch from master Why? Esp. why don't you keep things in master as long as possible and create those 0.4.x maintenance branches only when they are really needed? Actually, what is the role of master branch in your plan? >> d) gets tagged on the branch Why not on master (if possible in the given situation)? >> e) gets full release notes, JIRA, email communication, blog >> f) bits are published to JBoss Nexus and Github > > Don't think we should create a branch for the sake of it - if required (i.e. for a patch) then can be created from the tag. >> 3) A patch release >> a) needed to address urgent bugs or regression between scheduled releases >> b) is an increment in the PATCH version (eg. 0.4.2) >> c) no dedicated branch, patches are applied to the branch of a 'scheduled >> release' >> d) gets tagged on the working branch >> e) no release notes, blog posts, or similar communication; the only >> official communication will be a list of JIRAs fixed >> f) bits published to JBoss Nexus and Github >> g) all the code fixes will be applied retroactively to master > > Not sure we are meant to release artifacts for patches? I thought patches are only for product. Community would need to build from source if they required these releases. > > Regards > Gary > >> >> >> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. Why one a month? Is there a way for me to find out at any point in time when will the next Metrics release happen? E.g. ATM it would be very helpful to know when is 0.3.5 coming? Note that rather than waiting days for the polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 coming today to be able to work on its integration into Hawkular. Thanks, -- P >> The >> 'patch releases' will be created on a need basis and only if there are JIRAs >> reported against the 'scheduled release' or 'patch release' that need to be >> addressed before the next 'scheduled release'. One goal with the patch >> releases is to avoid publish a huge number of them in a short amount of time >> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they >> will continue to get published from the code in the master branch. >> >> >> It would be great if all the projects converge on a similar process. I >> recognize that due to different maturity levels that might not be practical >> now for everybody, but it would be huge win for the entire Hawkular to make >> even small steps in the same direction. >> >> >> >> 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 theute at redhat.com Mon Jun 15 04:19:24 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 15 Jun 2015 10:19:24 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: <2029FF2C-6EB3-4FE3-A07F-0ABE49E85B07@redhat.com> References: <557E79A9.6050904@redhat.com> <2029FF2C-6EB3-4FE3-A07F-0ABE49E85B07@redhat.com> Message-ID: <557E8A8C.8000307@redhat.com> Thanks ! On 06/15/2015 09:55 AM, Heiko W.Rupp wrote: > On 15 Jun 2015, at 9:07, Thomas Heute wrote: > >> This looks very promising, let us know once you have an apk build that >> we can easily try out on our phones. > > You can try this one: > https://dl.dropboxusercontent.com/u/21627069/android-client-heiko-debug.apk > that I built on my machine. Works on Lolipop on my OpO > > There is a login screen issue > https://issues.jboss.org/browse/KEYCLOAK-1444 > that needs to be solved by Keycloak - I had a longer > discussion on Friday about this in #aerogear > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Mon Jun 15 04:21:40 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 15 Jun 2015 10:21:40 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> Message-ID: <557E8B14.6030006@redhat.com> Le 12/06/2015 22:45, Stefan Negrea a ?crit : > f) bits are published to JBoss Nexus and Github About Gihub releases page: can you make sure to upload the ptrans distribution zip, not the ptrans.jar file? The ptrans.jar file alone is useless. Also, could you share the release process doc somewhere (internally)? So that we can still release if you broke your leg :-) Don't worry it won't happen! From tsegismo at redhat.com Mon Jun 15 04:27:06 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 15 Jun 2015 10:27:06 +0200 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: References: Message-ID: <557E8C5A.4050506@redhat.com> Le 15/06/2015 08:16, Artur Dryomov a ?crit : > I haven?t found the source code for the Hawkugear experimental > application. Is it possible to get it somewhere? Probably I?m looking > for Thomas Segismont who is the author of the original post. Anyway ? > ping me if you have it :-) I haven't shared Hawkugear on Github because it's not useful. It's a generated Android project with the Aerogear snippets added. Nothing else. That said, last year I shared a Cordova prototype for interaction with RHQ alerts: https://github.com/tsegismont/rhq-alerts-mobile From ppalaga at redhat.com Mon Jun 15 04:28:53 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 15 Jun 2015 10:28:53 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <557E8B14.6030006@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <557E8B14.6030006@redhat.com> Message-ID: <557E8CC5.7070200@redhat.com> On 15/06/15 10:21, Thomas Segismont wrote: > Le 12/06/2015 22:45, Stefan Negrea a ?crit : >> f) bits are published to JBoss Nexus and Github > > About Gihub releases page: can you make sure to upload the ptrans > distribution zip, not the ptrans.jar file? The ptrans.jar file alone is > useless. > > Also, could you share the release process doc somewhere (internally)? So > that we can still release +1 for having several persons for every project who routinely alternate each other in releasing. -- P > if you broke your leg :-) Don't worry it won't > happen! > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Mon Jun 15 04:29:03 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 15 Jun 2015 11:29:03 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #3 In-Reply-To: <557E8C5A.4050506@redhat.com> References: <557E8C5A.4050506@redhat.com> Message-ID: Hey Thomas, OK, understood. I?ll write it from scratch then, no problem. Thanks! Artur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150615/ab472912/attachment.html From hrupp at redhat.com Mon Jun 15 05:11:58 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 15 Jun 2015 11:11:58 +0200 Subject: [Hawkular-dev] Git/jira workflow UPDATE Message-ID: <7C1A3AE0-5F76-41A5-9948-BCCF50FEC06D@redhat.com> Hey, I have lately seen git updates that did not directly trigger a workflow update in jira [1]. This was only sporadic. It looks like it is triggered by not putting a space at the end of the JIRA ticket id in the GitHub pr/merge See e.g. [HAWKULAR-334] and [2] where the commit title is "HAWKULAR-334: Refactored the link profile" - note the colon after the JIRA id. So please put a space at the end of the issue id. Heiko [1] https://issues.jboss.org/browse/ORG-2471 [HAWKULAR-334] https://issues.jboss.org/browse/HAWKULAR-334 [2] https://github.com/hawkular/hawkular/pull/207 From lkrejci at redhat.com Mon Jun 15 07:36:02 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 15 Jun 2015 13:36:02 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <842123470.13266991.1434123555418.JavaMail.zimbra@redhat.com> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <16486159.mZBUAu4MgK@localhost.localdomain> <842123470.13266991.1434123555418.JavaMail.zimbra@redhat.com> Message-ID: <1800188.5EZZNlYfLs@localhost.localdomain> I just hope you implement your filter as soon as possible so that all Hawkular components are authenticated against the same way. But I still think that as a user, I'd be opposed to any solution that would require me to duplicate any information - I will have to provide auth info (creds + optionally persona id). If the components need to provide any other info, given the current security model where persona == tenant, then I think that solution wouldn't be good. On Friday, June 12, 2015 11:39:15 Stefan Negrea wrote: > Hello Lukas, > > You are conflating two concepts in a bad way. First is multi-tenancy and > second is authentication. > It just happens now the path of least resistance > is to couple the concepts. The requirements for each might change over > time, so coupling them straight in the design will have negative effects. > Not only authentication but authorization also ;) That's because multi- tenancy, IMHO, doesn't make much sense without the other two.. I am not sure if multi-tenancy and authentication can be completely separated. As a user of a multi-tenant system (understood from a SaaS perspective), I would be disappointed if users "from other tenants" could access my data. So while, technically, we can understand multi-tenancy as solely a means of data separation, the end-user expectations of a multi-tenant system include access control and therefore both authentication and authorization. > Here is how Metrics approaches this: > 1) 'Hawkular-Tenant' header is the tenant differentiator > 2) 'Hawkular-Tenant' validation and verification is not yet defined > 3) For now use a naive approach that accepts and trusts any incoming values > 4) When Hawkular Accounts has the authentication filter ready , Metrics will > defer decisions to Accounts. All the logic will be contained in a single > filter. Some of the logic will be to map an Accounts concept (the strong > guess is Persona) to 'Hawkular-Tenant'. > 5) Any other service will go through a similar process as in step 4; see > > below ... > Accounts contain a single line of code for authentication - and that is reading the current principal from the session context (and assume that that principal is a keycloak principal). The rest of accounts deals with impersonation and authorization which you don't mention here at all. How do you envisage authorization to happen in metrics? > The process to integrate Metrics into another project: > 1) Find the authentication mechanism (algorithm, service, database, etc.) > 2) Create a filter to integrate with the authentication source > 3) Validate & verify using the external source and then translate to > 'Hawkular-Tenant' > > My proposal revolves around keeping the individual service architecture and > design clean with regards to multi-tenancy. If you do not see any value in > that for Hawkular Inventory then this discussion does not benefit your > project. > What you are proposing makes authentication and authorization optional, mandating a tenant. What alerts and inventory did was basically the opposite. They mandate auth and authz and make tenant optional/deduced. Users will always need to provide credentials to access the components (at least I hope so), so if there is a way of deducing additional information from that, we should IMHO be doing it. > > Thank you, > Stefan > > ----- Original Message ----- > > > From: "Lukas Krejci" > > To: hawkular-ev at lists.jboss.org > > Sent: Friday, June 12, 2015 9:02:52 AM > > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the > > upcoming Inventory 0.1.0> > > On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: > > > Hello, > > > > > > I hope we standardize on Hawkular-Tenant at service level. The concept > > > of > > > the persona is narrow and accounts specific. While we are mapping now > > > personas to tenants that could change in the future. > > > > > > Also, the concepts of tenant and multi-tenancy are easier to document > > > and > > > understand by external consumers. If/when the individual services are > > > decoupled and consumed by other projects or independently, there is no > > > extra documentation needed to explain the multi-tenant capability. > > > > I actually hope for quite the opposite ;) I hope we standardize on > > Hawkular > > Accounts providing auth and (help with) authz and the rest of the > > components using that info. Alerts and Inventory already do that. I hope > > Metrics will join soon. > > > > You are right that "Hawkular-Persona" is a header that "suggests" > > authentication rather than multi-tenancy, but that's exactly how it is > > used > > in > > inventory and alerts - we use accounts primarily for authentication. > > > > The fact that tenant = persona is not really that important and in fact if > > we decide in the future that tenant != persona, we might introduce > > another header, Hawkular-Tenant most probably, that will override the > > behavior we currently support by equating the auth and multi-tenancy > > (which btw. makes a lot of sense, at least for now). > > > > Metrics currently does not offer any form of authentication as far as I am > > aware, so an important part of the multi-tenancy picture is missing from > > it. > > > > IMHO the situation in inventory and alerts is much better now in that > > regard - > > we delegate the tenant creation/updates, permission grants, etc. to > > accounts, let it figure out what the user performing a request is in any > > way it chooses (basic auth, oauth, optionally override default persona > > with the Hawkular- Persona header, if deemed necessary) and use that to > > perform security checks. > > > > As a user of the current Hawkular I would find it weird to have to specify > > my creds/token, potentially a persona overriding header AND a tenant > > header if, as it is right now, the tenant id and the persona id would > > always be the same. > > > > I know that metrics are special and have to function outside of Hawkular, > > too, > > but when inside Hawkular, IMHO, they should blend in and not require > > special treatment - most of all when applying security. > > > > If you figure out a way of blending in Hawkular AND functioning on your > > own > > nicely, it'd be nice if the rest of us could reuse that solution. But at > > least > > for inventory, there is not direct requirement to run outside of Hawkular. > > > > > Thank you, > > > Stefan > > > > > > ----- Original Message ----- > > > > > > > From: "John Mazzitelli" > > > > To: "Discussions around Hawkular development" > > > > Sent: Thursday, June 11, 2015 9:26:59 > > > > AM > > > > Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming > > > > Inventory 0.1.0 > > > > > > > > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > > > > > > > I used Hawkular-Tenant header name in my changes to support metrics > > > > 0.3.5 > > > > > > > > The name "Hawkular-Persona" is a new one to me. > > > > > > > > ----- Original Message ----- > > > > > > > > > Hi all, > > > > > > > > > > I just wanted to let you know about the breaking change in the > > > > > upcoming > > > > > Inventory 0.1.0. > > > > > > > > > > Following the suite of metrics, inventory will no longer support the > > > > > tenantID > > > > > in the URL and will solely rely on Hawkular accounts to hand it the > > > > > tenantID > > > > > to use - i.e. it will be the tenant of the currently logged in user > > > > > or > > > > > of > > > > > the > > > > > persona passed in using the "Hawkular-Persona" header. > > > > > > > > > > Cheers, > > > > > > > > > > Lukas > > > > > > > > > > _______________________________________________ > > > > > 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 snegrea at redhat.com Mon Jun 15 08:42:16 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 15 Jun 2015 08:42:16 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> Message-ID: <1602312748.13965751.1434372136151.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Monday, June 15, 2015 1:46:20 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Hi Stefan > > ----- Original Message ----- > > Hello Everybody, > > > > Had some great conversations and feedback this week about the release > > process > > for Hawkular Metrics. A few ideas emerged and this email is a summary of > > the > > process Hawkular Metrics will implement starting next release (expected as > > soon as next week). > > > > Release Process: > > 1) Use semver as the versioning standard (http://semver.org/) > > The jboss/redhat convention also requires a qualifier, CR, Alpha, Final etc. When qualifiers will become relevant will add them to the version. Semver does not preclude the use of qualifiers, but Hawkular Metrics does not require qualifies at this time. > > > 2) A scheduled release: > > a) is a planned release, with a set of significant changes > > b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) > > c) gets a dedicated branch from master > > d) gets tagged on the branch > > e) gets full release notes, JIRA, email communication, blog > > f) bits are published to JBoss Nexus and Github > > Don't think we should create a branch for the sake of it - if required (i.e. > for a patch) then can be created from the tag. This model is not new, we've been tested it with RHQ and it worked well. It is good to have a permanent branch for some code if you expect to publish patch releases of that code. > > > 3) A patch release > > a) needed to address urgent bugs or regression between scheduled releases > > b) is an increment in the PATCH version (eg. 0.4.2) > > c) no dedicated branch, patches are applied to the branch of a 'scheduled > > release' > > d) gets tagged on the working branch > > e) no release notes, blog posts, or similar communication; the only > > official communication will be a list of JIRAs fixed > > f) bits published to JBoss Nexus and Github > > g) all the code fixes will be applied retroactively to master > > Not sure we are meant to release artifacts for patches? I thought patches are > only for product. Community would need to build from source if they required > these releases. This is an implicit requirement from the discussions I've had last week. The need was to patch (with a single commit) a previous version of Hawkular Metrics for consumption in Hawkular. Since Hawkular proper needed to consume the patched bits, publishing is the only option. Also, from the way I framed a patch release, unless somebody needs to consume fixed bits, it will not happen. If it's just a bug that can be fixed in the next scheduled release, then no code changes will be made for the affected release. Thank you, Stefan > > Regards > Gary > > > > > > > Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The > > 'patch releases' will be created on a need basis and only if there are > > JIRAs > > reported against the 'scheduled release' or 'patch release' that need to be > > addressed before the next 'scheduled release'. One goal with the patch > > releases is to avoid publish a huge number of them in a short amount of > > time > > (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; > > they > > will continue to get published from the code in the master branch. > > > > > > It would be great if all the projects converge on a similar process. I > > recognize that due to different maturity levels that might not be practical > > now for everybody, but it would be huge win for the entire Hawkular to make > > even small steps in the same direction. > > > > > > > > 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 Mon Jun 15 08:44:34 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 15 Jun 2015 08:44:34 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <557E8276.4060101@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <557E8276.4060101@redhat.com> Message-ID: <591013585.13966281.1434372274584.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Thomas Heute" > To: hawkular-dev at lists.jboss.org > Sent: Monday, June 15, 2015 2:44:54 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > > > On 06/12/2015 10:45 PM, Stefan Negrea wrote: > > Hello Everybody, > > > > Had some great conversations and feedback this week about the release > > process for Hawkular Metrics. A few ideas emerged and this email is a > > summary of the process Hawkular Metrics will implement starting next > > release (expected as soon as next week). > > > > Release Process: > > 1) Use semver as the versioning standard (http://semver.org/) > > 2) A scheduled release: > > a) is a planned release, with a set of significant changes > > b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to > > 0.5.0) > > c) gets a dedicated branch from master > > d) gets tagged on the branch > > e) gets full release notes, JIRA, email communication, blog > > f) bits are published to JBoss Nexus and Github > > 3) A patch release > > a) needed to address urgent bugs or regression between scheduled > > releases > > b) is an increment in the PATCH version (eg. 0.4.2) > > c) no dedicated branch, patches are applied to the branch of a > > 'scheduled release' > > d) gets tagged on the working branch > > e) no release notes, blog posts, or similar communication; the only > > official communication will be a list of JIRAs fixed > > f) bits published to JBoss Nexus and Github > > g) all the code fixes will be applied retroactively to master > > > > > > Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The > > 'patch releases' will be created on a need basis and only if there are > > JIRAs reported against the 'scheduled release' or 'patch release' that > > need to be addressed before the next 'scheduled release'. One goal with > > the patch releases is to avoid publish a huge number of them in a short > > amount of time (eg. 2 per day). This does not impact at all the release > > for SNAPSHOTS; they will continue to get published from the code in the > > master branch. > > > > > > It would be great if all the projects converge on a similar process. I > > recognize that due to different maturity levels that might not be > > practical now for everybody, but it would be huge win for the entire > > Hawkular to make even small steps in the same direction. > > > Standardization of some aspects have already been defined, for JBoss > projects as a whole. > > I said it many times, but the first one is: > https://developer.jboss.org/wiki/JBossProjectVersioning > > Thomas > Semver does not preclude JBoss versioning. When time comes we will adopt it in Hawkular Metrics, it's a bit too early now .... > > > > > > > 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 Mon Jun 15 08:56:45 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 15 Jun 2015 08:56:45 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <557E8A8C.80507@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <557E8A8C.80507@redhat.com> Message-ID: <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Monday, June 15, 2015 3:19:24 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Hi Stefan, thanks for informing us how you will be doing things. It > would be nice to hear more about your motivations for these particular > decisions - see my "why"s inline. > > On 15/06/15 08:46, Gary Brown wrote: > > Hi Stefan > > > > ----- Original Message ----- > >> Hello Everybody, > >> > >> Had some great conversations and feedback this week about the release > >> process > >> for Hawkular Metrics. A few ideas emerged and this email is a summary of > >> the > >> process Hawkular Metrics will implement starting next release (expected as > >> soon as next week). > >> > >> Release Process: > >> 1) Use semver as the versioning standard (http://semver.org/) > > > > The jboss/redhat convention also requires a qualifier, CR, Alpha, Final > > etc. > > +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if > not JBoss Versioning then why not? Semver does not preclude JBoss versioning. When time comes Hawkular Metrics will adopt it but it's a bit too early now .... > > >> 2) A scheduled release: > >> a) is a planned release, with a set of significant changes > >> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to > >> 0.5.0) > >> c) gets a dedicated branch from master > > Why? Esp. why don't you keep things in master as long as possible and > create those 0.4.x maintenance branches only when they are really needed? > Actually, what is the role of master branch in your plan? The model with a branch is cleaner if the plan has the expectation of patch releases. Plus, it is very easy to know where to branch when a release is cut rather than 3 months later. > > >> d) gets tagged on the branch > > Why not on master (if possible in the given situation)? Not possible. The commit with the version will only live in release branch. > > >> e) gets full release notes, JIRA, email communication, blog > >> f) bits are published to JBoss Nexus and Github > > > > Don't think we should create a branch for the sake of it - if required > > (i.e. for a patch) then can be created from the tag. > > >> 3) A patch release > >> a) needed to address urgent bugs or regression between scheduled > >> releases > >> b) is an increment in the PATCH version (eg. 0.4.2) > >> c) no dedicated branch, patches are applied to the branch of a > >> 'scheduled > >> release' > >> d) gets tagged on the working branch > >> e) no release notes, blog posts, or similar communication; the only > >> official communication will be a list of JIRAs fixed > >> f) bits published to JBoss Nexus and Github > >> g) all the code fixes will be applied retroactively to master > > > > Not sure we are meant to release artifacts for patches? I thought patches > > are only for product. Community would need to build from source if they > > required these releases. > > > > Regards > > Gary > > > >> > >> > >> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. > > Why one a month? > Is there a way for me to find out at any point in time when will the > next Metrics release happen? E.g. ATM it would be very helpful to know > when is 0.3.5 coming? Note that rather than waiting days for the > polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 > coming today to be able to work on its integration into Hawkular. There will be no other releases besides scheduled and patch releases. And this process will start with the next release (0.4.0) which will most likely happen this week. The one month timeline is what works currently for Hawkular Metrics. If you want up to date changes for Hawkular Metrics please use timed snapshots. Here is the list for 0.3.5: http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-metrics-api-jaxrs/0.3.5-SNAPSHOT/ Thank you, Stefan > > Thanks, > > -- P > > >> The > >> 'patch releases' will be created on a need basis and only if there are > >> JIRAs > >> reported against the 'scheduled release' or 'patch release' that need to > >> be > >> addressed before the next 'scheduled release'. One goal with the patch > >> releases is to avoid publish a huge number of them in a short amount of > >> time > >> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; > >> they > >> will continue to get published from the code in the master branch. > >> > >> > >> It would be great if all the projects converge on a similar process. I > >> recognize that due to different maturity levels that might not be > >> practical > >> now for everybody, but it would be huge win for the entire Hawkular to > >> make > >> even small steps in the same direction. > >> > >> > >> > >> Thank you, > >> Stefan Negrea > >> > >> Software Engineer > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Mon Jun 15 08:57:55 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 15 Jun 2015 08:57:55 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <557E8B14.6030006@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <557E8B14.6030006@redhat.com> Message-ID: <1731362149.13972376.1434373075935.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Thomas Segismont" > To: hawkular-dev at lists.jboss.org > Sent: Monday, June 15, 2015 3:21:40 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Le 12/06/2015 22:45, Stefan Negrea a ?crit : > > f) bits are published to JBoss Nexus and Github > > About Gihub releases page: can you make sure to upload the ptrans > distribution zip, not the ptrans.jar file? The ptrans.jar file alone is > useless. > > Also, could you share the release process doc somewhere (internally)? So > that we can still release if you broke your leg :-) Don't worry it won't > happen! Both recommendations noted. Thank you, Stefan > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Mon Jun 15 09:47:59 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 15 Jun 2015 15:47:59 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1602312748.13965751.1434372136151.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <1602312748.13965751.1434372136151.JavaMail.zimbra@redhat.com> Message-ID: On 15 Jun 2015, at 14:42, Stefan Negrea wrote: > When qualifiers will become relevant will add them to the version. > Semver does not preclude the use of qualifiers, but Hawkular Metrics > does not require qualifies at this time. Not Semver. But "Current Release Version Conventions..." on https://developer.jboss.org/wiki/JBossProjectVersioning From hrupp at redhat.com Mon Jun 15 09:49:18 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 15 Jun 2015 15:49:18 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <557E8A8C.80507@redhat.com> <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> Message-ID: On 15 Jun 2015, at 14:56, Stefan Negrea wrote: > The model with a branch is cleaner if the plan has the expectation of > patch releases. Plus, it is very easy to know where to branch when a > release is cut rather than 3 months later. Why? Tag point is branch point in that case? From ppalaga at redhat.com Mon Jun 15 10:00:36 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 15 Jun 2015 16:00:36 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <557E8A8C.80507@redhat.com> <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> Message-ID: <557EDA84.6030004@redhat.com> Hi Stefan, inline... On 15/06/15 14:56, Stefan Negrea wrote: > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Monday, June 15, 2015 3:19:24 AM >> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components >> >> Hi Stefan, thanks for informing us how you will be doing things. It >> would be nice to hear more about your motivations for these particular >> decisions - see my "why"s inline. >> >> On 15/06/15 08:46, Gary Brown wrote: >>> Hi Stefan >>> >>> ----- Original Message ----- >>>> Hello Everybody, >>>> >>>> Had some great conversations and feedback this week about the release >>>> process >>>> for Hawkular Metrics. A few ideas emerged and this email is a summary of >>>> the >>>> process Hawkular Metrics will implement starting next release (expected as >>>> soon as next week). >>>> >>>> Release Process: >>>> 1) Use semver as the versioning standard (http://semver.org/) >>> >>> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final >>> etc. >> >> +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if >> not JBoss Versioning then why not? > > Semver does not preclude JBoss versioning. When time comes Hawkular Metrics will adopt it but it's a bit too early now .... > >> >>>> 2) A scheduled release: >>>> a) is a planned release, with a set of significant changes >>>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to >>>> 0.5.0) >>>> c) gets a dedicated branch from master >> >> Why? Esp. why don't you keep things in master as long as possible and >> create those 0.4.x maintenance branches only when they are really needed? >> Actually, what is the role of master branch in your plan? > > The model with a branch is cleaner if the plan has the expectation of patch releases. Plus, it is very easy to know where to branch when a release is cut rather than 3 months later. Once again: could you please sum up in a single sentence what should happen in master? FWIW, I have understood already that tagging anything is not a kind of thing allowed in master. To the very opposite, I am convinced that tags are very useful in master - they mark very important milestones in the history and they naturaly mark points where the histories of maintenance branches diverge from master, if they exist or where to fork from master when there is a need to create a maintenance branch. I looked at RHQ and I must say I do not like it. >>>> d) gets tagged on the branch >> >> Why not on master (if possible in the given situation)? > > Not possible. The commit with the version will only live in release branch. > >> >>>> e) gets full release notes, JIRA, email communication, blog >>>> f) bits are published to JBoss Nexus and Github >>> >>> Don't think we should create a branch for the sake of it - if required >>> (i.e. for a patch) then can be created from the tag. >> >>>> 3) A patch release >>>> a) needed to address urgent bugs or regression between scheduled >>>> releases >>>> b) is an increment in the PATCH version (eg. 0.4.2) >>>> c) no dedicated branch, patches are applied to the branch of a >>>> 'scheduled >>>> release' >>>> d) gets tagged on the working branch >>>> e) no release notes, blog posts, or similar communication; the only >>>> official communication will be a list of JIRAs fixed >>>> f) bits published to JBoss Nexus and Github >>>> g) all the code fixes will be applied retroactively to master >>> >>> Not sure we are meant to release artifacts for patches? I thought patches >>> are only for product. Community would need to build from source if they >>> required these releases. >>> >>> Regards >>> Gary >>> >>>> >>>> >>>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. >> >> Why one a month? >> Is there a way for me to find out at any point in time when will the >> next Metrics release happen? E.g. ATM it would be very helpful to know >> when is 0.3.5 coming? Note that rather than waiting days for the >> polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 >> coming today to be able to work on its integration into Hawkular. > > > There will be no other releases besides scheduled and patch > releases.And this process will start with the next release (0.4.0) which will > most likely happen this week. The one month timeline is what works > currently for Hawkular Metrics. > > If you want up to date changes for Hawkular Metrics please use timed > snapshots. Here is the list for 0.3.5: Am I understanding you right that you do not plan to release 0.3.5? In this branch https://github.com/hawkular/hawkular/tree/metrics-next, we wait for 0.3.5 that would include the fix of the CORS bug provided to Metrics by Viliam. I hope that fulfills your definition of patch release (well, except that your definition is valid since next week of course)? We hereby kindy ask for 0.3.5 as soon as possible, because our branch is aging and we need to bring it to master as soon as possible. Please note that we cannot use a snapshot (timestamped or not) in hk master. Thanks, Peter > http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-metrics-api-jaxrs/0.3.5-SNAPSHOT/ > > > Thank you, > Stefan > >> >> Thanks, >> >> -- P >> >>>> The >>>> 'patch releases' will be created on a need basis and only if there are >>>> JIRAs >>>> reported against the 'scheduled release' or 'patch release' that need to >>>> be >>>> addressed before the next 'scheduled release'. One goal with the patch >>>> releases is to avoid publish a huge number of them in a short amount of >>>> time >>>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >>>> they >>>> will continue to get published from the code in the master branch. >>>> >>>> >>>> It would be great if all the projects converge on a similar process. I >>>> recognize that due to different maturity levels that might not be >>>> practical >>>> now for everybody, but it would be huge win for the entire Hawkular to >>>> make >>>> even small steps in the same direction. >>>> >>>> >>>> >>>> Thank you, >>>> Stefan Negrea >>>> >>>> Software Engineer >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Jun 15 10:20:28 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 15 Jun 2015 16:20:28 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1602312748.13965751.1434372136151.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <1602312748.13965751.1434372136151.JavaMail.zimbra@redhat.com> Message-ID: <557EDF2C.3010400@redhat.com> On 06/15/2015 02:42 PM, Stefan Negrea wrote: > > > ----- Original Message ----- >> From: "Gary Brown" >> To: "Discussions around Hawkular development" >> Sent: Monday, June 15, 2015 1:46:20 AM >> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components >> >> Hi Stefan >> >> ----- Original Message ----- >>> Hello Everybody, >>> >>> Had some great conversations and feedback this week about the release >>> process >>> for Hawkular Metrics. A few ideas emerged and this email is a summary of >>> the >>> process Hawkular Metrics will implement starting next release (expected as >>> soon as next week). >>> >>> Release Process: >>> 1) Use semver as the versioning standard (http://semver.org/) >> >> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final etc. > > When qualifiers will become relevant will add them to the version. Semver does not preclude the use of qualifiers, but Hawkular Metrics does not require qualifies at this time. It is required. >> >>> 2) A scheduled release: >>> a) is a planned release, with a set of significant changes >>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) >>> c) gets a dedicated branch from master >>> d) gets tagged on the branch >>> e) gets full release notes, JIRA, email communication, blog >>> f) bits are published to JBoss Nexus and Github >> >> Don't think we should create a branch for the sake of it - if required (i.e. >> for a patch) then can be created from the tag. > > This model is not new, we've been tested it with RHQ and it worked well. It is good to have a permanent branch for some code if you expect to publish patch releases of that code. > >> >>> 3) A patch release >>> a) needed to address urgent bugs or regression between scheduled releases >>> b) is an increment in the PATCH version (eg. 0.4.2) >>> c) no dedicated branch, patches are applied to the branch of a 'scheduled >>> release' >>> d) gets tagged on the working branch >>> e) no release notes, blog posts, or similar communication; the only >>> official communication will be a list of JIRAs fixed >>> f) bits published to JBoss Nexus and Github >>> g) all the code fixes will be applied retroactively to master >> >> Not sure we are meant to release artifacts for patches? I thought patches are >> only for product. Community would need to build from source if they required >> these releases. > > This is an implicit requirement from the discussions I've had last week. The need was to patch (with a single commit) a previous version of Hawkular Metrics for consumption in Hawkular. Since Hawkular proper needed to consume the patched bits, publishing is the only option. Also, from the way I framed a patch release, unless somebody needs to consume fixed bits, it will not happen. If it's just a bug that can be fixed in the next scheduled release, then no code changes will be made for the affected release. You may still need to release more often/change schedule to satisfy the main consumer which is Hawkular. Thomas > > > Thank you, > Stefan > >> >> Regards >> Gary >> >>> >>> >>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The >>> 'patch releases' will be created on a need basis and only if there are >>> JIRAs >>> reported against the 'scheduled release' or 'patch release' that need to be >>> addressed before the next 'scheduled release'. One goal with the patch >>> releases is to avoid publish a huge number of them in a short amount of >>> time >>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >>> they >>> will continue to get published from the code in the master branch. >>> >>> >>> It would be great if all the projects converge on a similar process. I >>> recognize that due to different maturity levels that might not be practical >>> now for everybody, but it would be huge win for the entire Hawkular to make >>> even small steps in the same direction. >>> >>> >>> >>> Thank you, >>> Stefan Negrea >>> >>> Software Engineer >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Mon Jun 15 10:23:29 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 15 Jun 2015 10:23:29 -0400 (EDT) Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <557EDA84.6030004@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <557E8A8C.80507@redhat.com> <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> <557EDA84.6030004@redhat.com> Message-ID: <1352554784.14027741.1434378209499.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Peter Palaga" > To: "Discussions around Hawkular development" > Sent: Monday, June 15, 2015 9:00:36 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Hi Stefan, inline... > > On 15/06/15 14:56, Stefan Negrea wrote: > > > > > > ----- Original Message ----- > >> From: "Peter Palaga" > >> To: "Discussions around Hawkular development" > >> > >> Sent: Monday, June 15, 2015 3:19:24 AM > >> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + > >> Components > >> > >> Hi Stefan, thanks for informing us how you will be doing things. It > >> would be nice to hear more about your motivations for these particular > >> decisions - see my "why"s inline. > >> > >> On 15/06/15 08:46, Gary Brown wrote: > >>> Hi Stefan > >>> > >>> ----- Original Message ----- > >>>> Hello Everybody, > >>>> > >>>> Had some great conversations and feedback this week about the release > >>>> process > >>>> for Hawkular Metrics. A few ideas emerged and this email is a summary of > >>>> the > >>>> process Hawkular Metrics will implement starting next release (expected > >>>> as > >>>> soon as next week). > >>>> > >>>> Release Process: > >>>> 1) Use semver as the versioning standard (http://semver.org/) > >>> > >>> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final > >>> etc. > >> > >> +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if > >> not JBoss Versioning then why not? > > > > Semver does not preclude JBoss versioning. When time comes Hawkular Metrics > > will adopt it but it's a bit too early now .... > > > >> > >>>> 2) A scheduled release: > >>>> a) is a planned release, with a set of significant changes > >>>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to > >>>> 0.5.0) > >>>> c) gets a dedicated branch from master > >> > >> Why? Esp. why don't you keep things in master as long as possible and > >> create those 0.4.x maintenance branches only when they are really needed? > >> Actually, what is the role of master branch in your plan? > > > > The model with a branch is cleaner if the plan has the expectation of patch > > releases. Plus, it is very easy to know where to branch when a release is > > cut rather than 3 months later. > > Once again: could you please sum up in a single sentence what should > happen in master? > > FWIW, I have understood already that tagging anything is not a kind of > thing allowed in master. > > To the very opposite, I am convinced that tags are very useful in master > - they mark very important milestones in the history and they naturaly > mark points where the histories of maintenance branches diverge from > master, if they exist or where to fork from master when there is a need > to create a maintenance branch. > > I looked at RHQ and I must say I do not like it. > > >>>> d) gets tagged on the branch > >> > >> Why not on master (if possible in the given situation)? > > > > Not possible. The commit with the version will only live in release branch. > > > >> > >>>> e) gets full release notes, JIRA, email communication, blog > >>>> f) bits are published to JBoss Nexus and Github > >>> > >>> Don't think we should create a branch for the sake of it - if required > >>> (i.e. for a patch) then can be created from the tag. > >> > >>>> 3) A patch release > >>>> a) needed to address urgent bugs or regression between scheduled > >>>> releases > >>>> b) is an increment in the PATCH version (eg. 0.4.2) > >>>> c) no dedicated branch, patches are applied to the branch of a > >>>> 'scheduled > >>>> release' > >>>> d) gets tagged on the working branch > >>>> e) no release notes, blog posts, or similar communication; the only > >>>> official communication will be a list of JIRAs fixed > >>>> f) bits published to JBoss Nexus and Github > >>>> g) all the code fixes will be applied retroactively to master > >>> > >>> Not sure we are meant to release artifacts for patches? I thought patches > >>> are only for product. Community would need to build from source if they > >>> required these releases. > >>> > >>> Regards > >>> Gary > >>> > >>>> > >>>> > >>>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. > >> > >> Why one a month? > >> Is there a way for me to find out at any point in time when will the > >> next Metrics release happen? E.g. ATM it would be very helpful to know > >> when is 0.3.5 coming? Note that rather than waiting days for the > >> polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 > >> coming today to be able to work on its integration into Hawkular. > > > > > > There will be no other releases besides scheduled and patch > > releases.And this process will start with the next release (0.4.0) which > > will > > most likely happen this week. The one month timeline is what works > > currently for Hawkular Metrics. > > > > If you want up to date changes for Hawkular Metrics please use timed > > snapshots. Here is the list for 0.3.5: > > Am I understanding you right that you do not plan to release 0.3.5? > > In this branch https://github.com/hawkular/hawkular/tree/metrics-next, > we wait for 0.3.5 that would include the fix of the CORS bug provided to > Metrics by Viliam. I hope that fulfills your definition of patch release > (well, except that your definition is valid since next week of course)? > > We hereby kindy ask for 0.3.5 as soon as possible, because our branch is > aging and we need to bring it to master as soon as possible. Please note > that we cannot use a snapshot (timestamped or not) in hk master. You are correct, 0.3.5 will never be released. The next version according to this new release plan is 0.4.0. And it should come sometimes this week, if we wrap this version in a good way. But this is versioning minutia. If you need to test with fixed code, that is available today and it was available since the fix was added on the master branch. Until the release is available please use the link below and pick a timed snapshot. > > Thanks, > > Peter > > > http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-metrics-api-jaxrs/0.3.5-SNAPSHOT/ > > > > > > Thank you, > > Stefan > > > >> > >> Thanks, > >> > >> -- P > >> > >>>> The > >>>> 'patch releases' will be created on a need basis and only if there are > >>>> JIRAs > >>>> reported against the 'scheduled release' or 'patch release' that need to > >>>> be > >>>> addressed before the next 'scheduled release'. One goal with the patch > >>>> releases is to avoid publish a huge number of them in a short amount of > >>>> time > >>>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; > >>>> they > >>>> will continue to get published from the code in the master branch. > >>>> > >>>> > >>>> It would be great if all the projects converge on a similar process. I > >>>> recognize that due to different maturity levels that might not be > >>>> practical > >>>> now for everybody, but it would be huge win for the entire Hawkular to > >>>> make > >>>> even small steps in the same direction. > >>>> > >>>> > >>>> > >>>> Thank you, > >>>> Stefan Negrea > >>>> > >>>> Software Engineer > >>>> > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Mon Jun 15 10:45:25 2015 From: jsanda at redhat.com (John Sanda) Date: Mon, 15 Jun 2015 10:45:25 -0400 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <1800188.5EZZNlYfLs@localhost.localdomain> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <16486159.mZBUAu4MgK@localhost.localdomain> <842123470.13266991.1434123555418.JavaMail.zimbra@redhat.com> <1800188.5EZZNlYfLs@localhost.localdomain> Message-ID: Comments/questions inline... > On Jun 15, 2015, at 7:36 AM, Lukas Krejci wrote: > > I just hope you implement your filter as soon as possible so that all Hawkular > components are authenticated against the same way. > > But I still think that as a user, I'd be opposed to any solution that would > require me to duplicate any information - I will have to provide auth info > (creds + optionally persona id). If the components need to provide any other > info, given the current security model where persona == tenant, then I think > that solution wouldn't be good. Why and to whom would components be providing auth info? My understanding is that we will eventually have the security filter through which all requests are routed. That filter will handle authentication/authorization so that when a request does reach the component endpoint, we can assume authentication/authorization have already been taken care of. > > On Friday, June 12, 2015 11:39:15 Stefan Negrea wrote: >> Hello Lukas, >> >> You are conflating two concepts in a bad way. First is multi-tenancy and >> second is authentication. >> It just happens now the path of least resistance >> is to couple the concepts. The requirements for each might change over >> time, so coupling them straight in the design will have negative effects. >> > > Not only authentication but authorization also ;) That's because multi- > tenancy, IMHO, doesn't make much sense without the other two.. > > I am not sure if multi-tenancy and authentication can be completely separated. > As a user of a multi-tenant system (understood from a SaaS perspective), I > would be disappointed if users "from other tenants" could access my data. Agree about data separation, and I do not think there is anything being suggested that would allow for/support this. > > So while, technically, we can understand multi-tenancy as solely a means of > data separation, the end-user expectations of a multi-tenant system include > access control and therefore both authentication and authorization. I think this conflate the two, separate concerns. As the user I should not have to know or care about the existence of other tenants. From my perspective there is my tenant and that?s it. There might be other tenants, but that should not be a concern to me as it related to authentication and authorization. For example, in a future version suppose we decide to completely replace our authentication/authorization model with something else. That should not (at least in theory) change multi tenancy. > >> Here is how Metrics approaches this: >> 1) 'Hawkular-Tenant' header is the tenant differentiator >> 2) 'Hawkular-Tenant' validation and verification is not yet defined >> 3) For now use a naive approach that accepts and trusts any incoming values >> 4) When Hawkular Accounts has the authentication filter ready , Metrics will >> defer decisions to Accounts. All the logic will be contained in a single >> filter. Some of the logic will be to map an Accounts concept (the strong >> guess is Persona) to 'Hawkular-Tenant'. >> 5) Any other service will go through a similar process as in step 4; see > >> below ... >> > > Accounts contain a single line of code for authentication - and that is > reading the current principal from the session context (and assume that that > principal is a keycloak principal). > > The rest of accounts deals with impersonation and authorization which you > don't mention here at all. How do you envisage authorization to happen in > metrics? Other than configuring/applying the filter, I do not envision metrics, nor any other component for that matter, doing authorization. That is the responsibility of accounts. > >> The process to integrate Metrics into another project: >> 1) Find the authentication mechanism (algorithm, service, database, etc.) >> 2) Create a filter to integrate with the authentication source >> 3) Validate & verify using the external source and then translate to >> 'Hawkular-Tenant' >> >> My proposal revolves around keeping the individual service architecture and >> design clean with regards to multi-tenancy. If you do not see any value in >> that for Hawkular Inventory then this discussion does not benefit your >> project. >> > > What you are proposing makes authentication and authorization optional, > mandating a tenant. What alerts and inventory did was basically the opposite. > They mandate auth and authz and make tenant optional/deduced. > > Users will always need to provide credentials to access the components (at > least I hope so), so if there is a way of deducing additional information from > that, we should IMHO be doing it. > >> >> Thank you, >> Stefan >> >> ----- Original Message ----- >> >>> From: "Lukas Krejci" > >>> To: hawkular-ev at lists.jboss.org >>> Sent: Friday, June 12, 2015 9:02:52 AM >>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the >>> upcoming Inventory 0.1.0> >>> On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: >>>> Hello, >>>> >>>> I hope we standardize on Hawkular-Tenant at service level. The concept >>>> of >>>> the persona is narrow and accounts specific. While we are mapping now >>>> personas to tenants that could change in the future. >>>> >>>> Also, the concepts of tenant and multi-tenancy are easier to document >>>> and >>>> understand by external consumers. If/when the individual services are >>>> decoupled and consumed by other projects or independently, there is no >>>> extra documentation needed to explain the multi-tenant capability. >>> >>> I actually hope for quite the opposite ;) I hope we standardize on >>> Hawkular >>> Accounts providing auth and (help with) authz and the rest of the >>> components using that info. Alerts and Inventory already do that. I hope >>> Metrics will join soon. >>> >>> You are right that "Hawkular-Persona" is a header that "suggests" >>> authentication rather than multi-tenancy, but that's exactly how it is >>> used >>> in >>> inventory and alerts - we use accounts primarily for authentication. >>> >>> The fact that tenant = persona is not really that important and in fact if >>> we decide in the future that tenant != persona, we might introduce >>> another header, Hawkular-Tenant most probably, that will override the >>> behavior we currently support by equating the auth and multi-tenancy >>> (which btw. makes a lot of sense, at least for now). >>> >>> Metrics currently does not offer any form of authentication as far as I am >>> aware, so an important part of the multi-tenancy picture is missing from >>> it. >>> >>> IMHO the situation in inventory and alerts is much better now in that >>> regard - >>> we delegate the tenant creation/updates, permission grants, etc. to >>> accounts, let it figure out what the user performing a request is in any >>> way it chooses (basic auth, oauth, optionally override default persona >>> with the Hawkular- Persona header, if deemed necessary) and use that to >>> perform security checks. >>> >>> As a user of the current Hawkular I would find it weird to have to specify >>> my creds/token, potentially a persona overriding header AND a tenant >>> header if, as it is right now, the tenant id and the persona id would >>> always be the same. >>> >>> I know that metrics are special and have to function outside of Hawkular, >>> too, >>> but when inside Hawkular, IMHO, they should blend in and not require >>> special treatment - most of all when applying security. >>> >>> If you figure out a way of blending in Hawkular AND functioning on your >>> own >>> nicely, it'd be nice if the rest of us could reuse that solution. But at >>> least >>> for inventory, there is not direct requirement to run outside of Hawkular. >>> >>>> Thank you, >>>> Stefan >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "John Mazzitelli" >>>>> To: "Discussions around Hawkular development" >>>>> Sent: Thursday, June 11, 2015 9:26:59 >>>>> AM >>>>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming >>>>> Inventory 0.1.0 >>>>> >>>>> I thought it was Hawkular-Tenant, not Hawkular-Persona. >>>>> >>>>> I used Hawkular-Tenant header name in my changes to support metrics >>>>> 0.3.5 >>>>> >>>>> The name "Hawkular-Persona" is a new one to me. >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>> Hi all, >>>>>> >>>>>> I just wanted to let you know about the breaking change in the >>>>>> upcoming >>>>>> Inventory 0.1.0. >>>>>> >>>>>> Following the suite of metrics, inventory will no longer support the >>>>>> tenantID >>>>>> in the URL and will solely rely on Hawkular accounts to hand it the >>>>>> tenantID >>>>>> to use - i.e. it will be the tenant of the currently logged in user >>>>>> or >>>>>> of >>>>>> the >>>>>> persona passed in using the "Hawkular-Persona" header. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lukas >>>>>> >>>>>> _______________________________________________ >>>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150615/d5e6fd24/attachment-0001.html From ppalaga at redhat.com Mon Jun 15 11:32:49 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 15 Jun 2015 17:32:49 +0200 Subject: [Hawkular-dev] Release Process - Hawkular Metrics + Components In-Reply-To: <1352554784.14027741.1434378209499.JavaMail.zimbra@redhat.com> References: <768642812.13397184.1434141929504.JavaMail.zimbra@redhat.com> <1884132129.14324038.1434350780231.JavaMail.zimbra@redhat.com> <557E8A8C.80507@redhat.com> <778480873.13972145.1434373005086.JavaMail.zimbra@redhat.com> <557EDA84.6030004@redhat.com> <1352554784.14027741.1434378209499.JavaMail.zimbra@redhat.com> Message-ID: <557EF021.2030702@redhat.com> Hi Stefan, inline again... On 15/06/15 16:23, Stefan Negrea wrote: > > > ----- Original Message ----- >> From: "Peter Palaga" >> To: "Discussions around Hawkular development" >> Sent: Monday, June 15, 2015 9:00:36 AM >> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components >> >> Hi Stefan, inline... >> >> On 15/06/15 14:56, Stefan Negrea wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Peter Palaga" >>>> To: "Discussions around Hawkular development" >>>> >>>> Sent: Monday, June 15, 2015 3:19:24 AM >>>> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + >>>> Components >>>> >>>> Hi Stefan, thanks for informing us how you will be doing things. It >>>> would be nice to hear more about your motivations for these particular >>>> decisions - see my "why"s inline. >>>> >>>> On 15/06/15 08:46, Gary Brown wrote: >>>>> Hi Stefan >>>>> >>>>> ----- Original Message ----- >>>>>> Hello Everybody, >>>>>> >>>>>> Had some great conversations and feedback this week about the release >>>>>> process >>>>>> for Hawkular Metrics. A few ideas emerged and this email is a summary of >>>>>> the >>>>>> process Hawkular Metrics will implement starting next release (expected >>>>>> as >>>>>> soon as next week). >>>>>> >>>>>> Release Process: >>>>>> 1) Use semver as the versioning standard (http://semver.org/) >>>>> >>>>> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final >>>>> etc. >>>> >>>> +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if >>>> not JBoss Versioning then why not? >>> >>> Semver does not preclude JBoss versioning. When time comes Hawkular Metrics >>> will adopt it but it's a bit too early now .... >>> >>>> >>>>>> 2) A scheduled release: >>>>>> a) is a planned release, with a set of significant changes >>>>>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to >>>>>> 0.5.0) >>>>>> c) gets a dedicated branch from master >>>> >>>> Why? Esp. why don't you keep things in master as long as possible and >>>> create those 0.4.x maintenance branches only when they are really needed? >>>> Actually, what is the role of master branch in your plan? >>> >>> The model with a branch is cleaner if the plan has the expectation of patch >>> releases. Plus, it is very easy to know where to branch when a release is >>> cut rather than 3 months later. >> >> Once again: could you please sum up in a single sentence what should >> happen in master? >> >> FWIW, I have understood already that tagging anything is not a kind of >> thing allowed in master. >> >> To the very opposite, I am convinced that tags are very useful in master >> - they mark very important milestones in the history and they naturaly >> mark points where the histories of maintenance branches diverge from >> master, if they exist or where to fork from master when there is a need >> to create a maintenance branch. >> >> I looked at RHQ and I must say I do not like it. >> >>>>>> d) gets tagged on the branch >>>> >>>> Why not on master (if possible in the given situation)? >>> >>> Not possible. The commit with the version will only live in release branch. >>> >>>> >>>>>> e) gets full release notes, JIRA, email communication, blog >>>>>> f) bits are published to JBoss Nexus and Github >>>>> >>>>> Don't think we should create a branch for the sake of it - if required >>>>> (i.e. for a patch) then can be created from the tag. >>>> >>>>>> 3) A patch release >>>>>> a) needed to address urgent bugs or regression between scheduled >>>>>> releases >>>>>> b) is an increment in the PATCH version (eg. 0.4.2) >>>>>> c) no dedicated branch, patches are applied to the branch of a >>>>>> 'scheduled >>>>>> release' >>>>>> d) gets tagged on the working branch >>>>>> e) no release notes, blog posts, or similar communication; the only >>>>>> official communication will be a list of JIRAs fixed >>>>>> f) bits published to JBoss Nexus and Github >>>>>> g) all the code fixes will be applied retroactively to master >>>>> >>>>> Not sure we are meant to release artifacts for patches? I thought patches >>>>> are only for product. Community would need to build from source if they >>>>> required these releases. >>>>> >>>>> Regards >>>>> Gary >>>>> >>>>>> >>>>>> >>>>>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. >>>> >>>> Why one a month? >>>> Is there a way for me to find out at any point in time when will the >>>> next Metrics release happen? E.g. ATM it would be very helpful to know >>>> when is 0.3.5 coming? Note that rather than waiting days for the >>>> polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 >>>> coming today to be able to work on its integration into Hawkular. >>> >>> >>> There will be no other releases besides scheduled and patch >>> releases.And this process will start with the next release (0.4.0) which >>> will >>> most likely happen this week. The one month timeline is what works >>> currently for Hawkular Metrics. >> > >>> If you want up to date changes for Hawkular Metrics please use timed >>> snapshots. Here is the list for 0.3.5: >> >> Am I understanding you right that you do not plan to release 0.3.5? >> >> In this branch https://github.com/hawkular/hawkular/tree/metrics-next, >> we wait for 0.3.5 that would include the fix of the CORS bug provided to >> Metrics by Viliam. I hope that fulfills your definition of patch release >> (well, except that your definition is valid since next week of course)? >> >> We hereby kindy ask for 0.3.5 as soon as possible, because our branch is >> aging and we need to bring it to master as soon as possible. Please note >> that we cannot use a snapshot (timestamped or not) in hk master. > > You are correct, 0.3.5 will never be released. The next version > according to this new release plan is 0.4.0. OK, so, now combining what you say with looking into metrics master, I understood that what we consume as 0.3.5-SNAPSHOT in our metrics-next branch will be released as 0.4.0. Sorry, I thought, that you did API breaking changes leaving us without 0.3.5 as you already wanted to do once with 0.3.2. Getting 0.3.5-SNAPSHOT as 0.4.0 this week is basically a good news, but next time, could you please set the proper expectations through changing the version in your master to suit what comes next as soon as you make the decision about the next release? > And it should come > sometimes this week, if we wrap this version in a good way. > > But this is versioning minutia. If you need to test with fixed code, > that is available today and it was available since the fix was added on > the master branch. Until the release is available please use the link > below and pick a timed snapshot. We already do what you say in the integration branch metrics-next, but merging the branch to master would break the "master releasable anytime" rule. The bottom line is that having to keep the integration branches for as long as a month does not sound feasible. Getting a Metrics release more often would be better for us. Thanks, Peter >> >> Thanks, >> >> Peter >> >>> http://origin-repository.jboss.org/nexus/content/repositories/public/org/hawkular/metrics/hawkular-metrics-api-jaxrs/0.3.5-SNAPSHOT/ >>> >>> >>> Thank you, >>> Stefan >>> >>>> >>>> Thanks, >>>> >>>> -- P >>>> >>>>>> The >>>>>> 'patch releases' will be created on a need basis and only if there are >>>>>> JIRAs >>>>>> reported against the 'scheduled release' or 'patch release' that need to >>>>>> be >>>>>> addressed before the next 'scheduled release'. One goal with the patch >>>>>> releases is to avoid publish a huge number of them in a short amount of >>>>>> time >>>>>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >>>>>> they >>>>>> will continue to get published from the code in the master branch. >>>>>> >>>>>> >>>>>> It would be great if all the projects converge on a similar process. I >>>>>> recognize that due to different maturity levels that might not be >>>>>> practical >>>>>> now for everybody, but it would be huge win for the entire Hawkular to >>>>>> make >>>>>> even small steps in the same direction. >>>>>> >>>>>> >>>>>> >>>>>> Thank you, >>>>>> Stefan Negrea >>>>>> >>>>>> Software Engineer >>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Mon Jun 15 16:14:48 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 15 Jun 2015 16:14:48 -0400 (EDT) Subject: [Hawkular-dev] attribute names have a new rule in WF9 In-Reply-To: <1240370415.2245332.1434399138942.JavaMail.zimbra@redhat.com> Message-ID: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> I didn't get any response in #wildfly, but I tested this and I found it to be true: 03:23:11 PM) mazz: I need a sanity check please. I'm trying to run unit tests on my module subsystem (via my subclass of org.jboss.as.subsystem.test.AbstractSubsystemBaseTest). My test DID work on WF8.2 but FAIL when I move to WF9 CR2. (03:23:11 PM) mazz: The error is : (03:23:11 PM) mazz: failure description: "WFLYCTL0201: Unknown attribute 'org'" (03:23:11 PM) mazz: in my custom subsystem, I have several attributes of the form "org.abc.xyz" such as: (03:23:11 PM) mazz: (03:23:44 PM) mazz: could it be possible that attribute names can no longer have "." in their names? (03:24:11 PM) mazz: I have no attributes called "org" but plenty that look like "org.some.name.here" (03:47:24 PM) mazz: uh-oh. Yeah, I thikn that's a problem (03:47:48 PM) mazz: in WildFly 9 CR2, it is no longer possible to have a dot (".") in attribute names. (03:47:50 PM) mazz: This makes me sad (03:48:06 PM) mazz: this was possible in WildFly 8.2.Final (03:48:36 PM) mazz: I just changed all my "." to "-" in my custom module subsystem extension (in the java code and the .xml) and now my tests pass (03:50:06 PM) mazz: I don't know if that is also true for element names. (03:50:25 PM) mazz: I have "org.abc.xyz" element names as well. but the error message I got just mentioned attribute name I suppose we could change these names so the "." is replaced with "-" (they are also sysprop names that are used to replace ${key} tokens in bus config files, so i used the standard "." notation for these names). What should we do? Ask WF to fix this (it probably is a bug - I doubt they meant to make that change) or just deal with it and workaround by changing our attribute names? From jshaughn at redhat.com Mon Jun 15 17:05:59 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Mon, 15 Jun 2015 17:05:59 -0400 Subject: [Hawkular-dev] attribute names have a new rule in WF9 In-Reply-To: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> References: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> Message-ID: <557F3E37.9030807@redhat.com> Sounds like a pretty bad regression. They should likely fix it. Although we may want also want to make a change to '-' instead of waiting for a fix. Bad for sysprop names, though... On 6/15/2015 4:14 PM, John Mazzitelli wrote: > I didn't get any response in #wildfly, but I tested this and I found it to be true: > > 03:23:11 PM) mazz: I need a sanity check please. I'm trying to run unit tests on my module subsystem (via my subclass of org.jboss.as.subsystem.test.AbstractSubsystemBaseTest). My test DID work on WF8.2 but FAIL when I move to WF9 CR2. > (03:23:11 PM) mazz: The error is : > (03:23:11 PM) mazz: failure description: "WFLYCTL0201: Unknown attribute 'org'" > (03:23:11 PM) mazz: in my custom subsystem, I have several attributes of the form "org.abc.xyz" such as: > (03:23:11 PM) mazz: > (03:23:44 PM) mazz: could it be possible that attribute names can no longer have "." in their names? > (03:24:11 PM) mazz: I have no attributes called "org" but plenty that look like "org.some.name.here" > (03:47:24 PM) mazz: uh-oh. Yeah, I thikn that's a problem > (03:47:48 PM) mazz: in WildFly 9 CR2, it is no longer possible to have a dot (".") in attribute names. > (03:47:50 PM) mazz: This makes me sad > (03:48:06 PM) mazz: this was possible in WildFly 8.2.Final > (03:48:36 PM) mazz: I just changed all my "." to "-" in my custom module subsystem extension (in the java code and the .xml) and now my tests pass > (03:50:06 PM) mazz: I don't know if that is also true for element names. > (03:50:25 PM) mazz: I have "org.abc.xyz" element names as well. but the error message I got just mentioned attribute name > > I suppose we could change these names so the "." is replaced with "-" (they are also sysprop names that are used to replace ${key} tokens in bus config files, so i used the standard "." notation for these names). > > What should we do? Ask WF to fix this (it probably is a bug - I doubt they meant to make that change) or just deal with it and workaround by changing our attribute names? > _______________________________________________ > 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/20150615/dd7bd39e/attachment.html From hrupp at redhat.com Tue Jun 16 03:23:04 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 09:23:04 +0200 Subject: [Hawkular-dev] Fwd: Streamlined "Start Progress" action in jboss.org JIRA References: <557EAE3A.7070502@redhat.com> Message-ID: <1E89461A-6854-4D91-BAA8-B676B462D546@redhat.com> FYI .. tl;dr : when starting to work on a JIRA, just click on the "Start progress" button. Forwarded message: > From: Vlastimil Elias > To: jboss-dev-all R&D > Subject: Streamlined "Start Progress" action in jboss.org JIRA > Date: Mon, 15 Jun 2015 12:51:38 +0200 > > Hi, > > jboss.org JIRA server running at https://issues.jboss.orgprovides > streamlined functionality of "Start Progress" action now, which is in > align with latest JIRA default workflow. > > You had to manually assign issue to yourself to be able to perform > "Start Progress" action before this change. Now, the "Start Progress" > action is available to all Assignable users (potential developers). > Status of the issue is changed and you are made issue's Assignee once > you use it, so one less click is necessary and workflow is more user > friendly. > > - See more at: > https://developer.jboss.org/en/website/blog/2015/06/15/streamlined-start-progress-action-in-jbossorg-jira#sthash.cldHYV8i.dpuf > jboss.org JIRA server provides streamlined functionality of "Start > Progress" action now, which is in align with latest JIRA default > workflow. > > You had to manually assign issue to yourself to be able to perform > "Start Progress" action before this change. Now, the "Start Progress" > action is available to all Assignable users (potential developers). > Status of the issue is changed and you are made issue's Assignee once > you use it, so one less click is necessary and workflow is more user > friendly. > > See more and discuss at > https://developer.jboss.org/en/website/blog/2015/06/15/streamlined-start-progress-action-in-jbossorg-jira > > Enjoy > > Vlastimil > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > From hrupp at redhat.com Tue Jun 16 03:28:41 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 09:28:41 +0200 Subject: [Hawkular-dev] attribute names have a new rule in WF9 In-Reply-To: <557F3E37.9030807@redhat.com> References: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> <557F3E37.9030807@redhat.com> Message-ID: <5BFBC563-A609-4183-9ADF-AD14827C471A@redhat.com> On 15 Jun 2015, at 23:05, Jay Shaughnessy wrote: > Sounds like a pretty bad regression. They should likely fix it. > Although we may want also want to make a change to '-' instead of > waiting for a fix. Bad for sysprop names, though... How exactly does that impact us? Attribute names can't be FQDN, that I understand. But why do we want them as FQDN in the first place? I see one occurence in standalone.xml Can't that just be "protocol" ? If WildFly forces a FQDN here for the protocol, then they need to support it. Otherwise we can change our side. Sysprops are in the form and seem not affected Heiko From hrupp at redhat.com Tue Jun 16 04:29:32 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 10:29:32 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) Message-ID: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> Hey, currently one can pass properties/options like the C* to use via -Dkey=value pairs to standalone.sh/bat This is a bit cumbersome and also does not work in cases, where the command line is set at "compile time" like in a Dockerfile, but the property needs to be set at run time (when docker run a pre-made image). There would be the option to set JAVA_OPTS before starting the script, but JAVA_OPTS is a) something that may apply to multiple java programs on a machine and is thus not specific b) inside standalone.conf not additive, so one has to repeat all the options from standalone.conf on JAVA_OPTS So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS that are additive to JAVA_OPTS. We need to modify standalone.sh/bat to source them (and keep the modified versions in our git repo. Alternatives could be - create wrapper scripts that set JAVA_OPTS and call standalone.sh, but that only indirectly solves [1] - as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases. I fear that may take too long. Opinions? [1] https://issues.jboss.org/browse/HAWKULAR-288 From jpkroehling at redhat.com Tue Jun 16 04:39:38 2015 From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Tue, 16 Jun 2015 10:39:38 +0200 Subject: [Hawkular-dev] Container Tests In-Reply-To: <55759F1E.4090007@redhat.com> References: <55759CE4.7070603@redhat.com> <55759F1E.4090007@redhat.com> Message-ID: <557FE0CA.6090107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/08/2015 03:56 PM, Peter Palaga wrote: >> we have any machines available to setup an environment for these >> types of tests? > > Torii maybe? -- P Torii could be a solution, as well as OS1. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVf+DKAAoJECKM1e+fkPrXcfIH/RxokaAl+6Z0j3ki3dTLfCMb yPT0zd2jXVVcVxlUpCKuQ2JnOxY07MaZ+i4D9rAjOcK28JZH8BxbOuFaPsWr9SZH dU8f45CNgCqP3X/mh1kQwUgryMCogiVlb1XoMWmBYRD+J6sbw28dJ2bKF1wgSXNf BBOBgbs7EmNLc6zmoWpfRZNno7nsbcdDNZdqPj2ap4JbzZE4VVlSZZrBnsoxmoYe j1O3V+peWXBiR9wtN49/gRDgMnzVl0E7kAVveGMBulibAng2+uAcyHgWcL5NTomf 3GfjJizioBrhMltKKUZHBNzvBYBV7pXKuddtMReNhumDP2n/A018ByjYqL9ESk0= =TpD7 -----END PGP SIGNATURE----- From jpkroehling at redhat.com Tue Jun 16 04:56:57 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 16 Jun 2015 10:56:57 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> References: <3679046.Q0CT4NcL9M@localhost.localdomain> <167852557.535618.1434032819368.JavaMail.zimbra@redhat.com> Message-ID: <557FE4D9.4070201@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/11/2015 04:26 PM, John Mazzitelli wrote: > I thought it was Hawkular-Tenant, not Hawkular-Persona. > > I used Hawkular-Tenant header name in my changes to support metrics > 0.3.5 > > The name "Hawkular-Persona" is a new one to me. At least from the Accounts' side, it was never "Hawkular-Tenant". I've seen mentions of this on the metrics side, though. For Accounts, it was always "Hawkular-Persona": http://www.hawkular.org/docs/dev/accounts.html - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVf+TZAAoJECKM1e+fkPrXk84IAJA2FPNBpXnXIHOyi27yA0J/ l5bMco8ADMBxGB/8GhNn4bXjCX03qX6ENzP4wbnuqrmrr/GJRy9FD53QM6F0b5wu n1Q4jRS4BtRIJeXp68XxMBFw2shgsjhDmQMb7Ct1XZoAaXkp8OiHhHr0Wef7af76 4Xoa/SJptHI6VoPbqB9tvqCNClLTEX0ttsj0tnQBcc2LKXy7PEnx+PxjA6aBeuQW Xu0pE1FKD3lOhAInLBvhIb70ERjTYEz2FjtaEsyKPV+GncQi9zouxThNFGBlQe5v oeyvPwIoacabcBJMf3ZGIzPnSf1SPiHfZ2s8qN/J3rDlEMJ6TiVGCPdVAQX9Suo= =6X3V -----END PGP SIGNATURE----- From jpkroehling at redhat.com Tue Jun 16 05:06:57 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Tue, 16 Jun 2015 11:06:57 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: References: <3679046.Q0CT4NcL9M@localhost.localdomain> <16486159.mZBUAu4MgK@localhost.localdomain> <842123470.13266991.1434123555418.JavaMail.zimbra@redhat.com> <1800188.5EZZNlYfLs@localhost.localdomain> Message-ID: <557FE731.7060303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/15/2015 04:45 PM, John Sanda wrote: > Why and to whom would components be providing auth info? My > understanding is that we will eventually have the security filter > through which all requests are routed. That filter will handle > authentication/authorization so that when a request does reach the > component endpoint, we can assume authentication/authorization > have already been taken care of. As it is right now, Accounts provides an API for permission checking, so, individual components can check if the current "persona" has the required permissions to perform the operation on the "resource". More about it can be found on the documentation: http://www.hawkular.org/docs/dev/accounts.html There's a JIRA for supporting security-by-annotations, but it's not something that's on top of my queue right now. > I think this conflate the two, separate concerns. As the user I > should not have to know or care about the existence of other > tenants. From my perspective there is my tenant and that?s it. > There might be other tenants, but that should not be a concern to > me as it related to authentication and authorization. For example, > in a future version suppose we decide to completely replace our > authentication/authorization model with something else. That should > not (at least in theory) change multi tenancy. That's not how we defined it. An user can (and potentially will) belong to more than one organization, so, an user might belong and "act-as" different organizations, effectively being different "personas" . So, while I have only one registered account, I might be sending requests as different personas. > Other than configuring/applying the filter, I do not envision > metrics, nor any other component for that matter, doing > authorization. That is the responsibility of accounts. Quite the opposite. Authentication is done 100% by Accounts, Authorizations is done by the individual components, with the tools provided by Accounts. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVf+cxAAoJECKM1e+fkPrXpYAH/1KCMgKr5N8p2qc15Dve3pyO Sa4bC5+XdztY4wXb9jHGUqQYgrqjyeAiMnOaL++sIzqEUdw3OQC1XbDrb5GHP/NW qMulkoZjRZgjMGLVZ4bZGunMzc3t0gDyJ5l5w9GwQp7c8NMWPMRuAak3PGP3XZg4 wg+1/J+2AnFCgIo2QY46FZFHeO/Nt54nkSWFpdorBpzX6wIMSlYwzMptCKMv5+Su ri8QjKz1vOnBFs+2wEfAbZQg8iyiUtQ4iTMlTv9xFxqqAj702vrhjvetMmqsuPR/ d7p/Qa7zqFNBi52AIoQmvBvyyPDlhACwkyClw0hM1COiaDOC3vUQN3yCt150laY= =ASGv -----END PGP SIGNATURE----- From ppalaga at redhat.com Tue Jun 16 05:50:16 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 16 Jun 2015 11:50:16 +0200 Subject: [Hawkular-dev] Import order Message-ID: <557FF158.2000708@redhat.com> Hi Mazz, While I can remember some basic discussion about the order Java imports, I do not remember at all what was the result. I saw that you added Eclipse prefs for import order to dev tools which is definitely good https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder Do Idea prefs contain the same settings? Are there projects using these settings consequently? But did we say we would enforce the imports order by checkstyle? They have a rule for that: http://checkstyle.sourceforge.net/config_imports.html#ImportOrder Its a pity that we have not done it earlier. Thanks, Peter From tsegismo at redhat.com Tue Jun 16 06:14:46 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 16 Jun 2015 12:14:46 +0200 Subject: [Hawkular-dev] Import order In-Reply-To: <557FF158.2000708@redhat.com> References: <557FF158.2000708@redhat.com> Message-ID: <557FF716.3080100@redhat.com> Le 16/06/2015 11:50, Peter Palaga a ?crit : > Hi Mazz, > > While I can remember some basic discussion about the order Java imports, > I do not remember at all what was the result. > > I saw that you added Eclipse prefs for import order to dev tools which > is definitely good > https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder > > Do Idea prefs contain the same settings? Yes, they were built by Lucas and reviewed by me. > > Are there projects using these settings consequently? All projects _should_ be using the same. > > But did we say we would enforce the imports order by checkstyle? We didn't talk about that. I have recently commented on GitHub that import order was the only thing not checked yet, and we keep on seeing PR with many lines of import order differences. To me, it shows that formatting rules, if not enforced, are not naturally observed. > They have a rule for that: > http://checkstyle.sourceforge.net/config_imports.html#ImportOrder +1 for adding > > Its a pity that we have not done it earlier. > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Tue Jun 16 06:18:00 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 16 Jun 2015 12:18:00 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> Message-ID: <557FF7D8.90306@redhat.com> Le 16/06/2015 10:29, Heiko W.Rupp a ?crit : > We need to modify standalone.sh/bat to source them (and keep the > modified versions in our git repo. I'd rather modify standalone.conf (and WIN equivalent) instead. This file is meant for that, create/modify env vars before the server is started. From mazz at redhat.com Tue Jun 16 09:16:22 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 16 Jun 2015 09:16:22 -0400 (EDT) Subject: [Hawkular-dev] Import order In-Reply-To: <557FF158.2000708@redhat.com> References: <557FF158.2000708@redhat.com> Message-ID: <452848654.2648540.1434460582103.JavaMail.zimbra@redhat.com> Yes, we agreed to an order. I don't know about IDEA, but I think they have the ability to do the same. The order agreed to was: STATIC IMPORTS FIRST - java, javax, org, com (in that order) NON-STATIC IMPORTS NEXT - java, javax, org, com (in that order) I assumed there was already a checkstyle rule in place for this. ----- Original Message ----- > Hi Mazz, > > While I can remember some basic discussion about the order Java imports, > I do not remember at all what was the result. > > I saw that you added Eclipse prefs for import order to dev tools which > is definitely good > https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder > > Do Idea prefs contain the same settings? > > Are there projects using these settings consequently? > > But did we say we would enforce the imports order by checkstyle? > They have a rule for that: > http://checkstyle.sourceforge.net/config_imports.html#ImportOrder > > Its a pity that we have not done it earlier. > > Thanks, > > Peter > From mazz at redhat.com Tue Jun 16 09:27:35 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 16 Jun 2015 09:27:35 -0400 (EDT) Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> Message-ID: <2084944584.2661828.1434461255306.JavaMail.zimbra@redhat.com> My opinion is don't keep our own versions of modified WildFly files in our own repositories as they will inevitably go stale and out of date. We can do tricks in our mvn poms and assembly scripts to alter them during the build (using ant scripts or whatever). We can look into standalone.conf (don't they provide something like this?) Or contribute the change back to WildFly folks. Worst case is we keep our own copies of modified WildFly files - but I just don't like that option. ----- Original Message ----- > Hey, > > currently one can pass properties/options like the C* to use > via -Dkey=value pairs to standalone.sh/bat > > This is a bit cumbersome and also does not work in cases, where > the command line is set at "compile time" like in a Dockerfile, > but the property needs to be set at run time (when docker run > a pre-made image). > > There would be the option to set JAVA_OPTS before starting > the script, but JAVA_OPTS is > a) something that may apply to multiple java programs on a machine > and is thus not specific > b) inside standalone.conf not additive, so one has to repeat all the > options from standalone.conf on JAVA_OPTS > > So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS > that are additive to JAVA_OPTS. > > We need to modify standalone.sh/bat to source them (and keep the > modified versions in our git repo. > > Alternatives could be > - create wrapper scripts that set JAVA_OPTS and call standalone.sh, > but that only indirectly solves [1] > - as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases. > I fear that may take too long. > > Opinions? > > > [1] https://issues.jboss.org/browse/HAWKULAR-288 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Tue Jun 16 09:32:12 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 16 Jun 2015 09:32:12 -0400 (EDT) Subject: [Hawkular-dev] attribute names have a new rule in WF9 In-Reply-To: <5BFBC563-A609-4183-9ADF-AD14827C471A@redhat.com> References: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> <557F3E37.9030807@redhat.com> <5BFBC563-A609-4183-9ADF-AD14827C471A@redhat.com> Message-ID: <1359944087.2663969.1434461532090.JavaMail.zimbra@redhat.com> These aren't FQDN java names - these are sysprop names. They are like this because these are actually used to "pass through" to the active mq broker configuration file. I could name them something simpler, but the idea was you can definitely tell which ones were sysprops to be passed through (and in the future we are going to need more of these to further configure the bus broker). This worked in 8.2. They didn't care what our names are of the attributes. Something broke in 9. ----- Original Message ----- > On 15 Jun 2015, at 23:05, Jay Shaughnessy wrote: > > > Sounds like a pretty bad regression. They should likely fix it. > > Although we may want also want to make a change to '-' instead of > > waiting for a fix. Bad for sysprop names, though... > > How exactly does that impact us? > Attribute names can't be FQDN, that I understand. > But why do we want them as FQDN in the first place? > I see one occurence in standalone.xml > > org.hawkular.bus.broker.connector.protocol="tcp" > socket-binding="org.hawkular.bus.broker"/> > > Can't that just be "protocol" ? > > If WildFly forces a FQDN here for the protocol, then they need to > support it. Otherwise we can change our side. > > Sysprops are in the form > > > > and seem not affected > > Heiko > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mwringe at redhat.com Tue Jun 16 09:34:07 2015 From: mwringe at redhat.com (Matt Wringe) Date: Tue, 16 Jun 2015 09:34:07 -0400 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> Message-ID: <558025CF.2080307@redhat.com> On 16/06/15 04:29 AM, Heiko W.Rupp wrote: > Hey, > > currently one can pass properties/options like the C* to use > via -Dkey=value pairs to standalone.sh/bat > > This is a bit cumbersome and also does not work in cases, where > the command line is set at "compile time" like in a Dockerfile, > but the property needs to be set at run time (when docker run > a pre-made image). You can specify the default start options in the dockerfile, which allows for a simple install of that image. But you can also pass your own options when you go to first start your docker image, as well as overwrite them in the kubernetes configuration. Setting the options via a command line option is the easiest option when dealing with docker images and kubernetes, otherwise you need to jump through a bunch of hoops. I would really like to keep this option available if possible. > > There would be the option to set JAVA_OPTS before starting > the script, but JAVA_OPTS is > a) something that may apply to multiple java programs on a machine > and is thus not specific > b) inside standalone.conf not additive, so one has to repeat all the > options from standalone.conf on JAVA_OPTS > > So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS > that are additive to JAVA_OPTS. > > We need to modify standalone.sh/bat to source them (and keep the > modified versions in our git repo. > > Alternatives could be > - create wrapper scripts that set JAVA_OPTS and call standalone.sh, > but that only indirectly solves [1] > - as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases. > I fear that may take too long. > > Opinions? > > > [1] https://issues.jboss.org/browse/HAWKULAR-288 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From theute at redhat.com Tue Jun 16 10:07:53 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 16 Jun 2015 16:07:53 +0200 Subject: [Hawkular-dev] attribute names have a new rule in WF9 In-Reply-To: <1359944087.2663969.1434461532090.JavaMail.zimbra@redhat.com> References: <2068821628.2247551.1434399288317.JavaMail.zimbra@redhat.com> <557F3E37.9030807@redhat.com> <5BFBC563-A609-4183-9ADF-AD14827C471A@redhat.com> <1359944087.2663969.1434461532090.JavaMail.zimbra@redhat.com> Message-ID: <55802DB9.3050008@redhat.com> Tomas just answered on #wildfly: BTW mazz found either an issue or a deliberate change in WF9. subsystem attributes names used to accept things like "foo.bar" now it chokes on the "." ctomc, do you know who we can annoy to make sure that this is expected and we need to change or if that's a bug and going to change back theute i would be the one that you would need to annoy but all i can tell you that this is done on purpose "." is special charachers that cannot be part of attribute name :-/ as it is used for "enhaced syntax" resolving in cli/mgmt tools and "-" is safe ? yes https://issues.jboss.org/browse/WFCORE-460 jira [WFCORE-460] Extended sytnax for read/write-attribute [Resolved (Done) Sub-task, Major, Tomaz Cerar] https://issues.jboss.org/browse/WFCORE-460 we added support for some neat stuff https://gist.github.com/ctomc/91055a6f4e7502dcd130 on top of my head, forbiden chars are .[]() and few more Thomas On 06/16/2015 03:32 PM, John Mazzitelli wrote: > These aren't FQDN java names - these are sysprop names. They are like this because these are actually used to "pass through" to the active mq broker configuration file. I could name them something simpler, but the idea was you can definitely tell which ones were sysprops to be passed through (and in the future we are going to need more of these to further configure the bus broker). > > This worked in 8.2. They didn't care what our names are of the attributes. Something broke in 9. > > ----- Original Message ----- > > On 15 Jun 2015, at 23:05, Jay Shaughnessy wrote: > > > >> Sounds like a pretty bad regression. They should likely fix it. > >> Although we may want also want to make a change to '-' instead of > >> waiting for a fix. Bad for sysprop names, though... > > > > How exactly does that impact us? > > Attribute names can't be FQDN, that I understand. > > But why do we want them as FQDN in the first place? > > I see one occurence in standalone.xml > > > > > org.hawkular.bus.broker.connector.protocol="tcp" > > socket-binding="org.hawkular.bus.broker"/> > > > > Can't that just be "protocol" ? > > > > If WildFly forces a FQDN here for the protocol, then they need to > > support it. Otherwise we can change our side. > > > > Sysprops are in the form > > > > > > > > and seem not affected > > > > 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 > From ppalaga at redhat.com Tue Jun 16 11:17:16 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 16 Jun 2015 17:17:16 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <2084944584.2661828.1434461255306.JavaMail.zimbra@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> <2084944584.2661828.1434461255306.JavaMail.zimbra@redhat.com> Message-ID: <55803DFC.8070701@redhat.com> Hi *, inline... On 16/06/15 15:27, John Mazzitelli wrote: > My opinion is don't keep our own versions of modified WildFly files > in our own repositories as they will inevitably go stale and out of > date. +1 for not not maintaining modified WF stuff in our git repos as far as possible. > We can do tricks in our mvn poms and assembly scripts to alter them > during the build (using ant scripts or whatever). Yes, transform their files at build time, or as a variant of that: Rename their standalone.sh to standalone-wildfly.sh and create our own wrapper called standalone.sh that would basically call standalone-wildfly.sh with some hawkular defaults? -- P > We can look into > standalone.conf (don't they provide something like this?) Or contribute > the change back to WildFly folks. > > Worst case is we keep our own copies of modified WildFly files - but I just don't like that option. > > ----- Original Message ----- >> Hey, >> >> currently one can pass properties/options like the C* to use >> via -Dkey=value pairs to standalone.sh/bat >> >> This is a bit cumbersome and also does not work in cases, where >> the command line is set at "compile time" like in a Dockerfile, >> but the property needs to be set at run time (when docker run >> a pre-made image). >> >> There would be the option to set JAVA_OPTS before starting >> the script, but JAVA_OPTS is >> a) something that may apply to multiple java programs on a machine >> and is thus not specific >> b) inside standalone.conf not additive, so one has to repeat all the >> options from standalone.conf on JAVA_OPTS >> >> So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS >> that are additive to JAVA_OPTS. >> >> We need to modify standalone.sh/bat to source them (and keep the >> modified versions in our git repo. >> >> Alternatives could be >> - create wrapper scripts that set JAVA_OPTS and call standalone.sh, >> but that only indirectly solves [1] >> - as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases. >> I fear that may take too long. >> >> Opinions? >> >> >> [1] https://issues.jboss.org/browse/HAWKULAR-288 >> _______________________________________________ >> 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 Jun 16 11:25:04 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 17:25:04 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <558025CF.2080307@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> <558025CF.2080307@redhat.com> Message-ID: <8D015DFF-08C6-41ED-9ED3-317D64B2C8EA@redhat.com> On 16 Jun 2015, at 15:34, Matt Wringe wrote: > On 16/06/15 04:29 AM, Heiko W.Rupp wrote: >> Hey, >> >> currently one can pass properties/options like the C* to use >> via -Dkey=value pairs to standalone.sh/bat >> >> This is a bit cumbersome and also does not work in cases, where >> the command line is set at "compile time" like in a Dockerfile, >> but the property needs to be set at run time (when docker run >> a pre-made image). > > You can specify the default start options in the dockerfile, which > allows for a simple install of that image. Yes, but then you are forced to e.g. build the Docker image with e.g. standalone.sh -XX:+UnlockCommercialFeatures -XX:+FlightRecorder which is probably no longer portable to OpenJDK, that does not offer this. Similar for properties to tell where C* is (embedded or on a different host/port). > > But you can also pass your own options when you go to first start your > docker image, as well as overwrite them in the kubernetes configuration. > > Setting the options via a command line option is the easiest option when > dealing with docker images and kubernetes, otherwise you need to jump > through a bunch of hoops. I would really like to keep this option > available if possible. I do not want to abandon the command line options/parsing. I want env-variables on top, that can easily be passed into Docker and allow to use the same Docker image no matter if using the embedded C* or C* on the host or in some other Docker container. Heiko From vnguyen at redhat.com Tue Jun 16 11:40:28 2015 From: vnguyen at redhat.com (Viet Nguyen) Date: Tue, 16 Jun 2015 11:40:28 -0400 (EDT) Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <8D015DFF-08C6-41ED-9ED3-317D64B2C8EA@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> <558025CF.2080307@redhat.com> <8D015DFF-08C6-41ED-9ED3-317D64B2C8EA@redhat.com> Message-ID: <1111471945.18878382.1434469228618.JavaMail.zimbra@redhat.com> Heiko, You can still customize Hawkular start up script in Docker at runtime. Both vanilla Docker and Kubernetes support runtime environment variables. Dockerfile: CMD jboss_standalone.sh ${HAWKULAR_OPT} Runtime: docker run -e HAWKULAR_OPT=... Viet ----- Original Message ----- From: "Heiko W.Rupp" To: "Discussions around Hawkular development" Sent: Wednesday, June 17, 2015 12:25:04 AM Subject: Re: [Hawkular-dev] Property passing into Hawkular(-metrics) On 16 Jun 2015, at 15:34, Matt Wringe wrote: > On 16/06/15 04:29 AM, Heiko W.Rupp wrote: >> Hey, >> >> currently one can pass properties/options like the C* to use >> via -Dkey=value pairs to standalone.sh/bat >> >> This is a bit cumbersome and also does not work in cases, where >> the command line is set at "compile time" like in a Dockerfile, >> but the property needs to be set at run time (when docker run >> a pre-made image). > > You can specify the default start options in the dockerfile, which > allows for a simple install of that image. Yes, but then you are forced to e.g. build the Docker image with e.g. standalone.sh -XX:+UnlockCommercialFeatures -XX:+FlightRecorder which is probably no longer portable to OpenJDK, that does not offer this. Similar for properties to tell where C* is (embedded or on a different host/port). > > But you can also pass your own options when you go to first start your > docker image, as well as overwrite them in the kubernetes configuration. > > Setting the options via a command line option is the easiest option when > dealing with docker images and kubernetes, otherwise you need to jump > through a bunch of hoops. I would really like to keep this option > available if possible. I do not want to abandon the command line options/parsing. I want env-variables on top, that can easily be passed into Docker and allow to use the same Docker image no matter if using the embedded C* or C* on the host or in some other Docker container. Heiko _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Tue Jun 16 11:41:38 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 16 Jun 2015 17:41:38 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <55803DFC.8070701@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> <2084944584.2661828.1434461255306.JavaMail.zimbra@redhat.com> <55803DFC.8070701@redhat.com> Message-ID: <558043B2.3070804@redhat.com> Le 16/06/2015 17:17, Peter Palaga a ?crit : > Rename their standalone.sh to standalone-wildfly.sh and create our own > wrapper called standalone.sh that would basically call > standalone-wildfly.sh with some hawkular defaults? -1 Customization of environment variables in general and JAVA_OPTS in particular should happen in standalone.conf, which is in the bin directory exactly for this purpose. From hrupp at redhat.com Tue Jun 16 12:01:58 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 18:01:58 +0200 Subject: [Hawkular-dev] Updated JIRA workflow for HAWKULAR Message-ID: <7CAEF7A0-6861-4FC9-A12F-3B8F16989A38@redhat.com> A non-text attachment was scrubbed... Name: Bildschirmfoto 2015-06-16 um 17.49.32.png Type: image/png Size: 17151 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150616/e4201003/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Bildschirmfoto 2015-06-16 um 17.50.13.png Type: image/png Size: 56726 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150616/e4201003/attachment-0003.png From hrupp at redhat.com Tue Jun 16 11:36:22 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 17:36:22 +0200 Subject: [Hawkular-dev] Property passing into Hawkular(-metrics) In-Reply-To: <55803DFC.8070701@redhat.com> References: <6A2A3DE8-0449-4D48-A208-79F487B3EBC5@redhat.com> <2084944584.2661828.1434461255306.JavaMail.zimbra@redhat.com> <55803DFC.8070701@redhat.com> Message-ID: <41EDC95E-20C6-4470-9D84-6A9E22B37024@redhat.com> On 16 Jun 2015, at 17:17, Peter Palaga wrote: > +1 for not not maintaining modified WF stuff in our git repos as far as > possible. > Yes, transform their files at build time, or as a variant of that: If we expect the original files to be modified, is it safe to assume that our transformation code can stay as is? Providing a home-grown standalone.conf(.bat) is probably the safest option here, as this one is only meant to define env variables and is sourced by the standalone.sh/.bat files. Heiko From lkrejci at redhat.com Tue Jun 16 13:48:35 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 16 Jun 2015 19:48:35 +0200 Subject: [Hawkular-dev] Tenant no longer in URL in the upcoming Inventory 0.1.0 In-Reply-To: References: <3679046.Q0CT4NcL9M@localhost.localdomain> <1800188.5EZZNlYfLs@localhost.localdomain> Message-ID: <2470887.JBsGTBOpgD@localhost.localdomain> On Monday, June 15, 2015 10:45:25 John Sanda wrote: > Comments/questions inline... > > > On Jun 15, 2015, at 7:36 AM, Lukas Krejci wrote: > > > > I just hope you implement your filter as soon as possible so that all > > Hawkular components are authenticated against the same way. > > > > But I still think that as a user, I'd be opposed to any solution that > > would > > require me to duplicate any information - I will have to provide auth info > > (creds + optionally persona id). If the components need to provide any > > other info, given the current security model where persona == tenant, > > then I think that solution wouldn't be good. > > Why and to whom would components be providing auth info? My understanding is > that we will eventually have the security filter through which all requests > are routed. That filter will handle authentication/authorization so that > when a request does reach the component endpoint, we can assume > authentication/authorization have already been taken care of. Users would be supplying auth info. Authorization is impossible to do generically imho and has to be done by components - only the components know their security model. Accounts can provide the tools to facilitate the authorization but it must be the components that use those tools to apply the authorization in a component-specific way. > > On Friday, June 12, 2015 11:39:15 Stefan Negrea wrote: > >> Hello Lukas, > >> > >> You are conflating two concepts in a bad way. First is multi-tenancy and > >> second is authentication. > >> It just happens now the path of least resistance > >> is to couple the concepts. The requirements for each might change over > >> time, so coupling them straight in the design will have negative effects. > > > > Not only authentication but authorization also ;) That's because multi- > > tenancy, IMHO, doesn't make much sense without the other two.. > > > > I am not sure if multi-tenancy and authentication can be completely > > separated. As a user of a multi-tenant system (understood from a SaaS > > perspective), I would be disappointed if users "from other tenants" could > > access my data. > Agree about data separation, and I do not think there is anything being > suggested that would allow for/support this. > > So while, technically, we can understand multi-tenancy as solely a means > > of > > data separation, the end-user expectations of a multi-tenant system > > include > > access control and therefore both authentication and authorization. > > I think this conflate the two, separate concerns. As the user I should not > have to know or care about the existence of other tenants. From my > perspective there is my tenant and that?s it. There might be other tenants, > but that should not be a concern to me as it related to authentication and > authorization. For example, in a future version suppose we decide to > completely replace our authentication/authorization model with something > else. That should not (at least in theory) change multi tenancy. That is precisely what I was trying to imply - as a user I should not care what a tenant is. I should just provide my creds + optionally impersonation info (if a user wants to act as an org for example). "Hawkular-Tenant" header goes against that if it would be the user that would be supplying that info. > >> Here is how Metrics approaches this: > >> 1) 'Hawkular-Tenant' header is the tenant differentiator > >> 2) 'Hawkular-Tenant' validation and verification is not yet defined > >> 3) For now use a naive approach that accepts and trusts any incoming > >> values > >> 4) When Hawkular Accounts has the authentication filter ready , Metrics > >> will defer decisions to Accounts. All the logic will be contained in a > >> single filter. Some of the logic will be to map an Accounts concept (the > >> strong guess is Persona) to 'Hawkular-Tenant'. > >> 5) Any other service will go through a similar process as in step 4; see > >> > > >> below ... > > > > Accounts contain a single line of code for authentication - and that is > > reading the current principal from the session context (and assume that > > that principal is a keycloak principal). > > > > The rest of accounts deals with impersonation and authorization which you > > don't mention here at all. How do you envisage authorization to happen in > > metrics? > > Other than configuring/applying the filter, I do not envision metrics, nor > any other component for that matter, doing authorization. That is the > responsibility of accounts. -1. Metrics have completely different authz requirements from alerts which are completely different from inventory's authz reqs. It is the components or a dedicated wrapper thereof that need to do the authz. Accounts can help with that but the logic will be component specific. > >> The process to integrate Metrics into another project: > >> 1) Find the authentication mechanism (algorithm, service, database, etc.) > >> 2) Create a filter to integrate with the authentication source > >> 3) Validate & verify using the external source and then translate to > >> 'Hawkular-Tenant' > >> > >> My proposal revolves around keeping the individual service architecture > >> and > >> design clean with regards to multi-tenancy. If you do not see any value > >> in > >> that for Hawkular Inventory then this discussion does not benefit your > >> project. > > > > What you are proposing makes authentication and authorization optional, > > mandating a tenant. What alerts and inventory did was basically the > > opposite. They mandate auth and authz and make tenant optional/deduced. > > > > Users will always need to provide credentials to access the components (at > > least I hope so), so if there is a way of deducing additional information > > from that, we should IMHO be doing it. > > > >> Thank you, > >> Stefan > >> > >> ----- Original Message ----- > >> > >>> From: "Lukas Krejci" > > >>> To: hawkular-ev at lists.jboss.org > >>> Sent: Friday, June 12, 2015 9:02:52 AM > >>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the > >>> upcoming Inventory 0.1.0> > >>> > >>> On Thursday, June 11, 2015 13:18:43 Stefan Negrea wrote: > >>>> Hello, > >>>> > >>>> I hope we standardize on Hawkular-Tenant at service level. The concept > >>>> of > >>>> the persona is narrow and accounts specific. While we are mapping now > >>>> personas to tenants that could change in the future. > >>>> > >>>> Also, the concepts of tenant and multi-tenancy are easier to document > >>>> and > >>>> understand by external consumers. If/when the individual services are > >>>> decoupled and consumed by other projects or independently, there is no > >>>> extra documentation needed to explain the multi-tenant capability. > >>> > >>> I actually hope for quite the opposite ;) I hope we standardize on > >>> Hawkular > >>> Accounts providing auth and (help with) authz and the rest of the > >>> components using that info. Alerts and Inventory already do that. I hope > >>> Metrics will join soon. > >>> > >>> You are right that "Hawkular-Persona" is a header that "suggests" > >>> authentication rather than multi-tenancy, but that's exactly how it is > >>> used > >>> in > >>> inventory and alerts - we use accounts primarily for authentication. > >>> > >>> The fact that tenant = persona is not really that important and in fact > >>> if > >>> we decide in the future that tenant != persona, we might introduce > >>> another header, Hawkular-Tenant most probably, that will override the > >>> behavior we currently support by equating the auth and multi-tenancy > >>> (which btw. makes a lot of sense, at least for now). > >>> > >>> Metrics currently does not offer any form of authentication as far as I > >>> am > >>> aware, so an important part of the multi-tenancy picture is missing from > >>> it. > >>> > >>> IMHO the situation in inventory and alerts is much better now in that > >>> regard - > >>> we delegate the tenant creation/updates, permission grants, etc. to > >>> accounts, let it figure out what the user performing a request is in any > >>> way it chooses (basic auth, oauth, optionally override default persona > >>> with the Hawkular- Persona header, if deemed necessary) and use that to > >>> perform security checks. > >>> > >>> As a user of the current Hawkular I would find it weird to have to > >>> specify > >>> my creds/token, potentially a persona overriding header AND a tenant > >>> header if, as it is right now, the tenant id and the persona id would > >>> always be the same. > >>> > >>> I know that metrics are special and have to function outside of > >>> Hawkular, > >>> too, > >>> but when inside Hawkular, IMHO, they should blend in and not require > >>> special treatment - most of all when applying security. > >>> > >>> If you figure out a way of blending in Hawkular AND functioning on your > >>> own > >>> nicely, it'd be nice if the rest of us could reuse that solution. But at > >>> least > >>> for inventory, there is not direct requirement to run outside of > >>> Hawkular. > >>> > >>>> Thank you, > >>>> Stefan > >>>> > >>>> ----- Original Message ----- > >>>> > >>>>> From: "John Mazzitelli" > >>>>> To: "Discussions around Hawkular development" > >>>>> Sent: Thursday, June 11, 2015 9:26:59 > >>>>> AM > >>>>> Subject: Re: [Hawkular-dev] Tenant no longer in URL in the upcoming > >>>>> Inventory 0.1.0 > >>>>> > >>>>> I thought it was Hawkular-Tenant, not Hawkular-Persona. > >>>>> > >>>>> I used Hawkular-Tenant header name in my changes to support metrics > >>>>> 0.3.5 > >>>>> > >>>>> The name "Hawkular-Persona" is a new one to me. > >>>>> > >>>>> ----- Original Message ----- > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I just wanted to let you know about the breaking change in the > >>>>>> upcoming > >>>>>> Inventory 0.1.0. > >>>>>> > >>>>>> Following the suite of metrics, inventory will no longer support the > >>>>>> tenantID > >>>>>> in the URL and will solely rely on Hawkular accounts to hand it the > >>>>>> tenantID > >>>>>> to use - i.e. it will be the tenant of the currently logged in user > >>>>>> or > >>>>>> of > >>>>>> the > >>>>>> persona passed in using the "Hawkular-Persona" header. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Lukas > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 hrupp at redhat.com Tue Jun 16 15:50:15 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 16 Jun 2015 21:50:15 +0200 Subject: [Hawkular-dev] Hawkular QA Message-ID: <213DE829-787B-4AEC-B8FD-907AEA732236@redhat.com> Hey, as I mentioned earlier today, QA is currently busy with "other things" :-) and can't look after the Hawkular Jiras in Resolve state. So in the best of Kanban we should chime in here and smoke test items that are RESOLVED (QA Todo in the Kanban board), so that they can be moved to the QA Done = Closed state And as with Pull-Requests: Don't QA the things you implemented yourself. Heiko From theute at redhat.com Wed Jun 17 03:08:19 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 17 Jun 2015 09:08:19 +0200 Subject: [Hawkular-dev] WF 9 upgrade Message-ID: <55811CE3.3010001@redhat.com> We have to upgrade to WF9 to get more data out of WF9. there are quite some changes to be made: - Parent declares the version of WF to use and BOM: here is my branch: https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 - Accounts need to upgrade to KC 1.3 (to be released this week) Juca will work on this - Bus/Nest needs to adapt here is my branch https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another patch from Mazz) - Agent also needs some changes. WF 9 GA is supposed to go out at any point now, let's try to coordinate around that, if you have a release pending, think of that. BTW, I tried to reflect the dependencies between component, would have been easier if everyone could respect our standards, in particular: - declare all dependencies at the root pom - use in pom properties. So please fix this if you do not follow those basic rules. PS: for the upstream project, it is ok if all dependencies don't fully align, for instance 2 components could depend on 2 different versions of the parent. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: componentDependencies.png Type: image/png Size: 99104 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150617/be377823/attachment-0001.png From ppalaga at redhat.com Wed Jun 17 03:11:05 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 17 Jun 2015 09:11:05 +0200 Subject: [Hawkular-dev] Import order In-Reply-To: <557FF716.3080100@redhat.com> References: <557FF158.2000708@redhat.com> <557FF716.3080100@redhat.com> Message-ID: <55811D89.8080507@redhat.com> OK, I'll add the import order check to checkstyle. https://issues.jboss.org/browse/HAWKULAR-358 -- P On 16/06/15 12:14, Thomas Segismont wrote: > Le 16/06/2015 11:50, Peter Palaga a ?crit : >> Hi Mazz, >> >> While I can remember some basic discussion about the order Java imports, >> I do not remember at all what was the result. >> >> I saw that you added Eclipse prefs for import order to dev tools which >> is definitely good >> https://github.com/hawkular/hawkular-build-tools/blob/master/ide-configs/eclipse/hawkular-eclipse-preferences-java-codestyle-organizeimports.importorder >> >> Do Idea prefs contain the same settings? > > Yes, they were built by Lucas and reviewed by me. > >> >> Are there projects using these settings consequently? > > All projects _should_ be using the same. > >> >> But did we say we would enforce the imports order by checkstyle? > > We didn't talk about that. > > I have recently commented on GitHub that import order was the only thing > not checked yet, and we keep on seeing PR with many lines of import > order differences. > > To me, it shows that formatting rules, if not enforced, are not > naturally observed. > >> They have a rule for that: >> http://checkstyle.sourceforge.net/config_imports.html#ImportOrder > > +1 for adding > >> >> Its a pity that we have not done it earlier. >> >> Thanks, >> >> Peter >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Wed Jun 17 05:45:12 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Wed, 17 Jun 2015 11:45:12 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55811CE3.3010001@redhat.com> References: <55811CE3.3010001@redhat.com> Message-ID: <558141A8.4040506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Accounts tracking JIRA: HAWKULAR-362 I'll perform the changes in Accounts' dist, which can later be used as base for the main Hawkular dist. - - Juca. On 06/17/2015 09:08 AM, Thomas Heute wrote: > > We have to upgrade to WF9 to get more data out of WF9. > > there are quite some changes to be made: - Parent declares the > version of WF to use and BOM: here is my branch: > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > - Accounts need to upgrade to KC 1.3 (to be released this week) > Juca will work on this - Bus/Nest needs to adapt here is my branch > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs > another patch from Mazz) - Agent also needs some changes. > > WF 9 GA is supposed to go out at any point now, let's try to > coordinate around that, if you have a release pending, think of > that. > > BTW, I tried to reflect the dependencies between component, would > have been easier if everyone could respect our standards, in > particular: - declare all dependencies at the root pom - use > in pom properties. So please fix this if you do > not follow those basic rules. > > PS: for the upstream project, it is ok if all dependencies don't > fully align, for instance 2 components could depend on 2 different > versions of the parent. > > Thomas > > > _______________________________________________ hawkular-dev > mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVgUGoAAoJECKM1e+fkPrXkiEH/RJ4vf+lQogc4d59wSVaqzSC uSPMK4QinX+9PHw1ZejmS/12147q0IhrBrXGyFz5KOWY86rFKSgTU1pXMbaT14/X RVY3oM1RZU1POQyKJX2K3LZUh18FDllJhPXXw4QF28Hb4X4qBxI+iN7AZLKQHRi/ oMUBUpMaFpPZROvr7N1efr41RqdJG16AWTilpMIhG32HF1HqKG8ZLEZLLnhG9bGd Yrgy4mdZ0lLx1vROH/RF8Oh8Qx2FkfA9NNPENqBMg9e2rfmyXGpb4MchRSjaCVol phDminims6thApl7dSRe/3Eb0goU7TfiwvO9Khsr6JhbhZnLFdY8AoFHfl+J+8Q= =l/8o -----END PGP SIGNATURE----- From jpkroehling at redhat.com Wed Jun 17 05:46:40 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Wed, 17 Jun 2015 11:46:40 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <558141A8.4040506@redhat.com> References: <55811CE3.3010001@redhat.com> <558141A8.4040506@redhat.com> Message-ID: <55814200.5070307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 By the way: does this task means that we are building feature packs for WF9, or we are just bumping the WF version and fixing whatever breaks? - - Juca. On 06/17/2015 11:45 AM, Juraci Paix?o Kr?hling wrote: > Accounts tracking JIRA: HAWKULAR-362 > > I'll perform the changes in Accounts' dist, which can later be used > as base for the main Hawkular dist. > > - Juca. > > On 06/17/2015 09:08 AM, Thomas Heute wrote: > >> We have to upgrade to WF9 to get more data out of WF9. > >> there are quite some changes to be made: - Parent declares the >> version of WF to use and BOM: here is my branch: >> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >> - Accounts need to upgrade to KC 1.3 (to be released this week) >> Juca will work on this - Bus/Nest needs to adapt here is my >> branch https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 >> (needs another patch from Mazz) - Agent also needs some changes. > >> WF 9 GA is supposed to go out at any point now, let's try to >> coordinate around that, if you have a release pending, think of >> that. > >> BTW, I tried to reflect the dependencies between component, >> would have been easier if everyone could respect our standards, >> in particular: - declare all dependencies at the root pom - use >> in pom properties. So please fix this if you >> do not follow those basic rules. > >> PS: for the upstream project, it is ok if all dependencies don't >> fully align, for instance 2 components could depend on 2 >> different versions of the parent. > >> Thomas > > >> _______________________________________________ hawkular-dev >> mailing list hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ hawkular-dev > mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVgUIAAAoJECKM1e+fkPrXLUgH/jpV7wTTlayfAY5FVzRBJdA5 AyELpcT9KSQlrVntMKwi6fi8nNWLRzTXR06XP8mLrSVW8w6/fImxICxpi6/ztKhP zrJ7rh7yU2bsdLFOKm9amfSwF4aW/ypS5Hvc7CXqwI1zR6S/3hqXAanqkRQcn5Db G244XgypyuSKeURQ5/64XWrWE9TeaJykHTtwWWh7GWVxACGlamWjLSLKp0G2k/Qr cxkcf3LRohM82H9vo6/RRk3RnrOhzpnyOBxM9uVg787f0FVIgYEpdv/ahDTUMc96 C64dYabq7qHMKgJxPnl67DkEwBREc+LVvFlCMGkkBRiYvMMyTau6MSCXblGbX4Q= =dvQq -----END PGP SIGNATURE----- From theute at redhat.com Wed Jun 17 05:59:40 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 17 Jun 2015 11:59:40 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55814200.5070307@redhat.com> References: <55811CE3.3010001@redhat.com> <558141A8.4040506@redhat.com> <55814200.5070307@redhat.com> Message-ID: <5581450C.1090302@redhat.com> For now updating and fixing. We should look into feature packs stuff and if that helps separately Thomas On 06/17/2015 11:46 AM, Juraci Paix?o Kr?hling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > By the way: does this task means that we are building feature packs > for WF9, or we are just bumping the WF version and fixing whatever > breaks? > > - - Juca. > > On 06/17/2015 11:45 AM, Juraci Paix?o Kr?hling wrote: > > Accounts tracking JIRA: HAWKULAR-362 > > > > I'll perform the changes in Accounts' dist, which can later be used > > as base for the main Hawkular dist. > > > > - Juca. > > > > On 06/17/2015 09:08 AM, Thomas Heute wrote: > > > >> We have to upgrade to WF9 to get more data out of WF9. > > > >> there are quite some changes to be made: - Parent declares the > >> version of WF to use and BOM: here is my branch: > >> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > >> - Accounts need to upgrade to KC 1.3 (to be released this week) > >> Juca will work on this - Bus/Nest needs to adapt here is my > >> branch https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 > >> (needs another patch from Mazz) - Agent also needs some changes. > > > >> WF 9 GA is supposed to go out at any point now, let's try to > >> coordinate around that, if you have a release pending, think of > >> that. > > > >> BTW, I tried to reflect the dependencies between component, > >> would have been easier if everyone could respect our standards, > >> in particular: - declare all dependencies at the root pom - use > >> in pom properties. So please fix this if you > >> do not follow those basic rules. > > > >> PS: for the upstream project, it is ok if all dependencies don't > >> fully align, for instance 2 components could depend on 2 > >> different versions of the parent. > > > >> Thomas > > > > > >> _______________________________________________ hawkular-dev > >> mailing list hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ hawkular-dev > > mailing list hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVgUIAAAoJECKM1e+fkPrXLUgH/jpV7wTTlayfAY5FVzRBJdA5 > AyELpcT9KSQlrVntMKwi6fi8nNWLRzTXR06XP8mLrSVW8w6/fImxICxpi6/ztKhP > zrJ7rh7yU2bsdLFOKm9amfSwF4aW/ypS5Hvc7CXqwI1zR6S/3hqXAanqkRQcn5Db > G244XgypyuSKeURQ5/64XWrWE9TeaJykHTtwWWh7GWVxACGlamWjLSLKp0G2k/Qr > cxkcf3LRohM82H9vo6/RRk3RnrOhzpnyOBxM9uVg787f0FVIgYEpdv/ahDTUMc96 > C64dYabq7qHMKgJxPnl67DkEwBREc+LVvFlCMGkkBRiYvMMyTau6MSCXblGbX4Q= > =dvQq > -----END PGP SIGNATURE----- > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Wed Jun 17 06:36:35 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 17 Jun 2015 12:36:35 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <5581450C.1090302@redhat.com> References: <55811CE3.3010001@redhat.com> <558141A8.4040506@redhat.com> <55814200.5070307@redhat.com> <5581450C.1090302@redhat.com> Message-ID: <55814DB3.4000507@redhat.com> I talked about that with Toma? Cerar at RivieraDEV. I'll try to determine if we can get a JAX-RS + CDI server for Metrics. I'll keep you informed. Le 17/06/2015 11:59, Thomas Heute a ?crit : > > For now updating and fixing. > > We should look into feature packs stuff and if that helps separately > > Thomas > > On 06/17/2015 11:46 AM, Juraci Paix?o Kr?hling wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> By the way: does this task means that we are building feature packs >> for WF9, or we are just bumping the WF version and fixing whatever >> breaks? >> >> - - Juca. >> >> On 06/17/2015 11:45 AM, Juraci Paix?o Kr?hling wrote: >>> Accounts tracking JIRA: HAWKULAR-362 >>> >>> I'll perform the changes in Accounts' dist, which can later be used >>> as base for the main Hawkular dist. >>> >>> - Juca. >>> >>> On 06/17/2015 09:08 AM, Thomas Heute wrote: >>> >>>> We have to upgrade to WF9 to get more data out of WF9. >>> >>>> there are quite some changes to be made: - Parent declares the >>>> version of WF to use and BOM: here is my branch: >>>> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >>>> - Accounts need to upgrade to KC 1.3 (to be released this week) >>>> Juca will work on this - Bus/Nest needs to adapt here is my >>>> branch https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 >>>> (needs another patch from Mazz) - Agent also needs some changes. >>> >>>> WF 9 GA is supposed to go out at any point now, let's try to >>>> coordinate around that, if you have a release pending, think of >>>> that. >>> >>>> BTW, I tried to reflect the dependencies between component, >>>> would have been easier if everyone could respect our standards, >>>> in particular: - declare all dependencies at the root pom - use >>>> in pom properties. So please fix this if you >>>> do not follow those basic rules. >>> >>>> PS: for the upstream project, it is ok if all dependencies don't >>>> fully align, for instance 2 components could depend on 2 >>>> different versions of the parent. >>> >>>> Thomas >>> >>> >>>> _______________________________________________ hawkular-dev >>>> mailing list hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >>> _______________________________________________ hawkular-dev >>> mailing list hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQEcBAEBCAAGBQJVgUIAAAoJECKM1e+fkPrXLUgH/jpV7wTTlayfAY5FVzRBJdA5 >> AyELpcT9KSQlrVntMKwi6fi8nNWLRzTXR06XP8mLrSVW8w6/fImxICxpi6/ztKhP >> zrJ7rh7yU2bsdLFOKm9amfSwF4aW/ypS5Hvc7CXqwI1zR6S/3hqXAanqkRQcn5Db >> G244XgypyuSKeURQ5/64XWrWE9TeaJykHTtwWWh7GWVxACGlamWjLSLKp0G2k/Qr >> cxkcf3LRohM82H9vo6/RRk3RnrOhzpnyOBxM9uVg787f0FVIgYEpdv/ahDTUMc96 >> C64dYabq7qHMKgJxPnl67DkEwBREc+LVvFlCMGkkBRiYvMMyTau6MSCXblGbX4Q= >> =dvQq >> -----END PGP SIGNATURE----- >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Wed Jun 17 09:18:29 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 17 Jun 2015 09:18:29 -0400 (EDT) Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55811CE3.3010001@redhat.com> References: <55811CE3.3010001@redhat.com> Message-ID: <1783945600.3512591.1434547109101.JavaMail.zimbra@redhat.com> FWIW: I also have a separate branch where the agent is built and can be run in WildFly Swarm - but it won't work until we move to WF9. So once we go to WF9, I'll introduce this agent swarm stuff as well. ----- Original Message ----- > > We have to upgrade to WF9 to get more data out of WF9. > > there are quite some changes to be made: > - Parent declares the version of WF to use and BOM: > here is my branch: > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > - Accounts need to upgrade to KC 1.3 (to be released this week) > Juca will work on this > - Bus/Nest needs to adapt > here is my branch > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > patch from Mazz) > - Agent also needs some changes. > > WF 9 GA is supposed to go out at any point now, let's try to coordinate > around that, if you have a release pending, think of that. > > BTW, I tried to reflect the dependencies between component, would have > been easier if everyone could respect our standards, in particular: > - declare all dependencies at the root pom > - use in pom properties. > So please fix this if you do not follow those basic rules. > > PS: for the upstream project, it is ok if all dependencies don't fully > align, for instance 2 components could depend on 2 different versions of > the parent. > > Thomas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 17 09:51:57 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 17 Jun 2015 15:51:57 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <1783945600.3512591.1434547109101.JavaMail.zimbra@redhat.com> References: <55811CE3.3010001@redhat.com> <1783945600.3512591.1434547109101.JavaMail.zimbra@redhat.com> Message-ID: <55817B7D.4080309@redhat.com> As said before, we can't use/rely on Swarm, so -1 to put that in our build. This won't be supported, Swarm is a R&P project while Hawkular is a R&D project Thomas On 06/17/2015 03:18 PM, John Mazzitelli wrote: > FWIW: I also have a separate branch where the agent is built and can be run in WildFly Swarm - but it won't work until we move to WF9. So once we go to WF9, I'll introduce this agent swarm stuff as well. > > ----- Original Message ----- > > > > We have to upgrade to WF9 to get more data out of WF9. > > > > there are quite some changes to be made: > > - Parent declares the version of WF to use and BOM: > > here is my branch: > > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > > - Accounts need to upgrade to KC 1.3 (to be released this week) > > Juca will work on this > > - Bus/Nest needs to adapt > > here is my branch > > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > > patch from Mazz) > > - Agent also needs some changes. > > > > WF 9 GA is supposed to go out at any point now, let's try to coordinate > > around that, if you have a release pending, think of that. > > > > BTW, I tried to reflect the dependencies between component, would have > > been easier if everyone could respect our standards, in particular: > > - declare all dependencies at the root pom > > - use in pom properties. > > So please fix this if you do not follow those basic rules. > > > > PS: for the upstream project, it is ok if all dependencies don't fully > > align, for instance 2 components could depend on 2 different versions of > > the parent. > > > > Thomas > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Wed Jun 17 10:04:12 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 17 Jun 2015 10:04:12 -0400 (EDT) Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55817B7D.4080309@redhat.com> References: <55811CE3.3010001@redhat.com> <1783945600.3512591.1434547109101.JavaMail.zimbra@redhat.com> <55817B7D.4080309@redhat.com> Message-ID: <1610827669.3556873.1434549852173.JavaMail.zimbra@redhat.com> then we should close https://issues.jboss.org/browse/HAWKULAR-192 - because it was that JIRA that caused me to even look at swarm. ----- Original Message ----- > As said before, we can't use/rely on Swarm, so -1 to put that in our build. > This won't be supported, Swarm is a R&P project while Hawkular is a R&D > project > > Thomas > > On 06/17/2015 03:18 PM, John Mazzitelli wrote: > > FWIW: I also have a separate branch where the agent is built and can be run > > in WildFly Swarm - but it won't work until we move to WF9. So once we go > > to WF9, I'll introduce this agent swarm stuff as well. > > > > ----- Original Message ----- > > > > > > We have to upgrade to WF9 to get more data out of WF9. > > > > > > there are quite some changes to be made: > > > - Parent declares the version of WF to use and BOM: > > > here is my branch: > > > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > > > - Accounts need to upgrade to KC 1.3 (to be released this week) > > > Juca will work on this > > > - Bus/Nest needs to adapt > > > here is my branch > > > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > > > patch from Mazz) > > > - Agent also needs some changes. > > > > > > WF 9 GA is supposed to go out at any point now, let's try to coordinate > > > around that, if you have a release pending, think of that. > > > > > > BTW, I tried to reflect the dependencies between component, would have > > > been easier if everyone could respect our standards, in particular: > > > - declare all dependencies at the root pom > > > - use in pom properties. > > > So please fix this if you do not follow those basic rules. > > > > > > PS: for the upstream project, it is ok if all dependencies don't fully > > > align, for instance 2 components could depend on 2 different versions of > > > the parent. > > > > > > Thomas > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > From theute at redhat.com Wed Jun 17 11:19:54 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 17 Jun 2015 17:19:54 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <1610827669.3556873.1434549852173.JavaMail.zimbra@redhat.com> References: <55811CE3.3010001@redhat.com> <1783945600.3512591.1434547109101.JavaMail.zimbra@redhat.com> <55817B7D.4080309@redhat.com> <1610827669.3556873.1434549852173.JavaMail.zimbra@redhat.com> Message-ID: <5581901A.9010504@redhat.com> It is definitely a low priority, not sure if it should be closed. If this is important for us, we should make comments and push it to pass the prototype phase, if it doesn't help, we should move on. But again, definitely not a high priority, even though it looks good on paper Thomas On 06/17/2015 04:04 PM, John Mazzitelli wrote: > then we should close https://issues.jboss.org/browse/HAWKULAR-192 - because it was that JIRA that caused me to even look at swarm. > > ----- Original Message ----- > > As said before, we can't use/rely on Swarm, so -1 to put that in our build. > > This won't be supported, Swarm is a R&P project while Hawkular is a R&D > > project > > > > Thomas > > > > On 06/17/2015 03:18 PM, John Mazzitelli wrote: > >> FWIW: I also have a separate branch where the agent is built and can be run > >> in WildFly Swarm - but it won't work until we move to WF9. So once we go > >> to WF9, I'll introduce this agent swarm stuff as well. > >> > >> ----- Original Message ----- > >>> > >>> We have to upgrade to WF9 to get more data out of WF9. > >>> > >>> there are quite some changes to be made: > >>> - Parent declares the version of WF to use and BOM: > >>> here is my branch: > >>> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > >>> - Accounts need to upgrade to KC 1.3 (to be released this week) > >>> Juca will work on this > >>> - Bus/Nest needs to adapt > >>> here is my branch > >>> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > >>> patch from Mazz) > >>> - Agent also needs some changes. > >>> > >>> WF 9 GA is supposed to go out at any point now, let's try to coordinate > >>> around that, if you have a release pending, think of that. > >>> > >>> BTW, I tried to reflect the dependencies between component, would have > >>> been easier if everyone could respect our standards, in particular: > >>> - declare all dependencies at the root pom > >>> - use in pom properties. > >>> So please fix this if you do not follow those basic rules. > >>> > >>> PS: for the upstream project, it is ok if all dependencies don't fully > >>> align, for instance 2 components could depend on 2 different versions of > >>> the parent. > >>> > >>> Thomas > >>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Wed Jun 17 17:18:06 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Wed, 17 Jun 2015 17:18:06 -0400 Subject: [Hawkular-dev] Hawkular Alerts 0.1.0.Final released Message-ID: <5581E40E.9090904@redhat.com> Hawkular 0.1.0.Final has been Released. It includes the following work: https://issues.jboss.org/issues/?jql=project%20%3D%20HWKALERTS%20AND%20fixVersion%20%3D%200.1.0.Final It does contain some API changes to support paging when fetching Alerts. So some integration work may be involved when moving to this version. The next scheduled version is 0.2.0.Final sometime in the next few weeks. -Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150617/77f813aa/attachment.html From hrupp at redhat.com Thu Jun 18 07:43:13 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 18 Jun 2015 13:43:13 +0200 Subject: [Hawkular-dev] Fwd: [wildfly-dev] WildFly 10 Schedule References: Message-ID: <7D2D01A1-23C7-421C-8FB1-BAC13AF3B87B@redhat.com> Forwarded message: > From: Jason Greene > To: WildFly Developers > Subject: [wildfly-dev] WildFly 10 Schedule > Date: Wed, 17 Jun 2015 16:43:56 -0500 > > In addition to the biweekly Alphas, the following are the key dates > for the WildFly 10 schedule: > > WildFly 10 Beta1 - August, 6th > WildFly 10 CR1 - September 9th > WildFly 10 CR2 (if needed) - September 16th > WildFly 10 Final - October 8th* > > All new feature development needs to be wrapped by August, and > preferably most PRs already submitted in July. > > Happy Hacking! > > * As always, Final releases are contingent on the last CR being > blocker-free. If we aren?t blocker free, we will introduce another > CR > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jsanda at redhat.com Thu Jun 18 12:29:50 2015 From: jsanda at redhat.com (John Sanda) Date: Thu, 18 Jun 2015 12:29:50 -0400 Subject: [Hawkular-dev] C* schema design Message-ID: <4DD9562B-299E-4D2E-8DCE-6CC7843E07A7@redhat.com> I had been looking at the alerts schema briefly and wanted to share some thoughts on schema design in general. My understanding is that there can be many alerts for a single trigger. And based on my understanding and experience with RHQ, it is possible for there to be a large number of alerts. Here is the schema for the alerts table, CREATE TABLE alerts ( tenantid text, alertid text, payload text, PRIMARY KEY (tenantid, alertid) ) Simple enough. Here is a short test driver[1] I wrote to insert 100 million alerts into a 3 node cluster. Note that only a single tenant is used. As the test ran, I periodically ran nodetool status to check the load on the cluster. You can see the output of that here[2]. You will that only of the nodes owns virtually all of load. 127.0.0.1 has over 2 GB of data while the other two have less than 500 KB each. All of the alerts for a single tenant are stored in a single partition. In other words, all alerts are stored in one physical row on disk. This does not scale. Regardless of the number of nodes, only one node owns all of the data for a given tenant. This will also probably increasingly negative impact on read performance. The first change I might consider is to partition by trigger, but that alone is probably not sufficient. What if a single trigger generates thousands of alerts per day? That is still going to lead to hot spots (i.e., partition becoming too large). I would also consider partitioning by some time slice. Something like this, CREATE TABLE alerts ( tenantid text, triggerid text, date timestamp, alertid text, payload text, PRIMARY KEY ((tenantid, triggerid, date), alertid) ) Now data is partitioned by tenant, trigger, and date. The date column might be rounded down to week, day, hour, etc. It really depends on the frequency of writes as well as the read patterns. Now the data will be spread across nodes in a more scalable way. And when you have to fetch data across multiple time slices, you can execute the queries in parallel. [1] https://gist.github.com/jsanda/ce07905fa9f16f13c661 [2] https://gist.github.com/jsanda/6d2ee6cd5bcab07331d2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150618/899dd44a/attachment.html From lponce at redhat.com Thu Jun 18 12:41:07 2015 From: lponce at redhat.com (Lucas Ponce) Date: Thu, 18 Jun 2015 12:41:07 -0400 (EDT) Subject: [Hawkular-dev] C* schema design In-Reply-To: <4DD9562B-299E-4D2E-8DCE-6CC7843E07A7@redhat.com> References: <4DD9562B-299E-4D2E-8DCE-6CC7843E07A7@redhat.com> Message-ID: <2123449965.4790405.1434645667177.JavaMail.zimbra@redhat.com> > CREATE TABLE alerts ( > tenantid text, > triggerid text, > date timestamp, > alertid text, > payload text, > PRIMARY KEY ((tenantid, triggerid, date), alertid) > ) > Hey John, Thanks for the tip, I had exactly this approach in my todo-list for adding triggerid in the partition key. Also the date is interesting. The main idea is to locate all info related on an specific trigger close, to avoid stress the full partition. From amendonc at redhat.com Thu Jun 18 14:22:58 2015 From: amendonc at redhat.com (Alexandre Mendonca) Date: Thu, 18 Jun 2015 14:22:58 -0400 (EDT) Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55811CE3.3010001@redhat.com> References: <55811CE3.3010001@redhat.com> Message-ID: <954394316.16235328.1434651778503.JavaMail.zimbra@redhat.com> Regarding the fact that we need to upgrade to WF9 to get more data from it.. does it means that Hawkular will only be "compatible" with WF9+ ? Because for instance, I'm thinking on the Web Metrics screen, with WF8 we can't (in a very sane way) get the data we need to fill it as we will be able with WF9. So it will work fine with the local server, since it will be WF9, but what if a WF8 server is added to be monitored, how do we display that same data ? Do we need server type specific screens ? This should also apply to other metrics screens regarding other server types (that we might support in the future). Alexandre ----- Original Message ----- From: "Thomas Heute" To: "Discussions around Hawkular development" Sent: Wednesday, 17 June, 2015 8:08:19 AM Subject: [Hawkular-dev] WF 9 upgrade We have to upgrade to WF9 to get more data out of WF9. there are quite some changes to be made: - Parent declares the version of WF to use and BOM: here is my branch: https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 - Accounts need to upgrade to KC 1.3 (to be released this week) Juca will work on this - Bus/Nest needs to adapt here is my branch https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another patch from Mazz) - Agent also needs some changes. WF 9 GA is supposed to go out at any point now, let's try to coordinate around that, if you have a release pending, think of that. BTW, I tried to reflect the dependencies between component, would have been easier if everyone could respect our standards, in particular: - declare all dependencies at the root pom - use in pom properties. So please fix this if you do not follow those basic rules. PS: for the upstream project, it is ok if all dependencies don't fully align, for instance 2 components could depend on 2 different versions of the parent. Thomas _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From theute at redhat.com Fri Jun 19 02:20:14 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 19 Jun 2015 08:20:14 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <954394316.16235328.1434651778503.JavaMail.zimbra@redhat.com> References: <55811CE3.3010001@redhat.com> <954394316.16235328.1434651778503.JavaMail.zimbra@redhat.com> Message-ID: <5583B49E.8090808@redhat.com> My understanding is that the agent would work with WF8 and WF9, but indeed with WF8 we "lose" some metrics. While we'll need to keep some consistency between server screens, we'll also have differences (Tomcat/JWS, Fuse...). I hope we don't have to duplicate all but hide/show parts of the screens depending on the server type/version. Thomas On 06/18/2015 08:22 PM, Alexandre Mendonca wrote: > Regarding the fact that we need to upgrade to WF9 to get more data from it.. does it means that Hawkular will only be "compatible" with WF9+ ? > > Because for instance, I'm thinking on the Web Metrics screen, with WF8 we can't (in a very sane way) get the data we need to fill it as we will be able with WF9. So it will work fine with the local server, since it will be WF9, but what if a WF8 server is added to be monitored, how do we display that same data ? Do we need server type specific screens ? This should also apply to other metrics screens regarding other server types (that we might support in the future). > > Alexandre > > ----- Original Message ----- > From: "Thomas Heute" > To: "Discussions around Hawkular development" > Sent: Wednesday, 17 June, 2015 8:08:19 AM > Subject: [Hawkular-dev] WF 9 upgrade > > > We have to upgrade to WF9 to get more data out of WF9. > > there are quite some changes to be made: > - Parent declares the version of WF to use and BOM: > here is my branch: > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > - Accounts need to upgrade to KC 1.3 (to be released this week) > Juca will work on this > - Bus/Nest needs to adapt > here is my branch > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > patch from Mazz) > - Agent also needs some changes. > > WF 9 GA is supposed to go out at any point now, let's try to coordinate > around that, if you have a release pending, think of that. > > BTW, I tried to reflect the dependencies between component, would have > been easier if everyone could respect our standards, in particular: > - declare all dependencies at the root pom > - use in pom properties. > So please fix this if you do not follow those basic rules. > > PS: for the upstream project, it is ok if all dependencies don't fully > align, for instance 2 components could depend on 2 different versions of > the parent. > > Thomas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Fri Jun 19 04:16:05 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 19 Jun 2015 10:16:05 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55811CE3.3010001@redhat.com> References: <55811CE3.3010001@redhat.com> Message-ID: <5583CFC5.9010807@redhat.com> hawkular-parent 16 with an upgrade to WF9 was just released and I have sent PRs to all projects on my list. -- P On 17/06/15 09:08, Thomas Heute wrote: > > We have to upgrade to WF9 to get more data out of WF9. > > there are quite some changes to be made: > - Parent declares the version of WF to use and BOM: > here is my branch: > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > - Accounts need to upgrade to KC 1.3 (to be released this week) > Juca will work on this > - Bus/Nest needs to adapt > here is my branch > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > patch from Mazz) > - Agent also needs some changes. > > WF 9 GA is supposed to go out at any point now, let's try to coordinate > around that, if you have a release pending, think of that. > > BTW, I tried to reflect the dependencies between component, would have > been easier if everyone could respect our standards, in particular: > - declare all dependencies at the root pom > - use in pom properties. > So please fix this if you do not follow those basic rules. > > PS: for the upstream project, it is ok if all dependencies don't fully > align, for instance 2 components could depend on 2 different versions of > the parent. > > Thomas > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Fri Jun 19 07:22:58 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 19 Jun 2015 13:22:58 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <5583CFC5.9010807@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> Message-ID: <5583FB92.8030702@redhat.com> Can you close your PR against Metrics and open a JIRA? There's an issue with the BOM we use. I'll take care of this. Le 19/06/2015 10:16, Peter Palaga a ?crit : > hawkular-parent 16 with an upgrade to WF9 was just released and I have > sent PRs to all projects on my list. -- P > > On 17/06/15 09:08, Thomas Heute wrote: >> >> We have to upgrade to WF9 to get more data out of WF9. >> >> there are quite some changes to be made: >> - Parent declares the version of WF to use and BOM: >> here is my branch: >> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >> - Accounts need to upgrade to KC 1.3 (to be released this week) >> Juca will work on this >> - Bus/Nest needs to adapt >> here is my branch >> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another >> patch from Mazz) >> - Agent also needs some changes. >> >> WF 9 GA is supposed to go out at any point now, let's try to coordinate >> around that, if you have a release pending, think of that. >> >> BTW, I tried to reflect the dependencies between component, would have >> been easier if everyone could respect our standards, in particular: >> - declare all dependencies at the root pom >> - use in pom properties. >> So please fix this if you do not follow those basic rules. >> >> PS: for the upstream project, it is ok if all dependencies don't fully >> align, for instance 2 components could depend on 2 different versions of >> the parent. >> >> Thomas >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Fri Jun 19 10:18:09 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 19 Jun 2015 16:18:09 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <5583FB92.8030702@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> Message-ID: <558424A1.30804@redhat.com> https://issues.jboss.org/browse/HWKMETRICS-145 On 06/19/2015 01:22 PM, Thomas Segismont wrote: > Can you close your PR against Metrics and open a JIRA? There's an issue > with the BOM we use. > > I'll take care of this. > > Le 19/06/2015 10:16, Peter Palaga a ?crit : > > hawkular-parent 16 with an upgrade to WF9 was just released and I have > > sent PRs to all projects on my list. -- P > > > > On 17/06/15 09:08, Thomas Heute wrote: > >> > >> We have to upgrade to WF9 to get more data out of WF9. > >> > >> there are quite some changes to be made: > >> - Parent declares the version of WF to use and BOM: > >> here is my branch: > >> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > >> - Accounts need to upgrade to KC 1.3 (to be released this week) > >> Juca will work on this > >> - Bus/Nest needs to adapt > >> here is my branch > >> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another > >> patch from Mazz) > >> - Agent also needs some changes. > >> > >> WF 9 GA is supposed to go out at any point now, let's try to coordinate > >> around that, if you have a release pending, think of that. > >> > >> BTW, I tried to reflect the dependencies between component, would have > >> been easier if everyone could respect our standards, in particular: > >> - declare all dependencies at the root pom > >> - use in pom properties. > >> So please fix this if you do not follow those basic rules. > >> > >> PS: for the upstream project, it is ok if all dependencies don't fully > >> align, for instance 2 components could depend on 2 different versions of > >> the parent. > >> > >> Thomas > >> > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From tsegismo at redhat.com Fri Jun 19 11:05:10 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 19 Jun 2015 17:05:10 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <558424A1.30804@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> <558424A1.30804@redhat.com> Message-ID: <55842FA6.9090908@redhat.com> You've assigned it to Matt. Is that intentional? Le 19/06/2015 16:18, Thomas Heute a ?crit : > https://issues.jboss.org/browse/HWKMETRICS-145 > > On 06/19/2015 01:22 PM, Thomas Segismont wrote: >> Can you close your PR against Metrics and open a JIRA? There's an issue >> with the BOM we use. >> >> I'll take care of this. >> >> Le 19/06/2015 10:16, Peter Palaga a ?crit : >> > hawkular-parent 16 with an upgrade to WF9 was just released and I have >> > sent PRs to all projects on my list. -- P >> > >> > On 17/06/15 09:08, Thomas Heute wrote: >> >> >> >> We have to upgrade to WF9 to get more data out of WF9. >> >> >> >> there are quite some changes to be made: >> >> - Parent declares the version of WF to use and BOM: >> >> here is my branch: >> >> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >> >> - Accounts need to upgrade to KC 1.3 (to be released this week) >> >> Juca will work on this >> >> - Bus/Nest needs to adapt >> >> here is my branch >> >> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs >> another >> >> patch from Mazz) >> >> - Agent also needs some changes. >> >> >> >> WF 9 GA is supposed to go out at any point now, let's try to >> coordinate >> >> around that, if you have a release pending, think of that. >> >> >> >> BTW, I tried to reflect the dependencies between component, would have >> >> been easier if everyone could respect our standards, in particular: >> >> - declare all dependencies at the root pom >> >> - use in pom properties. >> >> So please fix this if you do not follow those basic rules. >> >> >> >> PS: for the upstream project, it is ok if all dependencies don't fully >> >> align, for instance 2 components could depend on 2 different >> versions of >> >> the parent. >> >> >> >> Thomas >> >> >> >> >> >> _______________________________________________ >> >> hawkular-dev mailing list >> >> hawkular-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> > >> > _______________________________________________ >> > hawkular-dev mailing list >> > hawkular-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > From mwringe at redhat.com Fri Jun 19 11:12:55 2015 From: mwringe at redhat.com (Matt Wringe) Date: Fri, 19 Jun 2015 11:12:55 -0400 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55842FA6.9090908@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> <558424A1.30804@redhat.com> <55842FA6.9090908@redhat.com> Message-ID: <55843177.1070900@redhat.com> Ah, I assumed that jira was just for updating the Docker image to WF9 :) On 19/06/15 11:05 AM, Thomas Segismont wrote: > You've assigned it to Matt. Is that intentional? > > Le 19/06/2015 16:18, Thomas Heute a ?crit : >> https://issues.jboss.org/browse/HWKMETRICS-145 >> >> On 06/19/2015 01:22 PM, Thomas Segismont wrote: >>> Can you close your PR against Metrics and open a JIRA? There's an issue >>> with the BOM we use. >>> >>> I'll take care of this. >>> >>> Le 19/06/2015 10:16, Peter Palaga a ?crit : >>>> hawkular-parent 16 with an upgrade to WF9 was just released and I have >>>> sent PRs to all projects on my list. -- P >>>> >>>> On 17/06/15 09:08, Thomas Heute wrote: >>>>> We have to upgrade to WF9 to get more data out of WF9. >>>>> >>>>> there are quite some changes to be made: >>>>> - Parent declares the version of WF to use and BOM: >>>>> here is my branch: >>>>> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >>>>> - Accounts need to upgrade to KC 1.3 (to be released this week) >>>>> Juca will work on this >>>>> - Bus/Nest needs to adapt >>>>> here is my branch >>>>> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs >>> another >>>>> patch from Mazz) >>>>> - Agent also needs some changes. >>>>> >>>>> WF 9 GA is supposed to go out at any point now, let's try to >>> coordinate >>>>> around that, if you have a release pending, think of that. >>>>> >>>>> BTW, I tried to reflect the dependencies between component, would have >>>>> been easier if everyone could respect our standards, in particular: >>>>> - declare all dependencies at the root pom >>>>> - use in pom properties. >>>>> So please fix this if you do not follow those basic rules. >>>>> >>>>> PS: for the upstream project, it is ok if all dependencies don't fully >>>>> align, for instance 2 components could depend on 2 different >>> versions of >>>>> the parent. >>>>> >>>>> Thomas >>>>> >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From tsegismo at redhat.com Fri Jun 19 11:30:11 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 19 Jun 2015 17:30:11 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55843177.1070900@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> <558424A1.30804@redhat.com> <55842FA6.9090908@redhat.com> <55843177.1070900@redhat.com> Message-ID: <55843583.10406@redhat.com> I knew the question was worth asking :) I'll start with testing the code, and see if I can do something for the Docker images build files. Does that work? Le 19/06/2015 17:12, Matt Wringe a ?crit : > Ah, I assumed that jira was just for updating the Docker image to WF9 :) > > On 19/06/15 11:05 AM, Thomas Segismont wrote: >> You've assigned it to Matt. Is that intentional? >> >> Le 19/06/2015 16:18, Thomas Heute a ?crit : >>> https://issues.jboss.org/browse/HWKMETRICS-145 >>> >>> On 06/19/2015 01:22 PM, Thomas Segismont wrote: >>>> Can you close your PR against Metrics and open a JIRA? There's an issue >>>> with the BOM we use. >>>> >>>> I'll take care of this. >>>> >>>> Le 19/06/2015 10:16, Peter Palaga a ?crit : >>>>> hawkular-parent 16 with an upgrade to WF9 was just released and I have >>>>> sent PRs to all projects on my list. -- P >>>>> >>>>> On 17/06/15 09:08, Thomas Heute wrote: >>>>>> We have to upgrade to WF9 to get more data out of WF9. >>>>>> >>>>>> there are quite some changes to be made: >>>>>> - Parent declares the version of WF to use and BOM: >>>>>> here is my branch: >>>>>> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 >>>>>> - Accounts need to upgrade to KC 1.3 (to be released this week) >>>>>> Juca will work on this >>>>>> - Bus/Nest needs to adapt >>>>>> here is my branch >>>>>> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs >>>> another >>>>>> patch from Mazz) >>>>>> - Agent also needs some changes. >>>>>> >>>>>> WF 9 GA is supposed to go out at any point now, let's try to >>>> coordinate >>>>>> around that, if you have a release pending, think of that. >>>>>> >>>>>> BTW, I tried to reflect the dependencies between component, would have >>>>>> been easier if everyone could respect our standards, in particular: >>>>>> - declare all dependencies at the root pom >>>>>> - use in pom properties. >>>>>> So please fix this if you do not follow those basic rules. >>>>>> >>>>>> PS: for the upstream project, it is ok if all dependencies don't fully >>>>>> align, for instance 2 components could depend on 2 different >>>> versions of >>>>>> the parent. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >> _______________________________________________ >> 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 vnguyen at redhat.com Fri Jun 19 14:50:21 2015 From: vnguyen at redhat.com (Viet Nguyen) Date: Fri, 19 Jun 2015 14:50:21 -0400 (EDT) Subject: [Hawkular-dev] Hawkular public instance is offline due to VM disk i/o issue (eom) In-Reply-To: <55843583.10406@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> <558424A1.30804@redhat.com> <55842FA6.9090908@redhat.com> <55843177.1070900@redhat.com> <55843583.10406@redhat.com> Message-ID: <1910775028.20020867.1434739821488.JavaMail.zimbra@redhat.com> From artur.dryomov at gmail.com Sat Jun 20 17:56:05 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Sun, 21 Jun 2015 00:56:05 +0300 Subject: [Hawkular-dev] Docker Image Message-ID: Hi everyone, I?m trying to run the Docker image using Vagrant and CoreOS. I can register an account, but after logging in I see an infinite progress bar and? that?s it. This behaviour is similar for ?URLs? and ?Application Servers? tabs. REST requests via console tools like cURL and HTTPie give me 500 error code all the time. I believe I compose correct commands, because the public community server and a standalone Hawkular instance from .zip snapshot [1] work fine with them. I?ve created a related issue some time ago with no feedback [2]. There is Docker information I have [3] and Vagrant configuration as well [4]. Is this behaviour well-known? Can it be fixed somehow in the future? Artur. [1]: http://www.hawkular.org/downloads.html [2]: https://issues.jboss.org/browse/HAWKULAR-268 [3]: http://pastie.org/private/ohx78eawvmvkhhui8omvza [4]: http://pastie.org/private/g9ay7tfs2pgvvjtluvzkha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150621/3d1106c9/attachment.html From artur.dryomov at gmail.com Sat Jun 20 18:26:41 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Sun, 21 Jun 2015 01:26:41 +0300 Subject: [Hawkular-dev] Alerts API Message-ID: Hi everyone, I?m trying to use Hawkular API with AeroGear for Android. Just to remind everyone, the Hawkular Alerts API uses HTTP PUT requests for actions such as resolve and acknowledge. Affected alert IDs are passed as a HTTP query parameter. As such, if I want to resolve an alert with ID ?oops?, I need to do the following request: http PUT :8080/hawkular/alerts/resolve?alertIds=oops At the same time, AeroGear uses PUT requests more traditionally, appending model ID to the request URL so it looks something like ?hawkular/alerts/resolve/oops?. As a result, I have no ability to use Alert actions using AeroGear, because there is no real way to customise the behaviour the easy way. The goal of this message is to start the discussion around this topic and maybe decide what is better to do from Hawkular or AeroGear side. I?m adding Daniel and Summers to the discussion as AeroGear Android developers, maybe they can elaborate a little and provide ideas and / or details. Artur. [1]: http://www.hawkular.org/docs/rest/rest-alerts.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150621/a52bd495/attachment-0001.html From artur.dryomov at gmail.com Sun Jun 21 17:39:58 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Mon, 22 Jun 2015 00:39:58 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #4 Message-ID: Hi everyone, This year I am working on the Hawkular Android application as part of the Google Summer of Code 2015 program. I?ve spent the last week mostly on the Alert-related activities.. At this point you can list alerts in a format very similar to the web UI [1]. There is a PR with actions support, but actual actions processing is delayed due to API and AeroGear limitations ? I?ve sent an email about it to the ML some time ago. The application got the push notifications support [3]. With a great help from #hawkular and #aerogear guys I finally managed to run the whole system, which includes Hawkular, Google Cloud Messaging and AeroGear Unified Push Server. The process at moment is not very end-user-friendly and there are no guides describing every step, so I combined one from various sources [4]. Unfortunately the format of messages sent by Hawkular is not great at moment, so only a generic notification is shown. This most likely will change in the future. I?ve rewrote the authorization procedure as well. It is now contained at a standalone screen [5]. There is a PR for a navigation drawer [6]. It will need some work to be merged so I can make it actually work. This week I would like to work on combining my efforts into a single state. By that I mean the navigation drawer integration, cleaning up screens and making them work together a bit better. Hopefully it will become a kind-of-ready-to-use application. Have a nice week! Artur. [1]: https://github.com/hawkular/hawkular-android-client/pull/13 [2]: https://github.com/hawkular/hawkular-android-client/pull/18 [3]: https://github.com/hawkular/hawkular-android-client/pull/15 [4]: https://github.com/hawkular/hawkular-android-client/wiki/Push-Notifications [5]: https://github.com/hawkular/hawkular-android-client/pull/16 [6]: https://github.com/hawkular/hawkular-android-client/pull/20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150622/29011e5f/attachment.html From mithomps at redhat.com Sun Jun 21 21:37:26 2015 From: mithomps at redhat.com (mike thompson) Date: Sun, 21 Jun 2015 18:37:26 -0700 Subject: [Hawkular-dev] A Nice Overview of the Monitoring Landscape Scene Message-ID: This is a pretty complete overview of the Monitoring Landscape Tools: including: System Monitoring Time Series Event Processing Web Monitoring APM Log Management etc... https://bigpanda.io/monitoringscape/ Should be good for some ideas ;) ? Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150621/c739d2eb/attachment.html From lponce at redhat.com Mon Jun 22 03:23:34 2015 From: lponce at redhat.com (Lucas Ponce) Date: Mon, 22 Jun 2015 03:23:34 -0400 (EDT) Subject: [Hawkular-dev] Alerts API In-Reply-To: References: Message-ID: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> Hi Artur, > > Hi everyone, > > I?m trying to use Hawkular API with AeroGear for Android. > > Just to remind everyone, the Hawkular Alerts API uses HTTP PUT requests for > actions such as resolve and acknowledge. Affected alert IDs are passed as a > HTTP query parameter. As such, if I want to resolve an alert with ID ?oops?, > I need to do the following request: > > http PUT :8080/hawkular/alerts/resolve?alertIds=oops > > At the same time, AeroGear uses PUT requests more traditionally, appending > model ID to the request URL so it looks something like > ?hawkular/alerts/resolve/oops?. As a result, I have no ability to use Alert > actions using AeroGear, because there is no real way to customise the > behaviour the easy way. > > The goal of this message is to start the discussion around this topic and > maybe decide what is better to do from Hawkular or AeroGear side. I?m adding > Daniel and Summers to the discussion as AeroGear Android developers, maybe > they can elaborate a little and provide ideas and / or details. > What model can work better for your use case ? If we pass the list of alertsId to resolve inside a json object can work better in that scenario ? Thanks, Lucas > Artur. > > [1]: http://www.hawkular.org/docs/rest/rest-alerts.html > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Mon Jun 22 03:25:41 2015 From: theute at redhat.com (Thomas Heute) Date: Mon, 22 Jun 2015 09:25:41 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55843177.1070900@redhat.com> References: <55811CE3.3010001@redhat.com> <5583CFC5.9010807@redhat.com> <5583FB92.8030702@redhat.com> <558424A1.30804@redhat.com> <55842FA6.9090908@redhat.com> <55843177.1070900@redhat.com> Message-ID: <5587B875.8070905@redhat.com> Took me a while to understand how that happened... I used "Containers" as component, thinking about server/web container and this automatically assigned to Matt... Sorry about that. Thomas On 06/19/2015 05:12 PM, Matt Wringe wrote: > Ah, I assumed that jira was just for updating the Docker image to WF9 :) > > On 19/06/15 11:05 AM, Thomas Segismont wrote: > > You've assigned it to Matt. Is that intentional? > > > > Le 19/06/2015 16:18, Thomas Heute a ?crit : > >> https://issues.jboss.org/browse/HWKMETRICS-145 > >> > >> On 06/19/2015 01:22 PM, Thomas Segismont wrote: > >>> Can you close your PR against Metrics and open a JIRA? There's an issue > >>> with the BOM we use. > >>> > >>> I'll take care of this. > >>> > >>> Le 19/06/2015 10:16, Peter Palaga a ?crit : > >>>> hawkular-parent 16 with an upgrade to WF9 was just released and I have > >>>> sent PRs to all projects on my list. -- P > >>>> > >>>> On 17/06/15 09:08, Thomas Heute wrote: > >>>>> We have to upgrade to WF9 to get more data out of WF9. > >>>>> > >>>>> there are quite some changes to be made: > >>>>> - Parent declares the version of WF to use and BOM: > >>>>> here is my branch: > >>>>> https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > >>>>> - Accounts need to upgrade to KC 1.3 (to be released this week) > >>>>> Juca will work on this > >>>>> - Bus/Nest needs to adapt > >>>>> here is my branch > >>>>> https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs > >>> another > >>>>> patch from Mazz) > >>>>> - Agent also needs some changes. > >>>>> > >>>>> WF 9 GA is supposed to go out at any point now, let's try to > >>> coordinate > >>>>> around that, if you have a release pending, think of that. > >>>>> > >>>>> BTW, I tried to reflect the dependencies between component, would > >>>>> have > >>>>> been easier if everyone could respect our standards, in particular: > >>>>> - declare all dependencies at the root pom > >>>>> - use in pom properties. > >>>>> So please fix this if you do not follow those basic rules. > >>>>> > >>>>> PS: for the upstream project, it is ok if all dependencies don't > >>>>> fully > >>>>> align, for instance 2 components could depend on 2 different > >>> versions of > >>>>> the parent. > >>>>> > >>>>> Thomas > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> hawkular-dev mailing list > >>>>> hawkular-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>>> > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Mon Jun 22 04:51:55 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Mon, 22 Jun 2015 10:51:55 +0200 Subject: [Hawkular-dev] WF 9 upgrade In-Reply-To: <55811CE3.3010001@redhat.com> References: <55811CE3.3010001@redhat.com> Message-ID: <5587CCAB.7040405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/17/2015 09:08 AM, Thomas Heute wrote: > > We have to upgrade to WF9 to get more data out of WF9. > > there are quite some changes to be made: - Parent declares the > version of WF to use and BOM: here is my branch: > https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244 > - Accounts need to upgrade to KC 1.3 (to be released this week) > Juca will work on this Accounts 1.0.6 was just released. It seems I don't have permissions to create a branch on the main hawkular repository, so, I've pushed it to my repo: http://git.io/vLHtB Note that the distribution from this branch won't even boot, because of changes required by other modules. This branch should be good to be merged with another branch or as base for further commits. > - Bus/Nest needs to adapt here is my branch > https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs > another patch from Mazz) - Agent also needs some changes. > - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVh8yrAAoJECKM1e+fkPrXLzYH/3/BB4KAS+ryPwsYLR7iSJnU dvpUUga47dLQAZ4nZRpLV1fn35rLGT/y9XxkURy8Mt7+dfB+diC1MlA75IQTTI95 g/CH50FzfF1aUyhL2PY5b4ARkRpIHR0P4p8x8Nl33PkcjkFLj+W8MNe6jmCpHGwH 6DfkEQNkNR5RSf41Ee2anyaonaOBTNXBbeSuoH238mptT1dIZTuxjAsNKJAnCpAs FSbxHE9u+HInQRP2xv7GGoAQyaKmW0m/JO6K61PiniDUPlFAwbPEpXSP/4cKFO44 hGxAKURKZg0AHbJXDO2Rm0alOspK2N7W8tSWSNHGgoriyUfjukqDDLlUOhIHd3w= =j2Jx -----END PGP SIGNATURE----- From tsegismo at redhat.com Mon Jun 22 10:18:23 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 22 Jun 2015 16:18:23 +0200 Subject: [Hawkular-dev] Parent POM and Wildfly BOM Message-ID: <5588192F.3030906@redhat.com> Hi everyone, I've been working on the changes needed in Metrics for the parent POM upgrade to version 16 (those introducing Wildfly 9). There are three things I noticed which I believe are worth sharing. Firstly beware that the Wildfly guys have changed their philosophy about the BOM: now they force the "provided" scope in the BOM and exclude all the dependencies they think you shouldn't care about as a EE7 application developer. On one hand it frees you from adding the provided scope declaration in your application POM. On the other hand, if you use one of the artifacts in tests then dependency resolution could suddenly be broken. Secondly our parent POM does not only declare the Wildfly POM in dependency management section, in also imports it. Which means that all our projects get forced versioning and scope, even if they are not Wildfly based. Thirdly, minor issue, the Wildfly Maven plugin does not configure a default Wildfly version which means that we are all forced to declare in components parent POMs. Like this in Metrics: https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196 Going forward, I propose that we no longer "import" the BOM in Hawkular parent, and let components do it where needed. And that we declare the Wildfly version to start with the Wildfly Maven plugin in the parent. Regards, Thomas From mazz at redhat.com Mon Jun 22 10:25:03 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 22 Jun 2015 10:25:03 -0400 (EDT) Subject: [Hawkular-dev] Parent POM and Wildfly BOM In-Reply-To: <5588192F.3030906@redhat.com> References: <5588192F.3030906@redhat.com> Message-ID: <1551507510.5959965.1434983103385.JavaMail.zimbra@redhat.com> > Firstly beware that the Wildfly guys have changed their philosophy about > the BOM: now they force the "provided" scope in the BOM and exclude all > the dependencies they think you shouldn't care about as a EE7 > application developer. FWIW, I believe that violates common Maven practice for them to explicitly declare provided scope in the BOM. They should change that. Has anyone asked them about it? I thought you should never declare scope in dependencyManagement? From tsegismo at redhat.com Mon Jun 22 10:27:58 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Mon, 22 Jun 2015 16:27:58 +0200 Subject: [Hawkular-dev] Parent POM and Wildfly BOM In-Reply-To: <1551507510.5959965.1434983103385.JavaMail.zimbra@redhat.com> References: <5588192F.3030906@redhat.com> <1551507510.5959965.1434983103385.JavaMail.zimbra@redhat.com> Message-ID: <55881B6E.6030901@redhat.com> Le 22/06/2015 16:25, John Mazzitelli a ?crit : >> Firstly beware that the Wildfly guys have changed their philosophy about >> the BOM: now they force the "provided" scope in the BOM and exclude all >> the dependencies they think you shouldn't care about as a EE7 >> application developer. > > FWIW, I believe that violates common Maven practice for them to explicitly declare provided scope in the BOM. They should change that. Has anyone asked them about it? I thought you should never declare scope in dependencyManagement? I haven't. I found the issue before lunch and first sent this email. From snegrea at redhat.com Mon Jun 22 19:12:26 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Mon, 22 Jun 2015 19:12:26 -0400 (EDT) Subject: [Hawkular-dev] Hawkular Metrics 0.4.0 - Release & Beyond In-Reply-To: <1612220746.6120317.1432919825994.JavaMail.zimbra@redhat.com> Message-ID: <2104056868.17547738.1435014746912.JavaMail.zimbra@redhat.com> Hello Everybody, I am happy to announce release 0.4.0 of Hawkular Metrics. The release is anchored by new Counter metric implementation, various stability enhancements, and Grafana integration updates. Release Updates There was an email thread on Hawkular Devel List about 1 week ago that announced some minor changes to the release process for Hawkular Metrics. This release is the first to apply the plan. Going forward, the project will follow JBoss Project Versioning (https://developer.jboss.org/wiki/JBossProjectVersioning) guidelines. To avoid confusion here is an explanation of the release version number. The current release 0.4.0.Final contains the code that was initially planned under 0.3.5. The version bump was required to align the release version with the release mechanics. But there are no surprising commits or changes in functionality that were not expected to be released. Here is a list of major changes in this release: 1) Documentation * Added a new, Metrics specific, documentation section on the Hawkular website * Installation, configuration and Grafana integration are covered * Link: http://www.hawkular.org/docs/components/metrics/index.html 2) External Integration * The Grafana graph panel editor is now able to autocomplete the metric name * Documentation regrading the Grafana integration is now covered by the official Hawkular Metrics documentation (see above) * Heapster versions 0.14.0 and up can use Hawkular-Metrics as their time series data storage. 3) Updates to core API** (https://issues.jboss.org/browse/HWKMETRICS-113) * Metric is now a concrete type. GaugeMetric and AvailabilityMetric classes have been removed. * The new DataPoint class replaces the former GaugeDataPoint and AvailabilityDataPoint classes. * All of the new model classes are immutable. We will continue refactoring to make model classes immutable. * Swagger and Jackson dependencies have been removed from core 4) Cassandra * Cassandra Java driver upgraded to version 2.1.6 (https://issues.jboss.org/browse/HWKMETRICS-109) * Embedded Cassandra is no longer part of the Hawkular Metrics * Cassandra is now an integral part of Hawkular Project * Embedded Cassandra has been moved to Hawkular Commons(https://github.com/hawkular/hawkular-commons) repository * For now, will keep including the compatible embedded jar distribution as part of the release downloads * NOTE: the embedded Cassandra should only be used for testing, debugging, or developing Hawkular Metrics. In production environments please use a full Cassandra deployment. 5) Updated Counter Metric (https://issues.jboss.org/browse/HWKMETRICS-53, https://issues.jboss.org/browse/HWKMETRICS-59) * Core and REST APIs support reading/writing counters * Core API supports generating and reading rates * REST API for rates will come in next release 6) Developer tools * Gatling load testing scenario added * Source code: https://github.com/hawkular/hawkular-metrics/tree/master/load-tests * This is part of the on-going effort for testing and performance profiling Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.4.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/12327451/ Hawkular Metrics 0.5.0 & Beyond 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.5.0. 2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. 3) Improved docker and kubernetes support - this is a long term goal for the project 4) The counters will received improved REST API support 5) Initial support in the Python & Golang clients for counters A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Jirka Kremser, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer From mazz at redhat.com Mon Jun 22 20:27:41 2015 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 22 Jun 2015 20:27:41 -0400 (EDT) Subject: [Hawkular-dev] new hawkular build In-Reply-To: <296038401.6234507.1435018994848.JavaMail.zimbra@redhat.com> Message-ID: <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> The hawkular/hawkular repo (hawkular-nest branch) is close to being ready for WF9. It builds, and seems to run OK except for an issue in inventory which Jiri has a fix for that he'll push. The agent is kinda ready - I can't release until inventory 0.1.0 is released, but it should be ready to work with the new inventory other than just waiting for the inventory release. The agent is also ready for the new metrics 0.4.0 that was released. I don't know the state of the UI, alerts, and accounts with respect to the new hawkular-next branch - but I think they are close if not fully ready. So we are close to getting a full integration build that runs on WF9. From theute at redhat.com Tue Jun 23 03:26:57 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 23 Jun 2015 09:26:57 +0200 Subject: [Hawkular-dev] Hawkular Metrics 0.4.0 - Release & Beyond In-Reply-To: <2104056868.17547738.1435014746912.JavaMail.zimbra@redhat.com> References: <2104056868.17547738.1435014746912.JavaMail.zimbra@redhat.com> Message-ID: <55890A41.9000007@redhat.com> Congrats and thank you for the release + detailed release note ! Thomas On 06/23/2015 01:12 AM, Stefan Negrea wrote: > Hello Everybody, > > I am happy to announce release 0.4.0 of Hawkular Metrics. The release is anchored by new Counter metric implementation, various stability enhancements, and Grafana integration updates. > > > Release Updates > > There was an email thread on Hawkular Devel List about 1 week ago that announced some minor changes to the release process for Hawkular Metrics. This release is the first to apply the plan. Going forward, the project will follow JBoss Project Versioning (https://developer.jboss.org/wiki/JBossProjectVersioning) guidelines. > > To avoid confusion here is an explanation of the release version number. The current release 0.4.0.Final contains the code that was initially planned under 0.3.5. The version bump was required to align the release version with the release mechanics. But there are no surprising commits or changes in functionality that were not expected to be released. > > > > Here is a list of major changes in this release: > > 1) Documentation > * Added a new, Metrics specific, documentation section on the Hawkular website > * Installation, configuration and Grafana integration are covered > * Link: http://www.hawkular.org/docs/components/metrics/index.html > > 2) External Integration > * The Grafana graph panel editor is now able to autocomplete the metric name > * Documentation regrading the Grafana integration is now covered by the official Hawkular Metrics documentation (see above) > * Heapster versions 0.14.0 and up can use Hawkular-Metrics as their time series data storage. > > 3) Updates to core API** (https://issues.jboss.org/browse/HWKMETRICS-113) > * Metric is now a concrete type. GaugeMetric and AvailabilityMetric classes have been removed. > * The new DataPoint class replaces the former GaugeDataPoint and AvailabilityDataPoint classes. > * All of the new model classes are immutable. We will continue refactoring to make model classes immutable. > * Swagger and Jackson dependencies have been removed from core > > 4) Cassandra > * Cassandra Java driver upgraded to version 2.1.6 (https://issues.jboss.org/browse/HWKMETRICS-109) > * Embedded Cassandra is no longer part of the Hawkular Metrics > * Cassandra is now an integral part of Hawkular Project > * Embedded Cassandra has been moved to Hawkular Commons(https://github.com/hawkular/hawkular-commons) repository > * For now, will keep including the compatible embedded jar distribution as part of the release downloads > * NOTE: the embedded Cassandra should only be used for testing, debugging, or developing Hawkular Metrics. In production environments please use a full Cassandra deployment. > > 5) Updated Counter Metric (https://issues.jboss.org/browse/HWKMETRICS-53, https://issues.jboss.org/browse/HWKMETRICS-59) > * Core and REST APIs support reading/writing counters > * Core API supports generating and reading rates > * REST API for rates will come in next release > > 6) Developer tools > * Gatling load testing scenario added > * Source code: https://github.com/hawkular/hawkular-metrics/tree/master/load-tests > * This is part of the on-going effort for testing and performance profiling > > > Github Release: > https://github.com/hawkular/hawkular-metrics/releases/tag/0.4.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/12327451/ > > > > Hawkular Metrics 0.5.0 & Beyond > > 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.5.0. > 2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. > 3) Improved docker and kubernetes support - this is a long term goal for the project > 4) The counters will received improved REST API support > 5) Initial support in the Python & Golang clients for counters > > > A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Jirka Kremser, and Heiko Rupp for their project contributions. > > > Thank you, > Stefan Negrea > > Software Engineer > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Tue Jun 23 03:28:15 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 23 Jun 2015 09:28:15 +0200 Subject: [Hawkular-dev] new hawkular build In-Reply-To: <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> References: <296038401.6234507.1435018994848.JavaMail.zimbra@redhat.com> <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> Message-ID: <55890A8F.5090203@redhat.com> Thanks for the update ! On 06/23/2015 02:27 AM, John Mazzitelli wrote: > The hawkular/hawkular repo (hawkular-nest branch) is close to being ready for WF9. It builds, and seems to run OK except for an issue in inventory which Jiri has a fix for that he'll push. > > The agent is kinda ready - I can't release until inventory 0.1.0 is released, but it should be ready to work with the new inventory other than just waiting for the inventory release. The agent is also ready for the new metrics 0.4.0 that was released. > > I don't know the state of the UI, alerts, and accounts with respect to the new hawkular-next branch - but I think they are close if not fully ready. > > So we are close to getting a full integration build that runs on WF9. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From artur.dryomov at gmail.com Tue Jun 23 03:41:41 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 23 Jun 2015 10:41:41 +0300 Subject: [Hawkular-dev] Alerts API In-Reply-To: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> References: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> Message-ID: Hey Lucas, Not really sure actually. What Daniel suggested and what is actually supported at this point by AeroGear looks something like this. http PUT /hawkular/alerts/resolve/ALERT-ID Artur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150623/c35f88a5/attachment.html From lponce at redhat.com Tue Jun 23 03:47:02 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 23 Jun 2015 03:47:02 -0400 (EDT) Subject: [Hawkular-dev] Alerts API In-Reply-To: References: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> Message-ID: <2066173822.6331040.1435045622849.JavaMail.zimbra@redhat.com> > > Hey Lucas, > > Not really sure actually. What Daniel suggested and what is actually > supported at this point by AeroGear looks something like this. > > http PUT /hawkular/alerts/resolve/ALERT-ID > I'm thinking if we may maintain both approaches, one endpoint as you suggest for individual alert resolution, and a second one with an object as payload with a list of alert-id. A common scenario might need to resolve a group of ids in one step. Ok, I'm going to update this info in a formal JIRA. Thanks for the feedback. Lucas From artur.dryomov at gmail.com Tue Jun 23 03:54:57 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Tue, 23 Jun 2015 10:54:57 +0300 Subject: [Hawkular-dev] Alerts API In-Reply-To: <2066173822.6331040.1435045622849.JavaMail.zimbra@redhat.com> References: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> <2066173822.6331040.1435045622849.JavaMail.zimbra@redhat.com> Message-ID: Yep, I understand. I will understand if you decide not to update API as well :-) It would be great to provide the most universal API possible, without adjusting to any specific tools. I heard about batch requests [1] some time ago, maybe it can help. [1]: https://developers.google.com/drive/web/batch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150623/df7bb334/attachment.html From lponce at redhat.com Tue Jun 23 04:00:35 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 23 Jun 2015 04:00:35 -0400 (EDT) Subject: [Hawkular-dev] Alerts API In-Reply-To: References: <317462540.5663564.1434957814315.JavaMail.zimbra@redhat.com> <2066173822.6331040.1435045622849.JavaMail.zimbra@redhat.com> Message-ID: <647717695.6337492.1435046435400.JavaMail.zimbra@redhat.com> I've created a JIRA to track this enhancement: https://issues.jboss.org/browse/HWKALERTS-60 It's interesting to get feedback to see what is best approach. I'm collecting all feedback to review whole REST API if needed. Feel free to comment on the JIRA as well. Thanks, Lucas ----- Original Message ----- > From: "Artur Dryomov" > To: "Discussions around Hawkular development" > Cc: supittma at redhat.com > Sent: Tuesday, June 23, 2015 9:54:57 AM > Subject: Re: [Hawkular-dev] Alerts API > > Yep, I understand. I will understand if you decide not to update API as well > :-) It would be great to provide the most universal API possible, without > adjusting to any specific tools. > > I heard about batch requests [1] some time ago, maybe it can help. > > [1]: https://developers.google.com/drive/web/batch > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Tue Jun 23 05:49:59 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 23 Jun 2015 11:49:59 +0200 Subject: [Hawkular-dev] Hawkular Metrics 0.4.0 - Release & Beyond In-Reply-To: <55890A41.9000007@redhat.com> References: <2104056868.17547738.1435014746912.JavaMail.zimbra@redhat.com> <55890A41.9000007@redhat.com> Message-ID: <55892BC7.8000605@redhat.com> Actually it's so well written that it should be in the blog. Wink wink looking at Stefan ;) Thomas On 06/23/2015 09:26 AM, Thomas Heute wrote: > Congrats and thank you for the release + detailed release note ! > > Thomas > > On 06/23/2015 01:12 AM, Stefan Negrea wrote: > > Hello Everybody, > > > > I am happy to announce release 0.4.0 of Hawkular Metrics. The release is anchored by new Counter metric implementation, various stability enhancements, and Grafana integration updates. > > > > > > Release Updates > > > > There was an email thread on Hawkular Devel List about 1 week ago that announced some minor changes to the release process for Hawkular Metrics. This release is the first to apply the plan. Going forward, the project will follow JBoss Project Versioning (https://developer.jboss.org/wiki/JBossProjectVersioning) guidelines. > > > > To avoid confusion here is an explanation of the release version number. The current release 0.4.0.Final contains the code that was initially planned under 0.3.5. The version bump was required to align the release version with the release mechanics. But there are no surprising commits or changes in functionality that were not expected to be released. > > > > > > > > Here is a list of major changes in this release: > > > > 1) Documentation > > * Added a new, Metrics specific, documentation section on the Hawkular website > > * Installation, configuration and Grafana integration are covered > > * Link: http://www.hawkular.org/docs/components/metrics/index.html > > > > 2) External Integration > > * The Grafana graph panel editor is now able to autocomplete the metric name > > * Documentation regrading the Grafana integration is now covered by the official Hawkular Metrics documentation (see above) > > * Heapster versions 0.14.0 and up can use Hawkular-Metrics as their time series data storage. > > > > 3) Updates to core API** (https://issues.jboss.org/browse/HWKMETRICS-113) > > * Metric is now a concrete type. GaugeMetric and AvailabilityMetric classes have been removed. > > * The new DataPoint class replaces the former GaugeDataPoint and AvailabilityDataPoint classes. > > * All of the new model classes are immutable. We will continue refactoring to make model classes immutable. > > * Swagger and Jackson dependencies have been removed from core > > > > 4) Cassandra > > * Cassandra Java driver upgraded to version 2.1.6 (https://issues.jboss.org/browse/HWKMETRICS-109) > > * Embedded Cassandra is no longer part of the Hawkular Metrics > > * Cassandra is now an integral part of Hawkular Project > > * Embedded Cassandra has been moved to Hawkular Commons(https://github.com/hawkular/hawkular-commons) repository > > * For now, will keep including the compatible embedded jar distribution as part of the release downloads > > * NOTE: the embedded Cassandra should only be used for testing, debugging, or developing Hawkular Metrics. In production environments please use a full Cassandra deployment. > > > > 5) Updated Counter Metric (https://issues.jboss.org/browse/HWKMETRICS-53, https://issues.jboss.org/browse/HWKMETRICS-59) > > * Core and REST APIs support reading/writing counters > > * Core API supports generating and reading rates > > * REST API for rates will come in next release > > > > 6) Developer tools > > * Gatling load testing scenario added > > * Source code: https://github.com/hawkular/hawkular-metrics/tree/master/load-tests > > * This is part of the on-going effort for testing and performance profiling > > > > > > Github Release: > > https://github.com/hawkular/hawkular-metrics/releases/tag/0.4.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/12327451/ > > > > > > > > Hawkular Metrics 0.5.0 & Beyond > > > > 1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.5.0. > > 2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low. > > 3) Improved docker and kubernetes support - this is a long term goal for the project > > 4) The counters will received improved REST API support > > 5) Initial support in the Python & Golang clients for counters > > > > > > A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Jirka Kremser, and Heiko Rupp for their project contributions. > > > > > > 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 hrupp at redhat.com Tue Jun 23 06:00:22 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 23 Jun 2015 12:00:22 +0200 Subject: [Hawkular-dev] Hawkular Metrics 0.4.0 - Release & Beyond In-Reply-To: <55892BC7.8000605@redhat.com> References: <2104056868.17547738.1435014746912.JavaMail.zimbra@redhat.com> <55890A41.9000007@redhat.com> <55892BC7.8000605@redhat.com> Message-ID: On 23 Jun 2015, at 11:49, Thomas Heute wrote: > Actually it's so well written that it should be in the blog. Wink wink > looking at Stefan ;) https://github.com/hawkular/hawkular.github.io/pull/46 From ppalaga at redhat.com Tue Jun 23 08:57:09 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 23 Jun 2015 14:57:09 +0200 Subject: [Hawkular-dev] Solved in Parent 17: JavaDoc Plugin failing during release:perform Message-ID: <558957A5.4010206@redhat.com> Hi *, I could finally find why the JavaDoc plugin was failing during release:perform. The ${javadoc.doclint} parameter set in "release" profile in parent [1] was ignored because the "release" profile simply was not active during release:perform. I always thought that release plugin activates the profile with this name during release:perform by default. Apparently, it is not the case. The solution was to add an explicit release to the of release plugin [2]. The change is there in hawkular-parent 17 that I have just released. I am about to send PRs to consuming projects. Sorry for the inconvenience that was caused solely by my ignorance. BTW, for those, who want to assure the quality their JavaDoc manually, this will fail if there is any problem in JavaDoc: mvn clean install -Prelease -Djavadoc.doclint=-Xdoclint:all The variant without -Djavadoc.doclint=-Xdoclint:all will just output all warnings and will not fail: mvn clean install -Prelease Best, Peter [1] https://github.com/hawkular/hawkular-parent-pom/blob/a0e3a27165b140bbe4b6ba86a7cc96a427b77217/pom.xml#L785 [2] https://github.com/hawkular/hawkular-parent-pom/commit/6acd616c53d0f1a14a3c4d5d13785cd1079ee25f From mazz at redhat.com Tue Jun 23 09:04:55 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 23 Jun 2015 09:04:55 -0400 (EDT) Subject: [Hawkular-dev] Solved in Parent 17: JavaDoc Plugin failing during release:perform In-Reply-To: <558957A5.4010206@redhat.com> References: <558957A5.4010206@redhat.com> Message-ID: <1954826673.6497520.1435064695588.JavaMail.zimbra@redhat.com> Thank you!!!! That deserves a Red Hat Rewards nomination! Coming your way... :-) ----- Original Message ----- > Hi *, > > I could finally find why the JavaDoc plugin was failing during > release:perform. > > The ${javadoc.doclint} parameter set > in "release" profile in parent [1] was ignored because the "release" > profile simply was not active during release:perform. > > I always thought that release plugin activates the profile with this > name during release:perform by default. Apparently, it is not the case. > The solution was to add an explicit > > release > > to the of release plugin [2]. The change is there in > hawkular-parent 17 that I have just released. I am about to send PRs to > consuming projects. > > Sorry for the inconvenience that was caused solely by my ignorance. > > > BTW, for those, who want to assure the quality their JavaDoc manually, > this will fail if there is any problem in JavaDoc: > > mvn clean install -Prelease -Djavadoc.doclint=-Xdoclint:all > > The variant without -Djavadoc.doclint=-Xdoclint:all will just output all > warnings and will not fail: > > mvn clean install -Prelease > > Best, > > Peter > > [1] > https://github.com/hawkular/hawkular-parent-pom/blob/a0e3a27165b140bbe4b6ba86a7cc96a427b77217/pom.xml#L785 > > [2] > https://github.com/hawkular/hawkular-parent-pom/commit/6acd616c53d0f1a14a3c4d5d13785cd1079ee25f > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Tue Jun 23 09:07:35 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 23 Jun 2015 15:07:35 +0200 Subject: [Hawkular-dev] Solved in Parent 17: JavaDoc Plugin failing during release:perform In-Reply-To: <1954826673.6497520.1435064695588.JavaMail.zimbra@redhat.com> References: <558957A5.4010206@redhat.com> <1954826673.6497520.1435064695588.JavaMail.zimbra@redhat.com> Message-ID: <55895A17.403@redhat.com> On 23/06/15 15:04, John Mazzitelli wrote: > Thank you!!!! That deserves a Red Hat Rewards nomination! Coming your way... :-) Earning rewards by a mere ignorance!?!? /me is shaming ;) -- P > ----- Original Message ----- >> Hi *, >> >> I could finally find why the JavaDoc plugin was failing during >> release:perform. >> >> The ${javadoc.doclint} parameter set >> in "release" profile in parent [1] was ignored because the "release" >> profile simply was not active during release:perform. >> >> I always thought that release plugin activates the profile with this >> name during release:perform by default. Apparently, it is not the case. >> The solution was to add an explicit >> >> release >> >> to the of release plugin [2]. The change is there in >> hawkular-parent 17 that I have just released. I am about to send PRs to >> consuming projects. >> >> Sorry for the inconvenience that was caused solely by my ignorance. >> >> >> BTW, for those, who want to assure the quality their JavaDoc manually, >> this will fail if there is any problem in JavaDoc: >> >> mvn clean install -Prelease -Djavadoc.doclint=-Xdoclint:all >> >> The variant without -Djavadoc.doclint=-Xdoclint:all will just output all >> warnings and will not fail: >> >> mvn clean install -Prelease >> >> Best, >> >> Peter >> >> [1] >> https://github.com/hawkular/hawkular-parent-pom/blob/a0e3a27165b140bbe4b6ba86a7cc96a427b77217/pom.xml#L785 >> >> [2] >> https://github.com/hawkular/hawkular-parent-pom/commit/6acd616c53d0f1a14a3c4d5d13785cd1079ee25f >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Tue Jun 23 11:25:41 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Tue, 23 Jun 2015 11:25:41 -0400 Subject: [Hawkular-dev] Hawkular Alerts 0.2.0.Final released Message-ID: <55897A75.7070700@redhat.com> Hawkular 0.2.0.Final has been Released. It includes the following work in Jira: https://issues.jboss.org/issues/?jql=project%20%3D%20HWKALERTS%20AND%20fixVersion%20%3D%200.2.0.Final Additionally, it contains changes for Hawkular WF9 support and a fix for Alert pagination. The next scheduled version is 0.3.0.Final sometime in the next few weeks. -Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150623/38762702/attachment.html From gbrown at redhat.com Wed Jun 24 04:45:56 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 04:45:56 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <443370232.19908813.1435135131356.JavaMail.zimbra@redhat.com> Message-ID: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> Hi Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency? When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties? Possibly metrics needs the concept of a tag/label as well? Regards Gary From theute at redhat.com Wed Jun 24 05:02:14 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 24 Jun 2015 11:02:14 +0200 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> References: <443370232.19908813.1435135131356.JavaMail.zimbra@redhat.com> <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> Message-ID: <558A7216.3040606@redhat.com> Good point, I guess inventory has or needs tags/labels too Thomas On 06/24/2015 10:45 AM, Gary Brown wrote: > Hi > > Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency? > > When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties? > > Possibly metrics needs the concept of a tag/label as well? > > Regards > Gary > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From miburman at redhat.com Wed Jun 24 06:25:00 2015 From: miburman at redhat.com (Michael Burman) Date: Wed, 24 Jun 2015 06:25:00 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> Message-ID: <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> Hi, I don't agree with changing the terms. Many of metrics competing products (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand the differences and similarities between products. Using different terminology was one of the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should repeat the same mistake. - Micke ----- Original Message ----- From: "Gary Brown" To: "Discussions around Hawkular development" Sent: Wednesday, June 24, 2015 11:45:56 AM Subject: [Hawkular-dev] Tag concept in metrics and alerts Hi Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency? When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties? Possibly metrics needs the concept of a tag/label as well? Regards Gary _______________________________________________ hawkular-dev mailing list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev From ppalaga at redhat.com Wed Jun 24 06:32:03 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 24 Jun 2015 12:32:03 +0200 Subject: [Hawkular-dev] Hawkular Commons 0.1.1.Final (a.k.a. Embedded Cassandra) released Message-ID: <558A8723.508@redhat.com> Hi *, I just released Hawkular Commons 0.1.1.Final. This release fixes 0.1.0.Final which did not work at all in Hawkular. Changes: https://github.com/hawkular/hawkular-commons/commits/0.1.1.Final As agreed with Heiko, this release introduces the tagging scheme with tags in master, which we find more intuitive and more common than the scheme used in Metrics which has tags only in maintenance branches thus making important points of the history invisible in master. I am personally sorry not to have enough time to discuss the change with the originators of the original tagging policy before changing the policy. We needed to release to fix Hawkular and there seemed to exist a broader consensus that having tags in master is better. Best, Peter From theute at redhat.com Wed Jun 24 06:35:53 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 24 Jun 2015 12:35:53 +0200 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> Message-ID: <558A8809.8090302@redhat.com> Not using the same terminology as "industry standards" is a problem, not using the same terminology within Hawkular small world is another... Can we solve both ? Thomas On 06/24/2015 12:25 PM, Michael Burman wrote: > Hi, > > I don't agree with changing the terms. Many of metrics competing products (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand the differences and similarities between products. Using different terminology was one of the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should repeat the same mistake. > > - Micke > > ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Wednesday, June 24, 2015 11:45:56 AM > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > Hi > > Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency? > > When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties? > > Possibly metrics needs the concept of a tag/label as well? > > Regards > Gary > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Wed Jun 24 06:43:56 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 06:43:56 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <558A8809.8090302@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> Message-ID: <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> +1 I don't mind if we adopt Tag as being name/value pair - but then we should use the same approach in Alerts. I actually need the Alert to have ability to record name/value pairs so this would suit my need, but they would then they would need to change their current Tag to be something else, possibly Label? Regards Gary ----- Original Message ----- > Not using the same terminology as "industry standards" is a problem, not > using the same terminology within Hawkular small world is another... > Can we solve both ? > > Thomas > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > Hi, > > > > I don't agree with changing the terms. Many of metrics competing products > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier > > for customers to understand the differences and similarities between > > products. Using different terminology was one of the difficulties in RHQ > > (like noted in the F2F meeting) and I don't think we should repeat the > > same mistake. > > > > - Micke > > > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Discussions around Hawkular development" > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > Hi > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > name/value pair for a tag, and alerts uses it as a label. Wondering > > whether we need consistency? > > > > When I hear the term tag, I usually envisage a label - e.g. as in git. So > > wondering whether it would be clearer for metrics to rename tags to > > properties? > > > > Possibly metrics needs the concept of a tag/label as well? > > > > Regards > > Gary > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Wed Jun 24 06:55:51 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 24 Jun 2015 06:55:51 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> Message-ID: <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> Perhaps a rename to "Label" can be valid. Gary, is there some place where I can find more details about the context ? (Just to understand the whole scenario and see if what can be needed/interesting). Thanks, Lucas ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Wednesday, June 24, 2015 12:43:56 PM > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > +1 > > I don't mind if we adopt Tag as being name/value pair - but then we should > use the same approach in Alerts. I actually need the Alert to have ability > to record name/value pairs so this would suit my need, but they would then > they would need to change their current Tag to be something else, possibly > Label? > > Regards > Gary > > ----- Original Message ----- > > Not using the same terminology as "industry standards" is a problem, not > > using the same terminology within Hawkular small world is another... > > Can we solve both ? > > > > Thomas > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > Hi, > > > > > > I don't agree with changing the terms. Many of metrics competing products > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier > > > for customers to understand the differences and similarities between > > > products. Using different terminology was one of the difficulties in RHQ > > > (like noted in the F2F meeting) and I don't think we should repeat the > > > same mistake. > > > > > > - Micke > > > > > > ----- Original Message ----- > > > From: "Gary Brown" > > > To: "Discussions around Hawkular development" > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > Hi > > > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > > name/value pair for a tag, and alerts uses it as a label. Wondering > > > whether we need consistency? > > > > > > When I hear the term tag, I usually envisage a label - e.g. as in git. So > > > wondering whether it would be clearer for metrics to rename tags to > > > properties? > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > Regards > > > Gary > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Wed Jun 24 07:14:47 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 07:14:47 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> Message-ID: <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> Hi Lucas The context is around the topic of HWKALERTS-49 - being able to replicate the RTGov 'situation' functionality using alerts. I think the main part missing at the moment is being able to associate the Alert with the business transaction information that caused it. I believe there are two scenarios that may occur, where business transaction data may result in an Alert: (1) metrics derived from the business transaction data are applied to the alert engine resulting in an alert - the persisted Alert will need to contain some link back to the business transaction. Metrics has their 'tag' name/value pair, which I believe could be used to store this info when the metric is created - so just need a way to carry that over into the alert. (2) other 'events' - so for example, if we identify some situation of interest (a service failure), we create an object representing that situation and send it to the alerts engine - again the originating business transaction id would need to be carried across via the intermediate 'service failure' object. Is it possible this could be handled by the work you are doing on HALERT-57? Regards Gary ----- Original Message ----- > Perhaps a rename to "Label" can be valid. > > Gary, is there some place where I can find more details about the context ? > > (Just to understand the whole scenario and see if what can be > needed/interesting). > > Thanks, > Lucas > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Discussions around Hawkular development" > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > +1 > > > > I don't mind if we adopt Tag as being name/value pair - but then we should > > use the same approach in Alerts. I actually need the Alert to have ability > > to record name/value pairs so this would suit my need, but they would then > > they would need to change their current Tag to be something else, possibly > > Label? > > > > Regards > > Gary > > > > ----- Original Message ----- > > > Not using the same terminology as "industry standards" is a problem, not > > > using the same terminology within Hawkular small world is another... > > > Can we solve both ? > > > > > > Thomas > > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > > Hi, > > > > > > > > I don't agree with changing the terms. Many of metrics competing > > > > products > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier > > > > for customers to understand the differences and similarities between > > > > products. Using different terminology was one of the difficulties in > > > > RHQ > > > > (like noted in the F2F meeting) and I don't think we should repeat the > > > > same mistake. > > > > > > > > - Micke > > > > > > > > ----- Original Message ----- > > > > From: "Gary Brown" > > > > To: "Discussions around Hawkular development" > > > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > Hi > > > > > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > > > name/value pair for a tag, and alerts uses it as a label. Wondering > > > > whether we need consistency? > > > > > > > > When I hear the term tag, I usually envisage a label - e.g. as in git. > > > > So > > > > wondering whether it would be clearer for metrics to rename tags to > > > > properties? > > > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > > > Regards > > > > Gary > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Wed Jun 24 07:27:18 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 24 Jun 2015 07:27:18 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> Message-ID: <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> Thx Gary, Comments in-line, > > Hi Lucas > > The context is around the topic of HWKALERTS-49 - being able to replicate the > RTGov 'situation' functionality using alerts. I think the main part missing > at the moment is being able to associate the Alert with the business > transaction information that caused it. > > I believe there are two scenarios that may occur, where business transaction > data may result in an Alert: > > (1) metrics derived from the business transaction data are applied to the > alert engine resulting in an alert - the persisted Alert will need to > contain some link back to the business transaction. Metrics has their 'tag' > name/value pair, which I believe could be used to store this info when the > metric is created - so just need a way to carry that over into the alert. > > (2) other 'events' - so for example, if we identify some situation of > interest (a service failure), we create an object representing that > situation and send it to the alerts engine - again the originating business > transaction id would need to be carried across via the intermediate 'service > failure' object. > > Is it possible this could be handled by the work you are doing on HALERT-57? > In HWKALERTS-57 we are improving the Action model to pass the Alert that was linked and also the Alert should have information about the definition who triggered it. So, having an action, you will have the alert and the definition data. If the business transaction info is "mapped" into the definition, the action will have it. These requeriments were addressed by plugins but as we are still working on it, we can join other requeriments in the same context to improve it. How do you plan to map the BTM info into the definition ? using Tags ? That can help me to add/modify some aspect of the present work. Thanks, Lucas > Regards > Gary > > ----- Original Message ----- > > Perhaps a rename to "Label" can be valid. > > > > Gary, is there some place where I can find more details about the context ? > > > > (Just to understand the whole scenario and see if what can be > > needed/interesting). > > > > Thanks, > > Lucas > > > > ----- Original Message ----- > > > From: "Gary Brown" > > > To: "Discussions around Hawkular development" > > > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > +1 > > > > > > I don't mind if we adopt Tag as being name/value pair - but then we > > > should > > > use the same approach in Alerts. I actually need the Alert to have > > > ability > > > to record name/value pairs so this would suit my need, but they would > > > then > > > they would need to change their current Tag to be something else, > > > possibly > > > Label? > > > > > > Regards > > > Gary > > > > > > ----- Original Message ----- > > > > Not using the same terminology as "industry standards" is a problem, > > > > not > > > > using the same terminology within Hawkular small world is another... > > > > Can we solve both ? > > > > > > > > Thomas > > > > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > > > Hi, > > > > > > > > > > I don't agree with changing the terms. Many of metrics competing > > > > > products > > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is > > > > > easier > > > > > for customers to understand the differences and similarities between > > > > > products. Using different terminology was one of the difficulties in > > > > > RHQ > > > > > (like noted in the F2F meeting) and I don't think we should repeat > > > > > the > > > > > same mistake. > > > > > > > > > > - Micke > > > > > > > > > > ----- Original Message ----- > > > > > From: "Gary Brown" > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > Hi > > > > > > > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > > > > name/value pair for a tag, and alerts uses it as a label. Wondering > > > > > whether we need consistency? > > > > > > > > > > When I hear the term tag, I usually envisage a label - e.g. as in > > > > > git. > > > > > So > > > > > wondering whether it would be clearer for metrics to rename tags to > > > > > properties? > > > > > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > > > > > Regards > > > > > Gary > > > > > _______________________________________________ > > > > > hawkular-dev mailing list > > > > > hawkular-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > > > > hawkular-dev mailing list > > > > > hawkular-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Wed Jun 24 07:40:34 2015 From: jsanda at redhat.com (John Sanda) Date: Wed, 24 Jun 2015 07:40:34 -0400 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> Message-ID: <20D51909-5E68-4CBB-A6AD-71EE8F761B32@redhat.com> Originally tags were implemented just as a label, not a key/value pair. I saw that a number of other time series dbs use key/value pairs and decided to make the change. It can also produce more efficient queries. For example, filtering against N labels would require querying N partitions (in the original schema). Querying against one tag name with N different values however would only require querying 1 partition. > On Jun 24, 2015, at 6:25 AM, Michael Burman wrote: > > Hi, > > I don't agree with changing the terms. Many of metrics competing products (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand the differences and similarities between products. Using different terminology was one of the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should repeat the same mistake. > > - Micke > > ----- Original Message ----- > From: "Gary Brown" > To: "Discussions around Hawkular development" > Sent: Wednesday, June 24, 2015 11:45:56 AM > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > Hi > > Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency? > > When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties? > > Possibly metrics needs the concept of a tag/label as well? > > Regards > Gary > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From gbrown at redhat.com Wed Jun 24 07:47:15 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 07:47:15 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> Message-ID: <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> Hi Lucas Not sure the alert or definition will be appropriate - assuming that the definition is a static representation of the trigger? The information (business transaction id) I am referring to is per business transaction instance - i.e. it is unique for each invocation of a business transaction. So this can only be obtained from the information being evaluated by the trigger. Let me know if I have misunderstand what you meant as definition. Regards Gary ----- Original Message ----- > Thx Gary, > > Comments in-line, > > > > > Hi Lucas > > > > The context is around the topic of HWKALERTS-49 - being able to replicate > > the > > RTGov 'situation' functionality using alerts. I think the main part missing > > at the moment is being able to associate the Alert with the business > > transaction information that caused it. > > > > I believe there are two scenarios that may occur, where business > > transaction > > data may result in an Alert: > > > > (1) metrics derived from the business transaction data are applied to the > > alert engine resulting in an alert - the persisted Alert will need to > > contain some link back to the business transaction. Metrics has their 'tag' > > name/value pair, which I believe could be used to store this info when the > > metric is created - so just need a way to carry that over into the alert. > > > > (2) other 'events' - so for example, if we identify some situation of > > interest (a service failure), we create an object representing that > > situation and send it to the alerts engine - again the originating business > > transaction id would need to be carried across via the intermediate > > 'service > > failure' object. > > > > Is it possible this could be handled by the work you are doing on > > HALERT-57? > > > > In HWKALERTS-57 we are improving the Action model to pass the Alert that was > linked and also the Alert should have information about the definition who > triggered it. > > So, having an action, you will have the alert and the definition data. > > If the business transaction info is "mapped" into the definition, the action > will have it. > > These requeriments were addressed by plugins but as we are still working on > it, we can join other requeriments in the same context to improve it. > > How do you plan to map the BTM info into the definition ? using Tags ? > > That can help me to add/modify some aspect of the present work. > > Thanks, > Lucas > > > > Regards > > Gary > > > > ----- Original Message ----- > > > Perhaps a rename to "Label" can be valid. > > > > > > Gary, is there some place where I can find more details about the context > > > ? > > > > > > (Just to understand the whole scenario and see if what can be > > > needed/interesting). > > > > > > Thanks, > > > Lucas > > > > > > ----- Original Message ----- > > > > From: "Gary Brown" > > > > To: "Discussions around Hawkular development" > > > > > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM > > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > +1 > > > > > > > > I don't mind if we adopt Tag as being name/value pair - but then we > > > > should > > > > use the same approach in Alerts. I actually need the Alert to have > > > > ability > > > > to record name/value pairs so this would suit my need, but they would > > > > then > > > > they would need to change their current Tag to be something else, > > > > possibly > > > > Label? > > > > > > > > Regards > > > > Gary > > > > > > > > ----- Original Message ----- > > > > > Not using the same terminology as "industry standards" is a problem, > > > > > not > > > > > using the same terminology within Hawkular small world is another... > > > > > Can we solve both ? > > > > > > > > > > Thomas > > > > > > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > > > > Hi, > > > > > > > > > > > > I don't agree with changing the terms. Many of metrics competing > > > > > > products > > > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is > > > > > > easier > > > > > > for customers to understand the differences and similarities > > > > > > between > > > > > > products. Using different terminology was one of the difficulties > > > > > > in > > > > > > RHQ > > > > > > (like noted in the F2F meeting) and I don't think we should repeat > > > > > > the > > > > > > same mistake. > > > > > > > > > > > > - Micke > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gary Brown" > > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > > > Hi > > > > > > > > > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > > > > > name/value pair for a tag, and alerts uses it as a label. Wondering > > > > > > whether we need consistency? > > > > > > > > > > > > When I hear the term tag, I usually envisage a label - e.g. as in > > > > > > git. > > > > > > So > > > > > > wondering whether it would be clearer for metrics to rename tags to > > > > > > properties? > > > > > > > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > > > > > > > Regards > > > > > > Gary > > > > > > _______________________________________________ > > > > > > hawkular-dev mailing list > > > > > > hawkular-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > > > > > hawkular-dev mailing list > > > > > > hawkular-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > hawkular-dev mailing list > > > > > hawkular-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Wed Jun 24 07:48:03 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 24 Jun 2015 07:48:03 -0400 (EDT) Subject: [Hawkular-dev] JSON: jackson and gson. Can we unify the libraries ? In-Reply-To: <2012510233.7063179.1435146165548.JavaMail.zimbra@redhat.com> Message-ID: <120551491.7067407.1435146483710.JavaMail.zimbra@redhat.com> Hello, As an implementation detail, we are using two libraries to serialize/deserialize with JSON. For REST endpoints we are using mainly jackson library as it's packaged with RESTEasy implementation. For BUS and other scenarios (like alert engine), we are using gson library. Does it make sense to unify them ? I have an scenario where I would like to use a class used as data in REST endpoints as payload of a BUS message, and I need to deal with some duplication on json serialization/deserialization tasks. Perhaps there are good reason to maintain both and that's the best answer but I'm not sure and I wanted to start a discussion around it. Thanks, Lucas From gbrown at redhat.com Wed Jun 24 07:51:18 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 07:51:18 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <20D51909-5E68-4CBB-A6AD-71EE8F761B32@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <20D51909-5E68-4CBB-A6AD-71EE8F761B32@redhat.com> Message-ID: <804504293.20059660.1435146678380.JavaMail.zimbra@redhat.com> Hi John Thanks for the clarification - that fits with how I need to use metrics. So for example, I may have btm_id=, and possibly service_type=, operation= - so assume they would all be ok? Regards Gary ----- Original Message ----- > Originally tags were implemented just as a label, not a key/value pair. I saw > that a number of other time series dbs use key/value pairs and decided to > make the change. It can also produce more efficient queries. For example, > filtering against N labels would require querying N partitions (in the > original schema). Querying against one tag name with N different values > however would only require querying 1 partition. > > > On Jun 24, 2015, at 6:25 AM, Michael Burman wrote: > > > > Hi, > > > > I don't agree with changing the terms. Many of metrics competing products > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier > > for customers to understand the differences and similarities between > > products. Using different terminology was one of the difficulties in RHQ > > (like noted in the F2F meeting) and I don't think we should repeat the > > same mistake. > > > > - Micke > > > > ----- Original Message ----- > > From: "Gary Brown" > > To: "Discussions around Hawkular development" > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > Hi > > > > Both metrics and alerts use the term 'tag' - however metrics use a > > name/value pair for a tag, and alerts uses it as a label. Wondering > > whether we need consistency? > > > > When I hear the term tag, I usually envisage a label - e.g. as in git. So > > wondering whether it would be clearer for metrics to rename tags to > > properties? > > > > Possibly metrics needs the concept of a tag/label as well? > > > > Regards > > Gary > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Wed Jun 24 07:53:55 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 24 Jun 2015 07:53:55 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> Message-ID: <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > Hi Lucas > > Not sure the alert or definition will be appropriate - assuming that the > definition is a static representation of the trigger? > > The information (business transaction id) I am referring to is per business > transaction instance - i.e. it is unique for each invocation of a business > transaction. So this can only be obtained from the information being > evaluated by the trigger. > > Let me know if I have misunderstand what you meant as definition. > No, I think you were right. Then the BT id is mapped into the data being processed by the engine. So, then I guess that BT id should be mapped just in the data that alerts use as input for processing. The Alert model stores this info by default. Each alert has a list of the evaluations (conditions definitions + specific data responsible of the trigger). Then perhaps I understand that you need to code the BT info into the incoming data, right ? > Regards > Gary > > ----- Original Message ----- > > Thx Gary, > > > > Comments in-line, > > > > > > > > Hi Lucas > > > > > > The context is around the topic of HWKALERTS-49 - being able to replicate > > > the > > > RTGov 'situation' functionality using alerts. I think the main part > > > missing > > > at the moment is being able to associate the Alert with the business > > > transaction information that caused it. > > > > > > I believe there are two scenarios that may occur, where business > > > transaction > > > data may result in an Alert: > > > > > > (1) metrics derived from the business transaction data are applied to the > > > alert engine resulting in an alert - the persisted Alert will need to > > > contain some link back to the business transaction. Metrics has their > > > 'tag' > > > name/value pair, which I believe could be used to store this info when > > > the > > > metric is created - so just need a way to carry that over into the alert. > > > > > > (2) other 'events' - so for example, if we identify some situation of > > > interest (a service failure), we create an object representing that > > > situation and send it to the alerts engine - again the originating > > > business > > > transaction id would need to be carried across via the intermediate > > > 'service > > > failure' object. > > > > > > Is it possible this could be handled by the work you are doing on > > > HALERT-57? > > > > > > > In HWKALERTS-57 we are improving the Action model to pass the Alert that > > was > > linked and also the Alert should have information about the definition who > > triggered it. > > > > So, having an action, you will have the alert and the definition data. > > > > If the business transaction info is "mapped" into the definition, the > > action > > will have it. > > > > These requeriments were addressed by plugins but as we are still working on > > it, we can join other requeriments in the same context to improve it. > > > > How do you plan to map the BTM info into the definition ? using Tags ? > > > > That can help me to add/modify some aspect of the present work. > > > > Thanks, > > Lucas > > > > > > > Regards > > > Gary > > > > > > ----- Original Message ----- > > > > Perhaps a rename to "Label" can be valid. > > > > > > > > Gary, is there some place where I can find more details about the > > > > context > > > > ? > > > > > > > > (Just to understand the whole scenario and see if what can be > > > > needed/interesting). > > > > > > > > Thanks, > > > > Lucas > > > > > > > > ----- Original Message ----- > > > > > From: "Gary Brown" > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM > > > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > +1 > > > > > > > > > > I don't mind if we adopt Tag as being name/value pair - but then we > > > > > should > > > > > use the same approach in Alerts. I actually need the Alert to have > > > > > ability > > > > > to record name/value pairs so this would suit my need, but they would > > > > > then > > > > > they would need to change their current Tag to be something else, > > > > > possibly > > > > > Label? > > > > > > > > > > Regards > > > > > Gary > > > > > > > > > > ----- Original Message ----- > > > > > > Not using the same terminology as "industry standards" is a > > > > > > problem, > > > > > > not > > > > > > using the same terminology within Hawkular small world is > > > > > > another... > > > > > > Can we solve both ? > > > > > > > > > > > > Thomas > > > > > > > > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I don't agree with changing the terms. Many of metrics competing > > > > > > > products > > > > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is > > > > > > > easier > > > > > > > for customers to understand the differences and similarities > > > > > > > between > > > > > > > products. Using different terminology was one of the difficulties > > > > > > > in > > > > > > > RHQ > > > > > > > (like noted in the F2F meeting) and I don't think we should > > > > > > > repeat > > > > > > > the > > > > > > > same mistake. > > > > > > > > > > > > > > - Micke > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Gary Brown" > > > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > Both metrics and alerts use the term 'tag' - however metrics use > > > > > > > a > > > > > > > name/value pair for a tag, and alerts uses it as a label. > > > > > > > Wondering > > > > > > > whether we need consistency? > > > > > > > > > > > > > > When I hear the term tag, I usually envisage a label - e.g. as in > > > > > > > git. > > > > > > > So > > > > > > > wondering whether it would be clearer for metrics to rename tags > > > > > > > to > > > > > > > properties? > > > > > > > > > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > > > > > > > > > Regards > > > > > > > Gary > > > > > > > _______________________________________________ > > > > > > > hawkular-dev mailing list > > > > > > > hawkular-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > > > > > > hawkular-dev mailing list > > > > > > > hawkular-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > hawkular-dev mailing list > > > > > > hawkular-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > _______________________________________________ > > > > > hawkular-dev mailing list > > > > > hawkular-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 24 07:59:18 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 24 Jun 2015 13:59:18 +0200 Subject: [Hawkular-dev] JSON: jackson and gson. Can we unify the libraries ? In-Reply-To: <120551491.7067407.1435146483710.JavaMail.zimbra@redhat.com> References: <2012510233.7063179.1435146165548.JavaMail.zimbra@redhat.com> <120551491.7067407.1435146483710.JavaMail.zimbra@redhat.com> Message-ID: <558A9B96.1010709@redhat.com> Minimum dependencies is definitely something that matters. (Security, productization...). Since jackson is already used and productized, there is definitely a strong advantage to use that one over gson. Thomas On 06/24/2015 01:48 PM, Lucas Ponce wrote: > Hello, > > As an implementation detail, we are using two libraries to serialize/deserialize with JSON. > > For REST endpoints we are using mainly jackson library as it's packaged with RESTEasy implementation. > > For BUS and other scenarios (like alert engine), we are using gson library. > > Does it make sense to unify them ? > > I have an scenario where I would like to use a class used as data in REST endpoints as payload of a BUS message, and I need to deal with some duplication on json serialization/deserialization tasks. > > Perhaps there are good reason to maintain both and that's the best answer but I'm not sure and I wanted to start a discussion around it. > > Thanks, > Lucas > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Wed Jun 24 08:41:18 2015 From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Wed, 24 Jun 2015 14:41:18 +0200 Subject: [Hawkular-dev] JSON: jackson and gson. Can we unify the libraries ? In-Reply-To: <558A9B96.1010709@redhat.com> References: <2012510233.7063179.1435146165548.JavaMail.zimbra@redhat.com> <120551491.7067407.1435146483710.JavaMail.zimbra@redhat.com> <558A9B96.1010709@redhat.com> Message-ID: <558AA56E.5000209@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/24/2015 01:59 PM, Thomas Heute wrote: > Minimum dependencies is definitely something that matters. > (Security, productization...). Since jackson is already used and > productized, there is definitely a strong advantage to use that one > over gson. Any reason not to use javax.json, which is shipped with Wildfly? - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJViqVuAAoJECKM1e+fkPrXclAH/RcrZWNucrzW6DGIYZEucNsx vrNxlX+mF7FWpXlJbhjzQCymqCM7ODY6tJcz5DLakIbaO9SUqgBeqjyYjZkZ9xVy j0gQLF8dAiBM7Xu9Z5pg67SlofxJMV/Z5FdTxxTZx8AUpY1a+k3W1BbPaN9mWb3I xQdykDRBmZzMIow89ErPUGl83wxXjLY0Tn9xWyv4/3pSmWAhvFhy4faqzRd8YnJB 1K5fPVYFYiVQc3eiSMCtCI14KBl1Ehl0YPGftBXzDyKjX0S8x2ov50pZtPl5GZOS no9zbpKhHaQnF+UjLr0Og9wZlqV6U0/n0EcggXMyjvrBp+VrtxyThvFW2K6iiHE= =KZhm -----END PGP SIGNATURE----- From tsegismo at redhat.com Wed Jun 24 08:43:14 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Wed, 24 Jun 2015 14:43:14 +0200 Subject: [Hawkular-dev] JSON: jackson and gson. Can we unify the libraries ? In-Reply-To: <558AA56E.5000209@redhat.com> References: <2012510233.7063179.1435146165548.JavaMail.zimbra@redhat.com> <120551491.7067407.1435146483710.JavaMail.zimbra@redhat.com> <558A9B96.1010709@redhat.com> <558AA56E.5000209@redhat.com> Message-ID: <558AA5E2.7080202@redhat.com> Le 24/06/2015 14:41, Juraci Paix?o Kr?hling a ?crit : > Any reason not to use javax.json, which is shipped with Wildfly? Does someone on earth use javax.json? :) Jackson is shipped with Wildfly as well From gbrown at redhat.com Wed Jun 24 08:51:49 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 08:51:49 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <558A8809.8090302@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> Message-ID: <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > Hi Lucas > > > > Not sure the alert or definition will be appropriate - assuming that the > > definition is a static representation of the trigger? > > > > The information (business transaction id) I am referring to is per business > > transaction instance - i.e. it is unique for each invocation of a business > > transaction. So this can only be obtained from the information being > > evaluated by the trigger. > > > > Let me know if I have misunderstand what you meant as definition. > > > > No, I think you were right. > > Then the BT id is mapped into the data being processed by the engine. > > So, then I guess that BT id should be mapped just in the data that alerts use > as input for processing. > > The Alert model stores this info by default. Each alert has a list of the > evaluations (conditions definitions + specific data responsible of the > trigger). > > Then perhaps I understand that you need to code the BT info into the incoming > data, right ? Yes that is correct. So just to check - if I include the BT id in the metric being supplied to the engine, then the 'tag' (name/value pairs) information for that metric will be carried into alert as part of the evaluation information? Regards Gary > > > Regards > > Gary > > > > ----- Original Message ----- > > > Thx Gary, > > > > > > Comments in-line, > > > > > > > > > > > Hi Lucas > > > > > > > > The context is around the topic of HWKALERTS-49 - being able to > > > > replicate > > > > the > > > > RTGov 'situation' functionality using alerts. I think the main part > > > > missing > > > > at the moment is being able to associate the Alert with the business > > > > transaction information that caused it. > > > > > > > > I believe there are two scenarios that may occur, where business > > > > transaction > > > > data may result in an Alert: > > > > > > > > (1) metrics derived from the business transaction data are applied to > > > > the > > > > alert engine resulting in an alert - the persisted Alert will need to > > > > contain some link back to the business transaction. Metrics has their > > > > 'tag' > > > > name/value pair, which I believe could be used to store this info when > > > > the > > > > metric is created - so just need a way to carry that over into the > > > > alert. > > > > > > > > (2) other 'events' - so for example, if we identify some situation of > > > > interest (a service failure), we create an object representing that > > > > situation and send it to the alerts engine - again the originating > > > > business > > > > transaction id would need to be carried across via the intermediate > > > > 'service > > > > failure' object. > > > > > > > > Is it possible this could be handled by the work you are doing on > > > > HALERT-57? > > > > > > > > > > In HWKALERTS-57 we are improving the Action model to pass the Alert that > > > was > > > linked and also the Alert should have information about the definition > > > who > > > triggered it. > > > > > > So, having an action, you will have the alert and the definition data. > > > > > > If the business transaction info is "mapped" into the definition, the > > > action > > > will have it. > > > > > > These requeriments were addressed by plugins but as we are still working > > > on > > > it, we can join other requeriments in the same context to improve it. > > > > > > How do you plan to map the BTM info into the definition ? using Tags ? > > > > > > That can help me to add/modify some aspect of the present work. > > > > > > Thanks, > > > Lucas > > > > > > > > > > Regards > > > > Gary > > > > > > > > ----- Original Message ----- > > > > > Perhaps a rename to "Label" can be valid. > > > > > > > > > > Gary, is there some place where I can find more details about the > > > > > context > > > > > ? > > > > > > > > > > (Just to understand the whole scenario and see if what can be > > > > > needed/interesting). > > > > > > > > > > Thanks, > > > > > Lucas > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gary Brown" > > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM > > > > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > > > +1 > > > > > > > > > > > > I don't mind if we adopt Tag as being name/value pair - but then we > > > > > > should > > > > > > use the same approach in Alerts. I actually need the Alert to have > > > > > > ability > > > > > > to record name/value pairs so this would suit my need, but they > > > > > > would > > > > > > then > > > > > > they would need to change their current Tag to be something else, > > > > > > possibly > > > > > > Label? > > > > > > > > > > > > Regards > > > > > > Gary > > > > > > > > > > > > ----- Original Message ----- > > > > > > > Not using the same terminology as "industry standards" is a > > > > > > > problem, > > > > > > > not > > > > > > > using the same terminology within Hawkular small world is > > > > > > > another... > > > > > > > Can we solve both ? > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I don't agree with changing the terms. Many of metrics > > > > > > > > competing > > > > > > > > products > > > > > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it > > > > > > > > is > > > > > > > > easier > > > > > > > > for customers to understand the differences and similarities > > > > > > > > between > > > > > > > > products. Using different terminology was one of the > > > > > > > > difficulties > > > > > > > > in > > > > > > > > RHQ > > > > > > > > (like noted in the F2F meeting) and I don't think we should > > > > > > > > repeat > > > > > > > > the > > > > > > > > same mistake. > > > > > > > > > > > > > > > > - Micke > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Gary Brown" > > > > > > > > To: "Discussions around Hawkular development" > > > > > > > > > > > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM > > > > > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > Both metrics and alerts use the term 'tag' - however metrics > > > > > > > > use > > > > > > > > a > > > > > > > > name/value pair for a tag, and alerts uses it as a label. > > > > > > > > Wondering > > > > > > > > whether we need consistency? > > > > > > > > > > > > > > > > When I hear the term tag, I usually envisage a label - e.g. as > > > > > > > > in > > > > > > > > git. > > > > > > > > So > > > > > > > > wondering whether it would be clearer for metrics to rename > > > > > > > > tags > > > > > > > > to > > > > > > > > properties? > > > > > > > > > > > > > > > > Possibly metrics needs the concept of a tag/label as well? > > > > > > > > > > > > > > > > Regards > > > > > > > > Gary > > > > > > > > _______________________________________________ > > > > > > > > hawkular-dev mailing list > > > > > > > > hawkular-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > _______________________________________________ > > > > > > > > hawkular-dev mailing list > > > > > > > > hawkular-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > hawkular-dev mailing list > > > > > > > hawkular-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > _______________________________________________ > > > > > > hawkular-dev mailing list > > > > > > hawkular-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > _______________________________________________ > > > > > hawkular-dev mailing list > > > > > hawkular-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > _______________________________________________ > > > > hawkular-dev mailing list > > > > hawkular-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Wed Jun 24 08:55:43 2015 From: jsanda at redhat.com (John Sanda) Date: Wed, 24 Jun 2015 08:55:43 -0400 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <804504293.20059660.1435146678380.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <489501412.30253594.1435141500469.JavaMail.zimbra@redhat.com> <20D51909-5E68-4CBB-A6AD-71EE8F761B32@redhat.com> <804504293.20059660.1435146678380.JavaMail.zimbra@redhat.com> Message-ID: <9022EDAA-8266-4F3B-BBE5-A08A79E96D9D@redhat.com> This is exactly what we have in mind as well as wild cards, e.g., btm_id=, service_type=, operation=* > On Jun 24, 2015, at 7:51 AM, Gary Brown wrote: > > Hi John > > Thanks for the clarification - that fits with how I need to use metrics. So for example, I may have btm_id=, and possibly service_type=, operation= - so assume they would all be ok? > > Regards > Gary > > ----- Original Message ----- >> Originally tags were implemented just as a label, not a key/value pair. I saw >> that a number of other time series dbs use key/value pairs and decided to >> make the change. It can also produce more efficient queries. For example, >> filtering against N labels would require querying N partitions (in the >> original schema). Querying against one tag name with N different values >> however would only require querying 1 partition. >> >>> On Jun 24, 2015, at 6:25 AM, Michael Burman wrote: >>> >>> Hi, >>> >>> I don't agree with changing the terms. Many of metrics competing products >>> (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier >>> for customers to understand the differences and similarities between >>> products. Using different terminology was one of the difficulties in RHQ >>> (like noted in the F2F meeting) and I don't think we should repeat the >>> same mistake. >>> >>> - Micke >>> >>> ----- Original Message ----- >>> From: "Gary Brown" >>> To: "Discussions around Hawkular development" >>> >>> Sent: Wednesday, June 24, 2015 11:45:56 AM >>> Subject: [Hawkular-dev] Tag concept in metrics and alerts >>> >>> Hi >>> >>> Both metrics and alerts use the term 'tag' - however metrics use a >>> name/value pair for a tag, and alerts uses it as a label. Wondering >>> whether we need consistency? >>> >>> When I hear the term tag, I usually envisage a label - e.g. as in git. So >>> wondering whether it would be clearer for metrics to rename tags to >>> properties? >>> >>> Possibly metrics needs the concept of a tag/label as well? >>> >>> Regards >>> Gary >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From lponce at redhat.com Wed Jun 24 09:05:12 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 24 Jun 2015 09:05:12 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <1565324956.20008109.1435142636491.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> Message-ID: <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> > > > > ----- Original Message ----- > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts > > > > > > Hi Lucas > > > > > > Not sure the alert or definition will be appropriate - assuming that the > > > definition is a static representation of the trigger? > > > > > > The information (business transaction id) I am referring to is per > > > business > > > transaction instance - i.e. it is unique for each invocation of a > > > business > > > transaction. So this can only be obtained from the information being > > > evaluated by the trigger. > > > > > > Let me know if I have misunderstand what you meant as definition. > > > > > > > No, I think you were right. > > > > Then the BT id is mapped into the data being processed by the engine. > > > > So, then I guess that BT id should be mapped just in the data that alerts > > use > > as input for processing. > > > > The Alert model stores this info by default. Each alert has a list of the > > evaluations (conditions definitions + specific data responsible of the > > trigger). > > > > Then perhaps I understand that you need to code the BT info into the > > incoming > > data, right ? > > Yes that is correct. > > So just to check - if I include the BT id in the metric being supplied to the > engine, then the 'tag' (name/value pairs) information for that metric will > be carried into alert as part of the evaluation information? > In alert context, the incoming data should match org.hawkular.alerts.api.model.data https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data These data is carried and stored in the evaluation details for an alert. But "Tag" in alerts is used as a way to put "alias" on definitions but is not related to specific incoming data. I have some questions, that may be can help us to refine your requeriment: - The incoming data you need is something like a pair of (BT id, value) = (bt1, 1000), (bt2, 1002) ... - ? Where you want to apply conditions matching for specific BT id ? - ? Or perhaps you have a more complex incoming data ? Can you ellaborate an example ? Thanks, Lucas > Regards > Gary > From gbrown at redhat.com Wed Jun 24 09:13:52 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 09:13:52 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> Message-ID: <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > >> > So just to check - if I include the BT id in the metric being supplied to > > the > > engine, then the 'tag' (name/value pairs) information for that metric will > > be carried into alert as part of the evaluation information? > > > > In alert context, the incoming data should match > org.hawkular.alerts.api.model.data > > https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data > > These data is carried and stored in the evaluation details for an alert. > > But "Tag" in alerts is used as a way to put "alias" on definitions but is not > related to specific incoming data. Sorry when I referred to 'tag', I meant the tag in the metrics event, which is a map of name/value pairs. So when the alerts engine is analysing a metric, is the tag information on the metric stored in the alert's condition evaluation data? > > I have some questions, that may be can help us to refine your requeriment: > > - The incoming data you need is something like a pair of (BT id, value) = > (bt1, 1000), (bt2, 1002) ... > > - ? Where you want to apply conditions matching for specific BT id ? No, the condition wouldn't refer to the BT id - the id is only included for future reference to enable apps to link back to the business transaction that caused the alert. > > - ? Or perhaps you have a more complex incoming data ? > > Can you ellaborate an example ? Sure - so the business transaction information may be used to derive a latency metric, describing the time delay between one service sending a message and the recipient receiving the message. The metric will include the BT id associated with the latency. The alerts engine will then apply a condition to determine whether the latency is greater than a permitted value, and if so create an alert. We then need to resulting Alert to directly or indirectly contain the BT id, so that when a user investigates the latency problem, they could navigate back to the business transaction that caused the problem to see if there is anything of interest. Now in reality this would not happen, as latency would probably be aggregated and only if the aggregate value hit a threshold would an alert be triggered - but it provides a potential example of the end to end flow of business txn data collection -> metrics -> alerts and then having the necessary info in the alert to trace back, Regards Gary > > Thanks, > Lucas From jshaughn at redhat.com Wed Jun 24 10:33:43 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Wed, 24 Jun 2015 10:33:43 -0400 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <187476451.7032580.1435143351852.JavaMail.zimbra@redhat.com> <371695460.20027520.1435144487214.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> Message-ID: <558ABFC7.1030601@redhat.com> On 6/24/2015 9:13 AM, Gary Brown wrote: > > ----- Original Message ----- >> In alert context, the incoming data should match >> org.hawkular.alerts.api.model.data >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data >> These data is carried and stored in the evaluation details for an >> alert. But "Tag" in alerts is used as a way to put "alias" on >> definitions but is not related to specific incoming data. > Sorry when I referred to 'tag', I meant the tag in the metrics event, which is a map of name/value pairs. > > So when the alerts engine is analysing a metric, is the tag information on the metric stored in the alert's condition evaluation data? As you mentioned earlier, Tags are labels that can be attached ad-hoc to Trigger definitions. They can then be used to filter queries, like, "give me all of the unresolved alerts for triggers labeled XYZ". That mechanism is for use by the clients, to be used in their own way. When a trigger fires an alert it does so based on one or more sets of true condition evaluations. One evaluation per condition on the trigger. One set of condition evaluations for each repetition of the conditions, based on dampening. By default, just one set of conditions because with default dampening a trigger fires as soon as the conditions match. Those evaluations are performed on data coming in. An alert stores with it all of the evaluations and makes that available to the actions (notifiers). In 0.2.0 it is only a toString of the information. But in 0.3.0 it will be a json representation. Every datum has a dataId and some sort of value information. This is likely where you would get your Tx Ids, and yes, it is captured and made available. So perhaps this is what you are looking for. > >> I have some questions, that may be can help us to refine your requeriment: >> >> - The incoming data you need is something like a pair of (BT id, value) = >> (bt1, 1000), (bt2, 1002) ... >> >> - ? Where you want to apply conditions matching for specific BT id ? > No, the condition wouldn't refer to the BT id - the id is only included for future reference to enable apps to link back to the business transaction that caused the alert. > >> - ? Or perhaps you have a more complex incoming data ? >> >> Can you ellaborate an example ? > Sure - so the business transaction information may be used to derive a latency metric, describing the time delay between one service sending a message and the recipient receiving the message. The metric will include the BT id associated with the latency. The alerts engine will then apply a condition to determine whether the latency is greater than a permitted value, and if so create an alert. > > We then need to resulting Alert to directly or indirectly contain the BT id, so that when a user investigates the latency problem, they could navigate back to the business transaction that caused the problem to see if there is anything of interest. > > Now in reality this would not happen, as latency would probably be aggregated and only if the aggregate value hit a threshold would an alert be triggered - but it provides a potential example of the end to end flow of business txn data collection -> metrics -> alerts and then having the necessary info in the alert to trace back, So the issue we may have here is that it seems you may want some supplemental contextual info on the data being sent in. If I understand the above, you would likely define a Threshold condition. The dataId (like a metricId, is known in advance, say "latencyMetric". The value is the Double, and would be the actual latency. But you also have runtimeInfo, the BTID, not known in advance, but something you want to store with the datum. Is that correct? So, perhaps an optional free-format string that could be supplied? I have another question, would it make any sense for the threshold matching to be performed completely outside of Alerts? Meaning, let BTM determine if there is a situation completely on its own, and then just hook into alerting for the use of trigger dampening, life cycle, action invocations, etc? This is basically the ExternalCondition hooks I'm currently working on. It allows an external system to basically do the condition evaluation, in any way it sees fit. The data sent to alerts is assumed to already describe a "true" evaluation. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From gbrown at redhat.com Wed Jun 24 10:54:59 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 24 Jun 2015 10:54:59 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <558ABFC7.1030601@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> <558ABFC7.1030601@redhat.com> Message-ID: <1992013980.20240277.1435157699650.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > On 6/24/2015 9:13 AM, Gary Brown wrote: > > > > ----- Original Message ----- > >> In alert context, the incoming data should match > >> org.hawkular.alerts.api.model.data > >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data > >> These data is carried and stored in the evaluation details for an > >> alert. But "Tag" in alerts is used as a way to put "alias" on > >> definitions but is not related to specific incoming data. > > Sorry when I referred to 'tag', I meant the tag in the metrics event, which > > is a map of name/value pairs. > > > > So when the alerts engine is analysing a metric, is the tag information on > > the metric stored in the alert's condition evaluation data? > > As you mentioned earlier, Tags are labels that can be attached ad-hoc to > Trigger definitions. They can then be used to filter queries, like, > "give me all of the unresolved alerts for triggers labeled XYZ". That > mechanism is for use by the clients, to be used in their own way. Yes, this is where the use of 'tag' in alerts and metrics differs, so might be good if Tag in Alerts could be renamed Label. > > When a trigger fires an alert it does so based on one or more sets of > true condition evaluations. One evaluation per condition on the > trigger. One set of condition evaluations for each repetition of the > conditions, based on dampening. By default, just one set of conditions > because with default dampening a trigger fires as soon as the conditions > match. Those evaluations are performed on data coming in. An alert > stores with it all of the evaluations and makes that available to the > actions (notifiers). In 0.2.0 it is only a toString of the > information. But in 0.3.0 it will be a json representation. > > Every datum has a dataId and some sort of value information. This is > likely where you would get your Tx Ids, and yes, it is captured and made > available. So perhaps this is what you are looking for. > Yes its possible - I need to try out the integration with metrics and alerts soon to make sure. > > > >> I have some questions, that may be can help us to refine your requeriment: > >> > >> - The incoming data you need is something like a pair of (BT id, value) = > >> (bt1, 1000), (bt2, 1002) ... > >> > >> - ? Where you want to apply conditions matching for specific BT id ? > > No, the condition wouldn't refer to the BT id - the id is only included for > > future reference to enable apps to link back to the business transaction > > that caused the alert. > > > >> - ? Or perhaps you have a more complex incoming data ? > >> > >> Can you ellaborate an example ? > > Sure - so the business transaction information may be used to derive a > > latency metric, describing the time delay between one service sending a > > message and the recipient receiving the message. The metric will include > > the BT id associated with the latency. The alerts engine will then apply a > > condition to determine whether the latency is greater than a permitted > > value, and if so create an alert. > > > > We then need to resulting Alert to directly or indirectly contain the BT > > id, so that when a user investigates the latency problem, they could > > navigate back to the business transaction that caused the problem to see > > if there is anything of interest. > > > > Now in reality this would not happen, as latency would probably be > > aggregated and only if the aggregate value hit a threshold would an alert > > be triggered - but it provides a potential example of the end to end flow > > of business txn data collection -> metrics -> alerts and then having the > > necessary info in the alert to trace back, > > So the issue we may have here is that it seems you may want some > supplemental contextual info on the data being sent in. If I understand > the above, you would likely define a Threshold condition. The dataId > (like a metricId, is known in advance, say "latencyMetric". The value > is the Double, and would be the actual latency. But you also have > runtimeInfo, the BTID, not known in advance, but something you want to > store with the datum. Is that correct? Yes that is correct. > > So, perhaps an optional free-format string that could be supplied? > May be better if it was a map. Then the information from the 'tags' on metrics, which are name/value pairs, could simply be copied over. > I have another question, would it make any sense for the threshold > matching to be performed completely outside of Alerts? Meaning, let BTM > determine if there is a situation completely on its own, and then just > hook into alerting for the use of trigger dampening, life cycle, action > invocations, etc? This is basically the ExternalCondition hooks I'm > currently working on. It allows an external system to basically do the > condition evaluation, in any way it sees fit. The data sent to alerts > is assumed to already describe a "true" evaluation. This sounds like it might be useful for evaluating events. Regards Gary > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Wed Jun 24 11:35:00 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 24 Jun 2015 17:35:00 +0200 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <1992013980.20240277.1435157699650.JavaMail.zimbra@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> <558ABFC7.1030601@redhat.com> <1992013980.20240277.1435157699650.JavaMail.zimbra@redhat.com> Message-ID: <558ACE24.2030605@redhat.com> On 06/24/2015 04:54 PM, Gary Brown wrote: > > > ----- Original Message ----- >> >> >> On 6/24/2015 9:13 AM, Gary Brown wrote: >>> >>> ----- Original Message ----- >>>> In alert context, the incoming data should match >>>> org.hawkular.alerts.api.model.data >>>> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data >>>> These data is carried and stored in the evaluation details for an >>>> alert. But "Tag" in alerts is used as a way to put "alias" on >>>> definitions but is not related to specific incoming data. >>> Sorry when I referred to 'tag', I meant the tag in the metrics event, which >>> is a map of name/value pairs. >>> >>> So when the alerts engine is analysing a metric, is the tag information on >>> the metric stored in the alert's condition evaluation data? >> >> As you mentioned earlier, Tags are labels that can be attached ad-hoc to >> Trigger definitions. They can then be used to filter queries, like, >> "give me all of the unresolved alerts for triggers labeled XYZ". That >> mechanism is for use by the clients, to be used in their own way. > > Yes, this is where the use of 'tag' in alerts and metrics differs, so might be good if Tag in Alerts could be renamed Label. Do we need 1 word labelling at all or key/value pairs only ? (BTW to make it more confusing OpenShift/Kubernetes use the term label for key=value things) Thomas > >> >> When a trigger fires an alert it does so based on one or more sets of >> true condition evaluations. One evaluation per condition on the >> trigger. One set of condition evaluations for each repetition of the >> conditions, based on dampening. By default, just one set of conditions >> because with default dampening a trigger fires as soon as the conditions >> match. Those evaluations are performed on data coming in. An alert >> stores with it all of the evaluations and makes that available to the >> actions (notifiers). In 0.2.0 it is only a toString of the >> information. But in 0.3.0 it will be a json representation. >> >> Every datum has a dataId and some sort of value information. This is >> likely where you would get your Tx Ids, and yes, it is captured and made >> available. So perhaps this is what you are looking for. >> > > Yes its possible - I need to try out the integration with metrics and alerts soon to make sure. > >>> >>>> I have some questions, that may be can help us to refine your requeriment: >>>> >>>> - The incoming data you need is something like a pair of (BT id, value) = >>>> (bt1, 1000), (bt2, 1002) ... >>>> >>>> - ? Where you want to apply conditions matching for specific BT id ? >>> No, the condition wouldn't refer to the BT id - the id is only included for >>> future reference to enable apps to link back to the business transaction >>> that caused the alert. >>> >>>> - ? Or perhaps you have a more complex incoming data ? >>>> >>>> Can you ellaborate an example ? >>> Sure - so the business transaction information may be used to derive a >>> latency metric, describing the time delay between one service sending a >>> message and the recipient receiving the message. The metric will include >>> the BT id associated with the latency. The alerts engine will then apply a >>> condition to determine whether the latency is greater than a permitted >>> value, and if so create an alert. >>> >>> We then need to resulting Alert to directly or indirectly contain the BT >>> id, so that when a user investigates the latency problem, they could >>> navigate back to the business transaction that caused the problem to see >>> if there is anything of interest. >>> >>> Now in reality this would not happen, as latency would probably be >>> aggregated and only if the aggregate value hit a threshold would an alert >>> be triggered - but it provides a potential example of the end to end flow >>> of business txn data collection -> metrics -> alerts and then having the >>> necessary info in the alert to trace back, >> >> So the issue we may have here is that it seems you may want some >> supplemental contextual info on the data being sent in. If I understand >> the above, you would likely define a Threshold condition. The dataId >> (like a metricId, is known in advance, say "latencyMetric". The value >> is the Double, and would be the actual latency. But you also have >> runtimeInfo, the BTID, not known in advance, but something you want to >> store with the datum. Is that correct? > > Yes that is correct. > >> >> So, perhaps an optional free-format string that could be supplied? >> > > May be better if it was a map. Then the information from the 'tags' on metrics, which are name/value pairs, could simply be copied over. > >> I have another question, would it make any sense for the threshold >> matching to be performed completely outside of Alerts? Meaning, let BTM >> determine if there is a situation completely on its own, and then just >> hook into alerting for the use of trigger dampening, life cycle, action >> invocations, etc? This is basically the ExternalCondition hooks I'm >> currently working on. It allows an external system to basically do the >> condition evaluation, in any way it sees fit. The data sent to alerts >> is assumed to already describe a "true" evaluation. > > This sounds like it might be useful for evaluating events. > > Regards > Gary > >> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Wed Jun 24 14:21:10 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Wed, 24 Jun 2015 14:21:10 -0400 Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <558ACE24.2030605@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <1050173330.7046882.1435145238798.JavaMail.zimbra@redhat.com> <791324930.20052006.1435146435100.JavaMail.zimbra@redhat.com> <939816078.7076114.1435146835893.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> <558ABFC7.1030601@redhat.com> <1992013980.20240277.1435157699650.JavaMail.zimbra@redhat.com> <558ACE24.2030605@redhat.com> Message-ID: <558AF516.8000006@redhat.com> On 6/24/2015 11:35 AM, Thomas Heute wrote: > > On 06/24/2015 04:54 PM, Gary Brown wrote: >> >> ----- Original Message ----- >>> >>> On 6/24/2015 9:13 AM, Gary Brown wrote: >>>> ----- Original Message ----- >>>>> In alert context, the incoming data should match >>>>> org.hawkular.alerts.api.model.data >>>>> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data >>>>> These data is carried and stored in the evaluation details for an >>>>> alert. But "Tag" in alerts is used as a way to put "alias" on >>>>> definitions but is not related to specific incoming data. >>>> Sorry when I referred to 'tag', I meant the tag in the metrics event, which >>>> is a map of name/value pairs. >>>> >>>> So when the alerts engine is analysing a metric, is the tag information on >>>> the metric stored in the alert's condition evaluation data? >>> As you mentioned earlier, Tags are labels that can be attached ad-hoc to >>> Trigger definitions. They can then be used to filter queries, like, >>> "give me all of the unresolved alerts for triggers labeled XYZ". That >>> mechanism is for use by the clients, to be used in their own way. >> Yes, this is where the use of 'tag' in alerts and metrics differs, so might be good if Tag in Alerts could be renamed Label. > Do we need 1 word labelling at all or key/value pairs only ? > > (BTW to make it more confusing OpenShift/Kubernetes use the term label > for key=value things) > > Thomas I don't really want to rename Tag to Label unless it's really confusing people. Or until we have complete concensus over the terminology and semantics. As it stands, ALerts' tags are not 1 word labels, but actually allow for qualifying 'category', as well as the 'name'. From gbrown at redhat.com Thu Jun 25 03:16:43 2015 From: gbrown at redhat.com (Gary Brown) Date: Thu, 25 Jun 2015 03:16:43 -0400 (EDT) Subject: [Hawkular-dev] Tag concept in metrics and alerts In-Reply-To: <558AF516.8000006@redhat.com> References: <863672756.19909838.1435135556568.JavaMail.zimbra@redhat.com> <491844968.20119255.1435150309612.JavaMail.zimbra@redhat.com> <642391581.7109252.1435151112241.JavaMail.zimbra@redhat.com> <1157720139.20149774.1435151632354.JavaMail.zimbra@redhat.com> <558ABFC7.1030601@redhat.com> <1992013980.20240277.1435157699650.JavaMail.zimbra@redhat.com> <558ACE24.2030605@redhat.com> <558AF516.8000006@redhat.com> Message-ID: <1631126678.20558664.1435216603565.JavaMail.zimbra@redhat.com> Hi Jay Thats fine, better to get consensus, as we don't want to have to rename again in the future :) Another alternative that I'd like to suggest, based on your mention of the optional category, is to actually use Category, as it seems like that is how it is used (i.e. to categorize alerts) ? Regards Gary ----- Original Message ----- > > > On 6/24/2015 11:35 AM, Thomas Heute wrote: > > > > On 06/24/2015 04:54 PM, Gary Brown wrote: > >> > >> ----- Original Message ----- > >>> > >>> On 6/24/2015 9:13 AM, Gary Brown wrote: > >>>> ----- Original Message ----- > >>>>> In alert context, the incoming data should match > >>>>> org.hawkular.alerts.api.model.data > >>>>> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data > >>>>> These data is carried and stored in the evaluation details for an > >>>>> alert. But "Tag" in alerts is used as a way to put "alias" on > >>>>> definitions but is not related to specific incoming data. > >>>> Sorry when I referred to 'tag', I meant the tag in the metrics event, > >>>> which > >>>> is a map of name/value pairs. > >>>> > >>>> So when the alerts engine is analysing a metric, is the tag information > >>>> on > >>>> the metric stored in the alert's condition evaluation data? > >>> As you mentioned earlier, Tags are labels that can be attached ad-hoc to > >>> Trigger definitions. They can then be used to filter queries, like, > >>> "give me all of the unresolved alerts for triggers labeled XYZ". That > >>> mechanism is for use by the clients, to be used in their own way. > >> Yes, this is where the use of 'tag' in alerts and metrics differs, so > >> might be good if Tag in Alerts could be renamed Label. > > Do we need 1 word labelling at all or key/value pairs only ? > > > > (BTW to make it more confusing OpenShift/Kubernetes use the term label > > for key=value things) > > > > Thomas > > I don't really want to rename Tag to Label unless it's really confusing > people. Or until we have complete concensus over the terminology and > semantics. As it stands, ALerts' tags are not 1 word labels, but > actually allow for qualifying 'category', as well as the 'name'. > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From theute at redhat.com Thu Jun 25 03:37:14 2015 From: theute at redhat.com (Thomas Heute) Date: Thu, 25 Jun 2015 09:37:14 +0200 Subject: [Hawkular-dev] Docker files Message-ID: <558BAFAA.9040605@redhat.com> Is that one still used by something/someone ? https://github.com/hawkular/hawkular/blob/master/dist/docker/Dockerfile Thomas From hrupp at redhat.com Thu Jun 25 03:46:29 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 25 Jun 2015 09:46:29 +0200 Subject: [Hawkular-dev] Docker files In-Reply-To: <558BAFAA.9040605@redhat.com> References: <558BAFAA.9040605@redhat.com> Message-ID: On 25 Jun 2015, at 9:37, Thomas Heute wrote: > Is that one still used by something/someone ? > > https://github.com/hawkular/hawkular/blob/master/dist/docker/Dockerfile Yes. It is "only" not auto-built at the momen. Viet, Matt and I are looking into getting this up again (in a different way). I am also using it locally From hrupp at redhat.com Thu Jun 25 05:03:09 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 25 Jun 2015 11:03:09 +0200 Subject: [Hawkular-dev] new hawkular build In-Reply-To: <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> References: <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> Message-ID: <5D54C48D-989E-4123-9F81-9336D2FBBF01@redhat.com> On 23 Jun 2015, at 2:27, John Mazzitelli wrote: > So we are close to getting a full integration build that runs on WF9. Indeed - if only WF9.Final would be available :-) More seriously: hawkular-next branch reached a state late yesterday, that is "good enough". I have let that run over the night without larger fallout [1] so that Peter has pr'd and merged it to master this morning. Thanks to everyone involved in that large effort. Heiko [1] Currently it seems like the wf-agent is not delivering metrics to the server. From vnguyen at redhat.com Thu Jun 25 15:49:24 2015 From: vnguyen at redhat.com (Viet Nguyen) Date: Thu, 25 Jun 2015 15:49:24 -0400 (EDT) Subject: [Hawkular-dev] Automated Docker build is working again In-Reply-To: <5D54C48D-989E-4123-9F81-9336D2FBBF01@redhat.com> References: <2052466826.6235008.1435019261502.JavaMail.zimbra@redhat.com> <5D54C48D-989E-4123-9F81-9336D2FBBF01@redhat.com> Message-ID: <771099545.21837412.1435261764445.JavaMail.zimbra@redhat.com> Matt M. and I successfully switched the build from Docker Hub to our own Jenkins build slave. The chain is as follows hawkular/hawkular builds in Travis-ci (10-16 minutes) -> Docker image builds in our Jenkins -> image is pushed to Docker Hub (8 minutes) -> hawkular is deployed to livingontheedge.hawkular.org (3-5 minutes) Viet From brmeyer at redhat.com Fri Jun 26 12:45:36 2015 From: brmeyer at redhat.com (Brett Meyer) Date: Fri, 26 Jun 2015 12:45:36 -0400 (EDT) Subject: [Hawkular-dev] one more round of beta testing Message-ID: <1074565404.26827712.1435337136060.JavaMail.zimbra@redhat.com> If any of you would be willing to smoke test Artificer one more time, I'd sincerely appreciate it. 1.0.0.Beta2 will hopefully be the last beta release and Final should go out late next week. Thanks! https://developer.jboss.org/en/artificer/blog/2015/06/26/artificer-100beta2-released From artur.dryomov at gmail.com Sun Jun 28 08:20:25 2015 From: artur.dryomov at gmail.com (Artur Dryomov) Date: Sun, 28 Jun 2015 15:20:25 +0300 Subject: [Hawkular-dev] [GSoC] Hawkular Android Client: Weekly Report #5 Message-ID: Hi everyone, This year I am working on the Hawkular Android application as part of the Google Summer of Code 2015 program. I?ve spent the last week mostly on combining things together and little polishing. The authorization screen was tweaked a bit to include better information about requirements to run the application. The navigation drawer is fully working at this point. I?ve prepared a PR with proper state saving between orientation changes, helpful error and empty layouts and more [1]. At this point I finally can say that the application is kind of usable. Well, more or less. You can take a look at screenshots yourself [2]. I have several things in plans to work on, including fixing some authorization issues (the server side suddenly decides to return Not Authorized sometimes, I suspect it is related to OAuth token expiration), adding some abilities such as logging out, sorting and ranging alerts and metric data. I?m open to other suggestions, feel free to contact me or just file an issue! Have a nice week! Artur. [1]: https://github.com/hawkular/hawkular-android-client/pull/25 [2]: https://github.com/hawkular/hawkular-android-client/wiki/Design -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150628/d2a444cb/attachment.html From hrupp at redhat.com Mon Jun 29 07:45:32 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 29 Jun 2015 13:45:32 +0200 Subject: [Hawkular-dev] Resourcetype again In-Reply-To: <12258003.x1941inYKH@localhost.localdomain> References: <6859E673-FB75-4957-BE7F-6966ED5203DA@redhat.com> <12258003.x1941inYKH@localhost.localdomain> Message-ID: Hey, >> I believe that for a certain kind of resource - e.g. "WildFly 8.2", >> that >> "we" manage >> we should not have the agent/feed supply the types, but Hawkular >> should >> do so. > > This can be the first capability that the agents can declare. Even Which "this"? :) > nothing prevents anyone with enough permissions to create the resource > types a > priori in the inventory. A glue component could listen on the bus and > if it > sees a new tenant created, it can add the to-be-predefined resource > and metric > types. I would even go further and have that base WF8 type or whatever be defined for the whole Hawkular system and not per tenant. I.e. keeping that definition only once in the system. If that is not possible, we can certainly have that listener install it in each new tenant. > We already have a crude "proof-of-concept" of this way of doing things > with > our "TemporaryHacks" class that adds the resource types needed for Yes. In fact for more complex scenarios we not only need inventory be populated "server side", but the feeds (hawkular-monitor) also need to be able to consume this. > There is a question whether the glue component should be written in > the same > way as TemporaryHacks - using low level API and circumventing any auth > or if Yes. I think so. > hawkular components or maybe by just really requiring every component > having > controlled access. I am for the latter even if it means more work > because it > will provide the users with the ability to lock down the perms of > individual > components which is good to minimize the impact in case of security > breach in > one of the distributed components. There is certainly a point in this. Could we actually just shut down a certain api inside inventory (for a certain caller)? >> >> For security relevant things we can not let the client/feed just >> provide >> resource >> type data, as otherwise it is too easy to work around checks. >> > > This could be another agent capability - to support SSO - the auth > token would > flow all the way down from the browser to the agent which would > execute the > operation as the user on the managed resource. Not sure how feasible > this is > but it sounds nice ;) Again: two things. We must not allow a malicious feed (i.e. one where an attacker has modified resource type definitions to say "every one can execute") to be uploaded in the server and then prevent any RBAC checks inside the server. The other part which you mention is certainly SSO and "run as" for operations in the agent, which will allow WF to do its own security checking instead of relying that Hawkular has everything correctly set up. >> While it is possible for WildFly to obtain the security levels >> (automatically) >> from the WildFly Metadata, we still need to find a good way to add >> this >> information >> into our resource types, as the UI may need to react to them and not >> show a >> restart button for user that only has the Monitoring role. > > If these constraints are configurable then I think resource type is > not the > right place to have them. IMHO they would better fit into the > resources > themselves. Right, if you see the combination of as a runtime property of such a resource. Certainly makes sense, but also makes things more complicated and bloated. That is probably the price for not running inside the target server (like the WF-console). From hrupp at redhat.com Mon Jun 29 07:46:41 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 29 Jun 2015 13:46:41 +0200 Subject: [Hawkular-dev] Prototype of operations execution on the feed Message-ID: <8081F870-0E18-482B-B9F4-DD9B0965F2F2@redhat.com> Hey, I have prototyped the execution of operations on the feed (WF-server for now). Note, that this is not any way of final implementation, but merely a proof of concept to get this started with the possibility to discuss some less abstract situation/code. Also for the "action on all selected items" - that is currently not taking the selected items only. This works by having a new endpoint on the server http://localhost:8080/hawkular/opsq where a post to it submits one or more jobs onto the server. A get to opsq/{feedid} then pulls one job for that feed. The wf-agent now has a new runnable 'OpsGroupRunnable' that once per minute polls that above endpoint and executes jobs that are available. I think that for a real implementation we should consider upgrading the server-feed communication from many http/1.1 requests to a websocket connection, that is then multiplexed on the server and when something is added to the queue of jobs, it directly gets pushed instead of the agent polling for it. Also the result of the operation needs to be delivered back to the server and ui; we need to add some unique operation id, to be able to correlate request and result. This also brings back the resource type discussion (see other email), as e.g. a .war file does not support a :delete action. This needs e.g. to be broken out into a :undeploy and then remove-from-vf-content-repo action. Or there are no :enable/:disable actions. They may need to be translated into deploy/undeploy. Or greyed out in the UI. The implementation spans multiple repositories - I do not intend to send pull-requests, as this is only a prototype / proof of concept. Hawkular-Monitor: https://github.com/pilhuhn/hawkular-agent/tree/ops-get UI-Services: https://github.com/pilhuhn/hawkular-ui-services/tree/ops-get Hawkular: - QueueHandling https://github.com/pilhuhn/hawkular/tree/ops-get/modules/ops-queue - UI https://github.com/pilhuhn/hawkular/tree/ops-get/ui/console/src/main/scripts From ppalaga at redhat.com Mon Jun 29 12:59:43 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Mon, 29 Jun 2015 18:59:43 +0200 Subject: [Hawkular-dev] Integration of Inventory 0.1.0.Alpha3 Message-ID: <5591797F.8040809@redhat.com> Hi *, we have a couple of small changes in Inventory [1][2][3], that we'd like to release as Inventory 0.1.0.Alpha3 +-tomorrow 2015-06-30. I have started integration branches in Hawkular [4] and Agent [5]. Is it OK to have Inventory 0.1.0.Alpha3 in this form for Hawkular M2? Esp, note that HWKINVENT-10 Support resource hiearchy in the API will not be there in Inventory 0.1.0.Alpha3. -- P [1] Changes merged already: https://github.com/hawkular/hawkular-inventory/commits/master [2] One PR waiting: https://github.com/hawkular/hawkular-inventory/pull/101 [3] Titan backend https://issues.jboss.org/browse/HWKINVENT-22 [4] https://github.com/hawkular/hawkular/tree/dev/inventory-0.1.0.Alpha3, https://github.com/hawkular/hawkular/pull/273 [5] https://github.com/hawkular/hawkular-agent/tree/dev/inventory-0.1.0.Alpha3, https://github.com/hawkular/hawkular-agent/pull/13 From mwringe at redhat.com Mon Jun 29 16:53:34 2015 From: mwringe at redhat.com (Matt Wringe) Date: Mon, 29 Jun 2015 16:53:34 -0400 Subject: [Hawkular-dev] Hawkular Metrics Containers Changes Message-ID: <5591B04E.9020307@redhat.com> Just a heads up that I will need to delete the existing docker hub 'hawkular/hawkular-metrics' and 'hawkular/hawkular-cassandra' repositories. This is so we can convert the 'automated build' repository to a normal one (we cannot convert one to another, it has to be deleted first). This will finally allow us to build the docker images ourselves and push them out after the tests have passed. I will probably make this change tomorrow if there are no objections. Thanks, Matt Wringe From theute at redhat.com Tue Jun 30 07:41:06 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 30 Jun 2015 13:41:06 +0200 Subject: [Hawkular-dev] Integration of Inventory 0.1.0.Alpha3 In-Reply-To: <5591797F.8040809@redhat.com> References: <5591797F.8040809@redhat.com> Message-ID: <55928052.7040303@redhat.com> Do we need it ? and that would require new version of Inventory and Agent, do we need them for MS2 ? The currrent master is very unstable at the moment, let's make sure to not add more instability. If tested carefully and if we need new releases of the components anyway, I wouldn't object. Thomas On 06/29/2015 06:59 PM, Peter Palaga wrote: > Hi *, > > we have a couple of small changes in Inventory [1][2][3], that we'd like > to release as Inventory 0.1.0.Alpha3 +-tomorrow 2015-06-30. > > I have started integration branches in Hawkular [4] and Agent [5]. > > Is it OK to have Inventory 0.1.0.Alpha3 in this form for Hawkular M2? > > Esp, note that HWKINVENT-10 Support resource hiearchy in the API will > not be there in Inventory 0.1.0.Alpha3. > > -- P > > [1] Changes merged already: > https://github.com/hawkular/hawkular-inventory/commits/master > [2] One PR waiting: https://github.com/hawkular/hawkular-inventory/pull/101 > [3] Titan backend https://issues.jboss.org/browse/HWKINVENT-22 > > [4] > https://github.com/hawkular/hawkular/tree/dev/inventory-0.1.0.Alpha3, > https://github.com/hawkular/hawkular/pull/273 > > [5] > https://github.com/hawkular/hawkular-agent/tree/dev/inventory-0.1.0.Alpha3, > https://github.com/hawkular/hawkular-agent/pull/13 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Tue Jun 30 08:41:11 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 30 Jun 2015 14:41:11 +0200 Subject: [Hawkular-dev] Integration of Inventory 0.1.0.Alpha3 In-Reply-To: <5591797F.8040809@redhat.com> References: <5591797F.8040809@redhat.com> Message-ID: On 29 Jun 2015, at 18:59, Peter Palaga wrote: > Hi *, > > we have a couple of small changes in Inventory [1][2][3], that we'd Will it fix 14:40:04,886 ERROR [org.hawkular.agent.monitor] (Controller Boot Thread) HAWKMONITOR010024: Failed to store inventory data: java.lang.Exception: status-code=[404], reason=[Not Found], url=[http://snert:8080/hawkular/inventory/resourceTypes] at org.hawkular.agent.monitor.storage.HawkularStorageAdapter.registerResourceType(HawkularStorageAdapter.java:367) at org.hawkular.agent.monitor.storage.HawkularStorageAdapter.storeResourceType(HawkularStorageAdapter.java:231) 14:40:04,887 ERROR [org.hawkular.agent.monitor.service.MonitorService] (Controller Boot Thread) Failed to completely add our inventory - but we will keep going with partial inventory: java.lang.RuntimeException: Cannot create resource type: DMRResourceType[id=WildFly Server][props={name=WildFly Server, resourceConfiguration=[{name=Hostname}, {name=Max Heap}, {name=Version}]}] on server/agent restart? From lkrejci at redhat.com Tue Jun 30 10:17:09 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 30 Jun 2015 16:17:09 +0200 Subject: [Hawkular-dev] Integration of Inventory 0.1.0.Alpha3 In-Reply-To: References: <5591797F.8040809@redhat.com> Message-ID: <13959644.yCgFM5DE3m@localhost.localdomain> Removal of resource type version will not get rid of the below mentioned problem. But the fix for that would be part of the next inventory release - as HWKINVENT-54 has been fixed post 0.1.0.Alpha2. The removal of the version on resource type goes hand in hand with the filtering support we're adding for UI consumption - we'd need a release for that anyway. While the removal of resource type version will require another agent release, UI will benefit from it (otherwise filtering will not work) so I am personally in favor of letting this in. Note that I will be leaving out the change to run Inventory on Titan, even though it is ready including the configuration using env vars (barring changes from PR). This is quite a big change and so we will not introduce it just before the release. Also we unfortunately have to leave out resource hierarchy, because the "collateral" changes required for that to function "sanely" were so big that it still doesn't pass integration tests (actually, it's just one test failing, but one never knows what changes will be required to fix it ;) ). So to recap, these are the changes to go into 0.1.0.Final since 0.1.0.Alpha2: https://issues.jboss.org/browse/HWKINVENT-54 - 404 vs. 409 - needed by agent https://issues.jboss.org/browse/HWKINVENT-60 - filtering for the UI https://issues.jboss.org/browse/HWKINVENT-68 - non-functional - just itests https://issues.jboss.org/browse/HWKINVENT-78 - remove version from res. type On Tuesday, June 30, 2015 14:41:11 Heiko W.Rupp wrote: > On 29 Jun 2015, at 18:59, Peter Palaga wrote: > > Hi *, > > > > we have a couple of small changes in Inventory [1][2][3], that we'd > > Will it fix > > 14:40:04,886 ERROR [org.hawkular.agent.monitor] (Controller Boot Thread) > HAWKMONITOR010024: Failed to store inventory data: java.lang.Exception: > status-code=[404], reason=[Not Found], > url=[http://snert:8080/hawkular/inventory/resourceTypes] > at > org.hawkular.agent.monitor.storage.HawkularStorageAdapter.registerResourceTy > pe(HawkularStorageAdapter.java:367) at > org.hawkular.agent.monitor.storage.HawkularStorageAdapter.storeResourceType( > HawkularStorageAdapter.java:231) > > 14:40:04,887 ERROR [org.hawkular.agent.monitor.service.MonitorService] > (Controller Boot Thread) Failed to completely add our inventory - but we > will keep going with partial inventory: java.lang.RuntimeException: > Cannot create resource type: DMRResourceType[id=WildFly > Server][props={name=WildFly Server, > resourceConfiguration=[{name=Hostname}, {name=Max Heap}, > {name=Version}]}] > > on server/agent restart? > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From gcardoso at redhat.com Tue Jun 30 10:34:55 2015 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 30 Jun 2015 16:34:55 +0200 Subject: [Hawkular-dev] Apps list search Message-ID: <16F1F8C9-1F63-42AF-88A8-3B683267FAB8@redhat.com> Hello, I was assigned to design the search/filter component for the applications list and would like to bring some questions. I already got some requirements from Liz/Thomas. My proposal would be to present a behaviour similar to what JIRA does. They have ?dropdown? selectors to allow filtering + a search box (initially). For our context, the dropdowns would be to filter State (Up, Down etc.) and Type (EAP, Wildfly etc.). We probably don?t need the find input in the beginning, when we have not many options. Thomas brought this comment: > The input text should still be editable to do more filtering such as: > "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com ' " (To show all servers on *.corp.redhat.com that are down or unknown) JIRA also covers that, when clicking on Advanced, the dropdowns are hidden and everything goes inside the search input: I like this approach because we offer something user-friendly and at the same time provide something more powerful for advanced users. I would like to hear your feedback. @Inventory team, from what was presented, it is feasible to be implemented? Thanks, Gabriel Gabriel Cardoso UX designer @ Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150630/cc47b3dd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-06-30 at 3.21.08 PM.png Type: image/png Size: 232809 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150630/cc47b3dd/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-06-30 at 3.21.22 PM.png Type: image/png Size: 28038 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150630/cc47b3dd/attachment-0003.png From lponce at redhat.com Tue Jun 30 11:11:05 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 30 Jun 2015 11:11:05 -0400 (EDT) Subject: [Hawkular-dev] =?utf-8?q?=5BApache_Cassandra=5D_Fwd=3A_Partner_Ne?= =?utf-8?q?wsletter_=E2=80=93_Global_Payment_Technology_Company_Chooses_Az?= =?utf-8?q?ul_and_Feedzai?= In-Reply-To: <346880265.499283713.1435676579314.JavaMail.root@sjmas02.marketo.org> References: <346880265.499283713.1435676579314.JavaMail.root@sjmas02.marketo.org> Message-ID: <182413265.10655980.1435677065388.JavaMail.zimbra@redhat.com> Interesting related a big cassandra installation. ----- Forwarded Message ----- > From: "Azul Alliance Partner Program" > To: lponce at redhat.com > Sent: Tuesday, June 30, 2015 5:02:59 PM > Subject: Partner Newsletter ? Global Payment Technology Company Chooses Azul and Feedzai > > Subscribe: > http://info.azulsystems.com/SubscriptionCenter_Subscribe_partner_newsletter.html > > > June, 2015 Alliance Partner Newsletter > > > Feedzai and Azul Deploy Real-Time Fraud Detection Solution at Global Leader > in Payment Technology > > Azul and Feedzai collaborated to implement a real-time Apache > Cassandra?-based fraud detection use case for a major financial services > account. By deploying on Zing, which is fully certified with Feedzai, the > company is able to ensure the system can consistently meet response time > requirements in the 10s of milliseconds. > > Read more: > http://www.azulsystems.com/press-2015/feedzai-and-azul-systems-deploy-real-time-fraud-detection-solution-at-global-leader-in-payment-technology > > > Top News and Resources > > ? M2M Now: Why has Azul Systems launched Zulu Embedded? > Read More: > http://www.m2mnow.biz/2015/06/15/34001-why-has-azul-systems-launched-zulu-embedded/ > > ? Application Development Trends: Oracle Considers G1 Garbage Collector for > Java 9. Read More: https://adtmag.com/articles/2015/06/22/oracle-java-9.aspx > > ? Application Development Trends: Oracle Pushes Java EE 8 Release Date. > Read More: https://adtmag.com/articles/2015/06/08/java-ee-8-release-date.aspx > > ? InfoQ: Oracle Proposes G1 as the Default Garbage Collector for Java 9. > Read More: http://www.infoq.com/news/2015/06/Oracle-Proposes-G1-Default-GC > > ? BetterJava Blog: So, G1 may become the default collector for Java 9? > Read More: > https://betterjava.wordpress.com/2015/06/18/so-g1-may-become-the-default-collector-for-java-9/ > > ? InfoWorld: Java at 20: The JVM, Java's other big legacy. > Read More: > http://www.infoworld.com/article/2923035/java/java-at-20-jvm-javas-other-big-legacy.html > > > Upcoming Events > > OSCON > July 20 - 23 > Meet the Azul Systems team in booth #319 to discover open source Java > options. > More detail: http://www.azulsystems.com/content/oscon-2015-0 > > Embedded Systems Conference Silicon Valley > July 20 - 22 > Meet the Azul Systems team in booth #40 for scalable, fully customizable open > source Java for embedded systems and the IoT. > More detail: > http://www.azulsystems.com/content/embedded-systems-conference-santa-clara-2015 > > ?berConf Denver > July 21 - 24 > Azul VM Engineer Douglas Hawkins will be presenting four sessions on Java > topics. > More detail: http://www.azulsystems.com/content/%C3%BCberconf-denver-2015 > > > Azul Systems is the award-winning provider of Java for the enterprise. The > company has over 10 years' experience and deep domain knowledge in Java > runtimes, low-latency applications, elastic memory, Pauseless Java Garbage > Collection and runtime resource monitoring. Azul is also a member of the > Executive Committee of the Java Community Process (JCP) and a Silver Member > of the Cloud Foundry Foundation. www.azulsystems.com > > > ?Copyright 2015, Azul Systems, Inc. | 1173 Borregas Ave | Sunnyvale CA 94089 > | Phone : 650-230-6500 > > To ensure delivery of messages from Azul Systems please add > azul at azulsystems.com to your address book. If you no longer wish to receive > these emails, go to the following link to unsubscribe: > http://www.azulsystems.com/teal-azul/about_us/email_subscription?mkt_unsubscribe=1&mkt_tok=3RkMMJWWfF9wsRonuqjIde%2FhmjTEU5z16uktWqe3gIkz2EFye%2BLIHETpodcMTcJgPLnYDBceEJhqyQJxPr3FJdAN1d52RhfnAQ%3D%3D > From lkrejci at redhat.com Tue Jun 30 11:27:16 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 30 Jun 2015 17:27:16 +0200 Subject: [Hawkular-dev] Inventory 0.1.0.Final released Message-ID: <5810088.fcShA1NTaj@localhost.localdomain> Hi all, Inventory 0.1.0.Final has just been released. A couple of new features and enhancements have been made since 0.0.9, which you can read about here: https://issues.jboss.org/browse/HWKINVENT/fixforversion/12327452 Some of the notable changes: * REST API solidified and made more regular - associating metric types to resource types is done similarly to how metrics are associated to resources, etc. * Tenant ID no longer part of the URL - it is implied from the login credentials and current persona. * Basic filtering support for resources (above of what was available in an ad- hoc manner before) * REST API now can work with generic, free-form, relationships * Resource types no longer have mandatory version - this is going to come back at later releases in a very different and most probably transparent way. * Internally, much of the implementation has been factored out into a backend- agnostic place, leaving us in a much better place when inventory will be ported to Tinkerpop3 and Titan 1.0. Unfortunately, the big features originally slated for this release - running on Titan 0.5.x and support for resource hierarchy, slipped into the next release, where they should be ready relatively shortly. Big thanks go out to Peter Palaga who fixed many of the REST API problems and implemented resource filtering. Cheers, Lukas From lkrejci at redhat.com Tue Jun 30 11:43:17 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 30 Jun 2015 17:43:17 +0200 Subject: [Hawkular-dev] Apps list search In-Reply-To: <16F1F8C9-1F63-42AF-88A8-3B683267FAB8@redhat.com> References: <16F1F8C9-1F63-42AF-88A8-3B683267FAB8@redhat.com> Message-ID: <2278420.AeTsadHi21@localhost.localdomain> What kind of query language are we going to support here? How will it represent (if at all) the graph nature of inventory entities (e.g. gimme all resources of type EAP in the "test" environment which relate to data source DS by relationship "uses")? On Tuesday, June 30, 2015 16:34:55 Gabriel Cardoso wrote: > Hello, > > I was assigned to design the search/filter component for the applications > list and would like to bring some questions. I already got some > requirements from Liz/Thomas. > > My proposal would be to present a behaviour similar to what JIRA does. They > have ?dropdown? selectors to allow filtering + a search box (initially). > > > > For our context, the dropdowns would be to filter State (Up, Down etc.) and > Type (EAP, Wildfly etc.). We probably don?t need the find input in the > beginning, when we have not many options. > Thomas brought this comment: > > The input text should still be editable to do more filtering such as: > > "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com > > ' " (To show all servers on *.corp.redhat.com > > that are down or unknown) > JIRA also covers that, when clicking on Advanced, the dropdowns are hidden > and everything goes inside the search input: > > > > I like this approach because we offer something user-friendly and at the > same time provide something more powerful for advanced users. > > I would like to hear your feedback. > @Inventory team, from what was presented, it is feasible to be implemented? > > Thanks, > Gabriel > > Gabriel Cardoso > UX designer @ Red Hat From theute at redhat.com Tue Jun 30 12:35:09 2015 From: theute at redhat.com (Thomas Heute) Date: Tue, 30 Jun 2015 18:35:09 +0200 Subject: [Hawkular-dev] Apps list search In-Reply-To: <2278420.AeTsadHi21@localhost.localdomain> References: <16F1F8C9-1F63-42AF-88A8-3B683267FAB8@redhat.com> <2278420.AeTsadHi21@localhost.localdomain> Message-ID: <5592C53D.6000401@redhat.com> For now we are looking for relatively simple filtering (rather than search). On the app server list, I guess we would want to filter on status AND hostname. For instance, I may want to filter the whole list for all servers on *.corp.redhat.com that are DOWN OR UNKNOWN If we allow for a user "query language" should be easy to understand by non hardcore developers, like in JIRA. Thomas On 06/30/2015 05:43 PM, Lukas Krejci wrote: > What kind of query language are we going to support here? How will it > represent (if at all) the graph nature of inventory entities (e.g. gimme all > resources of type EAP in the "test" environment which relate to data source DS > by relationship "uses")? > > On Tuesday, June 30, 2015 16:34:55 Gabriel Cardoso wrote: >> Hello, >> >> I was assigned to design the search/filter component for the applications >> list and would like to bring some questions. I already got some >> requirements from Liz/Thomas. >> >> My proposal would be to present a behaviour similar to what JIRA does. They >> have ?dropdown? selectors to allow filtering + a search box (initially). >> >> >> >> For our context, the dropdowns would be to filter State (Up, Down etc.) and >> Type (EAP, Wildfly etc.). We probably don?t need the find input in the >> beginning, when we have not many options. >> Thomas brought this comment: >>> The input text should still be editable to do more filtering such as: >>> "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com >>> ' " (To show all servers on *.corp.redhat.com >>> that are down or unknown) >> JIRA also covers that, when clicking on Advanced, the dropdowns are hidden >> and everything goes inside the search input: >> >> >> >> I like this approach because we offer something user-friendly and at the >> same time provide something more powerful for advanced users. >> >> I would like to hear your feedback. >> @Inventory team, from what was presented, it is feasible to be implemented? >> >> Thanks, >> Gabriel >> >> Gabriel Cardoso >> UX designer @ Red Hat > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Tue Jun 30 16:42:30 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Tue, 30 Jun 2015 16:42:30 -0400 Subject: [Hawkular-dev] C* schema design In-Reply-To: <2123449965.4790405.1434645667177.JavaMail.zimbra@redhat.com> References: <4DD9562B-299E-4D2E-8DCE-6CC7843E07A7@redhat.com> <2123449965.4790405.1434645667177.JavaMail.zimbra@redhat.com> Message-ID: <5592FF36.1050708@redhat.com> Before getting to Alerts, maybe we should touch a little on the persisted data in the model. At the moment everything is pretty much partitioned on TenantId. For example: CREATE TABLE ${keyspace}.triggers ( tenantId text, // other fields... id text, PRIMARY KEY (tenantId, id) ) In general the number of Triggers will be relatively small, likely maxing out in the thousands. It could feasibly be a very small number. Queries are usually going to be on a specific Trigger. But queries on all triggers or some cross-section (likely based on the results of a prior Tag search) are possible. But all searches will likely be within a tenant. Leaving it as is would give us single-partition searches. Data would only be spread cross-partition if multiple tenants are in play. I'd say this is likely OK as is, or we could try and spread things across partitions by manufacturing an additional field, like "idbucket" that was a modulo of the id hash. That could ensure a few partitions even if there is only one tenant. Whether we leave it as is or tweak it with a bucket, I would think the trigger-actions, conditions, dampening and tags that hang off a trigger should probably have the same partitionId as the trigger. They would get the same distribution and should only hit one partition on a query, which typically goes through the owning trigger. Actions are queried by tenantId and actionPlugin. Again, the low cardinality would probably make the current tenantId partitionId OK, but we could also use (tenantId,pluginName) and get distribution + single-partition querying. Tags are a little funny because the category field is optional but is also something that could be queried. When searching for Triggers the queries are likely (tenantId,name) or (tenantId,name,category). When displaying a Trigger it would be (tenantId,triggerId). In this case it's probably best to store full tags in two ways, with a clustering key of name, and a clustering key of triggerId. This is basically what we have already. We have 'name' and 'triggerId,name' We may be able to drop the 'name' segment from that last one. We have a secondary index on category for both, I think we may be able to drop the one on tags table and keep it only on tags_triggers table. Alerts are of course the big thing. Although millions of alerts is probably unlikely (certainly unwanted), the number is hard to predict. But it will be the highest cardinality by far, as single triggers can generate many alerts. The thing about alert querying, I think, is that it is the most recent, unresolved alerts, that are very likely the most interesting. Once an alert is resolved, and certainly once it is resolved and old, its usefulness typically goes down considerably. At that point queries would be more for aggregate reporting, etc. I don't think in a well-behaved system that a trigger would generate thousands of alerts in a day. It certainly could generate thousands, or more, in a lifetime. Queries for alerts are often across triggers. reports-style queries will likely be in a time range. For pure distribution John's suggestion of PRIMARY KEY ((tenantid, triggerid, date), alertid) may be good but would suffer multi-partition hits for a time-based query. We may also want to consider PRIMARY KEY ((tenantid, date), triggerId, alertid) with 'date' being some length in which most alerts become less interesting. Like maybe a week. i don't know if all alerts that get generated in an entire week may be too much for a partition, maybe a day, or 3 days, or something would be safer. We have several secondary tables for search. These should likely be partitioned similarly. let's keep discussing, I'm new at this and may have missed the mark... On 6/18/2015 12:41 PM, Lucas Ponce wrote: > >> CREATE TABLE alerts ( >> tenantid text, >> triggerid text, >> date timestamp, >> alertid text, >> payload text, >> PRIMARY KEY ((tenantid, triggerid, date), alertid) >> ) >> > Hey John, > > Thanks for the tip, I had exactly this approach in my todo-list for adding triggerid in the partition key. > Also the date is interesting. > > The main idea is to locate all info related on an specific trigger close, to avoid stress the full partition. > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lkrejci at redhat.com Tue Jun 30 17:07:18 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 30 Jun 2015 23:07:18 +0200 Subject: [Hawkular-dev] Inventory 0.1.0.Alpha3 released Message-ID: <1571494.iqkMQSXZR7@localhost.localdomain> Hi all, In a surprising move, Inventory released its 0.1.0.Alpha3 version AFTER 0.1.0.Final. The release was cut from a branch branched off of a commit preceding 0.1.0.Final such that 0.1.0.Alpha3 only contains the fix for https://issues.jboss.org/browse/HWKINVENT-54 on top of what already has been available in inventory 0.1.0.Alpha2. This has been done so that Hawkular 1.0.0.Alpha2 can be released without any further API breakage. Thanks, Lukas