Multiple runtime support for C5 based products

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Multiple runtime support for C5 based products

Danesh Kuruppu
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,

wso2-carbon
|-- bin
|-- resources
|-- lib
|-- conf
|-- wso2
|-- <runtime1>
|-- bin
|-- logs
|-- conf
|-- deployment.yaml
|-- log4j2.xml
|-- security
|-- secure-vault.yaml
|-- secrets.properties
|-- deployment
|-- <runtime2>
----
|-- <runtime3>
|-- 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.

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

Thanks
--

Danesh Kuruppu

Senior Software Engineer | WSO2

Email: [hidden email]

Mobile: +94 (77) 1690552
Web: WSO2 Inc



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Multiple runtime support for C5 based products

Kasun Gajasinghe
Hi Danesh,

Please find some comments in-line.

On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
|-- <runtime1>
|-- bin
|-- logs
|-- conf
|-- deployment.yaml
|-- log4j2.xml
|-- security
|-- secure-vault.yaml
|-- secrets.properties
|-- deployment
|-- <runtime2>
----
|-- <runtime3>
|-- 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: [hidden email]

Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
Web: WSO2 Inc



_______________________________________________
Architecture mailing list
[hidden email]
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Kasun Gajasinghe
Software Engineer; WSO2 Inc.
http://kasunbg.org
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
    Hi Danesh,

    Please find some comments in-line.

    On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
    |-- <runtime1>
    |-- bin
    |-- logs
    |-- conf
    |-- deployment.yaml
    |-- log4j2.xml
    |-- security
    |-- secure-vault.yaml
    |-- secrets.properties
    |-- deployment
    |-- <runtime2>
    ----
    |-- <runtime3>
    |-- 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: [hidden email]

    Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
    Web: WSO2 Inc



    _______________________________________________
    Architecture mailing list
    [hidden email]
    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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
     

    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

    Mobile  +94712756809



    _______________________________________________
    Architecture mailing list
    [hidden email]
    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
    Reply | Threaded
    Open this post in threaded view
    |

    Re: Multiple runtime support for C5 based products

    Niranjan Karunanandham
    Hi Thusitha,

    On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
      Hi Danesh,

      Please find some comments in-line.

      On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
      |-- <runtime1>
      |-- bin
      |-- logs
      |-- conf
      |-- deployment.yaml
      |-- log4j2.xml
      |-- security
      |-- secure-vault.yaml
      |-- secrets.properties
      |-- deployment
      |-- <runtime2>
      ----
      |-- <runtime3>
      |-- 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: [hidden email]

      Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
      Web: WSO2 Inc



      _______________________________________________
      Architecture mailing list
      [hidden email]
      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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
       

      _______________________________________________
      Architecture mailing list
      [hidden email]
      https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

      Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



      Regards,
      Nira

      --

      Niranjan Karunanandham
      Associate Technical Lead - WSO2 Inc.
      WSO2 Inc.: http://www.wso2.com


      _______________________________________________
      Architecture mailing list
      [hidden email]
      https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
      Reply | Threaded
      Open this post in threaded view
      |

      Re: 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 <[hidden email]> wrote:
      Hi Thusitha,

      On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
        Hi Danesh,

        Please find some comments in-line.

        On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
        |-- <runtime1>
        |-- bin
        |-- logs
        |-- conf
        |-- deployment.yaml
        |-- log4j2.xml
        |-- security
        |-- secure-vault.yaml
        |-- secrets.properties
        |-- deployment
        |-- <runtime2>
        ----
        |-- <runtime3>
        |-- 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: [hidden email]

        Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
        Web: WSO2 Inc



        _______________________________________________
        Architecture mailing list
        [hidden email]
        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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
         

        _______________________________________________
        Architecture mailing list
        [hidden email]
        https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

        Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



        Regards,
        Nira

        --

        Niranjan Karunanandham
        Associate Technical Lead - WSO2 Inc.
        WSO2 Inc.: http://www.wso2.com


        _______________________________________________
        Architecture mailing list
        [hidden email]
        https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




        --
        Thanks
        Abimaran Kugathasan
        Senior Software Engineer - API Technologies

        Mobile : +94 773922820

            


        _______________________________________________
        Architecture mailing list
        [hidden email]
        https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
        Reply | Threaded
        Open this post in threaded view
        |

        Re: 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: [hidden email]
        mobile: +94772207259



        On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
        Hi Thusitha,

        On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
          Hi Danesh,

          Please find some comments in-line.

          On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
          |-- <runtime1>
          |-- bin
          |-- logs
          |-- conf
          |-- deployment.yaml
          |-- log4j2.xml
          |-- security
          |-- secure-vault.yaml
          |-- secrets.properties
          |-- deployment
          |-- <runtime2>
          ----
          |-- <runtime3>
          |-- 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: [hidden email]

          Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
          Web: WSO2 Inc



          _______________________________________________
          Architecture mailing list
          [hidden email]
          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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
           

          _______________________________________________
          Architecture mailing list
          [hidden email]
          https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

          Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



          Regards,
          Nira

          --

          Niranjan Karunanandham
          Associate Technical Lead - WSO2 Inc.
          WSO2 Inc.: http://www.wso2.com


          _______________________________________________
          Architecture mailing list
          [hidden email]
          https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




          --
          Thanks
          Abimaran Kugathasan
          Senior Software Engineer - API Technologies

          Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

              


          _______________________________________________
          Architecture mailing list
          [hidden email]
          https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



          _______________________________________________
          Architecture mailing list
          [hidden email]
          https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
          Reply | Threaded
          Open this post in threaded view
          |

          Re: Multiple runtime support for C5 based products

          Abimaran Kugathasan
          Hi Jayanga,

          On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
          mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



          On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
          Hi Thusitha,

          On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
            Hi Danesh,

            Please find some comments in-line.

            On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
            |-- <runtime1>
            |-- bin
            |-- logs
            |-- conf
            |-- deployment.yaml
            |-- log4j2.xml
            |-- security
            |-- secure-vault.yaml
            |-- secrets.properties
            |-- deployment
            |-- <runtime2>
            ----
            |-- <runtime3>
            |-- 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: [hidden email]

            Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
            Web: WSO2 Inc



            _______________________________________________
            Architecture mailing list
            [hidden email]
            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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
             

            _______________________________________________
            Architecture mailing list
            [hidden email]
            https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

            Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



            Regards,
            Nira

            --

            Niranjan Karunanandham
            Associate Technical Lead - WSO2 Inc.
            WSO2 Inc.: http://www.wso2.com


            _______________________________________________
            Architecture mailing list
            [hidden email]
            https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




            --
            Thanks
            Abimaran Kugathasan
            Senior Software Engineer - API Technologies

            Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                


            _______________________________________________
            Architecture mailing list
            [hidden email]
            https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





            --
            Thanks
            Abimaran Kugathasan
            Senior Software Engineer - API Technologies

            Mobile : +94 773922820

                


            _______________________________________________
            Architecture mailing list
            [hidden email]
            https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
            Reply | Threaded
            Open this post in threaded view
            |

            Re: Multiple runtime support for C5 based products

            Jayanga Dissanayake
            Hi Abimaran,

            On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <[hidden email]> wrote:
            Hi Jayanga,

            On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
            mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



            On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
            Hi Thusitha,

            On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
              Hi Danesh,

              Please find some comments in-line.

              On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
              |-- <runtime1>
              |-- bin
              |-- logs
              |-- conf
              |-- deployment.yaml
              |-- log4j2.xml
              |-- security
              |-- secure-vault.yaml
              |-- secrets.properties
              |-- deployment
              |-- <runtime2>
              ----
              |-- <runtime3>
              |-- 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: [hidden email]

              Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
              Web: WSO2 Inc



              _______________________________________________
              Architecture mailing list
              [hidden email]
              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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
               

              _______________________________________________
              Architecture mailing list
              [hidden email]
              https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

              Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



              Regards,
              Nira

              --

              Niranjan Karunanandham
              Associate Technical Lead - WSO2 Inc.
              WSO2 Inc.: http://www.wso2.com


              _______________________________________________
              Architecture mailing list
              [hidden email]
              https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




              --
              Thanks
              Abimaran Kugathasan
              Senior Software Engineer - API Technologies

              Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                  


              _______________________________________________
              Architecture mailing list
              [hidden email]
              https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





              --
              Thanks
              Abimaran Kugathasan
              Senior Software Engineer - API Technologies

              Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                  



              Jayanga Dissanayake
              Associate Technical Lead
              WSO2 Inc. - http://wso2.com/
              lean . enterprise . middleware
              email: [hidden email]
              mobile: +94772207259



              _______________________________________________
              Architecture mailing list
              [hidden email]
              https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
              Reply | Threaded
              Open this post in threaded view
              |

              Re: 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 <[hidden email]> wrote:
              Hi Abimaran,

              On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <[hidden email]> wrote:
              Hi Jayanga,

              On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
              mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



              On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
              Hi Thusitha,

              On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
                Hi Danesh,

                Please find some comments in-line.

                On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
                |-- <runtime1>
                |-- bin
                |-- logs
                |-- conf
                |-- deployment.yaml
                |-- log4j2.xml
                |-- security
                |-- secure-vault.yaml
                |-- secrets.properties
                |-- deployment
                |-- <runtime2>
                ----
                |-- <runtime3>
                |-- 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: [hidden email]

                Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                Web: WSO2 Inc



                _______________________________________________
                Architecture mailing list
                [hidden email]
                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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
                 

                _______________________________________________
                Architecture mailing list
                [hidden email]
                https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                Regards,
                Nira

                --

                Niranjan Karunanandham
                Associate Technical Lead - WSO2 Inc.
                WSO2 Inc.: http://www.wso2.com


                _______________________________________________
                Architecture mailing list
                [hidden email]
                https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




                --
                Thanks
                Abimaran Kugathasan
                Senior Software Engineer - API Technologies

                Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                    


                _______________________________________________
                Architecture mailing list
                [hidden email]
                https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





                --
                Thanks
                Abimaran Kugathasan
                Senior Software Engineer - API Technologies

                Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                    



                Jayanga Dissanayake
                Associate Technical Lead
                WSO2 Inc. - http://wso2.com/
                lean . enterprise . middleware
                email: [hidden email]
                mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                _______________________________________________
                Architecture mailing list
                [hidden email]
                https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                Mobile  +94712756809



                _______________________________________________
                Architecture mailing list
                [hidden email]
                https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                Reply | Threaded
                Open this post in threaded view
                |

                Re: 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 <[hidden email]> 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 (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 <[hidden email]> wrote:
                Hi Abimaran,

                On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <[hidden email]> wrote:
                Hi Jayanga,

                On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
                mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
                Hi Thusitha,

                On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
                  Hi Danesh,

                  Please find some comments in-line.

                  On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
                  |-- <runtime1>
                  |-- bin
                  |-- logs
                  |-- conf
                  |-- deployment.yaml
                  |-- log4j2.xml
                  |-- security
                  |-- secure-vault.yaml
                  |-- secrets.properties
                  |-- deployment
                  |-- <runtime2>
                  ----
                  |-- <runtime3>
                  |-- 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: [hidden email]

                  Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                  Web: WSO2 Inc



                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
                   

                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                  Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                  Regards,
                  Nira

                  --

                  Niranjan Karunanandham
                  Associate Technical Lead - WSO2 Inc.
                  WSO2 Inc.: http://www.wso2.com


                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




                  --
                  Thanks
                  Abimaran Kugathasan
                  Senior Software Engineer - API Technologies

                  Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                      


                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





                  --
                  Thanks
                  Abimaran Kugathasan
                  Senior Software Engineer - API Technologies

                  Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                      



                  Jayanga Dissanayake
                  Associate Technical Lead
                  WSO2 Inc. - http://wso2.com/
                  lean . enterprise . middleware
                  email: [hidden email]
                  mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                  Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




                  --

                  Danesh Kuruppu

                  Senior Software Engineer | WSO2

                  Email: [hidden email]

                  Mobile: +94 (77) 1690552
                  Web: WSO2 Inc



                  _______________________________________________
                  Architecture mailing list
                  [hidden email]
                  https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                  Reply | Threaded
                  Open this post in threaded view
                  |

                  Re: Multiple runtime support for C5 based products

                  Thusitha Thilina Dayaratne
                  Hi Danesh,

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

                  Thanks
                  Thusitha

                  On Mon, Apr 17, 2017 at 7:44 PM, Danesh Kuruppu <[hidden email]> 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 <[hidden email]> 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 (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 <[hidden email]> wrote:
                  Hi Abimaran,

                  On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <[hidden email]> wrote:
                  Hi Jayanga,

                  On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
                  mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                  On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <[hidden email]> 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 <[hidden email]> wrote:
                  Hi Thusitha,

                  On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <[hidden email]> 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}/bidirectory. 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 <SERVER_HOME>/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 <SERVER_HOME>/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 <[hidden email]> wrote:
                    Hi Danesh,

                    Please find some comments in-line.

                    On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[hidden email]> 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
                    |-- <runtime1>
                    |-- bin
                    |-- logs
                    |-- conf
                    |-- deployment.yaml
                    |-- log4j2.xml
                    |-- security
                    |-- secure-vault.yaml
                    |-- secrets.properties
                    |-- deployment
                    |-- <runtime2>
                    ----
                    |-- <runtime3>
                    |-- 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: [hidden email]

                    Mobile: <a href="tel:077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    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: <a href="tel:(650)%20745-4499" value="+16507454499" target="_blank">+1 650-745-4499, 77 678 0813 
                     

                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com


                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




                    --
                    Thanks
                    Abimaran Kugathasan
                    Senior Software Engineer - API Technologies

                    Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                        


                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture





                    --
                    Thanks
                    Abimaran Kugathasan
                    Senior Software Engineer - API Technologies

                    Mobile : <a href="tel:+94%2077%20392%202820" value="+94773922820" target="_blank">+94 773922820

                        



                    Jayanga Dissanayake
                    Associate Technical Lead
                    WSO2 Inc. - http://wso2.com/
                    lean . enterprise . middleware
                    email: [hidden email]
                    mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




                    --

                    Danesh Kuruppu

                    Senior Software Engineer | WSO2

                    Email: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  +94712756809



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: Multiple runtime support for C5 based products

                    Danesh Kuruppu
                    Hi Thusitha,
                     
                    Shouldn't we move resource dir to <runtime_home> 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: [hidden email]

                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: 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: [hidden email]
                    mobile: +94772207259



                    On Tue, Apr 18, 2017 at 9:42 AM, Danesh Kuruppu <[hidden email]> wrote:
                    Hi Thusitha,
                     
                    Shouldn't we move resource dir to <runtime_home> 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: [hidden email]

                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: Multiple runtime support for C5 based products

                    Niranjan Karunanandham
                    Hi,

                    On Tue, Apr 18, 2017 at 11:35 AM, Jayanga Dissanayake <[hidden email]> 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: [hidden email]
                    mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                    On Tue, Apr 18, 2017 at 9:42 AM, Danesh Kuruppu <[hidden email]> wrote:
                    Hi Thusitha,
                     
                    Shouldn't we move resource dir to <runtime_home> 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: [hidden email]

                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    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
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: Multiple runtime support for C5 based products

                    Danesh Kuruppu
                    In reply to this post by Danesh Kuruppu
                    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: [hidden email]

                    Mobile: +94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

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


                    Thanks
                    Thusitha


                    On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <[hidden email]> 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: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  +94712756809



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: Multiple runtime support for C5 based products

                    Niranjan Karunanandham
                    Hi,

                    On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <[hidden email]> 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., <ServerHome>/deployment. 
                     

                    On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <[hidden email]> 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: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com


                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: 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: [hidden email]
                    mobile: +94772207259



                    On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <[hidden email]> wrote:
                    Hi,

                    On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <[hidden email]> 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., <ServerHome>/deployment. 
                     

                    On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <[hidden email]> 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: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: 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. <server-home>/<runtime-home>/deployment
                    2. <server-home>/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 <[hidden email]> 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: [hidden email]
                    mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                    On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <[hidden email]> wrote:
                    Hi,

                    On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <[hidden email]> 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., <ServerHome>/deployment. 
                     

                    On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <[hidden email]> 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: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com





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

                    Mobile  +94712756809



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    Reply | Threaded
                    Open this post in threaded view
                    |

                    Re: Multiple runtime support for C5 based products

                    Niranjan Karunanandham
                    Hi Thusitha,

                    On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <[hidden email]> 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. <server-home>/<runtime-home>/deployment
                    2. <server-home>/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 <[hidden email]> 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: [hidden email]
                    mobile: <a href="tel:+94%2077%20220%207259" value="+94772207259" target="_blank">+94772207259



                    On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <[hidden email]> wrote:
                    Hi,

                    On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <[hidden email]> 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., <ServerHome>/deployment. 
                     

                    On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <[hidden email]> 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: [hidden email]

                    Mobile: <a href="tel:+94%2077%20169%200552" value="+94771690552" target="_blank">+94 (77) 1690552
                    Web: WSO2 Inc



                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com





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

                    Mobile  <a href="tel:+94%2071%20275%206809" value="+94712756809" target="_blank">+94712756809



                    Regards,
                    Nira

                    --

                    Niranjan Karunanandham
                    Associate Technical Lead - WSO2 Inc.
                    WSO2 Inc.: http://www.wso2.com


                    _______________________________________________
                    Architecture mailing list
                    [hidden email]
                    https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
                    12