Automation support for Liferay Upgrade process https://liferay.dev/c/message_boards/find_thread?p_l_id=119785294&threadId=122837265 2026-04-05T12:23:29Z 2026-04-05T12:23:29Z Jamie Sammons https://liferay.dev/c/message_boards/find_message?p_l_id=119785294&messageId=122838122 2024-08-13T16:13:55Z 2024-08-13T16:13:54Z

<p>Feature Request Created: https://liferay.atlassian.net/browse/LPD-33853</p>

Jamie Sammons 2024-08-13T16:13:54Z Tobias Barth https://liferay.dev/c/message_boards/find_message?p_l_id=119785294&messageId=122837264 2024-08-13T10:14:34Z 2024-08-13T10:14:32Z

<p>Our customer is running Liferay DXP 2023.q4 in Openshift 4. They use 2 Liferay containers as a cluster. Currently, when a Liferay update (which always includes a database update) is performed, they have to do multiple manual steps, including starting up just one of both containers with the new Liferay version, and watching its log output closely in order to see when the database upgrade is completed and whether it was successful or not.</p> <p>An additional hurdle is that there is always an error logged for the Database Upgrade process, because they have the enterprise feature disabled, and some OSGI modules do not start because of this.</p> <p>I request hereby:</p> <p>- Please offer a way to clearly figure out the status of the database upgrade process. Would it be able to expose the status via a web service?</p> <p>- Please think of additional ways of easing the update of a Liferay Cluster within Openshift. Maybe an Liferay Openshift Operator could be implemented for automating the whole Liferay install/update process? Or would it be possible to configure the Liferay containers so that, in case the database must be updated, one of the containers does the update, and the other container(s) disconnects from the database and shuts down? As an alternative, could there be special container images, which are only made for updating the database?</p>

Tobias Barth 2024-08-13T10:14:32Z