There is a new tag of ansible-conjur-host-identity to announce deprecation of standalone project

[BradleyBoutcher]

This project will be migrated to the ansible-conjur-collection, and will subsequently be deprecated.

AC:

• Add a tag to the Ansible role project to note that it has been deprecated and has moved to the new Conjur Collection

[izgeri]

From the conversation that started in #30:

@BradleyBoutcher proposed:

We should take the following steps to deprecate this project:

1. Complete migration of Role to the Collection (see Migrate this Ansible role to the Conjur Ansible collection #30)
2. Tag a release of Collection (ansible-conjur-collection#35)
3. Migrate docs ansible-conjur-host-identity docs are migrated  ansible-conjur-collection#36
4. Verify functionality of role in collection and document migration steps
5. Merge PR Deprecate project #43 in conjur-host-identity
6. Tag a release of the newly-deprecated conjur-host-identity (1.0.0, as this is a "breaking" change) (ansible-conjur-host-identity#42)

7. Add deprecated tag to the conjur-host-identity page in Ansible Galaxy

I asked for PO clarification of the deprecation process, and @alexkalish replied:

Users should be clearly informed of the following:

1. What exactly is being deprecated? Be detailed.
2. How long is the deprecation period? Said another way, when will the feature/component be removed?
3. What is the alternative path to meet the same outcome? What do we advise?

Readme is probably fine, assuming that is primary place where the component is consumed.

[izgeri]

@BradleyBoutcher here is what I would suggest we use as an approach, and completing these tasks would be the acceptance criteria for this card:

In this repository:

• Add a changelog entry that announces deprecating this role for use with Ansible 2.9+ in favor of using the role that's part of the Ansible collection (note: this means we can't tag in this repo until the role is available in a collection release). TBD whether we can also announce deprecating support for EOL versions of Ansible < 2.8.
• Move the Requirements section higher up in the README, and clearly indicate that it works with Ansible >= 2.3.0.0, < 2.9 (TBD whether this should just be Ansible 2.8)
• Add a link to the README in the Requirements section that points to the collection if you're using Ansible 2.9+
• Update any metadata to be clear about the Ansible versions this role supports, and to ensure the link to the collection will be clear in Galaxy if using Ansible 2.9+.
• Once these changes are in, tag the project with a patch release to announce the deprecation, and ensure the Galaxy listing for this role is clear about the compatible Ansible versions for this iteration of the role (e.g. Ansible >= 2.3.0.0, < 2.9 - TBD whether it would just be Ansible 2.8)

Open question:

• Can we also deprecate support for Ansible < 2.8 and update this role to indicate it's only supported for Ansible 2.8, and support will be maintained until Ansible 2.8 is unmaintained / EOL here.

[izgeri]

We decided to maintain support for this project while Ansible 2.8 is still supported; closing this issue for now.