Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter
On Thu, Nov 21, 2013 at 2:37 PM, Gordon Chung chu...@ca.ibm.com wrote: In all cases, these are free string fields. `user_id' and `project_id' map to Keystone _most of the time_, i'm sort of torn between the two -- which is why i brought it up i guess. i like the flexibility of having resource as a free string field but the difference between resource and project/user fields is that we can query directly on Resources. when we get a Resource, we get a list of associated Meters and if we don't set resource_id in a consistent manner, i worry we may be losing some relational information between Meters that groupings based off consistent resource_id can provide. The tuple (project id, source, resource id) is expected to be unique so that those values combined with a specific meter provide useful information about the resource. Beyond that unique constraint, I'm not sure we apply any rules, although check the SQL schema to make sure the resource id field isn't a short VARCHAR. Doug cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com ___ 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
Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter
On Wed, Nov 20 2013, Gordon Chung wrote: came across a question when reviewing https://review.openstack.org/#/c/56019... basically, in Samples, user_id and project_id attributes are pretty self-explanatory and map to Keystone concepts pretty well but what is the criteria for setting resource_id? maybe the ambiguity is that resource_id in a Sample is not the resource_id from Keystone... so what is it? is it just any UUID that is accessible from notification/response and if it is, is there a better (possibly more consistent) alternative? In all cases, these are free string fields. `user_id' and `project_id' map to Keystone _most of the time_, especially with samples emitted by Ceilometer itself. That can be false as soon as you send samples from external systems to Ceilometer. I don't have the feeling we should legislate on what a `resource_id`. -- Julien Danjou /* Free Software hacker * independent consultant http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter
In all cases, these are free string fields. `user_id' and `project_id' map to Keystone _most of the time_, i'm sort of torn between the two -- which is why i brought it up i guess. i like the flexibility of having resource as a free string field but the difference between resource and project/user fields is that we can query directly on Resources. when we get a Resource, we get a list of associated Meters and if we don't set resource_id in a consistent manner, i worry we may be losing some relational information between Meters that groupings based off consistent resource_id can provide. cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] meaning of resource_id in a meter
hi, for reference, this is a continuation of discussion from meeting: http://eavesdrop.openstack.org/meetings/ceilometer/2013/ceilometer.2013-11-20-21.00.log.html (see #topic what's a resource?) came across a question when reviewing https://review.openstack.org/#/c/56019... basically, in Samples, user_id and project_id attributes are pretty self-explanatory and map to Keystone concepts pretty well but what is the criteria for setting resource_id? maybe the ambiguity is that resource_id in a Sample is not the resource_id from Keystone... so what is it? is it just any UUID that is accessible from notification/response and if it is, is there a better (possibly more consistent) alternative? cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
