On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera <[email protected]> wrote:
> I believe the plan is that for server configs, there is no (admin) UI in > C5. It can be changed only via config files. End user scenarios such as API > publisher might have UIs for configs. ( We should agree here or have a > meeting if we want to change that) > On the API Cloud (and other clouds) we will have tenants changing some of their configs. So for that we will have to provide a UI since we won't have any other way to make them change files. > > What is an example of case where configs will take effect later? > > IMO storing configs in the dtabase make the deployment complicated. Also > it reduce the scalability as all server point to one DB. I think it also > make docker usecase complex. > > > --Srinath > > On Wed, Oct 12, 2016 at 3:17 AM, Nuwan Dias <[email protected]> wrote: > >> >> >> On Wed, Oct 12, 2016 at 3:28 PM, Lakmali Baminiwatta <[email protected]> >> wrote: >> >>> >>> >>> On 12 October 2016 at 14:31, Nuwan Dias <[email protected]> wrote: >>> >>>> There are challenges when moving configs to the DB. We experienced it >>>> once when we moved the analytics configs to the registry. And then we moved >>>> it back again to the FS because it was too painful to maintain. >>>> >>>> 1. The nodes have to keep polling the DB in a fast enough interval. >>>> This is a unnecessary performance overhead. Because in practise, someone >>>> will only change these configs once. But to support that use case, we have >>>> to keep polling the DB for life. >>>> >>>> 2. Gateways don't have access to the DB. So say you're enabling >>>> analytics (data publishing). You have to propagate that change to the >>>> Gateway nodes using some mechanism. And with no clustering on C5, this is a >>>> challenge. >>>> >>>> If the objective of this is to make the Cloud (tenant) experience >>>> better, I think we should just restart the tenant's containers with the >>>> relevant configs in place. >>>> >>> >>> Still we have a problem with regard to how we are going to allow the >>> tenants to do the configuration changes. Currently we do it through the >>> registry which will not work for C5. >>> >> >> Yes, so my idea is to provide a UI to do the configs. Those configs we >> can store anywhere (maybe in a table) just for the sake of rendering that >> UI. The product code will still read from the config files. When you apply >> those configs through the press of a button, the container should get >> rebuilt and restarted with the necessary modification to the config files. >> >>> >>> Thanks, >>> Lakmali >>> >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> On Wed, Oct 12, 2016 at 2:12 PM, Lakmali Baminiwatta <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 12 October 2016 at 13:47, Uvindra Dias Jayasinha <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Sajith, >>>>>> >>>>>> Yes even though the boot up time is not an issue in C5 the other >>>>>> advantages I have outlined are still there to be gained. There is a huge >>>>>> effort we have to do on dev ops side to maintain those images you are >>>>>> talking about because of having everything at file level. >>>>>> >>>>>> Some examples from API Manager I can think of are turning >>>>>> notifications on/off, enable monetization, enable/disable stats, >>>>>> configure >>>>>> work flows, Enable/Disable JWT token header. >>>>>> >>>>> >>>>> +1 to move feature related configurations to the database and make >>>>> them configurable through the UI. >>>>> >>>>> Thanks, >>>>> Lakmali >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 October 2016 at 12:58, Sajith Kariyawasam <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Uvindra, >>>>>>> >>>>>>> With cloud deployment in mind, the idea is to boot up the nodes in >>>>>>> quick time, therefore the docker images are pre-configured with all the >>>>>>> configuration values, which will speed up the node start up. A change of >>>>>>> configuration means a new docker image will be created with the new >>>>>>> configs, and re-spawn the cluster. >>>>>>> >>>>>>> Therefore, IMO a node restart for a config change is not relevant, >>>>>>> also no need of a periodic config checks. >>>>>>> >>>>>>> Btw, can you give me some example configuration you were thinking >>>>>>> of? >>>>>>> >>>>>>> Thanks, >>>>>>> Sajith >>>>>>> >>>>>>> On Wed, Oct 12, 2016 at 11:53 AM, Uvindra Dias Jayasinha < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Was wondering about $subject >>>>>>>> >>>>>>>> Traditionally we have stored our product configs, be it carbon.xml, >>>>>>>> api-manager.xml, identity.xml, etc. at file level. Some configs, such >>>>>>>> as >>>>>>>> "port offset" are inherently bound to the server startup so it makes >>>>>>>> sense >>>>>>>> for them to be at file level, since they come into affect during the >>>>>>>> startup. But certain runtime configs actually get engaged only when a >>>>>>>> given >>>>>>>> feature is used. But having those configs at file level require a >>>>>>>> restart >>>>>>>> for the changes to take affect. In C4 API Manager avoided doing >>>>>>>> restarts >>>>>>>> for certain config changes, like adding mediation extensions, by >>>>>>>> storing >>>>>>>> them in the registry. >>>>>>>> >>>>>>>> For C5 a reusable implementation can exist at each node which >>>>>>>> periodically reads the table(say once a minute) and updates the config >>>>>>>> values in memory. Products communicate with this config library to get >>>>>>>> the >>>>>>>> values of a given config. So eventually they will read the updated >>>>>>>> value in >>>>>>>> a short time. If we were to store at least certain configs at DB level >>>>>>>> there are several advantages. >>>>>>>> >>>>>>>> 1. Eliminate need for a restart for changes to take affect. I >>>>>>>> realize in C5 a restart is relatively cheap so this might not be a big >>>>>>>> deal, but you still need someone to initiate the restart after the >>>>>>>> config >>>>>>>> change. >>>>>>>> >>>>>>>> 2. Since the config DB table has a known structure a UI can be >>>>>>>> easily developed to do CRUD operations for config changes and used by >>>>>>>> all >>>>>>>> products. This is a lot more user friendly than asking users to change >>>>>>>> files. >>>>>>>> >>>>>>>> 3. We can provide a REST API to allow config changes to be done on >>>>>>>> the DB table alternatively. >>>>>>>> >>>>>>>> 4. Simplify dev ops by eliminating complicated puppet config >>>>>>>> templates that need to constantly maintained with new releases. >>>>>>>> >>>>>>>> 5. Since configs are in a central DB its easy to manage them since >>>>>>>> all nodes will read from the same table. >>>>>>>> >>>>>>>> 6. Configs can be backed up by simply backing up the table >>>>>>>> >>>>>>>> >>>>>>>> Doing this makes sense for certain use cases of API Manger, I'm >>>>>>>> sure there maybe similar benefits for other products as well. It may >>>>>>>> not >>>>>>>> make sense for all configs but at least for some that govern feature >>>>>>>> functionality its great to have. WDYT? >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Uvindra >>>>>>>> >>>>>>>> Mobile: 777733962 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sajith Kariyawasam >>>>>>> *Associate Tech Lead* >>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >>>>>>> *Committer and PMC member, Apache Stratos * >>>>>>> *AMIE (SL)* >>>>>>> *Mobile: 0772269575 <0772269575>* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmali Baminiwatta >>>>> Associate Technical Lead >>>>> WSO2, Inc.: http://wso2.com >>>>> lean.enterprise.middleware >>>>> mobile: +94 71 2335936 >>>>> blog : lakmali.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Lakmali Baminiwatta >>> Associate Technical Lead >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> blog : lakmali.com >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
