[ovirt-devel] Making event types backwards compatible?

[Michal Skrivanek]

> On 29 May 2017, at 10:39, Juan Hernández <jhernand at redhat.com> wrote:
> 
> Hello,
> 
> It has been recently requested that the API provides event types:
> 
>  [RFE] Expose event types to API
>  https://bugzilla.redhat.com/1453170
> 
> Currently the API provides the event code and description, for example:
> 
>  <event href="/ovirt-engine/api/events/8021" id="8021">
>    <code>19</code>
>    <description>Host myhost failed to recover.</description
>    ...
>  </event>
> 
> There is no documentation of what is the meaning of codes, except the
> source code of the engine itself. This forces some applications to add
> their own code to name mapping. For example, the 'ovirt' Ruby gem used
> by older versions of ManageIQ to interact with oVirt contains the following:
> 
>  https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> We could avoid this by adding to the API a new event attribute that
> indicates the type:
> 
>  <event href="/ovirt-engine/api/events/8021" id="8021">
>    <code>19</code>
>    <type>host_recover_failure</type>
>    <description>Host myhost failed to recover.</description>
>    ...
>  </event>
> 
> Ideally this should be defined as an enum, so that it will be
> represented as an enum in the SDKs. Alternatively it could just be an
> string, and we could reuse the 'name' attribute:
> 
>  <event href="/ovirt-engine/api/events/8021" id="8021">
>    <code>19</code>
>    <name>host_recover_failure</name>
>    <description>Host myhost failed to recover.</description>
>    ...
>  </event>
> 
> However, the key point to making this useful would be to keep the types
> (or names) backwards compatible, so that users of the API can rely on
> their values and meanings.
> 
> So this is my question to you: can we commit to keep the names and
> meanings of the backend event types backwards compatible?

Do we even have to make it bw compatible?
I guess it depends on the actual usage of those names…
The ovirt ruby gem itself doesn’t do much with it

Thanks,
michal

> 
> Regards,
> Juan Hernandez
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
>