Agree. The completed description of how configuration lookup happens should be properly documented, and our production guidelines should contain the recommendations for each deployment scenario.
Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Senior Software Engineer | WSO2 Blog: https://medium.com/@chamilad On Mon, Sep 4, 2017 at 12:20 PM, Bhathiya Jayasekara <[email protected]> wrote: > > On Mon, Sep 4, 2017 at 11:25 AM, Chamila De Alwis <[email protected]> > wrote: > >> Hi Bhathiya, >> >> Yes, this is an important point. However, I don't think we'd need to >> handle the order for the non-Container scenario specifically, as it would >> complicate the implementation too much. IMO config lookup should not take >> any of those factors into account. In any case, environment variables >> having priority over system properties sounds less odd, considering the >> fact that system properties are usually specified through starter scripts, >> that need to be overridden through more dynamic environment variables. WDYT? >> > > In general, envionrment variables should be overidable by system > variables. But, since we're shipping default system variable, your approach > should be ok. > However, to avoid possible issues with non-container scenarios, as a > practive we should use (and recommend) env variables only in containerized > envionrments. > > Thanks, > Bhathiya > > >> >> >> Regards, >> Chamila de Alwis >> Committer and PMC Member - Apache Stratos >> Senior Software Engineer | WSO2 >> Blog: https://medium.com/@chamilad >> >> >> >> On Sun, Sep 3, 2017 at 8:07 PM, Bhathiya Jayasekara <[email protected]> >> wrote: >> >>> >>> On Sun, Sep 3, 2017 at 7:49 PM, Bhathiya Jayasekara <[email protected]> >>> wrote: >>> >>>> Hi Chamila, >>>> >>>> On Fri, Sep 1, 2017 at 9:57 AM, Chamila De Alwis <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Please find the meeting notes below. >>>>> >>>>> 1. The existing approach where resorting to the deployment.yaml file >>>>> to figure out lookup hierarchy would be dropped. >>>>> 2. Instead, the lookup hierarchy would be implicit and will be the >>>>> following. >>>>> >>>>> 1. Environment variables >>>>> >>>>> 2. System properties >>>>> >>>>> >>>> Don't you think above 2 should be swapped? >>>> >>> >>> I gave some more thoughts to this and realized there are 2 sides to >>> this. >>> >>> 1. In a containerrized environment, above order is ok if we ship >>> default system variables. >>> 2. In a non-containerized environment, environment variables taking >>> priority over system variables sounds odd. >>> >>> I hope we came up with above order after considering both sides. >>> >>> Thanks, >>> Bhathiya >>> >>> >>>> Thanks, >>>> Bhathiya >>>> >>>> >>>>> 3. deployment.yaml file >>>>> >>>>> 4. Default values in the code >>>>> >>>>> 3. Environment variable names will be a standard convention. This >>>>> would conform to existing environment variable naming standards, namely >>>>> having all upper case letters with underscores acting as delimiters. >>>>> 4. System property names will also be a standard convention, where all >>>>> lower case letters would be used with periods being used as delimiters. >>>>> 5. It should be possible to translate map types into environment >>>>> variable names. Array types require more complex conventions that might be >>>>> non-readable. >>>>> 6. Configuration Documentation generation should also include >>>>> resources that specify the list of environment variable names that can be >>>>> used to set the possible values, for the convenience of the users. >>>>> 7. To ease the support process, it should be targetted to create tools >>>>> that collect a given deployments configurations and values. >>>>> 8. Current structure in which Data Sources are defined in the >>>>> Configuration needs to be refined into a Map type for better usability. >>>>> >>>>> Please add any that I might have missed. >>>>> >>>>> >>>>> Regards, >>>>> Chamila de Alwis >>>>> Committer and PMC Member - Apache Stratos >>>>> Senior Software Engineer | WSO2 >>>>> Blog: https://medium.com/@chamilad >>>>> >>>>> >>>>> >>>>> On Thu, Aug 31, 2017 at 1:12 PM, Chamila De Alwis <[email protected]> >>>>> wrote: >>>>> >>>>>> Kind reminder on the meeting at 2.00PM at 7th Floor Banksy room. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Chamila de Alwis >>>>>> Committer and PMC Member - Apache Stratos >>>>>> Senior Software Engineer | WSO2 >>>>>> Blog: https://medium.com/@chamilad >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 29, 2017 at 9:58 AM, Chamila De Alwis <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Please note I've pushed the meeting again to Thursday based on >>>>>>> availability. Sorry for the constant notifications. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Chamila de Alwis >>>>>>> Committer and PMC Member - Apache Stratos >>>>>>> Senior Software Engineer | WSO2 >>>>>>> Blog: https://medium.com/@chamilad >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 28, 2017 at 10:39 AM, Chamila De Alwis < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I've rescheduled the meeting to 30th August (Wednesday) 1pm-2pm, as >>>>>>>> Lakmal is unavailable today. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Chamila de Alwis >>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>> Senior Software Engineer | WSO2 >>>>>>>> Blog: https://medium.com/@chamilad >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 23, 2017 at 5:31 PM, Chamila De Alwis < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> I agree. We could omit Secure Vaulted or possible fields like >>>>>>>>> "password" values from being logged. >>>>>>>>> >>>>>>>>> I've scheduled a meeting on 28th Monday 2.00PM. Let's consolidate >>>>>>>>> these into a plan then. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Chamila de Alwis >>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>> Blog: https://medium.com/@chamilad >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 23, 2017 at 5:26 PM, Nuwan Dias <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Logging might be tricky. Some of these configs we're talking >>>>>>>>>> about are related to credentials. We shouldn't log credentials in any >>>>>>>>>> place. So we probably will have to find a way to omit logging certain >>>>>>>>>> variables if we go down the path of logging. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 23, 2017 at 5:21 PM, Chamila De Alwis < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I had an offline chat with IsuruH and Jayanga, during which >>>>>>>>>>> following points came into light. >>>>>>>>>>> >>>>>>>>>>> 1. To address the troubleshooting story, a separate log can be >>>>>>>>>>> written at the startup where the ConfigProvider executes that would >>>>>>>>>>> contain >>>>>>>>>>> the configurations overridden for the particular product. The >>>>>>>>>>> security of >>>>>>>>>>> this log should be handled in the same way for other logs. For >>>>>>>>>>> debugging, >>>>>>>>>>> this log file can be requested from a deployment. >>>>>>>>>>> 2. There is a possibility that product start-up time might >>>>>>>>>>> degrade if this logging is introduced. >>>>>>>>>>> 3. Not all configurations need to be set via environment >>>>>>>>>>> variables. There can be an attribute in the config annotation which >>>>>>>>>>> denotes >>>>>>>>>>> the environment variable that can be used to override the particular >>>>>>>>>>> configuration. This can also help in filling the documentation gap >>>>>>>>>>> that is >>>>>>>>>>> introduced, i.e. the list of environment variables that can be used >>>>>>>>>>> in a >>>>>>>>>>> particular product can be autogenerated when configuration doc >>>>>>>>>>> generation >>>>>>>>>>> story is completed. >>>>>>>>>>> 4. Complex types do not need to be supported in environment >>>>>>>>>>> variable story. This would vary depending on the likelihood that >>>>>>>>>>> configuration would be overridden through an environment variable. >>>>>>>>>>> >>>>>>>>>>> Let's schedule a meeting to discuss the concerns, including the >>>>>>>>>>> above, and come to a conclusion. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Chamila de Alwis >>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>>>> Blog: https://medium.com/@chamilad >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 23, 2017 at 3:01 PM, Chamila De Alwis < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> IMO logging values would be a security risk. It would be more >>>>>>>>>>>> manageable if information on where certain values are retrieved >>>>>>>>>>>> from can be >>>>>>>>>>>> displayed if that log level is enabled. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Chamila de Alwis >>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>>>>> Blog: https://medium.com/@chamilad >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 23, 2017 at 3:00 PM, Isuru Haththotuwa < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 23, 2017 at 2:46 PM, Lakmal Warusawithana < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 2:39 PM, Isuru Haththotuwa < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> While I fully agree that its necessary to be able to inject >>>>>>>>>>>>>>> configs via environment variables to be container friendly, I >>>>>>>>>>>>>>> think Jayanga >>>>>>>>>>>>>>> do have a point. When we are troubleshooting an issue, the >>>>>>>>>>>>>>> first thing to >>>>>>>>>>>>>>> check is the configurations. When up configuration values are >>>>>>>>>>>>>>> looked up via >>>>>>>>>>>>>>> environment variables, how do we know what are the >>>>>>>>>>>>>>> configuration parameters >>>>>>>>>>>>>>> that are used in the system? One possible option is to write to >>>>>>>>>>>>>>> a log as >>>>>>>>>>>>>>> Chamila has mentioned, or else write the currently used config >>>>>>>>>>>>>>> params to a >>>>>>>>>>>>>>> log file at startup. WDYT? However this does not take into >>>>>>>>>>>>>>> account the >>>>>>>>>>>>>>> possibility of changing an environment value even after the >>>>>>>>>>>>>>> server has >>>>>>>>>>>>>>> started. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Isuru, it is coming with correct namespace right? and first >>>>>>>>>>>>>> priority is given to environment variables. So there should not >>>>>>>>>>>>>> be an issue >>>>>>>>>>>>>> with identifying the our config from environment variables IMO. >>>>>>>>>>>>>> >>>>>>>>>>>>> Yes. What I want to highlight is the troubleshooting >>>>>>>>>>>>> perspective. We can have a particular set of config values coming >>>>>>>>>>>>> from >>>>>>>>>>>>> environment variables, another set of config values from >>>>>>>>>>>>> deployment.yaml >>>>>>>>>>>>> and defaults from the code. If we have log file file with all the >>>>>>>>>>>>> currently >>>>>>>>>>>>> used configurations values (irrespective of whether they are >>>>>>>>>>>>> coming from >>>>>>>>>>>>> environment variables, deployment.yaml or defaults in code), >>>>>>>>>>>>> which can be >>>>>>>>>>>>> written at server startup, it would be useful for the >>>>>>>>>>>>> troubleshooting >>>>>>>>>>>>> purpose IMHO. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 1:35 PM, Chamila De Alwis < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Jayanga, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From Support's point of view, requesting all the data that >>>>>>>>>>>>>>>> can have an effect is not an overhead IMO. Especially since we >>>>>>>>>>>>>>>> already do >>>>>>>>>>>>>>>> that now, we request for possible environmental factors, at >>>>>>>>>>>>>>>> least after all >>>>>>>>>>>>>>>> other efforts are exhausted. When this change is introduced, >>>>>>>>>>>>>>>> we would not >>>>>>>>>>>>>>>> additionally ask for anything. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Furthermore, environment variables would mainly be used in >>>>>>>>>>>>>>>> scenarios where Container Cluster Management systems are used, >>>>>>>>>>>>>>>> in which >>>>>>>>>>>>>>>> case there is a clear cut definition of which environment >>>>>>>>>>>>>>>> variables with >>>>>>>>>>>>>>>> what values are being applied to Containers. This is how most >>>>>>>>>>>>>>>> systems are >>>>>>>>>>>>>>>> debugged in CMSs like Kubernetes even now, where commands like >>>>>>>>>>>>>>>> `kubectl >>>>>>>>>>>>>>>> describe` would give you all the runtime information. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Non-Containerized environments like VMs would mostly use >>>>>>>>>>>>>>>> the file based approach where it is easy to be coupled with >>>>>>>>>>>>>>>> Config >>>>>>>>>>>>>>>> Automation tools like Puppet. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The concern of troubleshooting can be tackled by enabling a >>>>>>>>>>>>>>>> verbose log that would display the environment variable name >>>>>>>>>>>>>>>> from which a >>>>>>>>>>>>>>>> certain value was retrieved, at the time configs are loaded. >>>>>>>>>>>>>>>> This would >>>>>>>>>>>>>>>> obviously have to be verbose than INFO, however it would >>>>>>>>>>>>>>>> greatly help any >>>>>>>>>>>>>>>> debugging process. This is how tools like Puppet handle >>>>>>>>>>>>>>>> environment >>>>>>>>>>>>>>>> variable injected configs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The argument for file-less environment variables in the >>>>>>>>>>>>>>>> lookup hierarchy is how quickly it becomes cumbersome to handle >>>>>>>>>>>>>>>> configuration files across different Container images. Having >>>>>>>>>>>>>>>> files would >>>>>>>>>>>>>>>> soon present us with a situation similar to what we handle now >>>>>>>>>>>>>>>> in C4 with >>>>>>>>>>>>>>>> configuration repositories for different "patterns" of >>>>>>>>>>>>>>>> deployment in >>>>>>>>>>>>>>>> Containers, that requires a separate effort to be maintained >>>>>>>>>>>>>>>> for different >>>>>>>>>>>>>>>> releases. Having low-config convention-based environment >>>>>>>>>>>>>>>> variables support >>>>>>>>>>>>>>>> is a valuable addition to the C5 configuration lookup model >>>>>>>>>>>>>>>> since we've >>>>>>>>>>>>>>>> already reduced the number of configuration files. >>>>>>>>>>>>>>>> deployment.yaml will >>>>>>>>>>>>>>>> anyway be there, and I'm willing to bet that most clients >>>>>>>>>>>>>>>> would use that to >>>>>>>>>>>>>>>> make configuration changes. However, there are a set of >>>>>>>>>>>>>>>> clients who would >>>>>>>>>>>>>>>> require the convention-based environment variables for a >>>>>>>>>>>>>>>> smoother integration to Containerization than others. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Chamila de Alwis >>>>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>>>>>>>>> Blog: https://medium.com/@chamilad >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 1:03 PM, Jayanga Dissanayake < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @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 <+94%2077%20220%207259> >>>>>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Thanks and Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isuru H. >>>>>>>>>>>>>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Lakmal Warusawithana >>>>>>>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>>>>>>> Mobile : +94714289692 <071%20428%209692> >>>>>>>>>>>>>> Blogs : https://medium.com/@lakwarus/ >>>>>>>>>>>>>> http://lakmalsview.blogspot.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Thanks and Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Isuru H. >>>>>>>>>>>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Associate Technical Lead,* >>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>> >>>> *Phone: +94715478185 <071%20547%208185>* >>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>> <http://www.linkedin.com/in/bhathiyaj>* >>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>>> *Blog: http://movingaheadblog.blogspot.com >>>> <http://movingaheadblog.blogspot.com/>* >>>> >>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* >>> *Associate Technical Lead,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> *Phone: +94715478185 <+94%2071%20547%208185>* >>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>> <http://www.linkedin.com/in/bhathiyaj>* >>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>> *Blog: http://movingaheadblog.blogspot.com >>> <http://movingaheadblog.blogspot.com/>* >>> >> >> > > > -- > *Bhathiya Jayasekara* > *Associate Technical Lead,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185 <071%20547%208185>* > *LinkedIn: http://www.linkedin.com/in/bhathiyaj > <http://www.linkedin.com/in/bhathiyaj>* > *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* > *Blog: http://movingaheadblog.blogspot.com > <http://movingaheadblog.blogspot.com/>* >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
