Re: [ovirt-devel] Making event types backwards compatible?

[Moti Asayag]

On Tue, May 30, 2017 at 11:28 AM, Juan Hernández 
wrote:

> On 05/30/2017 09:38 AM, Tomas Jelinek wrote:
> >
> >
> > On Tue, May 30, 2017 at 9:16 AM, Juan Hernández  > > wrote:
> >
> > On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> > >
> > >
> > > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek <
> mskri...@redhat.com 
> > > >> wrote:
> > >
> > > > On 29 May 2017, at 11:44, Juan Hernández <
> jhern...@redhat.com 
> > >> wrote:
> > > >
> > > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > > >>
> > > >>> On 29 May 2017, at 10:39, Juan Hernández <
> jhern...@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:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   Host myhost failed to recover. > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> 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
> >  event.rb#L25-L485>
> > >
> >   event.rb#L25-L485
> >  event.rb#L25-L485>>
> > > >>>
> > > >>> We could avoid this by adding to the API a new event
> > attribute that
> > > >>> indicates the type:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   host_recover_failure
> > > >>>   Host myhost failed to recover.
> > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> 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:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   host_recover_failure
> > > >>>   Host myhost failed to recover.
> > > >>>   ...
> > > >>> 
>
> > >>>
> > > >>> 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?
>

we can maintain the mapping layer between backend event types to restapi
event types
on the restapi side. This is currently done on the ovirt-gem, and once
ovirt-gem is depracated
we could rely the manageiq-providers-ovirt code on the api/sdk which will
expose the event name.
Having a single api maintainer will ease the maintenance of it and will
allow a better control of
changes to that part.


> > > >>
> > > >> 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:
> > > >
> > > >
> > > >
> > 

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/30/2017 12:11 PM, Oved Ourfali wrote:
> 
> 
> On May 30, 2017 11:28, "Juan Hernández"  > wrote:
> 
> On 05/30/2017 09:38 AM, Tomas Jelinek wrote:
> >
> >
> > On Tue, May 30, 2017 at 9:16 AM, Juan Hernández
> 
> > >> wrote:
> >
> > On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> > >
> > >
> > > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek
> 
> >
> > > 
>  > >
> > > > On 29 May 2017, at 11:44, Juan Hernández
> 
> >
> > 
>  > > >
> > > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > > >>
> > > >>> On 29 May 2017, at 10:39, Juan Hernández
> 
> >
> > > 
>  > > >>>
> > > >>> 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:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   Host myhost failed to
> recover. > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> 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:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   host_recover_failure
> > > >>>   Host myhost failed to
> recover.
> > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> 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:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   host_recover_failure
> > > >>>   Host myhost failed to
> recover.
> > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> However, the key point to making this useful would
> be to keep
> > > the types
> > > >>> (or names) backwards 

Re: [ovirt-devel] Making event types backwards compatible?

[Oved Ourfali]

On May 30, 2017 11:28, "Juan Hernández"  wrote:

On 05/30/2017 09:38 AM, Tomas Jelinek wrote:
>
>
> On Tue, May 30, 2017 at 9:16 AM, Juan Hernández  > wrote:
>
> On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> >
> >
> > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek <
mskri...@redhat.com 
> > >> wrote:
> >
> > > On 29 May 2017, at 11:44, Juan Hernández 
> >> wrote:
> > >
> > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > >>
> > >>> On 29 May 2017, at 10:39, Juan Hernández <
jhern...@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:
> > >>>
> > >>> 
> > >>>   19
> > >>>   Host myhost failed to recover. > >>>   ...
> > >>> 
> > >>>
> > >>> 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:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> 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:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> 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/models/manageiq/providers/redhat/infra_
manager/event_parser.rb#L80-L92
> 
> >
>   >
> >
> >
> > hmmm, while we are on topic, this pretty much looks like that
manageiq
> > 

Re: [ovirt-devel] Making event types backwards compatible?

[Tomas Jelinek]

On Tue, May 30, 2017 at 9:16 AM, Juan Hernández  wrote:

