Community cookbook maintenance (was: Re: Reprepro cookbook)

[jdunn]

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.

• Julian

[Roland_Moriz1]

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

[Drew_Blessing1]

Roland,

A discussion about whether Chef Software continues to maintain cookbooks
has little to do with whether Supermarket is valuable. Even if Chef
Software maintains zero cookbooks the Supermarket is a huge community asset
(consider RubyGems). Let's not muddy the waters here.

On Mon, Jun 22, 2015 at 4: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

--
Drew

[Ranjib]

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).

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.

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.

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

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.

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

[Roland_Moriz1]

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&platforms[]= https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=

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

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

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

[nathwill]

interesting topic. pretty recently, my "one word description" for community
cookbooks was "cesspool", though i think that's getting a little better
lately, and now i'd have to choose a nicer word :). even so, cookbook
quality is definitely an area where we, as a community could benefit from
ongoing effort.

obviously, Chef Inc can't do all the heavy lifting, nor would they be the
most qualified in many cases. the old "official" cookbook thing was a nice
bootstrap technique, but even those weren't always the best available
cookbook, though they at least usually had a healthy number of eyes on them.

i'd be really bummed to see us going back to a model where Chef Inc is
directly, or through contractors, propping up the cookbook ecosystem, but i
do think more could be done than is happening now.

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 (

chef-boneyard/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.

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&platforms[]=
https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&platforms[]=

• 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 (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 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

[ssd]

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 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&platforms[]=

• 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 (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 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

[Roland_Moriz1]

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 (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. 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&platforms[]=

• 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 (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 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

[nathwill]

On Thu, 2015-06-25 at 12:57 +0200, Roland Moriz 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").

Yeah, definitely some potential pitfalls, but cookbooks are already
linted with foodcritic on upload to the supermarket, and I'm sure there
exist lots of other ways to pre-screen or delegate to community efforts
like chef-brigade/redguide to lower the review burden. And yeah,
denying/revoking certification would be where the scope ends; I don't
see that as a bad thing, the sole objective of certification would be
to make it easier to find the high-quality cookbooks in a world where
the one with the simplest/most obvious name may've just been first out
of the gate.

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.

i don't think that's pressure, just incentive, though i can see how
some might view it that way.

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.

None of this is chef specific; it seems more like you're questioning
the open-source development model, which IMO is doing just fine.

just to speak for myself, there's no way we, at $current_job would have
been able to accomplish as much as we have over the last year without
community cookbooks to help us get up and running. there've been a few
instances where the available community cookbooks didn't fit our needs,
and the differences were vast enough that a PR wasn't a reasonable
solution, but we're not that special, so those new cookbooks got open
-sourced too. for the majority, especially the more common components,
we've been able to benefit from steady, sustained improvement without
any investment aside from the time it takes to update our version
pinning and fix (mostly) minor breakages in our wrappers.

as for the cookbooks i've released, it's been well worth the time spent
maintaining to get the benefit of other people's opinions in the form
of issues and PRs, which help to improve things with pretty minimal
effort on my part. plus, people in this community are awesome, and it's
fun to engage with folks and find out how they're using something.

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

i don't think this is true at all. one would have to be pretty out of
touch to fail to distinguish between core product and product
extensions, or company & community. if someone makes that mistake and
either leaves without seeking help (and having said misconception
subsequently corrected), or has enough sense of entitlement to be so
demanding, good riddance.

regards,

nathan w

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&plat
forms%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
(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 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]

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.

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.

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.

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 (
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. 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&platforms[]=

• 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 (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 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

[tknerr]

I like the suggestion Nathan proposed, i.e. that we have some kind of
objective measure of quality for cookbooks.

Probably repeating, but that's what I'm thinking might possibly go into
such a "quality score" and should be prominently exposed in the supermarket:

• having foodcritic, chefspec and kitchenci in place at all
  ​

• number of supported platform as in metadata vs kitchen tested platforms
  ​- build information (including kitchenci!) publicly available​

​​
number of tests run and code coverage per platform

• ratio of open vs. closed github issues
• mean time to response for github issues / pull requests (that might be a
  hard one ;-))

Having that visibility / transparency in supermarket would probably make
the judgment about quality easi
​er ​
and be only the first step.​

​The harder part is getting quality in. Sean did a great example with the
httpd cookbook, but as Roland said, for most community maintainers the
reality is probably "
If your shop uses Debian X, you just don't care about some PR for CentOS Y
that much
​".

I don't​ really know how to solve this, just these two ideas (also already
mentioned, probably):
​

1. I could imagine that b
   ounty programs
   ​ could be effective ​
   ​, especially if
   they offer some kind of monetary rewards (or free confernece tickets etc)
   for working on community cookbooks
   ​ (which is a free time / spare time affair for quite a few of us, I guess)

2. a sponsored build system for community cookbooks would probably help,
   too. Most commity cookbooks have their kitchenci builds not running /
   publicly visible, but this is essential from a maintainer's perspective
   (think of kitchenci builds for pull requests). Personally I'm using
   CircleCI free tier, which lets you run kitchenci suites with the docker
   provider and up to 4x parallelism, but eventually that's not enough if you
   support a whole number of platforms * test suites​

​Cheers,
Torben​​

Am 25.06.2015 12:57 schrieb "Roland Moriz" rmoriz@gmail.com:

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 (
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. 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&platforms[]=

• 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 (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 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

[Ranjib]

my suggestion for this was to add badges. like foodcritics, chefspec, tk,
etc.. quality related badges as well as platform support related badges,
and allow consumer to filter by those badges, extend the same worlkflows to
knife cookbook download. But that whole thing relies on a build grid that
is capable of assigning those badges automatically... also im not sure if
this can be applied to all the platforms /scenarios.. but none the less it
address some of the issues.

On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> 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.

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.

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.

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 (
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. 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&platforms[]=

• 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 (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 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

[Torben_Knerr]

@Rabjib +1

P.S. on this:

1. I could imagine that b
   ounty programs
   ​ could be effective ​
   ​, especially if
   they offer some kind of monetary rewards (or free confernece tickets etc)
   for working on community cookbooks
   ​ (which is a free time / spare time affair for quite a few of us, I guess)

...or just stickers, or t-shirts, etc... it's not about the money, but
something where you'd feel that's worth putting effort into for.
On the other hand, building a business around improving cookbook quality
does not sound too bad either...

On Thu, Jun 25, 2015 at 6:28 PM, Ranjib Dey dey.ranjib@gmail.com wrote:

my suggestion for this was to add badges. like foodcritics, chefspec, tk,
etc.. quality related badges as well as platform support related badges,
and allow consumer to filter by those badges, extend the same worlkflows to
knife cookbook download. But that whole thing relies on a build grid that
is capable of assigning those badges automatically... also im not sure if
this can be applied to all the platforms /scenarios.. but none the less it
address some of the issues.

On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> 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.

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.

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.

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 (
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.
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&platforms[]=

• 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 (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 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

[Roland_Moriz1]

Am 25.06.2015 um 18:11 schrieb Yoshi Spendiff yoshi.spendiff@indochino.com:
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.

Actually, that's exactly what I tried with some cookbooks that are relevant to my interest. In one case I got the answer, that a rewrite is in the works and current issues/PR probably won't be handled. I was told to go through the open issues to make a triage easier.

Which I did. Problem: Still nothing happend.

Forking doesn't help, neither does Supermarket: If you use Berkshelf, at least for CI, then you would have to recursively change all Berksfiles to use your fork ("cookbook 'whatever', github: 'user/repo' "), given that you don't change the name of the cookbook.
If you miss one, you'll gonna have a bad time.™

If you decide to do a "orgname-cookbookname" rename-fork, good luck with changing all LWRPs…

regards
Roland

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.

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.

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 (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. 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&platforms[]=

• 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 (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 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

[nathwill]

On Thu, 2015-06-25 at 09:28 -0700, Ranjib Dey wrote:

my suggestion for this was to add badges. like foodcritics, chefspec,
tk, etc.. quality related badges as well as platform support related
badges, and allow consumer to filter by those badges, extend the same
worlkflows to knife cookbook download. But that whole thing relies on
a build grid that is capable of assigning those badges
automatically... also im not sure if this can be applied to all the
platforms /scenarios.. but none the less it address some of the
issues.
i do really like the idea of badges, especially since it's not an all
-or-nothing proposition like "compliance", and it's not as subjective
as something like a rating system. +1

On Thu, Jun 25, 2015 at 9:11 AM, Yoshi Spendiff > yoshi.spendiff@indochino.com> 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.> >
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.> >
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.

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 (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. 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&platforms[]=

• 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 (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 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

[nathwill]

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

[David_Joos]

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

[Fitzwater_Brian_K_CT]

On Thu, 2015-06-25 at 13:26 -0400, Nathan Williams wrote:

ratings systems are great for popularity, but they often miss the mark for quality.

TornadoGuard

[Trevor_Hess]

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?

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

Am 24.06.2015 um 17:33 schrieb Nathan Williams <
nath.e.will@gmail.commailto: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-supporthttp://github.com/chef/chef-rfc/blob/master/rfc021-platform-support
-policy.mdhttp://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.commailto:rmoriz@gmail.com>
wrote:
Hi,

Am 23.06.2015 um 00:23 schrieb Ranjib Dey <dey.ranjib@gmail.commailto: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
(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.iohttp://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 <rmoriz@gmail.commailto:rmoriz@gmail.com>
wrote:

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

On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob <adam@chef.iomailto: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

[Roland_Moriz1]

Am 25.06.2015 um 18:05 schrieb Nathan Williams nath.e.will@gmail.com:

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

i don't think this is true at all. one would have to be pretty out of
touch to fail to distinguish between core product and product
extensions, or company & community. if someone makes that mistake and
either leaves without seeking help (and having said misconception
subsequently corrected), or has enough sense of entitlement to be so
demanding, good riddance.

Here is a RL example of a large, profitable, well-known web-company (2014) with a few hundred nodes:

Team lead told me that they "trust their employees", not a single tool (or me as beeing just a contractor). If something doesn't work, they will question the tool, especially when the team could not make it work (anymore), everyone complained about the tool and the single guy that originally started using Chef left some time ago, anyways.

So nobody there gets fired for blaming Chef (tool).

Truth behind is: It's cheaper for them to start over with like $something_else_that_may_work_with_the_team than to start over with a new team. Experts are rare and too expensive. Failing tools/frameworks/workflows are accepted, because "this is true innovation"…

So IMHO they best way to persuade devops and management people, is to show the benefits of a solution in action. No marketing slides, no "Facebook uses it, too, they always use good stuff!". Just a typical use case of the company to shows that Chef works great, if used the right way.

And here we are: Examples, Cookbooks, things that work out of the box and are up to date.
Things, people can imitate to build experience and trust — to expand their knowledge and finaly build something their own upon it.

People don't want to ask a single expert about every problem because it makes them feel dumb. So they try Google, StackOverflow or GH issues instead. When questioners show very little undestanding of chef (tool), they are not everytime "trolls" or lazy, it might be a documentation and eco-system problem.

"You've a solution for every chef-related problem I have" may first sound flattering, but it also shows that you're SPOF, so this is a backhanded compliment.

regards
Roland

regards,

nathan w

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&plat
forms%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
(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 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