3:44 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev