On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah < > kishant...@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). >>> >> >> 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. >
It's not only about API-Manager product but the same requirement is needed for IoT product (and IS may also have the requirement when running the user/admin portal separately) that require multiple runtimes. So isn't it better to provide a common way to do this? > 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. > >> 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. >>> >>> 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 >>> >> >> >> >> -- >> *Kishanthan Thangarajah* >> Technical Lead, >> Platform Technologies Team, >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - +94773426635 >> Blog - *http://kishanthan.wordpress.com >> <http://kishanthan.wordpress.com>* >> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* >> > > > > -- > 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. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture