# get-hash consolidation
###### tags: `Design`

| Repository | Code src | Usage | Where |
| ---------- | -------- | ----- | ----- |
| openstack/tripleo-ci | [roles/build-containers](https://opendev.org/openstack/tripleo-ci/src/branch/master/roles/build-containers/tasks/main.yaml#L28-L69) | Retrieve the hash to build containers | container build jobs (check/periodic) |
| openstack/tripleo-ci | [emit_releases_file.py](https://opendev.org/openstack/tripleo-ci/src/branch/master/scripts/emit_releases_file/emit_releases_file.py#L84-L140) | :question: | :question: |
| openstack/tripleo-quickstart | [roles/repo-setup](https://opendev.org/openstack/tripleo-quickstart/src/branch/master/roles/repo-setup/tasks/main.yml) | retrieve hash to set repo up | :question: |
| rdo-infra/ci-config | [roles/get-hash](https://github.com/rdo-infra/ci-config/blob/master/ci-scripts/infra-setup/roles/get_hash/tasks/get_hash.yaml) | get hash for component/integration pipelines | centos8 & component jobs |
| rdo-infra/review.rdoproject.org-config | [get-hash.sh](https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/playbooks/tripleo-ci-periodic-base/pre.yaml#L22) | old/deprecated get-hash script | (must be) replaced by get-hash role in ci-config |
| rdo-infra/ci-config | promoter code | promoter bits that get dlrn hash? | promoter code |

## PROBLEMS

### Duplicated code
There are many different get-hash code functions spread across tripleo projects/repos w/ their respective unique ways of getting the hash from dlrn api. All these bits must be consolidated in one single code.

### Bash code
Some bits in bash are hard to test, or even untestable.

### Deprecated / old code
Some of these methods are no longer used and should be removed from the code base.

## SOLUTION
Once you get dlrnapi_client installed in the virtualenv, you can use dlrn_api ansible module like in the [example here]( https://github.com/softwarefactory-project/dlrnapi_client/blob/master/dlrnapi_client/ansible/example_playbook.yaml). You may also import the python module dlrnapi_client, which comes from the same pip packages installed.

Tested example:

- name: check reported results
  hosts: localhost
  vars:
    dlrnapi_user: <obfuscated>
    dlrnapi_pass: <obfuscated>
    dlrn_server_url: https://trunk.rdoproject.org/api-centos8-master-uc
    get_hash:
      commit_hash: 364d07fa857eb87caa6717f4d063dc84e5e2842a
      distro_hash: f6f9a73b2565b441813c54aa1e44730f9bde9c2e
  tasks:

    - pip:
        name: dlrnapi_client

    - command: "{{ ansible_python_interpreter }} -c 'import dlrnapi_client'"

    - dlrn_api:
        action: repo-status
        host: "{{ dlrn_server_url }}"
        user: "{{ dlrnapi_user }}"
        password: "{{ dlrnapi_pass }}"
        job_id: "{{ item }}"
        commit_hash: "{{ get_hash.commit_hash }}"
        distro_hash: "{{ get_hash.distro_hash }}"
        success: true
        notes: 'Tested from ansible'
      register: dlrnout
      with_items:
        - periodic-tripleo-ci-centos-8-standalone
    - debug:
        var: dlrnout

:::info
Note: This works pretty well on py3 :heavy_check_mark:
:::

## Collateral fixes
The bits that interact with dlrn api (like `check_dlrn_reports` task and `promote-hash` role) are written in bash and should be replaced w/ python/ansible modules. These are not directly related to `get-hash` code.

#### check dlrn reports
Even w/ the new role, the [code that interacts w/ dlrnapi](https://raw.githubusercontent.com/rdo-infra/review.rdoproject.org-config/b1fbc15575a6f9ad857cb747a7d5f3b8b7ccad4d/ci-scripts/tripleo-upstream/dlrnapi_check_reports.sh) is a bash script. And it sources files w/ env vars. This is how hash_info files are created and sourced in the get-hash role.

#### promote hash
Another piece of code that is in bash and must be converted to ansible is the [promote-hash role](https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/roles/promote-hash/tasks/promote-primary-distro.yaml#L23
) in config repo.

#### Ensuring rpm content is sane.
This may very well be out of scope, but it's related and worth writing down as a possible edge case.
[1] https://review.rdoproject.org/r/#/c/26294/

[1] fixed an issue where older ( much older) rpms
were getting added to promoted yum repos. This caused
a series of bugs and complaints in the upstream. [2][3]

[2]https://trello.com/c/uO0K0iE1
[3]https://trello.com/c/EpkhyOK9