Re: [Architecture] Multiple profile support for C5 based products.

[Nuwan Dias]

On Wed, Oct 12, 2016 at 11:09 PM, Imesh Gunaratne  wrote:

>
>
> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:
>
>> Do we really need multi-profile support (at an osgi level) on C5? What if
>> we have separate dedicated runtimes per profile? Which means that we have a
>> gateway runtime, store runtime, etc. within the same distribution? Each
>> will run on its own port, maybe using offsets by default (no need to worry
>> about that if each profile is a container).
>>
>
> ​+1 If we are not planning to have the single JVM mode in C5​, this might
> be the ideal design for a containerized deployment. It would also work for
> non containerized deployments as different profiles can be started using
> unique ports.
>
> The question is whether we need a single bash script/executable for
> starting multiple profiles?
>
>>
>> Also if we have profiles, do we also have a global profile which runs all
>> components in one? I doubt we'll be able to achieve the target of 1 to 2
>> sec startup time if we do that.
>>
>
> ​I think we are trying to reduce the server startup time by lazy loading
> bundles.​
>
>

Yes, but my gut feeling is that there will still be a clear difference
between lazyload(store, publisher, gw, km, tm) and lazyload(store),
lazyload(publisher), lazyload(gw), lazyload(km), lazyload(tm).

>
> On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah  com> wrote:
>
>>
>> On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias  wrote:
>>>
>>>
>>>
>> Ex: Store will have all its bundles, config files, etc in a single
>>> directory. And it'll have its own startup script (.sh). Same will be for
>>> the publisher and other runtimes. It will result in a certain amount of
>>> duplicate jars in those directories (carbon kernel), but that isn't much of
>>> a problem isn't it? Do you see any other problems in doing that?
>>>
>>
>> The duplication will be high here IMO based on the passed experience. The
> pack size will increase due to this.
>
> ​If we were to have a distribution per profile, would duplicating bundles
> be an issue?
>
> Thanks​
> ​Imesh​
>
>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq  wrote:
>>
>>> With regards to the discussion on improving some of the limitations in
>>> the our current product profiles support [1], we had a discussion to
>>> rethink how we can improve the support for running different profiles in C5.
>>>
>>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana,
>>> Rohan
>>>
>>> *Limitations with the current approach*
>>>
>>> - We only consider the bundles.info and load the necessary bundles,
>>> however there might be certain configs and deployment artifacts that's not
>>> required
>>> - Some functionalities that aren't required for certain profiles are
>>> enabled (e.g. transports)
>>> - Distribution size is not optimal for container native architecture
>>>
>>> *Suggestion for profile support in C5*
>>>
>>> Considering the above limitation, we decided on building a profile
>>> specific distribution from the base distribution. The base distribution
>>> will pack all artifacts and also profile specific descriptors
>>>
>>> If there are any configs specific to a profile, those configs can be
>>> changed using the deployment.properties file. The base distribution will
>>> have deployment.properties file specific to the profiles, that way we don't
>>> have to duplicate any config files.
>>>
>>> During the runtime, each profile will run as an independent process -
>>> for this, we'll be moving away from default 9763/9443 ports, instead each
>>> product will have an assigned port range.
>>>
>>> We will provide a tool that will look into the profile descriptors and
>>> build the bare minimum runtime corresponding to the profile. This tool will
>>> copy the required bundles, config files etc by looking into the meta info.
>>> We can use the same tool to start the runtimes as well.
>>>
>>> The directory structure of the base distribution will be something like;
>>>
>>> wso2-am
>>> |-- bin
>>> |-- osgi
>>>  |-- plugins
>>> |-- conf
>>> |-- profiles
>>>  |-- gateway
>>>   |-- metadata.yaml
>>>   |-- deployment.properties
>>>  |-- km
>>>   |-- metadata.yaml
>>>   |-- deployment.properties
>>> |-- *runtime* --> wiill be created by the tool
>>>  |-- *wso2-am-gateway*
>>>  |-- *wso2-am-km*
>>>
>>> As shown in the folder structure, the tool will create the profile
>>> specific runtime by reading the bundles.info, metadata file etc. In the
>>> metadata.yaml file, we can specify what are the config files and other
>>> resources needed for that particular profile. So a given runtime will only
>>> have the minimum required jars and configs.
>>>
>>> Additionally, the tool provides the option to create docker-compose
>>> yaml that would take the created runtimes and deploy it in containers.
>>>
>>> We have started 

Re: [Architecture] Multiple profile support for C5 based products.

[Nuwan Dias]

On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah  wrote:

>
>
> On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:
>>>
 Do we really need multi-profile support (at an osgi level) on C5? What
 if we have separate dedicated runtimes per profile? Which means that we
 have a gateway runtime, store runtime, etc. within the same distribution?
 Each will run on its own port, maybe using offsets by default (no need to
 worry about that if each profile is a container).

