[Hawkular-dev] ManageIQ / Hawkular - some questions

[Gary Brown]

Hi Lucas

I would also be interested in understanding more about the Alerting mechanism.

Are you planning to do a feature comparison between Hawkular and ManageIQ in this area? i.e. does ManageIQ alerting support dampening etc.

>From the little I've seen of ManageIQ alerts at the moment, it appears driven by events (which I guess are identifying a situation to be reported) - but not clear how those events (i.e. the real trigger) is defined. Possibly this is where the split between responsibilities occurs, i.e. the provider (or underling manager) detects the situation, and then ManageIQ just provides a standard way to manage how that situation is used to inform/automate actions, etc.

I would like to understand how the metric data is analysed to detect alerts.

Regards
Gary


----- Original Message -----
> Hi,
> 
> As commented in the IRC I am going to prepare some questions about the
> $SUBJECT.
> 
> I have spent a couple of days reviewing ruby and starting to look into
> ManageIQ architecture where Hawkular will be a Middleware provider.
> 
> Some my preliminar doubts (perhaps this was discussed in a different thread,
> so please, point me to that if I missed it):
> 
> * Where will be stored metrics and inventory ?
> 
> That info should live in the provider (owner of that information) and copied
> to ManageIQ repository ? Or on the contrary, ManageIQ will be the owner of
> that info and the provider is a technical cache.
> 
> * How information of the providers is collected ?
> 
> In some preliminary meeting I understood that agents or whatever mechanism
> that collects information of the middleware domain should be sent to the
> provider. Is this valid ? or the architecture is that in the future all
> agents should be managed directly into ManageIQ ?
> 
> I guess that this is some kind of hybrid architecture as there will be always
> external provider (thinking on Amazon or other domain) that is managed by
> ManageIQ but the provider is the owner of the info.
> 
> * Alerting
> 
> This perhaps brings to me as I have personal interest on this topic.
> I see that ManageIQ has alerting features, so it can define alerts and group
> them in policies into resources in some way.
> >From what I see and related with the previous information, who is the owner
> >of the information ? provider or ManageIQ ?
> I can see that ManageIQ can be the owner of alerts definitions but perhaps
> the provider can have their own pre-configured alerts and feed ManageIQ.
> (I am thinking again in how this works for the Amazon model, I'm sure that
> Amazon cloud will have their own alerting definitions, perhaps an hybrid
> approach can be used here).
> 
> Also, I have the same doubt with Events, one of the major features of
> Hawkular Alerts was to manage events in a generic way, so, if the provider
> if the owner of the metrics/inventory it makes sense in a first approach
> that it can be the owner of some of middleware events (perhaps Events might
> have several meanings here, it happened to us in Hawkular and also with the
> ManageIQ integration that term should be revisit to be sure that we are
> talking about same concept).
> 
> * Roles
> 
> Are we going to provide strong role profiles ? for example a middleware role,
> that only can see the Middleware information without any access to
> cloud/infrastructure.
> 
> * API
> 
> One of the feedbacks I have heard from people about Hawkular and with
> experience with OpenShift/CloudForms is the use of the API to personalize
> and automate powerful tasks (for example, feeding events generated by an
> application, not just for the container).
> 
> How API should work in this case ? All API should be proxied/routed by
> ManageIQ or accesing to the provider API is valid ? (Again, thinking on
> external providers like Amazon makes me wonder what is the goal of this).
> 
> 
> I have more doubts (perhaps more related of the global architecture as I am
> not yet familiar with it) but I think these 5 topics are high level and it
> could help to understand better the context.
> 
> (Again, perhaps these ones are discussed/written in other thread, and are
> obvious, but I couldn't find them).
> 
> Thanks,
> Lucas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>