Reviewing Core Plans example - database


Here is an example of reviewing a change to a database service package - in this case mysql - and this change

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!


Thanks for sharing your experience and recommendations with this @nellshamrell!