Hi folks, I had a chat with Sameera and Jayanga on how we can improve support for managing configurations for a particular profile.
We were discussing the possibility of extending the ConfigResolver [1] concept to manage profile specific configurations. With ConfigResolver, we have the ability to override certain configurations using the deployment.properties file, this way we only need modify a single file to override configurations scattered in different files. We are looking into the possibility of using the ConfigResolver approach to handle configs related to a specific profile as well. The idea is to have a profile specific deployment.properties file where we can specify the configs related to that particular profile. This way we can avoid duplicating the same config file and parameteriz values using the properties file. If we build a pack specific to a particular profile, this might create complication for the simplest scenario where a user wants to simply extract the distribution and try it out. With profile specific distributions, users will have to deal with multiple distributions (configuring offsets etc) even to try out a product which is cumbersome. So I feel, having a per profile properties is a feasible mechanism to define profile specify configs. Shall we go ahead with this approach? Any concerns, thoughts? [1] - [Architecture] [C5] Adding deployment.properties file to override configurations in components [2] - [C5] Less configuration elements with meaningful defaults On Mon, Oct 3, 2016 at 5:11 PM, Sameera Jayasoma <[email protected]> wrote: > Hi All, > > We can categorize all the files which need to be handled by profiles into > three groups. > > > *1) OSGi repository * > > - *Location:* repository/components > - *Description:* Contains all the OSGi bundles, dropins artifacts and > other required files. This repository is already organized into multiple > profiles(if any). > > > *2) Config repository* > > - *Location:* repository/conf > - *Description: Contains configuration files of the products. We need > to figure out a way handle profile specific configuration files.* > > > *3) Artifact repository* > > - *Location*: repository/deployment > - *Description*: Contains deployment artifacts of the product. We need > to figure out a way to handle profile specific deployment artifacts. > > > Shariq from the platform team will work on this. > > Thanks, > Sameera. > > On Fri, Sep 23, 2016 at 3:18 PM, Nuwan Dias <[email protected]> wrote: > >> >> >> On Fri, Sep 23, 2016 at 2:38 PM, Srinath Perera <[email protected]> wrote: >> >>> I think this happen with ESB NIO transport and Servelt transport for >>> webapps. ( Nuwan, is there other examples?). >>> >> >> In the regsitry.xml, we configure the indexers and handlers. These again >> are only required in certain profiles. There are also some configs in the >> api-manager.xml which only makes sense to enable in certain profiles. >> >>> >>> On Fri, Sep 23, 2016 at 9:42 AM, Kishanthan Thangarajah < >>> [email protected]> wrote: >>> >>>> Current issue is that all bundles and artifacts (conf files, webapps) >>>> are common to the server which are shared among all the profiles. We don't >>>> have a way to delete and modify them when starting up a profile. >>>> >>>> One other option is we could pack everything (profile specific >>>> artifacts) in the base distribution and provide a build script (ant) which >>>> create profile specific runtime a. >>>> >>>> We will check for the other alternatives along with this PoC and see. >>>> >>>> On Thu, Sep 22, 2016 at 12:27 PM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> We proposed an idea to build a pack based on a profile. That will >>>>> contain only the essential stuff. So rather than starting up a runtime and >>>>> then loading a profile, you build a pack that contains the bare >>>>> minimum stuff required. Perhaps we can have a descriptor which describes >>>>> what non-OSGi stuff are required for a profile and we can combine that >>>>> with >>>>> the OSGi bundles.info to figure out exactly what is needed. Can >>>>> someone in the kernel team do a quick PoC? >>>>> >>>>> On Thu, Sep 22, 2016 at 11:26 AM, Srinath Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> Smaeera, are these things we can fix? >>>>>> >>>>>> --Srinath >>>>>> >>>>>> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is to raise some concerns over the current server profiles. >>>>>>> Although we are able to control the bundles which are loaded to the >>>>>>> runtime >>>>>>> based on the -Dprofile parameter, we still lack the ability of removing >>>>>>> files and modifying configuration files when the server starts on a >>>>>>> profile. And this is forcing us to start unnecessary bundles at startup. >>>>>>> Let me explain... >>>>>>> >>>>>>> API Manager has both webapps and a gateway in its distribution. The >>>>>>> synapse bundles are only required in the Gateway profiles. However since >>>>>>> the axis2.xml file of API Manager defines the http transport senders and >>>>>>> receivers based on the Synapse passthrough senders and receivers, the >>>>>>> axis2 >>>>>>> engine will try to load the synapse classes on startup. Ideally if we >>>>>>> were >>>>>>> able to modify the axis2.xml on the Publisher, Store and Key Manager >>>>>>> profiles and replace the passthrough senders and receivers with our >>>>>>> standard http senders and receivers, we could avoid loading the synapse >>>>>>> bundles on the Publisher, Store and Key Manager. >>>>>>> >>>>>>> The same problem occurs for registry indexers and handlers. Since >>>>>>> the registry indexers and handlers are configured on the registry.xml, >>>>>>> even >>>>>>> though these are only required in the publisher and store profiles, >>>>>>> these >>>>>>> bundles will be activated and running even on the Gateway, Key Manager >>>>>>> and >>>>>>> Traffic Manager. So unless we modify the registry.xml on those nodes >>>>>>> manually, we can't stop those bundles from running. >>>>>>> >>>>>>> Another problem we're facing is the inability to remove webapps. >>>>>>> Since all webapps in the repository/deployment/server/webapps and >>>>>>> repository/deployment/server/jaggeryapps are deployed into the >>>>>>> runtime, unless we remove these webapps manually there is no other way >>>>>>> to >>>>>>> stop them from being deployed in unrelated profiles. >>>>>>> >>>>>>> I heard there is a discussion to bind a profile to a container. >>>>>>> Which would solve these problems. However it still won't help the >>>>>>> "non-container" deployments. Are there ways to overcome the above >>>>>>> mentioned >>>>>>> limitations and enhance the efficiency of our profiles? >>>>>>> >>>>>>> Thanks, >>>>>>> NuwanD. >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ============================ >>>>>> Srinath Perera, Ph.D. >>>>>> http://people.apache.org/~hemapani/ >>>>>> http://srinathsview.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *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]* >>>>> * 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* >>>>> >>>> >>>> >>>> >>>> -- >>>> *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>* >>>> >>>> >>>> -- >>>> *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>* >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> > > > > -- > Sameera Jayasoma, > Software Architect, > > WSO2, Inc. (http://wso2.com) > email: [email protected] > blog: https://medium.com/@sameera.jayasoma > twitter: https://twitter.com/sameerajayasoma > > > -- Thanks, Shariq Associate Technical Lead
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
