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

[Roland Moriz < >]

> 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 
> (https://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&platforms%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
>> 
>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature