FAQ
I'm working on a new provider for puppet 3.x and Solaris 11's dladm
command. One of the subcommands is set-linkprop which is used to set
various properties for networking links. The problem is there are dozens
and dozens of properties that can be set depending on the type of link
(physical or virtual) or what type of physical card is slotted on the
system.

I've been looking through some of the existing providers and the only thing
that comes even remotely close is the ZFS provider. The problem with that
provider is the list of possible properties is a hard-coded list. As
stated above, I can't really do something like that.

How can I design this provider, especially the exists? function, to handle
a dynamic list of valid properties? I was thinking of setting the type to
handle a manifest like:

linkprop { *'linkname'*:
     ensure => present,
     properties => { propname1 => value1, propname2 => value2, .... },
}

The exists? function would need to keep track of each individual propname
to pass off to create for later use. I'm assuming it's not an issue to
keep a "processed" hash table, but is that the "right" way to do it? Is
there a better way?

--
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/-/JFYEgLoIG_sJ.
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 Jan 16, 2013 at 3:39 pm

    On Tuesday, January 15, 2013 9:04:39 AM UTC-6, Drew Fisher wrote:
    I'm working on a new provider for puppet 3.x and Solaris 11's dladm
    command. One of the subcommands is set-linkprop which is used to set
    various properties for networking links. The problem is there are dozens
    and dozens of properties that can be set depending on the type of link
    (physical or virtual) or what type of physical card is slotted on the
    system.

    I've been looking through some of the existing providers and the only
    thing that comes even remotely close is the ZFS provider. The problem with
    that provider is the list of possible properties is a hard-coded list. As
    stated above, I can't really do something like that.

    How can I design this provider, especially the exists? function, to handle
    a dynamic list of valid properties? I was thinking of setting the type to
    handle a manifest like:

    linkprop { *'linkname'*:
    ensure => present,
    properties => { propname1 => value1, propname2 => value2, .... },
    }

    The exists? function would need to keep track of each individual propname
    to pass off to create for later use. I'm assuming it's not an issue to
    keep a "processed" hash table, but is that the "right" way to do it? Is
    there a better way?

    Maybe you're just using the wrong terminology, but if you're truly focusing
    on the provider then you are starting in the wrong place.

    You need to start with the the resource type. Is it a new type or an
    existing one? If new, then what target resource does it represent, and
    what properties does it expose for management? What identifier(s) does the
    system use for the target resource? Can the resource be created and
    removed, or is it always present even when unmanaged?


    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/-/36Rv46tTV5gJ.
    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.
  • Jakov Sosic at Jun 29, 2013 at 2:31 pm

    On 01/15/2013 04:04 PM, Drew Fisher wrote:
    I'm working on a new provider for puppet 3.x and Solaris 11's dladm
    command. One of the subcommands is set-linkprop which is used to set
    various properties for networking links. The problem is there are
    dozens and dozens of properties that can be set depending on the type of
    link (physical or virtual) or what type of physical card is slotted on
    the system.

    I've been looking through some of the existing providers and the only
    thing that comes even remotely close is the ZFS provider. The problem
    with that provider is the list of possible properties is a hard-coded
    list. As stated above, I can't really do something like that.

    How can I design this provider, especially the exists? function, to
    handle a dynamic list of valid properties? I was thinking of setting
    the type to handle a manifest like:

    linkprop { /'linkname'/:
    ensure => present,
    properties => { propname1 => value1, propname2 => value2, .... },
    }

    The exists? function would need to keep track of each individual
    propname to pass off to create for later use. I'm assuming it's not an
    issue to keep a "processed" hash table, but is that the "right" way to
    do it? Is there a better way?
    Why would you manage link property as a new resource? Why not manage it
    simply as property of a resource 'link'?


    --
    Jakov Sosic
    www.srce.unizg.hr

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 15, '13 at 4:55p
activeJun 29, '13 at 2:31p
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase