This will also make the life easier when we need to make such configurations tenant wise configurable.
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 > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
