Introducing the httpd cookbook

Hello Chefs!

I just pushed version 0.1.0 of the httpd cookbook, which you can find here:

I'm looking for feedback and initial testers, to help shake the bugs
out ahead of pushing a 1.0.0.

It's meant to be a "shining cookbook on the hill" that people can
reference as an example for creating highly re-usable cross platform
cookbooks.

Cross-platform cookbooks have been a huge source of frustration for a
long time now... Hopefully the design pattern represented here can
lead us out of the darkness.

Features -

  • Tested on Debian 7, Ubuntu 12.04 and 14.04, Centos5, Centos6, and Centos7
  • 2.2 and 2.4 support where appropriate
  • Supports multiple Apache instances on the same machine
  • Platform native idioms: no more "ubuntufying" rhel distros. (selinux
    should work!)
  • Modularity. httpd_config and httpd_module are used to implement httpd_service
  • No recipes! This cookbooks is meant to provide primitives... an
    extension of Chef.
  • Platform providers: resource patterns are self contained for extensibilty
  • Init system extensibility: subclassing for sysvinit vs systemd, etc
  • Full test coverage: developed from the ground up as a piece of Test
    Driven Infrastructure: 28 test-kitchen runs and 1936 specs

Known issues:

  • The README needs a lot of love
  • The primitives may be a bit too primitive.. httpd_service only
    loads enough modules to get itself running. Users may expect more
  • Needs a roadmap

Let me know what you think!

-s

Almost forgot:
This cookbook comes with an Official Release Soundtrack: http://bit.ly/1l1JKw0

On Fri, Aug 22, 2014 at 5:28 PM, Sean OMeara someara@opscode.com wrote:

Hello Chefs!

I just pushed version 0.1.0 of the httpd cookbook, which you can find here:

GitHub - chef-boneyard/httpd: DEPRECATED: Library cookbook with Apache httpd primitives

I'm looking for feedback and initial testers, to help shake the bugs
out ahead of pushing a 1.0.0.

It's meant to be a "shining cookbook on the hill" that people can
reference as an example for creating highly re-usable cross platform
cookbooks.

Cross-platform cookbooks have been a huge source of frustration for a
long time now... Hopefully the design pattern represented here can
lead us out of the darkness.

Features -

  • Tested on Debian 7, Ubuntu 12.04 and 14.04, Centos5, Centos6, and Centos7
  • 2.2 and 2.4 support where appropriate
  • Supports multiple Apache instances on the same machine
  • Platform native idioms: no more "ubuntufying" rhel distros. (selinux
    should work!)
  • Modularity. httpd_config and httpd_module are used to implement httpd_service
  • No recipes! This cookbooks is meant to provide primitives... an
    extension of Chef.
  • Platform providers: resource patterns are self contained for extensibilty
  • Init system extensibility: subclassing for sysvinit vs systemd, etc
  • Full test coverage: developed from the ground up as a piece of Test
    Driven Infrastructure: 28 test-kitchen runs and 1936 specs

Known issues:

  • The README needs a lot of love
  • The primitives may be a bit too primitive.. httpd_service only
    loads enough modules to get itself running. Users may expect more
  • Needs a roadmap

Let me know what you think!

-s

Does this or should this replace the existing Apache cookbooks?

On 8/22/14, 5:28 PM, "Sean OMeara" someara@opscode.com wrote:

Hello Chefs!

I just pushed version 0.1.0 of the httpd cookbook, which you can find
here:

GitHub - chef-boneyard/httpd: DEPRECATED: Library cookbook with Apache httpd primitives

I'm looking for feedback and initial testers, to help shake the bugs
out ahead of pushing a 1.0.0.

It's meant to be a "shining cookbook on the hill" that people can
reference as an example for creating highly re-usable cross platform
cookbooks.

Cross-platform cookbooks have been a huge source of frustration for a
long time now... Hopefully the design pattern represented here can
lead us out of the darkness.

Features -

  • Tested on Debian 7, Ubuntu 12.04 and 14.04, Centos5, Centos6, and
    Centos7
  • 2.2 and 2.4 support where appropriate
  • Supports multiple Apache instances on the same machine
  • Platform native idioms: no more "ubuntufying" rhel distros. (selinux
    should work!)
  • Modularity. httpd_config and httpd_module are used to implement
    httpd_service
  • No recipes! This cookbooks is meant to provide primitives... an
    extension of Chef.
  • Platform providers: resource patterns are self contained for
    extensibilty
  • Init system extensibility: subclassing for sysvinit vs systemd, etc
  • Full test coverage: developed from the ground up as a piece of Test
    Driven Infrastructure: 28 test-kitchen runs and 1936 specs

