[Hawkular-dev] communty distribution question

[Gary Brown]

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 -----
> 
> This relates to the "[Hawkular-dev] Future Packaging of Hawkular" thread. I
> started this thread to discuss a specific scenario that I don't know how to
> handle.
> 
> In addition to the components listed in that e-mail, there are a few other
> things in the Hawkular repo that weren't mentioned. For example, we have
> pinger and we have the inventory-event bus listener. I point out those two
> because I think they now exist solely to support the community UI. URL
> monitoring and Alert Center do not carry over to MIQ. With respect to the
> alert center we have out-of-box trigger definitions that are currently still
> active and are defined specifically to support the UI Alert center in
> Hawkular classic. And so we have a situation where code I would otherwise
> remove may need to exist to support the UI in the community distribution. Do
> we really want to keep a community-edition UI and the server-code that
> *only* supports what it does? If we remove it it will severely cripple the
> UI. But I fear that the UI will anyway quickly deteriorate unless we make
> concerted efforts to maintain compatible server code. Even today I think the
> UI is starting to falter. I'm not sure but when I tried to use the master
> version today to perform a deployment, it just hung.
> 
> So in line with Juca's questioning, what sort of effort do we put into the
> community UI? A lot, and keep it working as best as we can and ensure we
> mark server code that is relevant to community UI support? None, and just
> make the server code be the headless provider it needs to be to support MIQ,
> or something in the middle (which usually ends up being a waste of time).
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>