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 <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?
> 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
>> 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?
>> Mobile: 777733962
>> Architecture mailing list
> 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 mailing list