The modified interface abstraction to get repository information, create or
add repositories will be as follows:
Interface name: RepositoryManager
Methods:
void addRepository ();
- add a repository created by a tenant.
void provisionRepository ();
- create a repository on behalf of a tenant.
RepositoryInformation getReopsitoryInformation ();
- retrieve repository information such as url, user name and password,
etc.
On Sun, Apr 28, 2013 at 10:58 PM, Isuru Haththotuwa <[email protected]> wrote:
> The proposed interface for RepositoryInformationProvider tentatively would
> have a single method:
>
> public RepositoryInformation getRepositoryInformation(int tenantId);
>
> RepositoryInformation instance would hold data of the remote repository
> for the tenant, such as url, username, password, etc.
>
>
> On Wed, Apr 24, 2013 at 4:13 PM, Pradeep Fernando <[email protected]>wrote:
>
>>
>> Hi Isuru,
>>
>> On Wed, Apr 24, 2013 at 12:39 PM, Isuru Haththotuwa <[email protected]>wrote:
>>
>>> The main limitations with the current architecture related to
>>> generalizing the implementation are identified as follows:
>>>
>>> 1. The dependency on S2 based environment to get the information about
>>> the repositories for the tenants:
>>>
>>> A potential solution would be to abstract out the implementation for a
>>> repository information provider so that it can manage both the single
>>> repository (standard deployment), multiple repository (S2 / specialized
>>> deployment) and any other scenarios.
>>>
>>> 2. Usage of deployment synchronization messages in standard and S2
>>> deployments:
>>>
>>> In the current implementation, the ADC will send a
>>> GroupManagementCommand (a deployment synchronization message) when there
>>> are updates in the repository. The standard Deployment Synchronization
>>> message has been programatically disabled from the git based deployment
>>> synchronizer component, which is an incorrect thing to do.
>>>
>>> It was decided to hold a separate discussion on this to come up with a
>>> proper architecture for usage of deployment synchronization messages in
>>> different environments (standard and S2 environment).
>>>
>>
>> please go ahead and schedule.
>>
>>>
>>> 3. Supporting ghost deployment of artifacts:
>>>
>>> Svn based deployment synchronizer supports ghost deployment of artifacts
>>> through svn partial checkouts. Git doesn't support partial checkouts, so
>>> this is a potential problem. There may be workarounds available, need to
>>> research on this.
>>>
>>>
>>> On Fri, Apr 19, 2013 at 6:21 PM, Isuru Haththotuwa <[email protected]>wrote:
>>>
>>>> The Git based Deployment Synchronizer developed for Stratos 2 supports
>>>> Git repositories per tenant, which is a significant difference from other
>>>> Deployment Synchronizers (SVN depsync, etc). Therefore Git Depsync has to
>>>> query a service to obtain the git repository URLs and the credentials for
>>>> the repositories for each tenant at run time. In the SVN depsync, a single
>>>> repo is used and it's defined in the carbon.xml.
>>>>
>>>> Because of this, it is not possible to use the Git Depsync to in a
>>>> normal worker manager separation, in a similar way as SVN Depsync. To use
>>>> it in the worker manager separated setup, we can either create another
>>>> component which is similar to SVN depsync which uses a single repository,
>>>> or else generalize this implementation so that it can be used in both S2
>>>> scenario (with repos per tenant) and in normal worker manager separation
>>>> (single repo).
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
>
>
>
--
Thanks and Regards,
Isuru H.
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
