On Tue, Nov 25, 2014 at 6:31 PM, Nigel Kersten <[email protected]> wrote:
> > > 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. > Making a switch to non-authoritative would be in the realm of possibility for Puppet 4 given the short timeline. I think the group_membership resource type could be something that could be done at any time, and then the other properties deprecated and removed by Puppet 5 or 6. Given that the group_membership is a bit larger and would need more time for deprecations, I'd like to bring this back to just the non-authoritative. Would it be a beneficial switch to move to non-authoritative? > > > > > >> >> >> 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 > <https://groups.google.com/d/msgid/puppet-dev/CAGUqgV-0r60RH%2Bc0yYFpJsF%3DOR20A_1adGUV0xK1%2BP7xunh0kw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Rob Reynolds Developer, Puppet Labs *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - * http://2015.puppetconf.com/ *Register early to save 40%!* -- 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/CAMJiBK6_O4dS4C9zyghAfunV6HhdmSgLTeA8CbKLOUtU4x3h2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
