Hi shamika ,

When you minimize the replication of runtime of jenkins , I think you can
create SharedEnvironment  and Exclusive environment to load the jars for
JENKINS.



*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* <http://www.apache.org/>**
email: **[email protected]* <[email protected]>* cell: +94 71 5186770**
twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>**
harshathirimann
linked-in: **http: <http://lk.linkedin.com/in/afkhamazeez>**//
www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*
*
*
*Lean . Enterprise . Middleware*
*
*


On Mon, Jul 29, 2013 at 2:22 AM, Janaka Ranabahu <[email protected]> wrote:

> Hi Shamika,
>
> On Mon, Jul 29, 2013 at 11:31 AM, Shamika Ariyawansa <[email protected]>wrote:
>
>> 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 <[email protected]>wrote:
>>
>>> Hi Shamika,
>>>
>>>
>>> On Wed, Jul 24, 2013 at 5:20 PM, Ajanthan Balachandran <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 24, 2013 at 4:34 PM, Shamika Ariyawansa 
>>>> <[email protected]>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.
>>
> I guess you can use [1] for spawning instances on demand(haven't tried
> this yet).
>
> Thanks,
> Janaka
>
> [1] https://wiki.jenkins-ci.org/display/JENKINS/Scripted+Cloud+plugin
>
>
>>
>>
>>>
>>>>> 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
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Janaka Ranabahu*
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com*
>>>
>>> E-mail: [email protected]
>>> **M: **+94 718370861*
>>> *
>>>
>>> *Lean . Enterprise . Middleware
>>>
>>>
>>
>>
>> --
>> Shamika Ariyawansa
>> Senior Software Engineer
>>
>> Mob:+ 94 772929486
>>
>
>
>
> --
> *Janaka Ranabahu*
> Senior Software Engineer; WSO2 Inc.; http://wso2.com*
>
> E-mail: [email protected]
> **M: **+94 718370861**
>
> *Lean . Enterprise . Middleware
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to