<div dir="ltr"><div>Just to update this on a public list:</div><div><br></div><div>When the event data is created, Cinder is setting the volume type as the volume type ID. On the other hand, the pollsters are always updating the volume_type value in Gnocchi, but for every event, this value is then updated back to the ID (it is like a "flight" between these two subsystems to see who updates the status last). The thing is that, deleted volumes are not polled. Therefore, the last update is executed by the event processing systems, which updates the value to the volume type ID. This explains why only deleted volumes were perceived with the volume type being set as the ID.</div><div><br></div><div>So, to fix it. We need to decide which "standard" we want to use. At first sight, it looks more natural (when integrating system-system via API) to use an ID, but for humans when accessing Cinder API, it might be better to see the volume type name instead. Because the API is publicly available, and we never know what consumes it, I would say that changing from volume type name to volume type ID can break things that we are not aware of. On the other hand, fixing the event data should not break anything because we know (hopefully) where that message is pushed to. <br></div><div><br></div><div>We decided to move on (internally), and fix the event creation code, and use the volume type name there. As soon as we finish internally, we will open a push upstream PR.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 6, 2019 at 5:22 AM Florian Engelmann <<a href="mailto:florian.engelmann@everyware.ch">florian.engelmann@everyware.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
some volumes are stored with the volume_type Id instead of the <br>
volume_type name:<br>
<br>
openstack metric resource history --details <br>
b5496a42-c766-4267-9248-6149aa9dd483 -c id -c revision_start -c <br>
revision_end -c instance_id -c volume_type<br>
+--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+<br>
| id                                   | revision_start  | revision_end <br>
                    | instance_id    | volume_type <br>
    |<br>
+--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+<br>
| b5496a42-c766-4267-9248-6149aa9dd483 | <br>
2019-05-08T07:21:35.354474+00:00 | 2019-05-21T09:18:32.767426+00:00 | <br>
662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std    |<br>
| b5496a42-c766-4267-9248-6149aa9dd483 | <br>
2019-05-21T09:18:32.767426+00:00 | 2019-05-21T09:18:32.845700+00:00 | <br>
662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std    |<br>
| b5496a42-c766-4267-9248-6149aa9dd483 | <br>
2019-05-21T09:18:32.845700+00:00 | None                             | <br>
662998da-c3d1-45c5-9120-2cff6240e3b6 | <br>
8bd7e1b1-3396-49bf-802c-8c31a9444895 |<br>
+--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+<br>
<br>
<br>
I was not able to find anything fishy in ceilometer. So I guess it could <br>
be some event/notification with a wrong payload?<br>
<br>
Could anyone please verify this error is not uniq to our (rocky) <br>
environment by running:<br>
<br>
openstack metric resource list --type volume  -c id -c volume_type<br>
<br>
<br>
All the best,<br>
Florian<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Rafael Weingärtner</div></div>