What we need from an Illumos-based distribution
It started on Twitter:
@thatcks: Current status: depressing myself by looking at the status of Illumos distributions. There's nothing else like OmniOS out there.
@ptribble: So what are the values of OmniOS that are important to you and you feel aren't present in other illumos distributions?
This is an excellent question from Peter Tribble of Tribblix and it deserves a more elaborate answer than I could really give it on Twitter. So here's my take on what we need from an Illumos distribution.
- A traditional Unix server environment that will
do NFS fileservice with ZFS, because we already have a lot of
tooling and expertise in running such an Illumos-based environment
and our current environment has a very
particular setup due to local needs. If we have to completely
change how we design and operate NFS fileservice (for example to
move to a more 'storage appliance' environment), the advantages
of continuing with Illumos mostly go away. If we're going to have
to drastically redesign our environment no matter what, maybe the
simpler redesign is 'move to ZFS on FreeBSD doing NFS service as
a traditional Unix server'.
- A distribution that is actively 'developed', by which I mean that it
incorporates upstream changes from Illumos and other sources on
a regular basis and the installer is updated as necessary and so
on. Illumos is not a static thing; there's important evolution
in ZFS fixes and improvements, hardware drivers, and various other
components.
- Periodic stable releases that are supported with security updates
and important bug fixes for a few years but that do not get
wholesale rolling updates from upstream Illumos. We need this
because testing, qualifying, and updating to a whole new release
(with a wide assortment of changes) is a very large amount of
work and risk. We can't possibly do it on a regular basis, such
as every six months; even once a year is too much. Two years of
support is probably our practical minimum.
We could probably live with 'security updates only', although it'd be nice to be able to get high priority bug fixes as well (here I'm thinking of things that will crash your kernel or cause ZFS corruption, which are very close to 'must fix somehow' issues for people running ZFS fileservers).
We don't need the ability to upgrade from stable release to stable release. For various reasons we're probably always going to upgrade by installing from scratch on new system disks and then swapping things around in downtimes.
- An installer that lets us install systems from USB sticks or DVD images and doesn't require complicated backend infrastructure. We're not interested in big complex environments where we have to PXE-boot initial installs of servers, possibly with various additional systems to auto-configure them and tell them what to do.
In a world with pkgsrc and similar sources of pre-built and generally maintained packages, I don't think we need the distribution itself to have very many packages (I'm using the very specific 'we' here, meaning my group and our fileservers). Sure, it would be convenient for us if the distribution shipped with Postfix and Python and a few other important things, but it's not essential the way the core of Illumos is. While it would be ideal if the distribution owned everything important the way that Debian, FreeBSD, and so on do, it doesn't seem like Illumos distributions are going to have that kind of person-hours available, even for a relatively small package collection.
With that said I don't need for all packages to come from pkgsrc or whatever; I'm perfectly happy to have a mix of maintained packages from several sources, including the distribution in either their main source or an 'additional packages we use' repository. Since there's probably not going to be a plain-server NFS fileserver focused Illumos distribution, I'd expect any traditional Unix style distribution to have additional interests that lead to them packaging and maintaining some extra packages, whether that's for web service or X desktops or whatever.
(I also don't care about the package format that the distribution uses. If sticking with IPS is the easy way, that's fine. Neither IPS nor pkgsrc are among my favorite package management systems, but I can live with them.)
Out of all of our needs, I expect the 'stable releases' part to be the biggest problem. Stable releases are a hassle for distribution maintainers (or really for maintainers of anything); you have to maintain multiple versions and you may have to backport a steadily increasing amount of things over time. The amount of pain involved in them is why we're probably willing to live with only security updates for a relatively minimal set of packages and not demand backported bugfixes.
(In practice we don't expect to hit new bugs once our fileservers have gone into production and been stable, although it does happen every once in a while.)
Although 10G Ethernet support is very important to us in general, I'm not putting it on this list because I consider it a general Illumos issue, not something that's going to be specific to any particular distribution. If Illumos as a whole has viable 10G Ethernet for us, any reasonably up to date distribution should pick it up, and we don't want to use a distribution that's not picking those kind of things up.
Sidebar: My current short views on other Illumos distributions
Peter Tribble also asked what was missing in existing Illumos distributions. Based on an inspection of the Illumos wiki's options, I can split the available distributions into three sets:
- OpenIndiana and Tribblix are developed and more or less traditional
Unix systems, but don't appear to have stable releases that are
maintained for a couple of years; instead there are periodic new
releases with all changes included.
- SmartOS, Nexenta, and napp-it are Illumos based but as far as I can
tell aren't in the form of a traditional Unix system. (I'm not sure
if napp-it is actively updated, but the other two are.)
- the remaining distributions don't seem to be actively developed and may not have maintained stable releases either (I didn't look deeply).
Hopefully you can see why OmniOS hit a sweet spot for us; it is (or was) actively maintained, it has 'long term stable' releases that are supported for a few years, and you get a traditional Unix OS environment and a straightforward installation system.
Comments on this page:
|
|