Re: [Puppet Users] Re: defined types and enc
On Mon, Nov 12, 2012 at 06:32:02AM -0800, jcbollinger wrote:
On Friday, November 9, 2012 9:15:38 PM UTC-6, erkules wrote:
Ups sorry for the confusion.
Right now Ive got defines like:
lxc_builder{'starter01': ensure = 'define', ipadd='10.0.3.101/24' }
lxc_builder{'starter02': ensure = 'define', ipadd='10.0.3.102/24' }
lxc_builder{'starter03': ensure = 'define', ipadd='10.0.3.103/24' }
lxc_builder{'starter04': ensure = 'define', ipadd='10.0.3.104/24' }
The build an LXC application container on the host.
This works sufficient. Depending of the host there can be easily 100
Containers on
every host. (It is no KVM :)
So adding a container is writing a new line.
My intention was to put my configuration into an ENC.
Thats where the trouble started, as no place for defined types in ENC.
And now I wonder how a class would look like to transform my defined types
into a representation suitable for ENC
Thanks, that gives me a clearer picture.
I think you should consider whether en ENC is really what you want, or at
least whether it's the way you want to approach this issue (because you
might want an ENC for other reasons as well). What an ENC has to offer in
this area is dynamic determination of the containers that should be managed
on each node, and possibly of those containers' parameters. Unless that's
a bona fide computation, however, you would be better off with a tool
dedicated to data externalization, such as Hiera.
If you insist on doing this via an ENC, then you must use global variables
or class parameters to inform some class about which containers to manage.
The parameter value would need to be an array (if you need only resource
titles) or a richer data structure such as a hash of hashes (if you need to
associate per-container parameters with some containers). The class might
look something like this:
# A class declaring one container for each
# element of its $container_names parameter
class lxc_containers($container_names) {
lxc_builder{ ${container_names}:
ensure = 'define',
ipadd='10.0.3.101/24'
}
}
If the idea behind your ENC is simply to feed canned data -- possibly from
some configuration file -- to such a class, however, then you are
reinventing the wheel. That is exactly the job to which Hiera is
dedicated. If you are using Puppet 3 then you can even use the exact same
class as above, and let Hiera look up the value for $container_names
(instead of writing or configuring an ENC to do it). If you want
compatibility with Puppet 2.[67], or if you want your class to be more
explicit about what's happening then you can modify it slightly to:
class lxc_containers {
$container_names = hiera('lxc_containers::container_names')
lxc_builder{ ${container_names}:
ensure = 'define',
ipadd='10.0.3.101/24'
}
}
Of course, you do need to then configure Hiera and write your data files,
but that's not so hard.
Great thx.
Even Im not allowed to use Hiera right now it is a good solution.
I will check the arrays and trying to look into puppet-virt to make my
containers a type (in the end).
Think this could make things easier even for ENC.
thx for the patience
Erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
On Friday, November 9, 2012 9:15:38 PM UTC-6, erkules wrote:
Ups sorry for the confusion.
Right now Ive got defines like:
lxc_builder{'starter01': ensure = 'define', ipadd='10.0.3.101/24' }
lxc_builder{'starter02': ensure = 'define', ipadd='10.0.3.102/24' }
lxc_builder{'starter03': ensure = 'define', ipadd='10.0.3.103/24' }
lxc_builder{'starter04': ensure = 'define', ipadd='10.0.3.104/24' }
The build an LXC application container on the host.
This works sufficient. Depending of the host there can be easily 100
Containers on
every host. (It is no KVM :)
So adding a container is writing a new line.
My intention was to put my configuration into an ENC.
Thats where the trouble started, as no place for defined types in ENC.
And now I wonder how a class would look like to transform my defined types
into a representation suitable for ENC
Thanks, that gives me a clearer picture.
I think you should consider whether en ENC is really what you want, or at
least whether it's the way you want to approach this issue (because you
might want an ENC for other reasons as well). What an ENC has to offer in
this area is dynamic determination of the containers that should be managed
on each node, and possibly of those containers' parameters. Unless that's
a bona fide computation, however, you would be better off with a tool
dedicated to data externalization, such as Hiera.
If you insist on doing this via an ENC, then you must use global variables
or class parameters to inform some class about which containers to manage.
The parameter value would need to be an array (if you need only resource
titles) or a richer data structure such as a hash of hashes (if you need to
associate per-container parameters with some containers). The class might
look something like this:
# A class declaring one container for each
# element of its $container_names parameter
class lxc_containers($container_names) {
lxc_builder{ ${container_names}:
ensure = 'define',
ipadd='10.0.3.101/24'
}
}
If the idea behind your ENC is simply to feed canned data -- possibly from
some configuration file -- to such a class, however, then you are
reinventing the wheel. That is exactly the job to which Hiera is
dedicated. If you are using Puppet 3 then you can even use the exact same
class as above, and let Hiera look up the value for $container_names
(instead of writing or configuring an ENC to do it). If you want
compatibility with Puppet 2.[67], or if you want your class to be more
explicit about what's happening then you can modify it slightly to:
class lxc_containers {
$container_names = hiera('lxc_containers::container_names')
lxc_builder{ ${container_names}:
ensure = 'define',
ipadd='10.0.3.101/24'
}
}
Of course, you do need to then configure Hiera and write your data files,
but that's not so hard.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/6c6bNUz8uRMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
On Thursday, November 8, 2012 6:29:47 PM UTC-6, erkules wrote:
Hi, Im still confused:
On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
On Friday, October 26, 2012 11:32:36 AM UTC-5, erkules wrote:
If not is there a trick to call a class many times for a node. (Maybe
by
manipulating the name?)
You can create classes with different names but similar content, or you
can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can
do
that via global variables (yuck), class parameters (meh), or data from
an
external source (best bet).
So you got a fixed number in here where you filter the right ones?
Ideally, you know what the right ones are and your class declares only
those. You can, however, use one or another sort of conditional to choose
which of the possible ones to declare.
I would like to call the class with parameters and for each parameter
the defined type is called. Where a parameter is a hash with 3 keys (where
one is the name).
That sounds a lot like the behavior of the built-in create_resources()
function. Look it up in the Puppet function reference.
With this I could decide to run more or less containers just by adding
parameters.
Puppet classes and definitions do not have varargs support. All the
parameters they can accept must be pre-defined, though you can assign
default values to them so that you don't need to declare each one each
time. Puppet does support arrays and hashes, however, and these can be
assigned as parameter values.
I don't know if this is a possible way to implement my needs *kopfkraz*
It would help if you were clearer about what your actual needs *are*. I
have given you rather a lot of information about how you can approach your
task with Puppet, but you remain unsatisfied. If I have not been speaking
to your issue then it is because I don't know what your issue is.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/8omI8AxRD7wJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
Thx for your patience.
On Fri, Nov 09, 2012 at 06:23:21AM -0800, jcbollinger wrote:
On Thursday, November 8, 2012 6:29:47 PM UTC-6, erkules wrote:
Hi, Im still confused:
On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
On Friday, October 26, 2012 11:32:36 AM UTC-5, erkules wrote:
If not is there a trick to call a class many times for a node. (Maybe
by
manipulating the name?)
You can create classes with different names but similar content, or you
can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can
do
that via global variables (yuck), class parameters (meh), or data from
an
external source (best bet).
So you got a fixed number in here where you filter the right ones?
Ideally, you know what the right ones are and your class declares only
those. You can, however, use one or another sort of conditional to choose
which of the possible ones to declare.
I would like to call the class with parameters and for each parameter
the defined type is called. Where a parameter is a hash with 3 keys (where
one is the name).
That sounds a lot like the behavior of the built-in create_resources()
function. Look it up in the Puppet function reference.
++
With this I could decide to run more or less containers just by adding
parameters.
Puppet classes and definitions do not have varargs support. All the
parameters they can accept must be pre-defined, though you can assign
default values to them so that you don't need to declare each one each
time. Puppet does support arrays and hashes, however, and these can be
assigned as parameter values.
great
I don't know if this is a possible way to implement my needs *kopfkraz*
It would help if you were clearer about what your actual needs *are*. I
have given you rather a lot of information about how you can approach your
task with Puppet, but you remain unsatisfied. If I have not been speaking
to your issue then it is because I don't know what your issue is.
Ups sorry for the confusion.
Right now Ive got defines like:
lxc_builder{'starter01': ensure = 'define', ipadd='10.0.3.101/24' }
lxc_builder{'starter02': ensure = 'define', ipadd='10.0.3.102/24' }
lxc_builder{'starter03': ensure = 'define', ipadd='10.0.3.103/24' }
lxc_builder{'starter04': ensure = 'define', ipadd='10.0.3.104/24' }
The build an LXC application container on the host.
This works sufficient. Depending of the host there can be easily 100 Containers
on
every host. (It is no KVM :)
So adding a container is writing a new line.
My intention was to put my configuration into an ENC.
Thats where the trouble started, as no place for defined types in ENC.
And now I wonder how a class would look like to transform my defined types into
a representation suitable for ENC
thx a lot
Erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
Hi, Im still confused:
On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
On Friday, October 26, 2012 11:32:36 AM UTC-5, erkules wrote:
If not is there a trick to call a class many times for a node. (Maybe by
manipulating the name?)
You can create classes with different names but similar content, or you can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can do
that via global variables (yuck), class parameters (meh), or data from an
external source (best bet).
So you got a fixed number in here where you filter the right ones?
I would like to call the class with parameters and for each parameter
the defined type is called. Where a parameter is a hash with 3 keys (where one
is the name).
With this I could decide to run more or less containers just by adding
parameters.
I don't know if this is a possible way to implement my needs *kopfkraz*
Regards
Erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
On Friday, October 26, 2012 3:53:42 PM UTC-5, erkules wrote:
On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
[snip]
If not is there a trick to call a class many times for a node. (Maybe
by
manipulating the name?)
You can create classes with different names but similar content, or you
can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Ok my defined types in a class.
How would that look like in a yaml-output?
It would just look like the class. The declarations inside a class are not
represented in the ENC output that declares the class. I presented a model
of how the class itself might look in my previous message.
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can
do
that via global variables (yuck), class parameters (meh), or data from
an
external source (best bet).
Hmm, right now it is the same application running multiple times.
It makes little difference, really, whether it is multiple instances of one
application or of different ones. That the applications are all the same
does favor modeling that application itself via a definition instead of a
class, however.
On the other hand, don't discard the idea of different classes too
lightly. In many cases it makes a lot of sense. In particular, it may
relieve pressure on your defined type to be sufficiently flexible to do
everything needed for any application you might ever want to use.
Having a
separate class for each module could make it a lot easier to deal with
the
special needs of each application.
Right, in my case it is (for now) the same application. Having for every
application
a different name would no be that dynamic I would suggest/hope it to be.
As the differ in IP and some dirs only.
So this would suggest to write a class for every application I want to run
then?
You'll have to judge for yourself what makes the most sense for your site.
What I'm saying is that if you find yourself writing a lot of conditionals
and special cases to support various different applications, then that
suggests you might be better off creating separate classes for those
applications. Such classes might or might not leverage whatever
general-purpose application resources you create, however works best for
you.
As for being dynamic, as long as you do not rely on parametrized-style
declarations -- either because your classes are not parametrized, or
because you rely on hiera (in Puppet 3) to provide any needed parameter
customization -- you can have entirely as much dynamic behavior in your
manifests with classes as with definitions. On the other hand, I think
that's rather a straw man in the context of an ENC. The whole point of an
ENC is to provide whatever dynamic behavior you want, therefore you don't
need a lot of dynamism in the manifests of an ENC-driven site.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/JrzSVa633C8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: defined types and enc
On Friday, October 26, 2012 11:32:36 AM UTC-5, erkules wrote:
Moin,
playing with puppet. I did some defined type creating
lxc-application-containers.
With that I could run a lot of virtualised applications on a host.
I choose defined types to call them many times for a node.
In my understanding classes will not be able to be called many times on a
node.
('name-clashing').
That's sort-of true, but it misses the key point. Classes represent
configurations features with singleton nature -- if managed at all then
they are either present/on or absent/off. Thus, although there are ways to
declare the same class more than once, but they do not permit you to use
different sets of parameters, and they have no additional implications for
the target node's configuration beyond what declaring that class once would
have.
In any case, supposing that you want to be able to declare containers for
multiple different applications on the same node, you cannot model them all
via a single class (though you can model a particular collection of them
with a class).
Trying to get my configuration into an enc. I looks like you can't use
defined types via enc.
So I wonder if Im wrong?
You are correct that an ENC cannot declare instances of a defined type, nor
of any other resource type for that matter. It can declare only classes
and global variables.
If not is there a trick to call a class many times for a node. (Maybe by
manipulating the name?)
You can create classes with different names but similar content, or you can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can do
that via global variables (yuck), class parameters (meh), or data from an
external source (best bet).
On the other hand, don't discard the idea of different classes too
lightly. In many cases it makes a lot of sense. In particular, it may
relieve pressure on your defined type to be sufficiently flexible to do
everything needed for any application you might ever want to use. Having a
separate class for each module could make it a lot easier to deal with the
special needs of each application.
Note also that names in Puppet should not contain the hyphen (-). It may
happen to work in some versions of Puppet, but it is not supported, and
some uses definitely will fail in various Puppet versions. This applies
most to variable names, including parameter names, but also to class,
module, and definition names.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/sGIe97g0JsEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: defined types and enc
On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
[snip]
If not is there a trick to call a class many times for a node. (Maybe by
manipulating the name?)
You can create classes with different names but similar content, or you can
use one class that wraps all the resources you want. For example,
class mymodule::lxc_application_containers {
mymodule::lxc_application_container { 'container1:
application = 'Awesomeness1.1'
# other parameters
}
mymodule::lxc_application_container { 'container2:
application = 'Moneymaker3.2'
# other parameters
}
# other containers ...
}
Ok my defined types in a class.
How would that look like in a yaml-output?
Supposing that the point is to select a subset of the available
applications for each target node, using the one-class approach, you can do
that via global variables (yuck), class parameters (meh), or data from an
external source (best bet).
Hmm, right now it is the same application running multiple times.
On the other hand, don't discard the idea of different classes too
lightly. In many cases it makes a lot of sense. In particular, it may
relieve pressure on your defined type to be sufficiently flexible to do
everything needed for any application you might ever want to use. Having a
separate class for each module could make it a lot easier to deal with the
special needs of each application.
Right, in my case it is (for now) the same application. Having for every
application
a different name would no be that dynamic I would suggest/hope it to be.
As the differ in IP and some dirs only.
So this would suggest to write a class for every application I want to run then?
[snip/thx]
Regards
Erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
