Hi, On a side note, I would call it s/Deployment/Runtime. I think it is a more suitable name.
thanks, dimuthu On Tue, Dec 2, 2014 at 8:45 AM, Dimuthu Leelarathne <[email protected]> wrote: > Hi Rajeevan, > > Please see my comments below. > > On Mon, Dec 1, 2014 at 10:46 PM, Aiyadurai Rajeevan <[email protected]> > 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. > > > 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. > > AppType (1) ----------------- has ------------------> (n)Deployment Envs > > 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: [email protected] | Mobile : +94776411636 >> > > > > -- > Dimuthu Leelarathne > Architect & Product Lead of App Factory > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile : 0773661935 > > Lean . Enterprise . Middleware > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
