Implement state: absent for roles, repositories, privileges...

[zeitounator]

This is a follow-up ticket of #288

Currently, state: absent is only implemented for users.

We should add this to all other objects managed by the role

[kpoland-oncore]

This would be a nice addition. The Nexus install includes a number of default repos that I don't want and I'd like to be able to list those as "absent" in my config to delete them automatically.

[brianveltman]

My 2 cents on this:

I think a proper Ansible playbook should always get your system into the "desired state" as defined in the code.
When it comes to users, repositories roles and permissions I think it should be as easy as removing the defined resource/config from the code to remove it from the system as well. This way your Ansible group/inventory vars will hold a single source of truth when it comes to what has been provisioned.

In my opinion state absent should be used to explicitly remove Nexus defaults or ensure certain objects at OS-level are removed and there for perfect to be used during the INSTALL phase of the role.

Perhaps we could make a distinction between running the role with state absent for provisioning or run it as a kind of Desired State Config approach.

[zeitounator]

This would be a nice addition. The Nexus install includes a number of default repos that I don't want and I'd like to be able to list those as "absent" in my config to delete them automatically.

There's already a setting for this: nexus_delete_default_repos. You can also remove the default blobstore with nexus_delete_default_blobstore

[zeitounator]

@brianveltman I don't thing deleting anything in nexus just because your removed it (or did not include it) in the configuration is a good idea. I very often created repos on the fly from the guy and did changes in the role and run it before I actually pushed that new under test repo in the config. It would have delted the repos which was not expected. Taking this into account, I think that state absent would be a good implementation.

Regarding your last remark and taking into account my years of experience with this role, I think installing and provisioning should definitely be different operations and should not be carried out in the same role.

[brianveltman]

@zeitounator I agree with your last point. Installing and provisioning are two separate things. Not sure if having two separate roles for this is the best option. When I take a look at certain parts of the code, mainly the create repositories function, there are quite some implementations that would unset or remove certain repo configurations if not set using a variable. I think thats a nice implementation that's in line with single source of truth principles.

Besides the technical discussion; the environment I work in does usually not allow manual changes to business critical applications to keep traceability into place that's in line with compliance policies.

Using state absent in this situation will clutter the code with garbage and repo definitions that do no longer exist.