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
