Open jtgasper3 opened 8 years ago
That sort of a policy would be very appealing to me, but I would make strong delineations between security fixes and ordinary patch/feature additions.
I have a couple of orthogonal general package questions that I'll pose here. Please move the below to its own issue if you prefer that. I'm sure I'll come up with more later.
1) Do you try to incorporate new features? Is it hard to do that with the level of customization that deployers can expect? What happens if one site modified web.xml and another didn't? 2) What endpoints are exposed for monitoring?
The images is just a basic deployment of the IdP that saves a deployer from having to install and config Jetty and the IdP. Backchannel is already setup too.
1) Other than that it's up to the configure to deploy whatever options one wants. New versions will have the bits there, but the deployer might need to still enable... like ECP
2) If one wants to use build.sh, then their image just needs to have a RUN build.sh (or run it in the container start script) and they overlay the idp.xml file to point to the idp.war vs the webapps directory...
3) All standard endpoints are available. The deployer must configure any changes related to that just like they would in any other context.
Makes sense and clarifies things, thanks. Since this is aimed at basic integration today, my follow-on questions fall in the category of "feature request" rather than "support considerations".
I would still find the clarification you suggest, especially with regard to update releases versus security patches, very helpful.
Thanks for taking the time.
The Unicon IAM team did a code review and suggested several small adjustments. This is one of those adjustments:
To facilitate adoption of this image, Unicon should state a "policy" of how often checks for updates of the dependency resources (Java, Jetty, IdP) will occur and when those updates will be applied. The policy should include what type of updates will "trigger" an image release.