Community cookbook maintenance (was: Re: Reprepro cookbook)

Chef Infra (archive)
21

Am 25.06.2015 um 19:41 schrieb Trevor Hess thess@10thmagnitude.com:

What about an upvote/downvote system? It can be abused too, but what if a downvote required a linked issue on the repository?
Then badges could be related to the way a maintainer responds to issues?

The problem is time and changes.

Cookbooks that were great in 2011 wont necessarily be usable today.
Cookbooks that look great today may explode or just abandoned some time in the future.

You would need a reddit/HN-like system to expire ratings.

But still this implies ultimate trust in the voters to "know" if a cookbook is good or not.

If people don't know it or don't want to (re-)vote it's IMHO useless.

It's like real world democracy: Proper education + "auto-expiration" of trust.

Roland

--
T

From: David Joos [mailto:david.joos@gmail.com]
Sent: Thursday, June 25, 2015 12:32 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Community cookbook maintenance (was: Re: Reprepro cookbook)

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.

Yeah, I think that is also the reason why when the transition was made from the old "Chef community cookbooks"-catalog to the current "Chef Supermarket", the option to rate cookbooks was ditched.

+1 for the idea of badges though

2015-06-25 18:25 GMT+01:00 Nathan Williams nath.e.will@gmail.com:
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 rmoriz@gmail.com
wrote:

