On Friday, November 21, 2014 3:21:15 PM UTC-6, Rob Reynolds wrote: > > When we originally set out to do PUP-2628[1] for Puppet 4, we were going > to change the group resource default to not authoritative for Windows (e.g. > the specified members would be the minimum), because the thinking is that > is how it was for all of the other platforms. > > However after more research it is the user resource that has the minimum > set of groups by default[2][3] and the members listed in a group resource > are considered the authoritative list by default[4][5]. Having them be the > opposite by default feels a little surprising IMHO. > > The question has come up, should it be this way? We have the opportunity > for Puppet 4 to shift the behavior of group auth_membership. >
I agree that it would be less surprising for User and Group to use equivalent defaults for group membership. If a change is made in that area then I strongly prefer the default to be non-authoritative, as that has for less likelihood of accidentally causing damage (which appears basically to be what PUP-2628 is about). I'd like to observe, however, that this has long been an area where Puppet's system abstraction breaks down: on some systems you have to manage group membership via User resources, but on others you have to manage it via Group resources. As long as we're considering breaking changes in this area, perhaps this would be a good time to address that issue? I see a few alternatives there, but I think data design principles point to the best approach: when you have a many-to-many relationship, you express it via a separate table (resource type). A (say) Group_membership resource type could allow group membership to be expressed the same way for all systems, and it would dovetail nicely with the new ideas for client-side queries and resource purging. I think you still end up with a slightly leaky abstraction, in that only some systems have a concept of users' primary group, but support for that could and probably should be recast as a provider feature. On such systems, the Group_membership resource would manage only secondary groups, just as User.groups does now. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/338f30da-f742-4522-b832-d41f6f08f487%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
