Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi Sajith,

Yes, First we deploy the artifacts in server deployment directory and then
deploy the runtime specific artifacts.

Thanks
Thusitha

On Fri, Sep 8, 2017 at 11:14 AM, SajithAR Ariyarathna 
wrote:

> Hi Thusitha,
>
> On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Jayanga,
>>
>> From the beginning of C5, we tried to achieve a clear separation between,
>>> User(Custom) space and Server space.
>>> IMO, having just a single deployment directory (for both custom and
>>> server artifacts) won't help to maintain that separation.
>>
>> We are having 2 deployment directories.
>>
>>1. //deployment
>>2. /deployment
>>
>> Is there a priority in these directories?
> Thanks.
>
> On Mon, Aug 14, 2017 at 12:14 PM, Niranjan Karunanandham <
> niran...@wso2.com> wrote:
>
>> Hi Thusitha,
>>
>> On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi Jayanga,
>>>
>>> From the beginning of C5, we tried to achieve a clear separation
 between, User(Custom) space and Server space.
 IMO, having just a single deployment directory (for both custom and
 server artifacts) won't help to maintain that separation.
>>>
>>> We are having 2 deployment directories.
>>>
>>>1. //deployment
>>>2. /deployment
>>>
>>> The issue is in existing API we have a method to deploy/upload the given
>>> artifact to the deployment directory. This was not an issue previously coz
>>> we had only single deployment dir. But since now we have multiple
>>> deployment dirs, where should we deploy the artifact?
>>>
>> When are we using this method, i.e., the use-case? If the artifact is
>> within the either the runtime deployment or serverhome deployment
>> directory, then based on that the artifact can be deployed in the
>> corresponding directory.
>>
>>
>>>
>>> Thanks
>>> Thusitha
>>>
>>> On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
>>> wrote:
>>>
 Hi Thusitha/Nira,

 From the beginning of C5, we tried to achieve a clear separation
 between, User(Custom) space and Server space.
 IMO, having just a single deployment directory (for both custom and
 server artifacts) won't help to maintain that separation.

 WDYT?

 Thanks,
 Jayanga.

 *Jayanga Dissanayake*
 Associate Technical Lead
 WSO2 Inc. - http://wso2.com/
 lean . enterprise . middleware
 email: jaya...@wso2.com
 mobile: +94772207259 <+94%2077%20220%207259>
 

 On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
 niran...@wso2.com> wrote:

> Hi,
>
> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi All,
>>
>> In c5 carbon-deployment we have a method to manually deploy artifacts
>> where we only provide artifact's path and artifact type. This was no 
>> issue
>> until 5.2.0-m3 since we only had a single deployment directory.
>> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>>
>> But since we have 2 deployment directories with the new
>> runtime architecture. So how should we handle this deployment?
>> AFAIU options would be as follows
>>
>>1. Add a new API(method) to get the relevant deployment dir and
>>deploy to that
>>2. We have to prioritize a deployment directory (Server or
>>runtime) and deploy only to the prioritized one
>>3. Deploy to both deployment dirs
>>
>>
>>
> In the new deployment directory, each runtime will have a deployment
> directory and there will be on outside. The runtime deployment will be for
> wso2 artifacts. AFAIU with previous model (C4), the above method is used 
> by
> when a user uploads the artifact from a UI. Therefore IMO the default
> method should deploy the artifact to the deployment directory outside the
> runtime, i.e., /deployment.
>
>
>> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
>> onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
>> so2/carbon/deployment/engine/DeploymentService.java#L43
>>
>> Thanks
>> Thusitha
>>
>>
>> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu 
>> wrote:
>>
>>> Hi all,
>>>
>>> Correction: Proposed directory structure needed to be change as
>>> below. instead of having deployment directory per runtime, we will have
>>> only deployment directory per server distribution. This deployment
>>> directory contains custom deployable artifacts. So ideally there won't 
>>> be
>>> any artifact in default distribution.
>>>
>>> Though we have packaging all runtimes in one distribution. we are
>>> not encouraging to run all runtime from the single pack. So we are 
>>> going to
>>> 

Re: [Architecture] Multiple runtime support for C5 based products

[SajithAR Ariyarathna]

Hi Thusitha,

On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Jayanga,
>
> From the beginning of C5, we tried to achieve a clear separation between,
>> User(Custom) space and Server space.
>> IMO, having just a single deployment directory (for both custom and
>> server artifacts) won't help to maintain that separation.
>
> We are having 2 deployment directories.
>
>1. //deployment
>2. /deployment
>
> Is there a priority in these directories?
Thanks.

On Mon, Aug 14, 2017 at 12:14 PM, Niranjan Karunanandham 
wrote:

> Hi Thusitha,
>
> On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Jayanga,
>>
>> From the beginning of C5, we tried to achieve a clear separation between,
>>> User(Custom) space and Server space.
>>> IMO, having just a single deployment directory (for both custom and
>>> server artifacts) won't help to maintain that separation.
>>
>> We are having 2 deployment directories.
>>
>>1. //deployment
>>2. /deployment
>>
>> The issue is in existing API we have a method to deploy/upload the given
>> artifact to the deployment directory. This was not an issue previously coz
>> we had only single deployment dir. But since now we have multiple
>> deployment dirs, where should we deploy the artifact?
>>
> When are we using this method, i.e., the use-case? If the artifact is
> within the either the runtime deployment or serverhome deployment
> directory, then based on that the artifact can be deployed in the
> corresponding directory.
>
>
>>
>> Thanks
>> Thusitha
>>
>> On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
>> wrote:
>>
>>> Hi Thusitha/Nira,
>>>
>>> From the beginning of C5, we tried to achieve a clear separation
>>> between, User(Custom) space and Server space.
>>> IMO, having just a single deployment directory (for both custom and
>>> server artifacts) won't help to maintain that separation.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Jayanga.
>>>
>>> *Jayanga Dissanayake*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.com/
>>> lean . enterprise . middleware
>>> email: jaya...@wso2.com
>>> mobile: +94772207259 <+94%2077%20220%207259>
>>> 
>>>
>>> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
 Hi,

 On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
 thusit...@wso2.com> wrote:

> Hi All,
>
> In c5 carbon-deployment we have a method to manually deploy artifacts
> where we only provide artifact's path and artifact type. This was no issue
> until 5.2.0-m3 since we only had a single deployment directory.
> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>
> But since we have 2 deployment directories with the new
> runtime architecture. So how should we handle this deployment?
> AFAIU options would be as follows
>
>1. Add a new API(method) to get the relevant deployment dir and
>deploy to that
>2. We have to prioritize a deployment directory (Server or
>runtime) and deploy only to the prioritized one
>3. Deploy to both deployment dirs
>
>
>
 In the new deployment directory, each runtime will have a deployment
 directory and there will be on outside. The runtime deployment will be for
 wso2 artifacts. AFAIU with previous model (C4), the above method is used by
 when a user uploads the artifact from a UI. Therefore IMO the default
 method should deploy the artifact to the deployment directory outside the
 runtime, i.e., /deployment.


> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
> onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
> so2/carbon/deployment/engine/DeploymentService.java#L43
>
> Thanks
> Thusitha
>
>
> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu 
> wrote:
>
>> Hi all,
>>
>> Correction: Proposed directory structure needed to be change as
>> below. instead of having deployment directory per runtime, we will have
>> only deployment directory per server distribution. This deployment
>> directory contains custom deployable artifacts. So ideally there won't be
>> any artifact in default distribution.
>>
>> Though we have packaging all runtimes in one distribution. we are not
>> encouraging to run all runtime from the single pack. So we are going to
>> provide a script to exact runtime from the distribution pack.
>>
>> ServerHome
>>>|_ bin
>>>| |___ runtime1.sh
>>>| |___ runtime2.sh
>>>| |___ start-all.sh (start all the runtimes
>>> except default in separate JVMs)
>>>| |___ default.sh (start required runtimes in a
>>> 

Re: [Architecture] Multiple runtime support for C5 based products

[Niranjan Karunanandham]

Hi Thusitha,

On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Jayanga,
>
> From the beginning of C5, we tried to achieve a clear separation between,
>> User(Custom) space and Server space.
>> IMO, having just a single deployment directory (for both custom and
>> server artifacts) won't help to maintain that separation.
>
> We are having 2 deployment directories.
>
>1. //deployment
>2. /deployment
>
> The issue is in existing API we have a method to deploy/upload the given
> artifact to the deployment directory. This was not an issue previously coz
> we had only single deployment dir. But since now we have multiple
> deployment dirs, where should we deploy the artifact?
>
When are we using this method, i.e., the use-case? If the artifact is
within the either the runtime deployment or serverhome deployment
directory, then based on that the artifact can be deployed in the
corresponding directory.


>
> Thanks
> Thusitha
>
> On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
> wrote:
>
>> Hi Thusitha/Nira,
>>
>> From the beginning of C5, we tried to achieve a clear separation between,
>> User(Custom) space and Server space.
>> IMO, having just a single deployment directory (for both custom and
>> server artifacts) won't help to maintain that separation.
>>
>> WDYT?
>>
>> Thanks,
>> Jayanga.
>>
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Hi All,

 In c5 carbon-deployment we have a method to manually deploy artifacts
 where we only provide artifact's path and artifact type. This was no issue
 until 5.2.0-m3 since we only had a single deployment directory.
 public void deploy(String artifactPath, ArtifactType artifactType)[1]

 But since we have 2 deployment directories with the new
 runtime architecture. So how should we handle this deployment?
 AFAIU options would be as follows

1. Add a new API(method) to get the relevant deployment dir and
deploy to that
2. We have to prioritize a deployment directory (Server or runtime)
and deploy only to the prioritized one
3. Deploy to both deployment dirs



>>> In the new deployment directory, each runtime will have a deployment
>>> directory and there will be on outside. The runtime deployment will be for
>>> wso2 artifacts. AFAIU with previous model (C4), the above method is used by
>>> when a user uploads the artifact from a UI. Therefore IMO the default
>>> method should deploy the artifact to the deployment directory outside the
>>> runtime, i.e., /deployment.
>>>
>>>
 [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
 onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
 so2/carbon/deployment/engine/DeploymentService.java#L43

 Thanks
 Thusitha


 On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu 
 wrote:

> Hi all,
>
> Correction: Proposed directory structure needed to be change as below.
> instead of having deployment directory per runtime, we will have only
> deployment directory per server distribution. This deployment directory
> contains custom deployable artifacts. So ideally there won't be any
> artifact in default distribution.
>
> Though we have packaging all runtimes in one distribution. we are not
> encouraging to run all runtime from the single pack. So we are going to
> provide a script to exact runtime from the distribution pack.
>
> ServerHome
>>|_ bin
>>| |___ runtime1.sh
>>| |___ runtime2.sh
>>| |___ start-all.sh (start all the runtimes except
>> default in separate JVMs)
>>| |___ default.sh (start required runtimes in a
>> single JVM)
>>| |___ jartobundle.sh
>>|
>>|
>>|_ deployment (This will contains custom deployable
>> artifacts)
>>| |___ uuf
>>| |___ microservices
>>|
>>|_ lib
>>|
>>|_ conf
>>|| runtime1
>>|| | deployment.yaml
>>|| | master-keys.yaml
>>|| | secrets.properties
>>|| | log4j2.xml
>>|| | etc
>>|| 

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi Jayanga,

>From the beginning of C5, we tried to achieve a clear separation between,
> User(Custom) space and Server space.
> IMO, having just a single deployment directory (for both custom and server
> artifacts) won't help to maintain that separation.

We are having 2 deployment directories.

   1. //deployment
   2. /deployment

The issue is in existing API we have a method to deploy/upload the given
artifact to the deployment directory. This was not an issue previously coz
we had only single deployment dir. But since now we have multiple
deployment dirs, where should we deploy the artifact?

Thanks
Thusitha

On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
wrote:

> Hi Thusitha/Nira,
>
> From the beginning of C5, we tried to achieve a clear separation between,
> User(Custom) space and Server space.
> IMO, having just a single deployment directory (for both custom and server
> artifacts) won't help to maintain that separation.
>
> WDYT?
>
> Thanks,
> Jayanga.
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
> niran...@wso2.com> wrote:
>
>> Hi,
>>
>> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In c5 carbon-deployment we have a method to manually deploy artifacts
>>> where we only provide artifact's path and artifact type. This was no issue
>>> until 5.2.0-m3 since we only had a single deployment directory.
>>> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>>>
>>> But since we have 2 deployment directories with the new
>>> runtime architecture. So how should we handle this deployment?
>>> AFAIU options would be as follows
>>>
>>>1. Add a new API(method) to get the relevant deployment dir and
>>>deploy to that
>>>2. We have to prioritize a deployment directory (Server or runtime)
>>>and deploy only to the prioritized one
>>>3. Deploy to both deployment dirs
>>>
>>>
>>>
>> In the new deployment directory, each runtime will have a deployment
>> directory and there will be on outside. The runtime deployment will be for
>> wso2 artifacts. AFAIU with previous model (C4), the above method is used by
>> when a user uploads the artifact from a UI. Therefore IMO the default
>> method should deploy the artifact to the deployment directory outside the
>> runtime, i.e., /deployment.
>>
>>
>>> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
>>> onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
>>> so2/carbon/deployment/engine/DeploymentService.java#L43
>>>
>>> Thanks
>>> Thusitha
>>>
>>>
>>> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu  wrote:
>>>
 Hi all,

 Correction: Proposed directory structure needed to be change as below.
 instead of having deployment directory per runtime, we will have only
 deployment directory per server distribution. This deployment directory
 contains custom deployable artifacts. So ideally there won't be any
 artifact in default distribution.

 Though we have packaging all runtimes in one distribution. we are not
 encouraging to run all runtime from the single pack. So we are going to
 provide a script to exact runtime from the distribution pack.

 ServerHome
>|_ bin
>| |___ runtime1.sh
>| |___ runtime2.sh
>| |___ start-all.sh (start all the runtimes except
> default in separate JVMs)
>| |___ default.sh (start required runtimes in a
> single JVM)
>| |___ jartobundle.sh
>|
>|
>|_ deployment (This will contains custom deployable
> artifacts)
>| |___ uuf
>| |___ microservices
>|
>|_ lib
>|
>|_ conf
>|| runtime1
>|| | deployment.yaml
>|| | master-keys.yaml
>|| | secrets.properties
>|| | log4j2.xml
>|| | etc
>|| | |__
> pax-logging.properties
>|| | osgi
>||   |__ launch.properties
>||   |__ osgi-debug.options
>|| runtime2
>|  | deployment.yaml
>|  | master-keys.yaml
>|  | 

Re: [Architecture] Multiple runtime support for C5 based products

[Jayanga Dissanayake]

Hi Thusitha/Nira,

>From the beginning of C5, we tried to achieve a clear separation between,
User(Custom) space and Server space.
IMO, having just a single deployment directory (for both custom and server
artifacts) won't help to maintain that separation.

WDYT?

Thanks,
Jayanga.

*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: jaya...@wso2.com
mobile: +94772207259


On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham 
wrote:

> Hi,
>
> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi All,
>>
>> In c5 carbon-deployment we have a method to manually deploy artifacts
>> where we only provide artifact's path and artifact type. This was no issue
>> until 5.2.0-m3 since we only had a single deployment directory.
>> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>>
>> But since we have 2 deployment directories with the new
>> runtime architecture. So how should we handle this deployment?
>> AFAIU options would be as follows
>>
>>1. Add a new API(method) to get the relevant deployment dir and
>>deploy to that
>>2. We have to prioritize a deployment directory (Server or runtime)
>>and deploy only to the prioritized one
>>3. Deploy to both deployment dirs
>>
>>
>>
> In the new deployment directory, each runtime will have a deployment
> directory and there will be on outside. The runtime deployment will be for
> wso2 artifacts. AFAIU with previous model (C4), the above method is used by
> when a user uploads the artifact from a UI. Therefore IMO the default
> method should deploy the artifact to the deployment directory outside the
> runtime, i.e., /deployment.
>
>
>> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
>> onents/org.wso2.carbon.deployment.engine/src/main/java/org/
>> wso2/carbon/deployment/engine/DeploymentService.java#L43
>>
>> Thanks
>> Thusitha
>>
>>
>> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu  wrote:
>>
>>> Hi all,
>>>
>>> Correction: Proposed directory structure needed to be change as below.
>>> instead of having deployment directory per runtime, we will have only
>>> deployment directory per server distribution. This deployment directory
>>> contains custom deployable artifacts. So ideally there won't be any
>>> artifact in default distribution.
>>>
>>> Though we have packaging all runtimes in one distribution. we are not
>>> encouraging to run all runtime from the single pack. So we are going to
>>> provide a script to exact runtime from the distribution pack.
>>>
>>> ServerHome
|_ bin
| |___ runtime1.sh
| |___ runtime2.sh
| |___ start-all.sh (start all the runtimes except
 default in separate JVMs)
| |___ default.sh (start required runtimes in a
 single JVM)
| |___ jartobundle.sh
|
|
|_ deployment (This will contains custom deployable
 artifacts)
| |___ uuf
| |___ microservices
|
|_ lib
|
|_ conf
|| runtime1
|| | deployment.yaml
|| | master-keys.yaml
|| | secrets.properties
|| | log4j2.xml
|| | etc
|| | |__
 pax-logging.properties
|| | osgi
||   |__ launch.properties
||   |__ osgi-debug.options
|| runtime2
|  | deployment.yaml
|  | master-keys.yaml
|  | secrets.properties
|  | log4j2.xml
|  | etc
|  | |__
 pax-logging.properties
|  | osgi
||__ launch.properties
||__ osgi-debug.options
|
|_ resources
|| security
|  | wso2secvault.jks
|  | wso2carbon.jks
|
|_ wso2
 |___ Default (this can be used to combine several
 runtimes e.g in IoT)
 |   |___ bin
 |   |   

Re: [Architecture] Multiple runtime support for C5 based products

[Niranjan Karunanandham]

Hi,

On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi All,
>
> In c5 carbon-deployment we have a method to manually deploy artifacts
> where we only provide artifact's path and artifact type. This was no issue
> until 5.2.0-m3 since we only had a single deployment directory.
> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>
> But since we have 2 deployment directories with the new
> runtime architecture. So how should we handle this deployment?
> AFAIU options would be as follows
>
>1. Add a new API(method) to get the relevant deployment dir and deploy
>to that
>2. We have to prioritize a deployment directory (Server or runtime)
>and deploy only to the prioritized one
>3. Deploy to both deployment dirs
>
>
>
In the new deployment directory, each runtime will have a deployment
directory and there will be on outside. The runtime deployment will be for
wso2 artifacts. AFAIU with previous model (C4), the above method is used by
when a user uploads the artifact from a UI. Therefore IMO the default
method should deploy the artifact to the deployment directory outside the
runtime, i.e., /deployment.


> [1] - https://github.com/wso2/carbon-deployment/blob/master/
> components/org.wso2.carbon.deployment.engine/src/main/
> java/org/wso2/carbon/deployment/engine/DeploymentService.java#L43
>
> Thanks
> Thusitha
>
>
> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> Correction: Proposed directory structure needed to be change as below.
>> instead of having deployment directory per runtime, we will have only
>> deployment directory per server distribution. This deployment directory
>> contains custom deployable artifacts. So ideally there won't be any
>> artifact in default distribution.
>>
>> Though we have packaging all runtimes in one distribution. we are not
>> encouraging to run all runtime from the single pack. So we are going to
>> provide a script to exact runtime from the distribution pack.
>>
>> ServerHome
>>>|_ bin
>>>| |___ runtime1.sh
>>>| |___ runtime2.sh
>>>| |___ start-all.sh (start all the runtimes except
>>> default in separate JVMs)
>>>| |___ default.sh (start required runtimes in a
>>> single JVM)
>>>| |___ jartobundle.sh
>>>|
>>>|
>>>|_ deployment (This will contains custom deployable
>>> artifacts)
>>>| |___ uuf
>>>| |___ microservices
>>>|
>>>|_ lib
>>>|
>>>|_ conf
>>>|| runtime1
>>>|| | deployment.yaml
>>>|| | master-keys.yaml
>>>|| | secrets.properties
>>>|| | log4j2.xml
>>>|| | etc
>>>|| | |__
>>> pax-logging.properties
>>>|| | osgi
>>>||   |__ launch.properties
>>>||   |__ osgi-debug.options
>>>|| runtime2
>>>|  | deployment.yaml
>>>|  | master-keys.yaml
>>>|  | secrets.properties
>>>|  | log4j2.xml
>>>|  | etc
>>>|  | |__
>>> pax-logging.properties
>>>|  | osgi
>>>||__ launch.properties
>>>||__ osgi-debug.options
>>>|
>>>|_ resources
>>>|| security
>>>|  | wso2secvault.jks
>>>|  | wso2carbon.jks
>>>|
>>>|_ wso2
>>> |___ Default (this can be used to combine several
>>> runtimes e.g in IoT)
>>> |   |___ bin
>>> |   |   |_ carbon.sh
>>> |   |___ deployment
>>> |
>>> |___ Runtime1
>>> |   |___ bin
>>> |   |   |__ carbon.sh
>>> |   |___ deployment
>>> |
>>> |___ Runtime2
>>> |   |___ bin
>>> |   |   |_ carbon.sh
>>> |   |___ deployment
>>> |
>>> |___ lib (this will contains common jars)
>>>
>>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software 

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi All,

In c5 carbon-deployment we have a method to manually deploy artifacts where
we only provide artifact's path and artifact type. This was no issue until
5.2.0-m3 since we only had a single deployment directory.
public void deploy(String artifactPath, ArtifactType artifactType)[1]

But since we have 2 deployment directories with the new
runtime architecture. So how should we handle this deployment?
AFAIU options would be as follows

   1. Add a new API(method) to get the relevant deployment dir and deploy
   to that
   2. We have to prioritize a deployment directory (Server or runtime) and
   deploy only to the prioritized one
   3. Deploy to both deployment dirs


[1] -
https://github.com/wso2/carbon-deployment/blob/master/components/org.wso2.carbon.deployment.engine/src/main/java/org/wso2/carbon/deployment/engine/DeploymentService.java#L43

Thanks
Thusitha


On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu  wrote:

> Hi all,
>
> Correction: Proposed directory structure needed to be change as below.
> instead of having deployment directory per runtime, we will have only
> deployment directory per server distribution. This deployment directory
> contains custom deployable artifacts. So ideally there won't be any
> artifact in default distribution.
>
> Though we have packaging all runtimes in one distribution. we are not
> encouraging to run all runtime from the single pack. So we are going to
> provide a script to exact runtime from the distribution pack.
>
> ServerHome
>>|_ bin
>>| |___ runtime1.sh
>>| |___ runtime2.sh
>>| |___ start-all.sh (start all the runtimes except
>> default in separate JVMs)
>>| |___ default.sh (start required runtimes in a single
>> JVM)
>>| |___ jartobundle.sh
>>|
>>|
>>|_ deployment (This will contains custom deployable
>> artifacts)
>>| |___ uuf
>>| |___ microservices
>>|
>>|_ lib
>>|
>>|_ conf
>>|| runtime1
>>|| | deployment.yaml
>>|| | master-keys.yaml
>>|| | secrets.properties
>>|| | log4j2.xml
>>|| | etc
>>|| | |__ pax-logging.properties
>>|| | osgi
>>||   |__ launch.properties
>>||   |__ osgi-debug.options
>>|| runtime2
>>|  | deployment.yaml
>>|  | master-keys.yaml
>>|  | secrets.properties
>>|  | log4j2.xml
>>|  | etc
>>|  | |__ pax-logging.properties
>>|  | osgi
>>||__ launch.properties
>>||__ osgi-debug.options
>>|
>>|_ resources
>>|| security
>>|  | wso2secvault.jks
>>|  | wso2carbon.jks
>>|
>>|_ wso2
>> |___ Default (this can be used to combine several
>> runtimes e.g in IoT)
>> |   |___ bin
>> |   |   |_ carbon.sh
>> |   |___ deployment
>> |
>> |___ Runtime1
>> |   |___ bin
>> |   |   |__ carbon.sh
>> |   |___ deployment
>> |
>> |___ Runtime2
>> |   |___ bin
>> |   |   |_ carbon.sh
>> |   |___ deployment
>> |
>> |___ lib (this will contains common jars)
>>
>>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thusitha Dayaratne
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] Multiple runtime support for C5 based products

[Niranjan Karunanandham]

Hi,

On Tue, Apr 18, 2017 at 11:35 AM, Jayanga Dissanayake 
wrote:

> Hi Danesh,
>
> +1 for the suggested approach.
> It will allow keeping the /wso2 directory untouched by the users.
>
> And having different key stores for different runtimes is a valid
> use-case. Hence +1 for having secvault and transport keys stores with
> different names for each runtime in the /resources/security directory.
>
IMO we need not have separate jks for each runtime because in a default
pack this will be the same for all the runtime and we will be only
duplicating it. If the customer wants to have a separate one then they can
configure it in the deployment.yaml per runtime and point to a separate jks
(for securce vault and SSL, if required) for each runtime.


>
> Thanks,
> Jayanga.
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Tue, Apr 18, 2017 at 9:42 AM, Danesh Kuruppu  wrote:
>
>> Hi Thusitha,
>>
>>
>>> Shouldn't we move resource dir to  as well? AFAIU each
>>> runtime can have their own JKS. WDYT?
>>>
>>
>> Current idea is to have common jks files(one jks for securevault and one
>> for the transport) for all runtime in the distribution. Since this also can
>> change by the end user, we need to move out from the wso2 directory. If we
>> need to keep them per runtime, we can keep them in the same location with
>> different name and refer it from the runtime configuration file.
>>
>> WDYT?
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Regards,
Nira

-- 


*Niranjan Karunanandham*
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Multiple runtime support for C5 based products

[Jayanga Dissanayake]

Hi Danesh,

+1 for the suggested approach.
It will allow keeping the /wso2 directory untouched by the users.

And having different key stores for different runtimes is a valid use-case.
Hence +1 for having secvault and transport keys stores with different names
for each runtime in the /resources/security directory.

Thanks,
Jayanga.

*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: jaya...@wso2.com
mobile: +94772207259


On Tue, Apr 18, 2017 at 9:42 AM, Danesh Kuruppu  wrote:

> Hi Thusitha,
>
>
>> Shouldn't we move resource dir to  as well? AFAIU each
>> runtime can have their own JKS. WDYT?
>>
>
> Current idea is to have common jks files(one jks for securevault and one
> for the transport) for all runtime in the distribution. Since this also can
> change by the end user, we need to move out from the wso2 directory. If we
> need to keep them per runtime, we can keep them in the same location with
> different name and refer it from the runtime configuration file.
>
> WDYT?
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Multiple runtime support for C5 based products

[Danesh Kuruppu]

Hi Thusitha,


> Shouldn't we move resource dir to  as well? AFAIU each
> runtime can have their own JKS. WDYT?
>

Current idea is to have common jks files(one jks for securevault and one
for the transport) for all runtime in the distribution. Since this also can
change by the end user, we need to move out from the wso2 directory. If we
need to keep them per runtime, we can keep them in the same location with
different name and refer it from the runtime configuration file.

WDYT?

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi Danesh,

+1 for the suggestion.
Shouldn't we move resource dir to  as well? AFAIU each
runtime can have their own JKS. WDYT?

Thanks
Thusitha

On Mon, Apr 17, 2017 at 7:44 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> We need to do slight modification for the above directory structure. Since
> we are not allowing the end user to change any file inside wso2
> folder(ServerHome/wso2), we cannot keep the conf directory of each runtime
> inside wso2 directory. So we are planning to move out conf directory of
> each runtime from wso2 directory. Modified directory structure will look
> like below (changes from the above structure is highlighted in red colour),
>
> ServerHome
>|_ bin
>| |___ runtime1.sh
>| |___ runtime2.sh
>| |___ start-all.sh (start all the runtimes except
> default in separate JVMs)
>| |___ default.sh (start required runtimes in a single
> JVM)
>| |___ jartobundle.sh
>|
>|
>|_ deployment (This will contains custom deployable
> artifacts)
>| |___ runtime1
>| |   |___ uuf
>| |   |___ microservice
>| |
>| |___ runtime2
>| |___ uuf
>| |___ microservice
>|
>|
>|_ lib
>|
>|_ conf
>|| runtime1
>|| | deployment.yaml
>|| | master-keys.yaml
>|| | secrets.properties
>|| | log4j2.xml
>|| | etc
>|| | |__ pax-logging.properties
>|| | osgi
>||   |__ launch.properties
>||   |__ osgi-debug.options
>|| runtime2
>|  | deployment.yaml
>|  | master-keys.yaml
>|  | secrets.properties
>|  | log4j2.xml
>|  | etc
>|  | |__ pax-logging.properties
>|  | osgi
>||__ launch.properties
>||__ osgi-debug.options
>|
>|_ resources
>|| security
>|  | wso2secvault.jks
>|  | wso2carbon.jks
>|
>|_ wso2
> |___ Default (this can be used to combine several
> runtimes e.g in IoT)
> |   |___ bin
> |   |   |_ carbon.sh
> |   |___ deployment
> |
> |___ Runtime1
> |   |___ bin
> |   |   |__ carbon.sh
> |   |___ deployment
> |
> |___ Runtime2
> |   |___ bin
> |   |   |_ carbon.sh
> |   |___ deployment
> |
> |___ lib (this will contains common jars)
>
>
> We are currently working on this. Please share your thoughts / suggestions.
>
> Thanks
> Danesh
>
> On Thu, Mar 30, 2017 at 8:37 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi All,
>>
>> With the multiple runtime support, the directory structure of the
>> products would be change as follows.
>>
>> ServerHome
>>|_ bin
>>| |___ runtime1.sh
>>| |___ runtime2.sh
>>| |___ start-all.sh (start all the runtimes except
>> default in separate JVMs)
>>| |___ default.sh (start required runtimes in a single
>> JVM)
>>| |___ jartobundle.sh
>>|
>>|
>>|_ deployment (This will contains custom deployable
>> artifacts)
>>| |___ runtime1
>>| |   |___ uuf
>>| |   |___ microservice
>>| |
>>| |___ runtime2
>>| |___ uuf
>>| |___ microservice
>>|
>>|
>>|_ lib
>>|
>>|
>>|
>>|_ wso2
>> |___ Default (this can be used to combine sevral
>> runtimes e.g in IoT)
>> |   |___ bin
>> |

Re: [Architecture] Multiple runtime support for C5 based products

[Danesh Kuruppu]

Hi all,

We need to do slight modification for the above directory structure. Since
we are not allowing the end user to change any file inside wso2
folder(ServerHome/wso2), we cannot keep the conf directory of each runtime
inside wso2 directory. So we are planning to move out conf directory of
each runtime from wso2 directory. Modified directory structure will look
like below (changes from the above structure is highlighted in red colour),

ServerHome
   |_ bin
   | |___ runtime1.sh
   | |___ runtime2.sh
   | |___ start-all.sh (start all the runtimes except
default in separate JVMs)
   | |___ default.sh (start required runtimes in a single
JVM)
   | |___ jartobundle.sh
   |
   |
   |_ deployment (This will contains custom deployable
artifacts)
   | |___ runtime1
   | |   |___ uuf
   | |   |___ microservice
   | |
   | |___ runtime2
   | |___ uuf
   | |___ microservice
   |
   |
   |_ lib
   |
   |_ conf
   || runtime1
   || | deployment.yaml
   || | master-keys.yaml
   || | secrets.properties
   || | log4j2.xml
   || | etc
   || | |__ pax-logging.properties
   || | osgi
   ||   |__ launch.properties
   ||   |__ osgi-debug.options
   || runtime2
   |  | deployment.yaml
   |  | master-keys.yaml
   |  | secrets.properties
   |  | log4j2.xml
   |  | etc
   |  | |__ pax-logging.properties
   |  | osgi
   ||__ launch.properties
   ||__ osgi-debug.options
   |
   |_ resources
   || security
   |  | wso2secvault.jks
   |  | wso2carbon.jks
   |
   |_ wso2
|___ Default (this can be used to combine several
runtimes e.g in IoT)
|   |___ bin
|   |   |_ carbon.sh
|   |___ deployment
|
|___ Runtime1
|   |___ bin
|   |   |__ carbon.sh
|   |___ deployment
|
|___ Runtime2
|   |___ bin
|   |   |_ carbon.sh
|   |___ deployment
|
|___ lib (this will contains common jars)


We are currently working on this. Please share your thoughts / suggestions.

Thanks
Danesh

On Thu, Mar 30, 2017 at 8:37 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi All,
>
> With the multiple runtime support, the directory structure of the products
> would be change as follows.
>
> ServerHome
>|_ bin
>| |___ runtime1.sh
>| |___ runtime2.sh
>| |___ start-all.sh (start all the runtimes except
> default in separate JVMs)
>| |___ default.sh (start required runtimes in a single
> JVM)
>| |___ jartobundle.sh
>|
>|
>|_ deployment (This will contains custom deployable
> artifacts)
>| |___ runtime1
>| |   |___ uuf
>| |   |___ microservice
>| |
>| |___ runtime2
>| |___ uuf
>| |___ microservice
>|
>|
>|_ lib
>|
>|
>|
>|_ wso2
> |___ Default (this can be used to combine sevral
> runtimes e.g in IoT)
> |   |___ bin
> |   |   |_ carbon.sh
> |   |___ conf (runtime specific conf)
> |   |   |_ deployment.yaml
> |   |___ deployment
> |
> |___ Runtime1
> |   |___ bin
> |   |   |__ carbon.sh
> |   |___ conf 

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi All,

With the multiple runtime support, the directory structure of the products
would be change as follows.

ServerHome
   |_ bin
   | |___ runtime1.sh
   | |___ runtime2.sh
   | |___ start-all.sh (start all the runtimes except
default in separate JVMs)
   | |___ default.sh (start required runtimes in a single
JVM)
   | |___ jartobundle.sh
   |
   |
   |_ deployment (This will contains custom deployable
artifacts)
   | |___ runtime1
   | |   |___ uuf
   | |   |___ microservice
   | |
   | |___ runtime2
   | |___ uuf
   | |___ microservice
   |
   |
   |_ lib
   |
   |
   |
   |_ wso2
|___ Default (this can be used to combine sevral
runtimes e.g in IoT)
|   |___ bin
|   |   |_ carbon.sh
|   |___ conf (runtime specific conf)
|   |   |_ deployment.yaml
|   |___ deployment
|
|___ Runtime1
|   |___ bin
|   |   |__ carbon.sh
|   |___ conf (runtime specific conf)
|   |   |___ deployment.yaml
|   |___ deployment
|
|___ Runtime2
|   |___ bin
|   |   |_ carbon.sh
|   |___ conf
|   |   |_ deployment.yaml
|   |___ deployment
|
|___ lib (this will contains common jars)



   - Kernel runtime feature will provide the default carbon.sh startup
   script.
   At the moment kernel provides org.wso2.carbon.kernel.feature(kernel
   related stuffs), org.wso2.carbon.runtime.feature(OSGi runtime related jars)
   and org.wso2.carbon.touchpoint.feature. With the new restructure there will
   be 4 features instead of 3. We will splitting
   the org.wso2.carbon.kernel.feature to 2 features based on runtime and
   standalone. There we will also rename org.wso2.carbon.runtime.feature would
   be renamed to something like org.wso2.carbon.osgi.feature which will
   contain all the equinox OSGi stuffs.

   - It will set the runtime.home based on the directory structure
   Default carbon.sh will determine the runtime based on the place the
   script resides and it will set the system property to that. Product teams
   don't have to modify this script. Product team can create their own script
   and put in ServerHome/bin which can be used as a linker to specific
   runtime/bin/carbon.sh. So product-specific properties can be set from that
   script and default carbon.sh file will make sure those properties will be
   set when the runtime starts.

   - Product team have to create start-all.sh or other scripts which will
   be in *ServerHome/bin*
   If a product contains multiple runtimes, then product team have to
   create a script which is responsible for starting all the available
   runtimes in separate JVMs

   - Customers will not modify anything on the wso2 folder. (Unless configs
   in particular runtime)
   The intention of naming this directory as wso2 is that this will contain
   the wso2 specific stuff and users shouldn't modify this.

   - If they want to customize something, still they don't change default
   apps inside wso2 directory
   e.g. if someone wanna customize the theme or some ui components, still
   they will not touch default artifacts in wso2 directory but
   ServerHome/deployment

   - This same structure would be maintained in products which will release
   on 4.4.x e.g. IoT


Thanks
Thusitha

On Thu, Mar 30, 2017 at 6:15 PM, Jayanga Dissanayake 
wrote:

> Hi Abimaran,
>
> On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan 
> wrote:
>
>> Hi Jayanga,
>>
>> On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake 
>> wrote:
>>
>>> Hi Abimaran,
>>>
>>> The basic idea is, if you had (store, publisher, key-manager, gateway)
>>> profiles on the previous model. In new Runtime model, you will have
>>> separate runtimes for each of those.
>>>
>>> It is somewhat similar to what was there as profiles, but different in
>>> packaging(folder) structure, deployment (each runtime will have specific
>>> deployment artifacts), etc.
>>>
>>
>> API Manager won't require multiple profiles/runtimes, reason is, earlier,
>> we has a profile called Key Manager, for C5 APIM, it will be vannila IS
>> pack, Gateway will be vannila EI, and there will be Analytics whch inclues
>> TM feaure as a 

Re: [Architecture] Multiple runtime support for C5 based products

[Jayanga Dissanayake]

Hi Abimaran,

On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan 
wrote:

> Hi Jayanga,
>
> On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake 
> wrote:
>
>> Hi Abimaran,
>>
>> The basic idea is, if you had (store, publisher, key-manager, gateway)
>> profiles on the previous model. In new Runtime model, you will have
>> separate runtimes for each of those.
>>
>> It is somewhat similar to what was there as profiles, but different in
>> packaging(folder) structure, deployment (each runtime will have specific
>> deployment artifacts), etc.
>>
>
> API Manager won't require multiple profiles/runtimes, reason is, earlier,
> we has a profile called Key Manager, for C5 APIM, it will be vannila IS
> pack, Gateway will be vannila EI, and there will be Analytics whch inclues
> TM feaure as a seperate product and a Broker.
>
> I guess, API Manager won't need this multiple runtime concept for C5.
>

​Packing an entire products inside another product is not recommended in C5
way.
You have to use the runtimes. EI6.0 has already done that and IOT is now
following the same approach.
Please check how EI has used the runtimes.

>
>> Thanks,
>> Jayanga.
>>
>>
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>> On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan 
>> wrote:
>>
>>> Hi Danesh,
>>>
>>> By runtime, do you mean profile of the same product? In C4 based APIM,
>>> we had multiple profiles (Store, Publisher, Key Manager, Gateway, Traffic
>>> manager) but with C5, there will be multiple products shipped into one
>>> package like API Manager, IS, EI, etc.
>>>
>>> Is this applicable only for profiles of the same product?
>>>
>>> On Thu, Mar 30, 2017 at 2:30 PM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
 Hi Thusitha,

 On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
 thusit...@wso2.com> wrote:

> Since there will be multiple runtimes in a single product we need to
> get the information such as current runtime name/path etc..
>
> According to the EI structure, the startup script for each runtime
> resides in the <*ServerHome>/wso2/{runtime}/bin *directory. And there
> is a corresponding script at <*ServerHome>/bin* which will call the
> particular runtime's startup script.  Do we follow the same structure or 
> we
> put all the startup scripts in the <*ServerHome>/bin* directory?
>
> IMHO We have following options
>
> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin
> *and linker script in <*ServerHome>/bin *(Similar to EI structure)
>
>- Kernel feature can set the runtime.home based om the script
>location (which will be required for config resolver and etc..) from 
> the
>carbon.sh so product teams don't have to change the default carbon.sh
>
> +1 for this option. In this way other products need not maintain
 runtime specific carbon.sh file. This should come along with the Kernel
 runtime specific feature. In-addition to this, it would be nice if the
 startall script in the /bin finds the runtimes dynamically
 without having specify it in the script. IMO we can get all the runtime
 which has a carbon.sh file inside its bin directory  or getting all the
 folder names in /wso2 excluding lib folder.


>
>-
>
> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>
>- We can assume the startup script name is equivalent to runtime
>name. apim.sh and set that as runtime.home.
>- Product teams have to rename the default carbon.sh file to
>relevant runtime name
>
> *Option 3 *- Can be any of above 2 options
>
>- Default carbon.sh will set the runtime.home to "default" and
>product team have to edit default script and change the runtime.home 
> value
>in product level.
>
> WDYT?
>
> Thanks
> Thusitha
>
>
>
> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe 
> wrote:
>
>> Hi Danesh,
>>
>> Please find some comments in-line.
>>
>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu 
>> wrote:
>>
>>> Hi all,
>>>
>>> In C5 based products, we can have multiple runtimes in the product
>>> package. For each runtime, there will be configuration(deployment.yaml),
>>> securevault, execution scripts(carbon.sh etc), logs, deployment specific
>>> only for that runtime. resources(wso2carbon.jks) and lib directory will 
>>> be
>>> common to every runtime and those are placed at top level.
>>> So the directory structure of the basic distribution will be
>>> something like,

Re: [Architecture] Multiple runtime support for C5 based products

[Abimaran Kugathasan]

Hi Jayanga,

On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake 
wrote:

> Hi Abimaran,
>
> The basic idea is, if you had (store, publisher, key-manager, gateway)
> profiles on the previous model. In new Runtime model, you will have
> separate runtimes for each of those.
>
> It is somewhat similar to what was there as profiles, but different in
> packaging(folder) structure, deployment (each runtime will have specific
> deployment artifacts), etc.
>

API Manager won't require multiple profiles/runtimes, reason is, earlier,
we has a profile called Key Manager, for C5 APIM, it will be vannila IS
pack, Gateway will be vannila EI, and there will be Analytics whch inclues
TM feaure as a seperate product and a Broker.

I guess, API Manager won't need this multiple runtime concept for C5.


>
> Thanks,
> Jayanga.
>
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan 
> wrote:
>
>> Hi Danesh,
>>
>> By runtime, do you mean profile of the same product? In C4 based APIM, we
>> had multiple profiles (Store, Publisher, Key Manager, Gateway, Traffic
>> manager) but with C5, there will be multiple products shipped into one
>> package like API Manager, IS, EI, etc.
>>
>> Is this applicable only for profiles of the same product?
>>
>> On Thu, Mar 30, 2017 at 2:30 PM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Thusitha,
>>>
>>> On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Since there will be multiple runtimes in a single product we need to
 get the information such as current runtime name/path etc..

 According to the EI structure, the startup script for each runtime
 resides in the <*ServerHome>/wso2/{runtime}/bin *directory. And there
 is a corresponding script at <*ServerHome>/bin* which will call the
 particular runtime's startup script.  Do we follow the same structure or we
 put all the startup scripts in the <*ServerHome>/bin* directory?

 IMHO We have following options

 *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin
 *and linker script in <*ServerHome>/bin *(Similar to EI structure)

- Kernel feature can set the runtime.home based om the script
location (which will be required for config resolver and etc..) from the
carbon.sh so product teams don't have to change the default carbon.sh

 +1 for this option. In this way other products need not maintain
>>> runtime specific carbon.sh file. This should come along with the Kernel
>>> runtime specific feature. In-addition to this, it would be nice if the
>>> startall script in the /bin finds the runtimes dynamically
>>> without having specify it in the script. IMO we can get all the runtime
>>> which has a carbon.sh file inside its bin directory  or getting all the
>>> folder names in /wso2 excluding lib folder.
>>>
>>>

-

 *Option 2* - All startup scripts are in <*ServerHome>/bin*

- We can assume the startup script name is equivalent to runtime
name. apim.sh and set that as runtime.home.
- Product teams have to rename the default carbon.sh file to
relevant runtime name

 *Option 3 *- Can be any of above 2 options

- Default carbon.sh will set the runtime.home to "default" and
product team have to edit default script and change the runtime.home 
 value
in product level.

 WDYT?

 Thanks
 Thusitha



 On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe 
 wrote:

> Hi Danesh,
>
> Please find some comments in-line.
>
> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu 
> wrote:
>
>> Hi all,
>>
>> In C5 based products, we can have multiple runtimes in the product
>> package. For each runtime, there will be configuration(deployment.yaml),
>> securevault, execution scripts(carbon.sh etc), logs, deployment specific
>> only for that runtime. resources(wso2carbon.jks) and lib directory will 
>> be
>> common to every runtime and those are placed at top level.
>> So the directory structure of the basic distribution will be
>> something like,
>>
>>
>
> What's the difference between top-level conf/ folder and the conf/
> folders under runtimes?
>
> And, how will this new directory structure affect the p2.inf
> instructions? In the p2.inf, we define from/where to the config files.
>
>
>
>> wso2-carbon
>>> |-- bin
>>> |-- resources
>>> |-- lib
>>> |-- conf
>>> |-- wso2
>>> |-- 
>>> |-- bin
>>> |-- logs
>>> |-- conf
>>> 

Re: [Architecture] Multiple runtime support for C5 based products

[Jayanga Dissanayake]

Hi Abimaran,

The basic idea is, if you had (store, publisher, key-manager, gateway)
profiles on the previous model. In new Runtime model, you will have
separate runtimes for each of those.

It is somewhat similar to what was there as profiles, but different in
packaging(folder) structure, deployment (each runtime will have specific
deployment artifacts), etc.

Thanks,
Jayanga.


*Jayanga Dissanayake*
Associate Technical Lead
WSO2 Inc. - http://wso2.com/
lean . enterprise . middleware
email: jaya...@wso2.com
mobile: +94772207259


On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan 
wrote:

> Hi Danesh,
>
> By runtime, do you mean profile of the same product? In C4 based APIM, we
> had multiple profiles (Store, Publisher, Key Manager, Gateway, Traffic
> manager) but with C5, there will be multiple products shipped into one
> package like API Manager, IS, EI, etc.
>
> Is this applicable only for profiles of the same product?
>
> On Thu, Mar 30, 2017 at 2:30 PM, Niranjan Karunanandham  > wrote:
>
>> Hi Thusitha,
>>
>> On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Since there will be multiple runtimes in a single product we need to get
>>> the information such as current runtime name/path etc..
>>>
>>> According to the EI structure, the startup script for each runtime
>>> resides in the <*ServerHome>/wso2/{runtime}/bin *directory. And there
>>> is a corresponding script at <*ServerHome>/bin* which will call the
>>> particular runtime's startup script.  Do we follow the same structure or we
>>> put all the startup scripts in the <*ServerHome>/bin* directory?
>>>
>>> IMHO We have following options
>>>
>>> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin
>>> *and linker script in <*ServerHome>/bin *(Similar to EI structure)
>>>
>>>- Kernel feature can set the runtime.home based om the script
>>>location (which will be required for config resolver and etc..) from the
>>>carbon.sh so product teams don't have to change the default carbon.sh
>>>
>>> +1 for this option. In this way other products need not maintain runtime
>> specific carbon.sh file. This should come along with the Kernel runtime
>> specific feature. In-addition to this, it would be nice if the startall
>> script in the /bin finds the runtimes dynamically without
>> having specify it in the script. IMO we can get all the runtime which has a
>> carbon.sh file inside its bin directory  or getting all the folder names in
>> /wso2 excluding lib folder.
>>
>>
>>>
>>>-
>>>
>>> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>>>
>>>- We can assume the startup script name is equivalent to runtime
>>>name. apim.sh and set that as runtime.home.
>>>- Product teams have to rename the default carbon.sh file to
>>>relevant runtime name
>>>
>>> *Option 3 *- Can be any of above 2 options
>>>
>>>- Default carbon.sh will set the runtime.home to "default" and
>>>product team have to edit default script and change the runtime.home 
>>> value
>>>in product level.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> Thusitha
>>>
>>>
>>>
>>> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe 
>>> wrote:
>>>
 Hi Danesh,

 Please find some comments in-line.

 On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> In C5 based products, we can have multiple runtimes in the product
> package. For each runtime, there will be configuration(deployment.yaml),
> securevault, execution scripts(carbon.sh etc), logs, deployment specific
> only for that runtime. resources(wso2carbon.jks) and lib directory will be
> common to every runtime and those are placed at top level.
> So the directory structure of the basic distribution will be something
> like,
>
>

 What's the difference between top-level conf/ folder and the conf/
 folders under runtimes?

 And, how will this new directory structure affect the p2.inf
 instructions? In the p2.inf, we define from/where to the config files.



> wso2-carbon
>> |-- bin
>> |-- resources
>> |-- lib
>> |-- conf
>> |-- wso2
>> |-- 
>> |-- bin
>> |-- logs
>> |-- conf
>> |-- deployment.yaml
>> |-- log4j2.xml
>> |-- security
>> |-- secure-vault.yaml
>> |-- secrets.properties
>> |-- deployment
>> |-- 
>> 
>> |-- 
>> |-- lib
>> |-- features
>> |-- p2
>> |-- plugins
>>
>
>
>
> Each runtime will be started as different processes/JVM and for the
> distributed setup, we are going to provide a tool to run each runtime in
> different nodes/containers.
>

 Does this mean we can run multiple runtimes at the same time from a
 given product instance?

 Thanks,
 KasunG


> We are 

Re: [Architecture] Multiple runtime support for C5 based products

[Abimaran Kugathasan]

Hi Danesh,

By runtime, do you mean profile of the same product? In C4 based APIM, we
had multiple profiles (Store, Publisher, Key Manager, Gateway, Traffic
manager) but with C5, there will be multiple products shipped into one
package like API Manager, IS, EI, etc.

Is this applicable only for profiles of the same product?

On Thu, Mar 30, 2017 at 2:30 PM, Niranjan Karunanandham 
wrote:

> Hi Thusitha,
>
> On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Since there will be multiple runtimes in a single product we need to get
>> the information such as current runtime name/path etc..
>>
>> According to the EI structure, the startup script for each runtime
>> resides in the <*ServerHome>/wso2/{runtime}/bin *directory. And there is
>> a corresponding script at <*ServerHome>/bin* which will call the
>> particular runtime's startup script.  Do we follow the same structure or we
>> put all the startup scripts in the <*ServerHome>/bin* directory?
>>
>> IMHO We have following options
>>
>> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin
>> *and linker script in <*ServerHome>/bin *(Similar to EI structure)
>>
>>- Kernel feature can set the runtime.home based om the script
>>location (which will be required for config resolver and etc..) from the
>>carbon.sh so product teams don't have to change the default carbon.sh
>>
>> +1 for this option. In this way other products need not maintain runtime
> specific carbon.sh file. This should come along with the Kernel runtime
> specific feature. In-addition to this, it would be nice if the startall
> script in the /bin finds the runtimes dynamically without
> having specify it in the script. IMO we can get all the runtime which has a
> carbon.sh file inside its bin directory  or getting all the folder names in
> /wso2 excluding lib folder.
>
>
>>
>>-
>>
>> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>>
>>- We can assume the startup script name is equivalent to runtime
>>name. apim.sh and set that as runtime.home.
>>- Product teams have to rename the default carbon.sh file to
>>relevant runtime name
>>
>> *Option 3 *- Can be any of above 2 options
>>
>>- Default carbon.sh will set the runtime.home to "default" and
>>product team have to edit default script and change the runtime.home value
>>in product level.
>>
>> WDYT?
>>
>> Thanks
>> Thusitha
>>
>>
>>
>> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe 
>> wrote:
>>
>>> Hi Danesh,
>>>
>>> Please find some comments in-line.
>>>
>>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu  wrote:
>>>
 Hi all,

 In C5 based products, we can have multiple runtimes in the product
 package. For each runtime, there will be configuration(deployment.yaml),
 securevault, execution scripts(carbon.sh etc), logs, deployment specific
 only for that runtime. resources(wso2carbon.jks) and lib directory will be
 common to every runtime and those are placed at top level.
 So the directory structure of the basic distribution will be something
 like,


>>>
>>> What's the difference between top-level conf/ folder and the conf/
>>> folders under runtimes?
>>>
>>> And, how will this new directory structure affect the p2.inf
>>> instructions? In the p2.inf, we define from/where to the config files.
>>>
>>>
>>>
 wso2-carbon
> |-- bin
> |-- resources
> |-- lib
> |-- conf
> |-- wso2
> |-- 
> |-- bin
> |-- logs
> |-- conf
> |-- deployment.yaml
> |-- log4j2.xml
> |-- security
> |-- secure-vault.yaml
> |-- secrets.properties
> |-- deployment
> |-- 
> 
> |-- 
> |-- lib
> |-- features
> |-- p2
> |-- plugins
>



 Each runtime will be started as different processes/JVM and for the
 distributed setup, we are going to provide a tool to run each runtime in
 different nodes/containers.

>>>
>>> Does this mean we can run multiple runtimes at the same time from a
>>> given product instance?
>>>
>>> Thanks,
>>> KasunG
>>>
>>>
 We are currently working on this. Please share your thoughts /
 suggestions.

 Thanks
 --

 *Danesh Kuruppu*
 Senior Software Engineer | WSO2

 Email: dan...@wso2.com
 Mobile: +94 (77) 1690552 <077%20169%200552>
 Web: WSO2 Inc 


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


>>>
>>>
>>> --
>>>
>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>> email: kasung AT spamfree wso2.com
>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>> blog: http://kasunbg.org
>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>>
>>>
>>> 

Re: [Architecture] Multiple runtime support for C5 based products

[Niranjan Karunanandham]

Hi Thusitha,

On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Since there will be multiple runtimes in a single product we need to get
> the information such as current runtime name/path etc..
>
> According to the EI structure, the startup script for each runtime resides
> in the <*ServerHome>/wso2/{runtime}/bin *directory. And there is a
> corresponding script at <*ServerHome>/bin* which will call the particular
> runtime's startup script.  Do we follow the same structure or we put all
> the startup scripts in the <*ServerHome>/bin* directory?
>
> IMHO We have following options
>
> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin *and
> linker script in <*ServerHome>/bin *(Similar to EI structure)
>
>- Kernel feature can set the runtime.home based om the script location
>(which will be required for config resolver and etc..) from the carbon.sh
>so product teams don't have to change the default carbon.sh
>
> +1 for this option. In this way other products need not maintain runtime
specific carbon.sh file. This should come along with the Kernel runtime
specific feature. In-addition to this, it would be nice if the startall
script in the /bin finds the runtimes dynamically without
having specify it in the script. IMO we can get all the runtime which has a
carbon.sh file inside its bin directory  or getting all the folder names in
/wso2 excluding lib folder.


>
>-
>
> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>
>- We can assume the startup script name is equivalent to runtime name.
>apim.sh and set that as runtime.home.
>- Product teams have to rename the default carbon.sh file to
>relevant runtime name
>
> *Option 3 *- Can be any of above 2 options
>
>- Default carbon.sh will set the runtime.home to "default" and product
>team have to edit default script and change the runtime.home value in
>product level.
>
> WDYT?
>
> Thanks
> Thusitha
>
>
>
> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe  wrote:
>
>> Hi Danesh,
>>
>> Please find some comments in-line.
>>
>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu  wrote:
>>
>>> Hi all,
>>>
>>> In C5 based products, we can have multiple runtimes in the product
>>> package. For each runtime, there will be configuration(deployment.yaml),
>>> securevault, execution scripts(carbon.sh etc), logs, deployment specific
>>> only for that runtime. resources(wso2carbon.jks) and lib directory will be
>>> common to every runtime and those are placed at top level.
>>> So the directory structure of the basic distribution will be something
>>> like,
>>>
>>>
>>
>> What's the difference between top-level conf/ folder and the conf/
>> folders under runtimes?
>>
>> And, how will this new directory structure affect the p2.inf
>> instructions? In the p2.inf, we define from/where to the config files.
>>
>>
>>
>>> wso2-carbon
 |-- bin
 |-- resources
 |-- lib
 |-- conf
 |-- wso2
 |-- 
 |-- bin
 |-- logs
 |-- conf
 |-- deployment.yaml
 |-- log4j2.xml
 |-- security
 |-- secure-vault.yaml
 |-- secrets.properties
 |-- deployment
 |-- 
 
 |-- 
 |-- lib
 |-- features
 |-- p2
 |-- plugins

>>>
>>>
>>>
>>> Each runtime will be started as different processes/JVM and for the
>>> distributed setup, we are going to provide a tool to run each runtime in
>>> different nodes/containers.
>>>
>>
>> Does this mean we can run multiple runtimes at the same time from a given
>> product instance?
>>
>> Thanks,
>> KasunG
>>
>>
>>> We are currently working on this. Please share your thoughts /
>>> suggestions.
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: dan...@wso2.com
>>> Mobile: +94 (77) 1690552 <077%20169%200552>
>>> Web: WSO2 Inc 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thusitha Dayaratne
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809 <+94%2071%20275%206809>
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
> 
>
>
Regards,
Nira

-- 


*Niranjan Karunanandham*
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
___
Architecture mailing list

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Since there will be multiple runtimes in a single product we need to get
the information such as current runtime name/path etc..

According to the EI structure, the startup script for each runtime resides
in the <*ServerHome>/wso2/{runtime}/bin *directory. And there is a
corresponding script at <*ServerHome>/bin* which will call the particular
runtime's startup script.  Do we follow the same structure or we put all
the startup scripts in the <*ServerHome>/bin* directory?

IMHO We have following options

*Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin *and
linker script in <*ServerHome>/bin *(Similar to EI structure)

   - Kernel feature can set the runtime.home based om the script location
   (which will be required for config resolver and etc..) from the carbon.sh
   so product teams don't have to change the default carbon.sh

*Option 2* - All startup scripts are in <*ServerHome>/bin*

   - We can assume the startup script name is equivalent to runtime name.
   apim.sh and set that as runtime.home.
   - Product teams have to rename the default carbon.sh file to
   relevant runtime name

*Option 3 *- Can be any of above 2 options

   - Default carbon.sh will set the runtime.home to "default" and product
   team have to edit default script and change the runtime.home value in
   product level.

WDYT?

Thanks
Thusitha



On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe  wrote:

> Hi Danesh,
>
> Please find some comments in-line.
>
> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> In C5 based products, we can have multiple runtimes in the product
>> package. For each runtime, there will be configuration(deployment.yaml),
>> securevault, execution scripts(carbon.sh etc), logs, deployment specific
>> only for that runtime. resources(wso2carbon.jks) and lib directory will be
>> common to every runtime and those are placed at top level.
>> So the directory structure of the basic distribution will be something
>> like,
>>
>>
>
> What's the difference between top-level conf/ folder and the conf/ folders
> under runtimes?
>
> And, how will this new directory structure affect the p2.inf instructions?
> In the p2.inf, we define from/where to the config files.
>
>
>
>> wso2-carbon
>>> |-- bin
>>> |-- resources
>>> |-- lib
>>> |-- conf
>>> |-- wso2
>>> |-- 
>>> |-- bin
>>> |-- logs
>>> |-- conf
>>> |-- deployment.yaml
>>> |-- log4j2.xml
>>> |-- security
>>> |-- secure-vault.yaml
>>> |-- secrets.properties
>>> |-- deployment
>>> |-- 
>>> 
>>> |-- 
>>> |-- lib
>>> |-- features
>>> |-- p2
>>> |-- plugins
>>>
>>
>>
>>
>> Each runtime will be started as different processes/JVM and for the
>> distributed setup, we are going to provide a tool to run each runtime in
>> different nodes/containers.
>>
>
> Does this mean we can run multiple runtimes at the same time from a given
> product instance?
>
> Thanks,
> KasunG
>
>
>> We are currently working on this. Please share your thoughts /
>> suggestions.
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552 <077%20169%200552>
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thusitha Dayaratne
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

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

Re: [Architecture] Multiple runtime support for C5 based products

[KasunG Gajasinghe]

Hi Danesh,

Please find some comments in-line.

On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu  wrote:

> Hi all,
>
> In C5 based products, we can have multiple runtimes in the product
> package. For each runtime, there will be configuration(deployment.yaml),
> securevault, execution scripts(carbon.sh etc), logs, deployment specific
> only for that runtime. resources(wso2carbon.jks) and lib directory will be
> common to every runtime and those are placed at top level.
> So the directory structure of the basic distribution will be something
> like,
>
>

What's the difference between top-level conf/ folder and the conf/ folders
under runtimes?

And, how will this new directory structure affect the p2.inf instructions?
In the p2.inf, we define from/where to the config files.



> wso2-carbon
>> |-- bin
>> |-- resources
>> |-- lib
>> |-- conf
>> |-- wso2
>> |-- 
>> |-- bin
>> |-- logs
>> |-- conf
>> |-- deployment.yaml
>> |-- log4j2.xml
>> |-- security
>> |-- secure-vault.yaml
>> |-- secrets.properties
>> |-- deployment
>> |-- 
>> 
>> |-- 
>> |-- lib
>> |-- features
>> |-- p2
>> |-- plugins
>>
>
>
>
> Each runtime will be started as different processes/JVM and for the
> distributed setup, we are going to provide a tool to run each runtime in
> different nodes/containers.
>

Does this mean we can run multiple runtimes at the same time from a given
product instance?

Thanks,
KasunG


> We are currently working on this. Please share your thoughts / suggestions.
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <077%20169%200552>
> Web: WSO2 Inc 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
phone: +1 650-745-4499, 77 678 0813
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture