FAQ
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.

Search Discussions

  • Jcbollinger at Oct 27, 2012 at 6:33 am

    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.
  • Erkan yanar at Oct 26, 2012 at 10:29 pm
    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.
  • Jcbollinger at Oct 29, 2012 at 1:15 pm

    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.
  • Erkan yanar at Nov 9, 2012 at 12:29 am
    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.
  • Jcbollinger at Nov 9, 2012 at 2:23 pm

    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.
  • Erkan yanar at Nov 10, 2012 at 3:15 am
    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.
  • Jcbollinger at Nov 12, 2012 at 2:32 pm

    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.
  • Erkan yanar at Nov 14, 2012 at 2:23 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 26, '12 at 5:38p
activeNov 14, '12 at 2:23p
posts9
users2
websitepuppetlabs.com

2 users in discussion

Erkan yanar: 5 posts Jcbollinger: 4 posts

People

Translate

site design / logo © 2022 Grokbase