On Mon, Nov 24, 2014 at 7:37 AM, John Bollinger <john.bollin...@stjude.org> 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 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 > <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 puppet-dev+unsubscr...@googlegroups.com. 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.
