Puppet users - Jan 2013 - Recommendations for devlopment of a new provider

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.

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.

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.