Proposal to remove redundant info in source => parameters
Nigel Kersten
being the most common case is correct]
class foo {
file { "/etc/foo.conf":
source => "puppet:///modules/foo/foo.conf",
}
}
For me, every single one of my source specifications refers to a file
inside the current module. My intuition is that this is the most
common case outside my own deployment, so why don't we optimize for
it?
class foo {
file { "/etc/foo.conf":
source => "foo.conf",
}
}
eg the proposal is that if you don't specify the protocol, server
address, modules prefix, module name, it is assumed you are referring
to a file path relative to the 'files' subdirectory of the current
module.
If you wish to fully specify the source URI, you're free to do so.
--
nigel
Nan Liu
> eg the proposal is that if you don't specify the protocol, server
> address, modules prefix, module name, it is assumed you are referring
> to a file path relative to the 'files' subdirectory of the current
> module.
>
> If you wish to fully specify the source URI, you're free to do so.
Since we can determine module_name in 2.6, I agree with this change.
But we should update template behavior so it's the same as file.
Currently for templates:
content => template("foo.erb"),
Puppet would look in $templatedir/foo.erb which is
/var/lib/puppet/template/foo.erb, rather than foo module templates
directory.
If we make this change for files we should have both behave the same.
Thanks,
Nan
Nigel Kersten
Well that's a function, which does behave differently anyway.
I have a similar proposal for the file function to behave exactly like
the template function.
I'd be reasonably happy to reduce my proposal to require the
modulename, but I still think it's redundant info in the majority of
cases, but I guess the $module_name variable mitigates this somewhat.
>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>
>
--
nigel
Nigel Kersten
>> eg the proposal is that if you don't specify the protocol, server
>> address, modules prefix, module name, it is assumed you are referring
>> to a file path relative to the 'files' subdirectory of the current
>> module.
>>
>> If you wish to fully specify the source URI, you're free to do so.
>
> Since we can determine module_name in 2.6, I agree with this change.
> But we should update template behavior so it's the same as file.
> Currently for templates:
>
> content => template("foo.erb"),
Ah I missed addressing this point.
I don't think we can do this and still have backwards compatibility.
How do you tell whether 'foo/bar.erb' refers to 'foo' the module or a
subdirectory 'foo' in the current module? Which should take
precedence? How do we throw a deprecation warning?
I don't think we can feasibly forbid references to templates outside
the current module. That would have a significant effect upon our
ability to share modules.
With the benefit of hindsight, we should possibly have made the source
parameter, file function and template function consistent...
Can we get there from here?
>
> Puppet would look in $templatedir/foo.erb which is
> /var/lib/puppet/template/foo.erb, rather than foo module templates
> directory.
>
> If we make this change for files we should have both behave the same.
>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>
Nigel Kersten
>
> On Sep 25, 2010, at 10:02 AM, Nigel Kersten wrote:
>
>> On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <n...@puppetlabs.com> wrote:
>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <nig...@google.com> wrote:
>>>> eg the proposal is that if you don't specify the protocol, server
>>>> address, modules prefix, module name, it is assumed you are referring
>>>> to a file path relative to the 'files' subdirectory of the current
>>>> module.
>>>>
>>>> If you wish to fully specify the source URI, you're free to do so.
>>>
>>> Since we can determine module_name in 2.6, I agree with this change.
>>> But we should update template behavior so it's the same as file.
>>> Currently for templates:
>>>
>>> content => template("foo.erb"),
>>
>> Ah I missed addressing this point.
>>
>> I don't think we can do this and still have backwards compatibility.
>>
>> How do you tell whether 'foo/bar.erb' refers to 'foo' the module or a
>> subdirectory 'foo' in the current module? Which should take
>> precedence? How do we throw a deprecation warning?
>>
>> I don't think we can feasibly forbid references to templates outside
>> the current module. That would have a significant effect upon our
>> ability to share modules.
>>
>> With the benefit of hindsight, we should possibly have made the source
>> parameter, file function and template function consistent...
>>
>> Can we get there from here?
>
I'm normally really reluctant to add more special characters to the
syntax, as I feel like we're way too busy as it stands, but I really
do quite like this idea, using normal *nix syntax for your home vs
other users...
Let me incorporate your suggestion as I think adding syntax allows us
to make all three consistent.
modules/$module_name/files/foo
file { source => "~/foo" }
File (source) from another module 'bar':
file { source => "~bar/foo" }
modules/$module_name/templates/foo.erb
template("~/foo.erb")
modules/bar/templates/foo.erb:
template("~bar/foo.erb")
modules/$module_name/files/foo
file("~/foo")
modules/bar/files/foo
file("~bar/foo")
All of this *only* applies if you are within a module.
We don't deprecate the puppet:// or file:// syntax
Do we deprecate the existing template function syntax?
If not, do we add the existing template function syntax to the file
function for consistency?
We don't support setting the server, or access to static mount points.
If you want those, use the puppet:// syntax.
This feels good. We're optimizing for the two most common cases,
without removing the most flexible syntax.
Brice Figureau
It looks like I missed your original e-mail to puppet-dev.
My issue with your proposal is that at first glance it will look like a
local copy (which should require an absolute path) and not a remote
copy. This certainly violate the least surprise paradigm for new users.
What about a new URI scheme (ie module) which would do the same:
class foo {
file { "/etc/foo.conf":
source => "module://foo.conf",
}
}
--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!