* This keeps us from hitting bugs in repoquery/yum plugins in certain
instances (#2559).
* The previous is also a small performance boost
* Also in is_installed(), when using the yum API, return if we detect
a package name has been installed. We don't need to also check
virtual provides in that case. This is another small performance
boost.
* Sort the list of packages returned by the list parameter.
If the requirements contains a repos url it will always report 'Successfully
installed'; there is no difference in the output to tell apart if
anything new was pulled. Use freeze to detect if the environment changed
in any way.
Should fixansible/ansible#1705
The yum module allows the 'name' parameter to be given as 'pkg', in
a similar way to some of the other package managers. This change
documents this alias.
The module's 'state' parameter has two other aliases, in line with
the 'apt' action; the 'state' parameter can take 'installed' as an
alias for 'present', and 'removed' as an alias for 'absent'. These
aliases are documented.
Closes#1189.
This will cause the settings in Ansible to override the system settings.
That will have no effect except on systems that have an out-of-Ansible
configuration that disables automatic installation of recommended
packages. Previously, ansible would use the OS default whenever
install_recommends wasn't part of the playbook. This change will cause
the Ansible default configuration setting of installing recommended
packages to override the configuration files set on the OS for things
installed through ansible, even when there is no install_recommends
specified in the playbook. Because the OS default matches the Ansible
default, this shouldn't have wide impact.
This was originally required to allow other methods in SourcesList to
fail, but subsequent changes rendered that unnecessary, and it's just
a cleanup now, and avoids passing in module separately to save().
1. Don't test check_mode in both the caller and in the callee.
2. Don't test HAVE_PYTHON_APT inside an if that tests HAVE_PYTHON_APT
3. Don't be irritatingly vague about why the module fails ("You may be
seeing this because…").
Note that if «apt-get -y install python-apt» succeeds with rc==0, but
for some reason python_apt is not usable afterwards, this will break
because the imports in install_python_apt aren't wrapped inside a
try/except.
In other words, we assume that install_python_apt either succeeds or
fails with a traceback. This commit doesn't affect that behaviour.
The original problem is: apt_repository.py connect to launchpad on
every playbook run. In this patch apt_repository.py checks if required
repository already exists or not. If no - paa will be added, if yes -
just skip actions.
Fix#412. Check mode was always returning changed=True for pip
when the target was in a virtualenv. The code now uses the normal
tests for determining if change status.
* Only install yum-utils if needed (b/c we're going to use repoquery)
* Add a warning message explaining that why slower repoquery was used
rather than yum API.
The message there is that Yum API prints an error message if the
rhn-plugin is in use and no rhn-certificate is available. So instead of
using repoquery in preference always here we use repoquery in preference
if the rhn-plugin is enabled.
The ordering of disabling/enabling yum repositories matters, and
the yum module was mixing and matching the order. Specifically,
when yum-utils isn't installed, the codepath which uses the yum
python module was incorrectly ordering enabling and disabling.
The preferred order is to disable repositories and then enable them
to prevent clobbering. This was previously discussed in
ansible/ansible#5255 and incompletely addressed in 0cca4a3.
When subscribing a system with an activationkey, it seems (sometimes?)
required to pass the "--org <number>" parameter to subscription-manager.
Activation Keys can be created through the Red Hat Customer Portal, and
a subscription can be attached to those. This makes is easy to register
systems without passing username/passwords around.
The organisation ID can be retrieved by executing the following command
on a registered system (*not* the account number):
# subscription-manager identity
URL: https://access.redhat.com/management/activation_keys
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-by: Ken Dreyer <kdreyer@redhat.com>
Prior to this commit, Ansible would pass '--activationkeys <value>' as a
literal string, which the remote server would interpret as a single
argument to subscription-manager.
This led to the following failure message when using an activation key:
subscription-manager: error: no such option: --activationkey "mykey"
Update the arguments so that the remote server will properly interpret
them as two separate values.
Barnaby Court
Michael Scherer
Martin Matuska
stephane
Toshio Kuratomi
Veaceslav Mindru
Daniele Varrazzo
Daniel Kimsey
Charles Ferguson
Felix Engelmann
Harlan Lieberman-Berg
Patrick Galbraith
Brian Coca
Greg DeKoenigsberg
Marius Gedminas
Jason DeTiberus
queridiculo
Austin Brown
Pierre-Louis Bonicoli
Abhijit Menon-Sen
Yuhui Huang
Wouter Bolsterlee
Matt Martz
verm666
Sebastian Gerhards
Jim Patterson
az7arul
Greg DeKoenigsberg
Edward Torbett
Demian Gemperli
Jonathan Mainguy
Vasyl Kaigorodov
Schlueter
Zoltan Kozma
Semyon Deviatkin
Dominic Hargreaves
James Cammarata
bugchecker
David Wittman
Niels de Vos
Michael Scherer
Ken Dreyer