Hello guys,
I was taking a look at the proposed alarm-page designs [1] for the bp:
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
and I saw that the alarms table has a column named “Resource Name”. The
intention of that column is to show the resources associated within an alarm
(also for the case of more complex alarms or “combined alarm” if you prefer)
but right now, ceilometer does only retrieve the associated resources id’s
inside the “query” param (at least, for the threshold alarms, in the case of
combined alarms you won’t get any resource id).
I don't really understand what you're getting at with ...
ceilometer does only retrieve the associated resources id’s inside
the “query” param
But I'll take a guess that you're concerned that ceilometer doesn't
map eagerly from resource ID to resource names?
Ok, let's back up a bit here and level-set ...
* A ceilometer alarm *may* include a resource-based constraint
* The resource-based constraint *may* be based on a resource ID,
or else on any other aspect of resource metadata that ceilometer
persists (e.g. in the case of a Heat autoscaling alarm, resource
ID wouldn't even enter into the equation, instead a group of
instances is referred to via their common user metadata)
* Either way, the resource constraint isn't evaluated until the
stats query underpinning the alarm is evaluated
* It has to work this way, as for a start the set of matching
resources may be different at the time the alarm is evaluated
as compared to when the alarm was defined
From the Horizon POV, getting the resource name represents a lot of work and
a huge impact in performance because, if we choose to show this “Resource
Name” column, we would need to do, for each alarm retrieved :
1. Check the query parameter and then extract the resource id
Note the resource ID is not a required constraint. Not all alarms will
include this constraint. So it shouldn't be assumed in the UI.
2. Then, depending on the type of resource (because it could be a vm, an
image, etc.) ask for its name to the appropriate service (not sure if that
is right way of doing it)
3. Save that name and then show it on the UI
In the case of combined alarms, not only we’ll have to do all that but also:
· Extract the alarms_ids used for the alarm combination (which can be also
combined alarms, so take that into account)
· For each threshold alarm, run previous 1-3 steps
o In case of step 3, instead of show the name to the UI, store it into a list
of resource names that needs to be showed after finishing the processing
As you can see, for an alarm table of, let’s say 10 combined alarms (which it
could be a valid use case), we would need to do one call to alarm-list, 20
calls to alarm-shows and then other 20 calls to each of the service that
could give us the name of the resources.
I’m seeing a couple of possible solutions:
1) not rendering the “Resource name” column J (not actually an option)
a. but I know it is the “coward” solution and I also know that showing and
filtering alarms based on resources it’s a good and necessary feature.
This seems like the only sane solution IIUC, because as stated above there
is *no assumption* of a 1:1 mapping between alarms and resources.
Let me know if I've misunderstood what you're getting at here,
Cheers,
Eoghan
2) Expose the resource_id as we do with “meter_name”, although we still need
to ask for the resource name on the horizon side
a. For the combined alarms, expose a list of resources and (why not) a list
of meter associated with the combined alarms.
3) Save the resource id in the alarm table in a separated column and then
retrieve it
a. For combined alarms, save a list of resource_id’s?
4) Any solution that you consider J
Any thoughts around this?
Thanks for all the help!
Christian
[1]:
http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-06-05.pdf
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
