Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Hudson » Enterprise issues with the Team Concept
Enterprise issues with the Team Concept [message #1229482] Thu, 09 January 2014 14:35 Go to next message
Joel F is currently offline Joel F
Messages: 10
Registered: March 2013
Junior Member
I run a Hudson server with ~600 jobs and around 25-30 active builds that use sets of these jobs, each of which is grouped by a tab. This doesn't scale well as you have to scroll horizontally to see a lot of the tabs (and to login, for that matter.)

I was happy to see the Team concept, as we could easily break these builds out into a number of teams so that the scalability issue is solved. I was surprised to see that issues that have to do with scalability, which I assumed was much of the point of Teams, were not addressed. Here is a list:

* All tabs exist for everyone. I was hoping that tabs could be associated with teams. This alone means that Teams does not solve the main issue.

* A sysadmin sees all jobs. This basically means that you need a seperate sysadmin login for anyone that needs to manage teams. Either that, or a sysadmin does not benefit from the team concept. For example, I am both sysadmin and a user of hudson. I don't want to see other team's jobs, so I had to have IT create an LDAP service account so that I have a seperate sysadmin login. They don't really want to have to do this for the 4 other users who also should be sysadmins. In other enterprise tools I use, this is handled by temporary elevation of access while logged in (see JIRA,Confluence, etc.), AKA 'websudo'.

* There is no bulk way to migrate sets of jobs to a team. (for instance, by regex or wildcard.) I had to click 600 checkboxes to migrate my jobs. I originally started to script it by modifying the XML but then realized there was so much to track because of job renaming etc. that I gave up because I would have spent more time debugging and fixing things than just brute force migration.

Teams looks promising but at this point it really does not solve any problems. It may make security a little easier for sets of jobs, but frankly that's not really an issue in a typical company. That is, our prior security was to allow those 15-odd users who manage jobs access to configure and build any job, and trust them to only work with theirs. Never had an issue. Scalability is the primary issue, and this is not solved.

If the tab issue could be fixed, that could go a very long way. And the 'websudo' would be nice, even if it was a simple sysadmin toggle next to your username.

Hope this is helpful.
Re: Enterprise issues with the Team Concept [message #1229619 is a reply to message #1229482] Thu, 09 January 2014 20:56 Go to previous message
Winston Prakash is currently offline Winston Prakash
Messages: 426
Registered: August 2011
Location: Fremont, CA USA
Senior Member
Hi Joel thanks for the comments. We are expecting exactly this kind of feed back to improve the functionalities in Hudson.

Added the requests to https://wiki.eclipse.org/Hudson-ci/features/Team_Concept#Future_Enhancement_requests


> All tabs exist for everyone. I was hoping that tabs could be associated with teams.

Agree, associating View Tabs to teams would be a good enhancement. In a Team Management setup you don't need that many tabs right?


> A sysadmin sees all jobs. This basically means that you need a seperate sysadmin login for anyone that needs to manage teams.

We designed sysadmin as a super user. You are right, just for the purpose of creating teams, you don't have to give the full sysadmin power to a user. Thanks for the "websudo" hint we will look in to that. Other option is to create permission scheme for sysadmin, with authorization such as all power, manage slaves, create team etc

> There is no bulk way to migrate sets of jobs to a team.

Bob Foster wrote a plugin (https://github.com/hudson3-plugins/copy-team-cli-plugin) that adds a CLI to copy teams (jobs from a team to a newly created team). This could be modified to take a list of job names (in a file) and move those from one team (or initial public) to any team.

Additionally, we are also thinking in the direction of isolating slaves per team. Means, allow Team Admin to create slaves that can be used only to execute jobs from that specific team.



Winston Prakash
Eclipse Hudson team

[Updated on: Thu, 09 January 2014 20:57]

Report message to a moderator

Previous Topic:Multiconfiguration job and setting build description
Next Topic:Push notification from GIT is missing in Hudson
Goto Forum:
  


Current Time: Thu Oct 23 01:57:01 GMT 2014

Powered by FUDForum. Page generated in 0.06853 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software