Known issues:

  • The README needs a lot of love
  • The primitives may be a bit too primitive.. httpd_service only
    loads enough modules to get itself running. Users may expect more
  • Needs a roadmap

Let me know what you think!

-s

Maybe, and "not yet."

This is definitely not a drop-in replacement for the apache2
cookbook. Apache2, for example, provides a "web_app" definition that
operates at a much higher level of abstraction. This cookbook could
theoretically be used to implement (parts of the) apache2 cookbook.

Apache2 currently has more platform support, is battle tested, etc.

-s

On Fri, Aug 22, 2014 at 5:41 PM, Durfee, Bernie (GE Global Research)
bernie.durfee@ge.com wrote:

Does this or should this replace the existing Apache cookbooks?

On 8/22/14, 5:28 PM, "Sean OMeara" someara@opscode.com wrote:

Hello Chefs!

I just pushed version 0.1.0 of the httpd cookbook, which you can find
here:

GitHub - chef-boneyard/httpd: DEPRECATED: Library cookbook with Apache httpd primitives

I'm looking for feedback and initial testers, to help shake the bugs
out ahead of pushing a 1.0.0.

It's meant to be a "shining cookbook on the hill" that people can
reference as an example for creating highly re-usable cross platform
cookbooks.

Cross-platform cookbooks have been a huge source of frustration for a
long time now... Hopefully the design pattern represented here can
lead us out of the darkness.

Features -

  • Tested on Debian 7, Ubuntu 12.04 and 14.04, Centos5, Centos6, and
    Centos7
  • 2.2 and 2.4 support where appropriate
  • Supports multiple Apache instances on the same machine
  • Platform native idioms: no more "ubuntufying" rhel distros. (selinux
    should work!)
  • Modularity. httpd_config and httpd_module are used to implement
    httpd_service
  • No recipes! This cookbooks is meant to provide primitives... an
    extension of Chef.
  • Platform providers: resource patterns are self contained for
    extensibilty
  • Init system extensibility: subclassing for sysvinit vs systemd, etc
  • Full test coverage: developed from the ground up as a piece of Test
    Driven Infrastructure: 28 test-kitchen runs and 1936 specs

Known issues:

  • The README needs a lot of love
  • The primitives may be a bit too primitive.. httpd_service only
    loads enough modules to get itself running. Users may expect more
  • Needs a roadmap

Let me know what you think!

-s

I still cannot get this model of "all done by a wrapper cookbook using
LWRP". It is just simpler to read node values...

On Fri, Aug 22, 2014 at 6:28 PM, Sean OMeara someara@opscode.com wrote:

Hello Chefs!

I just pushed version 0.1.0 of the httpd cookbook, which you can find here:

GitHub - chef-boneyard/httpd: DEPRECATED: Library cookbook with Apache httpd primitives

I'm looking for feedback and initial testers, to help shake the bugs
out ahead of pushing a 1.0.0.

It's meant to be a "shining cookbook on the hill" that people can
reference as an example for creating highly re-usable cross platform
cookbooks.

Cross-platform cookbooks have been a huge source of frustration for a
long time now... Hopefully the design pattern represented here can
lead us out of the darkness.

Features -

  • Tested on Debian 7, Ubuntu 12.04 and 14.04, Centos5, Centos6, and Centos7
  • 2.2 and 2.4 support where appropriate
  • Supports multiple Apache instances on the same machine
  • Platform native idioms: no more "ubuntufying" rhel distros. (selinux
    should work!)
  • Modularity. httpd_config and httpd_module are used to implement
    httpd_service
  • No recipes! This cookbooks is meant to provide primitives... an
    extension of Chef.
  • Platform providers: resource patterns are self contained for extensibilty
  • Init system extensibility: subclassing for sysvinit vs systemd, etc
  • Full test coverage: developed from the ground up as a piece of Test
    Driven Infrastructure: 28 test-kitchen runs and 1936 specs

