Creating alert definitions with CLI

Michael Burman miburman at redhat.com
Tue Oct 14 14:37:07 UTC 2014


Hi,

As we talked on the IRC, the security should not be an issue. Currently 
our processes require MANAGE_ALERTS rights, and I was thinking about 
preserving that requirement (using the exact same cherkPermission method 
as the GUI).

As for the Notification-API, currently our REST-interface has an API 
with senderName (plugin-name) and config + extraConfig. For these 
notifications, creating a typed interface is next to impossible since 
different plugins could be created. So my plan was to create same sort 
of API here as well, but include in our remote-cli samples a JavaScript 
for some of the (or all) included server-plugins we currently ship. 
Technically there's no reason to avoid this for Java also and to throw 
exception if the sender plugin isn't available. For JS, the user could 
add their own helper methods if they have their own sender-plugins, but 
for Java this isn't possible in practise now.

In pseudu-code, meaning .sender("systemUser").add("username", 
"rhqadmin"); style as the normal API, but helper methods such as 
addNotification().helpers().systemNotifier().user("rhqadmin"); that 
would then return the Configuration (or throw exception is 
systemNotifier is not available in this installation).

   -  Micke


On 10/10/2014 04:42 PM, Lukas Krejci wrote:
> This looks quite OK but you're missing the 1 thing we choke upon when thinking
> about this before and that is the configuration of notifications.
>
> We need to figure out how to do that securely and user friendly (for example
> try doing the notification of "running a CLI script as a different user").
>
> ----- Original Message -----
>> From: "Michael Burman" <miburman at redhat.com>
>> To: rhq-devel at lists.fedorahosted.org
>> Sent: Friday, October 10, 2014 2:53:31 PM
>> Subject: Creating alert definitions with CLI
>>
>> Hi,
>>
>> About the long standing RFE (BZ 617202), I'd like to ask for your opinions.
>> I've done some work and a preliminary implementation that would make
>> creating definitions through CLI as close as possible to the GUI interface.
>> Now I would like to have some opinions, if I'm taking the right route and if
>> you have any wishes. I try to employ the builder-pattern in this case and I
>> tried to use existing domain-models (I haven't changed any existing ones to
>> preserve backwards compatibility) whenever it made sense.
>>
>> So here's the sort of query language I have in place now ("working" example):
>>
>>          AlertDefinitionTemplate template = new AlertDefinitionTemplate()
>>                  .enabled(true)
>>                  .description("description")
>>                  .name("name")
>>                  .priority(AlertPriority.MEDIUM)
>>                  .alertProtocol(BooleanExpression.ANY);
>>
>>          // Set recovery rules
>>          template.recovery()
>>                  .disableWhenFired(false);
>>
>>          // Set dampening rules
>>          template.dampening()
>>                  .category(AlertDampening.Category.CONSECUTIVE_COUNT)
>>                  .occurences(2);
>>
>>          // Add AlertConditions
>>          template.addCondition(AvailabilityCondition.class)
>>                  .availability(AlertConditionOperator.AVAIL_GOES_DOWN);
>>
>>          template.addCondition(AbsoluteValueCondition.class)
>>                  .comparator(AlertConditionOperator.GREATER_THAN)
>>                  .value(90.0)
>>                  .metric(11465);
>>
>> Function names might not be consistent yet in all cases (I've tried to keep
>> them short, but in some cases I couldn't think of very short descriptive
>> one). There's no PR yet for this.
>>
>>     - Micke
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list