HI Janaka,

We have decided to leave out 2nd and 3rd options go with the 1st option.
Comments are inline.



On Mon, Jul 29, 2013 at 10:37 AM, Janaka Ranabahu <jan...@wso2.com> wrote:

> Hi Shamika,
>
>
> On Wed, Jul 24, 2013 at 5:20 PM, Ajanthan Balachandran 
> <ajant...@wso2.com>wrote:
>
>>
>>
>>
>> On Wed, Jul 24, 2013 at 4:34 PM, Shamika Ariyawansa <sham...@wso2.com>wrote:
>>
>>> HI,
>>>
>>> As we discussed so fa,r we tried/trying following approaches for the
>>> $subject.
>>>
>>> 1. Deploying Jenkins web app in AS per tenant. - Solution was not
>>> scalable due to the size of the Jenkins Web-app (61MB - without plugins)
>>> and its not practicable to deploy this as the tenant count gets increased.
>>>
>> If the content of the war duplicated for tenants you can put the common
>> libs into $CARBON_HOME/repository/components/lib(in parent classloader) and
>> make minimal war file that contains tenant specific stuffs.
>>
> How will this handle the load of a build job? Say that each of these
> Jenkins server instances can run a number of build jobs(more than 1 build
> per tenant). How can we handle the concurrent build load?
>

      As Ajanthan suggested we are going to minimize the Jenkins app by
removing common components and plugins and making them available as common
libraries. We tried that on a Tomcat instance and worked fine. Now working
on that on AS. This Jenkins app per tenant work as the Master. We could
have multiple slaves per tenant and handle the load. Later we can have a
slave pool where all the masters can share the slaves on demand depending
on the work.


>
>>> 2. Use one Jenkins server and make it possible to make it multi-tenant
>>> by introducing a role-based plugin (an extension to Role-Strategy Plugin).
>>>
>>> Here all the tenants related jobs are stored in one space
>>> (no operation between tenant) and the multi-tenancy is achieved by having a
>>> filtering mechanism based on the logged users tenant. Problem here is
>>> everything will be done in one workspace so it will be difficult to manage
>>> when the the tenant count gets increased with the job count.
>>>
>> Jenkins has lots of extension points. Can we have a concept of
> folders/collections in Jenkins jobs? If so we can group jobs by tenant.
> This could be done as a part of the Role-Strategy plugin.
>

 As a found  so far there is no such categorization available and not
possible since they have one JENKINS_HOME per instance. Since it is storing
all the jobs in once location, it is not scalable either even though we
could have come up with a role-based plugin to filter them out by the
tenant.

>
>>> 3. Patch the Jenkins to set the JENKINS_HOME directory on the fly so
>>> that separate HOME directory will be used for the different tenants.
>>>
>>> By looking at the Jenkins code we found that the Jenkins Home is set to
>>> a singleton class (jenkins.model.Jenkins) and the whole system uses that
>>> class to obtain JENKINS HOME. As a solution we can update this class to
>>> return JENKINS_HOME based on logged users tenant.
>>>
>>> Main risk for this is that in the  in above class has a public variable
>>> to store the JENKINS_HOME (variable - root). Also there is also an
>>> encapsulated method to get this too.( getRootDir() ). We are not sure the
>>> how the other plugins have referred this. I am trying to do an hard-coded
>>> test whether this works or not?
>>>
>> This will not work unless you reload all the configurations from disk
>> after returning the JENKINS_HOME.In jenkins on start up all the config
>> files are loaded from disk(job configs also).We change JENKINS_HOME at the
>> middle  but still in the memory there are configs(job configs) from
>> previous JENKINS_HOME.
>>
> We should be able to work with an existing Jenkins deployment without
> doing any modifications to the code. If this can be done through a plugin,
> then I guess it is fine. Otherwise I'm -1 for this.
>

Yes ass you pointed out, this would be not a good option if we cant do it
as a plugin. Also the way they have written the code this modification is
not realistic.


> Thanks,
> Janaka
>
>>
>>> WDYT?
>>>
>>> --
>>> Shamika Ariyawansa
>>> Senior Software Engineer
>>>
>>> Mob:+ 94 772929486
>>>
>>
>>
>>
>> --
>> ajanthan
>> --
>> Ajanthan Balachandiran
>> Senior Software Engineer;
>> Solutions Technologies Team ;WSO2, Inc.;  http://wso2.com/
>>
>> email: ajanthan <http://goog_595075977>@wso2.com; cell: +94775581497
>> blog: http://bkayts.blogspot.com/
>>
>> Lean . Enterprise . Middleware
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Janaka Ranabahu*
> Senior Software Engineer; WSO2 Inc.; http://wso2.com*
>
> E-mail: jan...@wso2.com
> **M: **+94 718370861*
> *
>
> *Lean . Enterprise . Middleware
>
>


-- 
Shamika Ariyawansa
Senior Software Engineer

Mob:+ 94 772929486
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to