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 <lakm...@wso2.com>
wrote:

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


-- 
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware

Mobile: +94 715 654154
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to