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