Am 24.06.2015 um 17:33 schrieb Nathan Williams <
nath.e.will@gmail.com>:
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.
GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service (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 rmoriz@gmail.com
wrote:
Hi,

Am 23.06.2015 um 00:23 schrieb Ranjib Dey dey.ranjib@gmail.com
:

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=✓&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 Partners | Chef 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 :wink:
(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 :slight_smile: , 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 :wink:

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 rmoriz@gmail.com
wrote:

Am 22.06.2015 um 22:52 schrieb Julian C. Dunn <
jdunn@aquezada.com>:

On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob adam@chef.io
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
(redguide · GitHub) 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

22

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

Actually I haven't, but I just went and had a look at a bunch of cookbooks
that I've used and don't see anything about it, so I'm guessing it's only
for flagging projects. It would be good to have it a step up where someone
who wants to contribute continuously has some way to communicate this to
the cookbook owner. Something a bit more formal than a bunch of pull
requests.

Thinking about it badges would be a lot more useful than ratings, although
it's have to be a lot more clever than simply having the test directories
in your cookbook to get the ChefSpec badge, for example.

Being able to differentiate between supported platforms based on metadata
and platforms where builds pass could be useful too, as it might describe a
situation where a cookbook is 'almost there' for a platform and just needs
someone to tip it over the edge instead of re-inventing the wheel.

On Thu, Jun 25, 2015 at 10:25 AM, Nathan Williams nath.e.will@gmail.com
wrote:

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 rmoriz@gmail.com
wrote:

Am 24.06.2015 um 17:33 schrieb Nathan Williams <
nath.e.will@gmail.com>:
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.
GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service (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 rmoriz@gmail.com
wrote:
Hi,

Am 23.06.2015 um 00:23 schrieb Ranjib Dey dey.ranjib@gmail.com
:

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=✓&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 Partners | Chef 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 :wink:
(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 :slight_smile: , 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 :wink:

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 rmoriz@gmail.com
wrote:

Am 22.06.2015 um 22:52 schrieb Julian C. Dunn <
jdunn@aquezada.com>:

On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob adam@chef.io
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
(redguide · GitHub) 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

--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

23

A quick reaction on this two points from my sysadmin point if view

And here we are: Examples, Cookbooks, things that work out of the box and are up to date.

Nothing should go on a server 'out of the box', if you're giving a sight on a product, deploying through chef is a bad idea (kind of premature optimization). Specially on free open source code, you should have a look to it and understand what's going on before allowing it to run within your company network.

Things, people can imitate to build experience and trust — to expand their knowledge and finaly build something their own upon it.

Again, something working out of the box won't be read and understood, imitating something simplified is a bad idea as the author did make choices which could not be the best.

Packages install of popular things like apache or nginx are a good Exemple, you have something running with some guidances on what the best path is, but if you let it 'stock' you won't run a big website on it and you'll be vulnerable to attacks due to the default behavior.

When you're managing systems you need to understand what you allow to run on it as much as possible.

Again, this is my opinion, not a judgement or anything else.
The quality level has refrain me to open-source most of my work because it's way too specific in my point if view, hardening this to avoid the burden of understanding what's going on to future users sounds counter productive to me.

24

Arguing semantics here, but I took 'out of the box' in this case means that
it work as intended. Being able to control apache settings via attributes
and modules via recipes is working 'out of the box' even though the admin
is doing work to configure attributes and set run lists, which means you
need a level of understanding. A cookbook that doesn't work because it's a
year old and systems have changed isn't working 'out of the box'

On Thu, Jun 25, 2015 at 12:36 PM, Tensibai Zhaoying tensibai@iabis.net
wrote:

A quick reaction on this two points from my sysadmin point if view

And here we are: Examples, Cookbooks, things that work out of the box
and are up to date.

Nothing should go on a server 'out of the box', if you're giving a sight
on a product, deploying through chef is a bad idea (kind of premature
optimization). Specially on free open source code, you should have a look
to it and understand what's going on before allowing it to run within your
company network.

Things, people can imitate to build experience and trust — to expand
their knowledge and finaly build something their own upon it.

Again, something working out of the box won't be read and understood,
imitating something simplified is a bad idea as the author did make choices
which could not be the best.

Packages install of popular things like apache or nginx are a good
Exemple, you have something running with some guidances on what the best
path is, but if you let it 'stock' you won't run a big website on it and
you'll be vulnerable to attacks due to the default behavior.

When you're managing systems you need to understand what you allow to run
on it as much as possible.

Again, this is my opinion, not a judgement or anything else.
The quality level has refrain me to open-source most of my work because
it's way too specific in my point if view, hardening this to avoid the
burden of understanding what's going on to future users sounds counter
productive to me.

--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

25

Well, what makes me think this was not the intent is the "out of the box
AND up to date", but your definition is absolutely valid.

At end, I've just the feeling that when reading through a cookbook to
write a wrapper, you have a correct idea of it's quality, seeing the
LWRP and what they allow you and the the 'up to date'ness of the
attributes (usually I look to the version targeted) give good clues on
the work to be done before getting this cookbook working to the wished
state.

So why not for badges, but I find a little interest in them and I'm
worried it will increase the 'I clicked, clicked again and it's not
working but it has the (company blessig|validation badges|high ranking
from community), that's so bad and unprofessional !!!' symptom we saw at
the start of this thread with the Opscode in the README of a cookbook...

Perhaps I'm too negative, just sharing my though anyway :slight_smile:

Le 2015-06-25 23:36, Yoshi Spendiff a écrit :

Arguing semantics here, but I took 'out of the box' in this case means that it work as intended. Being able to control apache settings via attributes and modules via recipes is working 'out of the box' even though the admin is doing work to configure attributes and set run lists, which means you need a level of understanding. A cookbook that doesn't work because it's a year old and systems have changed isn't working 'out of the box'

On Thu, Jun 25, 2015 at 12:36 PM, Tensibai Zhaoying tensibai@iabis.net wrote:

A quick reaction on this two points from my sysadmin point if view

And here we are: Examples, Cookbooks, things that work out of the box and are up to date.

Nothing should go on a server 'out of the box', if you're giving a sight on a product, deploying through chef is a bad idea (kind of premature optimization). Specially on free open source code, you should have a look to it and understand what's going on before allowing it to run within your company network.

Things, people can imitate to build experience and trust -- to expand their knowledge and finaly build something their own upon it.

Again, something working out of the box won't be read and understood, imitating something simplified is a bad idea as the author did make choices which could not be the best.

Packages install of popular things like apache or nginx are a good Exemple, you have something running with some guidances on what the best path is, but if you let it 'stock' you won't run a big website on it and you'll be vulnerable to attacks due to the default behavior.

When you're managing systems you need to understand what you allow to run on it as much as possible.

Again, this is my opinion, not a judgement or anything else.
The quality level has refrain me to open-source most of my work because it's way too specific in my point if view, hardening this to avoid the burden of understanding what's going on to future users sounds counter productive to me.

--

Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

26

Hi everyone,

Just My 2 Cents as redguide founder:
Efforts done this months to improve cookbook community are really good
(supermarket, adoptions etc) and improve overall quality of cookbooks.
But what I REALLY miss to improve global quality of community cookbooks is
a Test-Kitchen CI linked to github.
Today I can easily test rubocop/foodcritic... but that's most of the time
not enough.. and testing all TK can be quite too long for a CK maintainer.
And, of course, I want badges for it :wink:

Le jeu. 25 juin 2015 à 23:37, Yoshi Spendiff yoshi.spendiff@indochino.com
a écrit :

Arguing semantics here, but I took 'out of the box' in this case means
that it work as intended. Being able to control apache settings via
attributes and modules via recipes is working 'out of the box' even though
the admin is doing work to configure attributes and set run lists, which
means you need a level of understanding. A cookbook that doesn't work
because it's a year old and systems have changed isn't working 'out of the
box'

On Thu, Jun 25, 2015 at 12:36 PM, Tensibai Zhaoying tensibai@iabis.net
wrote:

A quick reaction on this two points from my sysadmin point if view

And here we are: Examples, Cookbooks, things that work out of the box
and are up to date.

Nothing should go on a server 'out of the box', if you're giving a sight
on a product, deploying through chef is a bad idea (kind of premature
optimization). Specially on free open source code, you should have a look
to it and understand what's going on before allowing it to run within your
company network.

Things, people can imitate to build experience and trust — to expand
their knowledge and finaly build something their own upon it.

Again, something working out of the box won't be read and understood,
imitating something simplified is a bad idea as the author did make choices
which could not be the best.

Packages install of popular things like apache or nginx are a good
Exemple, you have something running with some guidances on what the best
path is, but if you let it 'stock' you won't run a big website on it and
you'll be vulnerable to attacks due to the default behavior.

When you're managing systems you need to understand what you allow to run
on it as much as possible.

Again, this is my opinion, not a judgement or anything else.
The quality level has refrain me to open-source most of my work because
it's way too specific in my point if view, hardening this to avoid the
burden of understanding what's going on to future users sounds counter
productive to me.

--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

27

Hey Guilhem,

You can actually run test-kitchen on CircleCI, even in a free tier (1 build
worker), which is often good enough.

Seems that not so many people are using it though, don't know why

Here's an example:

Cheers, Torben
Hi everyone,

Just My 2 Cents as redguide founder:
Efforts done this months to improve cookbook community are really good
(supermarket, adoptions etc) and improve overall quality of cookbooks.
But what I REALLY miss to improve global quality of community cookbooks is
a Test-Kitchen CI linked to github.
Today I can easily test rubocop/foodcritic... but that's most of the time
not enough.. and testing all TK can be quite too long for a CK maintainer.
And, of course, I want badges for it :wink:

Le jeu. 25 juin 2015 à 23:37, Yoshi Spendiff yoshi.spendiff@indochino.com
a écrit :

Arguing semantics here, but I took 'out of the box' in this case means
that it work as intended. Being able to control apache settings via
attributes and modules via recipes is working 'out of the box' even though
the admin is doing work to configure attributes and set run lists, which
means you need a level of understanding. A cookbook that doesn't work
because it's a year old and systems have changed isn't working 'out of the
box'

On Thu, Jun 25, 2015 at 12:36 PM, Tensibai Zhaoying tensibai@iabis.net
wrote:

A quick reaction on this two points from my sysadmin point if view

And here we are: Examples, Cookbooks, things that work out of the box
and are up to date.

Nothing should go on a server 'out of the box', if you're giving a sight
on a product, deploying through chef is a bad idea (kind of premature
optimization). Specially on free open source code, you should have a look
to it and understand what's going on before allowing it to run within your
company network.

Things, people can imitate to build experience and trust — to expand
their knowledge and finaly build something their own upon it.

Again, something working out of the box won't be read and understood,
imitating something simplified is a bad idea as the author did make choices
which could not be the best.

Packages install of popular things like apache or nginx are a good
Exemple, you have something running with some guidances on what the best
path is, but if you let it 'stock' you won't run a big website on it and
you'll be vulnerable to attacks due to the default behavior.

When you're managing systems you need to understand what you allow to run
on it as much as possible.

Again, this is my opinion, not a judgement or anything else.
The quality level has refrain me to open-source most of my work because
it's way too specific in my point if view, hardening this to avoid the
burden of understanding what's going on to future users sounds counter
productive to me.

--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com