>>>
>>> This is the similar thing we are trying propose. The "profiles" concept
>>> is C5 is actually runtime we are talking about. It is not only about osgi
>>> bundles, but everything a runtime needs to start on its own.
>>>
>>> For example, api-manager store runtime needs set of bundles,
>>> configuration files and store UI component written using uuf/jaggery. The
>>> tool will create this runtime by reading the descriptor file and launch the
>>> instance as a separate JVM.
>>>
>>
>> But why would we need a tool to do that? What if we build the product
>> itself in that manner.
>>
>
> It's not only about API-Manager product but the same requirement is needed
> for IoT product (and IS may also have the requirement when running the
> user/admin portal separately) that require multiple runtimes. So isn't it
> better to provide a common way to do this?
>

Well, by providing a tool aren't we pushing the complication to the
customer's end? Specially when it comes to automating (puppet, chef)
customer specific deployment patterns and all, won't it be tricky to play
around with this tool to achieve it? Even for the case of IoTS and IS and
maybe even for the new ESB, I was thinking that all should build their own
distros in that way :).

>
>
>> Ex: Store will have all its bundles, config files, etc in a single
>> directory. And it'll have its own startup script (.sh). Same will be for
>> the publisher and other runtimes. It will result in a certain amount of
>> duplicate jars in those directories (carbon kernel), but that isn't much of
>> a problem isn't it? Do you see any other problems in doing that?
>>
>
> The duplication will be high here IMO based on the passed experience. The
> pack size will increase due to this.
>

Well, our focus should be to reduce the size of the runtime right? Not
really the pack. As far as the size of store, publisher, etc remain small,
it doesn't really matter if their accumulated size is large. Because the
objective of making the pack size small is to make them more container
friendly. So in practise, people will only execute individual runtimes in a
container and not the whole distribution (accumulated pack). Therefore as
far as the individual runtime is small, it should be fine I think.

>
>

>>> Additionally if we have option of docker compose given, then it will
>>> launch a docker instance with the store runtime.
>>>
>>>
 Also if we have profiles, do we also have a global profile which runs
 all components in one?

>>>
>>> No, with the above model, there will not be a single profile (or global
>>> profile) which has all the runtime components in it and we have to move
>>> away from single product running all the components together in the same
>>> JVM. Each runtime will be started as different processes/JVM (can be
>>> OSGi-java process and just another java process).
>>>
>>> If a runtime needs a non-OSGi java process (say for example you want to
>>> start activemq as part of the product), then you can also do that using
>>> this proposed approach.
>>>
>>>
>>>
 I doubt we'll be able to achieve the target of 1 to 2 sec startup time
 if we do that.

 Thanks,
 NuwanD.

 On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq 
 wrote:

> With regards to the discussion on improving some of the limitations in
> the our current product profiles support [1], we had a discussion to
> rethink how we can improve the support for running different profiles in 
> C5.
>
> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana,
> Rohan
>
> *Limitations with the current approach*
>
> - We only consider the bundles.info and load the necessary bundles,
> however there might be certain configs and deployment artifacts that's not
> required
> - Some functionalities that aren't required for certain profiles are
> enabled (e.g. transports)
> - Distribution size is not optimal for container native architecture
>
> *Suggestion for profile support in C5*
>
> Considering the above limitation, we decided on building a profile
> specific distribution from the base distribution. The base distribution
> will pack all artifacts and also profile 

Re: [Architecture] Multiple profile support for C5 based products.

[Imesh Gunaratne]

On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:

> Do we really need multi-profile support (at an osgi level) on C5? What if
> we have separate dedicated runtimes per profile? Which means that we have a
> gateway runtime, store runtime, etc. within the same distribution? Each
> will run on its own port, maybe using offsets by default (no need to worry
> about that if each profile is a container).
>

​+1 If we are not planning to have the single JVM mode in C5​, this might
be the ideal design for a containerized deployment. It would also work for
non containerized deployments as different profiles can be started using
unique ports.

The question is whether we need a single bash script/executable for
starting multiple profiles?

>
> Also if we have profiles, do we also have a global profile which runs all
> components in one? I doubt we'll be able to achieve the target of 1 to 2
> sec startup time if we do that.
>

​I think we are trying to reduce the server startup time by lazy loading
bundles.​


On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah  wrote:

>
> On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias  wrote:
>>
>>
>>
> Ex: Store will have all its bundles, config files, etc in a single
>> directory. And it'll have its own startup script (.sh). Same will be for
>> the publisher and other runtimes. It will result in a certain amount of
>> duplicate jars in those directories (carbon kernel), but that isn't much of
>> a problem isn't it? Do you see any other problems in doing that?
>>
>
> The duplication will be high here IMO based on the passed experience. The
pack size will increase due to this.

​If we were to have a distribution per profile, would duplicating bundles
be an issue?

Thanks​
​Imesh​


