Open Stack

On 9/19/2017 10:35 AM, Balazs Gibizer wrote:
> Hi,
> 
> Similar to my earlier mail about not transforming legacy notifications 
> in the networking area [1] now I want to propose not to transform 
> HostAPI related notifications.
> We have the following legacy notifications on our TODO list [2] to be 
> transformed:
> * HostAPI.power_action.end
> * HostAPI.power_action.start
> * HostAPI.set_enabled.end
> * HostAPI.set_enabled.start
> * HostAPI.set_maintenance.end
> * HostAPI.set_maintenance.start
> 
> However os-hosts API has been depraceted since microversion 2.43. The 
> suggested replacement is os-services API. The os-services API already 
> emits service.update notification for every action on that API. So I 
> suggest not to transform the above HostAPI notifications to the 
> versioned notification format.
> 
> Cheers,
> gibi
> 
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-September/121968.html 
> 
> [2] https://vntburndown-gibi.rhcloud.com/index.html
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

This also seems reasonable to me. I had to dig up what set_enabled was 
for again, but now I remember, it's basically the same thing as 
enable/disable a service in the os-services API, but only implemented 
for the xenapi driver.

So yeah, +1 to not converting these to versioned notifications.

As a side question: how do you keep track of the things we purposefully 
*aren't* going to implement for versioned notifications?

-- 

Thanks,

Matt