Setting up author or publish with "aem_id" set to something else than author/publish fails
Closed this issue · 2 comments
As we understand, the aem_id is intended to name the instance that we are setting up. It does not necessarily have to be "author" or "publish", but can also be something like "local-author".
This concept works fine across all files, except when aem::instance (bstopp) is hit: $aem_id is passed as the run_mode-parameter of aem::instance and of course bstopp validates this value to be one of [publish, author]. Therefore, we get an exception upon validating the steps.
So, you should introduce a parameter that can hold the AEM instance type and use aem_id purely for naming the instance. Then, pass the instance type to the run_mode-parameter of aem::instance.
https://github.com/shinesolutions/puppet-aem-curator/blob/master/manifests/install_aem64.pp#L65
type => $aem_id,
Should be
type => $run_mode,
@Carnifrex Yes, you're spot on about the intention of aem_id . The intention is to allow any combination of AEM instances, e.g. a single server might have author1, author2, publish1, publish2, publish3.
We used to pass type => $run_mode in the past, but run mode has been refactored to support multiple run_modes. Hence passing a single run mode to type is no longer correct because users can specify any run modes ordering and we wouldn't know where the author or publish would reside within the run modes.
I'd say the correct thing to do is for install_author to pass an additional aem_type param with value author, ditto with install_publish to pass an additional aem_type param with value publish. That way the type isn't exposed to the external users.
The above is the plan, but at the moment we're preparing for AEM OpenCloud 4.0.0 so this change will probably have to wait for a couple of weeks.
Done. This is included in version 2.2.0 .
@Carnifrex please let me know if this works for you, feel free to reopen if it doesn't fix your scenario.