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.
>
>
Patrick
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?
What about instead defining something uncommon to be "module root". Something like, as a random example, "~/". Then the syntax goes from "file:///modules/$modulename/file" to "~/file".
Nigel Kersten
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.
Patrick
Nigel Kersten
I don't think we mention file:// in the docs at all... I'd always been
under the impression that we supported "puppet://" for server-side
URIs and anything else was a local filesystem path.
Testing shows we do support file:///tmp/foo just like /tmp/foo. Huh.
Back to your question... I don't think so, but others may have a
different opinion.
Luke Kanies
I agree, this is a good option. The only other one I thought of was introducing a 'module_path' function or something similar to do the path expansion.
--
Hegel was right when he said that we learn from history that man can
never learn anything from history. -- George Bernard Shaw
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
Nigel Kersten
I thought about this for a while and even started to mock something
up, but it's kind of ugly.
There's something gorgeously attractive about being able to move to:
file { "/etc/sshd_config":
source => "~/sshd_config",
}
What implications of introducing a new syntactical element are there?
Where else could we use this? On import statements?
import "foo.pp" already looks in the current working directory, but is
there any point trying to add this throughout the language so you can
do:
# modules/foo/manifests/a/b/c/d/contrived.pp
import "~/clean.pp"
and it resolves to modules/foo/manifests/clean.pp ?
Patrick Mohr
That was a typo. I meant
Would it be worth the effort to allow "puppet://server.cxm/~/file"? This allows you to specify the server, but not give the full path.
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!
Nigel Kersten
But you're optimizing for an uncommon case...
Why doesn't this concern matter for everything else that happens
server-side? template/file functions, imports, etc.
The client never sees the manifest, only the catalog. I am talking
about a local copy. Local to the server. :)
I'm talking about throwing out the current assumptions because I don't
think they're aimed at the most common cases for Puppet, which are
client/server setups where your files primarily come from the modules
they are requested in.
> What about a new URI scheme (ie module) which would do the same:
>
> class foo {
> file { "/etc/foo.conf":
> source => "module://foo.conf",
> }
> }
It's ugly and unnecessarily verbose in my opinion. How many different
protocols are we really going to add to Puppet?
>
> --
> Brice Figureau
> Follow the latest Puppet Community evolutions on www.planetpuppet.org!
>
Alan Barrett
> What about a new URI scheme (ie module) which would do the same:
>
> class foo {
> file { "/etc/foo.conf":
> source => "module://foo.conf",
> }
> }
If you go this way, please do not include "://" in the URI. The
presence of "://" implies that the next thing after the "://" will
be an "authority" part (defined in RFC 3986 section 3.2; e.g.
something like a hostname, or user@host:port, or the empty
string that represents an implied hostname). RFC 3986 section 3
says 'When authority is not present, the path cannot begin with
two slash characters ("//").'
--apb (Alan Barrett)
Luke Kanies
Another option is a new function:
class foo {
file { "/etc/foo.conf":
source => expand("foo.conf")
}
}
Then all of the smarts could be in expand().
OTOH, I think it's a bit think in terms of syntax. Backticks? :)
--
Everything that is really great and inspiring is created by the
individual who can labor in freedom. -- Albert Einstein
Patrick
quicksilver03
not have a U.S. keyboard layout have a hard time typing them (2-to-3
keys combinations in some cases).
Nigel Kersten
I think it's too heavy and too tacked on.
After looking up a few of the major non-US keyboard layouts, I'm
really not sure '~' makes sense anymore. How do you people use Unixes?
:)
Brice Figureau
> [heavilly snipped because answer OT]
> After looking up a few of the major non-US keyboard layouts, I'm
> really not sure '~' makes sense anymore. How do you people use Unixes?
> :)
I dumped my azerty keyboard in favor of an US one as soon as I started
programming/admining :)
Now I struggle to add accented vowels when I write in French :)
James Turnbull
> On Tue, 2010-09-28 at 08:23 -0700, Nigel Kersten wrote:
>> [heavilly snipped because answer OT]
>> After looking up a few of the major non-US keyboard layouts, I'm
>> really not sure '~' makes sense anymore. How do you people use Unixes?
>> :)
Is OSX Unix? :)
>
> I dumped my azerty keyboard in favor of an US one as soon as I started
> programming/admining :)
> Now I struggle to add accented vowels when I write in French :)
What will you do without your outrageous accent? Oh "write in French"... :P
James
--
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571
Nigel Kersten
> Brice Figureau wrote:
>> On Tue, 2010-09-28 at 08:23 -0700, Nigel Kersten wrote:
>>> [heavilly snipped because answer OT]
>>> After looking up a few of the major non-US keyboard layouts, I'm
>>> really not sure '~' makes sense anymore. How do you people use Unixes?
>>> :)
>
> Is OSX Unix? :)
It is. They paid the money :)
>> I dumped my azerty keyboard in favor of an US one as soon as I started
>> programming/admining :)
>> Now I struggle to add accented vowels when I write in French :)
>
> What will you do without your outrageous accent? Oh "write in French"... :P
He could get a Mac. :) accented vowels are trivial on OS X US keyboards.
So back on a serious note... Is this definitely a deal breaker ? I
really don't want us to be US-centric...
Peter Meier
Hash: SHA1
> So back on a serious note... Is this definitely a deal breaker ? I
> really don't want us to be US-centric...
it wouldn't be one for me and I still stick with sg keyboards.
~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyiQ70ACgkQbwltcAfKi390gQCgldW2Q7VIqUfv0SJ3kjZKEHRg
KsAAnionImj1J9Zl5sP1qoos5LHiDh++
=FnVe
-----END PGP SIGNATURE-----
Christian Kauhaus
> it wouldn't be one for me and I still stick with sg keyboards.
It is two keys on most European keyboard layouts. I think that it will be
ok for most *nix users. We are already used to it. ;-)
For me, it would be a real time saver. Two keys is much less than the same
use case requires me to type now.
Christian
--
Dipl.-Inf. Christian Kauhaus <>< � k...@gocept.com � systems administration
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 11 � fax +49 345 1229889 1
Zope and Plone consulting and development
Nigel Kersten
> Am 28.09.2010 21:36, schrieb Peter Meier:
>> it wouldn't be one for me and I still stick with sg keyboards.
>
> It is two keys on most European keyboard layouts. I think that it will be
> ok for most *nix users. We are already used to it. ;-)
>
> For me, it would be a real time saver. Two keys is much less than the same
> use case requires me to type now.
Excellent. :)
I'll put a feature request in today and re-post it to the list so
people can provide more detailed feedback where it's easier to track.
Nigel Kersten
Jeff McCune
> What implications of introducing a new syntactical element are there?
Yet another inconsistency and confusion for newbies.
With that said, I think the benefits _far_ outweigh the drawbacks.
Especially since it brings consistency to the behavior of file()
template() and source.
> Where else could we use this? On import statements?
Any function that needs to read data from the file system on the master.
I'm looking at you, extlookup() ...
Today I wrote a function called getconf() which is little more than
Puppet::Parser::Functions.newfunction(:getconf, :type => :rvalue) do |args|
Puppet.settings[args[0]]
end
The motivation was to store extlookup data inside of confdir which is
usually under version control and at different file system paths for
development, testing, and production.
$confdir = getconf("confdir")
$extlookup_datadir = "${confdir}/extdata"
> import "foo.pp" already looks in the current working directory, but is
> there any point trying to add this throughout the language so you can
> do:
>
> # modules/foo/manifests/a/b/c/d/contrived.pp
> import "~/clean.pp"
>
> and it resolves to modules/foo/manifests/clean.pp ?
I think no matter what the path expansion logic should be generalized
into some utility method so types, providers, functions, report
processors, and whatever else we cook up can take advantage of this.
A quick win could be to add an path_to() function to the language
which should give us the desired behavior for free.
import path_to("~/clean.pp")
--
Jeff McCune
http://www.puppetlabs.com/
R.I.Pienaar
----- "Jeff McCune" <je...@puppetlabs.com> wrote:
> On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten
> <ni...@explanatorygap.net> wrote:
> > What implications of introducing a new syntactical element are
> there?
>
> Yet another inconsistency and confusion for newbies.
>
> With that said, I think the benefits _far_ outweigh the drawbacks.
> Especially since it brings consistency to the behavior of file()
> template() and source.
agree, we now have $module_name and friends which means we could achieve similar via a define but this syntax is much better
> > Where else could we use this? On import statements?
file() and template() should also support the array search order syntax same as source => does if we really want to get consistent behavior
>
> Any function that needs to read data from the file system on the
> master.
>
> I'm looking at you, extlookup() ...
>
> Today I wrote a function called getconf() which is little more than
>
> Puppet::Parser::Functions.newfunction(:getconf, :type => :rvalue) do
> |args|
> Puppet.settings[args[0]]
> end
>
> The motivation was to store extlookup data inside of confdir which is
> usually under version control and at different file system paths for
> development, testing, and production.
>
> $confdir = getconf("confdir")
> $extlookup_datadir = "${confdir}/extdata"
arent all the settings now available as variables?
% echo 'notice($settings::confdir)'|puppet
notice: Scope(Class[main]): /home/rip/.puppet
It's easy to gripe about abusing global variables the way extlookup does, there are very few options available to parser functions to do the right thing though.
I've filed a few enhancement requests around these but it seems the specific thing about config files i missed, it would be really nice if a plugin like extlookup can somehow hook into the main config file and add environment aware config options that we can access, that would have made the extlookup code/use a hell of alot less hacky
> > import "foo.pp" already looks in the current working directory, but
> is
> > there any point trying to add this throughout the language so you
> can
> > do:
> >
> > # modules/foo/manifests/a/b/c/d/contrived.pp
> > import "~/clean.pp"
> >
> > and it resolves to modules/foo/manifests/clean.pp ?
>
> I think no matter what the path expansion logic should be generalized
> into some utility method so types, providers, functions, report
> processors, and whatever else we cook up can take advantage of this.
>
> A quick win could be to add an path_to() function to the language
> which should give us the desired behavior for free.
>
> import path_to("~/clean.pp")
we'd need to think about defines quite carefully,
define somemodule::filecopier(...) {
file{$name:
source => "~/${name}"
}
}
someothermodule::filecopier{"foo": }
here the ~/${name} need to expand to someothermodule/files/${name} not somemodule/files/${name}
Nigel Kersten
Please update the bug with this so it doesn't fall through the tracks,
agreed on all counts.