Here is an example of reviewing a change to a database service package - in this case mysql - and this change https://github.com/habitat-sh/core-plans/pull/1321#pullrequestreview-109474501
For any database service update (especially ones that change behavior), you need to test both a single node and a cluster running that service.
Conveniently, the person who opened this PR included a Docker compose file to test the change in a cluster - most excellent!
I pulled down their branch onto my local machine, then built the mysql plan from this branch, then created a docker image from the resulting hart package.
I then copied the docker compose file (which was defined in the README) to my local machine to a file called “docker-compose.yml”, then ran
$ docker-compose up
This brought up the cluster successfully and I verified that a leader was elected as expected and it looked great!
However, before I merged and released it, I wanted to ensure that a single node running this plan would still work as expected. I did this by spinning up a single container running the docker image:
$ docker run -it -p 8000:8000 core/mysql
Unfortunately, this time it generated an error:
mysql.default hook[init]:(HK):
mysql.default(HK): Initialization failed! 'init' exited with status code 1
mysql.default(SR): Initializing
mysql.default hook[init]:(HK): 2018-04-04T19:46:44.906386Z 0 [ERROR] mysqld: Empty value for 'server_id' specified
mysql.default hook[init]:(HK): 2018-04-04T19:46:44.906573Z 0 [ERROR] Aborting
mysql.default hook[init]:(HK):
mysql.default(HK): Initialization failed! 'init' exited with status code 1
I then pulled down the latest stable core/mysql plan, exported it as a docker image, and tried spinning up just one node from that image. I confirmed that error did not appear with the stable version of core/mysql, which meant the error was new with that change.
I then requested changes on the pull request and detailed the error message that I was seeing.
Once the typo is corrected we’re going to want to test the package again. In testing a database, oftentimes just turning the cluster up and validating a habitat leader isn’t enough to guarantee functionality. As such, once we follow the previous steps for leader/follower and the cluster is live, we’re going to want to inject data into the database and validate that said data is replicated across to the follower nodes!