Add instance and database to Spanner emulator startup

[lkleeven]

We're using the Spanner emulator docker image for integration testing our Spanner database. What we're currently missing is an easy way to provide the Spanner emulator with the instance and database to create. Currently this only seems possible through added scripts and/or code initializing these things after the emulator has started. This makes it very hard to integrate with other tooling like the docker-maven-plugin and our gitlab-ci setup.

We'd very much like this to be available in the emulator on image startup, maybe through environment variables. To prevent us from needing to add extra tools on top for something that feels like basic functionality.

[cassianojaeger-prcl]

I'm facing similar challenges in my project. This would be a very useful functionality.

[gauravpurohit06]

Thanks @lkleeven and @cassianojaeger-prcl for filing the request. We are internally evaluating various options on how to provide this functionality. It would be really helpful if you can let us know your preference out of following options, feel free to add new options.

• Create separate sub commands under gcloud for Emulator.
• Start emulator with default database and instance with default names like testdb or defaultdb.
• Add additional command line arguments in gcloud emulators spanner start command to take db and instance name as input.

[lkleeven]

My feedback:

• I'm not quite sure how the sub command under gcloud would work? How is this different from your third option?
• Having the default names for database and instance doesn't really help us at all. Since every team would probably be using their own names and the default would never fit.
• This sounds ideal. From our, and our teams, perspective, you want to be able to start Spanner up and in the same command be able to define the database and instance name.

Some background: in our setup teams need to use a separate system to create and manage their Spanner instance. Those instances only live in our STG and PRO environment. When running locally users want to mimic this setup locally to. On top of that, we can't create any instances that our gitlab CI pipelines can connect to. So for that environment we need the same abilities. Hope this makes things more clear.

[danxmoran]

My team would also benefit from this. My ideal is similar to option 3, but I would prefer the functionality be exposed at the level of the gcr.io/cloud-spanner-emulator/emulator container - based on implementing similar features at work, I could see it implemented as new CLI flags on the gateway_main binary or as logic in a custom entrypoint script in the container.

Being able to set the default instance & DB names when directly running the container would make it much easier to use the emulator in a docker-compose setup or as a sidecar container in CI.

---

EDIT: Concretely, I'd like to be able to do something like this:

docker run -p 9010:9010 -p 9020:9020 gcr.io/cloud-spanner-emulator/emulator ./gateway_main -instance_name emulator -db_name testdb

Or like this:

docker run -p 9010:9010 -p 9020:9020 -e INSTANCE_NAME=emulator -e DB_NAME=testdb gcr.io/cloud-spanner-emulator/emulator

[alexrjones]

Hi, we'd also benefit from this. IMO, the environment variable approach would be ideal; this is how wrench works, so this would make the two dovetail nicely together.