Ok, that helps. I would totally support a set of conflict-management metaparams. Even just starting with a "fail if they're both there" param would probably suffice for most cases, and then maybe adding a 'skip if present' and 'always supercedes' param would be a good idea.
-- http://puppetlabs.com/ | http://about.me/lak | +1-615-594-8199 On Jul 29, 2013, at 7:14 PM, Trevor Vaughan <[email protected]> wrote: This is the main use case that came to hand and I certainly agree about the names. So, yes, having this restricted to 'file' statements and fragment providers (Augeas, file_line, etc....) would cover all of the use cases that I can think of off hand. The three cases would be: a) File wins b) Fragments win c) Conflict should not exist With c) being the default. Technically, you could also use this to enhance various resources by passing state between resources without the need for external files or in memory class variable hacks. foo { 'a': something => 'bar', send => { Foo['b'], 'awesome' } } foo { 'b': something => 'baz' } This would act as sort of an enhanced 'notify' allowing for passing values through to the actual applied providers. However, I fear that this may lead to bouts of over-creativity and complexity if not used carefully. Thanks, Trevor On Mon, Jul 29, 2013 at 12:22 AM, Luke Kanies <[email protected]> wrote: > Trevor Vaughan wrote: > >> Ok, so I'm not sure how this proposal will go over but I'm going to >> throw it out there. >> >> I recently encountered a situation where I was using the stdlib function >> 'file_line' to manage one line in a file but, through various means, >> ended up managing the entire file when using the code base i a different >> way. >> >> What I would like to propose is the addition of two metaparameters to >> correlate with the code smell of defined(). >> >> I hate defined() because it's code order dependent. So, I would like to >> add is_active and is_inactive as metaparameters that use the actual >> catalog state to determine whether or not to run the resource. >> >> Example: >> >> file { '/tmp/foo': content => "foo\nbar" } >> file_line { 'test': >> path => '/tmp/foo', >> line => 'foo' >> } >> >> As you can see from this contrived example, these two resources will >> constantly fight. >> >> However, if we do the following: >> >> file { '/tmp/foo': content => "foo\nbar" } >> file_line { 'test': >> path => 'tmp/foo', >> line => 'foo', >> is_inactive => File['/tmp/foo'] >> } >> >> Then, file_line will only execute if the File['/tmp/foo'] resource is >> not in the catalog. Otherwise, it should just log a debug message that >> it is not executing due to the is_inactive metaparameter. >> > > Hi Trevor, > > I think that's an interesting idea. Is the case of conflicting resources > the only one you would expect to use this, or are there other use cases? > If this is the main use case, I'd recommend names that better indicate a > conflict or the need for exclusivity. > > For this case, though, I actually prefer the idea of finding a way for the > system to detect conflicts between whole-file methods and the per-record > methods. I know that's not a great short-term fix, and I do think it's > past time we added some kind of catalog control like this into the system. > > -- > Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | > +1-615-594-8199 > > > -- > 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<puppet-dev%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out. -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