> On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> >
> >
> > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek  > > wrote:
> >
> > > On 29 May 2017, at 11:44, Juan Hernández  > wrote:
> > >
> > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > >>
> > >>> On 29 May 2017, at 10:39, Juan Hernández  > > 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:
> > >>>
> > >>> 
> > >>>   19
> > >>>   Host myhost failed to recover. > >>>   ...
> > >>> 
> > >>>
> > >>> 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
> >  event.rb#L25-L485>
> > >>>
> > >>> We could avoid this by adding to the API a new event attribute
> that
> > >>> indicates the type:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> 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:
> > >>>
> > >>> 
> > >>>   19
> > >>>   host_recover_failure
> > >>>   Host myhost failed to recover.
> > >>>   ...
> > >>> 
> > >>>
> > >>> 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/models/manageiq/providers/redhat/infra_
> manager/event_parser.rb#L80-L92
> >  master/app/models/manageiq/providers/redhat/infra_
> manager/event_parser.rb#L80-L92>
> >
> >
> > hmmm, while we are on topic, this pretty much looks like that manageiq
> > does not only rely on the code but also on the actual value of it since
> > it is parsing it:
> >
> > # sample message: "Interface nic1 (VirtIO) was added to VM v5. (User:
> > admin@internal-authz)" message.split(/\s/)[7][0...-1]
> >
> > Is this something we commit to maintain? Or should we commit to maintain
> it?
> >
>
> That is a good point, that isn't very future proof. We should also find
> a way to make less fragile. Any suggestion?
>

The only doable thing which comes to my mind is something like this:
The msg is defined like this:
USER_ADD_VM_POOL_WITH_VMS_FAILED=Failed to create VM Pool ${VmPoolName}
(User: ${UserName}).

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.

So, something like:


   19
   USER_ADD_VM_POOL_WITH_VMS_FAILED
   the substituted msg.
   
 
VmPoolName
The Pool Name
 
...
   


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.


> >
> > >
> > > That means that if we ever change the meaning of a code the
> ManageIQ
> > > provider, for example, will break.

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> 
> 
> On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek  > wrote:
> 
> > On 29 May 2017, at 11:44, Juan Hernández  > wrote:
> >
> >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> >>
> >>> On 29 May 2017, at 10:39, Juan Hernández  > 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:
> >>>
> >>> 
> >>>   19
> >>>   Host myhost failed to recover. >>>   ...
> >>> 
> >>>
> >>> 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:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> 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:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> 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/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92
> 
> 
> 
> 
> hmmm, while we are on topic, this pretty much looks like that manageiq
> does not only rely on the code but also on the actual value of it since
> it is parsing it:
> 
> # sample message: "Interface nic1 (VirtIO) was added to VM v5. (User:
> admin@internal-authz)" message.split(/\s/)[7][0...-1]
> 
> Is this something we commit to maintain? Or should we commit to maintain it?
>

That is a good point, that isn't very future proof. We should also find
a way to make less fragile. Any suggestion?

> 
> >
> > That means that if we ever change the meaning of a code the ManageIQ
> > provider, for example, will break.
> 
> Right,then it indeed needs to stay stable.
> But how is maintaining the enum string different from the code? It is
> the same information, so if MIQ doesn't use the name directly then it
> doesn't really matter if it's a code or string.
> Perhaps deprecate the code and keep the name fixed?
> 
> Thanks,
> michal
> 
> >
> >>>
> >>> Regards,
> >>> Juan Hernandez
> >>>
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org 
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> 
> >
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 

___
Devel mailing list
Devel@ovirt.org

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/30/2017 07:20 AM, Michal Skrivanek wrote:
>> On 29 May 2017, at 11:44, Juan Hernández  wrote:
>>
>>> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
>>>
 On 29 May 2017, at 10:39, Juan Hernández  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:

 
   19
   Host myhost failed to recover.>>>   ...
 

 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:

 
   19
   host_recover_failure
   Host myhost failed to recover.
   ...
 

 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:

 
   19
   host_recover_failure
   Host myhost failed to recover.
   ...
 

 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/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92
