Hi Chamila, According to the offline discussion with Nuwan, Here what we are doing is, automate configuration changes to optimize API-M profiles. Up to now, it has been manually done by users [1] when they wanted to run a selected profile.
We provide two options to accomplish this, 1. The user can do the optimization separately before the server starts up by run the profileSetup.sh along with a particular profile flag. (ex: profileSetup.sh -Dprofile=api-store ) Once it has done, can use this APIM package as the root image for CM tools. 2. The user can start the wso2server.sh with a particular profile along with --optimize flag. (i.e) wso2server.sh --optimize -Dprofile=api-store. if and only -optimize flag found we do the optimization for that particular profile then start the server automatically, otherwise not. Please find inline comments for further details: On Tue, Jun 5, 2018 at 4:11 AM, Chamila De Alwis <[email protected]> wrote: > Hi Sarubi, > > I have a couple of questions regarding the fit between the changes that > this script does and the config automation tools. > > Is this a tool focused on evaluation part of the product or the deployment > part? IMO both would require a re-evaluation of the approach. > This is focused on deployment part of product. > > IIUC, this script would alter the startup pack, with file additions and > removals done to config files, deployable artifacts, and other library > files. This could be a problematic case for continuous config automation > story. > > Consider a scenario where Puppet (or any other tool) configures a set of > instances, using the APIM pack as the root. The tool might be configured to > continuously run (say, with a 30-minute interval). Is there a chance for > the server to be reconfigured every time the tool is run, because the tool > detects the changes that this script does at the startup, as changes that > should be rolled back? > According to the scenario that you have mentioned, Puppet (or any other tool) can configures a set of instances, using optimized APIM pack as the root. > In that case, it might be better to have this tool as a separate script > rather than one which starts up the server as well. > Yes, now we maintain a seperate script which will get executed based on the user specification for server start-up. > > Another point against such a tool bound to server startup would be the > mixing of concerns. AFAIU, what this script does falls under what the > config automation tools do. IMO WSO2 server startup scripts should only > work on the bootstrapping of the server runtime, rather than the config > automation part. Also, we would essentially be repeating what the config > automation tools should do, but in Bash which sometimes is a lot harder. > Obtaining config values, managing them meaningfully, and applying them to > files is essentially what a config automation tool does. We may be > re-inventing the wheel here. For an example, should this tool be concerned > about the port offset at all since even dev deployments will be done using > separate VMs/Containers? Or should it be worried about different values for > the config options in different environments? > > Also, this script don't concerned about the port offset things since it designed only to configure the changes for corresponding profile specified. > Additionally, users who manage config automation usually adhere to one set > of scripts. Puppet users almost always go for Puppet, Chef users for Chef > etc. What we would be delivering might step on what they already have, or > are comfortable working with, and in turn, the adaption rate might take a > hit. > > User can go with first option, run the profile setup script seperatly before server start up and get optimized API-M pack as the base image > IMO you might benefit from reviewing your approach with the Installation > Experience effort, as the responsibilities of this tool fall close to, if > not overlap with, what the Installation Experience scripts deliver/would > deliver with different providers. > > WDYT? > > > Regards, > Chamila de Alwis > Committer and PMC Member - Apache Stratos > Associate Technical Lead | WSO2 > +94 77 220 7163 > Blog: https://medium.com/@chamilad > > Commnets or suggestions are highly appreciated. [1]https://docs.wso2.com/display/AM220/Product+Profiles -- *Sarubi Thillainathan * *Software Engineer - WSO2 Inc.* *Mobile : +94 (0) 76 68 49 101*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
