Community
Participate
Working Groups
The TCF project would like to request a vserver. Our target agents run binary compiled code, and in order to test those agents as part of our unittest suite, we need to run virtualbox images for multiple distributions and OS's on which we can test the agent. We have all the infrastructure set up, now we just need a vserver to deploy at Eclipse.org such that our tests run Open and Transparent in the public.
SLES 11 SP3 with 30G disk and 2G RAM is what we typically provide. Will those specifications meet your needs?
Will SLES 11 SP3 vserver be able to run VirtualBox? It is running virtualization software as guest of another virualization software. I'm not sure how that will work. A virtual Linux target takes about 5 GB disk space. If we create VirtualBox VMs to test major Linux distros, e.g. SUSE, Ubuntu, CentOS, Fedora, both 32 and 64-bit, - 8 targets, about 40 GB. We also would need Windows 7 and 8 VMs - another ~20 GB. Including some room for growth, I think we need at least 100 GB of disk space. 2G RAM should be fine.
In the Eclipse SCADA project we would also need some additional build servers 32bit, 64bit, arm, win32 (7), Ubuntu (12.04LTS), RHEL/Centos (6+), ... Since we do not run virtual machines inside that boxes, we could easily live with a virtual machine guest. The reason for this is that we compile some native code and we would like to host this compiling at Eclipse.
> Will SLES 11 SP3 vserver be able to run VirtualBox [snip] to test major Linux > distros, e.g. SUSE, Ubuntu, CentOS, Fedora, both 32 > and 64-bit I don't know if VirtualBox will run on Xen, but I don't think it makes sense. Looking at the bigger picture, I suspect most projects will (eventually) want to test against all those same platforms. Just a quick question: if your HIPP came magically configured with one slave process on Ubuntu, Fedora, CentOS, Win7 & Win8, would that satisfy the requirement? I'm not suggesting we do this right now... But I'm seeing patterns and I'm trying to find the easiest solution for everyone.
(In reply to Denis Roy from comment #4) > Just a quick question: if your HIPP came magically configured with one slave > process on Ubuntu, Fedora, CentOS, Win7 & Win8, would that satisfy the > requirement? Well for Eclipse SCADA this seems to be a working solution. We could then trigger the differents builds (mostly .deb and .rpm) automatically and gather the results in the hudson instance or the file system (if they would have the same shared file system).
> system (if they would have the same shared file system). For *nix systems (and maybe Macs) I can see them share our authentication mechanisms and shared filesystems (Thanh: read this as "hipp10 could be a Debian machine, and hipp11 could be a CentOS machine"). But for Windows, I doubt I will even be open minded enough to allow a Windows machine anywhere near our backend networks. For the foreseeable future, let's assume Windows machines are external to us.
(In reply to Denis Roy from comment #4) > Just a quick question: if your HIPP came magically configured with one slave > process on Ubuntu, Fedora, CentOS, Win7 & Win8, would that satisfy the > requirement? It would work for TCF testing.
(In reply to Denis Roy from comment #6) > But for Windows, I doubt I will even be open minded enough to allow a > Windows machine anywhere near our backend networks. For the foreseeable > future, let's assume Windows machines are external to us. What does "external do us" mean? Is is possible that we (Eclipse SCADA) build stuff elsewere and upload it to download.eclipse.org using our own build server?
> What does "external do us" mean? Is is possible that we (Eclipse SCADA) > build stuff elsewere and upload it to download.eclipse.org using our own > build server? You are under no obligation to use our build services. You can build remotely and upload to download.eclipse.org for distribution.
What's the status of this? Do we need to provide anything?
(In reply to Denis Roy from comment #10) > What's the status of this? Do we need to provide anything? For build/test automation in TCF project, we maintain a collection of virtual machines with all kinds/versions of OSes. We need ability to launch these virtual machines, one at a time, to build/test the project software. "SLES 11 SP3 with 30G disk and 2G RAM" is not what we need. It is just one virtual machine, while we need access to virtualization software itself as a service. > Just a quick question: if your HIPP came magically configured with one slave > process on Ubuntu, Fedora, CentOS, Win7 & Win8, would that satisfy the > requirement? This would work too, but ability to run our own virtual machines would be better.
> For build/test automation in TCF project, we maintain a collection of > virtual machines with all kinds/versions of OSes. We need ability to launch > these virtual machines, one at a time, to build/test the project software. Unfortunately, we don't offer such a service.
