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