On 03/22/2016 09:25 AM, Matthew Mosesohn wrote: > Andrew, > > The stubs + deprecation warning is exactly the approach I believewe > should take for renaming/moving tasks.
LGTM to me as far as it keeps plugins intact. So let's please update the patch [0] or submit required patches to unblock it. [0] https://review.openstack.org/#/c/283332/ > > If it was possible for a plugin to override a task, but preserve the > fields from the original task, we could avoid such scenarios. What I > mean is that if the following task: > > - id: workloads_collector_add > type: puppet > version: 2.0.0 > groups: [primary-controller] > required_for: [deploy_end] > requires: [keystone, primary-keystone] > parameters: > puppet_manifest: > /etc/puppet/modules/osnailyfacter/modular/keystone/workloads_collector_add.pp > puppet_modules: /etc/puppet/modules > timeout: 1800 > > If we could override the groups field only, a plugin developer would not > need to copy and paste the dependencies and other parameters. But until > that works, we should effectively deprecate top level tasks whenever > possible. > > On Mar 22, 2016 2:52 AM, "Andrew Woodward" <xar...@gmail.com > <mailto:xar...@gmail.com>> wrote: > > I've mocked up the change to implementation using the already landed > changes to ceph as an example > > https://review.openstack.org/295571 > > On Mon, Mar 21, 2016 at 3:44 PM Andrew Woodward <xar...@gmail.com > <mailto:xar...@gmail.com>> wrote: > > We had originally planned for the FFEs for both > fuel-openstack-tasks[1] and fuel-remove-conflict-openstack to > [2] to close on 3/20, This would have placed them before changes > that conflict with > fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html > [2] > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html > [3] > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/089028.html > > However we found this morning that the changes from [2], and > more of issue [1] will result in further issues such as [4], > where as the task files move, any task that explicitly relied on > it, now no longer is in the same path. > > [4] https://review.openstack.org/#/c/295170/ > > Due to this newly identified issue with backwards comparability. > It appears that [4] shows that we have plugins using interfaces > that we don't have formal coverage for so If we introduce this > set of changes, we will cause breakage for plugins that use > fuel's current tasks. > > From a deprecation standpoint we don't have a way to deal with > this, unless fuel-openstack-tasks [1] lands after > fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. > In this case we can take advantage of the class include stubs, > leaving a copy in the old location > (osnailyfacter/modular/roles/compute.pp) pointing to the new > include location (include openstack_tasks::roles::compute) and > adding a warning for deprecation. The tasks includes in the new > location openstack_tasks/examples/roles/compute.pp would simply > include the updated class location w/o the warning. > > This would take care of [1] and it's review [5] > > [5] https://review.openstack.org/283332 > > This still leaves [2] un-addressed, we still have 3 open CR for it: > > [6] Compute https://review.openstack.org/285567 > [7] Cinder https://review.openstack.org/294736 > [8] Swift https://review.openstack.org/294979 > > Compute [6] is in good shape, while Cinder [7] and Swift [8] are > not. For these do we want to continue to land them, if so what > do we want to do about the now deprecated openstack:: tasks? We > could leave them in place with a warning since we would not be > using them > > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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
