+1 :) I'm also +1 on amending our FFE rules so that the PTL can get a FFE on one thing of their desire, regardless of anyone disagreeing, as long as they have two cores that are willing to review. As a small thank-you for being PTL! :D (I'm serious even though I just thought of this.)
--ruby On 2018-01-23, 5:23 AM, "Dmitry Tantsur" <dtant...@redhat.com> wrote: Hi all, I'm writing to request an FFE for the classic drivers deprecation work [1][2]. This is a part of the driver composition reform [3] - the effort started in Ocata to revamp bare metal drivers. The following changes are in scope of this FFE: 1. Provide an automatic migration to hardware types as part of 'ironic-dbsync online_data_migrations' 2. Update the CI to use hardware types 3. Issue a deprecation warning when loading classic drivers, and deprecate enabled_drivers option. Finishing it in Queens will allow us to stick to our schedule (outlined in [1]) to remove classic drivers in Rocky. Keeping two methods of loading drivers is a maintenance burden. Even worse, two sets of mostly equivalent drivers confuse users, and the confusion well increase as we introduce features (like rescue) that are only available for nodes using the new-style drivers. The downside of this work is that it introduces a non-trivial data migration close to the end of the cycle. Thus, it is designed [1][2] to not fail if the migration cannot fully succeed due to environmental reasons. rloo and stendulker were so kind to agree to review this work during the feature freeze window, if it gets an exception. Dmitry [1] http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/classic-drivers-future.html [2] https://review.openstack.org/536298 [3] http://specs.openstack.org/openstack/ironic-specs/specs/7.0/driver-composition-reform.html __________________________________________________________________________ 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 __________________________________________________________________________ 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