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. On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah <[email protected] > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
