Prod and Dev – why two versions of OLab4?

There has been a wee bit of confusion recently regarding the fact that we are now running two parallel servers with OLab 4.6 on them. 

Why two servers?

We have a production server, which carries the main case content, and should be used for classes, tests, anything which directly involves learners. This is the stable one, which may not have the most recent fixes and code tweaks. Moodle courses will usually point to this server. 

We also have a dev(elopment) server, which carries a more recent (but possibly less stable) version of the code base. This is also the server which should be used for creating test scenarios, scratch-pads for diagnostics, stuff like that. We can try out new features and bug fixes on here without affecting the production server. 

When things are tested enough on the dev server that we are happy that they are stable, we can migrate those code changes to the production server. This does not migrate content created on the dev server to the prod server. 

Why two databases?

The two servers, prod and dev, do not share a common database. Changes made on one database do not affect the other database. Content remains separate. While this is not always convenient, it is intentional. 

Remember that this also applies to login credentials – if you change your password on one, it is not changed on the other. 

The two main applications in OLab, the player and the designer, do share a common database. See below. 

What gets a little confusing for some dev and testing purposes is that the database engine, MariaDB is the same for prod and dev, and resides on the same computer. So, occasionally, if one database is out of action, the other one may be as well. Not always, just sometimes… just to confuse you. 

Why two applications?

In OLab3, the player and the designer were all hosted within a single application. This simplified some things but was also harder to scale to more complex scenarios and bigger numbers of users. 

In OLab4, the player and the designer are two separate applications, with separate URLs. Typically, the first part of the URL e.g. demo.olab.ca is the same for both but the last word is not i.e. demo.olab.ca/player and demo.olab.ca/designer 

These two applications, player and designer, do share a common database. This is obvious when you stop and think about it, otherwise the designer would not be able to make changes to a case that you can then display in the player. 

Note that this also applies to login credentials, which are stored in that same database. So a change in credentials on the player will also affect the credentials that you use to login to the designer. 

Will things always be this way?

Eventually, when we move out of beta testing into a more generalized platform, some of this fuss and complexity will be resolved. Hosting services on cloud servers will help. 

At present, if you type https://demo.olab.ca, it will not take you anywhere. You have to specify player or designer. Eventually, the player and designer will be combined into a common interface, which will be easier. 

Because of some problems in network performance at our host institution, we have had to use off-site servers. As of May 2023, we are currently hosting our dev server at https://everest.cardinalcreek.ca and our prod server at https://logan.cardinalcreek.ca – again, remember to append /player and /designer onto these URLs.