multi OS repo-build needs to be more intuitive

[Kevin Carter]

When building an environment running >1 OS the repo-build needs to have special flags passed in at run time to ensure the python wheels are built from the appropriate sources on the different Operating Systems.

conversation from today:
‎[16:19] ‎<‎tasker‎>‎ OSA collects two groups for the repo_master, 14.04 and 16.04. it appears to build 14.04 on repo-1 no problem.
‎[16:19] ‎<‎tasker‎>‎ when it goes to run repo_build for repo-2 (16.04) it comes back with 'dict object' has no attribute 'repo_build' for the task "Ensure that temporary folders from previous build failures are absent"
[16:27] ‎<‎odyssey4me‎>‎ you may need to force a rebuild of wheels/venvs
‎[16:28] ‎<‎odyssey4me‎>‎ use -e 'repo_build_git_reclone=yes,repo_build_wheel_rebuild=yes, repo_build_venv_rebuild=yes'

This means in order to build wheels and venvs on different OS's we need to run

```
openstack-ansible repo-build.yml -e repo_build_git_reclone=yes \
                                 -e repo_build_wheel_rebuild=yes \
                                 -e repo_build_venv_rebuild=yes
```

The initial playbook should be able to detect the different OS's and set the correct vars according based on the state of the repo_server cluster instead of having the user know to pass in these flags.

While work to refactor some of the repo-server/build role may be underway it might we worth our time to add these overrides, and a blurb covering multi-os support, to our tips and tricks so folks are not left out in the cold when running a multi-os cloud.

[Jesse Pretorius (jesse-pretorius)]

I have seen multiple reports of there being issues, but inspecting the way it all works right now I don't understand why it's happening. As it stands right now each wheel/venv build process is completely independent per-distro per-arch. This means that if a new arch/distro is added, the requirements and other files checked when doing a build to determine if something has changed should pick up the change (as there are no previous files). I'll have to make some time to build a multi-distro environment to see the problem first-hand.

[Jean-Philippe Evrard (jean-philippe-evrard)]

Waiting for confirmation from manual triaging/other bug reporter.

[Eric M Gonzalez (egrh3)]

Sorry -- I have been unable to reproduce this error. With the help given from odyssey4me and cloudnull I was able to move past the problem. Now, with how far I've come in my installation procedure, I have not seen this again and am unable to go backwards.

This is a test cluster and I plan on starting over to finalize my procedure for when I upgrade production. I will keep my eyes open and logs hot in case this comes up again.

I do have a log snippet from a previous attempt here:

TASK [repo_build : Ensure that temporary folders from previous build failures are absent] ***
task path: /etc/ansible/roles/repo_build/tasks/repo_build_wheels.yml:16
fatal: [caiah-controller-2_repo_container-ead3a250]: FAILED! => {"failed": true, "msg": "The conditional check 'ansible_local['openstack_ansible']['repo_build']['need_wheel_build'] | bool' failed. The error was: error while evaluating conditional (ansible_local['openstack_ansible']['repo_build']['need_wheel_build'] | bool): 'dict object' has no attribute 'repo_build'\n\nThe error appears to have been in '/etc/ansible/roles/repo_build/tasks/main.yml': line 42, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- include: repo_build_wheels.yml\n ^ here\n"}

I hope that this helps.

[Jean-Philippe Evrard (jean-philippe-evrard)]

We'll leave the bug open, as currently no one has been able to reproduce it.

[Jesse Pretorius (jesse-pretorius)]

This *might* be a related fix here: https://review.openstack.org/#/q/I63817bb3c58a2c44d3e948bdb81005dc2e734c21

[Jonathan Rosser (jrosser)]

This is addressed by https://review.openstack.org/#/c/636192/ and the whole process is being overhauled in the Stein release. Marking as fixed

[Kevin Carter (kevin-carter)]

This should be resolved in Stien and is covered with the following review https://review.openstack.org/#/c/636192/