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'').
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?
If not is there a trick to call a class many times for a node. (Maybe by
manipulating the name?)
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.