Re: [Architecture] Storing configs in database for C5

Hi All, I think we need to consider two type of configs. 1. Configs which are only read at the system startup. Code is not written to allow re-read the properties and re-configure at runtime. 2. Configs which are changed at runtime, and dynamically affect the system. I think the type (1) configs

Re: [Architecture] Storing configs in database for C5

I think we should not be in the mind set that all configs are changed by system admins. That kind of thinking will not help us in our cloud first approach. Some configs govern how a particular feature may behave and its the end user who will need to set those. These are the exact kind of configs

Re: [Architecture] Storing configs in database for C5

On Fri, Oct 14, 2016 at 10:55 AM, Uvindra Dias Jayasinha wrote: > Let me summarize this thread so far. > > The functionality provided by a DB makes it easy to implement reading, > updating and sharing configs, but there have been some legitimate concerns > that have been raised

Re: [Architecture] Storing configs in database for C5

On Thu, Oct 13, 2016 at 11:39 AM, Lakmal Warusawithana wrote: > > > On Wed, Oct 12, 2016 at 6:36 PM, Nuwan Dias wrote: > >> >> >> On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera wrote: >> >>> I believe the plan is that for server configs,

Re: [Architecture] Storing configs in database for C5

Let me summarize this thread so far. The functionality provided by a DB makes it easy to implement reading, updating and sharing configs, but there have been some legitimate concerns that have been raised in this thread regarding that. As has already been outlined deployment based configs should

Re: [Architecture] Storing configs in database for C5

Hi All, If we try to categorize the configurations we have in C4, using the way we manage, 1. *Runtime configurations* - Any config you login to an UI and do - E.g. API creation/ subscription in APIM, Mediation flow in Integration Server, Service providers/ secondary user

Re: [Architecture] Storing configs in database for C5

On Wed, Oct 12, 2016 at 6:36 PM, Nuwan Dias wrote: > > > On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera 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

Re: [Architecture] Storing configs in database for C5

On Wed, Oct 12, 2016 at 6:36 PM, Nuwan Dias wrote: > > > On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera 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

Re: [Architecture] Storing configs in database for C5

On Wed, Oct 12, 2016 at 5:04 PM, Srinath Perera 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

Re: [Architecture] Storing configs in database for C5

Yes, storing configs in the database make the deployment complicated. In container world, config, dependancies, artifacts etc all bundle into docker image to make service start fast. Also it give as immutable container capabilities which make production deployment more robust. On Wed, Oct 12,

Re: [Architecture] Storing configs in database for C5

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) What is an example of case where configs

Re: [Architecture] Storing configs in database for C5

On Wed, Oct 12, 2016 at 3:28 PM, Lakmali Baminiwatta wrote: > > > On 12 October 2016 at 14:31, Nuwan Dias 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

Re: [Architecture] Storing configs in database for C5

On 12 October 2016 at 14:31, Nuwan Dias 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

Re: [Architecture] Storing configs in database for C5

Storing configurations in DB has some other advantages like security (where users cannot alter settings or read sensitive data). However, IMO it will add an unnecessary overhead because we have to rely on DB connection and reading overhead is also there. But, I agree on the point about the

Re: [Architecture] Storing configs in database for C5

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

Re: [Architecture] Storing configs in database for C5

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 wrote: > > > On 12 October 2016 at 13:47, Uvindra Dias Jayasinha > wrote: > >> Hi Sajith, >> >> Yes

Re: [Architecture] Storing configs in database for C5

On 12 October 2016 at 13:47, Uvindra Dias Jayasinha 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

Re: [Architecture] Storing configs in database for C5

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

Re: [Architecture] Storing configs in database for C5

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