[chef] Re: Re: Re: is anyone doing work on the PostgreSQL cookbook?

[Greg Symons < >]

Right now database has an explicit dependency on postgresql in the 
metadata. If postgresql were to add a dependency on database, it would 
indeed be a circular dependency. Librarian, at least, will choke on it; 
I think Berkshelf can handle it (see the circular dependency between 
RiotGames/artifact and RiotGames/nexus).

However, you're right, the postgresql cookbook _should_ have access to 
the LWRP for creating users. It seems that the providers for the 
database cookbook should probably live in  the cookbooks that the 
provider is for--i.e. the postgresql_database_user provider should be 
in the postgresql cookbook, and the mysql_database_provider should be 
in the mysql cookbook. At which point, I'm not sure whether the 
database cookbook should continue to be called the database cookbook, 
since all of its recipes are mysql specific.

On Wed 09 Jan 2013 11:58:02 AM CST, Julian C. Dunn wrote:
> Greg,
>
> I'm not so sure the dependency is really circular -- it's more like a
> co-dependency, since Chef computes the list of cookbooks at startup time.
>
> If we agree on that, it would be nicer, IMO, to replace some of the
> logic in the PostgreSQL cookbook wrt setting up the "postgres" user
> with a call to the user LWRP from the database cookbook.
>
> - Julian
>
> On Fri, Jan 4, 2013 at 3:29 PM, Greg Symons 
> <
>  
> <mailto:
>  >>
>  wrote:
>
>     I thought I had responded to this the first time I saw it, but
>     I've got some preliminary work on 2 at
>     http://github.com/__DrillingInfo/postgresql
>     <http://github.com/DrillingInfo/postgresql> on the 'di' branch,
>     but I just came up with that stuff based on reading the docs, so
>     if you've got something better, go ahead and ignore it. That work
>     is _not_ compatible with the latest postgresql cookbook, though;
>     it's on my todo list to make it so.
>
>     Enhancement (3) should probably be a separate cookbook that
>     depends on both postgresql and database. Circular dependencies are
>     bad.
>
>
>     On Thu 03 Jan 2013 09:22:36 AM CST, David Crane wrote:
>
>         My current work project is to distill my postgresql
>         administration experience
>         into chef cookbooks. Here's my project plan ...
>
>
>         (1) I began (COOK-2051) by broadening cookbook support from
>         debian to redhat
>         platform families and from PostgreSQL-8.4 to PostgreSQL-9.X.
>         In this, I
>         continued the recent approach of using common files.
>
>         (2) Compute attribute defaults to tune postgresql.conf to
>         hardware resources
>         detected by ohai.
>
>         (3) Write recipes to manage postgresql group/login roles
>         through data_bags,
>         which will greatly help with multiple-server shops such as ours.
>
>         (4) Further work might provide support for replication from a
>         postgresql master
>         server to a hot standby.
>
>         Enhancement (3) leads to the architectural question: Would it
>         be OK to
>         introduce a dependency so that opscode-cookbooks/postgresql uses
>         opscode-cookbooks/database resources? It provides a
>         database_user resource that
>         I need to implement my group/role recipes.