Dear Ansible Team and Users,
1) Could you please tell me, is it possible to implement the
installation of the packages from the certain repositories without
enabling them globally?
2) Can I install group of packages, instead of naming them separately?
3) From your point of you, what is the best schema for massive ansible
deployment for 500+ desktop linux machines?
Thank you in advance,
WBR, Mike Grozak
Dear Ansible Team and Users,
- Could you please tell me, is it possible to implement the
installation of the packages from the certain repositories without
enabling them globally?
not presently, unless you just ran yum via the command/shell module or something
- Can I install group of packages, instead of naming them separately?
deferring Q to others.
- From your point of you, what is the best schema for massive ansible
deployment for 500+ desktop linux machines?
Didn’t quite grok “schema” here. Setup? Yum specific question or ansible
scaling in general?
Hello,
not presently, unless you just ran yum via the command/shell module or something
Ok, I'll try to have a look at the source code of yum module, maybe
I'll find a way to implement it for me
> 3) From your point of you, what is the best schema for massive ansible
> deployment for 500+ desktop linux machines?Didn't quite grok "schema" here. Setup? Yum specific question or ansible
scaling in general?
Ansible scaling in general.
Didn’t quite grok “schema” here. Setup? Yum specific question or ansible
scaling in general?Ansible scaling in general.
Depends if you need to configure at initial provisioning time or repeatedly.
For repeatedly, check out ansible-pull, which has a playbook to set it up in the examples dir.
Uses cron+git, and inverts the push architecture.
Should scale like crazy, and bootstraps itself (mostly) just like regular Ansible – so it’s easy to reconfigure.
(it technically assumes you have a yum repo that can find ansible, which you can set up with ansible)
–Michael
Ok, thank you for the answers. I'll try to install and setup ansible-
pull; we'll see want will come out 
Dear Ansible Team and Users,
1) Could you please tell me, is it possible to implement the
installation of the packages from the certain repositories without
enabling them globally?
You want some way to pass in 'enable this repo'? If the .repo file is
on the system then, sure, we could probably add something to do that.
Alternatively a simple mechanism for you - since ansible runs in serial
would be to have
action: command yum-config-manager --enable somerepo somerepo1
action: yum state=installed pkg=foo
action: command yum-config-manager --enable somerepo somerepo1
Otherwise we'd need to modify the yum module to take
repoenables/disables as a part of the arguments which feels a bit
weird to me since from a declarative standpoint it feels awkward.
2) Can I install group of packages, instead of naming them separately?
the module currently doesn't support groups - only b/c the check to see
if the pkg is available is going to trip over the @group syntax. I can
pretty easily manage for that - but just to be clear the process to
check if a group is installed is.... a bit of a guess, really. It's a
heuristic which is not fantastic but 'works'.
I could probably make @groupname look there first.
However, I would want to reserve the right to just make state=removed
pkg=@groupname do exactly nothing b/c removing groups w/o user
intervention can be..... dangerous.
-sv
Thank you for the answers!
> 1) Could you please tell me, is it possible to implement the
> installation of the packages from the certain repositories without
> enabling them globally?You want some way to pass in 'enable this repo'? If the .repo file is
on the system then, sure, we could probably add something to do that.
Alternatively a simple mechanism for you - since ansible runs in serial
would be to haveaction: command yum-config-manager --enable somerepo somerepo1
action: yum state=installed pkg=foo
action: command yum-config-manager --enable somerepo somerepo1Otherwise we'd need to modify the yum module to take
repoenables/disables as a part of the arguments which feels a bit
weird to me since from a declarative standpoint it feels awkward.
I thought about something like:
action: yum state=installed pkg=foo repo=rpmforge
or, sometimes, it's better to specify 2 repos:
action: yum state=installed pkg=foo repo=rpmforge,epel
To be honest, it looks rather clean to me:) Without "repo" argument
the installation is performed in a standard way; with it - with
"enablerepo" argument to the yum command.
> 2) Can I install group of packages, instead of naming them separately?
the module currently doesn't support groups - only b/c the check to see
if the pkg is available is going to trip over the @group syntax. I can
pretty easily manage for that - but just to be clear the process to
check if a group is installed is.... a bit of a guess, really. It's a
heuristic which is not fantastic but 'works'.I could probably make @groupname look there first.
However, I would want to reserve the right to just make state=removed
pkg=@groupname do exactly nothing b/c removing groups w/o user
intervention can be..... dangerous.
According to my experience, on a common Linux system, administrator
does not really want to delete anything massively from the initial
installation. From the other side, in an ideal world, such action
should be possible - for example, when you want to clean up the
systems from the unnecessary localization groups, legacy software
support, or clean up a bit after an upgrade to the next minor release,
for example SL 6.1 to 6.2, etc.
The idea of group installation itself is coming from the attempt to
migrate the list of packages and package groups from a kickstart file
to the systems like ansible or puppet, b/c as opposed to kickstart
they could control their presence and integrity - at least, it looks
logical for them.
I also agree, that now there is no fast way to check the presence and
completeness of a group So, maybe the group functionality should be
left to the kickstart file, you are right, and we should accept such
compromise.
Thank you for your comments, anyway, they are quiet valuable for
understanding the ansible and its lifestyle