We received an email alerting us that all machines need to migrated out of XSEDE until 31st December. Like, this year So I will need all hands on deck to turn this ship! I didn’t realise we wouldn’t be able to keep a couple resources there for longer.
Due to that, I took a lot of liberties and created a bunch of machines in jetstream.
All new machines have a mysql running in docker. As we do plan to move mysql to a cluster, I’d ask all applications to have a configuration with the URL and credentials for the database, so we can migrate to the cluster later with minimal effort. Also, data should go to either docker volumes or /data.
@rkapali and @sparshadotel, I know I’ve asked you to start with the mysql cluster, but now that changed priority drastically. I’d kindly ask you to commit any code you’ve created to a branch, or any comments you have in our wiki, and please help me move JIRA to jetstream first. I granted you access to jira.openmrs.org (NOTE this is prod, and it’s shared with other services!!) and there’s now jira-new.openmrs.org for you. I need this JIRA version to be updated as well.
I’d prefer to not dockerize it.
@r0bby, I created ambam.openmrs.org (with two extra dns entries, crowd-new and id-new). Would you think you’d be able to deploy in an automated fashion (upgraded) crowd, mongodb, openldap and dashboard to the new machine in the next month or so? I’m quite alright to use ID 2.1, even if that means SSO with Helpdesk is lost.
@harshavenu99, I know you wanted to start with backups, but do you think you’d be able to tackle Confluence? If so, I’m going to deploy your key to current wiki (wiki.openmrs.org) and new machine (wiki-new.openmrs.org).
I will be working on Bamboo agents, http redirects (moving them to our dns provider or something), static assets (move to S3/cloudfront).
We’ll need to migrate as well:
Bamboo server (need another port open on firewall/security group for agents to connect)
sonarqube (I believe it will share the VM with Bamboo)
atlas.openmrs.org: requires changing the docker image, probably going to thika vm
yourls (om.rs): needs to be dockerised, probably going to thika vm
I’m a little bit worried as well with test environments.
int-platform
qa-platform
devtest03
devtest04
devtest00/mdsbuilder
@raff and @darius, do you think you guys could find someone willing to dockerise (some of) them? If there’s a docker-compose, it’s easy to deploy. I was told mdsbuilder needs backups, but I’m not sure how it works.
Copy that. We’ll move into working on the JIRA migration. We’ll use the latest version on the new one as well. We’ll make sure that it’s done within next week. Since we are doing this first, are we going to use a mysql instance in the same server or are we to create a new separate mysql for JIRA. Are there any specific versions we need to consider for JIRA, mysql and other dependencies for JIRA?
P.S: Sparsha is suffering from viral fever for the past couple of weeks and is recovering. He’ll be back with us next week.
I don’t mind the data migration or the upgrade being manual, they are one-off tasks. But after the migration, I do expect I’d be able to recreate JIRA VM without manual intervention.
JIRA appears to be down now so I cannot tell what’s the version we have now :D. But I’d like you to upgrade to whatever is the latest version. We need a plan on how to migrate (the data, how long will be the outage, how much time the upgrade will take, the steps and so on).
I’m running mysql 5.6, let me know if it’s not compatible.
I can’t think of any other dependency. Maybe crowd? Let us know what’s the version it needs.
@cintiadr so under 2.1 – everything is dockerized – so just deploy the docker-compose file. We’d need to take a mongodump of the old server and copy the LDAP data directory – which is the volume that the container uses…there’d be a period where there’d be no identity system…since it’s a pain in the butt keeping data consistency due to DNS propagation times…It might be wise to lower the TTL for both old and new records to 5 minutes.
@cintiadr : Sure. I can start working on the confluence migration from the old server to the new one. If you can add my key’s to the boxes that would be great. I can look around on how it’s setup and start working on the same.
Let me know if you disagree with anything. Let me also know if the mysql config is not what you need. Please use any docker image or ansible role you prefer.
Do we still have plans on deploying 2.1?
Regardless, if you test the data migration and crowd upgrade and you are happy with the result, we can schedule it. We just have to make sure crowd is compatible with your current JIRA and Confluence versions.
It would be better to schedule the migration on a weekend. Just write down the checklist/plan first
Done. I will need to give you access to ansible repo too.
Awesome!
I assigned both sonar and mdsbuilder to you.
I assume you’d prefer to make them in docker.
Let me know about when you’d like the hosts ready.
@cintiadr : I’ll start working on the Ansible role for setting up confluence.
I got a general idea from the wiki and will in-corporate the steps in Ansible and test it locally. Will keep you posted.
Confluence: @harshavenu99, do you reckon we’d be still able to deploy it next weekend? If so, when could I see the code? We need to schedule the outage.
JIRA: @sparshadotel and @rkapali, when would you guys be able to follow up the comments I did on the PR?
So I will need all hands on deck to turn this ship! I didn’t realise we wouldn’t be able to keep a couple resources there for longer.
