Mattermost-server: [Help Wanted] [MM-13895] Implement config migration command

[esethna]

If you're interested please comment here and come join our "Contributors" community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. For technical advice or questions, please join our "Developers" community channel.

New contributors please see our Developer's Guide.

---

Notes: Jira ticket

Implement a new command for migrating configuration to/from the database.

Example invocations:

mattermost config migrate --config=path/to/config.json --to=”mysql://mmuser:mostest@tcp(dockerhost:3306)/mattermost_test?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s”
mattermost config migrate --config=”mysql://mmuser:mostest@tcp(dockerhost:3306)/mattermost_test?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s” --to=path/to/config.json
mattermost config migrate --config=”mysql://mmuser:mostest@tcp(dockerhost:3306)/mattermost_test?charset=utf8mb4,utf8\u0026readTimeout=30s\u0026writeTimeout=30s” --to=”postgres://mmuser:mostest@dockerhost:5432/mattermost_test?sslmode=disable&connect_timeout=10”
mattermost config migrate --config=path/to/config.json --to=a/different/path/to/configuration.json

This command should instantiate a config store for each DSN using config.NewStore and then effectively invoke toConfig.Set(fromConfig.Get()) (and toConfig.Save()). It might be confusing have --config and --to flags instead of --from and --to (or --config and --from). Proposals welcome!

Unit test coverage should verify the effects of the migrate command using another store.

[joshuabezaleel]

I am interested in this issue but I still have not understood several parts:

1. Does migrating means that I have to delete/remove the previous store? Because from what I get, invoking toConfig.Set(fromConfig.Get()) (and toConfig.Save()) only means that copying the config from oldstore to newstore while the config at the oldstore still persists?
2. I still do not understand the unit test part. What do you mean that the unit test coverage should verify the effects of the migrate command using another store? How should we verify this?

Also, what do you think if we use the flags --config_source and --config_destination? Or perhaps only source anddestination`.

Thank you very much! Have a good day 🙂

@esethna

[jwilander]

@lieut-data

[joshuabezaleel]

May I have a shot on this? 🙂

[hanzei]

Sure, go ahead @joshuabezaleel :+1:

[lieut-data]

@joshuabezaleel,

1. No need to modify or remove the old store. Only the new store should be intact.
2. Ideally the unit tests prove that the new command actually works. It would probably be fine for the testing code to create new store instances after running the command to verify the changes.

My concern with the flags is that --config is a global for the config subcommand, so it's going to be accepted regardless of what new flags we accept. What if we accept --from as defining the source configuration, and then alias a --to to the existing --config so that we accept either?

[hanzei]

Hey @joshuabezaleel,

How is your work on this ticket going? Can we help with something?

[hanzei]

Making this one available for the public again due to inactivity. Let me know if you still want to work on this @joshuabezaleel!

[d28park]

Interested in taking a look at this.

@joshuabezaleel - Would that be alright? Did you make some progress on it already?

[hanzei]

Thanks for taking care of this @d28park!

[joshuabezaleel]

Hi @hanzei I am really sorry for my inactivity. There are a couple of things currently going on.
Hope that I can still take issues and won't be a burden in the future.

@d28park Sure! Thank you very much for taking this up! The issue's description should be really helpful.

[hanzei]

Fixed with https://github.com/mattermost/mattermost-server/pull/10508