@Nuwan, configs should be able to inject via environment properties. What I
am saying is all these configs should be specified the in the
deployment.yaml as {env:placeholder name}.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 12:51 PM, Nuwan Dias <[email protected]> wrote: > @Jayanga, how do you make the server run elegantly on containers without > being able to inject properties via env variables? > > On Wed, Aug 23, 2017 at 12:43 PM, Jayanga Dissanayake <[email protected]> > wrote: > >> 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 <+94%2077%20220%207259> >> <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 >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <+94%2077%20777%205729> > > _______________________________________________ > 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
