We would like to have a dedicated restart endpoint available to authorized release administrators that can be used for to restart the application via REST API. Use Case for example necessary application restarts in case of Plugin updates?
by: Daniel R. | over a year ago | API & CLI tools
Comments
Daniel, thank you for the idea!
We find installing and updating plugins a very important area for us, and we are working on improving it in such a way that restarts are no longer necessary. If restart wasn’t the main issue with installing/updating plugins, would you still need this feature? If yes, in which cases?
Please remember, that idea can be voted on clicking on "Vote for" button/label.
Thanks for sharing this information, Migle.
Currently, there are additional purposes for a restart endpoint.
In our use case, we do not have direct access to the Application Server to perform a restart. Only Operators have access to the instance due to strict security guidelines. If there are time-critical Release running and the application freezes due to the heavy load on the back pressure mechanism, we require restarts immediately. In those situations, we cannot rely on the SLA response and resolve times agreed with our operators.
We would need this feature to be available only to Release Administrators.
Additionally, this would be very helpful for release cluster setups when multiple services instances have to be restarted.
While we are planning to support restart mechanism for Kubernetes environment, you could try to see if you can achieve desired functionality by starting Release as a service (using service wrapper). If you need to restart it, you could invoke "/server/shutdown" endpoint (an internal endpoint accessible by Release administrators) that will shutdown Java application. We expect that the service should detect that application crashed and should bring it up.
We are in much the same position.
I would like to be able to upload new packages via the Rest API, and trigger a gradual rolling restart across the cluster.
This would enable us to perform CI/CD with our XLR extensions deployment, and it would free us from having to make requests of our internal tooling team to schedule a cluster reboot.
In the 23.3 release expected later this month we will have support for installing and upgrading container based plugins without a restart of Release. For more on container-based integrations see: https://community.digital.ai/release-deploy/post/recordings-now-available-for-the-integration-sdk-workshop-EyMSWWtUvEJcPAV
This idea would solve a lot of headaches I also face.
I work for an organisation wedded to the notion of change/run teams, with very rigid segmentations of responsibilities. In order to publish a new extension (we build our own in-house) involves an enormous amount of energy to be exerted to request the 'run' team perform a rolling K8s restart of the pods that maintain our XLR cluster.
Being able to upload a new extension, by an API, and then request that XLR perform it's own staged shutdown, would save me and my organisation so much energy and effort. Our application could perform it's own rolling restart to enable the new extension code seamlessly.
Regards,
Matt