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