Mechanism to seed a new open-balena instance?

[shaunco]

Is there a proper mechanism for seeding a new open-balena instance with orgs, users, api-keys, fleets, and fleet-wide config/env variables? For our local machine test environment we'd like to always seed open-balena with the exact same details, and for dev/prod environments we'd like to automate as much as possible (rather than having human driven run-book actions).

Things I've tried:

• balena CLI
  • no ability to create orgs
  • no ability to create users
  • no ability to specify a pre-created api-key when creating api-keys
• open-balena-api migration scripts
  • not run on a clean (new) environment
• extending https://github.com/balena-io/open-balena-api/blob/master/src/balena-init.sql and injecting the new one in through a volume mount in docker-compose
  • causes a bit of mayhem with foreign keys and SEQUENCES ... can probably be fixed, but just feels dirty
• extending https://github.com/balena-io/open-balena-api/blob/master/config.ts to add a customServerCode entry (also injected via a volume mount in docker-compose)
  • pinejs isn't clear whether this runs before or after all the route setup functions are called and looking through https://github.com/balena-io/open-balena-api/blob/master/init.ts I'm still not really clear
• Could replace all unit tests with a single postInit test via docker-compose volume mount that does the initialization ... but, again, feels dirty
• could replace https://github.com/balena-io/open-balena-api/blob/master/entry.sh via volume mount to spawn a second process that waits for /ping to return OK and then makes a bunch of curl calls to localhost to set things up?

Really what I'm looking for is something like migrations that is guaranteed to run once on any new API cluster (uninitialized DB)... and none of the above seem like "the right way".

[shaunco]

@thgreasi / @Page- - any thoughts on this?

[Page-]

Other than the options you've covered @shaunco the only things that come to mind are:

• Use the SDK as I believe you can probably do those things using it
• Edit /init.ts taking inspiration from the createSuperuser function
• Add an "async migration" with finalize: false and use asyncFn: (tx: Tx, options: { batchSize: number }, sbvrUtils: SbvrUtils) => Resolvable<number> to run js code as a migration that is still in-progress, you'd also need to handle ensuring it only runs once but as you should be able to do it in a single transaction you'll be able to create a record/check if it's previously been created and rely on transaction mechanisms to roll it back if necessary