> Thanks,
> NuwanD.
>
> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq  wrote:
>
>> With regards to the discussion on improving some of the limitations in
>> the our current product profiles support [1], we had a discussion to
>> rethink how we can improve the support for running different profiles in C5.
>>
>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana, Rohan
>>
>> *Limitations with the current approach*
>>
>> - We only consider the bundles.info and load the necessary bundles,
>> however there might be certain configs and deployment artifacts that's not
>> required
>> - Some functionalities that aren't required for certain profiles are
>> enabled (e.g. transports)
>> - Distribution size is not optimal for container native architecture
>>
>> *Suggestion for profile support in C5*
>>
>> Considering the above limitation, we decided on building a profile
>> specific distribution from the base distribution. The base distribution
>> will pack all artifacts and also profile specific descriptors
>>
>> If there are any configs specific to a profile, those configs can be
>> changed using the deployment.properties file. The base distribution will
>> have deployment.properties file specific to the profiles, that way we don't
>> have to duplicate any config files.
>>
>> During the runtime, each profile will run as an independent process - for
>> this, we'll be moving away from default 9763/9443 ports, instead each
>> product will have an assigned port range.
>>
>> We will provide a tool that will look into the profile descriptors and
>> build the bare minimum runtime corresponding to the profile. This tool will
>> copy the required bundles, config files etc by looking into the meta info.
>> We can use the same tool to start the runtimes as well.
>>
>> The directory structure of the base distribution will be something like;
>>
>> wso2-am
>> |-- bin
>> |-- osgi
>>  |-- plugins
>> |-- conf
>> |-- profiles
>>  |-- gateway
>>   |-- metadata.yaml
>>   |-- deployment.properties
>>  |-- km
>>   |-- metadata.yaml
>>   |-- deployment.properties
>> |-- *runtime* --> wiill be created by the tool
>>  |-- *wso2-am-gateway*
>>  |-- *wso2-am-km*
>>
>> As shown in the folder structure, the tool will create the profile
>> specific runtime by reading the bundles.info, metadata file etc. In the
>> metadata.yaml file, we can specify what are the config files and other
>> resources needed for that particular profile. So a given runtime will only
>> have the minimum required jars and configs.
>>
>> Additionally, the tool provides the option to create docker-compose yaml
>> that would take the created runtimes and deploy it in containers.
>>
>> We have started implementing the tool, please share your thoughts /
>> suggestions.
>>
>> [1] - [Architecture] How can we improve our profiles story?
>>
>> --
>> Thanks,
>> Shariq
>> Associate Technical Lead
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. 

Re: [Architecture] Multiple profile support for C5 based products.

[Kishanthan Thangarajah]

On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias  wrote:

>
>
> On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:
>>
>>> Do we really need multi-profile support (at an osgi level) on C5? What
>>> if we have separate dedicated runtimes per profile? Which means that we
>>> have a gateway runtime, store runtime, etc. within the same distribution?
>>> Each will run on its own port, maybe using offsets by default (no need to
>>> worry about that if each profile is a container).
>>>
>>
>> This is the similar thing we are trying propose. The "profiles" concept
>> is C5 is actually runtime we are talking about. It is not only about osgi
>> bundles, but everything a runtime needs to start on its own.
>>
>> For example, api-manager store runtime needs set of bundles,
>> configuration files and store UI component written using uuf/jaggery. The
>> tool will create this runtime by reading the descriptor file and launch the
>> instance as a separate JVM.
>>
>
> But why would we need a tool to do that? What if we build the product
> itself in that manner.
>

It's not only about API-Manager product but the same requirement is needed
for IoT product (and IS may also have the requirement when running the
user/admin portal separately) that require multiple runtimes. So isn't it
better to provide a common way to do this?


> Ex: Store will have all its bundles, config files, etc in a single
> directory. And it'll have its own startup script (.sh). Same will be for
> the publisher and other runtimes. It will result in a certain amount of
> duplicate jars in those directories (carbon kernel), but that isn't much of
> a problem isn't it? Do you see any other problems in doing that?
>

The duplication will be high here IMO based on the passed experience. The
pack size will increase due to this.


