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