[chef] Re: Re: Re: Community cookbook maintenance (was: Re: Reprepro cookbook)

[Nathan Williams < >]

On Thu, 2015-06-25 at 09:11 -0700, Yoshi Spendiff wrote:
> An official certification is probably too much to handle but there 
> could be value in stating guidelines that demonstrate how a reliable 
> cookbook is designed and tested. I know Chef doesn't like to 
> prescribe but for the sake of quality a recommended path for some 
> things might be a good idea.

that seems to be changing, though; between the tooling packaged with
chefdk, and the bundled generators, they're effectively prescribing
(which is great, please keep it going!) if not overtly doing so.

> 
> The reason to maintain a community cookbook is usually because it's 
> relevant to your business/job, which is obviously why cookbooks fall 
> out of repair and only  have certain coverage.
> 
> If business 1 makes  a cookbook for platform X only and business 2 
> wants to do the same for platform Y then their options are:
> 1. Make a new cookbook for platform X
> 2. Fork
> 3. Work on a pull request
> Having good methods for business 2 to contact business 1 and state 
> their intention could lead to productive collaboration and 
> implementing better ways to find contributors and reviewers of 
> cookbooks could be a good way to help out with this, whether it's 
> business to business or just individual contributors.
> 
> It would also be useful for there to be a mechanism where ownership 
> of stale cookbooks can be transferred, especially now there are 
> groups that are willing to maintain them.

have you seen the "adopt me" stuff on supermarket? i think that
addresses this situation pretty well.

> 
> Finally, better sorting and maybe a rating system on the supermarket 
> for cookbooks would be good. If a cookbook starts out excellent but 
> isn't maintained then many lower reviews will start to drag down the 
> rating.

this'd probably be easier to implement, but it's also very subjective.
ratings systems are great for popularity, but they often miss the mark
for quality.

> 
> On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz 
> <
 >
>  
> wrote:
> > > Am 24.06.2015 um 17:33 schrieb Nathan Williams <
> > 
 >:
