On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias <nuw...@wso2.com> wrote:

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

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


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

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


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



-- 
*Kishanthan Thangarajah*
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to