Known issues:

  • The README needs a lot of love
  • The primitives may be a bit too primitive.. httpd_service only
    loads enough modules to get itself running. Users may expect more
  • Needs a roadmap

Let me know what you think!

-s

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

I still cannot get this model of "all done by a wrapper cookbook using
LWRP". It is just simpler to read node values...

When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance. Then you start putting
arrays of hashes in your attributes. Since you're now looping over an
array and firing off a lot of resources you'll want to internally
implement that problem as LWRPs anyway. Then eventually you'll wind up
wanting to merge arrays in your attributes and you'll wind up on this
page eventually: Arrays and Chef Attributes – Noah Kantrowitz

Its much easier to just expose the LWRPs. Then the user can use node
attributes, drive them with databags, or just statically code them in
the LWRP.

I look at a little differently. I think, for most people, the promise of
shareable recipes that encode policy has failed. If you make them flexible
enough to matter (apaxhe2, say) you have a very complicated beast, when you
probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the end.

Adam
On Aug 22, 2014 6:31 PM, "Lamont Granquist" lamont@opscode.com wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

I still cannot get this model of "all done by a wrapper cookbook using
LWRP". It is just simpler to read node values...

When you go down that road you eventually wind up needing two of a thing
on a server and not just one instance. Then you start putting arrays of
hashes in your attributes. Since you're now looping over an array and
firing off a lot of resources you'll want to internally implement that
problem as LWRPs anyway. Then eventually you'll wind up wanting to merge
arrays in your attributes and you'll wind up on this page eventually:
Arrays and Chef Attributes – Noah Kantrowitz

Its much easier to just expose the LWRPs. Then the user can use node
attributes, drive them with databags, or just statically code them in the
LWRP.

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its
come at the
cost of years of fighting with it. I don't think the failures have
been enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/
<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

But why left node values forgotten? LWRP can be used with node values, for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

Well the idea is that should be up to you. So you can write a cookbook
that wraps that and exposes the node data that your organization needs
and then you can wrap that with application cookbooks that load up the
node data if that makes sense to you. Or else you can feed it from
databags if you like (and using databags to drive node data to drive
LWRPs is a layer of indirection that the databag-driven user does not
need). Or else you can just hard code it directly in the recipe because
you decide you don't need to search on that information. There's no one
best way to do that. But if node data makes sense to you, then you've
basically just written your wrapper cookbook there.

On 8/25/14, 8:22 AM, Bráulio Bhavamitra wrote:

But why left node values forgotten? LWRP can be used with node values,
for example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

Yep, agreed with all of that.  There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs.  The more
involved
members of the community have all come to that realization, but
its come at the
cost of years of fighting with it.  I don't think the failures
have been enumerated
clearly so that others understand it.


On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

    I look at a little differently. I think, for most people, the
    promise
    of shareable recipes that encode policy has failed. If you
    make them
    flexible enough to matter (apaxhe2, say) you have a very
    complicated
    beast, when you probably only needed 20 lines of it.

    I think it may well be that the having resources be the prime
    unit of
    re-use, rather than recipes, may well be the right abstraction
    in the end.

    Adam

    On Aug 22, 2014 6:31 PM, "Lamont Granquist"
    <lamont@opscode.com <mailto:lamont@opscode.com>
    <mailto:lamont@opscode.com <mailto:lamont@opscode.com>>> wrote:

        On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

            I still cannot get this model of "all done by a wrapper
            cookbook using
            LWRP". It is just simpler to read node values...


        When you go down that road you eventually wind up needing
    two of a
        thing on a server and not just one instance.   Then you start
        putting arrays of hashes in your attributes.  Since you're now
        looping over an array and firing off a lot of resources you'll
        want to internally implement that problem as LWRPs
    anyway.  Then
        eventually you'll wind up wanting to merge arrays in your
        attributes and you'll wind up on this page eventually:
    https://coderanger.net/arrays-__and-chef/

        <https://coderanger.net/arrays-and-chef/>

        Its much easier to just expose the LWRPs.  Then the user
    can use
        node attributes, drive them with databags, or just
    statically code
        them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br http://eita.org.br/

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo
é meu lar e todos nós somos cidadãos deste cosmo. Este universo é
a imaginação da Mente Macrocósmica, e todas as entidades estão
sendo criadas, preservadas e destruídas nas fases de extroversão
e introversão do fluxo imaginativo cósmico. No âmbito pessoal,
quando uma pessoa imagina algo em sua mente, naquele momento, essa
pessoa é a única proprietária daquilo que ela imagina, e ninguém mais.
Quando um ser humano criado mentalmente caminha por um milharal
também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a propriedade deste universo é de Brahma, e não dos microcosmos
que também foram criados pela imaginação de Brahma. Nenhuma
propriedade deste mundo, mutável ou imutável, pertence a um indivíduo
em particular; tudo é o patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values, for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

