Hi, If you have a deployer and it it is working keep it. But please don't add anymore features to this. We need to operate on "why" principle. Janaka if we go ahead with what you are saying it is a new feature. Current architecture is flexible and would make us think of many possibilities, but lets not do it.
thanks, dimuthu On Thu, Dec 4, 2014 at 10:42 AM, Dimuthu Leelarathne <dimut...@wso2.com> wrote: > Hi Guys, > > Please start with "why". Lets do minimal to achieve "why" with most > healthiest way. Why we need to do this is to external parties to add > interpreter based languages and their cartridges. We do not need a new > deployer type right now. I proposed a new "Runtime" object only because we > need to minimise the refactoring in the future. I don't think we need a > deployer IMO. > > thanks, > dimuthu > > On Thu, Dec 4, 2014 at 10:06 AM, Janaka Ranabahu <jan...@wso2.com> wrote: > >> Hi Rajeevan, >> >> Could you explain a bit more on how we are going to relate the lifecycle >> stage with the runtime? If you look at the appfactory.xml, you might have >> noticed that the Deployer information is defined for each lifecycle stage. >> So with this new runtime.xml, how are we going to address that? Does the >> runtime.xml contains all configurations or are we going to have different >> sub directories and have a runtime.xml in each of them for each lifecycle >> environment? >> >> Thanks, >> Janaka >> >> On Wed, Dec 3, 2014 at 2:17 PM, Danushka Fernando <danush...@wso2.com> >> wrote: >> >>> Hi Dimuthu and All >>> >>> We decided to go with a separate file for this runtime configs. So we >>> will deploy this file to a different location with a different axis2 >>> deployer. And we will mention in the apptype.xml which runtime to be used. >>> >>> WDYT? >>> >>> Thanks & Regards >>> Danushka Fernando >>> Software Engineer >>> WSO2 inc. http://wso2.com/ >>> Mobile : +94716332729 >>> >>> On Wed, Dec 3, 2014 at 11:49 AM, Aiyadurai Rajeevan <rajeev...@wso2.com> >>> wrote: >>> >>>> Hi Dimuthu, >>>> >>>> Thanks for the suggestion. So, As a conclusion I will go ahead with the >>>> implementation as having a runtime.xml for the whole below peroperties and >>>> populate a map from there. >>>> >>>> <Runtime> >>>> >>>> <Runtime>appserver</Runtime> >>>> >>>> >>>> <ClassName>org.wso2.carbon.appfactory.jenkins.deploy.JenkinsArtifactDeployer</ClassName> >>>> >>>> <Endpoint>https://sc.s2.AF_HOST:9463/services/</Endpoint> >>>> >>>> <RepositoryProvider> >>>> >>>> >>>> <ProviderClass>org.wso2.carbon.appfactory.s4.integration.GITBlitBasedGITRepositoryProvider</ProviderClass> >>>> >>>> <BaseURL>https://gitblit.s2.wso2.com:8444/</BaseURL> >>>> >>>> <URLPattern>{@stage}/as</URLPattern> >>>> >>>> <AdminUserName>admin</AdminUserName> >>>> >>>> <AdminPassword>admin</AdminPassword> >>>> >>>> </RepositoryProvider> >>>> >>>> <AliasPrefix>as</AliasPrefix> >>>> >>>> <CartridgeTypePrefix>as</CartridgeTypePrefix> >>>> >>>> <DeploymentPolicy>af-deployment</DeploymentPolicy> >>>> >>>> <AutoscalePolicy>economy</AutoscalePolicy> >>>> >>>> <RepoURL></RepoURL> >>>> >>>> <DataCartridgeType></DataCartridgeType> >>>> >>>> <DataCartridgeAlias></DataCartridgeAlias> >>>> >>>> <SubscribeOnDeployment>false</SubscribeOnDeployment> >>>> >>>> </Runtime> >>>> >>>> >>>> >>>> Thanks & Regards, >>>> S.A.Rajeevan >>>> Software Engineer WSO2 Inc >>>> E-Mail: rajeev...@wso2.com | Mobile : +94776411636 >>>> >>>> On Wed, Dec 3, 2014 at 11:03 AM, Dimuthu Leelarathne <dimut...@wso2.com >>>> > wrote: >>>> >>>>> 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 >>>>> >>>> >>>> >>> >> >> >> -- >> *Janaka Ranabahu* >> Senior Software Engineer; WSO2 Inc.; http://wso2.com >> >> >> *E-mail: jan...@wso2.com <http://wso2.com>**M: **+94 718370861 >> <%2B94%20718370861>* >> >> 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 > -- 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
