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

On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah <kishant...@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,
> 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
Architecture mailing list

Reply via email to