-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execute Startup Hook always after Pipeline Deployment #748
Comments
The question is how to reliably detect if the last execution of the ACTool was based on a different Cloud Manager build or the same. Potential candidates are:
|
Probably just checking if the previous log was a triggered via |
Regarding the reasons to run the tool automatically on mutable content after each deployment:
this can happen, the question is if the deployment event is the best time to react on such changes (conceivable is also to create listeners for children-changes of all content-derived loops and then automatically run the AC tool without deployment). But then again, usually the most straight forward is not to have content-derived loops but rather define the root folders as master in the AC tool with
I would assume that if manual interaction is allowed (it normally should not be allowed), then it's also ok to "reset to AC Tool config" by running the AC Tool manually
yes that could be an option if we want to change the behaviour - downside is that usually there is no change to be applied if the config files don't change (so the AC tool will run often in vain, especially for established platforms where the yaml files and root folders rarely change) |
It happens like this with AEM 6.5, therefore I would first like to align both versions before coming up with a more sophisticated option (listeners always mean quite some overhead)
It is not so much about the additional manual step but about the principle of least surprise which is IMHO violated here. |
Currently there is a simple logic in the Startup Hook which prevents it from being executed with each start of the Kubernetes pod
(https://github.com/Netcentric/accesscontroltool/blob/develop/docs/ApplyConfig.md#startup-hook)
Unfortunately that does also prevent reinstalling/cleaning up the relevant ACLs/authorizables from the YAML config after each Cloud Manager deployment
The installation incorrectly does not occur in case the YAML configuration was not touched but
biz.netcentric.cq.tools.actool.ims.IMSUserManagement
orbiz.netcentric.cq.tools.actool.impl.AcInstallationServiceImpl
)Instead of leveraging a hash over the config files to check if reinstallation is necessary one should rely on something else.
The text was updated successfully, but these errors were encountered: