Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Missing implementation of message.get_all_records_where method #5169

Open
olivierlambert opened this issue Sep 4, 2023 · 6 comments
Open

Missing implementation of message.get_all_records_where method #5169

olivierlambert opened this issue Sep 4, 2023 · 6 comments

Comments

@olivierlambert
Copy link

Hello there,

We are working on various GUIs where it's imperative for us to retrieve a summary of all ALARM messages. Given the vast number of messages in our system (e.g., 10,000 messages in our test lab, of which only 30 are alarms), it's inefficient to fetch all messages and then filter out the ALARM type.

Upon reviewing the documentation, I found the get_all_records_where method. This appears to be exactly what we need. However, it seems either not implemented or non-functional.

Can you confirm if this is expected behavior? If so, would it be possible to implement it?
@robhoes
Copy link
Member

robhoes commented Sep 4, 2023

For most classes, these functions are auto-generated. However, messages are implemented differently, as they are not stored in the usual xapi DB, but directly in the file system as XML files (due to the volume). So this one may be missing, but it should be possible to implement it. See ocaml/xapi/xapi_message.ml.

@olivierlambert
Copy link
Author

Oh okay, so maybe I got it wrong: I thought the where clause was used to filter a property in the XAPI object (eg like the name which can be "ALARM".

But it seems you are telling me it's used to filter on the XML content of the message ie the body entry. Example:

# xe message-param-list uuid=5c128a5e-06c6-787f-4ab1-7f7f86ec74fa
uuid ( RO)         : 5c128a5e-06c6-787f-4ab1-7f7f86ec74fa
         name ( RO): ALARM
     priority ( RO): 3
        class ( RO): SR
     obj-uuid ( RO): 6e6ee285-0efe-63d8-c354-d5f760e4d96c
    timestamp ( RO): 20230328T14:46:01Z
         body ( RO): value: 1.0
config:
<variable>
<name value="physical_utilisation"/>
<alarm_trigger_level value="0.8"/>
<alarm_trigger_period value ="60"/>
</variable>

My concern is not filtering the body but the name directly, to only get the filtered results (I don't want to fetch 10,000 messages). So it might be another new method added in the message class then?

@robhoes
Copy link
Member

robhoes commented Sep 4, 2023

No, the body may or may not contain XML, it depends on the message. But the messages themselves, including the name etc, are stored as XML files. Look in /var/xapi/blobs/messages. Here's an example:

# xmllint --format /var/xapi/blobs/messages/VM/614f7739-e975-7447-e76f-b7099cffe2f0/1692885300.00000
<?xml version="1.0" encoding="UTF-8"?>
<message>
  <generation>45076</generation>
  <ref>OpaqueRef:5f4969f7-6417-1a14-b658-c531282cc5aa</ref>
  <name>VM_SHUTDOWN</name>
  <priority>5</priority>
  <cls>VM</cls>
  <obj_uuid>614f7739-e975-7447-e76f-b7099cffe2f0</obj_uuid>
  <timestamp>20230824T13:55:00Z</timestamp>
  <uuid>9b4f5e63-4b59-2365-fe4f-c3cd89fec9db</uuid>
  <body>VM 'win10-x64' (uuid: 614f7739-e975-7447-e76f-b7099cffe2f0) shutdown</body>
</message>

So you could implement a filter on name, priority etc.

@olivierlambert
Copy link
Author

Okay so what would the next recommended step:

  1. using the existing get_all_records_where to build that filter
  2. create a new method in the message class
  3. something else?

@robhoes
Copy link
Member

robhoes commented Sep 4, 2023

Make the existing function actually use the expression/filter.

@olivierlambert
Copy link
Author

Okay we might get back to you with some questions on the "right way" to implement that. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@robhoes @olivierlambert