>
>> Additionally if we have option of docker compose given, then it will
>> launch a docker instance with the store runtime.
>>
>>
>>> Also if we have profiles, do we also have a global profile which runs
>>> all components in one?
>>>
>>
>> No, with the above model, there will not be a single profile (or global
>> profile) which has all the runtime components in it and we have to move
>> away from single product running all the components together in the same
>> JVM. Each runtime will be started as different processes/JVM (can be
>> OSGi-java process and just another java process).
>>
>> If a runtime needs a non-OSGi java process (say for example you want to
>> start activemq as part of the product), then you can also do that using
>> this proposed approach.
>>
>>
>>
>>> I doubt we'll be able to achieve the target of 1 to 2 sec startup time
>>> if we do that.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq 
>>> wrote:
>>>
 With regards to the discussion on improving some of the limitations in
 the our current product profiles support [1], we had a discussion to
 rethink how we can improve the support for running different profiles in 
 C5.

 Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana,
 Rohan

 *Limitations with the current approach*

 - We only consider the bundles.info and load the necessary bundles,
 however there might be certain configs and deployment artifacts that's not
 required
 - Some functionalities that aren't required for certain profiles are
 enabled (e.g. transports)
 - Distribution size is not optimal for container native architecture

 *Suggestion for profile support in C5*

 Considering the above limitation, we decided on building a profile
 specific distribution from the base distribution. The base distribution
 will pack all artifacts and also profile specific descriptors

 If there are any configs specific to a profile, those configs can be
 changed using the deployment.properties file. The base distribution will
 have deployment.properties file specific to the profiles, that way we don't
 have to duplicate any config files.

 During the runtime, each profile will run as an independent process -
 for this, we'll be moving away from default 9763/9443 ports, instead each
 product will have an assigned port range.

 We will provide a tool that will look into the profile descriptors and
 build the bare minimum runtime corresponding to the profile. This tool will
 copy the required bundles, config files etc by looking into the meta info.
 We can use the same tool to start the runtimes as well.

 The directory structure of the base distribution will be something like;

 wso2-am
 |-- bin
 |-- osgi
  |-- plugins
 |-- conf
 |-- profiles
  |-- gateway
   |-- metadata.yaml
   |-- deployment.properties
 

Re: [Architecture] Multiple profile support for C5 based products.

[Nuwan Dias]

On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah  wrote:

>
>
> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias  wrote:
>
>> Do we really need multi-profile support (at an osgi level) on C5? What if
>> we have separate dedicated runtimes per profile? Which means that we have a
>> gateway runtime, store runtime, etc. within the same distribution? Each
>> will run on its own port, maybe using offsets by default (no need to worry
>> about that if each profile is a container).
>>
>
> This is the similar thing we are trying propose. The "profiles" concept is
> C5 is actually runtime we are talking about. It is not only about osgi
> bundles, but everything a runtime needs to start on its own.
>
> For example, api-manager store runtime needs set of bundles, configuration
> files and store UI component written using uuf/jaggery. The tool will
> create this runtime by reading the descriptor file and launch the instance
> as a separate JVM.
>

But why would we need a tool to do that? What if we build the product
itself in that manner. Ex: Store will have all its bundles, config files,
etc in a single directory. And it'll have its own startup script (.sh).
Same will be for the publisher and other runtimes. It will result in a
certain amount of duplicate jars in those directories (carbon kernel), but
that isn't much of a problem isn't it? Do you see any other problems in
doing that?

>
> Additionally if we have option of docker compose given, then it will
> launch a docker instance with the store runtime.
>
>
>> Also if we have profiles, do we also have a global profile which runs all
>> components in one?
>>
>
> No, with the above model, there will not be a single profile (or global
> profile) which has all the runtime components in it and we have to move
> away from single product running all the components together in the same
> JVM. Each runtime will be started as different processes/JVM (can be
> OSGi-java process and just another java process).
>
> If a runtime needs a non-OSGi java process (say for example you want to
> start activemq as part of the product), then you can also do that using
> this proposed approach.
>
>
>
>> I doubt we'll be able to achieve the target of 1 to 2 sec startup time if
>> we do that.
>>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq  wrote:
>>
>>> With regards to the discussion on improving some of the limitations in
>>> the our current product profiles support [1], we had a discussion to
>>> rethink how we can improve the support for running different profiles in C5.
>>>
>>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana,
>>> Rohan
>>>
>>> *Limitations with the current approach*
>>>
>>> - We only consider the bundles.info and load the necessary bundles,
>>> however there might be certain configs and deployment artifacts that's not
>>> required
>>> - Some functionalities that aren't required for certain profiles are
>>> enabled (e.g. transports)
>>> - Distribution size is not optimal for container native architecture
>>>
>>> *Suggestion for profile support in C5*
>>>
>>> Considering the above limitation, we decided on building a profile
>>> specific distribution from the base distribution. The base distribution
>>> will pack all artifacts and also profile specific descriptors
>>>
>>> If there are any configs specific to a profile, those configs can be
>>> changed using the deployment.properties file. The base distribution will
>>> have deployment.properties file specific to the profiles, that way we don't
>>> have to duplicate any config files.
>>>
>>> During the runtime, each profile will run as an independent process -
>>> for this, we'll be moving away from default 9763/9443 ports, instead each
>>> product will have an assigned port range.
>>>
>>> We will provide a tool that will look into the profile descriptors and
>>> build the bare minimum runtime corresponding to the profile. This tool will
>>> copy the required bundles, config files etc by looking into the meta info.
>>> We can use the same tool to start the runtimes as well.
>>>
>>> The directory structure of the base distribution will be something like;
>>>
>>> wso2-am
>>> |-- bin
>>> |-- osgi
>>>  |-- plugins
>>> |-- conf
>>> |-- profiles
>>>  |-- gateway
>>>   |-- metadata.yaml
>>>   |-- deployment.properties
>>>  |-- km
>>>   |-- metadata.yaml
>>>   |-- deployment.properties
>>> |-- *runtime* --> wiill be created by the tool
>>>  |-- *wso2-am-gateway*
>>>  |-- *wso2-am-km*
>>>
>>> As shown in the folder structure, the tool will create the profile
>>> specific runtime by reading the bundles.info, metadata file etc. In the
>>> metadata.yaml file, we can specify what are the config files and other
>>> resources needed for that particular profile. So a given runtime will only
>>> have the minimum required jars and configs.
>>>
>>> Additionally, the tool provides 