Seab and Lorent, I'm questioning the lack of use of node values in shared
cookbooks, not on wrapper cookbooks. This makes us more dependent on
wrapper cookbooks and needing a whole bunch of lines of code. This just
doesn't make sense!
Em 25/08/2014 13:15, "Sean OMeara" someara@opscode.com escreveu:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

Databags also doesn't make sense to me, they really make configuration not
self-contained.
https://coderanger.net/data-bags/

On Mon, Aug 25, 2014 at 12:44 PM, Lamont Granquist lamont@opscode.com
wrote:

Well the idea is that should be up to you. So you can write a cookbook
that wraps that and exposes the node data that your organization needs and
then you can wrap that with application cookbooks that load up the node
data if that makes sense to you. Or else you can feed it from databags if
you like (and using databags to drive node data to drive LWRPs is a layer
of indirection that the databag-driven user does not need). Or else you
can just hard code it directly in the recipe because you decide you don't
need to search on that information. There's no one best way to do that.
But if node data makes sense to you, then you've basically just written
your wrapper cookbook there.

On 8/25/14, 8:22 AM, Bráulio Bhavamitra wrote:

But why left node values forgotten? LWRP can be used with node values, for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
 https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

On Mon, Aug 25, 2014 at 1:15 PM, Sean OMeara someara@opscode.com wrote:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

Correct, except that I would still use the send method.

What I'm suggesting is that a code like this must be on the httpd cookbook,
so that people can use it very fast for simple cases, without a wrapper
cookbook
.

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

At some point you will need to write code though... Chef is "Infrastructure as Code". I totally understand the desire to touch a few attributes and have a fully working "thing", but that proves to be highly unsustainable both from a cookbook maintenance standpoint (it's hard to test) and from an infrastructure reasoning standpoint (it's very difficult to determine the "flow" of a cookbook's behavior when everything is driven by attributes).

The argument that you "need a bunch more lines of code" is a bit lost on me. JSON is still code, and it's arguable more complex and difficult to reason about that Ruby code. Just because it is not "Ruby" does not mean it is not "code". Every line in an attribute file, role, or environment JSON is code.

We took a similar approach with the Jenkins cookbook rewrite and only utilize attributes where they make sense. Everything else is treated as a Chef resource (just like user or package). This has given the cookbook significantly more power and we have heard feedback that many user's like this pattern.

  • Seth
    @sethvargo

On Aug 25, 2014, at 12:43 PM, Bráulio Bhavamitra brauliobo@gmail.com wrote:

Seab and Lorent, I'm questioning the lack of use of node values in shared cookbooks, not on wrapper cookbooks. This makes us more dependent on wrapper cookbooks and needing a whole bunch of lines of code. This just doesn't make sense!

Em 25/08/2014 13:15, "Sean OMeara" <someara@opscode.com mailto:someara@opscode.com> escreveu:
You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
<brauliobo@gmail.com mailto:brauliobo@gmail.com> wrote:

But why left node values forgotten? LWRP can be used with node values, for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist <lamont@opscode.com mailto:lamont@opscode.com>
wrote:

Yep, agreed with all of that. There's the detail of why shareable recipes
have failed, though, and have been replaced by LWRPs. The more involved
members of the community have all come to that realization, but its come
at the
cost of years of fighting with it. I don't think the failures have been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com mailto:lamont@opscode.com
<mailto:lamont@opscode.com mailto:lamont@opscode.com>> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/ <https://coderanger.net/arrays-__and-chef/>

<https://coderanger.net/arrays-and-chef/ <https://coderanger.net/arrays-and-chef/>>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra http://cirandas.net/brauliobo
http://eita.org.br http://eita.org.br/

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia

Using a wrapper cookbook you wouldn't need to set attributes if you didn't
want to. For example If in my org I know the absolute authority for
configuring httpd is my cookbook then I have no need for attributes and can
declare exactly what I want in the recipe. In your attribute model you
force someone like me to use attributes when he doesn't want too. With just
an LWRP model you get the most flexibility with the least amount of
assumptions on implementation.

Turns out high levels of flexibility with low levels of baked in
assumptions is what most people want in a shared cookbook. If you want
something that works out of the box then wait for someone to come along and
publish a more apache2 like cookbook that used this httpd library cook.

WRT Simple I contest that this is the more simple thing:

https_service "mything" do
listen 80
run_user "awesemo"
end

VS

https_service node[:some_namespace][:http_service_name] do
   listen  node[:some_namespace][:http_port]
   run_user  node[:some_namespace][:http_user]
end

Which one of those is easier to operate ? If it's that you just want to
set attributes in an environment or role. Then I would give you the benefit
and say yea maybe the library cook isn't as easy as the non-library
'attribute-driven' cookbook. In this case I would also argue that the
management and operation of that model will far outweigh the time of
building a simple 'top level' cookbook to build your thing that is
declarative and easy to reason about.

Thanks Sean for all the work on this http cookbook I look forward to
abusing it soon.

On Mon, Aug 25, 2014 at 9:52 AM, Bráulio Bhavamitra brauliobo@gmail.com
wrote:

On Mon, Aug 25, 2014 at 1:15 PM, Sean OMeara someara@opscode.com wrote:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

Correct, except that I would still use the send method.

What I'm suggesting is that a code like this must be on the httpd
cookbook, so that people can use it very fast for simple cases, without
a wrapper cookbook
.

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more
involved
members of the community have all come to that realization, but its
come
at the
cost of years of fighting with it. I don't think the failures have
been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

Everybody just keep calm and carry on loving Chef =)

