AEM In-Place upgrade process should not check AEM Login page
Closed this issue · 3 comments
The AEM upgrade process currently contains a step to check if the AEM login page is available after the In-Place upgrade ran successfully. This step will fail if the AEM repository contains custom codes which are incompatible to the upgraded AEM version. This can result in a false negative where the user may get the assumption that the AEM In-Place upgrade failed but it's just the custom code which prevents the AEM Login page to be displayed after the AEM In-Place upgrade ran sucessful.
Many thanks @henrykuijpers for reporting this bug.
Shouldn't we still do this wait if we did install our upgraded custom code as part of the process? As I understood from our conversation yesterday, installing the newly upgraded custom code is an optional step in the upgrade process.
I think we shouldn't install the upgraded custom code as part of the process. I think I miscommunicated this. So the upgrade process should just do the upgrade steps:
- Prepare the environment for the upgrade e.g. unpack the new JAR file
- Run repository migration, if needed
- Run the AEM Upgrade
Due to a mistake in the past the last step also contained a check for the login page, which might be not available if custom code is still installed on AEM and will prevent the login page from beeing available ... So after the AEM Upgrade was sucessfully we do not check the AEM state anymore cause we are always expecting it to be broken. In our Jenkins pipeline for the upgrade automation we are calling this manifest after the AEM upgrade
This manifest uses the deployment descriptor to install the code packages which contains the compatible code to the upgraded AEM version on AEM. At the end of this deployment process we are checking if AEM is in a healthy state.
In your case if you do not use a deployment descriptor I would reckon to you to use this manifest to install the compatible code after the AEM Upgrade:
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/install_aem_package.pp
Following parameters need to be passed to make this manifest work as a bare minimum:
aem_id = author
artifacts_base = http://artifactory/repository
package_name = aem-helloworld
package_group = shinesolutions
package_version = 1.0.0
As you will see it checks the AEM state at the end of the process. I would also reckon to you to adjust the post sleep timer https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/install_aem_package.pp#L66. I had to set it to 10 minutes at one of our users after installing the compatible custom code package after the AEM upgrade ran successfully.
If this manifest doesn't work for you check this manifest
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/action_deploy_artifact.pp
We are calling this manifest by using this shell script:
https://github.com/shinesolutions/puppet-aem-curator/blob/master/templates/aem-tools/deploy-artifact.sh.epp
In summary our Jenkins upgrade automation pipeline (https://github.com/shinesolutions/aem-opencloud-manager/blob/master/provisioners/jenkins/jenkinsfiles/aem-opencloud/migration/aws/aem-upgrade-in-place) does the following
- Run SM-Event upgrade-unpack-jar
- Run SM-Event upgrade-repository-migration
- Run SM-Event run-aem-upgrade
- Run POST SM-Event deploy-artifacts-consolidated
Looking forward to hear your feedback !
-edit-
Added usage instructions
Done. To be included in 2.1.0.0 .