Refactor hard-coded zuul user in reproducer role
#3350
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
michburk
force-pushed
the
main
branch
2 times, most recently
from
02a1b24 to
55ebc64
Compare
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/a7738eda2d9e4d6b9ecbdac4b6cf2717 ✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 31m 14s |
michburk
force-pushed
the
main
branch
6 times, most recently
from
663c195 to
9466520
Compare
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/34c153c78ef7406991c39d16c100ea72 ✔️ cifmw-pod-zuul-files SUCCESS in 4m 45s |
michburk
force-pushed
the
main
branch
2 times, most recently
from
2f16f45 to
4822a60
Compare
michburk
changed the title
michburk
changed the title
zuul user in reproducer role
michburk
changed the title
zuul user in reproducer rolezuul user in reproducer role
|
I will pick that change in next iteration in tesstproject. |
|
testproject in the task: OSPRH-19950 |
|
temporarily adding dnm label, running test project against this slightly modified test pr to make sure the ['ansible_env']['USER'/'HOME'] approach works as expected |
|
Reverted back to using if I understand correctly, controller-0's ansible env is not available by the time we first try to use |
It was already technically possible to create a controller-0 vm with a
non-zuul user. This commit enables configuring controller-0 with a
non-zuul user by using controller-0's `ansible_ssh_user` from
`hostvars` in place of hardcoded `'zuul'`.
It is worth noting that we can't simply use vars like ansible_user_id
or ansible_user_dir with tasks that are delgated to controller-0.
If the host we are running the reproducer from has a different user
from controller-0, these vars will try to use the user from
the machine that is running the reproducer rather than controller-0's
user.
For example, let's say we are running the reproducer from a machine with
the user 'exampleuser' and we have the user 'zuul' on controller-0.
If we have some task that is delegated to controller-0 and
tries to create some file in the controller-0 user's home directory, we
can't simply do:
```
- name: Create some file
delegate_to: controller-0
ansible.builtin.file:
path: "{{ ansible_user_dir }}/some_file.txt"
state: touch
```
`ansible_user_dir` resolves to `/home/exampleuser`. This path does not
exist on controller-0, so this task would fail.
Previously, the check for `common-requirements.txt` would check if common requirements exists on localhost at a given path. This path is based on the home directory on localhost. If the file did exist, it would use that same path to try to install the requirements on controller-0. This causes issues when localhost and controller-0 do not have the same users and home directories.
|
uni alpha passed with #3433 (the same as this patch but without |
|
@fultonj wanna test this change on local setup? EDIT: doing it now EDIT |
4 participants
The reproducer role used a hardcoded
zuuluser and hardcoded/home/zuulpath in several places, particularly when configuring controller-0. This patch pulls out this hardcoded data into default vars in the reproducer.This patch also fixes a few incorrect assumptions that a var like
ansible_user_idcan be used when delegating to or configuring controller-0. For example, theansible_user_idwill not resolve to controller-0's user, and instead resolve to the host that the task is being delegated from. If there is a mismatch between these two users, this causes problems. This has mostly not been an issue because our ci assumes that there is azuuluser everywhere, but people running local deployments have encountered issues when using the framework on a hypervisor with a non-zuuluser.