Feature #915

Add 'options' support to type/provider relationship

Added by Luke Kanies over 4 years ago. Updated about 1 year ago.

Status:Duplicate Start date:
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:RAL
Target version:-
Affected Puppet version:0.24.7 Branch:
Keywords:
Votes: 7

Description

Some providers (notably packages) are configurable, and it is often important to be able to use that configuration to get specific behaviour from the providers.

We should add an ‘option’ hook to the providers, akin to the current ‘feature’ hook.


Related issues

related to Puppet - Feature #2247: enablerepo and disablerepo for yum type Needs Decision 05/12/2009
duplicated by Puppet - Feature #4800: Enable ability to give package manager command line options Duplicate 09/17/2010
duplicated by Puppet - Feature #2325: Apt provider should allow passing of arbitrary configurat... Duplicate 06/04/2009
duplicated by Puppet - Feature #1766: Control of recommends installation with aptitude provider Duplicate 11/20/2008
duplicates Puppet - Feature #4113: Allow provider-specific options as a first class part of ... Accepted 07/01/2010
duplicated by Puppet - Bug #1597: managing gems with Package does not allow arguments Duplicate 09/23/2008
duplicated by Puppet - Feature #6530: Do not generate rdoc and ri docs when installing gem pack... Duplicate 03/01/2011
duplicated by Puppet - Feature #4193: gem provider should support 'platforms' Duplicate 07/09/2010
duplicated by Puppet - Feature #556: apt provider should support --allow-unauthenticated option Duplicate

History

Updated by Redmine Admin almost 4 years ago

  • Status changed from 1 to Accepted

Updated by Luke Kanies almost 4 years ago

  • Priority changed from High to Normal
  • Affected Puppet version set to 0.24.4

Updated by James Turnbull about 3 years ago

  • Affected Puppet version changed from 0.24.4 to 0.24.7

Updated by Brandon Evans about 3 years ago

Another example of when being able to modify provider options would be when one wants to install a package from a repo that is disabled by default. For example, installing a package from rpmforge when rpmforge is disabled by default on my servers.

when running from the command line I can simply run:

yum —enablerepo=rpmforge install PACKAGE

however to do this in puppet I need o use an exec, or as ‘jamesturnbull’ suggested:

[3:52pm] package has a require and a notify metaparam [3:52pm] the requireis linked to a yumrepo resource that enables rpmforge [3:52pm] the notify is linked to a yumrepo resource that disables it

Both solutions work however having to use exec seems like a wast of the package{} command. Temporarily enabling the repo then triggering another resource is flawed too. Yums locking should prevent this, but what if someone on the server is doing a ‘yum update httpd’ while puppet has switched the rpmforge repo to enabled?

Updated by James Turnbull almost 3 years ago

  • Assignee deleted (Puppet Community)

Updated by Walter Heck over 1 year ago

I’d love to see this feature. I’m tryign to install zabbix-server-mysql with apt. This package has in the list of it’s recommended packages mysql-server, which I specifically don’t want. For any other package I install I do want the recommended packages though. That requires me to add —no-install-recommends to the command line params,which is currently not possible. Cleanest workaround for me right now is an apt-get Exec.

Updated by Nigel Kersten over 1 year ago

  • Target version deleted (4)

Updated by Richard Marshall about 1 year ago

What’s the status on this Feature? I can’t find any notes to explain why this was deleted. We’re finding that there are several different options that we’d like to be applying to apt instead of the defaults but we have to do it through exec which is rather inelegant. (it’s Feature 4800 that matches our request exactly, but that seems to be merged into this one)

Updated by James Turnbull about 1 year ago

It’s not deleted – it’s unplanned. This means it’s not something we’re immediately working on.

Updated by Nigel Kersten about 1 year ago

Richard, do you want to be changing which options are in use with different invocations of the package install?

Most of the time I’ve hit this problem it’s been much more maintainable to have those set up as global apt preferences. I had a hacky implementation of this feature, and it was really quite difficult to debug.

Can you outline what options you want to be able to set?

Updated by Nigel Kersten about 1 year ago

  • Status changed from Accepted to Duplicate

Although this is the older ticket, more current discussion is going on in #4113 so I’m reversing the normal duplicate relationship.

Also available in: Atom PDF