Great concept, terrible implementation

I’ve mentioned rPath before, as it is the basis for OpenFiler, and other appliances. Now with the mad headlong rush into the misty vapors of cloud computing, they are rebranding as a cloud appliance provider.
Their concept is great. Create a functional software appliance, run it everywhere.
Thats not what i am going to complain about. Its about the implementation.
[rant mode full on]
Its always about the implementation. As the implementation is the thing that drives support.

Ok. So you have this brand spanking new OpenFiler distro. It is based upon rPath. You install it on your new hardware. Only to discover, no driver for some aspect.
No problem. You are proficient at pulling down drivers, and building them.
So you pull down the driver.
And you try to build it.
Ok, oversight. No compiler.
No problem though, as surely, without a doubt, there is a compiler overlay bit, that allows you to do something as esoteric as building a driver you need.
If you are on rPath, the answer is an unequivocal “no”.
Lets take the case I am dealing with right now.
OpenFiler ships with an older driver for a RAID card. We need to update it. It is crashing for the customers, and this is a known problem, with a known solution. You update the driver. Solves the problem.
Can you do this on rPath (which OpenFiler is now built upon)?
No. You cannot.
Read that carefully.
You cannot. Its not that you are not allowed to. You, in the truest sense of the words, lack the ability.
This is not a slam at OpenFiler. It is a reasonable product for what it does. That you cannot update it, is not OpenFiler’s fault, its the thing under OpenFiler that prevents this.
It would be to rPaths credit, if they created a “BUILD DRIVERS HERE” image, which allowed you to, curiously enough, BUILD DRIVERS HERE and import them over to the appliance.
Remarkable concept.
Because, otherwise ….
… anything based upon rPath is effectively unsupportable in the face of driver updates, security updates, etc.
Sure sure sure… its an appliance. Its a black box. Who wants to update a black box?
Maybe a customer who has a known problem, with a known solution? Is this possible? Yes? Yes?
Yes yes … conary update (don’t get me started on conary … I see so many supposedly better mousetraps built to solve largely non-existent problems … ) will let you …
… update whatever is in the latest repository.
But if your driver isn’t there, you are SOL.
Your choices are stark.
First, you can, as is suggested in the OpenFiler fora, simply downgrade to supported hardware.
Second, you can abandon OpenFiler (and rPath).
I’d really like that third option. Download the BUILD DRIVERS HERE appliance. I just pulled down the devimage appliance, and hopefully it or the app2app will provide what we need TO BUILD THE DRIVERS.
Either that, or I could simply pull the right source, find the identical gcc version, build that somewhere else, and then build the driver against this. At least they haven’t taken away ssh (yet).
[end of rant]
The concept behind rPath is very good. Its the implementation that is lacking.
The JeOS and other initiatives, where you don’t actually have to give up your tool chain if you need it (e.g. you can pull it in) is a better implementation.
Then again, rPath demonstrated that, unlike Redhat, you really really don’t need such a huge install radius on your systems. Your installation radius as a function of how wide your dependency trees are. If you want to do network boots, or similar things, smaller is better. Appliances? Smaller is better.
This is the concept behind the modular Linux that was being pushed some years ago. It is a good/correct approach.
Crippling the install so that you cannot fix a problem in the field forcing the customer into a different solution? No so much a good idea.
(yeah, in case you didn’t sense it, I am annoyed by this)

1 thought on “Great concept, terrible implementation”

  1. Disclaimer: I work for rPath.
    I’m sorry you’ve been frustrated by this.
    Generally, under the appliance model, the appliance vendor (in this case OpenFiler) is responsible for releasing updates to released images. The rPath tools are designed to allow the appliance vendor to easily update the manifest that describes the appliance and make those updates available to deployed images.
    Appliances themselves generally do not include development tools, hence the lack of a compiler and associated tools.
    A generic development image for building drivers may not work, depending on how each appliance based on the rPath Appliance Platform has been built. rPath provides for lots of variation of eg. kernel versions and leaves it up to the appliance vendor to determine which versions makes sense for them.
    Ultimately, our design is to give control to the appliance vendor over what components and which versions of those components they ship. We do not make it easy for the end-user to modify the choices that the vendor has made (without creating a derivation of the appliance themselves). I believe that this latter point is the implementation you may be disagreeing with.

Comments are closed.