HI Dimuthu Please find my comments inline
On Tue, Dec 2, 2014 at 8:45 AM, Dimuthu Leelarathne <dimut...@wso2.com> wrote: > Hi Rajeevan, > > Please see my comments below. > > On Mon, Dec 1, 2014 at 10:46 PM, Aiyadurai Rajeevan <rajeev...@wso2.com> > wrote: > >> Hi All, >> >> We are trying to implement a feature on AF which enables the user to >> deploy their customized app types, Currently this configuration is >> available in *appfactory.xml *under *<Deployer>* tag the content would >> be as [1], likewise we have for each app types. Hence this wouldn't be >> editable by the users and may not deploy their own app types. If we move >> out this [1] from *appfactory.xml* and put this in a configurable file >> would enable the users to customize their need. >> >> When we analyzing the [1] we found out , The below content related to >> Pass artifact storage configuration and common to all app types. >> >> <RepositoryProvider> >> >> <Property name="Class"> >> >> >> org.wso2.carbon.appfactory.s4.integration.GITBlitBasedGITRepositoryProvider >> >> </Property> >> >> <Property name="BaseURL"> >> https://gitblit.s2.wso2.com:8444/</Property> >> >> <Property name="URLPattern">{@stage}/as >> </Property> >> >> <Property name="AdminUserName">admin</Property> >> >> <Property name="AdminPassword">admin</Property> >> >> </RepositoryProvider> >> >> > What is the other xml file are you talking about? Lets call it foo.xml. > The only other place that require these information other than App Factory > is Jenkins. So rather than putting these in separate xml file, I will put > it in the appfactory-plugin.xml file. This is because Jenkins provide and > inherent way to read appfactory-plugin.xml file and it doesn't give an > inherent way to read foo.xml file. > > So at this stage the foo.xml file is only used in App Factory. You may > merge it with appfactory.xml. The next question you may ask configuration > duplication. I say puppet is the answer. > > If we have code to read foo.xml we have to put the code in both Jenkins > side and AF side. I would rather use Jenkins inherent way of config files > as oppose to duplicating code in both places and having a special file. > I was thinking about moving outside the tag but keep it inside the same appfactory.xml. We can pass these to jenkins through property bag when deployment. > > > So we are planning to move this to a common configuration file and all the >> application types can access that. >> >> In [1] below properties are not used. Hence, We shall get rid of that >> from AF >> >> <Property name="minInstances">1</Property> >> >> <Property name="maxInstances">1</Property> >> >> <Property name="shouldActivate"></Property> >> <Property name="subscribeOnDeployment">false >> </Property> >> >> And the below properties are used. So, We can keep them in the >> *apptype.xml* as we already have separate apptype.xml for each app >> types.. >> > <Property name="alias">162dev</Property> >> >> <Property name="cartridgeType">162dev</Property> >> >> <Property name="deploymentPolicy">af-deployment >> </Property> >> >> <Property name="autoscalePolicy">economy >> </Property> >> >> <Property name="repoURL"></Property> >> >> <Property name="dataCartridgeType"></Property> >> >> <Property name="dataCartridgeAlias"></Property> >> >> >> > > > What is the propose of having the below in apptype.xml itself? What if we > move this to a different runtime.xml file? I am proposing because Runtime > is a different concept that is required by App Factory.Let me prove it by > example. If we use a different xml file for deployment(runtime), in future > we can implement "multiple deployment environments very easily. For example > consider the below relationship. > What I thought the cartidgeType only being used. But seems all of them used just for cartridge subscription. So we need a separate place to these indeed. And IMO we should add support to add the cartridge configuration file to the apptype as well. > > AppType (1) ----------------- has ------------------> (n)Deployment Envs > > Question about this. Is it one to many or many to many. If it is many to many its going to be complex I guess. In that case we cannot deploy the deploy / runtime configs with apptype it self. And there should be a way to map which runtimes are available to which apptype. If it is one to many there will be same deployer mentioned in several app types. Should we focus on that feature here. If it is to implement many to many relationship then we are doing that feature now. > Right now it is 1 to 1 relationship. In future it is 1 to n relationship. > So if we keep it in a separate XML the work we have to do is simply > externalise the deployment xmls to support the below scenario. > > For example consider app creation page. > > There is a "Application Type" drop down. In future we are going to have > "Runtimes" drop down. So if we have deployment as a separate concept in the > architecture it is going to be much better. > > thanks, > dimuthu > > > >> Look forward your views in this. >> >> Thanks & Regards, >> S.A.Rajeevan >> Software Engineer WSO2 Inc >> E-Mail: rajeev...@wso2.com | Mobile : +94776411636 >> > > > > -- > Dimuthu Leelarathne > Architect & Product Lead of App Factory > > WSO2, Inc. (http://wso2.com) > email: dimut...@wso2.com > Mobile : 0773661935 > > Lean . Enterprise . Middleware > Thanks & Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
