search

FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
91 stars 12 forks source link

Kickstart-style migrations #560

Open atrauzzi opened 4 years ago

atrauzzi commented 4 years ago

Kickstart-style Migrations

Problem

Kickstarting is so helpful for the first-run setup, but I think what would be better is if we had a way to also provide configuration changes over time.

Solution

Similar to how there are migration libraries for databases, the kickstart process should support running and tracking the "ran-state" of timestamped kickstart scripts, in order.

Alternatives/workarounds

Right now I think the only way to make changes after a kickstart has happened is to do so manually through the UI, via direct SQL or via the API.

Additional context

Given that kickstart already exists, this seems like a sensible addition. Configuration upgrades would be possible by restarting the container with the additional files bound in.

Related

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

robotdan commented 4 years ago

Is this a dup of https://github.com/FusionAuth/fusionauth-issues/issues/526? or perhaps similar?

atrauzzi commented 4 years ago

Not quite. The idea here would be support for "versioned" (timestamp is even sufficient) kickstart files to be run against the FustionAuth server after its initial deploy and to have those kickstart files originate from the orchestration layer.

So, think a directory full of kickstart files that have timestamps in their filenames. Then FusionAuth ensures that all are run in order, once and only ever once.

robotdan commented 4 years ago

Got it, ok thanks for the clarification. Sort of like a record option to track all API requests and add then export the log as a kickstart file.

atrauzzi commented 4 years ago

Hmm, no not quite, this idea has nothing to do with exporting anything. It has to do with what FusionAuth does on run. Consider it a fundamental improvement to how kickstarts work, less about getting all the information in at once, but about getting changes tracked over time.

What I'm saying is I want FusionAuth to look in a directory for *.json files when it starts up:

/kickstart-dir/
    0001-init.json    <-- Added March 24th
    0002-switch-password-salts.json  <-- Added April 3rd
    0003-add-mobile-application.json  <-- Added April 3rd
    0004-add-automations-group.json  <-- Added April 14th

(dates are made up, but imagine each time a file is added, the service is restarted or a command is executed in the container to apply the json script)

FusionAuth would see those files and run them, in order, internally tracking the state of which ones it's run. Subsequent starts of FusionAuth would only run new ones as they are added. Conceptually this is almost exactly like how database migrations work, except that instead of tracking and running SQL, it's tracking and "running" these JSON files as kickstarts. One after another to apply changes to state via the kickstart convention.

mooreds commented 4 years ago

I think that an alternative solution might be to create a Terraform provider for FusionAuth. I added an issue: https://github.com/FusionAuth/fusionauth-issues/issues/576

atrauzzi commented 4 years ago

That'd be super slick!

kevcube commented 2 years ago

I still don't feel the terraform provider is an adequate solution to this problem, is this something that will be worked on?

mooreds commented 2 years ago

Not in current plan, @kevcube .

I left a more complete comment over at the other issue: https://github.com/FusionAuth/fusionauth-issues/issues/1379#issuecomment-1171171567 (for anyone visiting this in the future).