search

bstopp / puppet-aem

Puppet module for managing AEM Installations.
https://forge.puppet.com/bstopp/aem
Apache License 2.0
30 stars 30 forks source link

Added support for standby type, which is a special case of AEM installation #109

Closed stevengssns closed 6 years ago

stevengssns commented 6 years ago

I have relaxed the constraint on the AEM instance type to also allow 'standby'. The main reason why I have added it as a separate type, and not simply an extra runmode is added to the documentation.

In short, it is because in our setup we have encountered problems when having both the 'author' and 'standby' runmode enabled at the same time. MQ listener services started to handle messages, which obviously should not have happened. The easiest way to avoid this in the puppet module is by allowing a new type. And as a standby does not need to have an 'author' (or 'publish' runmode) this seems to be the most correct solution anyway.

Fyi, I added a test, but I'm not able to run them locally, so it could still fail :s.

stevengssns commented 6 years ago

I have the impression that the builds are not failing due to any of my changes. Please correct me if I'm wrong.

bdhoine commented 6 years ago

@stevengssns indeed, the builds always fail due to conflicting config in rubocop and codeclimate, all my PR's also fail due to this

bstopp commented 6 years ago

Should this support both primary and standby, as per the docs?

https://helpx.adobe.com/experience-manager/6-3/sites/deploying/using/tarmk-cold-standby.html

stevengssns commented 6 years ago

A standby has no notion of being an author or publish instance, so I decided to treat it a s a type on its own. A primary on the other hand needs to be either an author or publish instance. The other way around is not true though, and author or publish does not need to be a primary. This is why I did not add this as a separate type, but kept it as a runmode that needs to be added to either author or publish (though it wouldn't be very useful to add it to the latter though).

Not having the author (or publish) runmode on the standby has the added benefit of not having OSGi configs become active by accident. However, we have noticed that we also need to clean application specific configs from the launchpad after restoring the backup from the primary. Fyi, a cold standby always requires a restored backup as a starting point, otherwise its invalid (and the puppet run will fail when starting the service..).