Thanks for your ideas Trevor, Looking at the current types and providers I could see some different ways to do the same so I will give them a look during this week. As soon as I have a working solution I will give feedback for others to work with.
Regards, On Thursday, May 30, 2013 4:25:49 PM UTC+2, Trevor Vaughan wrote: > > Looking through some additional code that does similar things, I'm fairly > certain that the first method will work but I'm not sure if my follow on > suggestions will. > > The 'package' and 'user' types use alternative providers but they do some > interesting things with manipulating the provider directly so I'm not > exactly sure how you would make this elegant. > > That said, you might also be able to do this with features in your type > and later provider confinement. > > Sorry to be so all over the place, I haven't done anything *exactly* like > this and the existing providers don't seem to either. > > Hopefully, one of the Puppet Labs folks will hop on and help out with a > working example. > > Trevor > > > > On Thu, May 30, 2013 at 9:34 AM, Trevor Vaughan > <[email protected]<javascript:> > > wrote: > >> 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 >> <[email protected]<javascript:> >> > 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 <[email protected]** >>>> > 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 [email protected]. >>>>> >>>>> 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 >>>> [email protected] >>>> >>>> >>>> -- 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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected]<javascript:> >>> . >>> 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 >> [email protected] <javascript:> >> >> >> -- This account not approved for unencrypted proprietary information -- >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] <javascript:> > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
