On Friday, May 6, 2016 at 5:19:50 AM UTC-5, Alexander Dacre wrote:
>
> I'm looking to build my first module with custom types and providers, but 
> I have some questions that I've been unable to find answers to.
>
> Lets say I have an application with a REST API that allows the creation of 
> widgets. My custom type and provider would define what the widget looks 
> like and contain code on how to create/delete etc. The problem is that the 
> REST API is authenticated with basic auth over HTTPS. Now, my question: 
> what is the general best practice for taking these credentials? Class 
> parameters? On a type instance basis?
>
>
The provider for each type has to have everything necessary to manage 
instances of that type.  In this case, that includes authentication 
credentials.  I see these options for communicating the credentials to 
providers:

   - hardcode them into the provider source (not recommended)
   - store them in some other, external client-side resource, such as a 
   file that the provider would read during catalog application (highly 
   questionable)
   - have the catalog builder feed them to the provider on a per-catalog 
   basis.  This would require making them parameters (not properties) of the 
   type.

If you go with the external resource, that probably means a file, and you 
can use any of the usual means to deliver an appropriate file to the 
appropriate place.

If you go with type parameters -- which seems the most likely approach to 
me -- then you still have to deliver the correct credentials in each 
declaration of an instance of your type, so there is a secondary question 
of how to feed those to the declaring class.  This is to a large extent the 
same analysis all over again, though whatever data store is involved is 
necessarily co-located with the catalog builder, so on the master in a 
master / agent setup.  My first inclination would be to use class 
parameters, or else maybe direct Hiera lookups, but analogs of all the same 
options there were for the type are also available for the class.


John

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/eab05c94-0c93-41c3-b10a-401c7e31c057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to