HI Rajeevan, No GUI please. We are changing the whole user story here.
thanks, dimuthu On Wed, Dec 3, 2014 at 10:54 AM, Aiyadurai Rajeevan <rajeev...@wso2.com> wrote: > Hi Dimuthu/All, > > In addition to this mail conversation we had discussed this in an internal > forum, Here is the update of thatdiscussion.... > > As of today We are using appfactory.xml file for the runtime > configurations the below fraction is the the configuration properties. > > <ApplicationType name="*"> > > <ClassName> > org.wso2.carbon.appfactory.jenkins.deploy.JenkinsArtifactDeployer > </ClassName> > > <Endpoint>https://sc.s2.AF_HOST:9463/services/</Endpoint> > > <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> > > <Properties> > > <Property name="alias">asdev</Property> > > <Property name="cartridgeType">asdev</Property> > > <Property name="deploymentPolicy">af-deployment</Property> > > <Property name="autoscalePolicy">economy</Property> > > <Property name="repoURL"></Property> > > <Property name="dataCartridgeType"></Property> > > <Property name="dataCartridgeAlias"></Property> > > <Property name="subscribeOnDeployment">false</Property> > > </Properties> > > </ApplicationType> > > > *Proposed solution* > > *Part 1: -* In the above xml, Content which enclosed within the > *RepositoryProvider* are used to do the Pass artifact storage > configuration. Hence, As suggested we can keep this in the > *org.wso2.carbon.appfactory.jenkins.AppfactoryPluginManager.xml* file. > > *Part 2:- *Content which are enclosed within *Properties* tag are used > for the subscription. Hence, Below is the solution which we are proposing. > So, it would be more user friendly. > > There can be multi tenant subscriber and single tenant subscriber, Lets > focus on the multi tenant scenario here. > > *Step 1*: Create Tenant > > *Step 2*:Tenant Admin Login > > *Step 3*: Go to subscriber manager, This would be a GUI which let > the user to subscribe the needed Cartridge type, Environment(Dev,Test > &Prod), deploymentPolicy and autoscalePolicy. The GUI shall look like > below. > > > > > Here We can populate cartridge type, deploymentPolicy and autoscalePolicy > details from Stratos service. > > So user can select the needed details in the above GUI and click > subscribe, That will invoke a call to Stratos service for the cartridge > allocation and create Repo URL which will used to commit the code in s2Git. > Altogether there would be three URL for the 3 environments. > > > Appreciate your views in this approach please. > > Thanks & Regards, > S.A.Rajeevan > Software Engineer WSO2 Inc > E-Mail: rajeev...@wso2.com | Mobile : +94776411636 > > On Tue, Dec 2, 2014 at 12:27 PM, Dimuthu Leelarathne <dimut...@wso2.com> > wrote: > >> 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 >> > > -- 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