Re: [Architecture] Storing configs in database for C5

[Kishanthan Thangarajah]

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

Shouldn't those configuration changes be env or sys variables and passed to
the container when launching them? You take the config values from the
user, and set them as env/sys variables for the container and start it.
This is how app cloud currently launches apps which require config changes
passed from user.



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

Re: [Architecture] Storing configs in database for C5

[Nuwan Dias]

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

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

Re: [Architecture] Multiple profile support for C5 based products.

[Nuwan Dias]

Do we really need multi-profile support (at an osgi level) on C5? What if
we have separate dedicated runtimes per profile? Which means that we have a
gateway runtime, store runtime, etc. within the same distribution? Each
will run on its own port, maybe using offsets by default (no need to worry
about that if each profile is a container).

Also if we have profiles, do we also have a global profile which runs all
components in one? I doubt we'll be able to achieve the target of 1 to 2
sec startup time if we do that.

Thanks,
NuwanD.

On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq  wrote:

> With regards to the discussion on improving some of the limitations in the
> our current product profiles support [1], we had a discussion to rethink
> how we can improve the support for running different profiles in C5.
>
> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana, Rohan
>
> *Limitations with the current approach*
>
> - We only consider the bundles.info and load the necessary bundles,
> however there might be certain configs and deployment artifacts that's not
> required
> - Some functionalities that aren't required for certain profiles are
> enabled (e.g. transports)
> - Distribution size is not optimal for container native architecture
>
> *Suggestion for profile support in C5*
>
> Considering the above limitation, we decided on building a profile
> specific distribution from the base distribution. The base distribution
> will pack all artifacts and also profile specific descriptors
>
> If there are any configs specific to a profile, those configs can be
> changed using the deployment.properties file. The base distribution will
> have deployment.properties file specific to the profiles, that way we don't
> have to duplicate any config files.
>
> During the runtime, each profile will run as an independent process - for
> this, we'll be moving away from default 9763/9443 ports, instead each
> product will have an assigned port range.
>
> We will provide a tool that will look into the profile descriptors and
> build the bare minimum runtime corresponding to the profile. This tool will
> copy the required bundles, config files etc by looking into the meta info.
> We can use the same tool to start the runtimes as well.
>
> The directory structure of the base distribution will be something like;
>
> wso2-am
> |-- bin
> |-- osgi
>  |-- plugins
> |-- conf
> |-- profiles
>  |-- gateway
>   |-- metadata.yaml
>   |-- deployment.properties
>  |-- km
>   |-- metadata.yaml
>   |-- deployment.properties
> |-- *runtime* --> wiill be created by the tool
>  |-- *wso2-am-gateway*
>  |-- *wso2-am-km*
>
> As shown in the folder structure, the tool will create the profile
> specific runtime by reading the bundles.info, metadata file etc. In the
> metadata.yaml file, we can specify what are the config files and other
> resources needed for that particular profile. So a given runtime will only
> have the minimum required jars and configs.
>
> Additionally, the tool provides the option to create docker-compose yaml
> that would take the created runtimes and deploy it in containers.
>
> We have started implementing the tool, please share your thoughts /
> suggestions.
>
> [1] - [Architecture] How can we improve our profiles story?
>
> --
> Thanks,
> Shariq
> Associate Technical Lead
>
> ___
> 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

Re: [Architecture] Storing configs in database for C5

[Lakmal Warusawithana]

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, 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 have a
> meeting if we want to change that)
>
> 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  wrote:
>
>>
>>
>> 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 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 
 wrote:

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

Re: [Architecture] Storing configs in database for C5

[Srinath Perera]

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

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


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

Re: [Architecture] Storing configs in database for C5

[Nuwan Dias]

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 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 
>> wrote:
>>
>>>
>>>
>>> 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 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 
 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.
>>

[Architecture] Multiple profile support for C5 based products.

[Muhammed Shariq]

With regards to the discussion on improving some of the limitations in the
our current product profiles support [1], we had a discussion to rethink
how we can improve the support for running different profiles in C5.

Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana, Rohan

*Limitations with the current approach*

- We only consider the bundles.info and load the necessary bundles, however
there might be certain configs and deployment artifacts that's not required
- Some functionalities that aren't required for certain profiles are
enabled (e.g. transports)
- Distribution size is not optimal for container native architecture

*Suggestion for profile support in C5*

Considering the above limitation, we decided on building a profile specific
distribution from the base distribution. The base distribution will pack
all artifacts and also profile specific descriptors

