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).
>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 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 :) (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. 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 :) 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
