fuel-dev team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

On 03/19/2014 01:31 PM, Dmitry Nikishov wrote:
> Actually, zabbix module doesn't come from any upstream repo, it's our
> own reimplementation of the module by PL team, which was based on
> upstream code. In Zabbix thread it was suggested that we split it into
> multiple commits instead of trying to push the whole thing at once.
> 
> It's unclear how it will affect internally developed modules like zabbix
> one. Should there be any at all? Or should we make a public repo with
> that module first and then try to include it into fuel-library?

It is also not quite clear how to submit these team-specific changes.
1) E.g. I've submitted the puppet-logstash module from Apollo11 team
(Poland) and that module was diverged from the original upstream version
by the team. Now we have a two diverged versions - an upstream one and a
submitted one.

2) Should I submit the diverged commits rebased onto the upstream
HEAD/stable version as a separate patchset which depends on the verbatim
copy of HEAD/stable patchset? That could be a very bad idea, because
rebasing might broke the module completely.

3) Should I do the same as (2) but use the common parent commit as an
upstream base for verbatim copy instead? Despite on no more rebasing
needed, that is not so good idea as well, because it would also
complicate the  upstream sync contribution process, if any planned in
the future.

4) So, looks like the only good option is to accept changes to the
puppet modules which are only the sync requests from the upstream (see
Openstack projects and Oslo) and never change them locally in the Fuel?
But I'm afraid the Fuel puppet modules are not ready yet for such
dramatical changes... Looks like we need a kind of Fuel-oslo ;)
> 
> 
> 2014-03-19 4:02 GMT+04:00 Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx
> <mailto:dborodaenko@xxxxxxxxxxxx>>:
> 
>     +1
> 
>     For perspective, whole fuel-library/deployment/puppet is currently at
>     36KLOC (33K Ruby, 17K Puppet), the pair of logstash+elasticsearch
>     commits alone brings it up to 92KLOC (40K Ruby, 39K Puppet): +20% Ruby
>     code (mostly specs) and +130%(!!!) Puppet code.
> 
>     Even worse, most of logstash manifests look nearly identical and
>     absolutely consistent, which indicates they were autogenerated. In my
>     experience, tracking auto-generated code in Git is a bad idea, you
>     always end up modifying it by hand, which is even worse.
> 
>     -DmitryB
> 
> 
>     On Tue, Mar 18, 2014 at 4:16 PM, Andrew Woodward <xarses@xxxxxxxxx
>     <mailto:xarses@xxxxxxxxx>> wrote:
>     > I propose that we make this method standard for bringing in
>     external puppet
>     > modules.
>     >
>     > Currently we have reviews open to add
>     >
>     > puppet-mongodb: +2397 lines
>     > puppet-elasticsearch: +1897 lines
>     > puppet-logstash: +38117 lines
>     > zabbix server: +888 lines
>     > zabbix types: +4494 lines
>     >
>     >>
>     >> However big commits like this are near impossible to review.
>     >>
>     >> I propose that whenever we are taking from a upstream library
>     that we need
>     >> to follow a new process
>     >> 1. Create a review request with a verbatim copy of the upstream
>     module and
>     >> no other related modifications. This review should also contain
>     the commit
>     >> hash from the upstream repo in the commit message. The review
>     should be
>     >> looked over for reasons for rejecting the entire module, such as
>     license
>     >> issues. Forbearing such issues it should be accepted with out
>     requiring
>     >> modifications.
>     >>
>     >> 2. Any changes necessary to make it work with fuel can then be
>     proposed as
>     >> a dependent change(s)
>     >>
>     >> This will allow us to review what we are actually changing to
>     support fuel
>     >> and should accelerate reviews. It also allows us some ability to
>     identify
>     >> where we diverged from upstream in the case that we want to push
>     changes
>     >> back up. It also allows us to identify what we changed in the
>     case that the
>     >> upstream license requires such tracking.
>     >
>     >
>     > --
>     > Andrew
>     > Mirantis
>     > Ceph community
>     >
>     > --
>     > Mailing list: https://launchpad.net/~fuel-dev
>     > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~fuel-dev
>     > More help   : https://help.launchpad.net/ListHelp
>     >
> 
> 
> 
>     --
>     Dmitry Borodaenko
> 
>     --
>     Mailing list: https://launchpad.net/~fuel-dev
>     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~fuel-dev
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> -- 
> Regards
> Dmitry Nikishov
> 
> 


-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando