Here are the details of what I am seeing. Please let me know if you need anymore info. I can confirm that for me with the lastest chef client I am still seeing this behavior on Ubuntu.(test) ~ 931# cat /etc/issue.netUbuntu 12.04.4 LTS(test) ~ 933# chef-client --versionChef: 11.12.8
(test) ~ 923# grep user[0-9] /etc/passwduser1:x:1023:1023::/home/user1:/bin/shuser2:x:1024:1024::/home/user2:/bin/sh(test) ~ 932# grep foobarbaz /etc/groupfoobarbaz:x:1025:user1,user2# client has a single recipe in the run list. The recipe isgroup "foobarbaz" domembers "user1,user2"end(test) ~ 934# chef-clientStarting Chef Client, version 11.12.8resolving cookbooks for run list: ["nbs_test::default"]Synchronizing Cookbooks:- nbs_testCompiling Cookbooks...Converging 1 resourcesRecipe: nbs_test::default* group[foobarbaz] action create- alter group group[foobarbaz]- replace group members with new list of members
Running handlers:Running handlers completeChef Client finished, 1/1 resources updated in 3.549844354 seconds
# here is the debug outout of this recipeRecipe: nbs_test::default* group[foobarbaz] action create[2014-07-17T15:52:47+00:00] INFO: Processing group[foobarbaz] action create (nbs_test::default line 1)[2014-07-17T15:52:47+00:00] DEBUG: Platform ubuntu version 12.04 found[2014-07-17T15:52:47+00:00] DEBUG: Executing groupmod foobarbaz[2014-07-17T15:52:47+00:00] DEBUG: ---- Begin output of groupmod foobarbaz ----[2014-07-17T15:52:47+00:00] DEBUG: STDOUT:[2014-07-17T15:52:47+00:00] DEBUG: STDERR:[2014-07-17T15:52:47+00:00] DEBUG: ---- End output of groupmod foobarbaz ----[2014-07-17T15:52:47+00:00] DEBUG: Ran groupmod foobarbaz returned 0[2014-07-17T15:52:47+00:00] DEBUG: group[foobarbaz] setting group members to: user1,user2[2014-07-17T15:52:47+00:00] INFO: group[foobarbaz] altered- alter group group[foobarbaz]- replace group members with new list of membersOn Wed, Jul 16, 2014 at 10:55 PM, George Miranda < " target="_blank"> > wrote:Scratch that. I went to verify this was indeed still a bug so I could move it to Github Issues. Using chef 11.12.8, I can no longer reproduce the bug.Can you provide some more details: chef-client version, platform, and an actual snippet of code that reproduces the bug you're seeing?On Wed, Jul 16, 2014 at 7:10 PM, George Miranda < " target="_blank"> > wrote:I found similar behavior, but only on Ubuntu and when gid is set to string values. I filed this bug regarding the issue -- https://tickets.opscode.com/browse/CHEF-4440Perhaps this is related?George Miranda — Partner Engineering
512.481.2876 – " style="color:rgb(105,117,130)" target="_blank"> – Linkedin Twitter
CHEF
TM
On Wed, Jul 16, 2014 at 5:14 PM, < " target="_blank"> > wrote:This is something that I have noticed for a while but has only started to
matter now that we are gathering metrics around the number of resources that
get updated during each chef run.
We are getting what we deem false metrics because we use Chef to manage
/etc/group and the client seems to update each group resource on every run even
if no modifications are really needed
Take for example the following simple resource
group "foobarbaz" do
action :create
members "user1,user2"
end
Everytime I run chef-client this resource is marked as updated. It seems that
the group provider does not bother to check existing group membership, it just
modifies the group to be what it is "supposed" to be.
While in the end this leaves /etc/group in the state that I require - it does
skew our metrics in that we always have resources to be updated on systems
where there really is not any update.
Is there anyway to get the Group provider to only update groups when they need
to be?
Archive powered by MHonArc 2.6.16.