Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployments don't lock the obs-api package #68

Open
eduardoj opened this issue Dec 1, 2022 · 4 comments
Open

Deployments don't lock the obs-api package #68

eduardoj opened this issue Dec 1, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@eduardoj
Copy link
Member

eduardoj commented Dec 1, 2022

As we can see from the deployment log, the zypper lock is removed

TASK [unlock obs-api] ************************************************************************************************************************************************************************
changed: [obs] 

But it's not restored back afterwards...

@eduardoj
Copy link
Member Author

eduardoj commented Dec 1, 2022

The lock is restored afterwards, at least in successful deployments. 🤔

Regarding the description of the issue:

As we can see from the deployment log, the zypper lock is removed

TASK [unlock obs-api] ************************************************************************************************************************************************************************
changed: [obs] 

But it's not restored back afterwards...

In this specific case the zypper lock was not restored because the condition was not met. It was skipped. We can see it in the logs, in the last TASK [include_tasks]:

TASK [include_role : unset_apache_maintenance_mode] ******************************************************************************************************************************************
skipping: [obs]

TASK [include_tasks] *************************************************************************************************************************************************************************
skipping: [obs]

TASK [include_tasks] *************************************************************************************************************************************************************************
skipping: [obs]

PLAY RECAP ***********************************************************************************************************************************************************************************
obs                        : ok=7    changed=3    unreachable=0    failed=0    skipped=8    rescued=0    ignored=0

@danidoni danidoni added the bug Something isn't working label Dec 1, 2022
@hennevogel
Copy link
Member

Sounds like it's related to #67 ?

@eduardoj
Copy link
Member Author

eduardoj commented Dec 1, 2022

Sounds like it's related to #67 ?

Hm... #67 is simply not implemented. There is only one task which records to GitHub. And it always records a successful result. When the deployment fails, the task is simply not run. See:

- name: update github deployment
shell: "bin/dotenv bin/ogd succeed --ref={{obs_running_version.stdout}}"
delegate_to: localhost
when: obs_running_version is succeeded

I guess that the right approach to make sure that the deployments always lock the obs-api package is to always perform this task, even if the deployment has failed. In other words, to remove the conditions which prevent the lock from being performed.

@danidoni
Copy link
Contributor

I guess that the right approach to make sure that the deployments always lock the obs-api package is to always perform this task, even if the deployment has failed. In other words, to remove the conditions which prevent the lock from being performed.

After re-reading the ansible-obs playbook and thinking about it, I believe @eduardoj is right. Locking zypper should happen always.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants