On Mon, Nov 24, 2014 at 7:37 AM, John Bollinger <[email protected]> wrote:
> > > 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). > This is my fault historically, as the plan was while I was at my last employer to add this functionality to the Group type across systems after starting with OS X, but then I went and joined Puppet Labs, hilariously giving me less time to contribute to Puppet... > > 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. > I believe last time we had this debate this was the agreement you and I both reached, and I still think it makes the most sense. > > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/338f30da-f742-4522-b832-d41f6f08f487%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/338f30da-f742-4522-b832-d41f6f08f487%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Nigel -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAGUqgV-0r60RH%2Bc0yYFpJsF%3DOR20A_1adGUV0xK1%2BP7xunh0kw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
