On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah <kishant...@wso2.com
> 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).
> This is the similar thing we are trying propose. The "profiles" concept is
> C5 is actually runtime we are talking about. It is not only about osgi
> bundles, but everything a runtime needs to start on its own.
> For example, api-manager store runtime needs set of bundles, configuration
> files and store UI component written using uuf/jaggery. The tool will
> create this runtime by reading the descriptor file and launch the instance
> as a separate JVM.
But why would we need a tool to do that? What if we build the product
itself in that manner. 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
> Additionally if we have option of docker compose given, then it will
> launch a docker instance with the store runtime.
>> Also if we have profiles, do we also have a global profile which runs all
>> components in one?
> No, with the above model, there will not be a single profile (or global
> profile) which has all the runtime components in it and we have to move
> away from single product running all the components together in the same
> JVM. Each runtime will be started as different processes/JVM (can be
> OSGi-java process and just another java process).
> If a runtime needs a non-OSGi java process (say for example you want to
> start activemq as part of the product), then you can also do that using
> this proposed approach.
>> 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 <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
> *Kishanthan Thangarajah*
> Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
Architecture mailing list