> > > i'd really like to see some official (maybe a BCP Chef RFC?) 
> > guidelines for quality based around the BCP guidelines... For 
> > example: evaluated with foodcritic and rubocop, integration tested 
> > with test-kitchen suites that cover the majority of recipe code
> > -paths (e.g. source vs package install, etc.), unit tested with 
> > chefspec, and support for the relevant Chef-supported platforms (ht
> > tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support
> > -policy.md).
> > >
> > > if we then had some application process for Chef Inc to certify a 
> > cookbook as complying with the BCP, and we surfaced BCP-compliant 
> > cookbooks through Supermarket (with periodic 
> > review/recertification), I think we'd be most of the way to 
> > victory. This kind of surfacing would help deal with the naming 
> > conflict and abandoned cookbook issues we currently have to deal 
> > with (the systemd cookbook is a particularly egregious example of 
> > name-squatting), and would hopefully encourage community cookbook 
> > developers to put in extra effort, knowing that BCP compliance 
> > meant better visibility and more adoption.
> > 
> > Let's assume there would be a strong quality regime in place for 
> > community cookbooks. Chef, Inc. would actively need to code review 
> > and monitor everything except "write the code". I'm not sure if 
> > this can work and even make sense. It's like taking over the 
> > responsibility ("certified cookbook") without beeing able/willing 
> > to intervene when things get bad ("not certified anymore, but out 
> > of our scope to fix").
> > 
> > It's also not useful to just increase the pressure for open source 
> > developers if you want to keep and even increase the level of 
> > community contribution.
> > 
> > This, again, brings up my other concern: Why, at all, maintain a 
> > community cookbook?
> > 
> > The vast majority - as far as I can see - is maintained by single 
> > developers and/or a single company. The GH issues to PR ration is 
> > like 10:1, e.g. it's very time consuming to support, if you take 
> > issue reports seriously and also less useful because PR aren't 
> > happening frequently and are probably not that useful (If your shop 
> > uses Debian X, you just don't care about some PR for CentOS Y that 
> > much - and vice versa).
> > 
> > I can fully understand that most OSS cookbook developers don't have 
> > time for this, become inactive or just give up. They are getting 
> > paid for keeping their employer's (or their own) business up and 
> > scaling or don't get paid at all and do this entirely in their 
> > spare time.
> > 
> > Nobody can blame them!
> > 
> > Most business are too critical to entirely rely on voluntary time 
> > allocation by open source maintainers. If your business is serious, 
> > you'll compulsorily have to start in-house maintaining most of the 
> > cookbooks over time. Usually this also implies no further 
> > contribution back to the ecosystem/upstream/supermarket. 
> > https://github.com/aws/opsworks-cookbooks ;(and OpsWorks in general) 
> > is a very good/bad example.
> > 
> > Best case is, that those "hidden" deployments will just stick with 
> > the chef patterns of 2010+, worst case they build things that 
> > should never ever be done in Chef and Ruby +that+ way…  In almost 
> > every case, Chef (product) will then be blamed for the eventual 
> > desaster, not the team that was not able to adopt the best 
> > practices provided by the community and/or Chef, Inc..
> > 
> > 
> > best regards
> > Roland
> > 
> > 
> > 
> > 
> > > anyways, that's my two cents.
> > >
> > > regards,
> > >
> > > nathan w
> > >
> > > On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz 
> > > <
 >
> > >  
> > wrote:
> > > Hi,
> > >
> > >
> > >> Am 23.06.2015 um 00:23 schrieb Ranjib Dey 
> > >> <
 >
> > :
> > >>
> > >> yes there is a lot of value with Chef inc, providing a public 
> > supermarket instance, it seeds community effort. You dont need it 
> > if you consume cookbooks from github or other sources (can be 
> > public, can be private/org specific).
> > >
> > >
> > > I don’t think that it seeds community effort, because it’s often 
> > a „trap“. A cookbook, e.g. named `systemd`, looks legit but it may 
> > be broken, outdated or just be a no-op cookbook that reserves the 
> > name:
> > >
> > > https://supermarket.chef.io/cookbooks?utf8=%E2%9C%93&q=systemd&pl
> > atforms%5B%5D=
> > >
> > > - number of downloads is irrelevant, as we all know
> > > - follower number is also not a good indication, because even 
> > after a year, supermarket did not get the traction of e.g. github
> > > - last release date is probably the best indicator. In my 
> > experience most cookbooks that are not updated within the last 12 
> > months are outdated, e.g. won’t work with the recent distros like 
> > Debian 8 or CentOS/RHEL 7. How should starters „know“ this?
> > >
> > > Imagine a rather new chef user that needs to deal with systemd 
> > unit files. Just with that single „trap" he/she will probably lose 
> > a couple of hours or days or give up and pick something else with 
> > batteries included.
> > >
> > > I’m sure this is not intentional and everyone had the best 
> > intentions doing it the current way - but IMHO it’s broken :-/
> > > IMHO it’s all about hitting the right spot in between of „too 
> > much“ and „too little“ and the original opscode-cookbooks concept 
> > was probably a „too much“-problem and today it looks like we’re in 
> > a „too little“ situation.
> > >
> > >
> > >> why should community maintainers maintain a cookbook? - many. 
> > and i dont see the different of this with ruby gem, or any 
> > userspace tool (pyhton egg, or a debian in ppa).  But the common 
> > reasons are: 1) you dont want to reinvent wheel,. if theres no 
> > opensource cookbook on ossec, every time i join a place it allows 
> > me rapidly roll out ossec cookboook. 2) my job depends on my 
> > skills/knowledge, to get a better job, i need to improve my skill. 
> > but that not possible if theres no one to mentor inside my own org. 
> > opensource brings that possibility. again this is not specific to 
> > chef, its very opensource thing, if you dont understand it, or dont 
> > know what value you get, dont do it. but for those of us, who are 
> > outside chef, uses it, and loves it. exposure is a huge thing, i 
> > cant become oracle reporting expert, but i can become chef expert 
> > even if dont have much money.
> > >
> > > Sorry, but that doesn’t answer my question. Many open source 
> > projects start, when something (technology, framework) becomes 
> > „hot“. Everyone is trying to learn and get a spot in the eco 
> > system. Popularity usually also means a rising number of jobs, e.g. 
> > people can get their OSS contribution funded and/or get an 
> > interesting job. However this strategy starts to collapse when the 
> > crowd moves on to „even hotter“ things (typical hype lifecycle).
> > >
> > > Example 1: now outdated Ruby gems -> maintainer moved to node ->  
> > now outdated npm modules -> maintainer moved to Go.
> > > Example 2: cfengine -> puppet -> chef -> ansible -> docker
> > >
> > > This brain-drain affects not only the quantity but also the 
> > quality of projects. Less „eyes“ to find bugs, less „hands“ to fix 
> > them, less users to use it. Experience for new users will suffer.
> > > Why should people contribute to $not_hot_anymore projects? I 
> > don’t see that many unique chef-jobs, so having something in the 
> > GitHub repo/CV doesn’t bring you new opportunities by itself.
> > > Even a popular (>200 stars on GH) knife plugin for some trending 
> > and cheap cloud hosting provider brings you exactly 0 job/project 
> > offers (btdt).
> > >
> > > possible options:
> > >
> > > - provide minimal services that work out of the box by yourself 
> > (Chef, Inc)
> > > - subsidize community to maintain it (you pay, you decide how)
> > > - offer opportunities so people can benefit from supporting the 
> > community (e.g. job site, contract projects, sales-partnerships 
> > with indies)
> > >   otoh: As far as I can see, most „Chef certified partners“ 
> > listed on  https://www.chef.io/partners/#find-a-partner are not ;
> > part of the community and some companies that provide value to the 
> > community are not listed there at all…
> > >
> > >
> > >> the last statement you made regarding namespace, is a technical 
> > problem. again its no different here than any other place. for 
> > example redhat has libvirt-lxc which everyone confuses with 
> > standard LXC but the project itself has little code/feature 
> > compatibility with main LXC. The point is like namespace is 
> > perceived, if you want you can publish a cookbook with samename and 
> > if its really good (and assuming theres enough people who wants it) 
> > you can definitely outweigh the other cookbook. if thats not 
> > happening, lets address that.
> > >
> > > Your libvirt-example is great, as it shows why nearly nobody used 
> > it and why Docker has such a huge impact by just providing a fancy 
> > way to distribute tar archives and wrap some syscalls ;) 
> > (oversimplification intentional)
> > > Redhat isn’t very good  in community/relationship outside of 
> > their own Fedora/RHEL area. Just see how they „sell“ systemd to 
> > users, developers and admins. I think better tutorials and 
> > community-relations would have prevented that hatery/shitstorm 
> > against it.
> > > When I talk to systemd-"haters", I ask them to write me a sysv
> > -init script for a service, then I show them the systemd unit 
> > representation.
> > > When ansible users talk to me (chef user), they ask me to write a 
> > solution that… whops. damn. You understand what I mean?
> > >
> > >> the definition of critical is very diverse, theres no common 
> > critical component/cookbook. nothing. 0. as far as the whole 
> > community is concerned. if you freeze platform  (since chef run 
> > from windows machine to raspberry pi to AIX to solaris) you might 
> > get a list of critical cookbooks (like sudo will be for linux), you 
> > might get another layer on family (like sysdtemd on ubuntu 15.04) 
> > .. we are in process of establishing the family specific 
> > maintainers, a similar effort can be made for cookbooks as well.. 
> > but will be mostly community and few core contributors .. similar 
> > to kernel and userspace..  linus and linux foundation or redhat 
> > does not maintain ruby specific rpm etc..
> > >
> > > Why do people need DevOps? To have a reliable infrastructure to 
> > provide services that make money and to stay competitive. Usually 
> > that involves more or less custom applications based on common 
> > frameworks/stacks that need to be deployed. So at least a couple of 
> > application deployment stacks are critical to show the benefits of 
> > a DevOps solution. Even the learn.chef.io tutorial falls apart, 
> > when you’re using the latest releases of cookbooks used in the 
> > tutorial, so this is also a good definition of critical.
> > >
> > >> i am very interested in addressing this.. please keep your 
> > thoughts pouring :-) , but understand we cant solve it in a click, 
> > its gonna take some time, we have to keep talking, and out 
> > collaborative efforts on the next blockers toward this direction.
> > >
> > >
> > >> fwiw i am the LT of chef on ubuntu, and i am working on a CD 
> > system that will test actual community cookbooks on every master 
> > merge of chef. Which will greatly reduce the maintenance burden, 
> > cause now core devs can also see what affect the changeset has. 
> > Next step will be do a survey and get a list of cookbooks and 
> > interested folks (brigade as we calling it) for ubuntu. What i 
> > wonder is a common pool might not make sense, though Chef is cross 
> > platform, majority of cookbook is not.
> > >
> > > You don’t need a fancy distro/edge-case. Just make sure Debian 8, 
> > RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t 
> > mean something like „it installs runit triggered by sysv-init — and 
> > it still works…“ on a systemd distro ;-)
> > >
> > >
> > > regards
> > > Roland
> > >
> > > PS: Despite all my examples I’m not a systemd zealot. I was okay 
> > with upstart… But a common base of various distros is a good thing 
> > for everyone in the long run. And it’s also a good example for a 
> > game-changer and about the agility/adoption capabilities of such 
> > things.
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >> hth
> > >> ranjib
> > >>
> > >> On Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz 
> > >> <
 >
