Open Stack

I see no follow-up to Swann's question so let me elaborate why this issue
is important for the LMA plugins.

First I need to explain what was our release schedule for the LMA plugins
during the MOS 7.0 cycle:
- New features were done on the master branch which was only compatible
with MOS 7.0.
- We maintained the stable/0.7 branches of the LMA plugins to remain
compatible with both MOS 6.1 and 7.0. The work was very lightweight like
backporting a few fixes from the master branch (for instance the
metadata.yaml update).

This workflow allows several things for us:
- Ship a point release of the LMA toolchain based on the stable(/0.7)
branch soon after MOS (7.0) is released. This let users deploy LMA with MOS
7 without waiting for the new LMA version that's been release a few months
after MOS 7.
- Use a well-know version of the LMA toolchain with the MOS version under
development for troubleshooting, performance analysis, longevity testing,
... This one is of great interest for the QA team. If we were to use the
master branch of the LMA plugins, it would dramatically decrease the
stability of the whole.
- Make sure that the LMA toolchain can be deployed with plugins that don't
support the latest MOS version: for instance, we're going to release our
master branch (compatible only with MOS 8) right after MOS GA but other
plugins won't ship a new version before MOS 9 so we need to keep supporting
MOS 7.

Looking at the originating bug description [1], I'm not sure to fully
understand what problem the change is trying to fix and why it's been
backported on stable/8.0. But IMO, the change puts too much burden on
plugin developers. Maintaining several branches of our plugins for every
MOS version is the last thing I want to do.

Regards,
Simon

[1] https://bugs.launchpad.net/fuel/+bug/1508486

On Thu, Jan 21, 2016 at 10:23 AM, Bartlomiej Piotrowski <
bpiotrowski at mirantis.com> wrote:

> Breakage of anything is probably the last thing I intended to achieve with
> that patch. Maybe I misunderstand how tasks dependencies works, let me
> describe *explicit* dependencies I did in tasks.yaml:
>
> hiera requires deploy_start
> hiera is required for setup_repositories
> setup_repositories is required for fuel_pkgs
> setup_repositories requires hiera
> fuel_pkgs requires setup_repositories
> fuel_pkgs is required globals
>
> Coming from packaging realm, there is clear transitive dependency for
> anything that pulls globals task, i.e. if task foo depends on globals, the
> latter pulls fuel_pkgs, which brings setup_repositories in. I'm in favor of
> reverting both patches (master and stable/8.0) if it's going to break
> backwards compatibility, but I really see bigger problem in the way we
> handle task dependencies.
>
> Bartłomiej
>
> On Thu, Jan 21, 2016 at 9:51 AM, Swann Croiset <scroiset at mirantis.com>
> wrote:
>
>> Sergii,
>> I'm also curious, what about plugins which intend to be compatible with
>> both MOS 7 and MOS 8?
>> I've in mind the LMA plugins stable/0.8
>>
>> BR
>>
>> --
>> Swann
>>
>> On Wed, Jan 20, 2016 at 8:34 PM, Sergii Golovatiuk <
>> sgolovatiuk at mirantis.com> wrote:
>>
>>> Plugin master branch won't be compatible with older versions. Though the
>>> plugin developer may create stable branch to have compatibility with older
>>> versions.
>>>
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Wed, Jan 20, 2016 at 6:41 PM, Dmitry Mescheryakov <
>>> dmescheryakov at mirantis.com> wrote:
>>>
>>>> Sergii,
>>>>
>>>> I am curious - does it mean that the plugins will stop working with
>>>> older versions of Fuel?
>>>>
>>>> Thanks,
>>>>
>>>> Dmitry
>>>>
>>>> 2016-01-20 19:58 GMT+03:00 Sergii Golovatiuk <sgolovatiuk at mirantis.com>
>>>> :
>>>>
>>>>> Hi,
>>>>>
>>>>> Recently I merged the change to master and 8.0 that moves one task
>>>>> from Nailgun to Library [1]. Actually, it replaces [2] to allow operator
>>>>> more flexibility with repository management.  However, it affects the
>>>>> detached components as they will require one more task to add as written at
>>>>> [3]. Please adapt your plugin accordingly.
>>>>>
>>>>> [1]
>>>>> https://review.openstack.org/#/q/I1b83e3bfaebecdb8455d5697e320f24fb4941536
>>>>> [2]
>>>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L149-L190
>>>>> [3] https://review.openstack.org/#/c/270232/1/deployment_tasks.yaml
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Sergii Golovatiuk,
>>>>> Skype #golserge
>>>>> IRC #holser
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160127/20997ab5/attachment.html>