On Wed, Oct 12, 2016 at 11:09 PM, Imesh Gunaratne <im...@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).
>>
>
> ​+1 If we are not planning to have the single JVM mode in C5​, this might
> be the ideal design for a containerized deployment. It would also work for
> non containerized deployments as different profiles can be started using
> unique ports.
>
> The question is whether we need a single bash script/executable for
> starting multiple profiles?
>
>>
>> Also if we have profiles, do we also have a global profile which runs all
>> components in one? I doubt we'll be able to achieve the target of 1 to 2
>> sec startup time if we do that.
>>
>
> ​I think we are trying to reduce the server startup time by lazy loading
> bundles.​
>
>

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

>
> On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah <kishanthan@wso2.
> com> wrote:
>
>>
>> On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>
>>>
>> Ex: Store will have all its bundles, config files, etc in a single
>>> directory. And it'll have its own startup script (.sh). Same will be for
>>> the publisher and other runtimes. It will result in a certain amount of
>>> duplicate jars in those directories (carbon kernel), but that isn't much of
>>> a problem isn't it? Do you see any other problems in doing that?
>>>
>>
>> The duplication will be high here IMO based on the passed experience. The
> pack size will increase due to this.
>
> ​If we were to have a distribution per profile, would duplicating bundles
> be an issue?
>
> Thanks​
> ​Imesh​
>
>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq <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
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to