On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera <srin...@wso2.com> wrote:

> I believe the plan is that for server configs, there is no (admin) UI in
> C5. It can be changed only via config files. End user scenarios such as API
> publisher might have UIs for configs.  ( We should agree here or have a
> meeting if we want to change that)
>

On the API Cloud (and other clouds) we will have tenants changing some of
their configs. So for that we will have to provide a UI since we won't have
any other way to make them change files.

>
> What is an example of case where configs will take effect later?
>
> IMO storing configs in the dtabase make the deployment complicated. Also
> it reduce the scalability as all server point to one DB. I think it also
> make docker usecase complex.
>
>
> --Srinath
>
> On Wed, Oct 12, 2016 at 3:17 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>>
>> On Wed, Oct 12, 2016 at 3:28 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On 12 October 2016 at 14:31, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> There are challenges when moving configs to the DB. We experienced it
>>>> once when we moved the analytics configs to the registry. And then we moved
>>>> it back again to the FS because it was too painful to maintain.
>>>>
>>>> 1. The nodes have to keep polling the DB in a fast enough interval.
>>>> This is a unnecessary performance overhead. Because in practise, someone
>>>> will only change these configs once. But to support that use case, we have
>>>> to keep polling the DB for life.
>>>>
>>>> 2. Gateways don't have access to the DB. So say you're enabling
>>>> analytics (data publishing). You have to propagate that change to the
>>>> Gateway nodes using some mechanism. And with no clustering on C5, this is a
>>>> challenge.
>>>>
>>>> If the objective of this is to make the Cloud (tenant) experience
>>>> better, I think we should just restart the tenant's containers with the
>>>> relevant configs in place.
>>>>
>>>
>>> Still we have a problem with regard to how we are going to allow the
>>> tenants to do the configuration changes. Currently we do it through the
>>> registry which will not work for C5.
>>>
>>
>> Yes, so my idea is to provide a UI to do the configs. Those configs we
>> can store anywhere (maybe in a table) just for the sake of rendering that
>> UI. The product code will still read from the config files. When you apply
>> those configs through the press of a button, the container should get
>> rebuilt and restarted with the necessary modification to the config files.
>>
>>>
>>> Thanks,
>>> Lakmali
>>>
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> 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 <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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>> email : nuw...@wso2.com
>>>> Phone : +94 777 775 729
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> ============================
> Srinath Perera, Ph.D.
>    http://people.apache.org/~hemapani/
>    http://srinathsview.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to