Group Resource auth_membership defaults to true - should this change?
116 views
Skip to first unread message
Rob Reynolds
Nov 21, 2014, 4:21:15 PM11/21/14
to puppe...@googlegroups.com
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.
[1] https://tickets.puppetlabs.com/browse/PUP-2628
--
--
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%!
John Bollinger
Nov 24, 2014, 10:37:38 AM11/24/14
to puppe...@googlegroups.com
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
John Bollinger
Nov 24, 2014, 2:28:39 PM11/24/14
to puppe...@googlegroups.com
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
Felix Frank
Nov 24, 2014, 5:32:16 PM11/24/14
to puppe...@googlegroups.com
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. :-)
> 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.
We can even avoid a breaking change - yay for deprecations.
Cheers,
Felix
Nigel Kersten
Nov 25, 2014, 7:31:18 PM11/25/14
to public puppet dev
On Mon, Nov 24, 2014 at 7:37 AM, John Bollinger <john.bo...@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+...@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.
Nigel
Rob Reynolds
Nov 26, 2014, 1:03:09 PM11/26/14
to puppe...@googlegroups.com
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.bo...@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+...@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.--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+...@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.
John Bollinger
Nov 26, 2014, 1:39:22 PM11/26/14
to puppe...@googlegroups.com
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
John
David Schmitt
Nov 27, 2014, 3:06:29 AM11/27/14
to puppe...@googlegroups.com
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
> 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?
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
Trevor Vaughan
Nov 27, 2014, 10:08:35 AM11/27/14
to puppe...@googlegroups.com
There's a patch for that.....
It was not included due to not wanting to increase the code in the core.
Trevor
--
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.
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
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
David Schmitt
Nov 27, 2014, 10:20:53 AM11/27/14
to puppe...@googlegroups.com
Awesome, thanks! That would have saved me a quite awkward moment at a
client. :-)
Regards, David
> Twitter: @dev_el_ops G+: https://plus.google.com/+__DavidSchmitt
> LinkedIn: http://at.linkedin.com/in/__davidschmitt
> <mailto:puppet-dev%2Bunsu...@googlegroups.com>.
> <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>.
> tvau...@onyxpoint.com <mailto:tvau...@onyxpoint.com>
> <mailto:puppet-dev+...@googlegroups.com>.
> <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVqbHDhumFt5_eQLtFY%2BHocDKOHqcE8Mo_9zk%2BQmazy8w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
client. :-)
Regards, David
> 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
>
> --
> 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,
> <mailto:puppet-dev%2Bunsu...@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>.
> tvau...@onyxpoint.com <mailto:tvau...@onyxpoint.com>
>
> -- This account not approved for unencrypted proprietary information --
>
> -- 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+...@googlegroups.com
> 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
> <mailto:puppet-dev+...@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=email&utm_source=footer>.
Trevor Vaughan
Nov 27, 2014, 10:58:19 AM11/27/14
to puppe...@googlegroups.com
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
an email to puppet-dev+unsubscribe@googlegroups.com
<mailto:puppet-dev+unsub...@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=email&utm_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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54774146.3070401%40dasz.at.
Rob Reynolds
Dec 3, 2014, 4:42:44 PM12/3/14
to puppe...@googlegroups.com
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!
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5476DB7B.6080705%40dasz.at.
David Schmitt
Dec 5, 2014, 8:07:34 AM12/5/14
to puppe...@googlegroups.com
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
> For the
> other items, please create tickets (feel free to point back to this
> discussion) and we can get them prioritized. Thanks!
2013. Or http://projects.puppetlabs.com/issues/7241 from 2011?
Rob Reynolds
Dec 5, 2014, 9:28:05 AM12/5/14
to puppe...@googlegroups.com
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5481AE10.6090906%40dasz.at.
Reply all
Reply to author
Forward
0 new messages