AFAIK most customers don't run the single profile we provide. EG: sometime store+publisher in a single node make scene, sometimes store alone is better, same thing for keymanger+tragicmanger.
So isn't it better if we can individually turn them on and off. EG: ./server.sh -profiles store,publisher OR We can ask to both in parallel ./server.sh -profile store ./server.sh -profile publisher On Thu, Oct 13, 2016 at 8:42 AM, Afkham Azeez <[email protected]> wrote: > Please note that during a discussion this week, we decided that instead of > all carbon servers running on the same ports, each of the 5 products will > have their own well known ports. For example, APIM GW port will be 8084 > (just an example). So while we would still have portOffset support, we > won't need to specify the offset when running multiple products on the same > machine and they will be able to discover each other on these well known > ports. > > 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). >> >> 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. >> >> 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 >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
