Boundary Dev mode to reuse db config data

Hi again,

Just trying out a few things on Boundary in Dev mode: I have left my terminal open where Boundary was running on foreground for about a week until I started getting errors:

"error": "rpc error: code = Unavailable desc = last connection error: connection error: desc = \"transport: Error while dialing (nodeenrollment.protocol.Dial) loaded node credentials are nil\"",
"error": "status error grace period has expired, canceling all sessions on worker",

I can imagine that Dev mode wasn’t meant to be used for that long and I accept the fact that I may have to restart things for them to work again.

What I’m trying to find out is whether I can reuse the configuration data that’s stored on Postgres without having to erase the database and start from scratch.

A bit of context here: I’m using a self-managed Postgres instance on my laptop and not the default docker container that Dev mode spins up automatically. I actually prefer to have full control of the database and the service directly from my OS.

The reason I ask is I saw there is an option -disable-database-destruction for the boundary dev command which prevents the removal of the database docker container when the dev server is shut down. If that’s possible I would assume it’s possible to reuse that database the next time you start the dev server, though I get this error when I try:

Error connecting to database: error creating global scope kms keys:
kms.(Kms).CreateKeysTx: duplicate key value violates unique constraint 
"kms_root_key_scope_id_key1": unique constraint violation: 
integrity violation: error #1002

I thought maybe by providing an AES key for recovery operations (-recovery-key) I could bypass that? Has anyone succeeded in doing that before?

Thanks.

If you kept the output at the start of dev mode that included the various AEAD keys you could probably craft a config file for a normal boundary server invocation that would work against that database. I haven’t tried it myself but I can imagine it should work.

Hey @jeff

That’s probably an overkill solution, right? I should just setup a Boundary server (without dev mode) locally and use that for my tests. If I need to start fresh, just drop the database and start over.

Dev is basically a normal server but with an ephemeral DB (normally) and with known IDs to make it easy to play with it. So for testing it can be nice to have those predictable IDs – at least, for the pre-populated resources. But either way works!