Open Stack

Sorry for the typo "s/I can shade more light/I can shed more light/"

On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L <eli at mirantis.com> wrote:

> Hi,
>
> As an author of this part of pluggable architecture I can shade more light
> on why it was implemented this way and why it's valuable to continue
> supporting multi-release feature.
>
> At the time it was implemented Fuel officially was supporting both Ubuntu
> and CentOS, in order to simplify plugins distribution development and
> support,
> plugin developer was able to create a single plugin which supports both
> operating systems, deployment scripts in the most cases support both
> operating systems, if they are not, there is enough flexibility to specify
> different set of deployment scripts and repositories.
>
> We don't force plugin developer to support all range of releases in a
> single
> plugin, it's up to plugin developer to decide what mechanism is better for
> specific plugin, I'm strongly against of making "single release a.k.a os"
> plugins.
>
> Also suggested change will dramatically complicate distribution when we
> get heterogeneous environments (different operating system in a single
> environment).
>
> Bulat is right that there are issues, but those issues has to be fixed, and
> there is straightforward way to do it.
>
> To summarise, I don't think that we should force the developer to follow
> specific release schema, let the developer decide.
>
> Thanks,
>
>
> On Thu, Feb 11, 2016 at 10: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://OpenStack-dev-request@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://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://OpenStack-dev-request@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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/759856d2/attachment.html>