By cormander
I’ve been working a lot with Tim Post these past few months of various things. He’s been a great mentor among other things. One thing that he is (that I am not) is a debian guy. This works well for the both of us, since I’m a RedHat guy and he isn’t. This creates quite the dynamic between the two of us on how we approach different issues.
One of the things we’ve been working to get going is gridnix, a linux distribution of our own. I’ve pulled Tim in my direction enough to be OK with the idea of using RHEL as a base for the OS, with our own various packages on top of it (and replacing some of the base os, such as coreutils). To this end, I’ve put together my Red Beret yum repo, to use for both gridnix and anyone else in the RHEL/CentOS community who would like to use these updated packages.
I, however, have been unable to pull him all the way in. He refuses to use yum, all for reasons I don’t have a good counter for. So I’ve decided to settle, and agree to use apt’s rpm port. So I looked to Dag Wieers’ site, since he’s the (perhaps only) CentOS core developer who uses apt. I read through his apt tutorial using apt in an rpm world and got myself up with it. So far so good.
This reminds me of what Scott Shinn has to say about the whole thing … he likes to joke that Dag has been converted to the dark side, since he’s kept yum at arm’s length. Well, turns out I’m headed in his direction. The apt utility has a lot of advantages over yum.
By cormander
Here is my proposed architecture for Xen being incorporated into RavenCore:
* Everything is based on a resource, eg; CPU, memory, disk, IP addresses, etc
* Resources are “detected” when you add a dom0 (xen host) to the cluster
* The total number of resources in the cluster are put into the “Administrative Resource Pool”
* The admin user create clients, and can assign them resources. The total number of client resources cannot exceed the amount in the admin pool (for obvious reasons)
* The clients can then use those resources to allocate as many virtual machines as they like – one big virtual machine using it all, or many small ones using a small portion each.
* A virtual machine, if desired, can be defined as a “shared host” and that client then has administrative rights to the provisioning of domains, email, etc on that virtual host. Basically, they get RavenCore as it is today on that VM
* If you add a server to the cluster that is not a dom0, it can still be defined as a “shared host” and either assigned to a client (who will become the admin of it) or just create clients on it directly.
What I want to stay away from in this design, for now, is hardware dependency. In particular, dependency on storage. To start with anyway, I’m not going to build in logic in the interface for things like a SAN. If you have one – great – you will be able to use it, but disk configuration is manual. Basically, when you install the control panel, you tell it what disk(s) you’d like to put into the admin pool. You have to manually create them (either fs files with dd, or a physical disk itself, or LVM logical volumes) and then point to them from the interface.
By cormander
For those of you that have been wondering, I’ve been spending a lot of my free time working with my good friend Tim Post working on a project called gridnix.
I’ll mostly be doing userspace applications and packaging, but so far my main contribution has been the kernel for the OS. I just recently posted all my patches to the kernel to a git tree:
http://git.ravencore.com/?p=kernel/linux-2.6.24.7-gridnix.git;a=summary
The tree is lacking config and build scripts at the moment, but it’ll build just fine as-is. A little later we’ll be adding those scripts to easilly build different kernel variants such as a xen dom0 kernel or a full fledged grsecurity kernel.
