Hi Danushka, Please see my comments below.
On Tue, Dec 2, 2014 at 12:01 PM, Danushka Fernando <danush...@wso2.com> wrote: > 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. > You are correct in saying we need to concentrate on this current feature only. But since we are going to be doing refactoring anyway I propose to separate out Runtime concept gradually. There is no harm in adding a new meta data object saying Runtime. It can only do us good. Less refactoring in the future. Could you tell me why we need to add cartridge.xml to *.apptype archive itself? I prefer to keep it separate as a part of PaaS. And use Runtime object to refer to it. I don't want CartridgeInfo objects being used all over in our code. Rather I prefer to see Runtime being used because AppFactory and Stratos can evolve fairly independently. thanks, dimuthu > >> 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 > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: dimut...@wso2.com Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
