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