Hi 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. > Maybe I raised my question in a wrong manner. I'm not talking about introducing a new deployer. Please see my comments below. Also please let me know whether I'm raising a invalid question. > > 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. >>>> >>>> The following section maps directly with the existing <Deployer> section in the appfactory.xml which we already defines for each stage. > <Runtime> >>>> >>>> <Runtime>appserver</Runtime> >>>> >>>> >>>> <ClassName>org.wso2.carbon.appfactory.jenkins.deploy.JenkinsArtifactDeployer</ClassName> >>>> >>>> <Endpoint>https://sc.s2.AF_HOST:9463/services/</Endpoint> >>>> >>> This endpoint is different from one environment to another even for a single runtime. > <RepositoryProvider> >>>> >>>> >>>> <ProviderClass>org.wso2.carbon.appfactory.s4.integration.GITBlitBasedGITRepositoryProvider</ProviderClass> >>>> >>>> <BaseURL>https://gitblit.s2.wso2.com:8444/</BaseURL> >>>> >>>> <URLPattern>{@stage}/as</URLPattern> >>>> >>> This URL pattern also different from one environment to another even for a single runtime. Previously we had 3 such configurations which defines these changing properties of a runtime environment. My question is, if we are defining a runtime of a new apptype how are we going to map the lifecycle stages of that apptype with the runtime? Thanks, Janaka <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 > -- *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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
