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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
