Hi All, This is the component architecture diagram of PPaaS Artifact Migration Tool. @ Chamila : Thank you for the suggestions and we will improve the tool as mentioned.
We highly appreciate your suggestions on this model. Thank you. On Fri, Dec 18, 2015 at 1:09 AM, Chamila De Alwis <chami...@wso2.com> wrote: > Hi Malmee, > > Great work on the migration tool. AFAIU this is as far as we can go to > ease the migration process for a Stratos user. > > Some improvements that can be implemented, IMO, are, > > 1. Rename bin/run.sh to bin/stratos.sh to conform with the existing > pattern where each separate Stratos component is started with a script > named stratos.sh > 2. If the path of the config file (currently config.properties) can also > be an input value like the log4j config file, it might be easy to reuse the > same tool with several config files, pointing to several Stratos > installations at the same time. > 3. Since configuration is a global state throughout a running instance, > IMO it can be included as static final values in a static Config class. > This might prove useful than the system property approach for several > reasons, one being that after loading the config, it wouldn't be > accidentally changed. > 4. IMO the singleton implementations can be static classes (Transformation > and ConversionTool). They don't seem to have any state. > 5. Apache Commons library seems to provide some functions in a safer > manner for some of the implemented methods like configuration loading[1] > and file writing [2]. > 6. From a superficial look it seems the fetch methods on OldArtifactLoader > can be refactored in to a single method. Please look in to this > possibility. > 7. If the existing RestClient implementation is going to be maintained, > IMO it would be a better design to let the configuration decide whether to > skip host and cert verification, as discussed in the code review. > 8. Move Constants to the root folder, since it's been called by other > classes as well. > 9. The next step can be to convert the Constants code file to a > configuration file (XML/YAML) for configurable options like the endpoints, > default values and cert path can be configured and the tool can be run > against any future versions as well. However AFAIU, that is out of scope > for the initial implementation. > > > [1] - > http://fahdshariff.blogspot.com/2013/04/adding-java-system-properties-from.html > > [2] - > http://www.avajava.com/tutorials/lessons/how-do-i-write-a-string-to-a-file-using-commons-io.html > > > > Regards, > Chamila de Alwis > Committer and PMC Member - Apache Stratos > Software Engineer | WSO2 | +94772207163 > Blog: code.chamiladealwis.com > > > > On Wed, Dec 16, 2015 at 10:07 AM, Malmee Weerasinghe <mal...@wso2.com> > wrote: > >> Hi Imesh, >> >> We will include a component architecture diagram of the PPaaS Artifact >> Migration Tool. >> >> Thanks. >> >> On Tue, Dec 15, 2015 at 10:53 PM, Imesh Gunaratne <im...@wso2.com> wrote: >> >>> Hi Malmee, >>> >>> It would be better if you can draw a component architecture diagram to >>> illustrate how this tool works. >>> >>> This might help us to understand how much load it can handle if the >>> existing Private PaaS 4.0.0 environment has considerable amount of >>> artifacts and subscriptions and how those can be processed efficiently. >>> >>> Thanks >>> >>> On Tue, Dec 15, 2015 at 10:39 PM, Malmee Weerasinghe <mal...@wso2.com> >>> wrote: >>> >>>> Hi All, >>>> We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to >>>> PPaaS 4.1.x. [1] >>>> >>>> There are changes in the artifacts deployment process in PPaaS 4.0.0 >>>> compared to 4.1.0. So this tool is developed for those who need to migrate >>>> from PPaaS 4.0.0 to 4.1.0. >>>> >>>> We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints, >>>> convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are >>>> accessed via a dependency and generate output artifacts to to be compatible >>>> with PPaaS 4.1.x. In this process, we use default values for the additional >>>> artifacts. >>>> >>>> These are the conversions we have implemented already. >>>> - auto scale policy artifacts >>>> - network partition list artifacts >>>> - deployment policy artifacts >>>> - cartridge artifacts >>>> - application artifacts >>>> - application sign ups - convert the cartridge subscription artifacts >>>> JSONs output from Subscription Manager [2] >>>> - domain mappings >>>> >>>> Would appreciate it if you could give your suggestions and comments on >>>> this. >>>> [1] >>>> https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter >>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fnishadi%2Fproduct-private-paas%2Ftree%2Fmaster%2Ftools%2Fmigration%2Fppaas-artifact-converter&sa=D&sntz=1&usg=AFQjCNE2Dyg5DdkTZPMJ0sAUvRsl2Gd3Sw> >>>> [2] >>>> https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0 >>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fproduct-private-paas%2Ftree%2Fmaster%2Ftools%2Fmigration%2Fsubscription-manager%2F4.0.0&sa=D&sntz=1&usg=AFQjCNE1lGmU7j6H3n40U6uIkNLVQYO5nQ> >>>> >>>> -- >>>> Malmee Weerasinghe >>>> WSO2 Intern >>>> mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> >>>> mal...@wso2.com >>>> >>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.gunaratne.org >>> Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> Malmee Weerasinghe >> WSO2 Intern >> mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> >> mal...@wso2.com >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malmee Weerasinghe WSO2 Intern mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> mal...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
