Hi Pubudu, IMHO, I prefer to skip the config override when running the profile > optimization. What if we make this as the default approach? If someone > wants to override the configs, then with profile optimization, they can use > a new flag called --override or something similar as Samitha mentioned. > If we make the default behavior to not-override, then in non Docker/K8s scenarios the profile optimization will be done incompletely. We have to think about most generic scenario of profile optimization. Is Docker/K8s the most generic scenario of customer use cases? I assume not.
And in the perspective that "the users expected to run the optimization first and then do the configuration", overriding the configs should be the default option. And thinking about preserving the same old behavior too, as Bhathiya suggested, overriding configs should be ideal. Regards, Samitha On Thu, Jan 30, 2020 at 10:28 AM Pubudu Gunatilaka <pubu...@wso2.com> wrote: > Hi, > > If we check one of the existing profile toml [1], the values are very > common and it cannot be used in real production cases. Sample values > contain commonly used hostnames and admin credentials. If we are to use > this feature properly with configuration override, users have to change > these default templates. And then they can use profile optimize along with > configs override. > > IMHO, I prefer to skip the config override when running the profile > optimization. What if we make this as the default approach? If someone > wants to override the configs, then with profile optimization, they can use > a new flag called --override or something similar as Samitha mentioned. > > In K8s, docker use cases we have a single docker image and we are having > profile based deployment.toml. We can bring the hostnames to the > deployment.toml as Nuwan suggested and this would simplify the > deployment.toml. When running the docker image, we can run the profile > optimize and it won't affect the deployment.tomls that come in config maps. > At the moment, in docker images, we had to deal with this configuration > overridden issue. > > [1] - > https://github.com/wso2/product-apim/blob/master/modules/distribution/product/src/main/resources/conf/deployment-templates/api-publisher.toml > > Thank you! > > On Wed, Jan 29, 2020 at 2:10 PM Harsha Kumara <hars...@wso2.com> wrote: > >> I'm thinking on real world scenario where customer will keep one base >> product archive and add the configs. isn't it easy for them to copy those >> files just to the profile optimizer tool location? >> >> On Wed, Jan 29, 2020 at 3:15 PM Bhathiya Jayasekara <bhath...@wso2.com> >> wrote: >> >>> Hi Samitha, >>> >>> On Wed, Jan 29, 2020 at 2:29 PM Samitha Chathuranga <sami...@wso2.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> Our profile optimization [1] script for 3.0.0 replaces [2] already >>>> available deployment.toml with a per-profile specific updated/optimized >>>> toml file. (i.e. api-devportal.toml, gateway-worker.toml, etc.). This >>>> process affects already configured setups, to lose the configurations. >>>> >>>> A user running the profile optimization might follow two approaches. >>>> >>>> 1. Run profile optimization on a vanilla pack. >>>> - So no any configurations done when the profile optimization is >>>> executed >>>> 2. Run profile optimization on a configured pack. >>>> - User/deployment specific configurations are already done in the >>>> deployment.toml file and user run the profile optimization after that. >>>> >>> >>> The user is expected to run the optimization first and then do the >>> configuration. The real problem here comes with Kubernetes, where we pass >>> configs as config maps. These shouldn't be replaced by the optimizer, >>> because we expect the optimized configs to come via config maps. >>> >>> >>>> >>>> There is no any issue with the Approach-1. But the Approach-2 results >>>> in the above mentioned issue. A user might have made all his configurations >>>> in the deployment.toml file. But once the profile optimization is executed, >>>> he will lose all those config changes. >>>> >>>> So the suggested solution is to pass an argument/option when we run the >>>> optimizing script, which decides whether to replace the deployment.toml or >>>> not. >>>> >>>> sh <PRODUCT_HOME>/bin/wso2server.sh --optimize *--<new-option> >>>> *-Dprofile=api-publisher >>>> >>>> In this case, we have to assume(and mandate) that user has manually >>>> applied the profile optimization related configurations too, into the >>>> deployment.toml file while doing the other configurations. So if the "new >>>> option" decides not to override the deployment.toml file, the profile >>>> optimization steps other than deployment.toml changes will be applied. >>>> >>>> So we have two concerns on how we use this new option. >>>> >>>> *What is the ideal name for the new option (<new-option>)?* >>>> Suggestions: --override, --overrideConfig >>>> >>> >>> How about --skipConfigOptimization ? >>> >>> >>>> >>>> *What is the default behavior of the new option?* >>>> - What is the default behavior if the new option is not passed when >>>> running the optimization.? >>>> >>> >>> It should be the current behavior. >>> >>> Thanks, >>> Bhathiya >>> >>> >>>> - Should it override the user-made configs with the profile-specific >>>> deployment toml or not? >>>> - Concerns: >>>> - If override the toml, users manual configs will be completely >>>> removed (may be unknowlingly too). >>>> - If do not override toml, the profile optimization will be done >>>> incompletely. Anyway we can echo a message conveying that the deployment >>>> toml was not overridiiden. >>>> >>>> Appreciate your input on this. >>>> >>>> [1] >>>> https://apim.docs.wso2.com/en/next/SetupAndInstall/DeployingWSO2APIManager/DistributedDeployment/product-profiles/ >>>> [2] >>>> https://github.com/wso2/product-apim/blob/master/modules/distribution/product/src/main/startup-scripts/profileSetup.sh#L302 >>>> >>>> Thanks, >>>> Samitha >>>> >>>> -- >>>> *Samitha Chathuranga* >>>> *Associate Technical Lead*, *WSO2 Inc.* >>>> lean.enterprise.middleware >>>> Mobile: +94715123761 >>>> >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. >>> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com >>> >>> >>> >> >> -- >> >> *Harsha Kumara* >> >> Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: hars...@wso2.coim >> Blog: harshcreationz.blogspot.com >> >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > *Pubudu Gunatilaka* | Technical Lead | WSO2 Inc. > (m) +94774078049 | (w) +94112145345 | (e) pubu...@wso2.com > <http://wso2.com/signature> > > -- *Samitha Chathuranga* *Associate Technical Lead*, *WSO2 Inc.* lean.enterprise.middleware Mobile: +94715123761 [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
