-
Notifications
You must be signed in to change notification settings - Fork 19
Get the IDR playbooks working smoothly with multiple deployments #124
Conversation
Conflicting PR. Removed from build MANAGEMENT_TOOLS-merge#970. See the console output for more details.
|
Conflicting PR. Removed from build MANAGEMENT_TOOLS-merge#973. See the console output for more details.
|
--exclude This is the combined state of the other PRs. Getting those in first. |
The only thing that's not in idr-omero.yml is screen
This should be handled outside this playbook. In addition running upgrade-distpackages in docker may cause problems if it updates core libraries e.g. systemd.
If you need web access use the idr-web-external security group instead
This supercedes os-create.yml and os-volumes.yml, which can be removed in future
As discussed I've refactored |
I've disabled the default nginx header in c135ef4, this shouldn't be needed any more since ome/openmicroscopy#4744 means the displayed host is generated on the client side not the server, and if it's enabled you always get redirected to idr-demo instead of whatever server you're trying to test.. |
Couple of questions:
|
👍
I'll remove them in a later PR once we know this works at EBI.
The main benefit was for testing the changes to infrastructure, in production it should be a one off copy so the time penalty doesn't matter so much. If you get any timeout or "not ready" errors just re-run |
idr-playbooks/idr-dundee-nfs.yml \ | ||
idr-playbooks/idr-ebi-nfs.yml \ | ||
idr-playbooks/idr.yml \ | ||
idr-playbooks/idr-docker.yml |
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.
This doesn't exist (yet?)
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.
True...that's in my other branch
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.
BASTION_IP=10.0.0.0 | ||
IDR_ENVIRONMENT=idr | ||
ansible-playbook \ | ||
-i inventory/openstack-private.py \ |
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.
For this to work, I have to remove clouds.yaml
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.
This is the public repo so the instructions are designed to work as far as possible without any private config. I assumed any internal instructions would be elsewhere
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.
Understood, but in general, I think we may still need to re-evaluate openstack-private.py (later)
Disabled |
Shooting for having this to be in 0.3.0-rc1 (of IDR) |
No objections in chat. Only non-IDR change is the selinux blocker. Merging. |
Get the IDR playbooks working smoothly with multiple deployments
Replaces
vm_prefix
withidr_environment
in all openstack IDR playbooks, adds this as a group prefix in all IDR playbooks.This means every server in an IDR deployment is in the following three groups
database-hosts
omero-hosts
gateway-hosts
{{idr_environment}}-hosts
{{idr_environment}} -database-hosts
{{idr_environment}} -omero-hosts
{{idr_environment}} -gateway-hosts
In practice this means it is possible to configure variables for
At present (3) should only contain one server (which can be addressed as e.g.
{{idr_environment}} -database-hosts[0]
, if we implement load-balancing there may be more than 1.This also reverts some changes to
ansible.cfg
from #112 in order to get this repo working, these changes should be reverted in adevelopment
orbreaking
branch until everyone's happy.idr_environment
defaults toidr
so that the IDR playbooks can be run without any private configuration. In most cases you should setidr_environment
to something else and add matching group vars files. For example see# IDR multinode omero
in VagrantfileFixes the following from the config issue:
fatal: [demo3-omero]: FAILED! => {"failed": true, "msg": "Failed to get information on remote file (/etc/security/limits.d/95-omero.conf): MODULE FAILURE"}
(idr-omero.yml))[0]
for which host to use is dangerous since it assumes one type per cloud.Includes:
vagrant up
brings up all nodes #120For tidiness this PR should be rebased after merging the above three.