[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: |
|
||||||||||||||||||||||||||||||||||||||||
| 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 configurationBackgroundFollow-up and align with proposal from ONDEMAND-2649;
Current situationBy 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. ProposalIntroduce 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
Compatibility
Potential further improvements
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: |
| Comment by Michael Duerig [ 29/Apr/20 ] |
|
mgeljic, ejervidalo 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:
|
| 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:
|