Bugzilla – Full Text Bug Listing
| Summary: | New Hudson needs easier JVM selection | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Carver <d_a_carver> |
| Component: | CI-Jenkins | Assignee: | CI Admin Inbox <ci.admin-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, denis.roy, thomas, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Carver
I second this. As things stands now, jobs must be locked to specific instances. Is the issue that the current labels are to verbose, or that jobs configured to run with Java 5 64bit(SUN) on the master fall over and die on the slaves? My understanding is that as long as the slaves have the tools in the same 'locations'(they do, it's all on NFS) as the master instance then they shouldn't/don't need any special configuration tweaks, it should just work. Is that not true? I understand that right now this works because we have a homogenized master/slave configuration, and if we were to add say a Mac running Amiga OS that it could need custom tool locations specified to match those currently on offer(if possible/available). The 32/64 options are to allow you(the project) to configure your build as you see fit, as the master and slaves all have 32bit compatibility turned on. I'm certainly willing to remove all of the PPC options, if those are cluttering the list. -M. (In reply to comment #2) > Is the issue that the current labels are to verbose, or that jobs configured to > run with Java 5 64bit(SUN) on the master fall over and die on the slaves? > I'm certainly willing to remove all of the PPC options, if those are cluttering > the list. So if I select a 64bit JVM, and the system it runs on is a 32bit only slave, is the 64bit option on the 32bit slave configured to correctly use the 32bit JVM? Basically if the option is not available on the slave machine there will be issues if it isn't configured to use the appropriate jvm for that machine. Please remove the PPC from the list. As if/when the old machine is added as a build machine, it's JVMs can fall under one of the existing categories. It would also be good to document this on a Wiki somewhere so that when committers are configuring their jobs they understand what is available. Wouldn't the solution be to have a directory that is not NFS mounted? I mean, let's decide on a root folder where the JVM's are stored. Let each platform have their own copy of this folder and then store the JVM's there. The layout could be: /jvmfolder/ java-1.4 java-1.5 java-1.6 java-1.7 This will be what the Hudson instance is pointing to. The java-xxx is of course links to the best Java installation of xxx version on that particular platform. Buckminster and other tools that need platform specific installations could use a similar setup. > So if I select a 64bit JVM, and the system it runs on is a 32bit only slave, is > the 64bit option on the 32bit slave configured to correctly use the 32bit JVM? Yes in that case we will need to tweak the configuration to get the slave as close as possible to the master. However at this time I'm not aware of any plans to add dedicated hardware that wouldn't be the same as our current slaves/master(the windows slave being an exception). > Basically if the option is not available on the slave machine there will be > issues if it isn't configured to use the appropriate jvm for that machine. So my take away from this is that I should update the windows slave config to mirror these choices and to 'remap' 64bit requests to the 32bit JVM that is installed, and remove the 'windows' slave items. No problem. > Please remove the PPC from the list. As if/when the old machine is added as a > build machine, it's JVMs can fall under one of the existing categories. They're gone. > It would also be good to document this on a Wiki somewhere so that when > committers are configuring their jobs they understand what is available. I've started this here: wiki.eclipse.org/hudson . (In reply to comment #4) > Wouldn't the solution be to have a directory that is not NFS mounted? With a single directory for tools shared between the master and slaves, any tool added for the master(or slave), is instantly available on the others with no extra overhead. If we didn't have such a homogenized setup then you're right, we would have to create a 'default' path structure and so on. -M. > (In reply to comment #4) > > Wouldn't the solution be to have a directory that is not NFS mounted? > > With a single directory for tools shared between the master and slaves, any > tool added for the master(or slave), is instantly available on the others with > no extra overhead. > > If we didn't have such a homogenized setup then you're right, we would have to > create a 'default' path structure and so on. Well, remember, Hudson also has the ability to download and install software if it is missing on the slave. The Hudson wiki also has an example slave configuration. http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix Since we have a homogenized setup, the example above doesn't apply, but I still think it might be good to allow Hudson to download what it needs, but that is just my personal feeling. (In reply to comment #5) > With a single directory for tools shared between the master and slaves, any > tool added for the master(or slave), is instantly available on the others with > no extra overhead. > I was referring to platform specific tools. They cannot be shared so when adding it to a master, it's actually destructive to make it available on the slaves unless they share the same architecture. If you want to make a java-1.7 available for instance, then you are really forced to install one linux.86, one ppc64, and one windows7 version of that. From Hudsons perspective, only one should be available at any one platform ant it should be available using the name java-1.7. Is this still an issue? -M. I suppose not. |