best debug output for resources?

[Philip Brown]

hi folks,
I'm trying some tweaks on a package provider.
I'd LIKE to debug it simply with

puppet resource package xyz

Trouble is, I'm getting no debug output.
I've tried using
   Puppet.debug "blah blah"

nothing.

I've tried adding --verbose. Doesnt help either.
Is there some other method I can use in the code to output stuff, when called as "puppet resource ..."?

And a semi-related question:

If I copy an existing package provider, lets say from "pkg.rb" to "pkg_test.rb", how can I force use of pkg_test as the provider of package resources, using the above one-syntax of

puppet resource ....

?

[Andy Parker]

Hi Philip,

Try using the --debug flag. You might also find --trace useful if you
get exceptions (it'll cause the backtrace to be printed).

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/N1x2k6aPmEQJ.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

[Philip Brown]

On Tue, Sep 18, 2012 at 9:48 AM, Andy Parker <an...@puppetlabs.com> wrote:
> Hi Philip,
>
> Try using the --debug flag. You might also find --trace useful if you
> get exceptions (it'll cause the backtrace to be printed).
>

Oh wow. lots of things support --debug! :)

good to be reminded of that, thanks.

I also note, that, if one does NOT want to be flooded with general
debug, tossing in a

warning "printf-type message here"

line, seems to get the job done too, if the goal is just temporary debugging.

Still wondering how to force override of a package provider type for
"puppet resource package ..." command line use, though.

[Andy Parker]

I think (haven't tried) that you can do "puppet resource ....
provider=pkg_test" if you also rename the provider to pkg_test in the
pkg_test.rb file.

> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

[Philip Brown]

On Tue, Sep 18, 2012 at 11:27 AM, Andy Parker <an...@puppetlabs.com> wrote:
> On Tue, Sep 18, 2012 at 10:04 AM, Philip Brown <ph...@bolthole.com> wrote:
>
>> Still wondering how to force override of a package provider type for
>> "puppet resource package ..." command line use, though.
>>
>
> I think (haven't tried) that you can do "puppet resource ....
> provider=pkg_test" if you also rename the provider to pkg_test in the
> pkg_test.rb file.
>

Hmm. well, it does seem to not complain, if you put it as the last
thing on the line.
However, according to --debug, it doesn't seem to actually DO anything.
It still calls all the other providers.

debug: Puppet::Type::Package::ProviderRpm: file rpm does not exist
debug: Puppet::Type::Package::ProviderUp2date: file
/usr/sbin/up2date-nox does not exist
....

[Andy Parker]

That is odd. However, this should only work if you have a
self.instances method. Can you post the code that you are trying to
use?

[Philip Brown]

On Tue, Sep 18, 2012 at 4:08 PM, Andy Parker <an...@puppetlabs.com> wrote:
> On Tue, Sep 18, 2012 at 11:43 AM, Philip Brown <ph...@bolthole.com> wrote:
>>>>>
>>> I think (haven't tried) that you can do "puppet resource ....
>>> provider=pkg_test" if you also rename the provider to pkg_test in the
>>> pkg_test.rb file.
>>>
>>
>> Hmm. well, it does seem to not complain, if you put it as the last
>> thing on the line.
>> However, according to --debug, it doesn't seem to actually DO anything.
>> It still calls all the other providers.
>>
>> debug: Puppet::Type::Package::ProviderRpm: file rpm does not exist
>> debug: Puppet::Type::Package::ProviderUp2date: file
>> /usr/sbin/up2date-nox does not exist
>> ....
>>
>
> That is odd. However, this should only work if you have a
> self.instances method. Can you post the code that you are trying to
> use?
>

Do this on a solaris 11 box:

(go to the package providers dir)
cp pkg.rb pkg_test.rb
(edit pkg_test.rb and change "pkg" class identity references to pkg_test)
(I think that means just changing the first ":pkg" to ":pkg_test" ? )

puppet resource --debug package gnu-patch provider=pkg_test


You will then see debug output by practically all other package providers.

I suppose I should mention that the puppet version I'm using, is that
autobuilt by ruby gems.
2.7.18

[Andy Parker]

On Tue, Sep 18, 2012 at 4:26 PM, Philip Brown <ph...@bolthole.com> wrote:
>
> Do this on a solaris 11 box:

Solaris 11 on 2.7 has problems. There has been a lot of work on
improving Solaris support in the upcoming Puppet 3 release.

>
> (go to the package providers dir)
> cp pkg.rb pkg_test.rb
> (edit pkg_test.rb and change "pkg" class identity references to pkg_test)
> (I think that means just changing the first ":pkg" to ":pkg_test" ? )
>
> puppet resource --debug package gnu-patch provider=pkg_test
>

I just tried this out with the gem provider (I don't have a solaris
box) and it did what I expected.

[13:26:29][Ruby(ruby-1.8.7-p358)][Git(2.7.x)] andy:puppet
> puppet resource package mocha -p provider provider=gem_test
package { 'mocha':
ensure => ['0.10.5'],
provider => 'gem_test',
}
[13:26:36][Ruby(ruby-1.8.7-p358)][Git(2.7.x)] andy:puppet
> puppet resource package mocha -p provider
warning: Package bundler found in both gem and gem_test; skipping the
gem_test version
warning: Package columnize found in both gem and gem_test; skipping
the gem_test version
warning: Package diff-lcs found in both gem and gem_test; skipping the
gem_test version
warning: Package fuubar found in both gem and gem_test; skipping the
gem_test version
warning: Package hpricot found in both gem and gem_test; skipping the
gem_test version
warning: Package hub found in both gem and gem_test; skipping the
gem_test version
warning: Package linecache found in both gem and gem_test; skipping
the gem_test version
warning: Package metaclass found in both gem and gem_test; skipping
the gem_test version
warning: Package mocha found in both gem and gem_test; skipping the
gem_test version
warning: Package net-scp found in both gem and gem_test; skipping the
gem_test version
warning: Package net-ssh found in both gem and gem_test; skipping the
gem_test version
warning: Package rake found in both gem and gem_test; skipping the
gem_test version
warning: Package rbx-require-relative found in both gem and gem_test;
skipping the gem_test version
warning: Package rcov found in both gem and gem_test; skipping the
gem_test version
warning: Package rspec found in both gem and gem_test; skipping the
gem_test version
warning: Package rspec-core found in both gem and gem_test; skipping
the gem_test version
warning: Package rspec-expectations found in both gem and gem_test;
skipping the gem_test version
warning: Package rspec-instafail found in both gem and gem_test;
skipping the gem_test version
warning: Package rspec-mocks found in both gem and gem_test; skipping
the gem_test version
warning: Package ruby-debug found in both gem and gem_test; skipping
the gem_test version
warning: Package ruby-debug-base found in both gem and gem_test;
skipping the gem_test version
warning: Package ruby-progressbar found in both gem and gem_test;
skipping the gem_test version
warning: Package sqlite3-ruby found in both gem and gem_test; skipping
the gem_test version
warning: Package stomp found in both gem and gem_test; skipping the
gem_test version
warning: Package systemu found in both gem and gem_test; skipping the
gem_test version
package { 'mocha':
ensure => ['0.10.5'],
provider => 'gem',

}

>
> You will then see debug output by practically all other package providers.
>

Could you provide that debug output. I'm at a loss for what is happening now.

> I suppose I should mention that the puppet version I'm using, is that
> autobuilt by ruby gems.
> 2.7.18
>

[Philip Brown]

On Wed, Sep 19, 2012 at 1:30 PM, Andy Parker <an...@puppetlabs.com> wrote:
> On Tue, Sep 18, 2012 at 4:26 PM, Philip Brown <ph...@bolthole.com> wrote:
>> puppet resource --debug package gnu-patch provider=pkg_test

>>...

>> You will then see debug output by practically all other package providers.
>>
>
> Could you provide that debug output. I'm at a loss for what is happening now.

okies.
This is actually from a "standard" machine without pkg_test, so
command line I used is
puppet resource --debug package gnu-patch provider=pkg >/tmp/output 2>&1
Excerpt from output:

# more /tmp/output
debug: Puppet::Type::Package::ProviderPortupgrade: file /usr/local/sbin/portupgr
ade does not exist

debug: Puppet::Type::Package::ProviderUp2date: file /usr/sbin/up2date-nox does n
ot exist

debug: Puppet::Type::Package::ProviderPacman: file /usr/bin/pacman does not exis
t
debug: Puppet::Type::Package::ProviderBlastwave: file pkg-get does not exist
debug: Puppet::Type::Package::ProviderFreebsd: file /usr/sbin/pkg_info does not
exist
debug: Puppet::Type::Package::ProviderAix: file /usr/bin/lslpp does not exist
debug: Puppet::Type::Package::ProviderNim: file /usr/sbin/nimclient does not exi
st

and so on and so forth.

So, on solaris, it is having ALL providers for resource type package, poll.
Whether you specify a provider explicitly on commandline, or not.

[Andy Parker]

Yeah, even when a provider is specified it'll check the others to see
if they would work. I'm not certain why that is done, but may not be
needed. However, I dont' think it is causing the problem.

Are you certain that the pkg_test.rb file is available in the load
path when you are running puppet? One way to find out if it is looking
at the right files is to break the pkg.rb provider and see if your
command breaks. This will tell you if it is loading the code you think
it is.

[Philip Brown]

On Thu, Sep 20, 2012 at 9:03 AM, Andy Parker <an...@puppetlabs.com> wrote:
>
> Yeah, even when a provider is specified it'll check the others to see
> if they would work. I'm not certain why that is done, but may not be
> needed. However, I dont' think it is causing the problem.
>

Erm.. we seem to be having a communications breakdown.
I'm saying, that IS the problem :)
Particularly on a system like solaris, where it has multiple possible
package providers, so the other providers will note that they CAN
work, and maybe override stuff.
Not good, when I've explicitly defined the provider I want puppet to use.

[Nan Liu]

Puppet will use the package provider you specified. This is a trivial
example where users can specify package provider => gem (shipped with
puppet) or provider => pe_gem (provided by the module):

https://github.com/puppetlabs/puppetlabs-pe_gem

Thanks,

Nan

[Andy Parker]

I can see how there is a potential for a problem because of this
behavior, but I haven't seen anything yet that tells me that is the
problem you are seeing. Can you explain to me again what exactly the
problem is that you are seeing and why you think that it checking
other providers even when one is specified is causing that problem?

[Philip Brown]

On Thu, Sep 20, 2012 at 11:01 AM, Andy Parker <an...@puppetlabs.com> wrote:

> I can see how there is a potential for a problem because of this
> behavior, but I haven't seen anything yet that tells me that is the
> problem you are seeing. Can you explain to me again what exactly the
> problem is that you are seeing and why you think that it checking
> other providers even when one is specified is causing that problem?

okay, sorry, reset time.
This "checking other providers" issue, is separate from any other
issue I've talked about.
I believe this is a problem, for a few reasons:

1. It pollutes the --debug output. Grossly, to the tune of multiple
pages of useless garbage output.
I consider this a non-trivial bug
2. Some of the providers (mainly, the "sun" one) are potentially
expensive in startup times. I'm concerned that if the sun one notices
it can run, then it will pre-populate its package hash. Which can be
reaaaally slow
3. (I havent run into this yet, but) it could potentially cause
conflicts, where if there is a duplicate name, a package gets loaded
from the wrong provider.
Note that under solaris 11, there are at least FOUR potential providers:
- sun
- blastwave
- sunfreeware
- pkg

any, or all, of blastwave, sunfreeware, and pkg, could have a
software package referenced as "make", for example.
So, if I designate "pkg" as the provider I want, and tell it to ensure
package "make" is installed... but it then finds sunfreeware active,
and decides to install a "make" package from there instead... then
that would be obviously bad.

Now, all this being said... rather than asking me "could you please go
spend a bunch of time verifying whether #3 happens or not", would it
be possible for puppetlabs to acknowlege, "well, #1 is 100% a real
verified bug. So we'll fix that, and then we probably wont have to
worry about #2 and #3 either" ?