[chef-dev] Re: Re: possible fixes for COOK-1676 (mysql cookbook fails on first run on RHEL6)

[Adam Jacob < >]

Configuration management, in this era, is all about trusting that the things 
you are calling are going to do the "right thing", where "right thing" is 
defined by a different policy based on the choice of operating system you 
made in the beginning. If it's going to behave differently, you hope that you 
were on the list of folks paying attention to the change in policy. :)

Best,
Adam

On Oct 9, 2012, at 4:37 PM, Joseph Anthony Pasquale Holsten wrote:

> Both assume quite a bit about the implementation inside the package. If 
> things change in the package, potentially anything could go wrong. Most 
> likely though, the user or group for a service will be changed. That would 
> break both approaches.
> 
> There are two advantages to the explicit user/group resources: source 
> installs and resource idempotence. Source installs will need the accounts 
> to be created anyway, so this makes the installation of each more similar. 
> And it's also more explicit about what resources should exist, instead of 
> 'resetting' and depending on resources that are managed under our noses.
> 
> That said, the reset is the lightest touch approach, least error prone and 
> most reusable.
> 
> YAY BIKE SHED
> 
> On 2012-10-09, at 23:17 , Jesse Campbell 
> <
 >
>  wrote:
> 
>> apologies, i can get a bit long-winded in my questions...
>> short version:
>> 
>> should I follow the fix for COOK-517, or the fix for COOK-727?
>> 
>> long version:
>> 
>> on RHEL/CentOS6, the current mysql cookbook installs the mysql server
>> package (which creates the mysql user and mysql group)
>> then it tries to create some folders and templates using the mysql
>> user and mysql group
>> 
>> since ruby caches the group names, this fails, as the group doesn't yet 
>> exist.
>> This is documented in COOK-1676, and has been occurring for a long
>> time, just didn't get a chance to write it up before, but now someone
>> else did.
>> 
>> I see two ways to fix this, neither have I completely tested, but both
>> theoretically will work.
>> 
>> In COOK-517, Seth Chisamore fixed the same bug in the users cookbook
>> by adding the following code:
>> 
>> ruby_block "reset group list" do
>> block do
>>   Etc.endgrent
>> end
>> action :nothing
>> end
>> 
>> then adding a notifies line to whatever block creates the group.
>> 
>> I just finished completing a mirror fix for the mysql cookbook here:
>> https://github.com/jcam/mysql/commit/d57e4055e3ec6fe9f4c5d5a868f552a02e408133
>> 
>> In COOK-727, Joshua Timberman made a fix for the postgresql cookbook
>> for the same issue,
>> but instead of resetting the group list, he manually created the user
>> and group for postgresql "like the package will"
>> see here:
>> https://github.com/lamont-opscode/cookbooks/blob/COOK-716/postgresql/recipes/server_redhat.rb
>> 
>> I could follow Joshua's way of doing it, but I worry... **what happens
>> if the mysql upstream package changes**? Then it doesn't create it
>> "like the package will". Then I'll be screwed in the middle of the
>> night when i am rebuilding a failed server.
>> 
>> Thoughts?
> 
>