[MAGNOLIA-7781] Follow-up - Improve profile and magnolia.properties handling in cloud bundle Created: 28/Apr/20  Updated: 16/Jun/20  Resolved: 25/May/20

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2.2

Type: Improvement Priority: Normal
Reporter: Mikaël Geljić Assignee: Michael Duerig
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
Issue split
split to MAGNOLIA-7805 Cloud native configuration for Magnol... Closed
split to MAGNOLIA-7804 Make system properties and environmen... Closed
split to MAGNOLIA-7809 Allow magnolia profile to be specifie... Closed
split to MAGNOLIA-7810 Fail when specified configuration pro... Closed
documentation
to be documented by MAGNOLIA-7821 DOC: Environment variable for profile... Closed
relation
is related to MAGNOLIA-7811 Remove deprecated configurations styl... Accepted
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Product improvements for Cloud project features
Sprint: TE 1, TE 2, TE 3
Story Points: 5

 Description   

Introduce profile based configuration

Background

Follow-up and align with proposal from ONDEMAND-2649;

  • Approach should be mostly applicable to defaults in magnolia-core: info.magnolia.init.DefaultMagnoliaPropertiesResolver#DEFAULT_INITIALIZATION_PARAMETER
  • and/or to magnolia-empty webapp (default properties files)

Current situation

By default Magnolia property files are resolved based on the host name, context path and name of the webapp. This default is specified in DefaultMagnoliaPropertiesResolver#DEFAULT_INITIALIZATION_PARAMETER and can be overridden via the magnolia.initialization.file context parameter.

Proposal

Introduce an alternative way to resolve Magnolia property files based on profiles. A profile is simply a name that can be further parametrized on the instance type and deployment stage. For profile based configuration we would change magnolia.initialization.file to something along the lines of

WEB-INF/config/${env/MAGNOLIA_PROFILE}/magnolia_${env/MAGNOLIA_INSTANCE_TYPE}.${env/MAGNOLIA_STAGE}.properties,
WEB-INF/config/${env/MAGNOLIA_PROFILE}/magnolia_${env/MAGNOLIA_INSTANCE_TYPE}.properties,
WEB-INF/config/${env/MAGNOLIA_PROFILE}/magnolia.properties,
WEB-INF/config/default/magnolia_${env/MAGNOLIA_INSTANCE_TYPE}.${env/MAGNOLIA_STAGE}.properties, 
WEB-INF/config/default/magnolia_${env/MAGNOLIA_INSTANCE_TYPE}.properties,
WEB-INF/config/default/magnolia.properties

 The profiles dev and cloud are reserved for development and cloud profiles, respectively. We include defaults for them for explicitness and convenience. The dev profile should simplify local development and we could draw inspirations from the dev webapp. The cloud profile should simplify Magnolia cloud deployments and cover ONDEMAND-2649 as much as possible.

Related concerns

  • Magnolia should log activated profiles and failures to resolve them to facilitate debugging.
  • Handling of non expanded $(variables) in DefaultMagnoliaPropertiesResolver should be improved: such configuration sources should be skipped explicitly instead of attempting resolution with the literal, non expanded name.
  • DefaultMagnoliaPropertiesResolver relies on PropertiesInitializer#processPropertyFilesString, which is deprecated. We could replace this method with a new implementation.

Compatibility

  • Profile based configuration must be explicitly enabled (command line argument, environment variable, context or init property)
  • Consider deprecating the server based configuration in favour of profile based configuration. Sketch a migration path for those who still rely on server based configuration.

Potential further improvements

  • The dev profile could be treated specially and include non resource files (e.g. from ~/.magnolia).
  • Cloud native ways for injection the configuration. E.g. AWS Systems Manager Parameter Store.

If considered worthwhile we should discuss implications such as additional complexity, security, etc. of in follow up tickets.



 Comments   
Comment by Espen Jervidalo [ 29/Apr/20 ]

The solution proposed/implemented in the linked ticket should still be considered a work-around for the problem at hand.

We still leak implementation details of our cloud architecture into our cloud-bundle. Besides, this only solves the problem for custom bundles, or Cloud 3.

"Citing" agarcia:
Properties should not be steered by hard-coded profiles in the bundle but instead, be injected by the runtime. In our current cloud implementation, this could be AWS Parameter Store.

Comment by Michael Duerig [ 29/Apr/20 ]

mgeljicejervidalo we need to clarify the goals we want to achieve here. I.e. what problems do we want to solve by including the changes to the web descriptor from ONDEMAND-2649 into DEFAULT_INITIALIZATION_PARAMETER? What use cases do we want to cover? What level of backward compatibility do we have to maintain?

I can deduce the case for ONDEMAND-2649 for the cloud bundle from looking at the implementation. But I don't see what pulling the changes to DEFAULT_INITIALIZATION_PARAMETER down to one of the core bundles would gain us.

Comment by Michael Duerig [ 08/May/20 ]

As discussed today we still see value in changes along the lines as described as one step towards making our bundles more cloud ready and simplifying local development. I will come up with a PR as base for discussing further details.

 

Comment by Espen Jervidalo [ 08/May/20 ]

Thanks! :like:

Comment by Michael Duerig [ 25/May/20 ]

akhamis re. documentation:

  • There is a new environment variable MAGNOLIA_PROFILE, which enables a profile based configuration style when set. See the class comment of info.magnolia.init.DefaultMagnoliaPropertiesResolver for the details. The current configuration style is now deprecated and will be removed at some point in the future (see MAGNOLIA-7811).
  • There is the now the new EnvironmentPropertySource exposing environment variables as PropertySource.
  • There are a few downstream tickets split from this one, which might tweak things a bit still. Maybe good to wait with documenting until these are resolved.
Comment by Ashraf Khamis [ 26/May/20 ]

Thanks a lot for the info, mduerig. I'll wait a bit then. Please keep me posted.

Comment by Michael Duerig [ 16/Jun/20 ]

akhamis the downstream tickets are done now. In addition to my previous comment:

  • With MAGNOLIA-7804 SystemPropertySource and EnvironmentPropertySource are now injectable.
  • With MAGNOLIA-7810 if a non existing profile is specified Magnolia would fail to start up and log an error message.
Generated at Mon Feb 12 04:26:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.