Looking at the 'host' provider from puppet, it looks like, to use a single
provider, you'll need to both confine it and to use the :operatingsystem
fact to create a case statement inside the provider.
So, yes, you can do what you want but not exactly in the most obvious
fashion.
Something like the following should work (untested):
Puppet::Type.type(:unpack).provide(:zip) do
case Facter.value(:operatingsystem)
when "windows"
...do windows stuff...
when "Solaris"
...do solaris stuff...
else
....do linux stuff....
end
end
Another way of possibly doing this would be to munge the provider name
before calling your provider.
You would use your example #2 above and then use the :operatingsystem fact
to change the provider name. This may be a code smell/horrible practice but
it *should* work (haven't tested this either).
Something like:
newparam(:provider) do
munge do |value|
"#{Facter.value(:operatingsystem)}_#{self[:provider]}"
end
end
If that doesn't work, you might have to hack it into the type initialize
define.
Something like:
def initialize(args)
super
self[:provider] = "#{Facter.value(:operatingsystem)}_#{self[:provider]}"
end
Good luck!
Trevor
On Thu, May 30, 2013 at 6:58 AM, David Campos wrote:Hello Trevor,
Thanks for the reply. I did knew that I should use confine statement to
reach that goal but I did not know whether I did need a new provider for
each OS or if I can share it.
Sample:
File rar-windows.rb
Puppet::Type.type(:zipfile).provide(:rar, ...)
confine :operatingsystem => :windows
File rar-unix.rb
Puppet::Type.type(:zipfile).provide(:rar, ...)
confine :operatingsystem => :linux
If puppet allows the same provider to be defined twice or more times this
would work and would be perfect because I could select provider => zip and
forget about OS.
Sample2
File rar-windows.rb
Puppet::Type.type(:zipfile).provide(:rar-windows, ...)
confine :operatingsystem => :windows
File rar-unix.rb
Puppet::Type.type(:zipfile).provide(:rar-unix, ...)
confine :operatingsystem => :linux
If the first sample does not work, this would mean that I have to select
the provider with puppet selectors before sending the parameter into the
resource.
On Wednesday, May 29, 2013 4:09:04 PM UTC+2, Trevor Vaughan wrote:David,
You'll need to use confine statements to set the suitability of a
particular provider to the OS.
See:
http://projects.puppetlabs.**com/projects/1/wiki/**Development_Provider_**Development<
http://projects.puppetlabs.com/projects/1/wiki/Development_Provider_Development>under 'Suitability'.
The new Types and Providers book covers this reasonably well also.
Finally, take a look at the 'group' provider in the Puppet core code to
see how they go between Windows and other OS's.
Good Luck!
Trevor
On Wed, May 29, 2013 at 5:40 AM, David Campos wrote:Hello all,
I am developing a few custom providers for some features that I need
into my system (such as dealing with different zipped files or generating
some JSON data based on OS files) and I have hit into a question about "how
to do this for multiple OS?"
Lets focus into the zipped file provider that should provide a common
method to pack or unpack zipped files (tar, tar.gz, rar, zip or any) backed
on OS tools or native ruby methods. Maybe the ruby approach would be the
most portable one but I will keep that approach aside right now. We end up
with 3 providers for the custom type 'zipfile': zip, rar and tar.
Those providers may share code but they differ on how to delegate its
functionality to third-party apps (7zip on windows and zip/unzip on linux
as an example). How can I deal with that? Can I clone the provider into
different files such as zip-windows.rb and zip-linux.rb, keep the same
header and use the confine method? Is there any filename -> provider
restriction? Is that the correct approach?
I have been searching through other core providers like file but I can
not find my answer...
Thanks
--
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...@**googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at
http://groups.google.com/**group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
.
For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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?hl=en.For more options, visit
https://groups.google.com/groups/opt_out. --
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com-- This account not approved for unencrypted proprietary information --
--
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?hl=en.For more options, visit
https://groups.google.com/groups/opt_out.
