Provider requires package to work

[Jakub Pastuszek]

Hi All,

I have a provider dns_zone_recourd that is using nsupdate and dig
commands.
nsupdate and dig are provided by bind-utils RPM.
Before I get puppet to install bind-utils I am getting an error:
"Could not run Puppet configuration client: Could not find a default
provider for dns_zone_record"

I am getting an error that there are no providers available before
puppet is able to install the package that allows the provider to
operate.

Is it possible to tell Puppet to ensure a package is installed before
using a custom provider that needs it for operation?
Or I need to make sure that base OS contains all the commands that any
provider may ever need?

My provider contains this declaration:

commands :nsupdate => "nsupdate", :dig => "dig"

Thanks,
Jakub

[donavan]

On Jan 26, 1:58 am, Jakub Pastuszek <jpastus...@newbay.com> wrote:
>
> Is it possible to tell Puppet to ensure a package is installed before
> using a custom provider that needs it for operation?
> Or I need to make sure that base OS contains all the commands that any
> provider may ever need?

I seem to recall that this is a known issue, but not solved yet. I'd
suggest reposting to puppet-dev.

A common pattern to work around this is to use a 'boot strap' when
provisioning a node. This boot strap only contains enough resources to
get the machine, and puppet, to a workable state. After that a second
'full' run is done which applies the typical catalog. To implement
this I prefer just using tags, though I know others have used stages
and environments as well.

[donavan]

On Jan 26, 9:20 pm, donavan <dona...@desinc.net> wrote:
> A common pattern to work around this is to use a 'boot strap' when
> provisioning a node. This boot strap only contains enough resources to
> get the machine, and puppet, to a workable state. After that a second
> 'full' run is done which applies the typical catalog. To implement
> this I prefer just using tags, though I know others have used stages
> and environments as well.

Forgot to mention there's an open issue where plugins, like providers,
aren't synced if you use --tags with puppet agent. A simple work
around is to use a 'full' run with --noop, which will sync plugins but
not apply resources:
puppet agent -t --noop # gets plugins, facts, etc
puppet agent -t --tags boot_strap # install minimal resources like
resolv.conf & Package[bind-utils]
puppet agent -t # 'full' run which applies everything else.

[Jakub Pastuszek]

STRICTLY PRIVATE, CONFIDENTIAL AND PRIVILEGED COMMUNICATION.

This message (including attachments) may contain information that is
privileged, confidential or protected from disclosure. They are intended
solely for the use of the intended recipient. If you are not the
intended recipient, you are hereby notified that dissemination,
disclosure, copying, distribution, printing, transmission or use of this
message or any information contained in it is strictly prohibited. If
you have received this message from NewBay Software in error, please
immediately notify the sender by reply email and delete this message
from your computer. The content of this e-mail, and any files
transmitted with it, may have been changed or altered without the
consent of the author. Although we have taken steps to ensure that this
email and attachments are free from any virus, we advise that in keeping
with good computing practice the recipient should ensure they are
actually virus free.

[Nigel Kersten]

On Thu, Jan 27, 2011 at 8:32 AM, Jakub Pastuszek <jpast...@newbay.com> wrote:

> It would be probably better if Puppet initialized providers on demand (lazy).
> This way I would require that this package is installed before using the resource.

Yes. I'll try and find the bug, but that's definitely where we're going.

The best workaround is the one you're doing, where you provide the
base tools, but it's not ideal at all.