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 <uvin...@wso2.com> 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 > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
