-
Notifications
You must be signed in to change notification settings - Fork 14
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
Update Nginx Configuration to use Microservice after updating OMERO-Web #438
base: master
Are you sure you want to change the base?
Update Nginx Configuration to use Microservice after updating OMERO-Web #438
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into these issues, there are at least three separate issues here:
- the
ome.iptables_raw
service startup error I can reproduce in https://github.com/sbesson/deployment/actions/runs/11435648689/job/31811454141. I have left a few comments on Change package name ome/ansible-role-iptables-raw#13 (review) about the underlying change. We might need a full testing environment to check the firewall rules are working as expected - the
ome.omero_web/ome.omero_ms_image_region
dependency. As shown in Micro-service deployment & NGINX configuration #436 although the two roles are built separately, there is a strong dependency between the two as the second one patches the NGINX configuration file created by the first one. In practice, they should always be run at the same time with the current architecture design. For future additions, this should probably be rethought to either separate the NGINX configuration from the application roles or allow to specify NGINX extension points. - the
ome.omero_ms_image_region/ome.omero_server
dependency. The default user of the former role is theomero-server
user created by the latter. Although the proposed check introduced in this PR might work, I think we need to find a different solution as this is adding another layer of complex logic to workaround the fact we have a circular dependency.
I think the order in
deployment/ansible/idr-01-install-idr.yml
Lines 9 to 12 in 87c6210
- import_playbook: idr-omero.yml | |
- import_playbook: idr-omero-web.yml | |
- import_playbook: idr-omero-readonly.yml |
1-
idr-omero.yml
i.e. install OMERO.server on the read-write servr2-
idr-omero-readonly.yml
i.e. install OMERO.server on the read-only servers3-
idr-omero-web.yml
i.e. install OMERO.web on all servers and the image-region micro-service on the read-only services
I get past the iptables issue, but now stuck at:
|
From yesterday's meeting on the upcoming changes for Given this work requires additional changes/testing, could the |
This PR fixes the issue #436 .
I have added a check on the
idr-omero-web
playbook for Micros-services user existence, i.e.,omero-server.
If so, it runs theomero_ms_image_region
role to update the Nginx configuration file for MS.The MS deployment cannot be moved to this playbook as the MS user is created after running this playbook.
The molecule test failed without modification due to the failure of starting
iptables
servicehttps://github.com/khaledk2/deployment/actions/runs/11316428331/job/31468697284#step:5:1497
I have checked this issue and found out that it failed due to this error:
/sbin/iptables does not exist
I have checked the
iptables_raw
role and successfully ran the molecule test. I compared the installation packages on the role molecule test and the installation package on the deployment playbook, and they are not identical; more packages are installed on the role which are related toiptables-nft.
I have changed the installation package on the iptables_raw from
iptables-services
toiptables-nft-services
and updated the deployment requirements to point to this modified branch (https://github.com/khaledk2/ansible-role-iptables-raw/tree/refs/heads/upgrade_package_name).Then I ran the molecule tests in the deployment repo and it passed.
I will open PR for the
iptables_raw
role shortly