Hi All, -1, for injecting configs without specifying it in the deployment.yaml
Reason: When analyzing most of the issues we request config files (with C5 deployment.yaml) from the users to identify what are the configuration changes. If we have at-least the place holders in the config files, there is a guarantee that we know what are the injected configuration and we could request the actual values of the configs we need. But with the suggested approach, we have to request the 1)config files, 2)all the environment variables and get the union to identify the changed configurations. IMO an additional effort. Hence considering the overhead on the support front I am -1 for the suggested approach. Thanks, Jayanga. *Jayanga Dissanayake* Associate Technical Lead WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware email: [email protected] mobile: +94772207259 <http://wso2.com/signature> On Wed, Aug 23, 2017 at 9:16 AM, Danesh Kuruppu <[email protected]> wrote: > Created git issue[1] to track this improvement. > > 1. https://github.com/wso2/carbon-config/issues/48 > > On Tue, Aug 22, 2017 at 9:50 AM, Danesh Kuruppu <[email protected]> wrote: > >> Hi Chamila, >> >> +1 for the suggested approach. So we can have both ways to set >> environment variables either from placeholder ${env:<key>} where we can >> specify any key for the variable or from the new approach. For the new >> approach, we need adhere to a certain format as suggested. >> >> Thanks >> Danesh >> >> On Mon, Aug 21, 2017 at 5:59 PM, Chamila De Alwis <[email protected]> >> wrote: >> >>> Hi, >>> >>> In C5, the configuration lookup is done in the environment variables, >>> system properties, deployment.yaml file, and the value provided in the >>> configuration bean class, in that order. However, it looks like environment >>> variable lookup happens only if the particular configuration is noted to do >>> so in the deployment.yaml, specifically if the value of the config is >>> prefixed by a placeholder env:. >>> >>> gateWayEndpoint: ${env:gateWayEndpoint} >>> >>> While this pattern may be easy to implement, it is cumbersome to be >>> followed in a Containerization approach and IMO breaks the 12Factor >>> approach to configuration. This is because of the need to edit a physical >>> file in order for the environment variables to be queried. This makes it >>> harder to maintain a single Container Image for different deployments, and >>> manipulate the Container runtimes via environment variables. >>> >>> AFAIU, this pattern emerges from the requirements in SecureVault; having >>> a ${sec:} prefix can mark the configuration value to be resolved through >>> Secure Vault resolver. However IMO this, value resolution, is not the same >>> as value lookup. >>> >>> IMO, the following should be the lookup order, without having to mark a >>> particular config in the deployment.yaml file. >>> >>> 1. Environment variables: PREFIX_wso2.NAMESPACE_CONFIGKEY="value", >>> PREFIX_wso2.NAMESPACE_CONFIGPARENT_CONFIG2="value2" >>> 2. deployment.yaml: >>> >>> wso2.NAMESPACE: >>> >>> CONFIG_KEY: value >>> >>> CONFIG_PARENT: >>> >>> CONFIG2: valu2 >>> >>> 3. Default value in the code >>> >>> This approach would be most Container friendly one as there is no need >>> to change files depending on deployment patterns, environments, etc. >>> >>> WDYT? >>> >>> Regards, >>> Chamila de Alwis >>> Committer and PMC Member - Apache Stratos >>> Senior Software Engineer | WSO2 >>> Blog: https://medium.com/@chamilad >>> >>> >>> >> >> >> -- >> >> *Danesh Kuruppu* >> Senior Software Engineer | WSO2 >> >> Email: [email protected] >> Mobile: +94 (77) 1690552 <+94%2077%20169%200552> >> Web: WSO2 Inc <https://wso2.com/signature> >> >> > > > -- > > *Danesh Kuruppu* > Senior Software Engineer | WSO2 > > Email: [email protected] > Mobile: +94 (77) 1690552 <+94%2077%20169%200552> > Web: WSO2 Inc <https://wso2.com/signature> > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
