shinesolutions/puppet-aem-curator

Update AEM Curator with newest changes from bstopp

Closed this issue · 4 comments

I saw some changes in the @bstopp repo, which got me thinking:

  • Currently AEM Curator is referencing a fork of the bstopp repo, which imho should not be needed, the change in that fork could be submitted to bstopp and then be merged in, then Curator could reference bstopp again
  • @bstopp fixed the SELinux issues in his module, which is nice, as we currently have those fixes as a customization when using the AEM Curator module. It would be ideal if we have them OOTB and supported.

I think that the feature needed on your fork has been merged. I'm trying to update the last bit to get a release out.


It would be ideal if we have them OOTB and supported.

To what are you referring to here?

Regarding ootb and supported: I meant that it would be nice if we (@Carnifrex and me) can remove our SELinux customizations and have OOTB support from you through your module. :)

@henrykuijpers The fork was needed that time as a quick response to a problem that one of our projects hit in production a while ago, due to process forks not being able to be allocated more than 1Gb memory and causing performance and stability issues.

Granted it was a while ago, so by now details are sketchy as people already forgot the specifics and none of those projects are willing to invest resources to reproduce a problem scenario that's already 'solved'. They tested that the start opt -nofork which was accepted as the 'solution' and it was backed by their performance test, i.e. they managed to reproduce the problem back then without the -nofork, and the problem no longer occurred when it's put in place.

PRs (not only for this issue, but few others) were already created, and I've been pretty much waiting. bstopp already merged most of them, except the one with -nofork which he believed to not be possible considering -nofork being a non option except when AEM was started directly from the jar. I'm currently waiting for confirmation from the project that experienced the problem, on the exact java process and opts they currently have when AEM is running. Again, this is going to be hard to confirm considering the PR was raised more than a year ago.

The intention has always been to switch back to public puppet-aem.
I just need to wait to hear back from that project, there should be updates coming in today and tomorrow.

Done. Thanks for raising this @henrykuijpers .
Published in 2.6.0 .