Add section describing how OIE is expected to be compatible with Mirt… #3
Conversation
jonbartels
force-pushed
the
update-readme-with-compatibility-info
branch
from
33d785d to
7dd968f
Compare
jonbartels
requested review from
a team,
gibson9583,
kayyagari,
kpalang,
pacmano1,
ssrowe and
tonygermano
and removed request for
a team
jonbartels
force-pushed
the
update-readme-with-compatibility-info
branch
from
7dd968f to
5248dc2
Compare
tonygermano
left a comment
tonygermano
left a comment
There was a problem hiding this comment.
This section reads more like a general server migration guide than docker fork compatibility. It's asking people to do a lot to switch to our docker container if they are already using the NG one.
I expect most people to be setting mirth.properties values via environment variables. As best as I can tell that hasn't changed and should be compatible. If they are pointing this container to an existing database, then none of the export/imports should be relevant. As always, the software must be pointed to a database at the same version level or lower in order for database migration to work, which automatically excludes Mirth 4.6+ and BridgeLink at this time (as they started at version 4.5.3 and we are still at 4.5.2.)
Relevant to current users of the NextGen containers version 4.5.2 and earlier is how they can use existing docker volumes with the new container, or if that is not supported at this time (I think it should be possible to do and would make upgrades much smoother.)
Signed-off-by: Jon Bartels <[email protected]>
jonbartels
force-pushed
the
update-readme-with-compatibility-info
branch
from
5248dc2 to
85d2b89
Compare
| 1. Update your Mirth Connect installation to Mirth Connect 4.5.2 | ||
| 2. Backup your Mirth Connect database | ||
| 3. Stop your Mirth Connect server | ||
| 4. Update Open Integration Engine to use the same `vmoptions` and `mirth.properties` files as your Mirth Connect installation. Containerized instances will use environment variables to set these options. Other installations use the config files. |
There was a problem hiding this comment.
Containerized instances will use environment variables to set these options.
Is that generally true? It's the tiniest nit in the world, but the docker hub connect hub page/readme has the following:
You can use environment variables to configure the mirth.properties file or to add custom JVM options.
e.g. shall/should/must.
That is the ideal way, but couldn't a containerized version also read from a mirth.properties file?
…h and other forks