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(a)redhat.com>
> To: rhq-devel(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel