Open Stack

On 16/12/2015 4:24 PM, Lu, Lianhao wrote:
> On Dec 16, 2015 14:13, Chris Dent wrote:
>> On Wed, 16 Dec 2015, Lu, Lianhao wrote:
>>
>>> In ceilometer, some metrics(e.g. network.incoming.bytes for VM net
>>> interface, hardware.network.incoming.bytes for host net interface,
>>> compute.node.cpu.percentage for nova compute node host cpu
>>> utilization,
>>> etc.) don't have their resource_id in UUID format(which is required
>>> by gnocchi). Instead, they have something like <id>.<interface_id> as
>>> their resource_id, in some cases even the <id> part won't be in uuid
>>> format. Gnocchi will treat these kind of resource_id as bad id, and
>>> build a new UUID format resource_id for them. Since users are mostly
>>> using resource_id to identify their resources, changing user passed
>>> in resource_id would require the users extra effort to identify the
>>> resources in gnocchi and link them with the resources they original
>>> passed in.
>> Just for the sake of completeness can you describe the use cases where
>> the resource_id translation that gnocchi does does not help the use
>> case. The one way translation is used in the body of search queries as
>> well as in any URL which contains a resource_id.
>>
>> I'm sure there are use cases where it breaks down, but I've not heard
>> them enumerated explicitly.
>>
> I'm not saying the translation will break down anything. It's just that in the case of using ceilometer/gnocchi together, when ceilometer samples are stored into gnocchi, the users need to do extra steps to figure out which resource to query to find its related metrics in the bad resource_id case. By simply looking at the http://docs.openstack.org/admin-guide-cloud/telemetry-measurements.html , the users can not easily identify the resource and its related metrics in gnocchi. The users need to be able to do a resource search based on resource attributes, such as original_resource_id, because in ceilometer/gnocchi cases, they don't get a chance to see the new resource_id gnocchi generated unless they search.
>
> Say we have configured nova to send out compute node metrics notification which will be turns into compute.node.cpu.percentage samples by ceilometer and stored into gnocchi, the original resource_id would be constructed as <nova compute host name>_<nova compute node name> of the nova compute node machine. But when admin want to search that resource in gnocchi, he either search for a specific new type of resource with some conditions or search for a generic resource with condition of original_resource_id="<nova compute host name>_<node name>", otherwise he doesn't have ways to find the resource which is identified by the original resource_id.
but when you query, you do use the original resource_id.  the 
translation happens on both writes and reads. while in reality, the db 
is will store a different id, users shouldn't really be aware of this.

that said, because of pecan, translations don't help when our ids have 
'/' in them... we should definitely fix that.

-- 
gord