Open Stack

Stanislaw B.,

You're somehow contradicting in your statements. However, taking into
account your's -

> Both of these approaches can be used, so I'm against forcing plugin
> developers to use just one approach.

I can conclude that you support idea of having multi-release plugins?
Because no one can restrict you use different VCS repos/branches for
single release if you want to.

Is that the case?

- Igor

On Fri, Feb 12, 2016 at 11:18 AM, Stanislaw Bogatkin
<sbogatkin at mirantis.com> wrote:
>>>With plugins we extend Fuel capabilities, which supports multiple
>>> operating system releases, so it's absolutely natural to extend multiple
>>> releases at the same time.
> It is okay for me when we talk about different operating system release, but
> initial question was about different Fuel and OpenStack releases, it is not
> the same. We can have one operating system thru several Fuel releases.
> As I said - approach when you need extend plugin functionality to multiple
> releases lead to mess in a plugin repo if you change the codebase from one
> release to another. From other hand - it works wonderful if plugin codebase
> doesn't change and all you need to support multiple Fuel releases is to
> change metadata.yaml. Both of these approaches can be used, so I'm against
> forcing plugin developers to use just one approach.
>
> On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <eli at mirantis.com> wrote:
>>
>> Ilya,
>>
>> >> My opinion that i've seen no example of multiple software of plugins
>> >> versions shipped in one package or other form of bundle. Its not a common
>> >> practice.
>>
>> With plugins we extend Fuel capabilities, which supports multiple
>> operating system releases, so it's absolutely natural to extend multiple
>> releases at the same time.
>>
>> >> Anyway we need to provide ability to override paths in manifest
>> >> (metadata.yaml).
>>
>> Could you please provide more information on that? I'm not sure if I
>> understand your solution.
>>
>> Also I'm not sure what we are arguing about, if plugin developer (or
>> certification process of some company) requires to have plugin per release,
>> it's *very easy* and straight forward to do it even now *without any*
>> changes.
>>
>> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc,
>> let them do it, and again when we get full support of multi-version
>> environments it's going to be even more crucial for UX to have a single
>> plugin with multi-release support.
>>
>> Thanks,
>>
>> On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutukov at mirantis.com>
>> wrote:
>>>
>>> My opinion that i've seen no example of multiple software of plugins
>>> versions shipped in one package or other form of bundle. Its not a common
>>> practice.
>>>
>>> Anyway we need to provide ability to override paths in manifest
>>> (metadata.yaml).
>>>
>>> So the plugin developers could use this approaches to provide multiple
>>> versions support:
>>>
>>> * tasks logic (do the plugin developers have access to current release
>>> info?)
>>> * hooks in pre-build process. Its not a big deal to preprocess source
>>> folder to build different packages with scripts that adding or removing some
>>> files or replacing some paths.
>>> * and, perhaps, logic anchors with YACL or other DSL in tasks
>>> dependancies if this functionality will be added this in theory could allow
>>> to use or not to use some graph parts depending on release.
>>>
>>> I think its already better than nothing and more flexible than any
>>> standardised approach.
>>>
>>> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasquier at mirantis.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky
>>>> <ikalnitsky at mirantis.com> wrote:
>>>>>
>>>>> Hey folks,
>>>>>
>>>>> The original idea is to provide a way to build plugin that are
>>>>> compatible with few releases. It makes sense to me, cause it looks
>>>>> awful if you need to maintain different branches for different Fuel
>>>>> releases and there's no difference in the sources. In that case, each
>>>>> bugfix to deployment scripts requires:
>>>>>
>>>>> * backport bugfix to other branches (N backports)
>>>>> * build new packages for supported releases (N builds)
>>>>> * release new packages (N releases)
>>>>>
>>>>> It's somehow.. annoying.
>>>>
>>>>
>>>> A big +1 on Igor's remark. I've already expressed it in another thread
>>>> but it should be expected that plugin developers want to support 2
>>>> consecutive versions of Fuel for a given version of their plugin.
>>>> That being said, I've never had issues to do it with the current plugin
>>>> framework. Except when Fuel breaks the backward compatibility but it's
>>>> another story...
>>>>
>>>> Simon
>>>>
>>>>>
>>>>>
>>>>> However, I starting agree that having all-in-one RPM when deployment
>>>>> scripts are different, tasks are different, roles/volumes are
>>>>> different, probably isn't a good idea. It basically means that your
>>>>> sources are completely different, and that means you have different
>>>>> implementations of the same plugin. In that case, in order to avoid
>>>>> mess in source tree, it'd be better to separate such implementations
>>>>> on VCS level.
>>>>>
>>>>> But I'd like to hear more opinion from plugin developers.
>>>>>
>>>>> - Igor
>>>>>
>>>>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin
>>>>> <bgaifullin at mirantis.com> wrote:
>>>>> > I agree with Stas, one rpm - one version.
>>>>> >
>>>>> > But plugin builder allows to specify several releases as compatible.
>>>>> > The
>>>>> > deployment tasks and repositories can be specified per release, at
>>>>> > the same
>>>>> > time the deployment graph is one for all releases.
>>>>> > Currently it looks like half-implemented feature.  Can we drop this
>>>>> > feature?
>>>>> > or should we finish implementation of this feature.
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Bulat Gaifullin
>>>>> > Mirantis Inc.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 11 Feb 2016, at 02:41, Andrew Woodward <xarses at gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko
>>>>> > <dborodaenko at mirantis.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> +1 to Stas, supplanting VCS branches with code duplication is a path
>>>>> >> to
>>>>> >> madness and despair. The dubious benefits of a cross-release
>>>>> >> backwards
>>>>> >> compatible plugin binary are not worth the code and infra technical
>>>>> >> debt
>>>>> >> that such approach would accrue over time.
>>>>> >
>>>>> >
>>>>> > Supporting multiple fuel releases will likely result in madness as
>>>>> > discussed, however as we look to support multiple OpenStack releases
>>>>> > from
>>>>> > the same version of fuel, this methodology becomes much more
>>>>> > important.
>>>>> >
>>>>> >>
>>>>> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
>>>>> >> > It changes mostly nothing for case of furious plugin development
>>>>> >> > when
>>>>> >> > big
>>>>> >> > parts of code changed from one release to another.
>>>>> >> >
>>>>> >> > You will have 6 different deployment_tasks directories and 30 a
>>>>> >> > little
>>>>> >> > bit
>>>>> >> > different files in root directory of plugin. Also you forgot about
>>>>> >> > repositories directory (+6 at least), pre_build hooks (also 6) and
>>>>> >> > so
>>>>> >> > on.
>>>>> >> > It will look as hell after just 3 years of development.
>>>>> >> >
>>>>> >> > Also I can't imagine how to deal with plugin licensing if you have
>>>>> >> > Apache
>>>>> >> > for liberty but BSD for mitaka release, for example.
>>>>> >> >
>>>>> >> > Much easier way to develop a plugin is to keep it's source in VCS
>>>>> >> > like
>>>>> >> > Git
>>>>> >> > and just make a branches for every fuel release. It will give us
>>>>> >> > opportunity to not store a bunch of similar but a little bit
>>>>> >> > different
>>>>> >> > files in repo. There is no reason to drag all different versions
>>>>> >> > of code
>>>>> >> > for specific release.
>>>>> >> >
>>>>> >> >
>>>>> >> > On other hand there is a pros - your plugin can survive after
>>>>> >> > upgrade if
>>>>> >> > it
>>>>> >> > supports new release, no changes needed here.
>>>>> >> >
>>>>> >> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov
>>>>> >> > <ashtokolov at mirantis.com>
>>>>> >> > wrote:
>>>>> >> >
>>>>> >> > > Fuelers,
>>>>> >> > >
>>>>> >> > > We are discussing the idea to extend the multi release packages
>>>>> >> > > for
>>>>> >> > > plugins.
>>>>> >> > >
>>>>> >> > > Fuel plugin builder (FPB) can create one rpm-package for all
>>>>> >> > > supported
>>>>> >> > > releases (from metadata.yaml) but we can specify only deployment
>>>>> >> > > scripts
>>>>> >> > > and repositories per release.
>>>>> >> > >
>>>>> >> > > Current release definition (in metadata.yaml):
>>>>> >> > >     - os: ubuntu
>>>>> >> > >       version: liberty-8.0
>>>>> >> > >       mode: ['ha']
>>>>> >> > >       deployment_scripts_path: deployment_scripts/
>>>>> >> > >       repository_path: repositories/ubuntu
>>>>> >> > >
>>>>> >
>>>>> >
>>>>> > This will result in far too much clutter.
>>>>> > For starters we should support nested over rides. for example the
>>>>> > author may
>>>>> > have already taken account for the changes between one openstack
>>>>> > version to
>>>>> > another. In this case they only should need to define the releases
>>>>> > they
>>>>> > support and not specify any additional locations. Later they may
>>>>> > determine
>>>>> > that they only need to replace packages, or one other file they
>>>>> > should not
>>>>> > be required to code every location for each release
>>>>> >
>>>>> > Also, at the same time we MUST clean up importing various yaml files.
>>>>> > Specifically, tasks, volumes, node roles, and network roles.
>>>>> > Requiring that
>>>>> > they all be maintained in a single file doesn't scale, we don't
>>>>> > require it
>>>>> > for tasks.yaml in fuel library, and we should not require it in
>>>>> > plugins. We
>>>>> > should simply do the same thing as tasks.yaml in library, scan the
>>>>> > subtree
>>>>> > for specific file names and just merge them all together. (This has
>>>>> > been
>>>>> > expressed multiple times by people with larger plugins)
>>>>> >
>>>>> >> > > So the idea [0] is to make releases fully configurable.
>>>>> >> > > Suggested changes for release definition (in metadata.yaml):
>>>>> >> > >       components_path: components_liberty.yaml
>>>>> >> > >       deployment_tasks_path: deployment_tasks_liberty/ # <-
>>>>> >> > > folder
>>>>> >>
>>>>> >> > >       environment_config_path: environment_config_liberty.yaml
>>>>> >> > >       network_roles_path: network_roles_liberty.yaml
>>>>> >> > >       node_roles_path: node_roles_liberty.yaml
>>>>> >> > >       volumes_path: volumes_liberty.yaml
>>>>> >> > >
>>>>> >> > > I see the issue: if we change anything for one release (e.g.
>>>>> >> > > deployment_task typo) revalidation is needed for all releases.
>>>>> >> > >
>>>>> >> > > Your Pros and cons please?
>>>>> >> > >
>>>>> >> > > [0] https://review.openstack.org/#/c/271417/
>>>>> >> > > ---
>>>>> >> > > WBR, Alexey Shtokolov
>>>>> >> > >
>>>>> >> > >
>>>>> >> > >
>>>>> >> > > __________________________________________________________________________
>>>>> >> > > 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
>>>>> >> > >
>>>>> >> > >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > with best regards,
>>>>> >> > Stan.
>>>>> >>
>>>>> >> >
>>>>> >> >
>>>>> >> > __________________________________________________________________________
>>>>> >> > 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
>>>>> >
>>>>> > --
>>>>> >
>>>>> > --
>>>>> >
>>>>> > 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://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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> with best regards,
> Stan.
>
> __________________________________________________________________________
> 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
>