Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-22 Thread Bogdan Dobrelya 
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"  > 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  > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-22 Thread Matthew Mosesohn 
Andrew,

The stubs + deprecation warning is exactly the approach I believewe should
take for renaming/moving tasks.

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"  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  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://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

Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-21 Thread Andrew Woodward 
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  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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-21 Thread Andrew Woodward 
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
__
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