There was a discussion a while ago about adding inheritance to definitions. There is a need for a way to specialize parameters while allowing passing other options. This comes up with remotefile where it would be nice to have a default server location but not specify all the parameters (and their defaults) in the definition. Was there a change to the syntax? Is there a way to accomplish this? - Ian
On Jan 10, 2007, at 2:25 PM, Ian Burrell wrote:> There was a discussion a while ago about adding inheritance to > definitions. There is a need for a way to specialize parameters while > allowing passing other options. This comes up with remotefile where > it would be nice to have a default server location but not specify all > the parameters (and their defaults) in the definition. > > Was there a change to the syntax? Is there a way to accomplish this?The consensus by (from what I could tell) everyone but me was that this was unnecessary, and I removed the syntax. Currently, there is no way to accomplish this. I like David Lutterkort''s idea of having a syntax for rolling up all remaining arguments and then passing them through, like Ruby''s ''*'' operator: def mything(one, two, *rest) three = rest.empty? ? rest.shift : nil something(one, two, three) end The problem is that Puppet''s language lacks the cohesive background story to make that work at this point. At the least, it would need to support hashes, and it definitely doesn''t. -- A computer lets you make more mistakes faster than any invention in human history--with the possible exceptions of handguns and tequila. -- Mitch Ratcliffe --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hello,
Are you talking about somethign like this:
define mything ( $variable = "bar", $server =
"puppet.mydomain.com" ) {
file { "$name" :
source => "$server://dists/$name-$variable",
recurse => true,
....
}
)
and call it like
mything { "sometime" : }
would get puppet.mydomain.com/dists/sometime-bar, and
mything { "another" :
server => "puppet.remotedomain.com",
variable => "foo"
}
would get puppet.remotedomain.com/dists/another-bar
ohhh and disclaimer: I wrote those off the top of my head..
but is that what you are asking about?
.r''
On 1/10/07, Ian Burrell <ianburrell@gmail.com>
wrote:> There was a discussion a while ago about adding inheritance to
> definitions. There is a need for a way to specialize parameters while
> allowing passing other options. This comes up with remotefile where
> it would be nice to have a default server location but not specify all
> the parameters (and their defaults) in the definition.
>
> Was there a change to the syntax? Is there a way to accomplish this?
>
> - Ian
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
On 1/10/07, RijilV <rijilv@gmail.com> wrote:> > Are you talking about somethign like this: ><snip>> but is that what you are asking about? >Overriding the defaults like that works right now. I am more interested in not specifying all the arguments when making a component which is "derivative" of file. define remotefile($source) { file { $name: source => $source, } } To allow saying: remotefile { "foo": source => "bar", mode => 0755, } That requires specifying all the possible file arguments in the derivatives. Right now, we only add the parameters that we need for later derivatives. - Ian
On 1/10/07, Luke Kanies <luke@madstop.com> wrote:> > The consensus by (from what I could tell) everyone but me was that > this was unnecessary, and I removed the syntax. Currently, there is > no way to accomplish this. > > I like David Lutterkort''s idea of having a syntax for rolling up all > remaining arguments and then passing them through, like Ruby''s ''*'' > operator: > > def mything(one, two, *rest) > three = rest.empty? ? rest.shift : nil > something(one, two, three) > end > > The problem is that Puppet''s language lacks the cohesive background > story to make that work at this point. At the least, it would need > to support hashes, and it definitely doesn''t. >I just discovered a case where it is necessary to be able to do this. My remotefile definition looks like: define remotefile($source, $owner = root, $group = root, $mode = 0644, $backup = false, $recurse = false) { file { $name: mode => $mode, owner => $owner, group => $group, backup => $backup, recurse => $recurse, source => "$puppetdir/$source", } } The ends up always setting the mode parameter to 0644 instead of using the mode from the source which is the default. I would like to have the default but be able to specify the mode when needed. The current solution I see is to copy the definition that does not pass the mode. One simple possibility is have a special symbol default. This uses the default of the called component if it isn''t specified. This still requires specifying all the parameters. And there is some complexity in specifying which defaults if there is a collision. efine remotefile($source, $owner = default, $group = default, $mode default, $backup = default, $recurse = default) { file { $name: mode => $mode, owner => $owner, group => $group, backup => $backup, recurse => $recurse, source => "$puppetdir/$source", } } - Ian
On Jan 25, 2007, at 1:42 PM, Ian Burrell wrote:> I just discovered a case where it is necessary to be able to do this. > My remotefile definition looks like: > > define remotefile($source, $owner = root, $group = root, $mode = 0644, > $backup = false, $recurse = false) { > file { $name: > mode => $mode, > owner => $owner, > group => $group, > backup => $backup, > recurse => $recurse, > source => "$puppetdir/$source", > } > } > > The ends up always setting the mode parameter to 0644 instead of using > the mode from the source which is the default. I would like to have > the default but be able to specify the mode when needed. The current > solution I see is to copy the definition that does not pass the mode.It''s not pretty, but you can do it this way: define remotefile(..., $mode = false, ...) { file { $name: ..., } if $mode { File[$name] { mode => $mode } } Yes, you have to do this for every parameter. Yes, I already said it''s ugly. I completely agree that this is a problem, I just don''t know how to solve it. My idea of type inheritance was roundly shot down, and no one has come up with another option (other than David''s roll-up idea, which lacks the details necessary to implement).> One simple possibility is have a special symbol default. This uses > the default of the called component if it isn''t specified. This still > requires specifying all the parameters. And there is some complexity > in specifying which defaults if there is a collision. > > efine remotefile($source, $owner = default, $group = default, $mode > default, $backup = default, $recurse = default) { > file { $name: > mode => $mode, > owner => $owner, > group => $group, > backup => $backup, > recurse => $recurse, > source => "$puppetdir/$source", > } > }This has been brought up before. I''m not completely opposed to the idea, although it seems a bit much like a hack that we will later regret. Any other opinions? -- Chase after truth like hell and you''ll free yourself, even though you never touch its coat-tails. -- Clarence Darrow --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, On Thu, 25 Jan 2007, Luke Kanies wrote:> It''s not pretty, but you can do it this way: > > define remotefile(..., $mode = false, ...) { > file { $name: ..., } > > if $mode { File[$name] { mode => $mode } > } > > Yes, you have to do this for every parameter. Yes, I already said > it''s ugly.Being very novice in puppy I''d say one can live with it. What I find much more disturbing as a missing feature is to append list of elements to a list, e.g.: define remotefile(..., $require = false, ...) { if $require { File[$name] { $require => [Service["server-foo"], $require] } } else { File[$name] { $require => Service["server-foo"] } } ... } and be able to write remotefile { ... require => [ File["bar"], Service["bar"]] } It''d be handy when writing rules for services running in virtual servers. Best regards, Jozsef -- E-mail : kadlec@sunserv.kfki.hu, kadlec@blackhole.kfki.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
>> if $mode { File[$name] { mode => $mode } >> }i do not see anywhere that puppet has an ''if'' thing, the docs only speak of ''case''. Is it in the core and supported or still a beta thing not documented because not ready or do i missed it in the docs ? -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 26, 2007, at 1:56 AM, ADNET Ghislain wrote:> > i do not see anywhere that puppet has an ''if'' thing, the docs only > speak of ''case''. Is it in the core and supported or still a beta > thing not documented because not ready or do i missed it in the docs ?It''s been around for a couple of releases, I just (apparently) haven''t documented it. Hopefully someday soon, I guess. -- The only really good place to buy lumber is at a store where the lumber has already been cut and attached together in the form of furniture, finished, and put inside boxes. --Dave Barry --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jan 25, 2007, at 3:39 PM, Kadlecsik Jozsi wrote:> > Being very novice in puppy I''d say one can live with it. What I > find much > more disturbing as a missing feature is to append list of elements > to a > list, e.g.: > > define remotefile(..., $require = false, ...) { > if $require > { File[$name] { $require => [Service["server-foo"], > $require] } } > else { File[$name] { $require => Service["server-foo"] } } > ... > } > > and be able to write > > remotefile { ... require => [ File["bar"], Service["bar"]] } > > It''d be handy when writing rules for services running in virtual > servers.This is a common feature request. I don''t know if it will happen or not. I think the better long-term direction is to pull relationships out of parameters and somehow directly support them in the language, but I''ve no idea how to do that yet. -- It''s not to control, but to protect the citizens of Singapore. In our society, you can state your views, but they have to be correct. -- Ernie Hai, co-ordinator of the Singapore Government Internet Project --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com