Bráulio!

I totally understand where you're coming from. It's as if a million
blog posts, tutorials, and Vagrant files suddenly cried out in horror.
You can't add a resource directly to a run_list, and that's annoying.
Meau Culpa.

I love that this conversation is happening. Let's riff on this a bit.

First, lets address resources vs cookbooks, then we can talk about
dynamically driven cookbooks via node attributes.

Here's the thing. Chef is supposed to be easy. People think it's hard.
Its usually people's experience consuming community cookbooks that
drives this perception. Simple cookbooks grow in scope and complexity
over time, as platform support grows, new platform versions come out,
and new versions of the technology under automation are released.

We're trying to get back to here: http://bit.ly/1mIOlyG

I don't think this is controversial. The trend towards publishing
cookbooks that ship new resources is a direct result of this. Creating
a resource has a lot of advantages over cookbooks.... First, it forces
the author to write down the interface (via parameters), defines a
scope, creates a closure around variables, and defines a domain of
predictability.

Regarding the lack or recipes in this cookbook:

The reason I chose not to ship any recipes is because that's the
simplest possible thing to do. (from the my perspective.) Breaking the
normal consumption pattern of "run list add" or include_recipe, drives
home the primitive-ness of this cookbook. This is a Chef module that
provides a new autonomous test-and-repair-bot, not a piece of
opinionated policy.

You know what you should totally do? Repair that consumption pattern.

Be the person who writes the popular cookbook that consumes this.
Publish it on the Supermarket.
Have your cookbook be the one appears in all the blog posts and
tutorials. Drive it with attributes. Call it "dynamic_httpd", or
something more clever.

Shipping the primitives gives you the freedom to do that.

-s

On Mon, Aug 25, 2014 at 1:22 PM, Jesse Nelson spheromak@gmail.com wrote:

Using a wrapper cookbook you wouldn't need to set attributes if you didn't
want to. For example If in my org I know the absolute authority for
configuring httpd is my cookbook then I have no need for attributes and can
declare exactly what I want in the recipe. In your attribute model you force
someone like me to use attributes when he doesn't want too. With just an
LWRP model you get the most flexibility with the least amount of assumptions
on implementation.

Turns out high levels of flexibility with low levels of baked in assumptions
is what most people want in a shared cookbook. If you want something that
works out of the box then wait for someone to come along and publish a more
apache2 like cookbook that used this httpd library cook.

WRT Simple I contest that this is the more simple thing:

