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