[openstack-dev] [vitrage] [aodh] Error when creating 2 event alarms with the same name
ZhiQiang Fan
aji.zqfan at gmail.com
Tue May 3 15:04:43 UTC 2016
Alarm name unique constraint is only applied to each project, I don't
remember the original cause, but in our customer's environment, alarm will
be showed in the portal, with their name, no uuid, because user will be
confused about such a random like string, then if alarm name can be
duplicated, it is hard for them to differ between alarms.
So is there particular reason why you need to create duplicate name? can it
be something like event-alarm-{event_type}-{seq_number} ?
Anyway, it is not so hard to remove this constraint, I just want to say
that alarm name should be meaningful, otherwise it makes no difference with
UUID: not human friendly.
On Tue, May 3, 2016 at 10:30 PM, Weyl, Alexey (Nokia - IL) <
alexey.weyl at nokia.com> wrote:
> Hi,
>
> First of all, I wanted to thank again to all the participants in the
> fruitful Aodh-Vitrage design session in Austin :)
>
> I wanted to show in this email, the problem that we have when creating 2
> event alarms with the same name.
> Here is what I got in the command line:
>
> stack at ubuntu-devstack:/etc/vitrage$ ceilometer
> alarm-list
>
> +----------+------+-------+----------+---------+------------+-----------------+------------------+
> | Alarm ID | Name | State | Severity | Enabled | Continuous | Alarm
> condition | Time constraints |
>
> +----------+------+-------+----------+---------+------------+-----------------+------------------+
>
> +----------+------+-------+----------+---------+------------+-----------------+------------------+
>
> stack at ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name
> 'Event Alarm 2' --state alarm --event-type 'my.event'
> +---------------------------+--------------------------------------+
> | Property | Value |
> +---------------------------+--------------------------------------+
> | alarm_actions | [] |
> | alarm_id | 96f11384-abd7-4c11-b0a5-678646c11e79 |
> | description | Alarm when my.event event occurred. |
> | enabled | True |
> | event_type | my.event |
> | insufficient_data_actions | [] |
> | name | Event Alarm 2 |
> | ok_actions | [] |
> | project_id | bec13d47c22e45a9948981f5cb1ba45b |
> | query | [] |
> | repeat_actions | False |
> | severity | low |
> | state | alarm |
> | type | event |
> | user_id | d8812494489546aca8341af184eddd2c |
> +---------------------------+--------------------------------------+
>
> stack at ubuntu-devstack:/etc/vitrage$ ceilometer alarm-list
>
> +--------------------------------------+---------------+-------+----------+---------+------------+----------------------+------------------+
> | Alarm ID | Name | State | Severity
> | Enabled | Continuous | Alarm condition | Time constraints |
>
> +--------------------------------------+---------------+-------+----------+---------+------------+----------------------+------------------+
> | 96f11384-abd7-4c11-b0a5-678646c11e79 | Event Alarm 2 | alarm | low
> | True | False | query: [] | None |
> | | | |
> | | | event_type: my.event | |
>
> +--------------------------------------+---------------+-------+----------+---------+------------+----------------------+------------------+
>
> stack at ubuntu-devstack:/etc/vitrage$ ceilometer alarm-event-create --name
> 'Event Alarm 2' --state alarm --event-type 'my.event'
> Alarm with name='Event Alarm 2' exists (HTTP 409) (Request-ID:
> req-b05dd105-fd23-47d3-a0b6-940bde6bcdd8)
>
>
> Do you think it is possible to drop the uniqueness of the alarm name in
> Aodh (for the Vitrage use cases that we talked about in the design session)?
>
> Best regards,
> Alexey Weyl
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160503/3fa0e266/attachment.html>
More information about the OpenStack-dev
mailing list