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
