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 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.

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 13:41, Juraci Paixão Kröhling wrote: So the clear suggestion and opinion here is to remove everything that is not absolutely required by the ManageIQ integration? -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

On 29.04.2016 14:49, Heiko W.Rupp wrote: Might be, I don't know. Here we cycle back to the question about the purpose. What's Hawkular's purpose? If our purpose is to "provide Middleware management to ManageIQ", then why not. There are so many interesting things to be done at Middleware management that it's a shame we'd spend so much time on other non-core stuff... - Juca.

On 29 Apr 2016, at 15:58, John Sanda wrote: You may have experienced in the past, that members of the community have helped tremendously with issues around Storage Nodes. For me such feedback is a big motivation.

On Fri, Apr 29, 2016 at 9:58 AM, John Sanda <jsanda(a)redhat.com&gt; wrote: It's hard to predict what the future will hold, but already we're providing middleware metrics to openshift, and will be providing MW mgmt to CF. There is also a shift happening with some of our long time customers to stop delivering packaged applications to their customers and transition to a SaaS model based upon subscriptions. If that is a trend, then hawkular, headless or not would be a valuable piece in our portfolio. I don't believe that "all management' will have to go through CF for all cases.

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.

On 29 Apr 2016, at 17:02, Gary Brown wrote: As the backend is accessed via frontend, all interaction via the frontend will use and "test" the backend. I don't think this implication is correct. I do not see why this is an either/or here. I still see a value in the Hawkular we have (without the App server) tab beyond the use case of Middleware Management in MiQ, but am not able to predict (to address Juca's questions) what users can come up with.