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