Currently events contain a description that is built a template and a set of properties added by the backend to the audit log object. For example, when a NIC is added to a virtual machine the generated event looks like this:

  <event href="/ovirt-engine/api/events/99" id="99">
    <description>Interface nic2 (VirtIO) was added to VM myvm. (User: admin@internal-authz)</description>
    <code>932</code>
    ...
    <vm href="/ovirt-engine/api/vms/34bc8a23-8749-481c-a67e-dd855960cf79" id="34bc8a23-8749-481c-a67e-dd855960cf79"/>
    ...
  </event>

Some applications need to extract certain details from that message, for example the name of the virtual machine. For a selected set of objects that information can be extracted from the links that are part of the event. For example, in the above example the user could follow the <vm ../> link to get the VM name. But this isn't always possible, as there may not be a link containing the required information. In that cases applications tend to parse the text message. For example, that is what ManageIQ currently does to extract the VM name:

  https://github.com/ManageIQ/manageiq/blob/fine-1/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L88

That is very fragile.

To better support these applications the API should provide the properties in easier and more reliable way:

  <event href="/ovirt-engine/api/events/99" id="99">
    <description>Interface nic2 (VirtIO) was added to VM myvm. (User: admin@internal-authz)</description>
    <code>932</code>
    <properties>
      <property>
        <name>nic_name</name>
        <value>nic2</value>
      </property>
      <property>
        <name>nic_interface</name>
        <value>VirtIO</value>
      </property>
      <property>
        <name>vm_name</name>
        <value>myvm</value>
      </property>
      <property>
        <name>user_name</name>
        <value>admin@internal-authz</value>
      </property>

    </properties>
    ...
  </event>

The set of properties available for each event type should be kept backwards compatible, and the names and meanings should be documented in the specification of the API.