Generally uninstalls aren't frequent.

The reason for this is you don't know what software someone *manually*
installed that you don't want present.

One method might be to have a list of packages in something like
group_vars/<groupname> called "uninstall_packages"

and then just:

- yum: name={{item}} state=absent
  with_items: uninstall_packages

Which would be a reasonable solution.

We do somewhat similar things in our Tower install playbooks when we no
longer use a particular subcomponent.



On Wed, Sep 10, 2014 at 7:48 PM, Trevor G <[email protected]> wrote:

> It's great that I can easily pull in different roles into my playbooks.
> By default, anything under tasks/main will get run (usually as an
> installation process).  I was wondering if there were any best practices
> for packaging a list of uninstall tasks within the role as well to undo any
> changes that were done in the installation process.
>
> One thought was to have my main task file in my role to have something
> like:
>
> ---
> - include: install.yml
>   when: install == "y"
>
> - include: uninstall.yml
>   when: install != "y"
>
>
> and by default, the install variable would be set to "y".  Then when I
> run the playbook, I'd use --extra-vars to set the "install" variable to "n"
> if I wanted to uninstall software.  The downside is that the conditional
> task include will dump out that the tasks that are being skipped.  This
> ends up cluttering the output and making things confusing, especially when
> there's a lot of installation and uninstall tasks.
>
> Another option would be to create a new role for uninstalling the
> software, but that is cumbersome and then requires someone to pull down two
> different roles and makes tasks that should be closely related much more
> separated and harder to manage.
>
> Is this the best practice for handling this use case?  Is there some sort
> of "include_task" type feature that would allow one to include a bunch of
> tasks without applying the condition to every individual task?
>
> Thanks,
>   Trevor
>
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/3b723b8f-87ff-4b6e-b640-b95c92611a28%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/3b723b8f-87ff-4b6e-b640-b95c92611a28%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgw-h21uAQ1Dfsne1vtKNKqgU5c8xRPO5fLZ87oPEC_yYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to