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
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?
>> 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 , 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,
>>> *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
>>> - 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;
>>> |-- 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 /
>>>  - [Architecture] How can we improve our profiles story?
>>> Associate Technical Lead
>>> Architecture mailing list
>> 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
Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
Architecture mailing list