On 12 October 2016 at 13:47, Uvindra Dias Jayasinha <uvin...@wso2.com> 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 <saj...@wso2.com> 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 < >> 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 >> >> > > > -- > Regards, > Uvindra > > Mobile: 777733962 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
