From ppalaga at redhat.com Tue Dec 1 02:31:26 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Dec 2015 08:31:26 +0100 Subject: [Hawkular-dev] Travis Integration Tests! In-Reply-To: <43CF393D-92CE-45D1-8533-DAC55A14200F@redhat.com> References: <43CF393D-92CE-45D1-8533-DAC55A14200F@redhat.com> Message-ID: <565D4CCE.9040201@redhat.com> Hi Mike, could you please post links to a couple of those failed jobs? -- P On 2015-12-01 02:35, mike thompson wrote: > Hey Guys, > > So I think you all probably already know what I?m talking about. We have an indeterministic suite of integration tests. So, for every PR you have to submit it X times (2 to 7 is normal) before the PR can be merged and by that time it might already need to be rebased. Is this on anyones radar to look at? > > -- Mike > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From gbrown at redhat.com Tue Dec 1 03:20:51 2015 From: gbrown at redhat.com (Gary Brown) Date: Tue, 1 Dec 2015 03:20:51 -0500 (EST) Subject: [Hawkular-dev] Hawkular BTM 0.6.0.Final In-Reply-To: <154651903.14642909.1448957838021.JavaMail.zimbra@redhat.com> Message-ID: <1383550164.14644641.1448958051582.JavaMail.zimbra@redhat.com> Hi all Pleased to announce the release of Hawkular Business Transaction Management (BTM) version 0.6.0.Final. The main focus of this release has been the development of the business transaction stats UI page. A full list of the new features can be found here: https://github.com/hawkular/hawkular-btm/releases/tag/0.6.0.Final A demo of the new version is also available here: https://vimeo.com/147347020 Now work will start on version 0.7.0, which will focus on integration with Hawkular Alerts! Regards Gary From jpkroehling at redhat.com Tue Dec 1 04:05:55 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 1 Dec 2015 10:05:55 +0100 Subject: [Hawkular-dev] Travis Integration Tests! In-Reply-To: <43CF393D-92CE-45D1-8533-DAC55A14200F@redhat.com> References: <43CF393D-92CE-45D1-8533-DAC55A14200F@redhat.com> Message-ID: <565D62F3.3080305@redhat.com> Just to have another data point: Travis itself doesn't help much as well. From time to time, I get timeouts when starting Wildfly from within the integration tests. Just increasing the timeout is not a proper solution, but there's not much we can do at Travis... Based on my experience, Travis is the problem "most" of the time. - Juca. On 01.12.2015 02:35, mike thompson wrote: > Hey Guys, > > So I think you all probably already know what I?m talking about. We have an indeterministic suite of integration tests. So, for every PR you have to submit it X times (2 to 7 is normal) before the PR can be merged and by that time it might already need to be rebased. Is this on anyones radar to look at? > > -- Mike > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From snegrea at redhat.com Tue Dec 1 09:53:00 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Tue, 1 Dec 2015 09:53:00 -0500 (EST) Subject: [Hawkular-dev] Hawkular Metrics 0.10.0 - Release & Beyond In-Reply-To: <1444190753.1752564.1446503338035.JavaMail.zimbra@redhat.com> Message-ID: <1035597778.26933253.1448981580949.JavaMail.zimbra@redhat.com> Hello Everybody, I am happy to announce that release 0.10.0 of Hawkular Metrics was published on Monday. This is a regular schedule release anchored by bus and performance and stability enhancements, and container work. This release is not as large as previous ones because of we have a few major updates that will make their way into 0.11.0. Here is a list of major changes in this release: 1) Containers * Docker containers for Hawkular Metrics REST Interface are now based on Wildfly 9 (HWKMETRCS-147) * The deprecated container images have been moved out of the Hawkular Metrics repository (HWKMETRCS-328) 2) Hawkular Bus Integration * Performance improvements (HWKMETRCS-319) 3) Influx Endpoint * Use series name prefix to match a counter or a gauge (HWKMETRCS-66) Github Release: https://github.com/hawkular/hawkular-metrics/releases/tag/0.10.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/12328552 Hawkular Metrics Clients * Ruby: https://github.com/hawkular/hawkular-client-ruby * Python: https://github.com/hawkular/hawkular-client-python * Go: https://github.com/hawkular/hawkular-client-go Hawkular Metrics 0.11.0 & Beyond: 1) Continuous agggregation - this has been a long term project goal and we are getting closer with refining the requirements and infrastructure 2) Improved docker and kubernetes support - this is a long term goal for the project 3) Improved tag support - to add bulk tag operations and tag queries 4) Improved aggregate downsampling for multiple metrics - the project has now a base with recently added stacking and uniform support; the goal is to expand the aggregation methods 5) Improved integration of Hawkular Metrics and Hawkular Alerts - this will be added the our long term development goals with the initial integration phase part of the release scheduled at the end of November. Keep and eye on both projects and the mailing list for more announcements. A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, and Heiko Rupp for their project contributions. Thank you, Stefan Negrea Software Engineer From jsanda at redhat.com Tue Dec 1 15:09:11 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 1 Dec 2015 15:09:11 -0500 Subject: [Hawkular-dev] Where should integration components live? Message-ID: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> Currently integration components, particularly those that interact with the bus, live in the respective component repos. I have been working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ to the default messaging subsystem in WildFly 10, which is based on ActiveMQ Artemis. While working on this, I started to wonder if all of the integration components should live in the same repo. Let?s say I make a breaking change in the bus, then we have to update and cut releases for each of the component repos, which is currently five or six. If the integration components live in the same repo as the bus, it is much easier to make the changes and we only have one new release to worry about. Keeping the integration components in the same repo should also help reduce the number of dependencies in each of the component repos which makes development on any one of them easier. I want to know what people think because once HAWKULAR-844 is done, I would like to consider some refactoring in the bus code to utilize JMS 2.0 APIs including support for async sending/receiving messages. This would likely entail breaking changes. - John From ppalaga at redhat.com Tue Dec 1 15:34:35 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Dec 2015 21:34:35 +0100 Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> Message-ID: <565E045B.4040909@redhat.com> Hi John, I was about to write a message on this topic now after I spoke with mazz :) > integration components, particularly those that interact > with the bus, live in the respective component repos. I am not 100% sure which are "integration components" for you. Nevertheless, mazz and me agree to move the "new Bus" (after HAWKULAR-844) and "new Nest" (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons git repository. I'll write more about the proposal in the next message. -- P On 2015-12-01 21:09, John Sanda wrote: > Currently integration components, particularly those that interact > with the bus, live in the respective component repos. I have been > working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ > to the default messaging subsystem in WildFly 10, which is based on > ActiveMQ Artemis. While working on this, I started to wonder if all > of the integration components should live in the same repo. Let?s say > I make a breaking change in the bus, then we have to update and cut > releases for each of the component repos, which is currently five or > six. If the integration components live in the same repo as the bus, > it is much easier to make the changes and we only have one new > release to worry about. Keeping the integration components in the > same repo should also help reduce the number of dependencies in each > of the component repos which makes development on any one of them > easier. I want to know what people think because once HAWKULAR-844 is > done, I would like to consider some refactoring in the bus code to > utilize JMS 2.0 APIs including support for async sending/receiving > messages. This would likely entail breaking changes. > > - John _______________________________________________ hawkular-dev > mailing list hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Tue Dec 1 15:36:02 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 1 Dec 2015 15:36:02 -0500 (EST) Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> Message-ID: <1506689500.21766570.1449002162450.JavaMail.zimbra@redhat.com> Similarly, what about the things in hawkular repo's "modules" directory? Shouldn't those also be moved to the same common repo? Maybe they can't for technical reasons, but it think we should at least look into it, especially if we are considering moving components to a common repo. ----- Original Message ----- > Currently integration components, particularly those that interact with the > bus, live in the respective component repos. I have been working with Peter > on HAWKULAR-844 to migrate the bus from ActiveMQ to the default messaging > subsystem in WildFly 10, which is based on ActiveMQ Artemis. While working > on this, I started to wonder if all of the integration components should > live in the same repo. Let?s say I make a breaking change in the bus, then > we have to update and cut releases for each of the component repos, which is > currently five or six. If the integration components live in the same repo > as the bus, it is much easier to make the changes and we only have one new > release to worry about. Keeping the integration components in the same repo > should also help reduce the number of dependencies in each of the component > repos which makes development on any one of them easier. I want to know what > people think because once HAWKULAR-844 is done, I would like to consider > some refactoring in the bus code to utilize JMS 2.0 APIs including support > for async sending/receiving messages. This would likely entail breaking > changes. > > - John > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jsanda at redhat.com Tue Dec 1 15:50:12 2015 From: jsanda at redhat.com (John Sanda) Date: Tue, 1 Dec 2015 15:50:12 -0500 Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <565E045B.4040909@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> <565E045B.4040909@redhat.com> Message-ID: <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> I am primarily talking about bus integration which would include things like, * hawkular-metrics-component * hawkular-alerts-bus * hawkular-alerts-bus * hawkular-alerts-actions-bus * hawkular-inventory-bus-api * hawkular-inventory-bus Once we move to WF 10, we will drop the bus subsystem in favor of the default messaging subsystem. All that remains of the bus is a shared, common library. It will no longer have (or need to have) any relationship/dependency with the nest. I wonder if the bus integration components should live in the main hawkular repo. If we have integration tests involving these components that run in a hawkular server, then I think from a development stand point, it makes things easier if they live in the main hawkular repo. > On Dec 1, 2015, at 3:34 PM, Peter Palaga wrote: > > Hi John, I was about to write a message on this topic now after I spoke > with mazz :) > >> integration components, particularly those that interact >> with the bus, live in the respective component repos. > > I am not 100% sure which are "integration components" for you. > > Nevertheless, mazz and me agree to move the "new Bus" (after > HAWKULAR-844) and "new Nest" > (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons > git repository. I'll write more about the proposal in the next message. > > -- P > > On 2015-12-01 21:09, John Sanda wrote: >> Currently integration components, particularly those that interact >> with the bus, live in the respective component repos. I have been >> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ >> to the default messaging subsystem in WildFly 10, which is based on >> ActiveMQ Artemis. While working on this, I started to wonder if all >> of the integration components should live in the same repo. Let?s say >> I make a breaking change in the bus, then we have to update and cut >> releases for each of the component repos, which is currently five or >> six. If the integration components live in the same repo as the bus, >> it is much easier to make the changes and we only have one new >> release to worry about. Keeping the integration components in the >> same repo should also help reduce the number of dependencies in each >> of the component repos which makes development on any one of them >> easier. I want to know what people think because once HAWKULAR-844 is >> done, I would like to consider some refactoring in the bus code to >> utilize JMS 2.0 APIs including support for async sending/receiving >> messages. This would likely entail breaking changes. >> >> - John _______________________________________________ hawkular-dev >> mailing list hawkular-dev at lists.jboss.org >> https://lists.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 Dec 1 16:49:01 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 1 Dec 2015 22:49:01 +0100 Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> <565E045B.4040909@redhat.com> <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> Message-ID: <565E15CD.302@redhat.com> On 2015-12-01 21:50, John Sanda wrote: > I am primarily talking about bus integration which would include things like, > > * hawkular-metrics-component > * hawkular-alerts-bus > * hawkular-alerts-bus > * hawkular-alerts-actions-bus > * hawkular-inventory-bus-api > * hawkular-inventory-bus Ah OK, this is a little bit different area than I wanted to speak about. > Once we move to WF 10, we will drop the bus subsystem in favor of the > default messaging subsystem. All that remains of the bus is a shared, > common library. It will no longer have (or need to have) any > relationship/dependency with the nest. I wonder if the bus integration > components should live in the main hawkular repo. If we have > integrationtests involving these components that run in a hawkular > server, then I think from a development stand point, it makes things > easier if they live in the main hawkular repo. I agree that integration tests should be located as close as possible to the components they are testing, ideally the tests should be located in the same git repository as the components tested. However, we cannot move bus-common to HK main, at least because that would introduce circular dependencies between HK main on one side and Agent and Command Gateway on the other side. -- P > >> On Dec 1, 2015, at 3:34 PM, Peter Palaga wrote: >> >> Hi John, I was about to write a message on this topic now after I spoke >> with mazz :) >> >>> integration components, particularly those that interact >>> with the bus, live in the respective component repos. >> >> I am not 100% sure which are "integration components" for you. >> >> Nevertheless, mazz and me agree to move the "new Bus" (after >> HAWKULAR-844) and "new Nest" >> (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons >> git repository. I'll write more about the proposal in the next message. >> >> -- P >> >> On 2015-12-01 21:09, John Sanda wrote: >>> Currently integration components, particularly those that interact >>> with the bus, live in the respective component repos. I have been >>> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ >>> to the default messaging subsystem in WildFly 10, which is based on >>> ActiveMQ Artemis. While working on this, I started to wonder if all >>> of the integration components should live in the same repo. Let?s say >>> I make a breaking change in the bus, then we have to update and cut >>> releases for each of the component repos, which is currently five or >>> six. If the integration components live in the same repo as the bus, >>> it is much easier to make the changes and we only have one new >>> release to worry about. Keeping the integration components in the >>> same repo should also help reduce the number of dependencies in each >>> of the component repos which makes development on any one of them >>> easier. I want to know what people think because once HAWKULAR-844 is >>> done, I would like to consider some refactoring in the bus code to >>> utilize JMS 2.0 APIs including support for async sending/receiving >>> messages. This would likely entail breaking changes. >>> >>> - John _______________________________________________ hawkular-dev >>> mailing list hawkular-dev at lists.jboss.org >>> https://lists.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 Dec 2 03:04:53 2015 From: gbrown at redhat.com (Gary Brown) Date: Wed, 2 Dec 2015 03:04:53 -0500 (EST) Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> <565E045B.4040909@redhat.com> <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> Message-ID: <137622850.15674185.1449043493323.JavaMail.zimbra@redhat.com> I think if all that will remain is a common library, which I guess will be located in hawkular-commons, then it would be better for the integration code to remain with their components. Although this work may be disruptive and result in changes in multiple repos, I still see the bus as plumbing and it should result in a stable API. Whereas the component code that uses the bus is more likely to change, and therefore it would be easier for the component developers to have their code in one place. Regards Gary ----- Original Message ----- > I am primarily talking about bus integration which would include things like, > > * hawkular-metrics-component > * hawkular-alerts-bus > * hawkular-alerts-bus > * hawkular-alerts-actions-bus > * hawkular-inventory-bus-api > * hawkular-inventory-bus > > Once we move to WF 10, we will drop the bus subsystem in favor of the default > messaging subsystem. All that remains of the bus is a shared, common > library. It will no longer have (or need to have) any > relationship/dependency with the nest. I wonder if the bus integration > components should live in the main hawkular repo. If we have integration > tests involving these components that run in a hawkular server, then I think > from a development stand point, it makes things easier if they live in the > main hawkular repo. > > > On Dec 1, 2015, at 3:34 PM, Peter Palaga wrote: > > > > Hi John, I was about to write a message on this topic now after I spoke > > with mazz :) > > > >> integration components, particularly those that interact > >> with the bus, live in the respective component repos. > > > > I am not 100% sure which are "integration components" for you. > > > > Nevertheless, mazz and me agree to move the "new Bus" (after > > HAWKULAR-844) and "new Nest" > > (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons > > git repository. I'll write more about the proposal in the next message. > > > > -- P > > > > On 2015-12-01 21:09, John Sanda wrote: > >> Currently integration components, particularly those that interact > >> with the bus, live in the respective component repos. I have been > >> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ > >> to the default messaging subsystem in WildFly 10, which is based on > >> ActiveMQ Artemis. While working on this, I started to wonder if all > >> of the integration components should live in the same repo. Let?s say > >> I make a breaking change in the bus, then we have to update and cut > >> releases for each of the component repos, which is currently five or > >> six. If the integration components live in the same repo as the bus, > >> it is much easier to make the changes and we only have one new > >> release to worry about. Keeping the integration components in the > >> same repo should also help reduce the number of dependencies in each > >> of the component repos which makes development on any one of them > >> easier. I want to know what people think because once HAWKULAR-844 is > >> done, I would like to consider some refactoring in the bus code to > >> utilize JMS 2.0 APIs including support for async sending/receiving > >> messages. This would likely entail breaking changes. > >> > >> - John _______________________________________________ hawkular-dev > >> mailing list hawkular-dev at lists.jboss.org > >> https://lists.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 Dec 2 04:12:27 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 2 Dec 2015 04:12:27 -0500 (EST) Subject: [Hawkular-dev] Where should integration components live? In-Reply-To: <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> References: <2DB383D3-6B7D-4C99-BD8D-CD40E563CB13@redhat.com> <565E045B.4040909@redhat.com> <0F0838A7-A9CA-4DF3-82C5-C9D3B3D7B26F@redhat.com> Message-ID: <1081198547.22060857.1449047547248.JavaMail.zimbra@redhat.com> Everything has pros and cons. If we move the glue projects into hawkular repo, yes a change in the bus will be easier to manager. On the contrary, a change on the component will need an additional update into the hawkular repo. So, synchronization is needed in one side of another. For alerts, that we relied on the bus for the integration metrics and also internally for plugins integration we worked fine with the components in alerts repo. As a change in the bus is rare (like this, once WF10 is out, I don't think a change here is going to be frequent), but on the contrary a change on these projects are pretty normal. So based on how we worked, for us, it would be better to maintain them on the component, to have all component-related-logic together. I agree that perhaps it might be parts shared that can be extracted and placed in a commons location, but most of the logic should remamin in the component IMO. Lucas ----- Original Message ----- > From: "John Sanda" > To: "Discussions around Hawkular development" > Sent: Tuesday, December 1, 2015 9:50:12 PM > Subject: Re: [Hawkular-dev] Where should integration components live? > > I am primarily talking about bus integration which would include things like, > > * hawkular-metrics-component > * hawkular-alerts-bus > * hawkular-alerts-bus > * hawkular-alerts-actions-bus > * hawkular-inventory-bus-api > * hawkular-inventory-bus > > Once we move to WF 10, we will drop the bus subsystem in favor of the default > messaging subsystem. All that remains of the bus is a shared, common > library. It will no longer have (or need to have) any > relationship/dependency with the nest. I wonder if the bus integration > components should live in the main hawkular repo. If we have integration > tests involving these components that run in a hawkular server, then I think > from a development stand point, it makes things easier if they live in the > main hawkular repo. > > > On Dec 1, 2015, at 3:34 PM, Peter Palaga wrote: > > > > Hi John, I was about to write a message on this topic now after I spoke > > with mazz :) > > > >> integration components, particularly those that interact > >> with the bus, live in the respective component repos. > > > > I am not 100% sure which are "integration components" for you. > > > > Nevertheless, mazz and me agree to move the "new Bus" (after > > HAWKULAR-844) and "new Nest" > > (https://github.com/hawkular/hawkular-nest/pull/1 ) to hawkular-commons > > git repository. I'll write more about the proposal in the next message. > > > > -- P > > > > On 2015-12-01 21:09, John Sanda wrote: > >> Currently integration components, particularly those that interact > >> with the bus, live in the respective component repos. I have been > >> working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ > >> to the default messaging subsystem in WildFly 10, which is based on > >> ActiveMQ Artemis. While working on this, I started to wonder if all > >> of the integration components should live in the same repo. Let?s say > >> I make a breaking change in the bus, then we have to update and cut > >> releases for each of the component repos, which is currently five or > >> six. If the integration components live in the same repo as the bus, > >> it is much easier to make the changes and we only have one new > >> release to worry about. Keeping the integration components in the > >> same repo should also help reduce the number of dependencies in each > >> of the component repos which makes development on any one of them > >> easier. I want to know what people think because once HAWKULAR-844 is > >> done, I would like to consider some refactoring in the bus code to > >> utilize JMS 2.0 APIs including support for async sending/receiving > >> messages. This would likely entail breaking changes. > >> > >> - John _______________________________________________ hawkular-dev > >> mailing list hawkular-dev at lists.jboss.org > >> https://lists.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 Dec 4 03:37:01 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 4 Dec 2015 09:37:01 +0100 Subject: [Hawkular-dev] Moving Nest and Bus to Hawkular Commons git repository Message-ID: <566150AD.5060000@redhat.com> Hi *, this was already discussed on several calls. Although I know of no objections, I am putting it also here to give you all the last chance to protest or discuss. The plan is to move the Maven modules from Nest [1] and Bus [2] git repositories to Commons repository [3]. Details: * Nest and Bus Maven modules will be moved to Hawkular Commons git repository * Nest and Bus Maven modules will belong to groupId org.hawkular.commons * All modules of the org.hawkular.commons incl. Nest and Bus will be released together * The new and old subcomponents of Commons (such as Nest, Bus, Templates, c* driver, ...) will be allowed to depend on each other, but clearly, they may not introduce circular dependencies. * To help to keep control on which subcomponent depends on which other subcomponents, the dependency management will happen on the subcomponent level rather than in hawkular-commons-parent * Components consuming Nest, Bus or any of the other subcomponents of Hawkular Commons will have to declare just one version property version.org.hawkular.commons to manage all the the artifacts they need from commons * As noted by Stefan, only such subcomponents should be allowed to be hosted in Commons that are generic enough -i.e. that do not contain any deep and specific domain knowledge. Move of Bus and Nest to commons satisfies this. Pros: * Decrease the maintenance overhead by decreasing the number of git repositories and by decreasing the number of Hawkular components having independent release cycles - e.g. after a new release of Hawkular Parent there is two component less to upgrade, two componets less to release and n components less to upgrade that depend on Bus and Nest Cons: * Loose some amount of design cleanness - Hawkular Commons hosts Maven modules with clean logical borders that could be hosted and released independently. * Esp. the independent release cycle could be seen as an advantage when fixing bugs and CVEs Pseudo-con: * Note that the new home of Nest and Bus does not prescribe any component that consumed Commons so far to consume also Nest and Bus from now on. Dependent components can still choose the artifacts to depend on with an unchanged granularity: Who dependeded on embedded c* so far can stay with it without depending on Bus or Nest. I am going to work on this change now. [1] https://github.com/hawkular/hawkular-nest [2] https://github.com/hawkular/hawkular-bus [3] https://github.com/hawkular/hawkular-commons Thanks, Peter From ppalaga at redhat.com Fri Dec 4 05:20:30 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 4 Dec 2015 11:20:30 +0100 Subject: [Hawkular-dev] Moving Nest and Bus to Hawkular Commons git repository In-Reply-To: <566150AD.5060000@redhat.com> References: <566150AD.5060000@redhat.com> Message-ID: <566168EE.7020406@redhat.com> FYI, I released Bus 0.8.0.Final before starting to move it. -- P On 2015-12-04 09:37, Peter Palaga wrote: > Hi *, > > this was already discussed on several calls. Although I know of no > objections, I am putting it also here to give you all the last chance to > protest or discuss. > > The plan is to move the Maven modules from Nest [1] and Bus [2] git > repositories to Commons repository [3]. > > Details: > * Nest and Bus Maven modules will be moved to Hawkular Commons git > repository > * Nest and Bus Maven modules will belong to groupId org.hawkular.commons > * All modules of the org.hawkular.commons incl. Nest and Bus will be > released together > * The new and old subcomponents of Commons (such as Nest, Bus, > Templates, c* driver, ...) will be allowed to depend on each other, > but clearly, they may not introduce circular dependencies. > * To help to keep control on which subcomponent depends on which other > subcomponents, the dependency management will happen on > the subcomponent level rather than in hawkular-commons-parent > > * Components consuming Nest, Bus or any of the other subcomponents of > Hawkular Commons will have to declare just one version property > version.org.hawkular.commons to manage all the the artifacts they > need from commons > > * As noted by Stefan, only such subcomponents should be allowed to be > hosted in Commons that are generic enough -i.e. that do not contain > any deep and specific domain knowledge. Move of Bus and Nest to > commons satisfies this. > > Pros: > * Decrease the maintenance overhead by decreasing the number of git > repositories and by decreasing the number of Hawkular components > having independent release cycles - e.g. after a new release of > Hawkular Parent there is two component less to upgrade, two componets > less to release and n components less to upgrade that depend on Bus > and Nest > > Cons: > * Loose some amount of design cleanness - Hawkular Commons hosts Maven > modules with clean logical borders that could be hosted and released > independently. > * Esp. the independent release cycle could be seen as an > advantage when fixing bugs and CVEs > > Pseudo-con: > * Note that the new home of Nest and Bus does not prescribe any > component that consumed Commons so far to consume also Nest and Bus > from now on. Dependent components can still choose the artifacts to > depend on with an unchanged granularity: Who dependeded on embedded > c* so far can stay with it without depending on Bus or Nest. > > I am going to work on this change now. > > [1] https://github.com/hawkular/hawkular-nest > [2] https://github.com/hawkular/hawkular-bus > [3] https://github.com/hawkular/hawkular-commons > > Thanks, > > Peter > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Fri Dec 4 10:01:35 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 04 Dec 2015 16:01:35 +0100 Subject: [Hawkular-dev] Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource ids. (#71) References: Message-ID: <990BA6D9-2C33-475C-BE61-8A40277A6BB3@redhat.com> Before we implement this - should we finally go and ban characters that are not valid in URIs in a literal way (see RFC 2396)? reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," Also: 2.4.3. Excluded US-ASCII Characters control = delims = "<" | ">" | "#" | "%" | <"> unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" Data corresponding to excluded characters must be escaped in order to be properly represented within a URI. > From: Jirka Kremser > To: hawkular/hawkular-ui-services > > Subject: [hawkular-ui-services] Slash hell: Preserving the encoded > slashes in the resource ids. (#71) > Date: Fri, 04 Dec 2015 06:53:17 -0800 > > Currently the interceptor replaces all the encoded slashes to the > simple ones, but we need to have the way to pass the encoded slash in > the resource id. If the resource id is manually encoded with > window.encodeURI() and then angular does it once more for the > 'percent' symbol, it ends up as '%252F' here we turn it back to simple > '%2F' for which the inventory backend is prepared. In short: '/' are > allowed as resource separators: r1/r2/r3 and '%2F' are allowed in the > resource ids: r%2F1/r%2F2 > > @ammendonca could you please check? > You can view, comment on, or merge this pull request online at: > > https://github.com/hawkular/hawkular-ui-services/pull/71 > > -- Commit Summary -- > > * Preserving the encoded slashes in the resource ids. Currently the > interceptor replaces all the encoded slashes to the simple ones, but > we need to have the way to pass the encoded slash in the resource id. > If the resource id is manually encoded with window.encodeURI() and > then angular does it once more for the 'percent' symbol, it ends up as > '%252F' here we turn it back to simple '%2F' for which the inventory > backend is prepared. In short: '/' are allowed as resource separators: > r1/r2/r3 and '%2F' are allowed in the resource ids: r%2F1/r%2F2 > > -- File Changes -- > > M src/rest/hawkRest-inventory-provider.ts (10) > > -- Patch Links -- > > https://github.com/hawkular/hawkular-ui-services/pull/71.patch > https://github.com/hawkular/hawkular-ui-services/pull/71.diff > > --- > Reply to this email directly or view it on GitHub: > https://github.com/hawkular/hawkular-ui-services/pull/71 From mazz at redhat.com Fri Dec 4 10:48:11 2015 From: mazz at redhat.com (John Mazzitelli) Date: Fri, 4 Dec 2015 10:48:11 -0500 (EST) Subject: [Hawkular-dev] Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource ids. (#71) In-Reply-To: <990BA6D9-2C33-475C-BE61-8A40277A6BB3@redhat.com> References: <990BA6D9-2C33-475C-BE61-8A40277A6BB3@redhat.com> Message-ID: <2128956505.23791498.1449244091052.JavaMail.zimbra@redhat.com> [I'm going to prefix this with - "this is all in my opinion" - if I'm the sole voice in the wilderness on this, I'll shut up.] Banning characters from resource ID strings that are not valid in URIs is essentially forcing an unnatural limitation on the feeds. First, feeds don't care that these resource IDs might end up on URLs. But they do care to use a string that identifies a resource (which may contain URI-restricted chars). Second, hawkular server should not dictate anything about resource IDs that feeds want to set. It should be the feeds that tell the server what they want the IDs to be and the server just uses them. There are going to be third party feeds that will want to set their own IDs and I think you are just going to have to eventually solve this problem anyway (the whole goal of the "feed" system was to make writing feeds the easiest as possible - dictating to the feed authors how they must design their IDs goes against that - IDs should be strings, that's all the restriction we should place on them). Next you are going to want to put the limitation that resource IDs must be normalized and cannot have parent IDs in them :) but rather IDs should only contain the last address path segment and the resource ancestry should have the rest of the ID parts; thus causing the feeds to no longer have a fully addressable resource ID easy at hand but instead feeds would now be required to do the extra steps of either calculating full addresses for resources by crawling the ancestor tree and performing string manipulation or be forced to add another piece of redundant data to hold a pre-calculated full address. In other words, making the life of the feed author harder. I say err on the side of cleaner, easier to write and maintain code for the feed author, which will also tend to make it more efficient at runtime (since there will be no need for extra string manipulation). And it will make less hoops that community-developed feed developers will have to jump through. In other words, let us do some up-front extra work and free the feed developer from having to do extra work to encode IDs so they are acceptable to Hawkular. Is this really just so we can support pretty REST URLs (which I assume the customer never sees, right?) Are there other reasons for wanting this restriction? Because it really shouldn't be a problem to allow encoded REST URLs. ----- Original Message ----- > > Before we implement this - should we finally > go and ban characters that are not valid in URIs > in a literal way (see RFC 2396)? > > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | > "$" | "," > > Also: > > 2.4.3. Excluded US-ASCII Characters > > control = > delims = "<" | ">" | "#" | "%" | <"> > unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" > > Data corresponding to excluded characters must be escaped in order to > be properly represented within a URI. > > > > > > From: Jirka Kremser > > To: hawkular/hawkular-ui-services > > > > Subject: [hawkular-ui-services] Slash hell: Preserving the encoded > > slashes in the resource ids. (#71) > > Date: Fri, 04 Dec 2015 06:53:17 -0800 > > > > Currently the interceptor replaces all the encoded slashes to the > > simple ones, but we need to have the way to pass the encoded slash in > > the resource id. If the resource id is manually encoded with > > window.encodeURI() and then angular does it once more for the > > 'percent' symbol, it ends up as '%252F' here we turn it back to simple > > '%2F' for which the inventory backend is prepared. In short: '/' are > > allowed as resource separators: r1/r2/r3 and '%2F' are allowed in the > > resource ids: r%2F1/r%2F2 > > > > @ammendonca could you please check? > > You can view, comment on, or merge this pull request online at: > > > > https://github.com/hawkular/hawkular-ui-services/pull/71 > > > > -- Commit Summary -- > > > > * Preserving the encoded slashes in the resource ids. Currently the > > interceptor replaces all the encoded slashes to the simple ones, but > > we need to have the way to pass the encoded slash in the resource id. > > If the resource id is manually encoded with window.encodeURI() and > > then angular does it once more for the 'percent' symbol, it ends up as > > '%252F' here we turn it back to simple '%2F' for which the inventory > > backend is prepared. In short: '/' are allowed as resource separators: > > r1/r2/r3 and '%2F' are allowed in the resource ids: r%2F1/r%2F2 > > > > -- File Changes -- > > > > M src/rest/hawkRest-inventory-provider.ts (10) > > > > -- Patch Links -- > > > > https://github.com/hawkular/hawkular-ui-services/pull/71.patch > > https://github.com/hawkular/hawkular-ui-services/pull/71.diff > > > > --- > > Reply to this email directly or view it on GitHub: > > https://github.com/hawkular/hawkular-ui-services/pull/71 > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jpkroehling at redhat.com Fri Dec 4 11:07:47 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Fri, 4 Dec 2015 17:07:47 +0100 Subject: [Hawkular-dev] Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource ids. (#71) In-Reply-To: <2128956505.23791498.1449244091052.JavaMail.zimbra@redhat.com> References: <990BA6D9-2C33-475C-BE61-8A40277A6BB3@redhat.com> <2128956505.23791498.1449244091052.JavaMail.zimbra@redhat.com> Message-ID: <5661BA53.7060509@redhat.com> On 04.12.2015 16:48, John Mazzitelli wrote: > First, feeds don't care that these resource IDs might end up on URLs. +1 . As a general comment not related to this particular task/bug/whatever this is: places building URLs should *always* properly encode/decode URL parts. Failing to do so is, among other things, a security liability. - Juca. From mwringe at redhat.com Fri Dec 4 12:15:17 2015 From: mwringe at redhat.com (Matthew Wringe) Date: Fri, 4 Dec 2015 12:15:17 -0500 (EST) Subject: [Hawkular-dev] Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource ids. (#71) In-Reply-To: <5661BA53.7060509@redhat.com> References: <990BA6D9-2C33-475C-BE61-8A40277A6BB3@redhat.com> <2128956505.23791498.1449244091052.JavaMail.zimbra@redhat.com> <5661BA53.7060509@redhat.com> Message-ID: <1516101605.35104009.1449249317892.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: hawkular-dev at lists.jboss.org > Sent: Friday, December 4, 2015 11:07:47 AM > Subject: Re: [Hawkular-dev] Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource > ids. (#71) > > On 04.12.2015 16:48, John Mazzitelli wrote: > > First, feeds don't care that these resource IDs might end up on URLs. > > +1 . As a general comment not related to this particular > task/bug/whatever this is: places building URLs should *always* properly > encode/decode URL parts. Failing to do so is, among other things, a > security liability. Also part of the problem is that even if everything we write and control ourselves is properly encoding the URL, it doesn't mean that this will properly work out on an actual network somewhere. There are other intermediary server which may control and route connections, and these servers tend to really not like certain elements within a URL, even if they are properly encode. We have already ran into a bunch of issues with this already where something else doesn't like it and either blocks or mangles the URL before sending it off to our components. Which sucks, because then our stuff wont work properly due to bugs in completely separate servers. So far we have come up work arounds (sort of, for one component it ended up that we just couldn't use it), but I have a feeling eventually we may have to add an option to base58 encode the metric id in the url From mithomps at redhat.com Tue Dec 8 10:15:14 2015 From: mithomps at redhat.com (mike thompson) Date: Tue, 8 Dec 2015 07:15:14 -0800 Subject: [Hawkular-dev] Monitoring Systems Article Message-ID: <883B2E3F-069E-4E8A-8D82-9C4B4F4DF7F9@redhat.com> I thought this was an interesting article, especially around syntactic monitoring systems: http://container-solutions.com/monitoring-performance-microservice-architectures/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151208/b0c999ac/attachment.html From mfoley at redhat.com Wed Dec 9 09:09:03 2015 From: mfoley at redhat.com (Michael Foley) Date: Wed, 9 Dec 2015 09:09:03 -0500 (EST) Subject: [Hawkular-dev] Cancelled: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Message-ID: <1318251602.39061167.1449670142982.JavaMail.zimbra@redhat.com> A single instance of the following meeting has been cancelled: Subject: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1 Organizer: "Michael Foley" Location: Bluejeans http://www.bluejeans.com/mfoley51 Time: Wednesday, December 9, 2015, 3:00:00 PM - 3:30:00 PM GMT -05:00 US/Canada Eastern Required: pruan at redhat.com; mmahoney at redhat.com; vnguyen at redhat.com; snegrea at redhat.com; jsanda at redhat.com; mwringe at redhat.com Optional: jon-qa-list at redhat.com; jboss-on-team at redhat.com; hawkular-dev at lists.jboss.org *~*~*~*~*~*~*~*~*~* Hi, Let's have a discussion and planning session on testing Openshift & Hawkular Integration! Let's use this etherpad to coordinate the discussion -->> http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning 5 Point Plan for Openshift 3.1 GA * Unit tests .... owned by Hawk-Metrics developers * Integration tests ... owned by Hawk-Metrics developers and Hawk-Metrics QE * Performance CI on Hawk-Metrics (this one is actually new and was not discussed on Wednesday , but I now see it makes sense) * Functional Integration tests on Hawk-Metrics latest + Openshift Origin latest * Funtional/UI .... Cucumber/Ruby tests ...owned by Openshift QE * Functional/Rest ... Cucumber/Ruby tests ... owned by Openshift QE * Performance & Scalability .... owned by Openshift QE Regards, Michael Foley QE Supervisor, Middleware BU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151209/9684973b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 7619 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151209/9684973b/attachment.bin From theute at redhat.com Wed Dec 9 09:35:45 2015 From: theute at redhat.com (Thomas Heute) Date: Wed, 9 Dec 2015 15:35:45 +0100 Subject: [Hawkular-dev] Monitoring Systems Article In-Reply-To: <883B2E3F-069E-4E8A-8D82-9C4B4F4DF7F9@redhat.com> References: <883B2E3F-069E-4E8A-8D82-9C4B4F4DF7F9@redhat.com> Message-ID: Yes interesting, this is why I think the inventory is being an important element of monitoring. It's not enough to look at a single resource, we need to look at how multiple resources are "connected". On Tue, Dec 8, 2015 at 4:15 PM, mike thompson wrote: > I thought this was an interesting article, especially around syntactic > monitoring systems: > > > http://container-solutions.com/monitoring-performance-microservice-architectures/ > > > > _______________________________________________ > 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/20151209/2573a2c8/attachment.html From mazz at redhat.com Wed Dec 9 10:27:37 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 9 Dec 2015 10:27:37 -0500 (EST) Subject: [Hawkular-dev] Monitoring Systems Article In-Reply-To: References: <883B2E3F-069E-4E8A-8D82-9C4B4F4DF7F9@redhat.com> Message-ID: <127660885.26170917.1449674857244.JavaMail.zimbra@redhat.com> I think we all agree that having an inventory with relationships between components and their dependencies/dependents would be very helpful to perform more intelligent alerting (e.g. if a database's write performance is performing poorly, yes we can alert on the database resource, but any application that uses that database for storage should go "yellow" to alert the user that performance degradation is caused by the bad DB and that storage failures could be on the horizon. Expand this further - you could be monitoring a disk, see it is malfunctioning, and alert on all DBs using that disk, which in turn can alert on all apps using that DB). Hawkular Inventory can already store those relationships in a graph, IF those relationships are known. BUT! As i see it, it is the discovery of those relationships that is the issue. Sure you can possibly auto-discover SOME relationships (e.g. we could look at the definitions in WildFly configuration and relate those databases to that WildFly application server), but many relationships are difficult if not impossible to auto-detect. For example, how does the WildFly agent know WHICH database resource to relate to its app server? How does the DB resource in inventory (presumably created by another feed) get known to the WF agent such that THAT DB gets related with THAT WF Server?). In other words, feeds/agents won't know about the full inventory "universe" to be able to create many relationships that you would think should be obvious to them. We have Gary's BTM which could be the answer to some of this (his injected monitoring code could be used to detect these relationships and automatically tell inventory about them - but again, how does it know about the full inventory identities of the resources it encounters to be able to relate them together). I think we need a really good UI story to help users map these relationships manually. The users will be able to tell us about these "hidden" relationships - relationships that cannot be auto-discovered. But it needs to be intuitive and easy to map out these relationships. ----- Original Message ----- > Yes interesting, this is why I think the inventory is being an important > element of monitoring. It's not enough to look at a single resource, we need > to look at how multiple resources are "connected". > > On Tue, Dec 8, 2015 at 4:15 PM, mike thompson < mithomps at redhat.com > wrote: > > > > I thought this was an interesting article, especially around syntactic > monitoring systems: > > http://container-solutions.com/monitoring-performance-microservice-architectures/ > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.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 Dec 9 15:17:04 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 9 Dec 2015 15:17:04 -0500 (EST) Subject: [Hawkular-dev] agent can now periodically perform discovery scans In-Reply-To: <605787029.26314615.1449691976001.JavaMail.zimbra@redhat.com> Message-ID: <1469749478.26315429.1449692224883.JavaMail.zimbra@redhat.com> FYI. The Hawkular WildFly Agent can now be configured to perform automatic discovery scans periodically. By default, the agent will perform auto-discovery every hour. You can make this more frequent or less frequent by adding the "autoDiscoveryScanPeriodSecs" to the agent's top level element in standalone.xml. It is specified in seconds as the name implies (again, default is 3600 == 1 hour). If you set this value to 0, auto-discovery will be disabled and the agent will act just like it acts now (performs an initial scan at startup to get the inventory, but that's it). That is all. From hrupp at redhat.com Thu Dec 10 11:10:22 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 10 Dec 2015 17:10:22 +0100 Subject: [Hawkular-dev] Hawkular Alpha 8 still on WF 9 ! Message-ID: <10FB513D-3C53-404B-9DBB-C9D77D75A9A1@redhat.com> Hey, as this may be unclear: We will do the Hawkular 1 alpha 8 release on WF 9 (as before) and only move to WF 10 after the release - no matter if WF 10 will be released until then. Heiko From theute at redhat.com Fri Dec 11 04:20:44 2015 From: theute at redhat.com (Thomas Heute) Date: Fri, 11 Dec 2015 10:20:44 +0100 Subject: [Hawkular-dev] Monitoring Systems Article In-Reply-To: <127660885.26170917.1449674857244.JavaMail.zimbra@redhat.com> References: <883B2E3F-069E-4E8A-8D82-9C4B4F4DF7F9@redhat.com> <127660885.26170917.1449674857244.JavaMail.zimbra@redhat.com> Message-ID: +1 On Wed, Dec 9, 2015 at 4:27 PM, John Mazzitelli wrote: > I think we all agree that having an inventory with relationships between > components and their dependencies/dependents would be very helpful to > perform more intelligent alerting (e.g. if a database's write performance > is performing poorly, yes we can alert on the database resource, but any > application that uses that database for storage should go "yellow" to alert > the user that performance degradation is caused by the bad DB and that > storage failures could be on the horizon. Expand this further - you could > be monitoring a disk, see it is malfunctioning, and alert on all DBs using > that disk, which in turn can alert on all apps using that DB). > > Hawkular Inventory can already store those relationships in a graph, IF > those relationships are known. BUT! As i see it, it is the discovery of > those relationships that is the issue. > > Sure you can possibly auto-discover SOME relationships (e.g. we could look > at the definitions in WildFly configuration and relate those > databases to that WildFly application server), but many relationships are > difficult if not impossible to auto-detect. For example, how does the > WildFly agent know WHICH database resource to relate to its app server? How > does the DB resource in inventory (presumably created by another feed) get > known to the WF agent such that THAT DB gets related with THAT WF Server?). > In other words, feeds/agents won't know about the full inventory "universe" > to be able to create many relationships that you would think should be > obvious to them. > > We have Gary's BTM which could be the answer to some of this (his injected > monitoring code could be used to detect these relationships and > automatically tell inventory about them - but again, how does it know about > the full inventory identities of the resources it encounters to be able to > relate them together). > > I think we need a really good UI story to help users map these > relationships manually. The users will be able to tell us about these > "hidden" relationships - relationships that cannot be auto-discovered. But > it needs to be intuitive and easy to map out these relationships. > > ----- Original Message ----- > > Yes interesting, this is why I think the inventory is being an important > > element of monitoring. It's not enough to look at a single resource, we > need > > to look at how multiple resources are "connected". > > > > On Tue, Dec 8, 2015 at 4:15 PM, mike thompson < mithomps at redhat.com > > wrote: > > > > > > > > I thought this was an interesting article, especially around syntactic > > monitoring systems: > > > > > http://container-solutions.com/monitoring-performance-microservice-architectures/ > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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/20151211/1a33a08a/attachment.html From jkremser at redhat.com Fri Dec 11 07:41:43 2015 From: jkremser at redhat.com (Jiri Kremser) Date: Fri, 11 Dec 2015 07:41:43 -0500 (EST) Subject: [Hawkular-dev] Aggregated Hawkular REST api In-Reply-To: <1413441145.18252365.1449835687176.JavaMail.zimbra@redhat.com> Message-ID: <966485859.18256418.1449837703254.JavaMail.zimbra@redhat.com> Good news everyone, I was finally able to open the pull request [1] with first shot of the new rest api module for Hawkular. It's goal is to simplify the overall api, in which each component/microservice has very fine-grained api. Currently it can't do much. All it does is manipulation with URls, but if you look into our current UI code here: http://git.io/v0I9p the addUrl function takes 248 LoC. It's creating a resource, computing md5 hash, creating 2 metrics, creating bunch of triggers with dampenings and conditions. Quite a lot. The drawback with this approach, where UI layer works as an integration layer, was visible during the android client creation. Artur had no idea why he needs to mimic all the logic that was already there in JavaScript. Module uses the Hystrix library, because it seems to be a great fit for api aggregation. It's heavily rx-java based and it supports the Circuit Breaker pattern that can help if the components are under heavy load. Similarly, like rx-java it takes quite a while to wrap your head around the concepts of reactive streams, though. Hopefully, it's not an overkill. Perhaps we can even closer integrate with their metric features [2]. [1]: https://github.com/hawkular/hawkular/pull/704 [2]: https://github.com/Netflix/Hystrix/wiki/Metrics-and-Monitoring jk From jshaughn at redhat.com Fri Dec 11 09:20:13 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Fri, 11 Dec 2015 09:20:13 -0500 Subject: [Hawkular-dev] Hawkular build and -Dsrcdeps.forwardProperties Message-ID: <566ADB9D.5010504@redhat.com> For anyone trying to build Hawkular and running into checkstyle issues despite adding -Dcheckstyle.skip to the mvn command line, you may need to add this as well to make sure it makes it to the recursive builds... > mvn blahblah '-Dsrcdeps.forwardProperties=srcdeps.*,revapi.skip -Dcheckstyle.skip' p.s. the revapi.skip is not relevant to checkstyle but if you happen to hit a revapi issue it may help you out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151211/88ac30f4/attachment.html From mazz at redhat.com Tue Dec 15 10:12:44 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 15 Dec 2015 10:12:44 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <426979420.28842831.1450192081761.JavaMail.zimbra@redhat.com> Message-ID: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> I just released the wildfly agent (0.13.7.Final) and I just realized I may not have moved things up to the latest releases of its dependencies. It would be really nice now if we had something (even if its just versions in the parent pom) that defines the latest releases that components should be using because right now, how many of our pom.xml files have things like this: 1.1.1.Final 0.7.3.Final 0.10.4.Final 0.2.3.Final 0.9.0.Final 0.10.0.Final It would be nice if we aren't required to set these (but we could override them, right? if we want to try out a different version than what the parent pom defines). This would make releasing easier. We just comment out all the entries in all our pom.xml files (if they are there at all), thus falling back to what the parent-pom has defined. Or maybe we build a bom?? I dunno - all I know is, there is going to come a time when something breaks because "uh-oh, this component built on version x.y.z of metrics, but THIS component built on version a.b.c of metrics". From ppalaga at redhat.com Tue Dec 15 11:11:52 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 15 Dec 2015 17:11:52 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> Message-ID: <56703BC8.6000908@redhat.com> Hi Mazz, inline... On 2015-12-15 16:12, John Mazzitelli wrote: > I just released the wildfly agent (0.13.7.Final) and I just realized I may not have moved things up to the latest releases of its dependencies. > > It would be really nice now if we had something (even if its just versions in the parent pom) that defines the latest releases that components should be using because right now, how many of our pom.xml files have things like this: > > 1.1.1.Final > 0.7.3.Final > 0.10.4.Final > 0.2.3.Final > 0.9.0.Final > 0.10.0.Final Yes, every component in Hawkular has such a section of version.org.hawkular.* properties, but in each of the components the list is different, containing only the direct dependencies and nothing else. I cannot imagine how *all* these componets props could live in a single pom (hawkular-parent or a separate hawkular-bom) - such a BoM would inevitably bring circular dependency to most of places where it would be used. Say, the BoM version 0.0.1 would contain exactly the versions you listed above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I do not have to maintain commons and accounts. What do I do? I'll import dependencyManagement/dependency/BoM version 0.0.1. But then I have released Inventory 0.9.1.Final and I need to upgrade the prop in the BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? Maybe I misunderstood your idea? -- P > It would be nice if we aren't required to set these (but we could override them, right? if we want to try out a different version than what the parent pom defines). > > This would make releasing easier. We just comment out all the entries in all our pom.xml files (if they are there at all), thus falling back to what the parent-pom has defined. Or maybe we build a bom?? I dunno - all I know is, there is going to come a time when something breaks because "uh-oh, this component built on version x.y.z of metrics, but THIS component built on version a.b.c of metrics". > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Tue Dec 15 11:36:46 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 15 Dec 2015 17:36:46 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <56703BC8.6000908@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56703BC8.6000908@redhat.com> Message-ID: <5670419E.1000403@redhat.com> On 2015-12-15 17:11, Peter Palaga wrote: > Hi Mazz, inline... > > On 2015-12-15 16:12, John Mazzitelli wrote: >> I just released the wildfly agent (0.13.7.Final) and I just realized I may not have moved things up to the latest releases of its dependencies. To avoid improper deps, I have no better idea than opening the components dependency graph [1] before releasing and asking the colleagues working on components I depend on, whether they have (or plant to release) something new. @all Please make sure that the deps in the graph are correct so that components you depend upon know that you might be interested in their updates. The the source of the graph lives in [2] [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies [2] https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manually-generated/assets/img/docs/dev/components-dependencies.dot -- P >> >> It would be really nice now if we had something (even if its just versions in the parent pom) that defines the latest releases that components should be using because right now, how many of our pom.xml files have things like this: >> >> 1.1.1.Final >> 0.7.3.Final >> 0.10.4.Final >> 0.2.3.Final >> 0.9.0.Final >> 0.10.0.Final > > Yes, every component in Hawkular has such a section of > version.org.hawkular.* properties, but in each of the components the > list is different, containing only the direct dependencies and nothing else. > I cannot imagine how *all* these componets props could live in a single > pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > inevitably bring circular dependency to most of places where it would be > used. > > Say, the BoM version 0.0.1 would contain exactly the versions you listed > above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I > do not have to maintain commons and accounts. What do I do? I'll import > dependencyManagement/dependency/BoM version 0.0.1. But then I have > released Inventory 0.9.1.Final and I need to upgrade the prop in the > BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? > > Maybe I misunderstood your idea? > > -- P > >> It would be nice if we aren't required to set these (but we could override them, right? if we want to try out a different version than what the parent pom defines). >> >> This would make releasing easier. We just comment out all the entries in all our pom.xml files (if they are there at all), thus falling back to what the parent-pom has defined. Or maybe we build a bom?? I dunno - all I know is, there is going to come a time when something breaks because "uh-oh, this component built on version x.y.z of metrics, but THIS component built on version a.b.c of metrics". >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Tue Dec 15 14:41:48 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 15 Dec 2015 14:41:48 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <5670419E.1000403@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56703BC8.6000908@redhat.com> <5670419E.1000403@redhat.com> Message-ID: <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> [this is a long email - the summary of it is - we need to stop allowing individual components (agent, inventory, alerts, etc) to release with their own set of version properties defined in their pom.xml files - we need to pick up a common set of version properties from parent pom. Otherwise, we are forced to manually go through some dependency document (that may or may not be up to date) so we know which version properties in which pom.xml files to manually update so they are all the same value. We already have parent-pom that can do this kind of thing for us. Here's the long email:] > To avoid improper deps, I have no better idea than opening the > components dependency graph [1] before releasing and asking the > colleagues working on components I depend on, whether they have (or > plant to release) something new. > > @all Please make sure that the deps in the graph are correct so that > components you depend upon know that you might be interested in their updates. There has to be a better way than this. Forget a BOM for the moment, and consider this idea: In parent-pom, we already have a section with all our third party lib versions defined: https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231-L255 Can't we have a list of all our hawkular component versions in here too? Set them to the last stable release versions. For example, we could say, "These version properties in parent-pom define the latest versions (.Final or srcdeps) that we know the hawkular dist build (aka kettle) needs and therefore all components should be using": ... ... ... ... ... ... ... ... ...and the rest... Now, notice this doesn't mean every hawkular component is pulling in EVERY other component as a dependency. This is just defining version properties, that's all (just like every other version property in here). It is up to the individual components to define their as usual, but now they don't have to hardcode all their version properties in their poms, they can just fallback to using the properties as found in parent-pom and just make sure their parent-pom version is the latest. So, for example, the wildfly agent pom.xml already has this: org.hawkular.inventory hawkular-inventory-json-helper ${version.org.hawkular.inventory} org.hawkular.metrics hawkular-metrics-clients-common ${version.org.hawkular.metrics} .... and the rest of my hawkualr deps, like accounts, bus, etc... The difference is now my agent doesn't have to define those properties - I'll just use what parent pom has. I can delete all the properties defined in the agent pom. Alerts can do the same thing - in their pom, they don't define ${version.org.hawkular.bus} and all the rest, they just use what parent-pom defines. If agent and alerts are on the same parent pom, we immediately know they are using all the same hawkular component versions as well. Now the only thing we have to update across all components is just the parent pom version. Each component should be on the same parent-pom before we do a full hawkular release. No need to ask people to keep some dependency document up to date, no need to manually go through that dependency document (that may or may not be up to date) in order to know what to change in what component. Just make sure everyone is on the same parent pom and we will know everyone is using the same accounts, alerts, inventory, metrics, blah blah blah. During development time, if a component DOES want to use a different version, they can still define their own version properties in their own pom.xml temporarily, but this should be rare. Most times, all of us should be using the SAME stable release across all components ("stable release" could be a srcdep if we want) and that is what parent pom defines for us. In short, we should all be using the same versions unless during development we need a different version. But how do we ensure everyone is using the same version? Rely on parent-pom. The only thing we should then have to worry about when we release is everyone is using the same parent-pom (with the assumption no component is overriding the version properties; if they are, they need to comment them out before releasing). Personally, I think it is a major problem that we are all releasing our components individually with no way to ensure we are all releasing with the same component dependencies. We've all got properties defined in all our pom.xmls, and they are all wildly different sometimes (this one is using srcdep, this one is using 1.Final, this one 2.Final, etc...) And when we go to release, someone has to go to every pom.xml and look at every and make sure they are the same. Of course, all the time prior to that, we've been testing with old versions, mixed versions (agent is using inventory a.b.c, alerts is using x.y.x) and once we move to the new ones, we hit failures we weren't expecting (and you know this always happens the day before we do a major Hawkular release :) Instead, I say we rely more on parent-pom. If we all say, "Move to parent pom 27" - that's a one line change in our poms, and once we do we immediately know we are all on the same versions for all components. Don't want to move to 27 yet? Fall back to 26 and pick up the previous stuff. Want to override a particular component during development, pass in -Dversion.org.hawkular... or set that temporarily in your pom.xml file. ----- Original Message ----- > On 2015-12-15 17:11, Peter Palaga wrote: > > Hi Mazz, inline... > > > > On 2015-12-15 16:12, John Mazzitelli wrote: > >> I just released the wildfly agent (0.13.7.Final) and I just realized I may > >> not have moved things up to the latest releases of its dependencies. > > To avoid improper deps, I have no better idea than opening the > components dependency graph [1] before releasing and asking the > colleagues working on components I depend on, whether they have (or > plant to release) something new. > > @all Please make sure that the deps in the graph are correct so that > components you depend upon know that you might be interested in their > updates. The the source of the graph lives in [2] > > [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies > [2] > https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manually-generated/assets/img/docs/dev/components-dependencies.dot > > -- P > > >> > >> It would be really nice now if we had something (even if its just versions > >> in the parent pom) that defines the latest releases that components > >> should be using because right now, how many of our pom.xml files have > >> things like this: > >> > >> 1.1.1.Final > >> 0.7.3.Final > >> 0.10.4.Final > >> 0.2.3.Final > >> 0.9.0.Final > >> 0.10.0.Final > > > > Yes, every component in Hawkular has such a section of > > version.org.hawkular.* properties, but in each of the components the > > list is different, containing only the direct dependencies and nothing > > else. > > I cannot imagine how *all* these componets props could live in a single > > pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > > inevitably bring circular dependency to most of places where it would be > > used. > > > > Say, the BoM version 0.0.1 would contain exactly the versions you listed > > above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I > > do not have to maintain commons and accounts. What do I do? I'll import > > dependencyManagement/dependency/BoM version 0.0.1. But then I have > > released Inventory 0.9.1.Final and I need to upgrade the prop in the > > BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? > > > > Maybe I misunderstood your idea? > > > > -- P > > > >> It would be nice if we aren't required to set these (but we could override > >> them, right? if we want to try out a different version than what the > >> parent pom defines). > >> > >> This would make releasing easier. We just comment out all the > >> entries in all our pom.xml files (if they are there at all), thus falling > >> back to what the parent-pom has defined. Or maybe we build a bom?? I > >> dunno - all I know is, there is going to come a time when something > >> breaks because "uh-oh, this component built on version x.y.z of metrics, > >> but THIS component built on version a.b.c of metrics". > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.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 Tue Dec 15 16:29:53 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 15 Dec 2015 16:29:53 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56703BC8.6000908@redhat.com> <5670419E.1000403@redhat.com> <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> Message-ID: <866129798.29006458.1450214993064.JavaMail.zimbra@redhat.com> > > [this is a long email - the summary of it is - we need to stop allowing > individual components (agent, inventory, alerts, etc) to release with their > own set of version properties defined in their pom.xml files - we need to > pick up a common set of version properties from parent pom. Otherwise, we > are forced to manually go through some dependency document (that may or may > not be up to date) so we know which version properties in which pom.xml > files to manually update so they are all the same value. We already have > parent-pom that can do this kind of thing for us. Here's the long email:] > +1 Having these properties on parent might help to reduce the synchronization in a soft way. I see as a good alternative to test. From ppalaga at redhat.com Tue Dec 15 17:05:20 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Tue, 15 Dec 2015 23:05:20 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56703BC8.6000908@redhat.com> <5670419E.1000403@redhat.com> <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> Message-ID: <56708EA0.8050805@redhat.com> Hi Mazz, no, it cannot work. To consume the props from parent, you'd have to (1) release parent and (2) propagate the new parent version to all components. And once you (3) release any of the components, you'd have to (4) update the version prop in parent. But so that other components can consume it via parent you'd have to go to (1) and so on. If this is not clear enough, just try it for a dummy parent, three dummy components and a couple of releases of each component -- P On 2015-12-15 20:41, John Mazzitelli wrote: > [this is a long email - the summary of it is - we need to stop allowing individual components (agent, inventory, alerts, etc) to release with their own set of version properties defined in their pom.xml files - we need to pick up a common set of version properties from parent pom. Otherwise, we are forced to manually go through some dependency document (that may or may not be up to date) so we know which version properties in which pom.xml files to manually update so they are all the same value. We already have parent-pom that can do this kind of thing for us. Here's the long email:] > >> To avoid improper deps, I have no better idea than opening the >> components dependency graph [1] before releasing and asking the >> colleagues working on components I depend on, whether they have (or >> plant to release) something new. >> >> @all Please make sure that the deps in the graph are correct so that >> components you depend upon know that you might be interested in their updates. > > > There has to be a better way than this. Forget a BOM for the moment, and consider this idea: > > In parent-pom, we already have a section with all our third party lib versions defined: https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231-L255 > > Can't we have a list of all our hawkular component versions in here too? Set them to the last stable release versions. For example, we could say, "These version properties in parent-pom define the latest versions (.Final or srcdeps) that we know the hawkular dist build (aka kettle) needs and therefore all components should be using": > > ... > ... > ... > ... > ... > ... > ... > ... > ...and the rest... > > Now, notice this doesn't mean every hawkular component is pulling in EVERY other component as a dependency. This is just defining version properties, that's all (just like every other version property in here). It is up to the individual components to define their as usual, but now they don't have to hardcode all their version properties in their poms, they can just fallback to using the properties as found in parent-pom and just make sure their parent-pom version is the latest. So, for example, the wildfly agent pom.xml already has this: > > > org.hawkular.inventory > hawkular-inventory-json-helper > ${version.org.hawkular.inventory} > > > org.hawkular.metrics > hawkular-metrics-clients-common > ${version.org.hawkular.metrics} > > .... and the rest of my hawkualr deps, like accounts, bus, etc... > > The difference is now my agent doesn't have to define those properties - I'll just use what parent pom has. I can delete all the properties defined in the agent pom. > > Alerts can do the same thing - in their pom, they don't define ${version.org.hawkular.bus} and all the rest, they just use what parent-pom defines. If agent and alerts are on the same parent pom, we immediately know they are using all the same hawkular component versions as well. > > Now the only thing we have to update across all components is just the parent pom version. Each component should be on the same parent-pom before we do a full hawkular release. No need to ask people to keep some dependency document up to date, no need to manually go through that dependency document (that may or may not be up to date) in order to know what to change in what component. Just make sure everyone is on the same parent pom and we will know everyone is using the same accounts, alerts, inventory, metrics, blah blah blah. > > During development time, if a component DOES want to use a different version, they can still define their own version properties in their own pom.xml temporarily, but this should be rare. Most times, all of us should be using the SAME stable release across all components ("stable release" could be a srcdep if we want) and that is what parent pom defines for us. > > In short, we should all be using the same versions unless during development we need a different version. But how do we ensure everyone is using the same version? Rely on parent-pom. The only thing we should then have to worry about when we release is everyone is using the same parent-pom (with the assumption no component is overriding the version properties; if they are, they need to comment them out before releasing). > > Personally, I think it is a major problem that we are all releasing our components individually with no way to ensure we are all releasing with the same component dependencies. We've all got properties defined in all our pom.xmls, and they are all wildly different sometimes (this one is using srcdep, this one is using 1.Final, this one 2.Final, etc...) And when we go to release, someone has to go to every pom.xml and look at every and make sure they are the same. Of course, all the time prior to that, we've been testing with old versions, mixed versions (agent is using inventory a.b.c, alerts is using x.y.x) and once we move to the new ones, we hit failures we weren't expecting (and you know this always happens the day before we do a major Hawkular release :) > > Instead, I say we rely more on parent-pom. If we all say, "Move to parent pom 27" - that's a one line change in our poms, and once we do we immediately know we are all on the same versions for all components. Don't want to move to 27 yet? Fall back to 26 and pick up the previous stuff. Want to override a particular component during development, pass in -Dversion.org.hawkular... or set that temporarily in your pom.xml file. > > ----- Original Message ----- >> On 2015-12-15 17:11, Peter Palaga wrote: >>> Hi Mazz, inline... >>> >>> On 2015-12-15 16:12, John Mazzitelli wrote: >>>> I just released the wildfly agent (0.13.7.Final) and I just realized I may >>>> not have moved things up to the latest releases of its dependencies. >> >> To avoid improper deps, I have no better idea than opening the >> components dependency graph [1] before releasing and asking the >> colleagues working on components I depend on, whether they have (or >> plant to release) something new. >> >> @all Please make sure that the deps in the graph are correct so that >> components you depend upon know that you might be interested in their >> updates. The the source of the graph lives in [2] >> >> [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies >> [2] >> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manually-generated/assets/img/docs/dev/components-dependencies.dot >> >> -- P >> >>>> >>>> It would be really nice now if we had something (even if its just versions >>>> in the parent pom) that defines the latest releases that components >>>> should be using because right now, how many of our pom.xml files have >>>> things like this: >>>> >>>> 1.1.1.Final >>>> 0.7.3.Final >>>> 0.10.4.Final >>>> 0.2.3.Final >>>> 0.9.0.Final >>>> 0.10.0.Final >>> >>> Yes, every component in Hawkular has such a section of >>> version.org.hawkular.* properties, but in each of the components the >>> list is different, containing only the direct dependencies and nothing >>> else. >>> I cannot imagine how *all* these componets props could live in a single >>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would >>> inevitably bring circular dependency to most of places where it would be >>> used. >>> >>> Say, the BoM version 0.0.1 would contain exactly the versions you listed >>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I >>> do not have to maintain commons and accounts. What do I do? I'll import >>> dependencyManagement/dependency/BoM version 0.0.1. But then I have >>> released Inventory 0.9.1.Final and I need to upgrade the prop in the >>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? >>> >>> Maybe I misunderstood your idea? >>> >>> -- P >>> >>>> It would be nice if we aren't required to set these (but we could override >>>> them, right? if we want to try out a different version than what the >>>> parent pom defines). >>>> >>>> This would make releasing easier. We just comment out all the >>>> entries in all our pom.xml files (if they are there at all), thus falling >>>> back to what the parent-pom has defined. Or maybe we build a bom?? I >>>> dunno - all I know is, there is going to come a time when something >>>> breaks because "uh-oh, this component built on version x.y.z of metrics, >>>> but THIS component built on version a.b.c of metrics". >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Tue Dec 15 17:19:11 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 15 Dec 2015 17:19:11 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <56708EA0.8050805@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56703BC8.6000908@redhat.com> <5670419E.1000403@redhat.com> <482358195.28977316.1450208508404.JavaMail.zimbra@redhat.com> <56708EA0.8050805@redhat.com> Message-ID: <653161137.29020873.1450217951141.JavaMail.zimbra@redhat.com> Ahh... yes, circular. Hmmmm.... There has to be a better way than how we are doing it today. I can't believe there isn't some easier way to do this rather than having to manually synchronize every individual component so all of their version properties match each other. ----- Original Message ----- > Hi Mazz, no, it cannot work. To consume the props from parent, you'd > have to (1) release parent and (2) propagate the new parent version to > all components. And once you (3) release any of the components, you'd > have to (4) update the version prop in parent. But so that other > components can consume it via parent you'd have to go to (1) and so on. > If this is not clear enough, just try it for a dummy parent, three dummy > components and a couple of releases of each component -- P > > On 2015-12-15 20:41, John Mazzitelli wrote: > > [this is a long email - the summary of it is - we need to stop allowing > > individual components (agent, inventory, alerts, etc) to release with > > their own set of version properties defined in their pom.xml files - we > > need to pick up a common set of version properties from parent pom. > > Otherwise, we are forced to manually go through some dependency document > > (that may or may not be up to date) so we know which version properties in > > which pom.xml files to manually update so they are all the same value. We > > already have parent-pom that can do this kind of thing for us. Here's the > > long email:] > > > >> To avoid improper deps, I have no better idea than opening the > >> components dependency graph [1] before releasing and asking the > >> colleagues working on components I depend on, whether they have (or > >> plant to release) something new. > >> > >> @all Please make sure that the deps in the graph are correct so that > >> components you depend upon know that you might be interested in their > >> updates. > > > > > > There has to be a better way than this. Forget a BOM for the moment, and > > consider this idea: > > > > In parent-pom, we already have a section with all our third > > party lib versions defined: > > https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231-L255 > > > > Can't we have a list of all our hawkular component versions in here too? > > Set them to the last stable release versions. For example, we could say, > > "These version properties in parent-pom define the latest versions (.Final > > or srcdeps) that we know the hawkular dist build (aka kettle) needs and > > therefore all components should be using": > > > > ... > > ... > > ... > > ... > > ... > > ... > > ... > > ... > > ...and the rest... > > > > Now, notice this doesn't mean every hawkular component is pulling in EVERY > > other component as a dependency. This is just defining version properties, > > that's all (just like every other version property in here). It is up to > > the individual components to define their as usual, but now > > they don't have to hardcode all their version properties in their poms, > > they can just fallback to using the properties as found in parent-pom and > > just make sure their parent-pom version is the latest. So, for example, > > the wildfly agent pom.xml already has this: > > > > > > org.hawkular.inventory > > hawkular-inventory-json-helper > > ${version.org.hawkular.inventory} > > > > > > org.hawkular.metrics > > hawkular-metrics-clients-common > > ${version.org.hawkular.metrics} > > > > .... and the rest of my hawkualr deps, like accounts, bus, etc... > > > > The difference is now my agent doesn't have to define those properties - > > I'll just use what parent pom has. I can delete all the > > properties defined in the agent pom. > > > > Alerts can do the same thing - in their pom, they don't define > > ${version.org.hawkular.bus} and all the rest, they just use what > > parent-pom defines. If agent and alerts are on the same parent pom, we > > immediately know they are using all the same hawkular component versions > > as well. > > > > Now the only thing we have to update across all components is just the > > parent pom version. Each component should be on the same parent-pom before > > we do a full hawkular release. No need to ask people to keep some > > dependency document up to date, no need to manually go through that > > dependency document (that may or may not be up to date) in order to know > > what to change in what component. Just make sure everyone is on the same > > parent pom and we will know everyone is using the same accounts, alerts, > > inventory, metrics, blah blah blah. > > > > During development time, if a component DOES want to use a different > > version, they can still define their own version properties in their own > > pom.xml temporarily, but this should be rare. Most times, all of us should > > be using the SAME stable release across all components ("stable release" > > could be a srcdep if we want) and that is what parent pom defines for us. > > > > In short, we should all be using the same versions unless during > > development we need a different version. But how do we ensure everyone is > > using the same version? Rely on parent-pom. The only thing we should then > > have to worry about when we release is everyone is using the same > > parent-pom (with the assumption no component is overriding the version > > properties; if they are, they need to comment them out before releasing). > > > > Personally, I think it is a major problem that we are all releasing our > > components individually with no way to ensure we are all releasing with > > the same component dependencies. We've all got > > properties defined in all our pom.xmls, and they are all wildly different > > sometimes (this one is using srcdep, this one is using 1.Final, this one > > 2.Final, etc...) And when we go to release, someone has to go to every > > pom.xml and look at every and make sure they are > > the same. Of course, all the time prior to that, we've been testing with > > old versions, mixed versions (agent is using inventory a.b.c, alerts is > > using x.y.x) and once we move to the new ones, we hit failures we weren't > > expecting (and you know this always happens the day before we do a major > > Hawkular release :) > > > > Instead, I say we rely more on parent-pom. If we all say, "Move to parent > > pom 27" - that's a one line change in our poms, and once we do we > > immediately know we are all on the same versions for all components. Don't > > want to move to 27 yet? Fall back to 26 and pick up the previous stuff. > > Want to override a particular component during development, pass in > > -Dversion.org.hawkular... or set that temporarily in your pom.xml file. > > > > ----- Original Message ----- > >> On 2015-12-15 17:11, Peter Palaga wrote: > >>> Hi Mazz, inline... > >>> > >>> On 2015-12-15 16:12, John Mazzitelli wrote: > >>>> I just released the wildfly agent (0.13.7.Final) and I just realized I > >>>> may > >>>> not have moved things up to the latest releases of its dependencies. > >> > >> To avoid improper deps, I have no better idea than opening the > >> components dependency graph [1] before releasing and asking the > >> colleagues working on components I depend on, whether they have (or > >> plant to release) something new. > >> > >> @all Please make sure that the deps in the graph are correct so that > >> components you depend upon know that you might be interested in their > >> updates. The the source of the graph lives in [2] > >> > >> [1] > >> http://www.hawkular.org/docs/dev/development.html#component-dependencies > >> [2] > >> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manually-generated/assets/img/docs/dev/components-dependencies.dot > >> > >> -- P > >> > >>>> > >>>> It would be really nice now if we had something (even if its just > >>>> versions > >>>> in the parent pom) that defines the latest releases that components > >>>> should be using because right now, how many of our pom.xml files have > >>>> things like this: > >>>> > >>>> 1.1.1.Final > >>>> 0.7.3.Final > >>>> 0.10.4.Final > >>>> 0.2.3.Final > >>>> 0.9.0.Final > >>>> 0.10.0.Final > >>> > >>> Yes, every component in Hawkular has such a section of > >>> version.org.hawkular.* properties, but in each of the components the > >>> list is different, containing only the direct dependencies and nothing > >>> else. > >>> I cannot imagine how *all* these componets props could live in a single > >>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > >>> inevitably bring circular dependency to most of places where it would be > >>> used. > >>> > >>> Say, the BoM version 0.0.1 would contain exactly the versions you listed > >>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I > >>> do not have to maintain commons and accounts. What do I do? I'll import > >>> dependencyManagement/dependency/BoM version 0.0.1. But then I have > >>> released Inventory 0.9.1.Final and I need to upgrade the prop in the > >>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and so > >>> on? > >>> > >>> Maybe I misunderstood your idea? > >>> > >>> -- P > >>> > >>>> It would be nice if we aren't required to set these (but we could > >>>> override > >>>> them, right? if we want to try out a different version than what the > >>>> parent pom defines). > >>>> > >>>> This would make releasing easier. We just comment out all the > >>>> > >>>> entries in all our pom.xml files (if they are there at all), thus > >>>> falling > >>>> back to what the parent-pom has defined. Or maybe we build a bom?? I > >>>> dunno - all I know is, there is going to come a time when something > >>>> breaks because "uh-oh, this component built on version x.y.z of metrics, > >>>> but THIS component built on version a.b.c of metrics". > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev at lists.jboss.org > >>>> https://lists.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 lkrejci at redhat.com Tue Dec 15 17:38:22 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Tue, 15 Dec 2015 23:38:22 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <653161137.29020873.1450217951141.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56708EA0.8050805@redhat.com> <653161137.29020873.1450217951141.JavaMail.zimbra@redhat.com> Message-ID: <3358974.gp6mTXm7BB@localhost.localdomain> Actually, this does not imply circular workflow, just a painful one :) 1) I want to release a new version of inventory and decide what its version is gonna be. 2) I update parent POM with the new inventory version and release the parent POM. Note that at this point in time no one is using this version of parent and that inventory hasn't been released yet. 3) I update inventory with the new parent POM version and release it with the intended version. So to break the circle outlined by Peter, you have to basically introduce a race condition and also double the number of releases we do. Note that the above workflow would work with a BOM, too. On Tuesday, December 15, 2015 17:19:11 John Mazzitelli wrote: > Ahh... yes, circular. Hmmmm.... > > There has to be a better way than how we are doing it today. I can't believe > there isn't some easier way to do this rather than having to manually > synchronize every individual component so all of their version properties > match each other. > > ----- Original Message ----- > > > Hi Mazz, no, it cannot work. To consume the props from parent, you'd > > have to (1) release parent and (2) propagate the new parent version to > > all components. And once you (3) release any of the components, you'd > > have to (4) update the version prop in parent. But so that other > > components can consume it via parent you'd have to go to (1) and so on. > > If this is not clear enough, just try it for a dummy parent, three dummy > > components and a couple of releases of each component -- P > > > > On 2015-12-15 20:41, John Mazzitelli wrote: > > > [this is a long email - the summary of it is - we need to stop allowing > > > individual components (agent, inventory, alerts, etc) to release with > > > their own set of version properties defined in their pom.xml files - we > > > need to pick up a common set of version properties from parent pom. > > > Otherwise, we are forced to manually go through some dependency document > > > (that may or may not be up to date) so we know which version properties > > > in > > > which pom.xml files to manually update so they are all the same value. > > > We > > > already have parent-pom that can do this kind of thing for us. Here's > > > the > > > long email:] > > > > > >> To avoid improper deps, I have no better idea than opening the > > >> components dependency graph [1] before releasing and asking the > > >> colleagues working on components I depend on, whether they have (or > > >> plant to release) something new. > > >> > > >> @all Please make sure that the deps in the graph are correct so that > > >> components you depend upon know that you might be interested in their > > >> updates. > > > > > > There has to be a better way than this. Forget a BOM for the moment, and > > > consider this idea: > > > > > > In parent-pom, we already have a section with all our third > > > party lib versions defined: > > > https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231 > > > -L255 > > > > > > Can't we have a list of all our hawkular component versions in here too? > > > Set them to the last stable release versions. For example, we could say, > > > "These version properties in parent-pom define the latest versions > > > (.Final > > > or srcdeps) that we know the hawkular dist build (aka kettle) needs and > > > > > > therefore all components should be using": > > > ... > > > ... > > > ... > > > ... > > > ... > > > ... > > > ... > > > ... > > > ...and the rest... > > > > > > Now, notice this doesn't mean every hawkular component is pulling in > > > EVERY > > > other component as a dependency. This is just defining version > > > properties, > > > that's all (just like every other version property in here). It is up to > > > the individual components to define their as usual, but > > > now > > > they don't have to hardcode all their version properties in their poms, > > > they can just fallback to using the properties as found in parent-pom > > > and > > > just make sure their parent-pom version is the latest. So, for example, > > > > > > the wildfly agent pom.xml already has this: > > > > > > > > > org.hawkular.inventory > > > hawkular-inventory-json-helper > > > ${version.org.hawkular.inventory} > > > > > > > > > > > > > > > org.hawkular.metrics > > > hawkular-metrics-clients-common > > > ${version.org.hawkular.metrics} > > > > > > > > > .... and the rest of my hawkualr deps, like accounts, bus, etc... > > > > > > The difference is now my agent doesn't have to define those properties - > > > I'll just use what parent pom has. I can delete all the > > > properties defined in the agent pom. > > > > > > Alerts can do the same thing - in their pom, they don't define > > > ${version.org.hawkular.bus} and all the rest, they just use what > > > parent-pom defines. If agent and alerts are on the same parent pom, we > > > immediately know they are using all the same hawkular component versions > > > as well. > > > > > > Now the only thing we have to update across all components is just the > > > parent pom version. Each component should be on the same parent-pom > > > before > > > we do a full hawkular release. No need to ask people to keep some > > > dependency document up to date, no need to manually go through that > > > dependency document (that may or may not be up to date) in order to know > > > what to change in what component. Just make sure everyone is on the same > > > parent pom and we will know everyone is using the same accounts, alerts, > > > inventory, metrics, blah blah blah. > > > > > > During development time, if a component DOES want to use a different > > > version, they can still define their own version properties in their own > > > pom.xml temporarily, but this should be rare. Most times, all of us > > > should > > > be using the SAME stable release across all components ("stable release" > > > could be a srcdep if we want) and that is what parent pom defines for > > > us. > > > > > > In short, we should all be using the same versions unless during > > > development we need a different version. But how do we ensure everyone > > > is > > > using the same version? Rely on parent-pom. The only thing we should > > > then > > > have to worry about when we release is everyone is using the same > > > parent-pom (with the assumption no component is overriding the version > > > properties; if they are, they need to comment them out before > > > releasing). > > > > > > Personally, I think it is a major problem that we are all releasing our > > > components individually with no way to ensure we are all releasing with > > > the same component dependencies. We've all got > > > properties defined in all our pom.xmls, and they are all wildly > > > different > > > sometimes (this one is using srcdep, this one is using 1.Final, this one > > > 2.Final, etc...) And when we go to release, someone has to go to every > > > pom.xml and look at every and make sure they > > > are > > > the same. Of course, all the time prior to that, we've been testing with > > > old versions, mixed versions (agent is using inventory a.b.c, alerts is > > > using x.y.x) and once we move to the new ones, we hit failures we > > > weren't > > > expecting (and you know this always happens the day before we do a major > > > Hawkular release :) > > > > > > Instead, I say we rely more on parent-pom. If we all say, "Move to > > > parent > > > pom 27" - that's a one line change in our poms, and once we do we > > > immediately know we are all on the same versions for all components. > > > Don't > > > want to move to 27 yet? Fall back to 26 and pick up the previous stuff. > > > Want to override a particular component during development, pass in > > > -Dversion.org.hawkular... or set that temporarily in your pom.xml file. > > > > > > ----- Original Message ----- > > > > > >> On 2015-12-15 17:11, Peter Palaga wrote: > > >>> Hi Mazz, inline... > > >>> > > >>> On 2015-12-15 16:12, John Mazzitelli wrote: > > >>>> I just released the wildfly agent (0.13.7.Final) and I just realized > > >>>> I > > >>>> may > > >>>> not have moved things up to the latest releases of its dependencies. > > >> > > >> To avoid improper deps, I have no better idea than opening the > > >> components dependency graph [1] before releasing and asking the > > >> colleagues working on components I depend on, whether they have (or > > >> plant to release) something new. > > >> > > >> @all Please make sure that the deps in the graph are correct so that > > >> components you depend upon know that you might be interested in their > > >> updates. The the source of the graph lives in [2] > > >> > > >> [1] > > >> http://www.hawkular.org/docs/dev/development.html#component-dependencie > > >> s > > >> [2] > > >> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manu > > >> ally-generated/assets/img/docs/dev/components-dependencies.dot > > >> > > >> -- P > > >> > > >>>> It would be really nice now if we had something (even if its just > > >>>> versions > > >>>> in the parent pom) that defines the latest releases that components > > >>>> should be using because right now, how many of our pom.xml files have > > >>>> > > >>>> things like this: > > >>>> 1.1.1.Final > >>>> ar.accounts> > > >>>> 0.7.3.Final > >>>> s> > > >>>> 0.10.4.Final > >>>> .cmdgw> > > >>>> 0.2.3.Final > >>>> r.commons> > > >>>> 0.9.0.Final > >>>> lar.inventory> > > >>>> 0.10.0.Final > >>>> lar.metrics>> >>> > > >>> Yes, every component in Hawkular has such a section of > > >>> version.org.hawkular.* properties, but in each of the components the > > >>> list is different, containing only the direct dependencies and nothing > > >>> else. > > >>> I cannot imagine how *all* these componets props could live in a > > >>> single > > >>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > > >>> inevitably bring circular dependency to most of places where it would > > >>> be > > >>> used. > > >>> > > >>> Say, the BoM version 0.0.1 would contain exactly the versions you > > >>> listed > > >>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that > > >>> I > > >>> do not have to maintain commons and accounts. What do I do? I'll > > >>> import > > >>> dependencyManagement/dependency/BoM version 0.0.1. But then I have > > >>> released Inventory 0.9.1.Final and I need to upgrade the prop in the > > >>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and > > >>> so > > >>> on? > > >>> > > >>> Maybe I misunderstood your idea? > > >>> > > >>> -- P > > >>> > > >>>> It would be nice if we aren't required to set these (but we could > > >>>> override > > >>>> them, right? if we want to try out a different version than what the > > >>>> parent pom defines). > > >>>> > > >>>> This would make releasing easier. We just comment out all the > > >>>> > > >>>> entries in all our pom.xml files (if they are there at all), thus > > >>>> falling > > >>>> back to what the parent-pom has defined. Or maybe we build a bom?? I > > >>>> dunno - all I know is, there is going to come a time when something > > >>>> breaks because "uh-oh, this component built on version x.y.z of > > >>>> metrics, > > >>>> but THIS component built on version a.b.c of metrics". > > >>>> _______________________________________________ > > >>>> hawkular-dev mailing list > > >>>> hawkular-dev at lists.jboss.org > > >>>> https://lists.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 Tue Dec 15 17:50:59 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 15 Dec 2015 17:50:59 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <3358974.gp6mTXm7BB@localhost.localdomain> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56708EA0.8050805@redhat.com> <653161137.29020873.1450217951141.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> Message-ID: <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> > > Actually, this does not imply circular workflow, just a painful one :) > > 1) I want to release a new version of inventory and decide what its version > is > gonna be. > > 2) I update parent POM with the new inventory version and release the parent > POM. Note that at this point in time no one is using this version of parent > and that inventory hasn't been released yet. > > 3) I update inventory with the new parent POM version and release it with the > intended version. > > So to break the circle outlined by Peter, you have to basically introduce a > race condition and also double the number of releases we do. > > Note that the above workflow would work with a BOM, too. > Out of curiosity, then how other projects works ? Can we adopt some best practice to reduce our complexity ? There are projects using bom and parent, and they have versions on both. If at the end of the story, there is a manual step of synchronization (i.e. I have to go to a place a look which version I need), I would like to see if we can get benefit in someway without adding circular dependencies or painful process. With the srcdeps plugin, we added an additional feature that helped in a sense. Is there a possibility to sync some property versions without entering on the circular dependency ? I am brainstorming, but what about a repo where we put these versions, and we can have just a plugin to warn if we are using correct ones ? (without having to place it on parent). I.e. In alerts I'm using a parent X and bus Y, and this plugin can check from the repo that my versions are not updated. So, manual step is not avoid but we are warned that for alpha8 target versions are a,b,c. When I release a new alerts, I can update that in the repo. Thoughts ? From lkrejci at redhat.com Tue Dec 15 18:11:55 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Wed, 16 Dec 2015 00:11:55 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> Message-ID: <2839992.dMsD1SPuzU@localhost.localdomain> I think this might be it: http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote: > > Actually, this does not imply circular workflow, just a painful one :) > > > > 1) I want to release a new version of inventory and decide what its > > version > > is > > gonna be. > > > > 2) I update parent POM with the new inventory version and release the > > parent POM. Note that at this point in time no one is using this version > > of parent and that inventory hasn't been released yet. > > > > 3) I update inventory with the new parent POM version and release it with > > the intended version. > > > > So to break the circle outlined by Peter, you have to basically introduce > > a > > race condition and also double the number of releases we do. > > > > Note that the above workflow would work with a BOM, too. > > Out of curiosity, then how other projects works ? Can we adopt some best > practice to reduce our complexity ? > > There are projects using bom and parent, and they have versions on both. > > If at the end of the story, there is a manual step of synchronization (i.e. > I have to go to a place a look which version I need), I would like to see > if we can get benefit in someway without adding circular dependencies or > painful process. > > With the srcdeps plugin, we added an additional feature that helped in a > sense. > > Is there a possibility to sync some property versions without entering on > the circular dependency ? > > I am brainstorming, but what about a repo where we put these versions, and > we can have just a plugin to warn if we are using correct ones ? (without > having to place it on parent). > > I.e. In alerts I'm using a parent X and bus Y, and this plugin can check > from the repo that my versions are not updated. > > So, manual step is not avoid but we are warned that for alpha8 target > versions are a,b,c. > > When I release a new alerts, I can update that in the repo. > > Thoughts ? > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From lponce at redhat.com Tue Dec 15 18:37:25 2015 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 15 Dec 2015 18:37:25 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <2839992.dMsD1SPuzU@localhost.localdomain> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> <2839992.dMsD1SPuzU@localhost.localdomain> Message-ID: <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> > > I think this might be it: > > http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html > It is interesting. But perhaps we might need something ad-hoc, in the srcdeps spirit. For example, in the versions repo we can target the Alpha8 versions, i.e. accounts 1.1.4.Final, perhaps, accounts might have other upper releases 2.0.0.Final for WF10, but the plugin can warn me that I'm not using the 1.1.4.Final. Accounts would be responsible (or someone else) to put the right version on the "versions repo" (which can be just a properties file on github). So, we would work as today, but this non-intrusive plugin could help us to coordinate in some degree. > On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote: > > > Actually, this does not imply circular workflow, just a painful one :) > > > > > > 1) I want to release a new version of inventory and decide what its > > > version > > > is > > > gonna be. > > > > > > 2) I update parent POM with the new inventory version and release the > > > parent POM. Note that at this point in time no one is using this version > > > of parent and that inventory hasn't been released yet. > > > > > > 3) I update inventory with the new parent POM version and release it with > > > the intended version. > > > > > > So to break the circle outlined by Peter, you have to basically introduce > > > a > > > race condition and also double the number of releases we do. > > > > > > Note that the above workflow would work with a BOM, too. > > > > Out of curiosity, then how other projects works ? Can we adopt some best > > practice to reduce our complexity ? > > > > There are projects using bom and parent, and they have versions on both. > > > > If at the end of the story, there is a manual step of synchronization (i.e. > > I have to go to a place a look which version I need), I would like to see > > if we can get benefit in someway without adding circular dependencies or > > painful process. > > > > With the srcdeps plugin, we added an additional feature that helped in a > > sense. > > > > Is there a possibility to sync some property versions without entering on > > the circular dependency ? > > > > I am brainstorming, but what about a repo where we put these versions, and > > we can have just a plugin to warn if we are using correct ones ? (without > > having to place it on parent). > > > > I.e. In alerts I'm using a parent X and bus Y, and this plugin can check > > from the repo that my versions are not updated. > > > > So, manual step is not avoid but we are warned that for alpha8 target > > versions are a,b,c. > > > > When I release a new alerts, I can update that in the repo. > > > > Thoughts ? > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.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 Dec 16 04:18:58 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 16 Dec 2015 10:18:58 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <3358974.gp6mTXm7BB@localhost.localdomain> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <56708EA0.8050805@redhat.com> <653161137.29020873.1450217951141.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> Message-ID: <56712C82.1080409@redhat.com> On 2015-12-15 23:38, Lukas Krejci wrote: > Actually, this does not imply circular workflow, just a painful one :) > > 1) I want to release a new version of inventory and decide what its version is > gonna be. > > 2) I update parent POM with the new inventory version and release the parent > POM. Note that at this point in time no one is using this version of parent > and that inventory hasn't been released yet. > > 3) I update inventory with the new parent POM version and release it with the > intended version. > > So to break the circle outlined by Peter, you have to basically introduce a > race condition and also double the number of releases we do. > > Note that the above workflow would work with a BOM, too. As side note about BoM vs Parent: Properties defined in a BoM are not imported. Artifacts have to managed in BoMs so that the BoMs make any sense. -- P > On Tuesday, December 15, 2015 17:19:11 John Mazzitelli wrote: >> Ahh... yes, circular. Hmmmm.... >> >> There has to be a better way than how we are doing it today. I can't believe >> there isn't some easier way to do this rather than having to manually >> synchronize every individual component so all of their version properties >> match each other. >> >> ----- Original Message ----- >> >>> Hi Mazz, no, it cannot work. To consume the props from parent, you'd >>> have to (1) release parent and (2) propagate the new parent version to >>> all components. And once you (3) release any of the components, you'd >>> have to (4) update the version prop in parent. But so that other >>> components can consume it via parent you'd have to go to (1) and so on. >>> If this is not clear enough, just try it for a dummy parent, three dummy >>> components and a couple of releases of each component -- P >>> >>> On 2015-12-15 20:41, John Mazzitelli wrote: >>>> [this is a long email - the summary of it is - we need to stop allowing >>>> individual components (agent, inventory, alerts, etc) to release with >>>> their own set of version properties defined in their pom.xml files - we >>>> need to pick up a common set of version properties from parent pom. >>>> Otherwise, we are forced to manually go through some dependency document >>>> (that may or may not be up to date) so we know which version properties >>>> in >>>> which pom.xml files to manually update so they are all the same value. >>>> We >>>> already have parent-pom that can do this kind of thing for us. Here's >>>> the >>>> long email:] >>>> >>>>> To avoid improper deps, I have no better idea than opening the >>>>> components dependency graph [1] before releasing and asking the >>>>> colleagues working on components I depend on, whether they have (or >>>>> plant to release) something new. >>>>> >>>>> @all Please make sure that the deps in the graph are correct so that >>>>> components you depend upon know that you might be interested in their >>>>> updates. >>>> >>>> There has to be a better way than this. Forget a BOM for the moment, and >>>> consider this idea: >>>> >>>> In parent-pom, we already have a section with all our third >>>> party lib versions defined: >>>> https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231 >>>> -L255 >>>> >>>> Can't we have a list of all our hawkular component versions in here too? >>>> Set them to the last stable release versions. For example, we could say, >>>> "These version properties in parent-pom define the latest versions >>>> (.Final >>>> or srcdeps) that we know the hawkular dist build (aka kettle) needs and >>>> >>>> therefore all components should be using": >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ...and the rest... >>>> >>>> Now, notice this doesn't mean every hawkular component is pulling in >>>> EVERY >>>> other component as a dependency. This is just defining version >>>> properties, >>>> that's all (just like every other version property in here). It is up to >>>> the individual components to define their as usual, but >>>> now >>>> they don't have to hardcode all their version properties in their poms, >>>> they can just fallback to using the properties as found in parent-pom >>>> and >>>> just make sure their parent-pom version is the latest. So, for example, >>>> >>>> the wildfly agent pom.xml already has this: >>>> >>>> >>>> org.hawkular.inventory >>>> hawkular-inventory-json-helper >>>> ${version.org.hawkular.inventory} >>>> >>>> >>>> >>>> >>>> org.hawkular.metrics >>>> hawkular-metrics-clients-common >>>> ${version.org.hawkular.metrics} >>>> >>>> >>>> .... and the rest of my hawkualr deps, like accounts, bus, etc... >>>> >>>> The difference is now my agent doesn't have to define those properties - >>>> I'll just use what parent pom has. I can delete all the >>>> properties defined in the agent pom. >>>> >>>> Alerts can do the same thing - in their pom, they don't define >>>> ${version.org.hawkular.bus} and all the rest, they just use what >>>> parent-pom defines. If agent and alerts are on the same parent pom, we >>>> immediately know they are using all the same hawkular component versions >>>> as well. >>>> >>>> Now the only thing we have to update across all components is just the >>>> parent pom version. Each component should be on the same parent-pom >>>> before >>>> we do a full hawkular release. No need to ask people to keep some >>>> dependency document up to date, no need to manually go through that >>>> dependency document (that may or may not be up to date) in order to know >>>> what to change in what component. Just make sure everyone is on the same >>>> parent pom and we will know everyone is using the same accounts, alerts, >>>> inventory, metrics, blah blah blah. >>>> >>>> During development time, if a component DOES want to use a different >>>> version, they can still define their own version properties in their own >>>> pom.xml temporarily, but this should be rare. Most times, all of us >>>> should >>>> be using the SAME stable release across all components ("stable release" >>>> could be a srcdep if we want) and that is what parent pom defines for >>>> us. >>>> >>>> In short, we should all be using the same versions unless during >>>> development we need a different version. But how do we ensure everyone >>>> is >>>> using the same version? Rely on parent-pom. The only thing we should >>>> then >>>> have to worry about when we release is everyone is using the same >>>> parent-pom (with the assumption no component is overriding the version >>>> properties; if they are, they need to comment them out before >>>> releasing). >>>> >>>> Personally, I think it is a major problem that we are all releasing our >>>> components individually with no way to ensure we are all releasing with >>>> the same component dependencies. We've all got >>>> properties defined in all our pom.xmls, and they are all wildly >>>> different >>>> sometimes (this one is using srcdep, this one is using 1.Final, this one >>>> 2.Final, etc...) And when we go to release, someone has to go to every >>>> pom.xml and look at every and make sure they >>>> are >>>> the same. Of course, all the time prior to that, we've been testing with >>>> old versions, mixed versions (agent is using inventory a.b.c, alerts is >>>> using x.y.x) and once we move to the new ones, we hit failures we >>>> weren't >>>> expecting (and you know this always happens the day before we do a major >>>> Hawkular release :) >>>> >>>> Instead, I say we rely more on parent-pom. If we all say, "Move to >>>> parent >>>> pom 27" - that's a one line change in our poms, and once we do we >>>> immediately know we are all on the same versions for all components. >>>> Don't >>>> want to move to 27 yet? Fall back to 26 and pick up the previous stuff. >>>> Want to override a particular component during development, pass in >>>> -Dversion.org.hawkular... or set that temporarily in your pom.xml file. >>>> >>>> ----- Original Message ----- >>>> >>>>> On 2015-12-15 17:11, Peter Palaga wrote: >>>>>> Hi Mazz, inline... >>>>>> >>>>>> On 2015-12-15 16:12, John Mazzitelli wrote: >>>>>>> I just released the wildfly agent (0.13.7.Final) and I just realized >>>>>>> I >>>>>>> may >>>>>>> not have moved things up to the latest releases of its dependencies. >>>>> >>>>> To avoid improper deps, I have no better idea than opening the >>>>> components dependency graph [1] before releasing and asking the >>>>> colleagues working on components I depend on, whether they have (or >>>>> plant to release) something new. >>>>> >>>>> @all Please make sure that the deps in the graph are correct so that >>>>> components you depend upon know that you might be interested in their >>>>> updates. The the source of the graph lives in [2] >>>>> >>>>> [1] >>>>> http://www.hawkular.org/docs/dev/development.html#component-dependencie >>>>> s >>>>> [2] >>>>> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manu >>>>> ally-generated/assets/img/docs/dev/components-dependencies.dot >>>>> >>>>> -- P >>>>> >>>>>>> It would be really nice now if we had something (even if its just >>>>>>> versions >>>>>>> in the parent pom) that defines the latest releases that components >>>>>>> should be using because right now, how many of our pom.xml files have >>>>>>> >>>>>>> things like this: >>>>>>> 1.1.1.Final>>>>>> ar.accounts> >>>>>>> 0.7.3.Final>>>>>> s> >>>>>>> 0.10.4.Final>>>>>> .cmdgw> >>>>>>> 0.2.3.Final>>>>>> r.commons> >>>>>>> 0.9.0.Final>>>>>> lar.inventory> >>>>>>> 0.10.0.Final>>>>>> lar.metrics>> >>> >>>>>> Yes, every component in Hawkular has such a section of >>>>>> version.org.hawkular.* properties, but in each of the components the >>>>>> list is different, containing only the direct dependencies and nothing >>>>>> else. >>>>>> I cannot imagine how *all* these componets props could live in a >>>>>> single >>>>>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would >>>>>> inevitably bring circular dependency to most of places where it would >>>>>> be >>>>>> used. >>>>>> >>>>>> Say, the BoM version 0.0.1 would contain exactly the versions you >>>>>> listed >>>>>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that >>>>>> I >>>>>> do not have to maintain commons and accounts. What do I do? I'll >>>>>> import >>>>>> dependencyManagement/dependency/BoM version 0.0.1. But then I have >>>>>> released Inventory 0.9.1.Final and I need to upgrade the prop in the >>>>>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and >>>>>> so >>>>>> on? >>>>>> >>>>>> Maybe I misunderstood your idea? >>>>>> >>>>>> -- P >>>>>> >>>>>>> It would be nice if we aren't required to set these (but we could >>>>>>> override >>>>>>> them, right? if we want to try out a different version than what the >>>>>>> parent pom defines). >>>>>>> >>>>>>> This would make releasing easier. We just comment out all the >>>>>>> >>>>>>> entries in all our pom.xml files (if they are there at all), thus >>>>>>> falling >>>>>>> back to what the parent-pom has defined. Or maybe we build a bom?? I >>>>>>> dunno - all I know is, there is going to come a time when something >>>>>>> breaks because "uh-oh, this component built on version x.y.z of >>>>>>> metrics, >>>>>>> but THIS component built on version a.b.c of metrics". >>>>>>> _______________________________________________ >>>>>>> hawkular-dev mailing list >>>>>>> hawkular-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Wed Dec 16 04:35:03 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 16 Dec 2015 10:35:03 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> <2839992.dMsD1SPuzU@localhost.localdomain> <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> Message-ID: <56713047.4090201@redhat.com> The DependencyConvergence rule [1] we were discussing earlier on this list can partly solve the present problem. DependencyConvergence simply won't allow inconsistent set of deps. - I.e. it won't allow me to upgrade Accounts in Inventory unless there is the same version of Commons in both Accounts and Inventory. I say *partly* because DependencyConvergence will not say anything if my consistent set of deps is outdated. I will introduce DependencyConvergence after all components are upgraded to WF10. I still think that speaking with one's upstream before releasing is the most flexible and reliable way of solving the present problem. -- P [1] http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html [2] http://stackoverflow.com/a/16239482 On 2015-12-16 00:37, Lucas Ponce wrote: >> >> I think this might be it: >> >> http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html >> > > > It is interesting. But perhaps we might need something ad-hoc, in the srcdeps spirit. > > For example, in the versions repo we can target the Alpha8 versions, i.e. accounts 1.1.4.Final, perhaps, accounts might have other upper releases 2.0.0.Final for WF10, but the plugin can warn me that I'm not using the 1.1.4.Final. > > Accounts would be responsible (or someone else) to put the right version on the "versions repo" (which can be just a properties file on github). > > So, we would work as today, but this non-intrusive plugin could help us to coordinate in some degree. > > > > > >> On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote: >>>> Actually, this does not imply circular workflow, just a painful one :) >>>> >>>> 1) I want to release a new version of inventory and decide what its >>>> version >>>> is >>>> gonna be. >>>> >>>> 2) I update parent POM with the new inventory version and release the >>>> parent POM. Note that at this point in time no one is using this version >>>> of parent and that inventory hasn't been released yet. >>>> >>>> 3) I update inventory with the new parent POM version and release it with >>>> the intended version. >>>> >>>> So to break the circle outlined by Peter, you have to basically introduce >>>> a >>>> race condition and also double the number of releases we do. >>>> >>>> Note that the above workflow would work with a BOM, too. >>> >>> Out of curiosity, then how other projects works ? Can we adopt some best >>> practice to reduce our complexity ? >>> >>> There are projects using bom and parent, and they have versions on both. >>> >>> If at the end of the story, there is a manual step of synchronization (i.e. >>> I have to go to a place a look which version I need), I would like to see >>> if we can get benefit in someway without adding circular dependencies or >>> painful process. >>> >>> With the srcdeps plugin, we added an additional feature that helped in a >>> sense. >>> >>> Is there a possibility to sync some property versions without entering on >>> the circular dependency ? >>> >>> I am brainstorming, but what about a repo where we put these versions, and >>> we can have just a plugin to warn if we are using correct ones ? (without >>> having to place it on parent). >>> >>> I.e. In alerts I'm using a parent X and bus Y, and this plugin can check >>> from the repo that my versions are not updated. >>> >>> So, manual step is not avoid but we are warned that for alpha8 target >>> versions are a,b,c. >>> >>> When I release a new alerts, I can update that in the repo. >>> >>> Thoughts ? >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.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 Dec 16 04:42:38 2015 From: lponce at redhat.com (Lucas Ponce) Date: Wed, 16 Dec 2015 04:42:38 -0500 (EST) Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <56713047.4090201@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> <2839992.dMsD1SPuzU@localhost.localdomain> <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> <56713047.4090201@redhat.com> Message-ID: <761718577.29156718.1450258958326.JavaMail.zimbra@redhat.com> > > The DependencyConvergence rule [1] we were discussing earlier on this > list can partly solve the present problem. DependencyConvergence simply > won't allow inconsistent set of deps. - I.e. it won't allow me to > upgrade Accounts in Inventory unless there is the same version of > Commons in both Accounts and Inventory. I say *partly* because > DependencyConvergence will not say anything if my consistent set of deps > is outdated. > > I will introduce DependencyConvergence after all components are upgraded > to WF10. > > I still think that speaking with one's upstream before releasing is the > most flexible and reliable way of solving the present problem. > Yes, but I think that a plugin as described should help also. With DependencyConvergence we might have the commons versions correct but both components in a wrong (but same) version of accounts (for example). I think if we might mark the target versions and check that a module is using it (without updating parent/bom) it can help. Cons is that we need to create the plugin :-). > -- P > > [1] > http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html > [2] http://stackoverflow.com/a/16239482 > > > On 2015-12-16 00:37, Lucas Ponce wrote: > >> > >> I think this might be it: > >> > >> http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html > >> > > > > > > It is interesting. But perhaps we might need something ad-hoc, in the > > srcdeps spirit. > > > > For example, in the versions repo we can target the Alpha8 versions, i.e. > > accounts 1.1.4.Final, perhaps, accounts might have other upper releases > > 2.0.0.Final for WF10, but the plugin can warn me that I'm not using the > > 1.1.4.Final. > > > > Accounts would be responsible (or someone else) to put the right version on > > the "versions repo" (which can be just a properties file on github). > > > > So, we would work as today, but this non-intrusive plugin could help us to > > coordinate in some degree. > > > > > > > > > > > >> On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote: > >>>> Actually, this does not imply circular workflow, just a painful one :) > >>>> > >>>> 1) I want to release a new version of inventory and decide what its > >>>> version > >>>> is > >>>> gonna be. > >>>> > >>>> 2) I update parent POM with the new inventory version and release the > >>>> parent POM. Note that at this point in time no one is using this version > >>>> of parent and that inventory hasn't been released yet. > >>>> > >>>> 3) I update inventory with the new parent POM version and release it > >>>> with > >>>> the intended version. > >>>> > >>>> So to break the circle outlined by Peter, you have to basically > >>>> introduce > >>>> a > >>>> race condition and also double the number of releases we do. > >>>> > >>>> Note that the above workflow would work with a BOM, too. > >>> > >>> Out of curiosity, then how other projects works ? Can we adopt some best > >>> practice to reduce our complexity ? > >>> > >>> There are projects using bom and parent, and they have versions on both. > >>> > >>> If at the end of the story, there is a manual step of synchronization > >>> (i.e. > >>> I have to go to a place a look which version I need), I would like to see > >>> if we can get benefit in someway without adding circular dependencies or > >>> painful process. > >>> > >>> With the srcdeps plugin, we added an additional feature that helped in a > >>> sense. > >>> > >>> Is there a possibility to sync some property versions without entering on > >>> the circular dependency ? > >>> > >>> I am brainstorming, but what about a repo where we put these versions, > >>> and > >>> we can have just a plugin to warn if we are using correct ones ? (without > >>> having to place it on parent). > >>> > >>> I.e. In alerts I'm using a parent X and bus Y, and this plugin can check > >>> from the repo that my versions are not updated. > >>> > >>> So, manual step is not avoid but we are warned that for alpha8 target > >>> versions are a,b,c. > >>> > >>> When I release a new alerts, I can update that in the repo. > >>> > >>> Thoughts ? > >>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev at lists.jboss.org > >>> https://lists.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 Wed Dec 16 04:52:47 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 16 Dec 2015 10:52:47 +0100 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <56713047.4090201@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> <2839992.dMsD1SPuzU@localhost.localdomain> <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> <56713047.4090201@redhat.com> Message-ID: <5671346F.8090303@redhat.com> On 16.12.2015 10:35, Peter Palaga wrote: > I still think that speaking with one's upstream before releasing is the > most flexible and reliable way of solving the present problem. +1 . The problems discussed in this thread are, IMO, inherent to our modular design. I certainly don't want an update to Accounts to be propagated right away to all components, as a bug there might block someone in a downstream component. What I certainly would want is to have all components updated to the same accounts version by a given date. I'm still convinced that we need some sort of code freeze, or, at least, a component freeze, like any multi-module project with complex dependencies have, such as a Linux distribution. My suggestion (based on our current dependency graph): - Thursday before the release: Parent, Commons and Accounts - Friday before the release: Inventory, Metrics, BTM - Monday before the release: Command Gateway, Agent, Alerts - Tuesday (release day): Hawkular This should give us enough time to fix any last-minute issues. - Juca. From mazz at redhat.com Wed Dec 16 08:05:21 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 16 Dec 2015 08:05:21 -0500 (EST) Subject: [Hawkular-dev] agent inventory scan In-Reply-To: <1172203070.29210030.1450270572965.JavaMail.zimbra@redhat.com> Message-ID: <760686185.29212785.1450271121746.JavaMail.zimbra@redhat.com> I think I remember why I made the agent periodic inventory scan one hour :) Right now, every time the agent does a scan, it takes the newly discovered inventory and completely overwrites the old inventory with the new. It's the same scan the agent does at startup. This means (in the current implementation) if we discover 200 resources, we send all 200 to inventory (even if nothing changed!). Even though we try to use the inventory bulk/ REST API, we still send multiple requests (we end up splitting up into multiple bulk/ requests - might send 5 resources one time, 2 another, 10 another... its the way the current implementation works) and this means it takes a long time to finish. I haven't looked at the numbers recently, but it wouldn't surprise me if it takes longer than 10 minutes for the inventory bulk/ requests to finish. So changing the scan to happen every 10 minutes might mean the agent will continuously be sending bulk/ requests. The second problem is that when resources DO change, and the agent puts the already existing-but-changed resources in its inventory, when it sends those resources to hawkular-inventory via bulk/ those resources aren't updated. Inventory will see the resources already exist, and just return a 409 and not change anything. Lukas said he is going to change that behavior (such that when you send a resource to inventory it will do a create-or-update for the caller, rather than the caller do a double round trip (send a create, receive a 409, send an update, receive a 201). I don't know when that will be in place (Lukas?) but I don't think it works like that now. So what am I saying? Doing a periodic scan will really only benefit you if a NEW resource was added to the WF hierarchy. If one was updated (say, a resource configuration property value changed) the UI won't see that change because it never gets updated into inventory. I'm working on trying to figure out how to change the implementation to fix these problems. So right now, think we should keep the scan interval at 1 hour, unless we are doing a demo that needs to find new resources quickly. You can change that setting in "autoDiscoveryScanPeriodSecs" attribute in the agent's element in standalone.xml. Setting it to 0 disables auto-scans. From jpkroehling at redhat.com Wed Dec 16 09:35:19 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 16 Dec 2015 15:35:19 +0100 Subject: [Hawkular-dev] autoVersionSubmodules = true Message-ID: <567176A7.8010701@redhat.com> Team, Is anyone against setting the property autoVersionSubmodules to true in the parent? This property instructs maven to set the same version of "parent" (your parent, not Hawkular parent) to all sub modules, so, during release, there's only one question about "what's the version to be released?" and "what's the next development version", no matter how many sub modules you have. It seems that some of us already have it either on the pom.xml for the project (Inventory), while others use the property via CLI (-DautoVersionSubmodules=true). So, if nobody is against it, I'll send a PR by Friday to our parent setting this to true. - Juca. From ppalaga at redhat.com Wed Dec 16 09:37:53 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Wed, 16 Dec 2015 15:37:53 +0100 Subject: [Hawkular-dev] autoVersionSubmodules = true In-Reply-To: <567176A7.8010701@redhat.com> References: <567176A7.8010701@redhat.com> Message-ID: <56717741.9030007@redhat.com> +1 for having autoVersionSubmodules=true in hawkular-parent -- P On 2015-12-16 15:35, Juraci Paix?o Kr?hling wrote: > Team, > > Is anyone against setting the property autoVersionSubmodules to true in > the parent? This property instructs maven to set the same version of > "parent" (your parent, not Hawkular parent) to all sub modules, so, > during release, there's only one question about "what's the version to > be released?" and "what's the next development version", no matter how > many sub modules you have. > > It seems that some of us already have it either on the pom.xml for the > project (Inventory), while others use the property via CLI > (-DautoVersionSubmodules=true). > > So, if nobody is against it, I'll send a PR by Friday to our parent > setting this to true. > > - Juca. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From mazz at redhat.com Wed Dec 16 09:45:00 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 16 Dec 2015 09:45:00 -0500 (EST) Subject: [Hawkular-dev] autoVersionSubmodules = true In-Reply-To: <567176A7.8010701@redhat.com> References: <567176A7.8010701@redhat.com> Message-ID: <691411912.29269848.1450277100137.JavaMail.zimbra@redhat.com> +1 - I use it always (I use the -D command line option) ----- Original Message ----- > Team, > > Is anyone against setting the property autoVersionSubmodules to true in > the parent? This property instructs maven to set the same version of > "parent" (your parent, not Hawkular parent) to all sub modules, so, > during release, there's only one question about "what's the version to > be released?" and "what's the next development version", no matter how > many sub modules you have. > > It seems that some of us already have it either on the pom.xml for the > project (Inventory), while others use the property via CLI > (-DautoVersionSubmodules=true). > > So, if nobody is against it, I'll send a PR by Friday to our parent > setting this to true. > > - Juca. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From jshaughn at redhat.com Wed Dec 16 10:22:00 2015 From: jshaughn at redhat.com (Jay Shaughnessy) Date: Wed, 16 Dec 2015 10:22:00 -0500 Subject: [Hawkular-dev] is it time for a bom? or for version definitions in parent pom? In-Reply-To: <5671346F.8090303@redhat.com> References: <1894856649.28845719.1450192364754.JavaMail.zimbra@redhat.com> <3358974.gp6mTXm7BB@localhost.localdomain> <1661504558.29026960.1450219859181.JavaMail.zimbra@redhat.com> <2839992.dMsD1SPuzU@localhost.localdomain> <62919541.29032396.1450222645021.JavaMail.zimbra@redhat.com> <56713047.4090201@redhat.com> <5671346F.8090303@redhat.com> Message-ID: <56718198.5090805@redhat.com> I agree with Juca, I think this is going to be solved only with process. We are waiting until the last moments before a Hawkular release to make component releases and that is killing us. I don't think Juca's proposal goes far enough in that I think the release dates should be earlier; for base components, a week of planned quiet time prior to the hawkular release. Furthermore, I think the components are getting mature enough to stick to a release schedule. Now we, the developers, need to be mature enough to apply more discipline to what we are producing. * release dates should be in Jira, should be based on the next hawkular release, and should be reliable o jiras should have Fix versions assigned as best as possible to reflect what is going to be in the release o slips, breaking changes, etc must be made very public o stability should start to take precedence over refactoring/elegance * back compat/stability: it would be nice if a component/hawkular did not *have* to always upgrade to the latest version of a dependency. * updating hawkular pom with a srcdep version means hawkular requires the upcoming .Final release * srcdeps removed/.Final versions updated in the hawkular pom prior to hawkular milestone: o at least 7 days prior: parent, bus, commons, accounts, command gateway, o at least 5 days prior: inventory, alerts, metrics, agent, BTM (when it is incorporated) o at least one day prior: console On 12/16/2015 4:52 AM, Juraci Paix?o Kr?hling wrote: > On 16.12.2015 10:35, Peter Palaga wrote: >> I still think that speaking with one's upstream before releasing is the >> most flexible and reliable way of solving the present problem. > +1 . The problems discussed in this thread are, IMO, inherent to our > modular design. I certainly don't want an update to Accounts to be > propagated right away to all components, as a bug there might block > someone in a downstream component. What I certainly would want is to > have all components updated to the same accounts version by a given date. > > I'm still convinced that we need some sort of code freeze, or, at least, > a component freeze, like any multi-module project with complex > dependencies have, such as a Linux distribution. > > My suggestion (based on our current dependency graph): > - Thursday before the release: Parent, Commons and Accounts > - Friday before the release: Inventory, Metrics, BTM > - Monday before the release: Command Gateway, Agent, Alerts > - Tuesday (release day): Hawkular > > This should give us enough time to fix any last-minute issues. > > - Juca. > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151216/e525e58a/attachment-0001.html From hrupp at redhat.com Thu Dec 17 13:33:01 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Thu, 17 Dec 2015 19:33:01 +0100 Subject: [Hawkular-dev] Alpha 9 targets Message-ID: <7BB24983-859C-4202-8C16-4A6D8AA61155@redhat.com> Hey, I've added that at the bottom of [1]: we should concentrate on stabilizing the code base (fix bugs). Other tasks are: * More work on labels * Allow to use tokens all over the place * Move Hawkular onto WildFly 10 (if available ) * Finally address (and fix) availability handling Heiko [1] http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html From snegrea at redhat.com Fri Dec 18 10:37:02 2015 From: snegrea at redhat.com (Stefan Negrea) Date: Fri, 18 Dec 2015 10:37:02 -0500 (EST) Subject: [Hawkular-dev] versioning schema In-Reply-To: <63FEF80E-45CF-4E4C-A23D-8EA607D7C758@redhat.com> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> <159510705.6960208.1447250256816.JavaMail.zimbra@redhat.com> <63FEF80E-45CF-4E4C-A23D-8EA607D7C758@redhat.com> Message-ID: <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> Hello, Sorry for the late reply but .Final-SNAPSHOT is not good for many reasons. First, the page below [1] has an implicit version for -SNAPSHOT by the virtue of "major.minor.micro.TIMESTAMP-Mn". .Final or any other moniker added (eg. .Beta) after the actual version and before -SNAPSHOT, will break the versioning for the timed snapshots. Second, it really makes the -SNAPSHOT moniker obsolete, because we will never have .Beta-SNAPSHOT (or if we do we will confuse absolutely everybody). So we might as well not use .SNAPSHOT at all and switch to use exclusively the labels in the document. And third, it just makes the version unnecessarily long since it does not provide any more context to potential users. I totally agree with mandating the released version numbers to be in accordance with the JBoss standards. But let's keep the -SNAPSHOT version as short as possible (x.y.z-SNAPSHOT). [1] https://developer.jboss.org/wiki/JBossProjectVersioning ----- Original Message ----- > From: "Heiko W.Rupp" > To: "Discussions around Hawkular development" > Sent: Wednesday, November 11, 2015 8:36:30 AM > Subject: Re: [Hawkular-dev] versioning schema > > The mentioned link does not mention .Final-SNAPSHOT anywhere. > Either x.y.z-SNAPSHOT (which has other issues, as discussed) > or x.y.z-Final. > (but then it does not even mention SNAPSHOT :-). > > > On 11 Nov 2015, at 14:57, John Mazzitelli wrote: > > > I like and use x.y.z.Final-SNAPSHOT if only because the mvn release > > plugin sets that all automatically for you. You just hit at > > the prompts and go. If you use x.y.x-SNAPSHOT you have to remember to > > change the value of the version at the mvn release plugin prompt, > > which can lead to typos/fat-fingering the version string ;) > > > > Make it easy on ourselves - just use x.y.z.ABC-SNAPSHOT - and let the > > mvn release plugin automatically determine the versions for us. > > > > ----- Original Message ----- > >> Hello, > >> I'd like to ask about the policy we want to use for the versioning > >> schema. > >> I've raised a PR [1] that will check the project version and fails > >> the > >> build if it's wrong. This should catch the releases with malformed > >> versions. It's aligned with the JBoss project versioning [2], > >> however, > >> it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good > >> point > >> in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can > >> be > >> also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when > >> releasing, we > >> add the Final/Alpha, etc. > >> > >> Looking into wildfly repo, they use the former method. Is this what > >> we want? > >> I personally consider the latter method more natural and we use it in > >> the > >> inventory, despite the fact the hawkular/hawkular uses the > >> x.y.z.AlphaN-SNAPSHOT. > >> > >> jk > >> > >> > >> [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 > >> [2]: https://developer.jboss.org/wiki/JBossProjectVersioning > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, > Charlie Peters > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From lponce at redhat.com Fri Dec 18 11:17:30 2015 From: lponce at redhat.com (Lucas Ponce) Date: Fri, 18 Dec 2015 11:17:30 -0500 (EST) Subject: [Hawkular-dev] hawkular-alerts/master synced with Wildfly10 In-Reply-To: <1506478987.30575411.1450455359260.JavaMail.zimbra@redhat.com> Message-ID: <543416977.30575812.1450455450678.JavaMail.zimbra@redhat.com> Hello, We have sync-ed hawkular-alerts master branch and now it is based on Wildfly10. This branch uses for itests the distribution defined in accounts via feature packs and travis is ok with it. https://travis-ci.org/hawkular/hawkular-alerts/builds/97694344 Lucas From ppalaga at redhat.com Fri Dec 18 18:57:33 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Sat, 19 Dec 2015 00:57:33 +0100 Subject: [Hawkular-dev] versioning schema In-Reply-To: <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> <159510705.6960208.1447250256816.JavaMail.zimbra@redhat.com> <63FEF80E-45CF-4E4C-A23D-8EA607D7C758@redhat.com> <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> Message-ID: <56749D6D.3090204@redhat.com> Hi Stefan, inline... On 2015-12-18 16:37, Stefan Negrea wrote: > Hello, > > Sorry for the late reply but .Final-SNAPSHOT is not good for many reasons. Three is not many ;) > First, the page below [1] has an implicit version for -SNAPSHOT by the virtue of "major.minor.micro.TIMESTAMP-Mn". .Final or any other moniker added (eg. .Beta) after the actual version and before -SNAPSHOT, will break the versioning for the timed snapshots. My curiosity: What are timed SNAPSHOTs good for? Are you using them for something? > Second, it really makes the -SNAPSHOT moniker obsolete, because we will never have .Beta-SNAPSHOT (or if we do we will confuse absolutely everybody). Assuming "we" is the whole Hawkular (rather than Metrics alone): (1) we can well have .BetaN-SNAPSHOT, I have no problem with that. (2) 1.2.3.Beta1-SNAPSHOT is not confusing at all. It sets the proper expectation what the next release will be. It will namely be 1.2.3.Beta1 which says something important about the delivered quality. > So we might as well not use .SNAPSHOT at all and switch to use exclusively the labels in the document. And third, it just makes the version unnecessarily long since it does not provide any more context to potential users. It does add more info to potential users: It makes clear what the next release will be. > I totally agree with mandating the released version numbers to be in accordance with the JBoss standards. But let's keep the -SNAPSHOT version as short as possible (x.y.z-SNAPSHOT). The bottom line is, that the Alpha|Beta|CR|Final part was made optional for SNAPSHOT versions in HK parent [2]. I have no plans to propose to revert that change because what matters is the naming scheme for releases, which is defined separately [3] and that one is just OK. To add some context for those ones curious why I did [2]: There is a perf job at QA's Jenkins that expects .Final-less version strings in Metrics and I wanted my PR [4] not to be blocked by that and there seemed to exist nobody to fix the Jenkins job fast enough. [2] https://github.com/hawkular/hawkular-parent-pom/commit/aa917af4c2628a5660ff03a2290525db483efb46 [3] https://github.com/hawkular/hawkular-parent-pom/blob/31/pom.xml#L1046 [4] https://github.com/hawkular/hawkular-metrics/pull/418 -- P > [1] https://developer.jboss.org/wiki/JBossProjectVersioning > > ----- Original Message ----- >> From: "Heiko W.Rupp" >> To: "Discussions around Hawkular development" >> Sent: Wednesday, November 11, 2015 8:36:30 AM >> Subject: Re: [Hawkular-dev] versioning schema >> >> The mentioned link does not mention .Final-SNAPSHOT anywhere. >> Either x.y.z-SNAPSHOT (which has other issues, as discussed) >> or x.y.z-Final. >> (but then it does not even mention SNAPSHOT :-). >> >> >> On 11 Nov 2015, at 14:57, John Mazzitelli wrote: >> >>> I like and use x.y.z.Final-SNAPSHOT if only because the mvn release >>> plugin sets that all automatically for you. You just hit at >>> the prompts and go. If you use x.y.x-SNAPSHOT you have to remember to >>> change the value of the version at the mvn release plugin prompt, >>> which can lead to typos/fat-fingering the version string ;) >>> >>> Make it easy on ourselves - just use x.y.z.ABC-SNAPSHOT - and let the >>> mvn release plugin automatically determine the versions for us. >>> >>> ----- Original Message ----- >>>> Hello, >>>> I'd like to ask about the policy we want to use for the versioning >>>> schema. >>>> I've raised a PR [1] that will check the project version and fails >>>> the >>>> build if it's wrong. This should catch the releases with malformed >>>> versions. It's aligned with the JBoss project versioning [2], >>>> however, >>>> it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good >>>> point >>>> in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can >>>> be >>>> also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when >>>> releasing, we >>>> add the Final/Alpha, etc. >>>> >>>> Looking into wildfly repo, they use the former method. Is this what >>>> we want? >>>> I personally consider the latter method more natural and we use it in >>>> the >>>> inventory, despite the fact the hawkular/hawkular uses the >>>> x.y.z.AlphaN-SNAPSHOT. >>>> >>>> jk >>>> >>>> >>>> [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 >>>> [2]: https://developer.jboss.org/wiki/JBossProjectVersioning >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> -- >> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, >> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn >> Handelsregister: Amtsgericht M?nchen HRB 153243 >> Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, >> Charlie Peters >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From hrupp at redhat.com Mon Dec 21 06:28:53 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 21 Dec 2015 12:28:53 +0100 Subject: [Hawkular-dev] Root cause analysis Message-ID: <2ABDE37D-E657-48FE-9D6E-06504ED46389@redhat.com> Hi, came along that tweet: https://twitter.com/tobiasfrech/status/678858126414716928 Suppose this happens and we did record that the update was end of week 48 we could in an alert not only say "value X too high" [1] but also deduct that this is most likely due to the update. [1] Currently this depends on having an alert trigger correctly defined to alert if the value goes above the max of week 45..48. We may want to have alerts figure this out automatically via the data analysis from Pavol. From lkrejci at redhat.com Mon Dec 21 10:41:05 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 21 Dec 2015 16:41:05 +0100 Subject: [Hawkular-dev] versioning schema In-Reply-To: <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> <63FEF80E-45CF-4E4C-A23D-8EA607D7C758@redhat.com> <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> Message-ID: <4194888.CydmjL14Lz@localhost.localdomain> I personally don't care about snapshots at all. Over the time I've leaned towards Mazz's "least amount of work needed to get a release out" and just go with ".Final-SNAPSHOT" in inventory. It enables me to go mindlessly "next- next-finish" during the release process, which is a good thing - my mind cares much more about other things than the release numbers - and I don't have to type any with this approach. My experience with -SNAPSHOT is that it is not useful for anything but relating to other artifacts in between versions LOCALLY. Even using server- side timed snapshots is problematic IMHO and we're much better off using srcdeps for that. A -SNAPSHOT version IMHO doesn't even say what's the next version gonna be, because it would require the developers to know the future - it merely says what the devs think the next version might be. So in another words, I've lost too much time on this already. There's a much bigger fish to fry than -SNAPHOSTs. On Friday, December 18, 2015 10:37:02 Stefan Negrea wrote: > Hello, > > Sorry for the late reply but .Final-SNAPSHOT is not good for many reasons. > First, the page below [1] has an implicit version for -SNAPSHOT by the > virtue of "major.minor.micro.TIMESTAMP-Mn". .Final or any other moniker > added (eg. .Beta) after the actual version and before -SNAPSHOT, will break > the versioning for the timed snapshots. Second, it really makes the > -SNAPSHOT moniker obsolete, because we will never have .Beta-SNAPSHOT (or > if we do we will confuse absolutely everybody). So we might as well not use > .SNAPSHOT at all and switch to use exclusively the labels in the document. > And third, it just makes the version unnecessarily long since it does not > provide any more context to potential users. > > I totally agree with mandating the released version numbers to be in > accordance with the JBoss standards. But let's keep the -SNAPSHOT version > as short as possible (x.y.z-SNAPSHOT). > > > [1] https://developer.jboss.org/wiki/JBossProjectVersioning > > ----- Original Message ----- > > > From: "Heiko W.Rupp" > > To: "Discussions around Hawkular development" > > Sent: Wednesday, November 11, 2015 8:36:30 > > AM > > Subject: Re: [Hawkular-dev] versioning schema > > > > The mentioned link does not mention .Final-SNAPSHOT anywhere. > > Either x.y.z-SNAPSHOT (which has other issues, as discussed) > > or x.y.z-Final. > > (but then it does not even mention SNAPSHOT :-). > > > > On 11 Nov 2015, at 14:57, John Mazzitelli wrote: > > > I like and use x.y.z.Final-SNAPSHOT if only because the mvn release > > > plugin sets that all automatically for you. You just hit at > > > the prompts and go. If you use x.y.x-SNAPSHOT you have to remember to > > > change the value of the version at the mvn release plugin prompt, > > > which can lead to typos/fat-fingering the version string ;) > > > > > > Make it easy on ourselves - just use x.y.z.ABC-SNAPSHOT - and let the > > > mvn release plugin automatically determine the versions for us. > > > > > > ----- Original Message ----- > > > > > >> Hello, > > >> I'd like to ask about the policy we want to use for the versioning > > >> schema. > > >> I've raised a PR [1] that will check the project version and fails > > >> the > > >> build if it's wrong. This should catch the releases with malformed > > >> versions. It's aligned with the JBoss project versioning [2], > > >> however, > > >> it's not clear how to use the "-SNAPSHOT" suffix. Peter has a good > > >> point > > >> in the PR comment that some use the x.y.z.Final-SNAPSHOT (final can > > >> be > > >> also AlphaN, BetaN and CRN) and some x.y.z-SNAPSHOT and when > > >> releasing, we > > >> add the Final/Alpha, etc. > > >> > > >> Looking into wildfly repo, they use the former method. Is this what > > >> we want? > > >> I personally consider the latter method more natural and we use it in > > >> the > > >> inventory, despite the fact the hawkular/hawkular uses the > > >> x.y.z.AlphaN-SNAPSHOT. > > >> > > >> jk > > >> > > >> > > >> [1]: https://github.com/hawkular/hawkular-parent-pom/pull/54 > > >> [2]: https://developer.jboss.org/wiki/JBossProjectVersioning > > >> _______________________________________________ > > >> hawkular-dev mailing list > > >> hawkular-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > -- > > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > > Handelsregister: Amtsgericht M?nchen HRB 153243 > > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, > > Charlie Peters > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev From lkrejci at redhat.com Mon Dec 21 10:44:29 2015 From: lkrejci at redhat.com (Lukas Krejci) Date: Mon, 21 Dec 2015 16:44:29 +0100 Subject: [Hawkular-dev] versioning schema In-Reply-To: <4194888.CydmjL14Lz@localhost.localdomain> References: <1391149840.5683140.1447245759516.JavaMail.zimbra@redhat.com> <1392258887.38360928.1450453022764.JavaMail.zimbra@redhat.com> <4194888.CydmjL14Lz@localhost.localdomain> Message-ID: <16302220.ijuo3cmoPU@localhost.localdomain> On Monday, December 21, 2015 16:41:05 Lukas Krejci wrote: > bigger fish to fry than -SNAPHOSTs. See? I care so little about this I can't even spell it properly :) From mazz at redhat.com Tue Dec 22 12:06:39 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 22 Dec 2015 12:06:39 -0500 (EST) Subject: [Hawkular-dev] agent auto-scan, inventory update In-Reply-To: <1638991978.906705.1450803716934.JavaMail.zimbra@redhat.com> Message-ID: <2002427474.907752.1450803999711.JavaMail.zimbra@redhat.com> I think I finally got the agent working much better than before. In the past: 1) the agent would scan for inventory and once it got that inventory, that was it. It could never detect any new resources unless you restarted it 2) the agent would never detect changes to resource configuration properties even for resources it found on the original scan I think I fixed both now. The agent will scan periodically for new resources and add them to hawkular-inventory when it finds them. It will also detect if existing resources changed their resource configuration, if so, it will send those changed resources to hawkular-inventory. I also fixed it where it will no longer send the ENTIRE inventory EVERY scan. The agent will only send resources to inventory that are new or changed to the agent. All of this is in master. I wanted to release the agent with this new stuff, but I need h-inventory to do a release first (agent and command-gateway have srcdep dependencies on it). From mazz at redhat.com Tue Dec 22 12:44:42 2015 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 22 Dec 2015 12:44:42 -0500 (EST) Subject: [Hawkular-dev] agent auto-scan, inventory update In-Reply-To: <2002427474.907752.1450803999711.JavaMail.zimbra@redhat.com> References: <2002427474.907752.1450803999711.JavaMail.zimbra@redhat.com> Message-ID: <1269675905.918961.1450806282219.JavaMail.zimbra@redhat.com> Jiri released inventory - so i just released cmdgw (0.10.6.Final) and agent (0.15.0.Final) ----- Original Message ----- > I think I finally got the agent working much better than before. In the past: > > 1) the agent would scan for inventory and once it got that inventory, that > was it. It could never detect any new resources unless you restarted it > > 2) the agent would never detect changes to resource configuration properties > even for resources it found on the original scan > > I think I fixed both now. The agent will scan periodically for new resources > and add them to hawkular-inventory when it finds them. It will also detect > if existing resources changed their resource configuration, if so, it will > send those changed resources to hawkular-inventory. I also fixed it where it > will no longer send the ENTIRE inventory EVERY scan. The agent will only > send resources to inventory that are new or changed to the agent. > > All of this is in master. I wanted to release the agent with this new stuff, > but I need h-inventory to do a release first (agent and command-gateway have > srcdep dependencies on it). > _______________________________________________ > hawkular-dev mailing list > hawkular-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > From ppalaga at redhat.com Sat Dec 26 05:44:19 2015 From: ppalaga at redhat.com (Peter Palaga) Date: Sat, 26 Dec 2015 11:44:19 +0100 Subject: [Hawkular-dev] CanonicalPath should go to Commons Message-ID: <567E6F83.1010208@redhat.com> Hi *, esp. Luk??, Having org.hawkular.inventory.api.model.CanonicalPath in a separate maven module inside Hawkular Commons git repo would make the life easier for both Alerts and Command Gateway. For both Alerts and Command Gateway, CanonicalPath is the only class they need from Inventory. If CanonicalPath was hosted in Commons, both Alerts and Command Gateway could stop maintaining any dependency on Inventory and the overall dependency graph [1] could thus be made simpler. Luk??, I remember I asked about this earlier, but do not precisely remember what was your reason for the denial? [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies Thanks, Peter From mazz at redhat.com Sat Dec 26 23:19:09 2015 From: mazz at redhat.com (John Mazzitelli) Date: Sat, 26 Dec 2015 23:19:09 -0500 (EST) Subject: [Hawkular-dev] wildfly agent can remove resources now In-Reply-To: <1167975611.1805750.1451188389852.JavaMail.zimbra@redhat.com> Message-ID: <1891841045.1805892.1451189949653.JavaMail.zimbra@redhat.com> The Hawkular WildFly Agent can now remove resources from inventory. Today, you can remove datasources and jdbc drivers and (I think) deployments (though I actually haven't tested deployments yet). I just tested the removal of a datasource from the UI and it worked (though, has anyone noticed the websocket connectivity is flaky in the UI? sometimes it works, sometimes it doesn't). The agent is getting in much better shape now. In prior releases of the agent, if anything changed in inventory (like a resource configuration property changed its value or a new resource was added, or a resource was removed) you had to restart the agent to pick up the change. Now the agent has auto-discovery scans running periodically and can discovery and update inventory on the fly. In addition, I made the inventory management more efficient - each full scan will now only tell Hawkular-Inventory about things that changed since the last time the agent sent up inventory - so if you perform a scan every 10 minutes but nothing changes, nothing will go to hawkular-inventory (before, the agent would always send everything all over again even if nothing changed). I released the agent with all these enhancements - 0.15.1.Final. Hopefully people will get a chance to beat on it and tell me what I broke :) OK, *now* I'll start my vacation. :) --John Mazz