If there are any configs specific to a profile, those configs can be
changed using the deployment.properties file. The base distribution will
have deployment.properties file specific to the profiles, that way we don't
have to duplicate any config files.

During the runtime, each profile will run as an independent process - for
this, we'll be moving away from default 9763/9443 ports, instead each
product will have an assigned port range.

We will provide a tool that will look into the profile descriptors and
build the bare minimum runtime corresponding to the profile. This tool will
copy the required bundles, config files etc by looking into the meta info.
We can use the same tool to start the runtimes as well.

The directory structure of the base distribution will be something like;

wso2-am
|-- bin
|-- osgi
 |-- plugins
|-- conf
|-- profiles
 |-- gateway
  |-- metadata.yaml
  |-- deployment.properties
 |-- km
  |-- metadata.yaml
  |-- deployment.properties
|-- *runtime* --> wiill be created by the tool
 |-- *wso2-am-gateway*
 |-- *wso2-am-km*

As shown in the folder structure, the tool will create the profile specific
runtime by reading the bundles.info, metadata file etc. In the
metadata.yaml file, we can specify what are the config files and other
resources needed for that particular profile. So a given runtime will only
have the minimum required jars and configs.

Additionally, the tool provides the option to create docker-compose yaml
that would take the created runtimes and deploy it in containers.

We have started implementing the tool, please share your thoughts /
suggestions.

[1] - [Architecture] How can we improve our profiles story?

-- 
Thanks,
Shariq
Associate Technical Lead
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Storing configs in database for C5

[Lakmali Baminiwatta]

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

Thanks,
Lakmali

>
> Thanks,
> NuwanD.
>
> 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 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  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 

Re: [Architecture] Storing configs in database for C5

[Inosh Goonewardena]

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 enable/disable configurations
(monetization, stats, etc,) where it require a server restart after config
changes atm. In this case, can't we watch the config file for changes (ex:
using WatchService) and reload if there are changes to config properties?

On Wed, Oct 12, 2016 at 1:47 PM, 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 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  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: 33962
>>>
>>> ___
>>> 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 *
>> *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: 33962
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,

Inosh Goonewardena

Re: [Architecture] ESB connector auto generation tool

[Malaka Silva]

Yes Authorization is bit tricky and specific to vendors. So we can have
predefined templates (eg: Salesforce custom web services) and make this
plug-able?

On Wed, Oct 12, 2016 at 2:44 PM, Rajjaz Mohammed  wrote:

> Hi All,
>
> I have done some testings on this area for that I created an apex class[1]
> to create an account in salesforce and tested with simple java client using
> WSDL file and it works fine and can able to extract the common information
> from WSDL (attached).
>
> Our next step will create the connector based on the information extracted
> from WSDL. But we can only create the synapse template configuration which
> is general. Another challenge is the authentication part so we plan to
> create the init as the separate module  because it will not same to all
> connectors.
>
> [1]
>
> global class ConnectorAutomation{
> global class RequestClass{
> webService String accountName;
> }
> global class ResponseClass{
> webService String responseResultID;
> webService String responseResultName;
> webService String responseResultRecordType;
> }
> webService static ResponseClass addAccount(String name){
> Account acct = new Account();
> acct.Name = name;
> insert acct;
> ResponseClass resClass = new ResponseClass();
> resClass.responseResultID = acct.Id;
> resClass.responseResultName = acct.Name;
> resClass.responseResultRecordType = acct.AccountNumber;
> return resClass;
> }
> }
>
>
>
> On Wed, Sep 21, 2016 at 10:41 AM, Malaka Silva  wrote:
>
>> Yes Kasun this is what our end goal is. We are starting this with soap
>> based services. Also great if you can share any work done to speed up our
>> r
>>
>> @Ajanthan
>> ​ - Yes we are currently planning to have this a command line tool,
>> however this is not yet finalized.​
>>
>> On Wed, Sep 21, 2016 at 2:09 AM, Kasun Indrasiri  wrote:
>>
>>> Hi Malaka,
>>>
>>> We did a PoC project on generating a connector based on a given Swagger
>>> definition. Is this a similar requirement?
>>>
>>> On Tue, Sep 20, 2016 at 10:51 AM, Ajanthan Balachandran <
>>> ajant...@wso2.com> wrote:
>>>
 What do you mean by a tool? Is it command line tool  or maven plugin or
 eclipse plugin?

 On Fri, Sep 9, 2016 at 2:07 AM, Rajjaz Mohammed 
 wrote:

