First of all, apologies if I am reiterating points already discussed, as I haven't had a chance to go through all emails in the thread as there was a lot to catch up on :) I agree that a middle solution is not really going to work, and could end up leaving community users with the impression that the project is not well supported. So the two options mentioned: 1) Fully supported community UI Issue here is that community users will be using capabilities, and a style of management UI, that may never be productised, so they may like the project but not be able to obtain a support subscription. 2) No community UI I think the problem we were looking to address here is making something easily consumable to help build the community. Now the decision has been made to unify management products, I think the community equivalent should be as close to the product as possible to better drive community participation to develop features that can move into the product. So, rather than having a single community UI/distribution, maybe we should focus on the separate deliverables we are looking to support, and see whether community support can be provided to make them easy to consume? So the community distributions could be: 1) The headless server with core services - so providing a community distribution of the server, with instructions on how to set up manageiq/provider. May not be straightforward initially, but this needs to be simplified for the benefit of both manageiq and other projects in Red Hat that are developing "providers". 2) Metrics (possibly with optional Alerts) server - provide a distribution and instructions on support with projects like grafana - so make it easy to get a complete solution up and running quickly 3) BTM - just provide a standalone community edition for now So at the moment I don't see a compelling reason for a fully integration community distribution with UI. Regards Gary ----- Original Message -----

On 29 Apr 2016, at 11:05, Juraci Paixão Kröhling wrote: As I said before: I believe that to be attractive for community, a product/project needs to pass the "I can get it initially going in 5 minutes" test. Which is/has been given before in all the Hawkular releases. And which will no longer be true for the hawkular-core-services, as the user needs to go through a number of additional steps to see something on screen: - install Cassandra - install some kind of UI (e.g. download + configure Grafana) - manually supply some data (curl, install wf+agent somewhere(*) I do not believe that "It was hard to create, so it should be hard to use" should be applied. Heiko *) this may still be provided inside core-services. But then as the Hawkular server is a black box, the detailed self-monitoring as we have today may change.

On 29.04.2016 12:00, Heiko W.Rupp wrote: From what I understand, we are maintaining a whole set of components, developing a web UI, building a separate assembler module, adding and integrating a big third-party component (Keycloak), just to make it easy for someone to use "hawkular-core-services" in a particular way. *This* is what is difficult for me to understand. I can't seem to accept that this 5 minutes test is a purpose, a "why". In the end, what people will see after this 5 minutes test is not what Hawkular is. All Hawkular releases so far had the purpose of being a monitoring platform. As a platform, our solution to the 5 minutes test was to add an embedded Cassandra and embedded Keycloak. That was our cost for the 5 minute test. Everything else was supposed to be part of the product: multi tenancy, BTM, Data Mining, charts and so on. To me, "hawkular-core-services" is essentially a data store. It is intended to be consumed by platforms "closer" to the end user, like OpenShift or MiQ. As such, I would expect as much of an UI to it as I would expect from, say, a PostgreSQL database server: I would certainly expect a way to manipulate and extract data, but I would *not* expect a full fledged user-friendly HTML5 snappy web UI. If our raison d'Être is around core-services, then having this "bloated" distribution is doing a disfavor: it dilutes the focus we have, it prevents developers from using the time on our core business and confuses people who first got in contact with Hawkular. More important than passing the 5 minute test is to clearly answer "what is this for and what can it do for me". And *this* is what I still don't understand. Nobody said that. - Juca.

On 29 Apr 2016, at 14:49, Heiko W.Rupp wrote: And going forward with this, as we only have 2 use cases going forward. - support ManageIQ - support Hawkular-Metrics Can we collapse the source into one or two source trees to save on all the integration / release / ... efforts? With the above there is no point in having any general purpose setup anymore.

Before making a decision one way or another, I agree with Juca that we need to answer the question, what is the purpose of Hawkular now? Do we really have legitimate reasons to invest the time, effort, and resources not needed for the ManageIQ integration? Maybe we do. I don’t know. And personally, I don’t think simply growing/supporting the community is very good motivation.

The community is very important to us - as discussed on the recent call, it is essential to get bake time in the community before project's are productised. But this is the key point - the community should be using the upstream version of what will be productised - not just the backend with a completely different front end. The (MiQ MW) UI is also an important part of the upstream project(s) that needs bake time and community user feedback - so it is essential that community users are able to easily setup and use MiQ+provider+headless server. If we are saying the only reason to have our own community distribution with hawkular specific UI is for ease of use, then it implies we don't care how complex our product is to setup. I think this is the wrong approach, we should use this difficulty in the current setup to motivate us to fix it rather than trying to avoid the issue. Regards Gary ----- Original Message -----

Yes the feedback was invaluable, but note the comparison. Storage nodes and RHQ in general had well-defined priorities around it. The things being discussed here no long have well-defined priorities. If maintaining this stuff for the sake of growing the community is reason enough, then why aren’t more of the former core RHQ devs still actively contributing to RHQ? The reason is very simple. It is no longer a priority.

Thanks for the insight. This is the kind of info I was looking for.

Where is this initially stated, I must have missed that. Knowing what the community/demo UI feature-set would be very helpful because that will indicate which hawkular back-end code to maintain, even if it is not needed for the hawkular provider.

On 28 Apr 2016, at 20:06, Jay Shaughnessy wrote: Which incidentally is part of the UI that we will remove from the community distribution anyway.