On Wed, Oct 12, 2016 at 11:09 PM, Imesh Gunaratne <[email protected]> wrote:
> > > On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias <[email protected]> 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 > bundles. > > 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 <[email protected]> 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? > > Thanks > Imesh > > >> Thanks, >> NuwanD. >> >> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq <[email protected]> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> 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 > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
