tbox does a few things now, mainly it is just a playground for devs. I'd like to setup a vm replacement for the following reasons: 1) Serve binpkgs for multiple arches in an official manner 2) OSUOSL wants to kill the current tbox since it is a desktop machine
I'd like to add that this vm would NOT need much horsepower and only a moderate amount of disk. However, it would need to allow members from the releng team to push data to it. Maybe a dedicated user with ssh-key that only allows rsync from certain IP's to access it? Alternatively, releng already has a staging server, team members could push data then then this vm could pull from it. Not sure yet.
We have 5 free IPs in our netblock allocation. I need to consult briefly with lance to see how the ganeti network is setup. Are we planning to manage these vms with cfengine? -A
(In reply to comment #2) > We have 5 free IPs in our netblock allocation. > I need to consult briefly with lance to see how the ganeti network is setup. > > Are we planning to manage these vms with cfengine? Wrong place to talk about it. However, I'm not aware of a decision on this yet (I hope so though) > > -A
(In reply to comment #2) > We have 5 free IPs in our netblock allocation. > I need to consult briefly with lance to see how the ganeti network is setup. > > Are we planning to manage these vms with cfengine? > > -A Not all VMs need public IPs. We should setup a some NAT/bash-in box.
For net, we have native HE ipv6, so we can use that. For serving packages, we would need likely need an ipv4 IP. This appears to be a pretty common need, so we might provide a mirror / web service where we sync content from the ipv6-only nodes and serve them to ipv4/6 customers. Please provide your CPU / RAM / DISK requirements (I don't know what modest means in this context.) -A
> Please provide your CPU / RAM / DISK requirements (I don't know what modest > means in this context.) my idea is enough hardware to serve static content only, but i'm not going to pursue this request any longer, releng or someone may want to pick it up
I'll take it. Answering the different questions: Hardware requirements ------------------------------------ Depends, right now tinderbox builds the x86 packages [1] along with serving the other arches packages [2] It also builds the x86 crosscompilers for all arches, along with hosting the amd64 crosscompilers for all arches. In a perfect scenario, we would have 'tinderbox' doing the serving of the built packages, and we would have a x86 VM(not amd64) for building the x86 packages. @grobian: Mind explaining what kind of services do you run on tinderbox? Right now tinderbox.dev.g.o is 1 P4 2.6GHz, 1GB RAM+1GB SWAP. It also has a 36G(28G used) disk and a 160GB(92GB used). So I believe 120GB of space would be enough. Networking ------------------------------------ Well, we're replacing an existing, physical machine, which already has an IPv4 address, so we could reuse that one once everything is migrated. [1] http://tinderbox.dev.gentoo.org/default-linux/x86/ [2] http://tinderbox.dev.gentoo.org/default-linux
with 1GB of ram, I guess the machine is disqualified
(In reply to comment #7) > @grobian: Mind explaining what kind of services do you run on tinderbox? we run rsync slave, nothing more iirc
I've allocated you a VM. It is not ready yet (still building it out). It will be ipv6-only until we migrate the existing ipv4 IP to it. It has 1 vcpu, 2G of ram, and 120G of space. The CPU is an emulated 2.1ghz core. I'll try to have it ready mid-next week; but I am travelling so it may be late. -A
The actual tinderbox.dev.g.o machine had a disk failure. The machine has two disks, one for the system and the other for storage. The latter is the one with the valuable data and the one that has failed.
(In reply to comment #11) > The actual tinderbox.dev.g.o machine had a disk failure. The machine has two > disks, one for the system and the other for storage. The latter is the one > with the valuable data and the one that has failed. ok - I guess the vm (how do I log into that) still has no ipv4?
(In reply to comment #12) > (In reply to comment #11) > > The actual tinderbox.dev.g.o machine had a disk failure. The machine has two > > disks, one for the system and the other for storage. The latter is the one > > with the valuable data and the one that has failed. > > ok - I guess the vm (how do I log into that) still has no ipv4? There's no VM yet...(/me stabs antarus), my plan was to use current tinderbox's ipv4 for the VM.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > The actual tinderbox.dev.g.o machine had a disk failure. The machine has two > > > disks, one for the system and the other for storage. The latter is the one > > > with the valuable data and the one that has failed. > > > > ok - I guess the vm (how do I log into that) still has no ipv4? > > There's no VM yet...(/me stabs antarus), my plan was to use current > tinderbox's ipv4 for the VM. The change from the physical machine to the VM was done at the end of February and its been working fine. Also the old physical machine was decommissioned at the same time. I'm closing this bug. @Fabian: if you want access to it, please send me your pubkey to my mail. Thanks
