On Tuesday, October 29, 2013 6:06:52 PM UTC-5, Josh Cooper wrote: > > > On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds > <[email protected]<javascript:> > > wrote: > >> >> [...] >> What we were just talking about was say dropping anything about the ACE >> knowing what it is applied to, that would go onto the ACL. >> > > So something like: > > ace { 'admins': > identity => 'Administrators', > rights => [full], > } > > ace { 'users': > identity => 'Users', > rights => [read_execute, list] > } > > acl { 'c:\somedir': > ensure => present, > permissions => [ > Ace['admins'], > Ace['users'] > ] > } > > acl { 'c:\somesensitivedir': > ensure => present, > purge => true, > protected => true, > permissions => [ > Ace['admins'] > ], > } > > So `c:\somedir` describes the complete set of explicit ACEs, though it may > inherit ACEs from its parent. > > On the other hand, `c:\somesensitivedir` is protected (breaks > inheritance), it only allows admins full control, and purges any other ACE. > > Thoughts? > >
It would probably work, but I don't like it because it takes ACEs from being bona fide resources to being plain data objects merely masquerading as resources. Halloween isn't until tomorrow. Seriously, though, shoehorning an object into a context where it doesn't quite fit tends to lead to trouble; just look at the myriad historical and continuing issues around the edges of resource-like class declarations for a close-to-home example. On the more practical side, I would like to be able to declare an ACE and rely on it being applied, without regard to whether the general properties of the overall ACL(s) to which it is applied are also managed. I really think it makes sense to keep the (DSL view of the) data structure simple. That makes the resource types easier to understand and easier to integrate with external data sources, including via automated parameter binding. From that perspective I prefer to avoid relying on complex parameter value types, and I particularly dislike relying on resource references to hook things together, as references cannot currently be expressed in external data. Additionally, relying on resource references brings in all the issues around ensuring resources are declared exactly once. That can easily be avoided here, so why would you intentionally choose to *not* avoid it? 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/7024cede-9c4b-4e0b-8be5-4d7b12c56beb%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