>
> Hi,
>>
>> ​We have currently 150+ connectors in store
>> . Using those we can easily build
>> integration use cases with WSO2 ESB.
>>
>> However there are some apis that resides on premises and specific to
>> some users. If we need to integrate such services, we either need to
>> manually do the integration with ESB or develop a connector and use it.
>>
>> The idea of this project is to automate the development of connectors
>> that makes the integration tasks more productive.
>>
>> So we are planning to start this with soap based connectors and move
>> to rest based support later.
>>
>> For soap based connector generation we basically need to parse the
>> wsdl and generate a connector operation per soap operation.
>>
>> For that we can use WSDL4J. Using this we can get the required
>> operations and request/response messages required. Using this information
>> we can build the connector operations.(Sequence Templates)
>>
>> eg:
>> String wsdlPath = "/home/wso2/Desktop/ConnectorTest.wsdl";
>> WSDLReader reader = javax.wsdl.factory.WSDLFactory
>> .newInstance().newWSDLReader();
>> javax.wsdl.Definition defn = reader.readWSDL(wsdlPath);
>>
>> Map tmp =
>> defn.getAllServices();
>>
>> for(javax.xml.namespace.QName  key:tmp.keySet()){
>> ServiceImpl serviceImpl = tmp.get(key);
>> Map  mPorts = serviceImpl.getPorts();
>> for(String k1:mPorts.keySet()){
>> PortImpl portImpl = mPorts.get(k1);
>> List bindingOperations =
>> portImpl.getBinding().getBindingOperations();
>> for(BindingOperationImpl bindingOperation:bindingOperations){
>> System.out.println("operation:" + bindingOperation.getName());
>> BindingInput bindingInput = bindingOperation.getBindingInput();
>> }
>> }
>> }
>> Map messages = defn.getMessages();
>> Iterator msgIterator = messages.values().iterator();
>> while (msgIterator.hasNext()){
>> Message msg = (Message)msgIterator.next();
>> if (!msg.isUndefined()) {
>>  System.out.println(msg.getQName());
>> }
>> }
>> Thoughts?
>>
>>
> Hi All,
>
> I have the plan to implement ESB connector auto-generation tool. Plase
> add if anything more to above explanation about the tool.
>
> Best Regards,
>>
>> Malaka Silva
>> Senior Technical Lead
>> M: +94 777 219 791
>> Tel : 94 11 214 5345
>> Fax :94 11 

Re: [Architecture] ESB connector auto generation tool

[Rajjaz Mohammed]

Hi All,

I have done some testings on this area for that I created an apex class[1]
to create an account in salesforce and tested with simple java client using
WSDL file and it works fine and can able to extract the common information
from WSDL (attached).

Our next step will create the connector based on the information extracted
from WSDL. But we can only create the synapse template configuration which
is general. Another challenge is the authentication part so we plan to
create the init as the separate module  because it will not same to all
connectors.

[1]

global class ConnectorAutomation{
global class RequestClass{
webService String accountName;
}
global class ResponseClass{
webService String responseResultID;
webService String responseResultName;
webService String responseResultRecordType;
}
webService static ResponseClass addAccount(String name){
Account acct = new Account();
acct.Name = name;
insert acct;
ResponseClass resClass = new ResponseClass();
resClass.responseResultID = acct.Id;
resClass.responseResultName = acct.Name;
resClass.responseResultRecordType = acct.AccountNumber;
return resClass;
}
}



On Wed, Sep 21, 2016 at 10:41 AM, Malaka Silva  wrote:

> Yes Kasun this is what our end goal is. We are starting this with soap
> based services. Also great if you can share any work done to speed up our
> r
>
> @Ajanthan
> ​ - Yes we are currently planning to have this a command line tool,
> however this is not yet finalized.​
>
> On Wed, Sep 21, 2016 at 2:09 AM, Kasun Indrasiri  wrote:
>
>> Hi Malaka,
>>
>> We did a PoC project on generating a connector based on a given Swagger
>> definition. Is this a similar requirement?
>>
>> On Tue, Sep 20, 2016 at 10:51 AM, Ajanthan Balachandran <
>> ajant...@wso2.com> wrote:
>>
>>> What do you mean by a tool? Is it command line tool  or maven plugin or
>>> eclipse plugin?
>>>
>>> On Fri, Sep 9, 2016 at 2:07 AM, Rajjaz Mohammed  wrote:
>>>

 Hi,
