<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 30, 2017 at 9:16 AM, Juan Hernández <span dir="ltr"><<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 05/30/2017 08:55 AM, Tomas Jelinek wrote:<br>
><br>
><br>
> On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek <<a href="mailto:mskrivan@redhat.com">mskrivan@redhat.com</a><br>
</span>> <mailto:<a href="mailto:mskrivan@redhat.com">mskrivan@redhat.com</a>>> wrote:<br>
<span class="gmail-">><br>
> > On 29 May 2017, at 11:44, Juan Hernández <<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> <mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>>> wrote:<br>
> ><br>
> >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:<br>
> >><br>
> >>> On 29 May 2017, at 10:39, Juan Hernández <<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a><br>
</span><div><div class="gmail-h5">> <mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>>> wrote:<br>
> >>><br>
> >>> Hello,<br>
> >>><br>
> >>> It has been recently requested that the API provides event types:<br>
> >>><br>
> >>> [RFE] Expose event types to API<br>
> >>> <a href="https://bugzilla.redhat.com/1453170" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>1453170</a><br>
> <<a href="https://bugzilla.redhat.com/1453170" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>1453170</a>><br>
> >>><br>
> >>> Currently the API provides the event code and description, for<br>
> example:<br>
> >>><br>
> >>> <event href="/ovirt-engine/api/<wbr>events/8021" id="8021"><br>
> >>> <code>19</code><br>
> >>> <description>Host myhost failed to recover.</description<br>
> >>> ...<br>
> >>> </event><br>
> >>><br>
> >>> There is no documentation of what is the meaning of codes,<br>
> except the<br>
> >>> source code of the engine itself. This forces some applications<br>
> to add<br>
> >>> their own code to name mapping. For example, the 'ovirt' Ruby<br>
> gem used<br>
> >>> by older versions of ManageIQ to interact with oVirt contains<br>
> the following:<br>
> >>><br>
> >>><br>
> <a href="https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485" rel="noreferrer" target="_blank">https://github.com/ManageIQ/<wbr>ovirt/blob/v0.17.0/lib/ovirt/<wbr>event.rb#L25-L485</a><br>
> <<a href="https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485" rel="noreferrer" target="_blank">https://github.com/ManageIQ/<wbr>ovirt/blob/v0.17.0/lib/ovirt/<wbr>event.rb#L25-L485</a>><br>
> >>><br>
> >>> We could avoid this by adding to the API a new event attribute that<br>
> >>> indicates the type:<br>
> >>><br>
> >>> <event href="/ovirt-engine/api/<wbr>events/8021" id="8021"><br>
> >>> <code>19</code><br>
> >>> <type>host_recover_failure</<wbr>type><br>
> >>> <description>Host myhost failed to recover.</description><br>
> >>> ...<br>
> >>> </event><br>
> >>><br>
> >>> Ideally this should be defined as an enum, so that it will be<br>
> >>> represented as an enum in the SDKs. Alternatively it could just<br>
> be an<br>
> >>> string, and we could reuse the 'name' attribute:<br>
> >>><br>
> >>> <event href="/ovirt-engine/api/<wbr>events/8021" id="8021"><br>
> >>> <code>19</code><br>
> >>> <name>host_recover_failure</<wbr>name><br>
> >>> <description>Host myhost failed to recover.</description><br>
> >>> ...<br>
> >>> </event><br>
> >>><br>
> >>> However, the key point to making this useful would be to keep<br>
> the types<br>
> >>> (or names) backwards compatible, so that users of the API can<br>
> rely on<br>
> >>> their values and meanings.<br>
> >>><br>
> >>> So this is my question to you: can we commit to keep the names and<br>
> >>> meanings of the backend event types backwards compatible?<br>
> >><br>
> >> Do we even have to make it bw compatible?<br>
> >> I guess it depends on the actual usage of those names…<br>
> >> The ovirt ruby gem itself doesn’t do much with it<br>
> ><br>
> > We need to make keep it backwards compatible or else tell users "don't<br>
> > rely on these values, as they may change without notice".<br>
> ><br>
> > The 'ovirt' gem doesn't do anything special, it just creates its own<br>
> > code to name mapping. But the users of the 'ovirt' gem (the ManageIQ<br>
> > oVirt provider) do rely on the name. For example:<br>
> ><br>
> ><br>
> > <a href="https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92" rel="noreferrer" target="_blank">https://github.com/ManageIQ/<wbr>manageiq-providers-ovirt/blob/<wbr>master/app/models/manageiq/<wbr>providers/redhat/infra_<wbr>manager/event_parser.rb#L80-<wbr>L92</a><br>
> <<a href="https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92" rel="noreferrer" target="_blank">https://github.com/ManageIQ/<wbr>manageiq-providers-ovirt/blob/<wbr>master/app/models/manageiq/<wbr>providers/redhat/infra_<wbr>manager/event_parser.rb#L80-<wbr>L92</a>><br>
><br>
><br>
> hmmm, while we are on topic, this pretty much looks like that manageiq<br>
> does not only rely on the code but also on the actual value of it since<br>
> it is parsing it:<br>
><br>
> # sample message: "Interface nic1 (VirtIO) was added to VM v5. (User:<br>
> admin@internal-authz)" message.split(/\s/)[7][0...-1]<br>
><br>
> Is this something we commit to maintain? Or should we commit to maintain it?<br>
><br>
<br>
</div></div>That is a good point, that isn't very future proof. We should also find<br>
a way to make less fragile. Any suggestion?<br></blockquote><div><br></div><div>The only doable thing which comes to my mind is something like this:<br></div><div>The msg is defined like this:<br>USER_ADD_VM_POOL_WITH_VMS_FAILED=Failed to create VM Pool ${VmPoolName} (User: ${UserName}).<br><br></div><div>e.g. the msg type and the variables. If we could expose in the api not only the substituted msg but also the variable/value binding, we could commit to keep the variable names backward compatible.<br><br></div><div>So, something like:<br><br><event href="/ovirt-engine/api/<wbr>events/8021" id="8021"><br> <code>19</code><br>
<type>USER_ADD_VM_POOL_WITH_VMS_FAILED</<wbr>type><br> <description>the substituted msg.</description><br></div><div> <parameters><br></div><div> <parameter><br></div><div> <key>VmPoolName</key><br> <value>The Pool Name<value></div><div> </parameter><br>...<br></div><div> </parameters></div><div>
</event></div><div> <br></div><div>Not really rock solid since the variables would still be defined in the AuditLogMessages.properties but still better and still easier to parse on the client side.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
><br>
> ><br>
> > That means that if we ever change the meaning of a code the ManageIQ<br>
> > provider, for example, will break.<br>
><br>
> Right,then it indeed needs to stay stable.<br>
> But how is maintaining the enum string different from the code? It is<br>
> the same information, so if MIQ doesn't use the name directly then it<br>
> doesn't really matter if it's a code or string.<br>
> Perhaps deprecate the code and keep the name fixed?<br>
><br>
> Thanks,<br>
> michal<br>
><br>
> ><br>
> >>><br>
> >>> Regards,<br>
> >>> Juan Hernandez<br>
> >>><br>
> >>><br>
> >>> ______________________________<wbr>_________________<br>
> >>> Devel mailing list<br>
</span>> >>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> <mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>><br>
> >>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
<span class="gmail-">> <<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a>><br>
> ><br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
</span>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> <mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
> <<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a>><br>
><br>
><br>
<br>
</blockquote></div><br></div></div>