Hi, On Thu, Jun 7, 2018 at 11:07 AM Sarubi Thillainathan <[email protected]> wrote:
> 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. > This creates a new distribution (.zip) file for the intended profile without altering the current distribution? Or it alters the current distribution it self? i.e, Let's say I have downloaded and extracted APIM, now I have to create api-store and api-publisher profiles. So, should I extract the distributions two times and run this commands seperately profileSetup.sh -Dprofile=api-store and profileSetup.sh -Dprofile=api-publisher in two extracted directories? Thanks, Sinthuja. > > 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 > -- *Sinthuja Rajendran* Senior Technical Lead WSO2, Inc.:http://wso2.com Blog: http://sinthu-rajan.blogspot.com/ Mobile: +94774273955
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
