We (myself and Azeez) had a offline chat about this requirement, it seems it would be much flexible for both users and product teams if deployment.yaml processing framework can support 3 levels instead of 2 : Component, Product, User
Component level : - Component author define default values within the bean class if 'default values' concept is applicable. Product level :- Product team override component level default values using 'defaults.yaml' file ( within the WSO2 file space ) User level :- User can override component or product level default values using deployment.yaml file The main advantage here is we can clearly separate responsibilities and scope of each group and possible to ship deployment.yaml with absolutely zero content. This is the same concept suggested by Ruwan with few modifications. Thanks ! On Thu, Feb 2, 2017 at 9:36 AM, Afkham Azeez <az...@wso2.com> wrote: > This is out of the scope of the deployment.yaml processing framework > Danesh wrote. If you want to have default connectors or config, you can > either write a product-specific component which programmatically creates > those, or you can ship that in the product specific deployment.yaml. > > On Thu, Feb 2, 2017 at 7:24 AM, Sagara Gunathunga <sag...@wso2.com> wrote: > >> >> >> On Wed, Feb 1, 2017 at 11:11 PM, Danesh Kuruppu <dan...@wso2.com> wrote: >> >>> Hi Jayanga, >>> >>> it is defaulted to the component. any product which is using the >>> component will get the same default values. If a product need values other >>> than the default value, they have to override it in the deployment.yaml. >>> default values should be component related values, not related for the >>> specific product. >>> >> >> This is true in ideal cases but practically we have more complex use >> cases, taking the same example identity-mgt is a generic F/W kind of a >> component which allows to register/manage IdentityStore connectors and >> there is no component level default connector concept, it's just a >> registration/management capability, only in product level(IS) we ship >> default IdentityStore connectors. Here we have 2 options .. >> >> 1.) As there is no default connector in component level, all the products >> including IS has to provide default connectors in deployment.yaml, then >> this is not kind of value overridden and when number of such components >> increase default size of the deployment.yaml will increase which again >> result into deviate from original motivation of deployment.yaml. >> >> >> 2. ) In cases of components do not have default values we can hard cord >> default values according to the base product, in this way at least base >> product can keep deployment.yaml clean. >> >> WDYT ? >> >> >> Thanks ! >> >> >>> >>> Thanks >>> Danesh >>> >>> On Wed, Feb 1, 2017 at 3:58 AM, Jayanga Kaushalya <jayan...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> If we are hard-coding default values to the bean class, are those >>>> values should be default to the component or to the product which is >>>> (frequently) using that component ? If we use default values related to the >>>> product then we can use that values directly in the specific product and if >>>> some other product is using that component, they have to override it in the >>>> deployment.yaml. For example product-is is using component identity-mgt. So >>>> what should be the default values for the config files coming from >>>> identity-mgt component ? Are those should be defaulted to the product-is >>>> related values or to the component related values and product-is should >>>> always override them from deployment.yaml. >>>> >>>> Thanks! >>>> >>>> *Jayanga Kaushalya* >>>> Software Engineer >>>> Mobile: +94777860160 <+94%2077%20786%200160> >>>> WSO2 Inc. | http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> On Wed, Nov 30, 2016 at 10:57 AM, Danesh Kuruppu <dan...@wso2.com> >>>> wrote: >>>> >>>>> Hi Dilan, >>>>> >>>>> If all user-configurable properties are not readily available in the >>>>>> .yaml file by default, how would a user know which >>>>>> properties are configurable and which are not ? >>>>>> >>>>> >>>>> All the configurable properties and their default values will be >>>>> documented. We are going to create this config document automatically by >>>>> reading the config bean class (using maven plugin). >>>>> We need to decide whether we pack those config documents in the >>>>> product or add to central location (doc page etc) >>>>> >>>>> Thanks >>>>> -- >>>>> >>>>> *Danesh Kuruppu* >>>>> Senior Software Engineer | WSO2 >>>>> >>>>> Email: dan...@wso2.com >>>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552> >>>>> Web: WSO2 Inc <https://wso2.com/signature> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> *Danesh Kuruppu* >>> Senior Software Engineer | WSO2 >>> >>> Email: dan...@wso2.com >>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552> >>> Web: WSO2 Inc <https://wso2.com/signature> >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Associate Director / Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> > > > -- > *Afkham Azeez* > Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- Sagara Gunathunga Associate Director / Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
