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

[Steven Danna < >]

> 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:

FWIW, I acquired this cookbook mostly by accident.  If anyone would
like to do something with it, please let me know.

On Wed, Jun 24, 2015 at 1:36 PM, 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
>>
>
>