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 <[email protected]> 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 <
> [email protected]> 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 <[email protected]>
>> wrote:
>>
>>> Hi Abimaran,
>>>
>>> On Thu, Mar 30, 2017 at 4:08 PM, Abimaran Kugathasan <[email protected]>
>>> wrote:
>>>
>>>> Hi Jayanga,
>>>>
>>>> On Thu, Mar 30, 2017 at 3:42 PM, Jayanga Dissanayake <[email protected]>
>>>> 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: [email protected]
>>>>> mobile: +94772207259 <+94%2077%20220%207259>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>> On Thu, Mar 30, 2017 at 2:48 PM, Abimaran Kugathasan <
>>>>> [email protected]> 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 <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Thusitha,
>>>>>>>
>>>>>>> On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Danesh,
>>>>>>>>>
>>>>>>>>> Please find some comments in-line.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <[email protected]>
>>>>>>>>> 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: [email protected]
>>>>>>>>>> Mobile: +94 (77) 1690552 <077%20169%200552>
>>>>>>>>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>>>>>>>> email: kasung AT spamfree wso2.com
>>>>>>>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>>>>>>>> blog: http://kasunbg.org
>>>>>>>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thusitha Dayaratne
>>>>>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>>>>>
>>>>>>>> Mobile  +94712756809 <+94%2071%20275%206809>
>>>>>>>> Blog      alokayasoya.blogspot.com
>>>>>>>> About    http://about.me/thusithathilina
>>>>>>>> <http://wso2.com/signature>
>>>>>>>>
>>>>>>>>
>>>>>>> Regards,
>>>>>>> Nira
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> *Niranjan Karunanandham*
>>>>>>> Associate Technical Lead - WSO2 Inc.
>>>>>>> WSO2 Inc.: http://www.wso2.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks
>>>>>> Abimaran Kugathasan
>>>>>> Senior Software Engineer - API Technologies
>>>>>>
>>>>>> Email : [email protected]
>>>>>> Mobile : +94 773922820 <+94%2077%20392%202820>
>>>>>>
>>>>>> <http://stackoverflow.com/users/515034>
>>>>>> <http://lk.linkedin.com/in/abimaran>
>>>>>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>>>>>>   <https://twitter.com/abimaran>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> Abimaran Kugathasan
>>>> Senior Software Engineer - API Technologies
>>>>
>>>> Email : [email protected]
>>>> Mobile : +94 773922820 <+94%2077%20392%202820>
>>>>
>>>> <http://stackoverflow.com/users/515034>
>>>> <http://lk.linkedin.com/in/abimaran>
>>>> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
>>>> <https://twitter.com/abimaran>
>>>>
>>>>
>>>
>>> ​
>>> *​Jayanga Dissanayake*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.com/
>>> lean . enterprise . middleware
>>> email: [email protected]
>>> mobile: +94772207259 <+94%2077%20220%207259>
>>> <http://wso2.com/signature>​
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thusitha Dayaratne
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> Mobile  +94712756809 <+94%2071%20275%206809>
>> Blog      alokayasoya.blogspot.com
>> About    http://about.me/thusithathilina
>> <http://wso2.com/signature>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: [email protected]
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc <https://wso2.com/signature>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


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

Mobile  +94712756809
Blog      alokayasoya.blogspot.com
About    http://about.me/thusithathilina
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to