Hi,
Additionally to this, I could see that there are still the below operations
executed in the profile optimization script.
* - Config changes in below config files*
- api-manager.xml - enable_policy_deploy, enable_data_publishing,
enable_blacklist_condition,
enable_decision_connection (JMSConnectionDetails)
- axis2.xml - transport.ws.sender.enable, transport.wss.sender.enable
- registry.xml - indexing.enable
These profile specific configurations are already handled by the
server_role implementation in infer.json, so no need to do anything in
profile optimization.
*- Config file replacements*
- axis2_TM.xml
- axis2_KM.xml
- registry_TM.xml
These operations are not required since, the config file replacement won't
be effective with the new toml based config model. And the related template
files are already been replaced via the optimization script.
So I will proceed to remove these redundant operations, within this effort
itself.
Regards,
Samitha
On Fri, Jan 31, 2020 at 11:31 AM Samitha Chathuranga <[email protected]>
wrote:
> And regarding name of the option;
>
>> *What is the ideal name for the new option (<new-option>)?*
>>> Suggestions: --override, --overrideConfig
>>>
>>
>> How about --skipConfigOptimization ?
>>
> +1 for this
> And if we use this, the default behavior should be overriding the configs.
>
>
> On Fri, Jan 31, 2020 at 9:49 AM Samitha Chathuranga <[email protected]>
> wrote:
>
>> 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 <[email protected]>
>> 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 <[email protected]> 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 <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Samitha,
>>>>>
>>>>> On Wed, Jan 29, 2020 at 2:29 PM Samitha Chathuranga <[email protected]>
>>>>> 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: [email protected]
>>>> Blog: harshcreationz.blogspot.com
>>>>
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> *Pubudu Gunatilaka* | Technical Lead | WSO2 Inc.
>>> (m) +94774078049 | (w) +94112145345 | (e) [email protected]
>>> <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>
>>
>
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] <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
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
