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