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).

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.


On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq <> 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 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 file. The base distribution will
> have 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
>           |--
>      |-- km
>           |-- metadata.yaml
>           |--
> |-- *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, 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

Nuwan Dias

Software Architect - WSO2, Inc.
email :
Phone : +94 777 775 729
Architecture mailing list

Reply via email to