Hi Georg 2018-04-04 23:55 GMT+02:00 Georg Henzler <[email protected]>:
> Possible solutions: > > 1. Generate a package with the configurations for a particular environment > on the fly using your favourite provisioning toolchain > (AWS/Chef/Puppet/Jenkins etc.) - merging of SW-delivered configs with > generated configs is error-prone, you reinvent the wheel depending on what > toolchain you are using (or you have to use for a particular client) > I consider this option 1 the most feasible way. Because the infrastructure for provisioning is already there and you just need to get the configuration into the system. Of course this way could and should be optimized. I could imagine to have maven tooling which creates a vlt package from an INI-style configuration file (assuming that every toolchain is able to dump the configuration into such a file quite easily). > > 2. Tweak the configurations directly on system via REST calls - fairly > complex to implement and make changes to, troubleshooting of why a system > is configured as is might be hard > > 3. Use an install hook to apply env specific values - IMHO currently the > best available option, follows the approach [2], see [3] for an install > hook that can be quickly introduced to a project and is provisioning tool > independent. Downside: JVM restart required for OS env var changes and > package installation to apply them ([3] has some configuration options for > that though) > > 4. Introduce a filtering mechanism in FileVault (like JCRVLT-254 > suggested) - not available at the moment, could work similar to 3 > > 5. Use a distributed configuration service like ZooKeeper - can be nice to > keep the env-specific configuration of all systems of one environment in > one place, but fairly complicated to integrate ([3] has POC-level support > for it) > > 6. Use install folder to put *.config files - does not work well to > overwrite existing configurations, does not work for replication agents > > 7. Introduce a lower level mechanism that works on OSGi level, this could > e.g. provide certain values for PID/propertyName as system properties that > would then take higher priority than anything else (like config sets coming > from JCR). I'm not aware of such a mechanism in OSGi, but maybe something > like that already exists? > > 8. Use Sling Context-Aware configuration and implement a custom override mechanism ( http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html); this will not cover OSGI-based configuration, but with the growing level of maturity of CA-Config we could get away from storing ever "configuration" in OSGI. > What solution do you use today? > What would be the best solution for the problem? > I don't think that there is a single best solution to this problem; but we have now 8 approaches outlined, and that's too much. If we could narrow it down to a few, we could implement them all and let the user choose which one is the best for that special case. But we should give clear guidance about the pro's and con's of each approach. Jörg -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