https_service "mything" do
listen 80
run_user "awesemo"
end

VS

https_service node[:some_namespace][:http_service_name] do
   listen  node[:some_namespace][:http_port]
   run_user  node[:some_namespace][:http_user]
end

Which one of those is easier to operate ? If it's that you just want to set
attributes in an environment or role. Then I would give you the benefit and
say yea maybe the library cook isn't as easy as the non-library
'attribute-driven' cookbook. In this case I would also argue that the
management and operation of that model will far outweigh the time of
building a simple 'top level' cookbook to build your thing that is
declarative and easy to reason about.

Thanks Sean for all the work on this http cookbook I look forward to abusing
it soon.

On Mon, Aug 25, 2014 at 9:52 AM, Bráulio Bhavamitra brauliobo@gmail.com
wrote:

On Mon, Aug 25, 2014 at 1:15 PM, Sean OMeara someara@opscode.com wrote:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

Correct, except that I would still use the send method.

What I'm suggesting is that a code like this must be on the httpd
cookbook, so that people can use it very fast for simple cases, without a
wrapper cookbook
.

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more
involved
members of the community have all come to that realization, but its
come
at the
cost of years of fighting with it. I don't think the failures have
been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of

a
thing on a server and not just one instance. Then you start
putting arrays of hashes in your attributes. Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway. Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically

code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua
mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que
também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

Hello Jesse,

It just seems strange to me put configuration values on mixed with other
ruby code, so your first example doesn't look fine to me. About the second
example, I had proposed something simpler for httpd and other cookbooks.

cheers,
bráulio

On Mon, Aug 25, 2014 at 2:22 PM, Jesse Nelson spheromak@gmail.com wrote:

Using a wrapper cookbook you wouldn't need to set attributes if you didn't
want to. For example If in my org I know the absolute authority for
configuring httpd is my cookbook then I have no need for attributes and can
declare exactly what I want in the recipe. In your attribute model you
force someone like me to use attributes when he doesn't want too. With just
an LWRP model you get the most flexibility with the least amount of
assumptions on implementation.

Turns out high levels of flexibility with low levels of baked in
assumptions is what most people want in a shared cookbook. If you want
something that works out of the box then wait for someone to come along and
publish a more apache2 like cookbook that used this httpd library cook.

WRT Simple I contest that this is the more simple thing:

https_service "mything" do
listen 80
run_user "awesemo"
end

VS

https_service node[:some_namespace][:http_service_name] do
   listen  node[:some_namespace][:http_port]
   run_user  node[:some_namespace][:http_user]
end

Which one of those is easier to operate ? If it's that you just want to
set attributes in an environment or role. Then I would give you the benefit
and say yea maybe the library cook isn't as easy as the non-library
'attribute-driven' cookbook. In this case I would also argue that the
management and operation of that model will far outweigh the time of
building a simple 'top level' cookbook to build your thing that is
declarative and easy to reason about.

Thanks Sean for all the work on this http cookbook I look forward to
abusing it soon.

On Mon, Aug 25, 2014 at 9:52 AM, Bráulio Bhavamitra brauliobo@gmail.com
wrote:

On Mon, Aug 25, 2014 at 1:15 PM, Sean OMeara someara@opscode.com wrote:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

Correct, except that I would still use the send method.

What I'm suggesting is that a code like this must be on the httpd
cookbook, so that people can use it very fast for simple cases, without
a wrapper cookbook
.

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more
involved
members of the community have all come to that realization, but its
come
at the
cost of years of fighting with it. I don't think the failures have
been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of

a

thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically

code

them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua
mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que
também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

Hello Seth,

It seems Chef needs more focus and orientation... As you are saying, there
is a shift in paradigm going on, without support to the previous model
(node attributes). That is pretty strange to me.

I really like to specify configuration values on roles/nodes because I get
a quick and general view of the configuration, independent of any code.

That the way I and others learned Chef. Again, more orientation is much
needed.

cheers,
bráulio

On Mon, Aug 25, 2014 at 2:22 PM, Seth Vargo sethvargo@gmail.com wrote:

At some point you will need to write code though... Chef is
"Infrastructure as Code". I totally understand the desire to touch a
few attributes and have a fully working "thing", but that proves to be
highly unsustainable both from a cookbook maintenance standpoint (it's hard
to test) and from an infrastructure reasoning standpoint (it's very
difficult to determine the "flow" of a cookbook's behavior when everything
is driven by attributes).

The argument that you "need a bunch more lines of code" is a bit lost on
me. JSON is still code, and it's arguable more complex and difficult to
reason about that Ruby code. Just because it is not "Ruby" does not mean it
is not "code". Every line in an attribute file, role, or environment JSON
is code.

We took a similar approach with the Jenkins cookbook rewrite and only
utilize attributes where they make sense. Everything else is treated as a
Chef resource (just like user or package). This has given the cookbook
significantly more power and we have heard feedback that many user's like
this pattern.

  • Seth
    @sethvargo

On Aug 25, 2014, at 12:43 PM, Bráulio Bhavamitra brauliobo@gmail.com
wrote:

Seab and Lorent, I'm questioning the lack of use of node values in shared
cookbooks, not on wrapper cookbooks. This makes us more dependent on
wrapper cookbooks and needing a whole bunch of lines of code. This just
doesn't make sense!
Em 25/08/2014 13:15, "Sean OMeara" someara@opscode.com escreveu:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist lamont@opscode.com
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more
involved
members of the community have all come to that realization, but its
come
at the
cost of years of fighting with it. I don't think the failures have
been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the promise
of shareable recipes that encode policy has failed. If you make them
flexible enough to matter (apaxhe2, say) you have a very complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit of
re-use, rather than recipes, may well be the right abstraction in the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two of a
thing on a server and not just one instance.   Then you start
putting arrays of hashes in your attributes.  Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.  Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can use
node attributes, drive them with databags, or just statically code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em

Hello Sean!

Again, there is a shift of paradigm going on. All the attribute overide
graph is now obselete with this wrapper cookbook logic. I'm worried that
the old model is being deprecated.

About the "dynamic_httpd" example, it really make evident the need from
users to configure things the old way. And it bogus that you need two
cookbooks for one simple thing!

cheers,
bráulio

On Mon, Aug 25, 2014 at 3:13 PM, Sean OMeara someara@opscode.com wrote:

Everybody just keep calm and carry on loving Chef =)

Bráulio!

I totally understand where you're coming from. It's as if a million
blog posts, tutorials, and Vagrant files suddenly cried out in horror.
You can't add a resource directly to a run_list, and that's annoying.
Meau Culpa.

I love that this conversation is happening. Let's riff on this a bit.

First, lets address resources vs cookbooks, then we can talk about
dynamically driven cookbooks via node attributes.

Here's the thing. Chef is supposed to be easy. People think it's hard.
Its usually people's experience consuming community cookbooks that
drives this perception. Simple cookbooks grow in scope and complexity
over time, as platform support grows, new platform versions come out,
and new versions of the technology under automation are released.

We're trying to get back to here: http://bit.ly/1mIOlyG

I don't think this is controversial. The trend towards publishing
cookbooks that ship new resources is a direct result of this. Creating
a resource has a lot of advantages over cookbooks.... First, it forces
the author to write down the interface (via parameters), defines a
scope, creates a closure around variables, and defines a domain of
predictability.

Regarding the lack or recipes in this cookbook:

The reason I chose not to ship any recipes is because that's the
simplest possible thing to do. (from the my perspective.) Breaking the
normal consumption pattern of "run list add" or include_recipe, drives
home the primitive-ness of this cookbook. This is a Chef module that
provides a new autonomous test-and-repair-bot, not a piece of
opinionated policy.

You know what you should totally do? Repair that consumption pattern.

Be the person who writes the popular cookbook that consumes this.
Publish it on the Supermarket.
Have your cookbook be the one appears in all the blog posts and
tutorials. Drive it with attributes. Call it "dynamic_httpd", or
something more clever.

Shipping the primitives gives you the freedom to do that.

-s

On Mon, Aug 25, 2014 at 1:22 PM, Jesse Nelson spheromak@gmail.com wrote:

Using a wrapper cookbook you wouldn't need to set attributes if you
didn't
want to. For example If in my org I know the absolute authority for
configuring httpd is my cookbook then I have no need for attributes and
can
declare exactly what I want in the recipe. In your attribute model you
force
someone like me to use attributes when he doesn't want too. With just an
LWRP model you get the most flexibility with the least amount of
assumptions
on implementation.

Turns out high levels of flexibility with low levels of baked in
assumptions
is what most people want in a shared cookbook. If you want something that
works out of the box then wait for someone to come along and publish a
more
apache2 like cookbook that used this httpd library cook.

WRT Simple I contest that this is the more simple thing:

https_service "mything" do
listen 80
run_user "awesemo"
end

VS

https_service node[:some_namespace][:http_service_name] do
   listen  node[:some_namespace][:http_port]
   run_user  node[:some_namespace][:http_user]
end

Which one of those is easier to operate ? If it's that you just want to
set
attributes in an environment or role. Then I would give you the benefit
and
say yea maybe the library cook isn't as easy as the non-library
'attribute-driven' cookbook. In this case I would also argue that the
management and operation of that model will far outweigh the time of
building a simple 'top level' cookbook to build your thing that is
declarative and easy to reason about.

Thanks Sean for all the work on this http cookbook I look forward to
abusing
it soon.

On Mon, Aug 25, 2014 at 9:52 AM, Bráulio Bhavamitra <brauliobo@gmail.com

wrote:

On Mon, Aug 25, 2014 at 1:15 PM, Sean OMeara someara@opscode.com
wrote:

You can absolutely use node attributes to drive your recipe... same
way you would use core Chef resource.

Your example would look more like this...

node['httpd']['services'].each do |service_name, val1, val2|
httpd_service service_name do
listen_ports val1
run_user val2
end
end

Correct, except that I would still use the send method.

What I'm suggesting is that a code like this must be on the httpd
cookbook, so that people can use it very fast for simple cases,
without a
wrapper cookbook
.

-s

On Mon, Aug 25, 2014 at 11:22 AM, Bráulio Bhavamitra
brauliobo@gmail.com wrote:

But why left node values forgotten? LWRP can be used with node
values,
for
example:

node[:httpd][:services].each do |service|
httpd_service do
service.each{ |key, value| send key, value }
end
end

Also, the provider could have a way to specify how node attributes
should
fill LWRP

cheers,
bráulio

On Sat, Aug 23, 2014 at 1:04 AM, Lamont Granquist <
lamont@opscode.com>
wrote:

Yep, agreed with all of that. There's the detail of why shareable
recipes
have failed, though, and have been replaced by LWRPs. The more
involved
members of the community have all come to that realization, but its
come
at the
cost of years of fighting with it. I don't think the failures have
been
enumerated
clearly so that others understand it.

On Fri Aug 22 18:54:45 2014, Adam Jacob wrote:

I look at a little differently. I think, for most people, the
promise
of shareable recipes that encode policy has failed. If you make
them
flexible enough to matter (apaxhe2, say) you have a very
complicated
beast, when you probably only needed 20 lines of it.

I think it may well be that the having resources be the prime unit
of
re-use, rather than recipes, may well be the right abstraction in
the
end.

Adam

On Aug 22, 2014 6:31 PM, "Lamont Granquist" <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

On Fri Aug 22 18:12:27 2014, Bráulio Bhavamitra wrote:

    I still cannot get this model of "all done by a wrapper
    cookbook using
    LWRP". It is just simpler to read node values...


When you go down that road you eventually wind up needing two

of

a
thing on a server and not just one instance. Then you start
putting arrays of hashes in your attributes. Since you're now
looping over an array and firing off a lot of resources you'll
want to internally implement that problem as LWRPs anyway.
Then
eventually you'll wind up wanting to merge arrays in your
attributes and you'll wind up on this page eventually:
https://coderanger.net/arrays-__and-chef/

<https://coderanger.net/arrays-and-chef/>

Its much easier to just expose the LWRPs.  Then the user can

use

node attributes, drive them with databags, or just statically

code
them in the LWRP.

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar
e todos nós somos cidadãos deste cosmo. Este universo é a imaginação
da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo
imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua
mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por
um
milharal também imaginado, a pessoa imaginada não é a propriedade
desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que
também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a
imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas,
preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina,
e ninguém mais. Quando um ser humano criado mentalmente caminha por um
milharal também imaginado, a pessoa imaginada não é a propriedade desse
milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por
isso a
propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste
mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra

--
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
Blog - Bráulio Bhavamitra
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
A problemática de hoje em dia - Bráulio Bhavamitra