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* *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
