Open Stack

On 4/18/2016 1:08 PM, Joshua Harlow wrote:
> Hi nova folks,
>
> I was reading over the following:
>
> http://lists.openstack.org/pipermail/openstack-operators/2016-April/010186.html
>
>
> And I am wondering if there is a list of all the plugin points and there
> schedule for being deprecated and then removed (or am I misreading that
> mail/thread?).
>
> I would assume this includes things like:
>
> - baremetal_scheduler_default_filters
> - cells/driver
> - cells/scheduler
> - cells/scheduler_filter_classes
> - compute_manager
> - compute_stats_class
> - conductor/manager
> - console_driver
> - console_manager
> - consoleauth_manager
> - db_driver
> - firewall_driver
> - floating_ip_dns_manager
> - instance_dns_manager
> - keymgr/api_class
> - l3_lib
> - linuxnet_interface_driver
> - metadata_manager
> - network_api_class
> - network_driver
> - network_manager
> - osapi_compute_extension
> - quota_driver
> - scheduler_available_filters
> - scheduler_default_filters
> - scheduler_driver
> - scheduler_host_manager
> - scheduler_weight_classes
> - servicegroup_driver
> - vendordata_driver
> - volume_api_class
> - xenserver/vif_driver
>
> (and or any I missed the end with '_driver' or 'manager').
>
> Also is there any docs on the reasons for removal (I think I get why,
> just wanted to be able to reference something for others); because I can
> imagine such a thing/wiki/docs/reason will be needed or people will
> start flipping a lot of tables.
>
> Any thoughts on the above (or a table showing timelines and reasons)
> would be great,
>
> Much appreciated!
>
> -Josh
>
>
> __________________________________________________________________________
> 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
>

The thread that started the latest round of deprecations was [1].

The main points are:

1. These are unversioned interfaces and we break them without knowing it.
2. We have versioned notifications now and some of the use cases for 
hooks could be solved with acting on notifications (versioned or not 
really).
3. Things that can't be solved with notifications, and is a good idea, 
should be proposed upstream as part of the core code rather than living 
out of tree where we can unknowingly break them.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087782.html

-- 

Thanks,

Matt Riedemann