Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On 2014-12-03 22:42, Rob Reynolds wrote: For the other items, please create tickets (feel free to point back to this discussion) and we can get them prioritized. Thanks! You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from 2013. Or http://projects.puppetlabs.com/issues/7241 from 2011? Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5481AE10.6090906%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Fri, Dec 5, 2014 at 7:07 AM, David Schmitt da...@dasz.at wrote: On 2014-12-03 22:42, Rob Reynolds wrote: For the other items, please create tickets (feel free to point back to this discussion) and we can get them prioritized. Thanks! You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from 2013. Or http://projects.puppetlabs.com/issues/7241 from 2011? I just bumped the one only on redmine over to https://tickets.puppetlabs.com/browse/PUP-3745. Of course these would already exist. :) Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5481AE10.6090906%40dasz.at. 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMJiBK5YeV%2BRO7in5KnbXdigbPms69Sv4ghMgcVjMG%3DwCP0K4A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Thu, Nov 27, 2014 at 2:06 AM, David Schmitt da...@dasz.at wrote: On 2014-11-26 19:02, Rob Reynolds wrote: 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? Given that the groupadd provider is the only provider relevant to the majority of Linux systems, and it is INCAPABLE of managing group members, I'm slightly amused by that question. Therefore I follow John's point of it being a net win based on principles as it cannot influence any of my systems. Everyone seems to be in agreement about this aspect so we created PUP-3719[1] to address the smaller change for non-authoritative. For the other items, please create tickets (feel free to point back to this discussion) and we can get them prioritized. Thanks! [1] https://tickets.puppetlabs.com/browse/PUP-3719 Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5476DB7B.6080705%40dasz.at. 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMJiBK5zekrLU08M%3DJqUbwJAenZ87gHng9omdVY%2BjyQGpnjUoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On 2014-11-26 19:02, Rob Reynolds wrote: 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? Given that the groupadd provider is the only provider relevant to the majority of Linux systems, and it is INCAPABLE of managing group members, I'm slightly amused by that question. Therefore I follow John's point of it being a net win based on principles as it cannot influence any of my systems. Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5476DB7B.6080705%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
There's a patch for that. https://github.com/onyxpoint/puppet-gpasswd/blob/master/lib/puppet/provider/group/gpasswd.rb It was not included due to not wanting to increase the code in the core. Trevor On Thu, Nov 27, 2014 at 3:06 AM, David Schmitt da...@dasz.at wrote: On 2014-11-26 19:02, Rob Reynolds wrote: 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? Given that the groupadd provider is the only provider relevant to the majority of Linux systems, and it is INCAPABLE of managing group members, I'm slightly amused by that question. Therefore I follow John's point of it being a net win based on principles as it cannot influence any of my systems. Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5476DB7B.6080705%40dasz.at. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
Awesome, thanks! That would have saved me a quite awkward moment at a client. :-) Regards, David On 2014-11-27 16:08, Trevor Vaughan wrote: There's a patch for that. https://github.com/onyxpoint/puppet-gpasswd/blob/master/lib/puppet/provider/group/gpasswd.rb It was not included due to not wanting to increase the code in the core. Trevor On Thu, Nov 27, 2014 at 3:06 AM, David Schmitt da...@dasz.at mailto:da...@dasz.at wrote: On 2014-11-26 19:02, Rob Reynolds wrote: 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? Given that the groupadd provider is the only provider relevant to the majority of Linux systems, and it is INCAPABLE of managing group members, I'm slightly amused by that question. Therefore I follow John's point of it being a net win based on principles as it cannot influence any of my systems. Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+__DavidSchmitt https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/__davidschmitt http://at.linkedin.com/in/davidschmitt -- 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+unsubscribe@__googlegroups.com mailto:puppet-dev%2bunsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/__msgid/puppet-dev/5476DB7B.__6080705%40dasz.at https://groups.google.com/d/msgid/puppet-dev/5476DB7B.6080705%40dasz.at. For more options, visit https://groups.google.com/d/__optout https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/54774146.3070401%40dasz.at. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
If you could make a push to get it into core, that would be great. I didn't understand the argument for rejecting it, but made the module anyway. It's plug and play and works in both 2.7 and 3.X. Trevor On Thu, Nov 27, 2014 at 10:20 AM, David Schmitt da...@dasz.at wrote: Awesome, thanks! That would have saved me a quite awkward moment at a client. :-) Regards, David On 2014-11-27 16:08, Trevor Vaughan wrote: There's a patch for that. https://github.com/onyxpoint/puppet-gpasswd/blob/master/ lib/puppet/provider/group/gpasswd.rb It was not included due to not wanting to increase the code in the core. Trevor On Thu, Nov 27, 2014 at 3:06 AM, David Schmitt da...@dasz.at mailto:da...@dasz.at wrote: On 2014-11-26 19:02, Rob Reynolds wrote: 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? Given that the groupadd provider is the only provider relevant to the majority of Linux systems, and it is INCAPABLE of managing group members, I'm slightly amused by that question. Therefore I follow John's point of it being a net win based on principles as it cannot influence any of my systems. Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+__DavidSchmitt https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/__davidschmitt http://at.linkedin.com/in/davidschmitt -- 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+unsubscribe@__googlegroups.com mailto:puppet-dev%2bunsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/__msgid/puppet-dev/5476DB7B.__ 6080705%40dasz.at https://groups.google.com/d/msgid/puppet-dev/5476DB7B. 6080705%40dasz.at. For more options, visit https://groups.google.com/d/__optout https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com mailto:tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 mailto:puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY% 2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs% 2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w% 40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/54774146.3070401%40dasz.at. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVwBEgy_sE8rFGhTsJDVdi24fBPzp3KdCZY6h10g9MkSA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Tue, Nov 25, 2014 at 6:31 PM, Nigel Kersten ni...@puppetlabs.com wrote: 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. 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 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=emailutm_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 https://groups.google.com/d/msgid/puppet-dev/CAGUqgV-0r60RH%2Bc0yYFpJsF%3DOR20A_1adGUV0xK1%2BP7xunh0kw%40mail.gmail.com?utm_medium=emailutm_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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Wednesday, November 26, 2014 12:03:09 PM UTC-6, Rob Reynolds wrote: 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? Pretty much any change to existing behavior will have negative consequences for somebody. This one will have no negative consequences for *me*, however, and I think non-authoritative would have been a better default from the beginning. When it surprises someone, the surprise behavior is less likely to take the form of damage. I'm inclined to call the change a win, but it costs me nothing. 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/8dea3e84-a55c-4d36-83d3-0c0eeab2a117%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
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=emailutm_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.
[Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
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.
[Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On Monday, November 24, 2014 9:37:38 AM UTC-6, John Bollinger wrote: 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. Clarification: support for primary group would be a feature of some *User* providers. 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/34903112-aba4-4198-8c34-6f082bb4e574%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?
On 11/24/2014 04:37 PM, John Bollinger wrote: 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. +1 would use. :-) We can even avoid a breaking change - yay for deprecations. Cheers, Felix -- 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/5473B1EC.8050203%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