>
> ​We have currently 150+ connectors in store
> . Using those we can easily build
> integration use cases with WSO2 ESB.
>
> However there are some apis that resides on premises and specific to
> some users. If we need to integrate such services, we either need to
> manually do the integration with ESB or develop a connector and use it.
>
> The idea of this project is to automate the development of connectors
> that makes the integration tasks more productive.
>
> So we are planning to start this with soap based connectors and move
> to rest based support later.
>
> For soap based connector generation we basically need to parse the
> wsdl and generate a connector operation per soap operation.
>
> For that we can use WSDL4J. Using this we can get the required
> operations and request/response messages required. Using this information
> we can build the connector operations.(Sequence Templates)
>
> eg:
> String wsdlPath = "/home/wso2/Desktop/ConnectorTest.wsdl";
> WSDLReader reader = javax.wsdl.factory.WSDLFactory
> .newInstance().newWSDLReader();
> javax.wsdl.Definition defn = reader.readWSDL(wsdlPath);
>
> Map tmp =
> defn.getAllServices();
>
> for(javax.xml.namespace.QName  key:tmp.keySet()){
> ServiceImpl serviceImpl = tmp.get(key);
> Map  mPorts = serviceImpl.getPorts();
> for(String k1:mPorts.keySet()){
> PortImpl portImpl = mPorts.get(k1);
> List bindingOperations =
> portImpl.getBinding().getBindingOperations();
> for(BindingOperationImpl bindingOperation:bindingOperations){
> System.out.println("operation:" + bindingOperation.getName());
> BindingInput bindingInput = bindingOperation.getBindingInput();
> }
> }
> }
> Map messages = defn.getMessages();
> Iterator msgIterator = messages.values().iterator();
> while (msgIterator.hasNext()){
> Message msg = (Message)msgIterator.next();
> if (!msg.isUndefined()) {
>  System.out.println(msg.getQName());
> }
> }
> Thoughts?
>
>
 Hi All,

 I have the plan to implement ESB connector auto-generation tool. Plase
 add if anything more to above explanation about the tool.

 Best Regards,
>
> Malaka Silva
> Senior Technical Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> https://wso2.com/signature
> http://www.wso2.com/about/team/malaka-silva/
> 
> https://store.wso2.com/store/
>
> 

Re: [Architecture] Storing configs in database for C5

[Nuwan Dias]

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.

Thanks,
NuwanD.

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

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> 

Re: [Architecture] Storing configs in database for C5

[Lahiru Cooray]

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

 ___
 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 *
>>> *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: 33962
>>
>> ___
>> 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 : 

Re: [Architecture] Storing configs in database for C5

[Lakmali Baminiwatta]

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 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  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: 33962
>>>
>>> ___
>>> 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 *
>> *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: 33962
>
> ___
> 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

Re: [Architecture] Storing configs in database for C5

[Uvindra Dias Jayasinha]

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.



On 12 October 2016 at 12:58, Sajith Kariyawasam  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  > 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: 33962
>>
>> ___
>> 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 *
> *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: 33962
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Storing configs in database for C5

[Sajith Kariyawasam]

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 
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: 33962
>
> ___
> 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 *
*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

Re: [Architecture] Review DB table audit fields for API Manager C5

[Inosh Goonewardena]

On Tue, Oct 11, 2016 at 2:40 PM, Uvindra Dias Jayasinha 
wrote:

> Thanks for the feedback, some interesting points were brought up
>
> @Abimaran, the problem with maintaining a rigid structure like old/new
> column is that if a user changes the value of 5 columns at a given time
> that would mean 5 different inserts to the table, when in actual fact it
> was a single transaction that took place when the user did the change and
> saved. So its better to use a implementation like
> google-diff-match-patch[1] to record the string diff between the values of
> the columns before the change took place and after the update. Though we
> dont need to worry about this implementation detail for now. The idea of
> using a single table to store the history of all tables that will require
> auditing sounds good.
>
> @Sanjeewa, yes this would improve performance when trying to retreive the
> LAST_UPDATED_TIME for a given entity.
>
> Let me elaborate a bit on Sanjeewa's point. So there can be only one
> CREATED_BY and CREATED_TIME for a given entity so that can remain as part
> of the original entities schema. Having the LAST_UPDATED_TIME as part of
> the original entities schema gives a performance advantage on checking if a
> given entity has been modified since it was last checked. This is vital for
> features such as ETags support for the REST API. So CREATED_BY,
> CREATED_TIME, LAST_UPDATED_TIME can remain with the original entities
> schema.
>
> We can still use the master audit table(building on Abimarans idea) to
> actually keep track of change history of a given entity, so that table
> could look like this,
>
> ENTRY_ID   PK
> TABLE_NAME VARCHAR
> ENTITY_ID  FK
> DIFF  BLOB
> ACTION*VARCHAR*
> ACTION_BY  *VARCHAR*
> ACTION_TIME   *TIMESTAMP*
>
>
+1 for having single audit table and recording a diff value. Using a
structure with old/new column could become unmanageable when the changes
happen to multiple columns. Also we are planning to do audit table updates
from our code right? Database level triggers can be used in such cases but
IMO we should avoid using triggers since it could affect the performance.


>

> [1] https://code.google.com/p/google-diff-match-patch/
>
> On 11 October 2016 at 13:44, Sanjeewa Malalgoda  wrote:
>
>> I think we can manage audit table while still having CREATED_BY,
>> CREATED_TIME,UPDATED_BY, UPDATED_TIME  in same tables. So with that
>> approach we may never need to do table scan of audit table while fetching
>> updates. So each updates will recorded in separate table while original
>> table having all relevant information. WDYT?
>>
>> Thanks,
>> sanjeewa.
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,

Inosh Goonewardena
Associate Technical Lead- WSO2 Inc.
Mobile: +94779966317
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Storing configs in database for C5

[Uvindra Dias Jayasinha]

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: 33962
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture