On Tue, Feb 19, 2013 at 1:26 PM, Cassiano Leal cassianoleal@gmail.comwrote:
-----Original message-----
From:Joshua Timberman joshua@opscode.com
By all means, don't use the community cookbook if it doesn't fit your preference, use case, supported platforms or standards.
Totally understood. Unfortunately, when it comes to such a basic cookbook as Apache, that means foregoing a very large share of the benefit of Chef - too many community cookbooks depend on it.
I have been thinking about this problem for a while now. I believe that
what Chef needs here is something similar to Virtual Packages on the Debian
packaging system.
Basically, abstract notions of a functionality, whose actual
implementation is delegated to one or more packages (or in Chef's case,
cookbooks).
I really like the idea of "virtual" cookbooks. But...
The real problem here is that you then get into the API of the cookbook -
if I say I "depends apache2" then what i really mean is that i expect to be
able to call the apache2_module LWRP and have it do the right thing.
But what happens when the opscode cookbook changes the semantics of the
LWRP (and does it right, bumps the major version etc). How do you express
the version number of the LWRP? Do all apache2 cookbooks have to have the
same version number?
Or are we actually talking about a "SONAME" of a cookbook, which becomes a
collection of "symbols" (LWRPs in this case) with specific versions. Then I
can say I actually want apache2_module ~> 2.0 and don't care about anything
else in the cookbook.
Or is this overthinking the problem?
Thom,
I don't think you're overthinking it…
If we go down this path, apache2 should probably be a "pure virtual"
cookbook; you would then have apache2_debian or apache2_redhat. Obviously
apache2 would not depend on either, so it's your responsibility to put the
correct one on the run list.
Each "concrete" cookbook would set an attribute to advertise itself to the
apache2 cookbook.
LWRPs like apache2_module would only be facades that would delegate to
apache2_debian_module as appropriate (depending on that cookbook).
This would be mildly boring but easy work. What would be harder is
implementing apache2_redhat in a meaningful way that is also backward
compatible with existing cookbooks.
A
On Tue, Feb 19, 2013 at 2:44 PM, Thom May thom@clearairturbulence.orgwrote:
On Tue, Feb 19, 2013 at 1:26 PM, Cassiano Leal cassianoleal@gmail.comwrote:
-----Original message-----
From:Joshua Timberman joshua@opscode.com
By all means, don't use the community cookbook if it doesn't fit your preference, use case, supported platforms or standards.
Totally understood. Unfortunately, when it comes to such a basic cookbook as Apache, that means foregoing a very large share of the benefit of Chef - too many community cookbooks depend on it.
I have been thinking about this problem for a while now. I believe that
what Chef needs here is something similar to Virtual Packages on the Debian
packaging system.
Basically, abstract notions of a functionality, whose actual
implementation is delegated to one or more packages (or in Chef's case,
cookbooks).
I really like the idea of "virtual" cookbooks. But...
The real problem here is that you then get into the API of the cookbook -
if I say I "depends apache2" then what i really mean is that i expect to be
able to call the apache2_module LWRP and have it do the right thing.
But what happens when the opscode cookbook changes the semantics of the
LWRP (and does it right, bumps the major version etc). How do you express
the version number of the LWRP? Do all apache2 cookbooks have to have the
same version number?
Or are we actually talking about a "SONAME" of a cookbook, which becomes a
collection of "symbols" (LWRPs in this case) with specific versions. Then I
can say I actually want apache2_module ~> 2.0 and don't care about anything
else in the cookbook.
Or is this overthinking the problem?
I work in a centos shop, and we run the apache2 cookbook.
It probably took our guys about half an hour to get used to the new
location of things.
Would it be easier if we didn’t need to change? Sure.
But the fragmentation suggested here depends on a lot of developers on each
platform.
Every new feature added to apache2_debian would need to get added to
apache2_redhat and apache2_osx and apache2_freebsd, solaris, windows, etc.
Then there is testing and bug fixes for every new implementation of the
same feature.
With a limited set of people working towards a common goal, forcing the
platform to some sort of a standard allows for faster feature development,
faster bug detection, and more developers who’ll fix those bugs.
I’m personally in favor of less fragmentation here, as (in my opinion) it
gets more done with less rework. And if debian/ubuntu happens to be the
base for laying things out? so be it
I’ve also been down the road of in-place edits… shot myself in the foot
more times than I can count before i just threw up my hands and jumped on
the full-template bandwagon.
-jesse
On Tue, Feb 19, 2013 at 3:26 PM, Jesse Campbell hikeit@gmail.com wrote:
I work in a centos shop, and we run the apache2 cookbook.
It probably took our guys about half an hour to get used to the new
location of things.
Would it be easier if we didn't need to change? Sure.
But the fragmentation suggested here depends on a lot of developers on
each platform.
Every new feature added to apache2_debian would need to get added to
apache2_redhat and apache2_osx and apache2_freebsd, solaris, windows, etc.
Then there is testing and bug fixes for every new implementation of the
same feature.
Amen. I dare to say that unless someone puts their money where their mouth
is and starts coding an apache2_redhat cookbook, this is moot. And then as
you say we still have the maintenance problem.
Ultimately this cookbook may be blessed by Opscode, but it's still largely
maintained by the community--and so far it seems to me that the large
majority is ok with the status quo.
As someone else has mentioned earlier in the thread: this is an opportunity
for a consulting firm to jump in and sell a subscription to RHEL blessed
cookbooks that fully support Selinux and so on.
Andrea