That seems to work! The message about the compiler being invoked is a
bit worrying through.
Amusingly, I'm also working on types for jenkins but with the cli jar
and groovy script fragments instead of the rest API.
-Josh
--
On 04/15/2015 11:03 AM, Branan Riley wrote:
`select` may be the method you want.
https://github.com/branan/puppet-jenkins/blob/jenkins_agent_type/lib/puppet/provider/jenkins_agent/json.rb#L50
is my code from a few years ago.
On Wed, Apr 15, 2015 at 10:58 AM, Joshua Hoblitt <[email protected]> wrote:
Hi Branna,
Under 3.7.5, that gives me a Puppet::Indirector::Face object.
https://github.com/puppetlabs/puppet/blob/3.7.5/lib/puppet/
indirector/face.rb
I'm not sure where to go from there as I don't want to download a new new
catalog, and at least from pry under the resource face, #find seems to
generate garbage catalogs. Any ideas?
-Josh
--
On 04/15/2015 09:42 AM, Branan Riley wrote:
In the past I have done this with `Puppet::Face[:catalog, :current]`
I did this in a prototype back for Puppet 2.7, so I have no idea if it
still works, and I can't promise that it will continue to work in the
future.
-- Branna
On Tue, Apr 14, 2015 at 7:49 PM, Joshua hoblitt <[email protected]> wrote:
I desire the ability to access DSL class parameters from within a
provider. Similar to the pattern that is frequently seen with DSL
defined
types and a controlling class within a module. AFAIK, the alternatives
for
sharing data are ugly. Including: forcing the user to declare facts via
ENC or an external fact source, using a file resource for "local IPC" (or
sysv shm...), or adding parameters to the type and using a DSL defined
type
as wrapper. The later is the least objectionable but feels like it
should
be unnecessary; the data is already in the catalog.
Accessing the catalog from within a provider instance isn't very
difficult
since the instantiated resource has an accessor for it. Eg.
`resource.catalog` Where I've hit a roadblock is trying to access the
catalog from a class method. I've spent several hours poking at classes
looking for an instance I could pry into or a singleton I could access
without much luck. There was a suggestion on #puppet that it might be
possible to obtain it via the indirector. I don't understand the
indirection facility but I don't believe it has knowledge beyond the name
of the catalog class. Eg. `Puppet::Indirector::
Indirection.instance(:catalog).instance_variable_get(:@
indirected_class).class`
Perhaps I'm in error? I also failed to identify a reference back to the
current transaction.
My last resort was to try passing the catalog from the resource to the
provider as class data. This is problematic in that I can't identify a
place to "hook" in that runs after both `Puppet::Util::ClassGen.
genclass`
and the providers are associated with a type but before the provider's
class instances method is called. I've been resisting the temptation to
stuff something into the `Puppet::Type.provide` method's option hash and
monkey patching my way to victory...
I did have some limited success in that I was able to get into the
catalog
from `::prefetch` by adding class accessors for `catalog` to the provider
and dropping this snippet into an autorequire block.
if provider.class.respond_to?(:catalog)
provider.class.catalog = catalog
end
Of course, where I want access to the catalog data is from `::instances`.
Have I missed something obvious?
Cheers,
-Josh
--
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/
msgid/puppet-dev/552DD1D6.5060005%40hoblitt.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/
msgid/puppet-dev/552EA6AD.2030606%40cpan.org.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/552EAAF3.3070404%40cpan.org.
For more options, visit https://groups.google.com/d/optout.
