fuel-dev team mailing list archive

[Dmitry Nikishov <nikishov.da@xxxxxxxxx>]

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?


2014-03-19 4:02 GMT+04:00 Dmitry Borodaenko <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> 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
> > 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
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Regards
Dmitry Nikishov