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
>>
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to