Open Stack

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" <xarses at gmail.com
> <mailto:xarses at 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 <xarses at gmail.com
>     <mailto:xarses at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando