I use a simple yaml file and and an external nodes script to express each of
my nodes. What I''m trying to do is make sure that all individual data
is
expressed at the node level and not have anything in classes or modules that
isn''t generic and shared.
the example below works really well but I can''t express it via my
external
nodes, I have to bury it in a class (or module). I''m trying to avoid
having
to have a class for each node.
I know I can call a define with an array, but I need the parameters to be
different for each element of the array.
anyone have any suggestions?
C
class network {
iface { ''eth1'':
ip => ''172.31.13.100'',
netmask => ''255.255.255.0'',
gateway => ''172.31.13.254'',
}
iface { ''eth1:0'':
ip => ''172.31.13.150'',
netmask => ''255.255.255.0'',
}
iface { ''eth1.800'':
ip => ''172.31.26.200'',
netmask => ''255.255.255.0'',
vlan => true,
}
file { "/etc/sysconfig/network":
mode => 0644,
content => template("network/network.erb"),
}
}
define iface (
$gateway = '''',
$bootproto = ''static'',
$ip = '''',
$netmask = '''',
$onboot = ''yes'',
$mac = '''',
$vlan = ''''
) {
file { $name:
name => "/etc/sysconfig/network-scripts/ifcfg-${name}",
mode => 0644,
content => template("network/interface.erb"),
#notify => Exec["manage-interface"],
}
}
--
stickm@gmail.com
-==< Stick >==-
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 12 October 2007, Chris MacLeod wrote:> I use a simple yaml file and and an external nodes script to express each > of my nodes. What I''m trying to do is make sure that all individual data > is expressed at the node level and not have anything in classes or modules > that isn''t generic and shared. > > the example below works really well but I can''t express it via my external > nodes, I have to bury it in a class (or module). I''m trying to avoid > having to have a class for each node. > > I know I can call a define with an array, but I need the parameters to be > different for each element of the array. > > anyone have any suggestions?You can always add a class with the name of the node and include this too. While this does not completely fits youre requirements, it solves the underlying problem. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHD9mu/Pp1N6Uzh0URAsygAJ9M2r4yH+vNiwMg6oADwqHqXF0CkgCfSi3F HfdwRdkL6zcXirTmTWQ4G94=2kFA -----END PGP SIGNATURE-----
On Oct 12, 2007, at 12:51 PM, Chris MacLeod wrote:> the example below works really well but I can''t express it via my > external nodes, I have to bury it in a class (or module). I''m > trying to avoid having to have a class for each node. > > I know I can call a define with an array, but I need the parameters > to be different for each element of the array.I don''t really understand the problem you''re trying to solve. Is it that each node has a unique list of ethernet interfaces, each with its own IP addresses? If not, what is it? -- You can''t have everything. Where would you put it? -- Stephen Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
that''s just the current example. I certainly need to solve that one.
David''s suggestion of including a node specific class file would work,
but
I''d like to keep all node specific data in the yaml rather than be
splitting
it between a node/class file and the yaml.
the conceptual problem is that I have node specific data (that has sub
attributes as well) that I want to express in my external nodes.
I certainly need to solve this specific problem, on our front level proxies
they have any number of interface aliases for ssl purposes.
Ideally I''d think the solution (in yaml) would be something like:
interface:
eth0:
ip: 1.1.1.1
netmask: 255.255.255.0
... etc
eth1:
ip: 1.1.2.1
... etc.
and so on, but I have no clue how I could express that in a way that a
define would work with it (or if I even can do that)
If it''s confusing the issue, we can step away from the conceptual
problem,
how are people handling multiple ethernet interfaces on a single node, when
using external nodes.
Maybe the way to go is not to have a yaml file per host for external nodes
to read and just have it output a small set of default classes and a
hostname.pp class file and do everything in there? Seems kinda backwards
but I guess it could work.
I really like the concept of only being able to define classes and variables
at a host level and having all the modules and classes be fairly generic and
reusable.
C
On 10/13/07, Luke Kanies <luke@madstop.com> wrote:>
> On Oct 12, 2007, at 12:51 PM, Chris MacLeod wrote:
>
> > the example below works really well but I can''t express it
via my
> > external nodes, I have to bury it in a class (or module).
I''m
> > trying to avoid having to have a class for each node.
> >
> > I know I can call a define with an array, but I need the parameters
> > to be different for each element of the array.
>
> I don''t really understand the problem you''re trying to
solve.
>
> Is it that each node has a unique list of ethernet interfaces, each
> with its own IP addresses? If not, what is it?
>
> --
> You can''t have everything. Where would you put it?
> -- Stephen Wright
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
--
stickm@gmail.com
-==< Stick >==-
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
On Oct 13, 2007, at 7:58 PM, Chris MacLeod wrote:> that''s just the current example. I certainly need to solve that > one. David''s suggestion of including a node specific class file > would work, but I''d like to keep all node specific data in the yaml > rather than be splitting it between a node/class file and the yaml. > > the conceptual problem is that I have node specific data (that has > sub attributes as well) that I want to express in my external nodes.I''m open to adding something like this in the future, but you can''t really do it right now. External nodes are for classification and parameters; all resource specification happens in Puppet''s language. -- Be wary of the man who urges an action in which he himself incurs no risk. -- Joaquin Setanti --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
So how are other people solving this problem? if there is a better way for me to express this as a parameter I''m all for it. On 10/15/07, Luke Kanies <luke@madstop.com> wrote:> > On Oct 13, 2007, at 7:58 PM, Chris MacLeod wrote: > > > that''s just the current example. I certainly need to solve that > > one. David''s suggestion of including a node specific class file > > would work, but I''d like to keep all node specific data in the yaml > > rather than be splitting it between a node/class file and the yaml. > > > > the conceptual problem is that I have node specific data (that has > > sub attributes as well) that I want to express in my external nodes. > > I''m open to adding something like this in the future, but you can''t > really do it right now. > > External nodes are for classification and parameters; all resource > specification happens in Puppet''s language. > > -- > Be wary of the man who urges an action in which he himself incurs no > risk. -- Joaquin Setanti > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Oct 15, 2007, at 11:48 AM, Chris MacLeod wrote:> So how are other people solving this problem? if there is a better > way for me to express this as a parameter I''m all for it.I think your only real choice is to have a per-node class that handles this: include "${hostname}_interfaces" -- 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
On 10/15/07, Luke Kanies <luke@madstop.com> wrote:> > On Oct 15, 2007, at 11:48 AM, Chris MacLeod wrote: > > > So how are other people solving this problem? if there is a better > > way for me to express this as a parameter I''m all for it. > > I think your only real choice is to have a per-node class that > handles this: > > include "${hostname}_interfaces"I guess I could drop the yaml file completly and use node specific pp file for each. then stick all my node specific data in there. Are not many people using external nodes? It seems like this problem would have been run into before. C -- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 10/15/07, Chris MacLeod <stickm@gmail.com> wrote:> > > > On 10/15/07, Luke Kanies <luke@madstop.com> wrote: > > > > On Oct 15, 2007, at 11:48 AM, Chris MacLeod wrote: > > > > > So how are other people solving this problem? if there is a better > > > way for me to express this as a parameter I''m all for it. > > > > I think your only real choice is to have a per-node class that > > handles this: > > > > include "${hostname}_interfaces" > > > > > > I guess I could drop the yaml file completly and use node specific pp file > for each. > then stick all my node specific data in there. >Apparently this is a bad idea as well b/c I lose my variable inheritance. I''m trying to avoid having a bunch of different places to go to do node specific things, if I have a ${hostname}_interfaces class for every server, then the next time I have a similar data type I end up with another host specific file. C -- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 15 October 2007, Chris MacLeod wrote:> On 10/15/07, Chris MacLeod <stickm@gmail.com> wrote: > > On 10/15/07, Luke Kanies <luke@madstop.com> wrote: > > > On Oct 15, 2007, at 11:48 AM, Chris MacLeod wrote: > > > > So how are other people solving this problem? if there is a better > > > > way for me to express this as a parameter I''m all for it. > > > > > > I think your only real choice is to have a per-node class that > > > handles this: > > > > > > include "${hostname}_interfaces" > > > > I guess I could drop the yaml file completly and use node specific pp > > file for each. > > then stick all my node specific data in there. > > Apparently this is a bad idea as well b/c I lose my variable inheritance. > > I''m trying to avoid having a bunch of different places to go to do node > specific things, if I have a ${hostname}_interfaces class for every server, > then the next time I have a similar data type I end up with another host > specific file.If you have any bigger system, then you already _have_ different places to go for node-specific information: a password here, a customized template there, whatever. puppet just makes it easier to describe the commonalities and the exceptions of your systems. For a well thought out configuration layout see the PuppetBestPractices page on the wiki. In the simplest case you put everything in a node-specific subdirectory, keyed by FQDN. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHFF5Q/Pp1N6Uzh0URArbhAKCj70Q5ypnRuFZGk+GFmOr9ExMyzQCdHcwn nEvFQOL/yJCFhwI6Ab3KN9Q=4ZK/ -----END PGP SIGNATURE-----
On 10/16/07, David Schmitt <david@schmitt.edv-bus.at> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 15 October 2007, Chris MacLeod wrote: > > On 10/15/07, Chris MacLeod <stickm@gmail.com> wrote: > > > On 10/15/07, Luke Kanies <luke@madstop.com> wrote: > > > > On Oct 15, 2007, at 11:48 AM, Chris MacLeod wrote: > > > > > So how are other people solving this problem? if there is a > better > > > > > way for me to express this as a parameter I''m all for it. > > > > > > > > I think your only real choice is to have a per-node class that > > > > handles this: > > > > > > > > include "${hostname}_interfaces" > > > > > > I guess I could drop the yaml file completly and use node specific pp > > > file for each. > > > then stick all my node specific data in there. > > > > Apparently this is a bad idea as well b/c I lose my variable > inheritance. > > > > I''m trying to avoid having a bunch of different places to go to do node > > specific things, if I have a ${hostname}_interfaces class for every > server, > > then the next time I have a similar data type I end up with another host > > specific file. > > If you have any bigger system, then you already _have_ different places to > go > for node-specific information: a password here, a customized template > there, > whatever. puppet just makes it easier to describe the commonalities and > the > exceptions of your systems. For a well thought out configuration layout > see > the PuppetBestPractices page on the wiki. In the simplest case you put > everything in a node-specific subdirectory, keyed by FQDN. > > hmm.I like that idea, though I''m not sure how the import/etc would work for that. Given that advice I''m thinking that a node directory based on FQDN that contains a yaml file to define classes and parameters then extra .pp files for interfaces or whatever. Thoughts? -- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users