Improve documentation for migration tool #536
Conversation
julianbrost
force-pushed
the
feature/migrate-history-docs
branch
from
f3f98d7 to
e938669
Compare
1. Moves the example config to a separate file one can just download. 2. Establishes some kind of standard workflow for the migration.
julianbrost
force-pushed
the
feature/migrate-history-docs
branch
from
e938669 to
ed9ae66
Compare
| sections of the configuration. | ||
|
|
||
| Both the IDO and Icinga DB support MySQL and PostgreSQL. You can migrate from | ||
| and to both types, including from one type to the other. |
There was a problem hiding this comment.
I still like the idea to get this fact underlined...
|
|
||
| # IDO database | ||
| ido: | ||
| type: mysql # or "pgsql" for PostgreSQL |
There was a problem hiding this comment.
... by switching the DB types here. :)
(After all this one's migrating from IPv4 to IPv6 as well.)
There was a problem hiding this comment.
As we support both databases, I don't think we should incentivize a switch here. So if a user has the desire to switch, they will probably look for it, others may be confused why the example migrates from MySQL to PostgreSQL.
There was a problem hiding this comment.
Oh, I think we should incentivize a switch – from PostgreSQL to MySQL.
There was a problem hiding this comment.
No. It would make no sense for Icinga DB to support PostgreSQL if we would recommend to migrate away from it.
TODO
Figure out if we want to keep the endpoint setting or just use NULL (context), then either write documentation for it or remove it altogether.endpointoption in other PR (cmd/icingadb-migrate: avoid unnecessary config option #541)