Thanks for your insights. I have not looked into title_patterns in this case because the name is available in the method and the other namevars are sufficient for retrieving the other information, though this would allow for the creation of resources with the same name value with other namevar values. I'm just starting to work with the resource api and I wanted to make sure I wasn't heading down the wrong road.
I started by trying to set the path to the only namevar, but soon realized that the simple provider requires the name value be the name. Allowing the use a value, other than name, could simplify this to some degree, since the path could be the identifier. Having something similar to the 'should' parameter in the get method would be helpful in cases where authoritative information on a type cannot be extracted from a server. This could be designed such that the type defines which values are exposed to the get method. This could be a safety mechanism a type/provider developer could use to keep other developers or themselves honest; i.e., force the provider to lookup the other attributes. An alternative implementation could be a separate feature for the type, similar to simple_get_filter, where all attributes in the resource are passed to the get method. The first option operates on the type, the second on each attribute. I'm relatively new to authoring types and providers, so I'm still learning. Thanks, Axton On Monday, October 28, 2019 at 5:06:43 AM UTC-5, David Schmitt wrote: > > Hi Axton, > > this is a long-standing issue with how puppet resources are implemented. > Adding path name vars like you did is one of the work arounds with the > least issues. if. you add title patterns, it can be actually quite nice to > use, say, defining for example "/etc/some.conf#key" for the "key" key in > the "/etc/some.conf" file. > > I've finally added this to the resource api backlog at > > https://github.com/puppetlabs/puppet-resource_api/projects/1#card-28372132 > > https://github.com/puppetlabs/puppet-resource_api/projects/1#card-26658327 is > another possible way forward, by providing the required data through a > separate resource in the catalogue. This would. Still not work for > instances where no catalogue is available (like the puppet resource > command) and make regular usage a lot more complex. > > would love to hear your thoughts. > > cheers, David > > On Sun, 27 Oct 2019, 22:07 gramsa49, <axton...@gmail.com <javascript:>> > wrote: > >> What is the best way to implement the get method in a new custom provider >> where information from the resource is required when using the Resource API? >> >> Using the management of public or private keys as an example, the get >> method cannot return a list of resources without certain information from >> the resource, like filename. >> >> I have managed to work around this by declaring certain parameters as >> :namevar so they are available in the provider's get method, but this >> doesn't seem like the intended use. Here is a working example: >> >> class Puppet::Provider::Pkey::Pkey < Puppet::ResourceApi::SimpleProvider >> def get(context, name) >> context.debug("Getting '#{name.inspect}'") >> result = [{}] >> name.each_index do |x| >> name[x].each do |key, val| >> result[x][key] = val unless key.to_s.eql? 'path' >> result[x][key] = val if (key.to_s.eql? 'path') && >> Pathname.new(val.to_s).exist? >> end >> result[x][:ensure] = 'present' >> end >> result >> end >> ... >> >> >> This basically iterates over the :namevar values and returns them in a >> hash if the resource exists. >> This is the complementary type for pkey: >> >> require 'puppet/resource_api' >> >> >> Puppet::ResourceApi.register_type( >> name: 'pkey', >> docs: <<-EOS, >> @summary a pkey type >> @example >> pkey { 'localhost.key': >> ensure => 'present', >> >> path => '/etc/ssl/private/localhost.key' >> >> outform => pem, >> algorithm => rsa, >> keysize => 2048, >> } >> >> This type provides Puppet with the capabilities to manage private keys >> EOS >> features: ['simple_get_filter'], >> attributes: { >> ensure: { >> type: 'Enum[present, absent]', >> desc: 'Whether this resource should be present or absent on the >> target system.', >> default: 'present', >> }, >> name: { >> type: 'String', >> desc: 'The name of the key', >> behavior: :namevar, >> }, >> path: { >> type: 'String', >> desc: 'The absolute path of the key file.', >> behavior: :namevar, >> }, >> ... >> >> >> >> The net effect of the code above is that the key shows to not exist if >> the file is not found, which is the desired behavior, but this seems like a >> misuse of :namevar. >> >> Is there are better way? >> >> This is going to be the case for any provider where state cannot be >> generated without user provided information, such as a filename (ini file, >> private key, certificate). >> >> Thanks, >> Axton >> >> -- >> 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...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/1279a793-5a8b-4e66-83d2-10e821f633b6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-users/1279a793-5a8b-4e66-83d2-10e821f633b6%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/47382477-a334-48e8-b5e9-fa864212b734%40googlegroups.com.
