Thoughts on building ansible community package

gistfile1.txt

= How are we going to build this? =
We’re only building a single ACD release at a time.  So each release will target the latest ansible-standard-lib and the latest collections which used to be in Core.


Ansible-standard-lib currently targets new minor releases every three weeks and new major releases every six months.  The proposal is that ACD will release on roughly the same schedule but lag the ansible-standard-lib releases.  So, it would be roughly ansible-standard-lib-2.10.1 is released and acd-2.10.1 would follow in 1 to 3 weeks.  


Major releases possibly pose more serious problems.  If we are not branching and testing against the new release, then there is the potential that when we switch CI over to the new ansible-standard-lib major release, things will break in more major ways.  So, we will likely lag major releases by more than the normal 3 weeks.  We will also not be able to put out new releases for the old stable ansible during this time if we are only working from a single branch and testing against a single release at a time.  (This extra lag is similar to the lag time for EPEL to be brought into alignment with a new major RHEL release).


We’ll need to build from source and make both source and “binaries” (collection packages) available to users in order to satisfy the GPL.  galaxy does not host source so we’ll have to have some way to pull source from elsewhere.  {Perhaps we’ll need to have all repositories that intend to be built as part of ACD use a versioned tag convention so that we can always build from those[h][i]?}

= How are we going to distribute this? =
We will need:


* Ansible Engine rpms which are named ansible-engine or ansible-base and do not contain the ACD.
   * Likely, these should Obsolete ansible < 2.10.  need to coordinate with EPEL, upstream rpm builds, (Debian/Ubuntu?)  etc on what packages they are going to build (see below) (TODO: Look into what can be provided without conflicting with an ansible meta package in EPEL)
* ansible-base tarball on pypi which only contains the contents of the ansible/ansible repo.
* ansible tarball on pypi which is one of the following:
   * [NO] A complete ACD inside of the tarball.  This will duplicate code in the ansible-base tarball.  It would end up overwriting an install of the ansible-stdlib rpm with additional content (assuming the same version was installed)
   * An ansible tarball which contains the collections in the ACD and depends on the ansible-base tarball.
   * An ansible tarball which just depends on other pypi packages that it needs.
      * The other tarballs would be ansible-base and the various ansible-collection-* packages which contain the ACD content.
      * This method seems the most likely to lead downstreams we don’t communicate with to package ACD sanely
* Core needs to implement something akin to tombstoning for things that have moved out of Core so that playbooks with a bare module name continue to work (I believe nitzmahone has this on his radar as a separate feature.)
* EPEL/Debian/Ubuntu/Upstream We need to coordinate with all of these people to see if we can agree on downstream packaging:
   * I suggest everyone builds an ansible-stdlib rpm which mirrors what AAP builds as their ansible-stdlib rpm.
   * In addition, they will want to build one or more packages that mirror the collections which are the contents of the ACD.
   * They should ship a metapackage named "ansible" which depends on ansible-stdlib and all of the additional packages which make up the collection packages.


If all of this goes through, these use cases would then be possible:


* If you only have AAP, not EPEL or upstream:
   * dnf upgrade ansible will work and install ansible-stdlib.
   * <strike>dnf install ansible-stdlib will work and install ansible-stdlib</strike> This may not work.  Have to figure out the Provides that work with EPEL and whether we can get this to work under those circumstances.
* If you have EPEL or upstream
   * dnf install ansible will install the ansible metapackage, the EPEL version of ansible-stdlib, and various ansible-collection-* packages
* Other distros which follow the guidance would have something similar to the EPEL experience
* pip install ansible will install something close to the ansible classic experience (via one of the three methods outlined above)