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;

|-- 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 /

[1] - [Architecture] How can we improve our profiles story?

Associate Technical Lead
Architecture mailing list

Reply via email to