> > >>  
> > wrote:
> > >>
> > >> > Am 22.06.2015 um 22:52 schrieb Julian C. Dunn <
> > 
 >:
> > >> >
> > >> > On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob 
> > >> > <
 >
> > >> >  
> > wrote:
> > >> >
> > >> >> To speak for Chef Software directly, we have always had 
> > people on staff
> > >> >> whose role was assisting the creation and maintenance of 
> > cookbooks. That
> > >> >> number has fluctuated up and down over time, with the skill 
> > sets of people
> > >> >> we hire, and the normal day-to-day ebb and flow of trying to 
> > figure out how
> > >> >> to build a business that is successful. We have people on 
> > staff today who do
> > >> >> the same. What is clear is that the energy around cookbooks 
> > in the community
> > >> >> is far greater than the energy we can muster as an 
> > organization (regardless
> > >> >> of how much capital we do or do not have - y'all outnumber 
> > us) - and so our
> > >> >> focus today is on trying to build and support the best 
> > community we can,
> > >> >> through development of the supermarket, better tooling, and 
> > providing a few
> > >> >> key examples of how best to build a community cookbook (see 
> > Sean's work on
> > >> >> the httpd cookbook.)
> > >> >>
> > >> >> Perhaps we need to organize a PR/merge festival brigade?
> > >> >
> > >> > Hey Adam,
> > >> >
> > >> > Would we consider transferring some of those cookbooks our of
> > >> > {opscode,chef}-cookbooks to a community-organized org like
> > >> > chef-brigade (https://github.com/chef-brigade) or redguide
> > >> > (https://github.com/redguide) for better maintenance? What 
> > would be
> > >> > the preconditions to doing that?
> > >> >
> > >> > Personally I would like the chef-brigade and redguide to be 
> > merged,
> > >> > but I do not remember all the players involved -- if they are 
> > on this
> > >> > list perhaps they can speak up.
> > >>
> > >>
> > >> How would this prevent the problems that happend with the last 
> > migration of former opscode-cookbooks to community maintainers?
> > >>
> > >> Why should community maintainers care about the cookbooks in the 
> > future?
> > >> It can be a time consuming burden and people need to pay their 
> > rent and do their regular jobs…
> > >>
> > >> I know, this will be very provoking, but:
> > >>
> > >> If Chef, inc. doesn't want to maintain even critical cookbooks 
> > anymore, is there still a valid reason for running a public 
> > Supermarket site?
> > >> If you go the "libertarian way" there is no reason for a 
> > supermarket site to protect/block names of cookbooks anymore that 
> > prevents users to pick other, maybe better community resources over 
> > legacy-cookbooks that are mentioned in guides and examples.
> > >>
> > >> Either you (Chef, Inc.) control the market (e.g. maintain 
> > critical things yourself) or you should allow the free market 
> > (=community) to compete against each other based on equal 
> > opportunity (= namespaces or no supermarket). Everything else/in 
> > between will just end in chaos and anarchy.
> > >>
> > >> regards
> > >> Roland
> > >>
> > >>
> > 
> > 
> 
>