3:39 a.m.
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?
Regards,
Juan Hernandez
4:27 a.m.
On 29 May 2017, at 10:39, Juan Hernández <jhernand(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4:44 a.m.
On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> On 29 May 2017, at 10:39, Juan Hernández <jhernand(a)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
We need to make keep it backwards compatible or else tell users "don't
rely on these values, as they may change without notice".
The 'ovirt' gem doesn't do anything special, it just creates its own
code to name mapping. But the users of the 'ovirt' gem (the ManageIQ
oVirt provider) do rely on the name. For example:
https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/mode...
That means that if we ever change the meaning of a code the ManageIQ
provider, for example, will break.
>
> Regards,
> Juan Hernandez
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
2533
days inactive
2533
days old
2 comments
2 participants
participants (2)
-
Juan Hernández -
Michal Skrivanek