>>
>> That means that if we ever change the meaning of a code the ManageIQ
>> provider, for example, will break.
> 
> Right,then it indeed needs to stay stable.
> But how is maintaining the enum string different from the code? It is
> the same information, so if MIQ doesn't use the name directly then it
> doesn't really matter if it's a code or string.

It is true that we could commit to keep the meanings of numeric codes
backwards compatible, and document them somehow. If we commit to do that
then I'd say the issue is mostly solved.

However, if we use an enum we have the additional advantage it is more
readable (in the SDKs in particular) and that the Java compiler would
help us to detect potential backwards compatibility breaking changes. In
addition changes to the enum would need to be done and reviewed in the
specification of the API, which would give us (us == the API
maintainers) the opportunity to review/discuss/document/decide about
them explicitly.

> Perhaps deprecate the code and keep the name fixed?

Yes, that is the idea, if we commit to keep them stable, see the bug.

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Making event types backwards compatible?

[Tomas Jelinek]

On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek 
wrote:

> > On 29 May 2017, at 11:44, Juan Hernández  wrote:
> >
> >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> >>
> >>> On 29 May 2017, at 10:39, Juan Hernández  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:
> >>>
> >>> 
> >>>   19
> >>>   Host myhost failed to recover. >>>   ...
> >>> 
> >>>
> >>> 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:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> 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:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> 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/models/manageiq/providers/redhat/infra_
> manager/event_parser.rb#L80-L92
>

hmmm, while we are on topic, this pretty much looks like that manageiq does
not only rely on the code but also on the actual value of it since it is
parsing it:

# sample message: "Interface nic1 (VirtIO) was added to VM v5. (User:
admin@internal-authz)" message.split(/\s/)[7][0...-1]

Is this something we commit to maintain? Or should we commit to maintain it?


> >
> > That means that if we ever change the meaning of a code the ManageIQ
> > provider, for example, will break.
>
> Right,then it indeed needs to stay stable.
> But how is maintaining the enum string different from the code? It is
> the same information, so if MIQ doesn't use the name directly then it
> doesn't really matter if it's a code or string.
> Perhaps deprecate the code and keep the name fixed?
>
> Thanks,
> michal
>
> >
> >>>
> >>> Regards,
> >>> Juan Hernandez
> >>>
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Making event types backwards compatible?

[Michal Skrivanek]

> On 29 May 2017, at 11:44, Juan Hernández  wrote:
>
>> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
>>
>>> On 29 May 2017, at 10:39, Juan Hernández  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:
>>>
>>> 
>>>   19
>>>   Host myhost failed to recover.>>   ...
>>> 
>>>
>>> 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:
>>>
>>> 
>>>   19
>>>   host_recover_failure
>>>   Host myhost failed to recover.
>>>   ...
>>> 
>>>
>>> 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:
>>>
>>> 
>>>   19
>>>   host_recover_failure
>>>   Host myhost failed to recover.
>>>   ...
>>> 
>>>
>>> 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/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92
>
> That means that if we ever change the meaning of a code the ManageIQ
> provider, for example, will break.

Right,then it indeed needs to stay stable.
But how is maintaining the enum string different from the code? It is
the same information, so if MIQ doesn't use the name directly then it
doesn't really matter if it's a code or string.
Perhaps deprecate the code and keep the name fixed?

Thanks,
michal

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

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> 
>> On 29 May 2017, at 10:39, Juan Hernández  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:
>>
>>  
>>19
>>Host myhost failed to recover.>...
>>  
>>
>> 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:
>>
>>  
>>19
>>host_recover_failure
>>Host myhost failed to recover.
>>...
>>  
>>
>> 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:
>>
>>  
>>19
>>host_recover_failure
>>Host myhost failed to recover.
>>...
>>  
>>
>> 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/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92

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@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
> 

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Making event types backwards compatible?

[Michal Skrivanek]

> On 29 May 2017, at 10:39, Juan Hernández  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:
> 
>  
>19
>Host myhost failed to recover....
>  
> 
> 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:
> 
>  
>19
>host_recover_failure
>Host myhost failed to recover.
>...
>  
> 
> 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:
> 
>  
>19
>host_recover_failure
>Host myhost failed to recover.
>...
>  
> 
> 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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel