(Moving this to oi-dev)
On 27/05/2012 16:47, Jim Klimov wrote:
2012-05-27 4:15, Alasdair Lumsden wrote:
As project lead I can tell you that we won't be doing SPARC
unless someone comes along and takes ownership of that project,
and we definitely won't ever be doing SVR4 packaging as long
as I'm project lead.
"No Bart, you cannot have the cookie now after all.
Your mother made a very loud point!" (C) The Simpsons
Sorry :-) I subscribe very strongly to the design principles of IPS
which came about due to shortcomings in SVR4. IPS may have some
implementation weaknesses, but it admirably solves the problems it set
out to and in my experience works very well indeed.
When people pine for the days of SVR4 I just get annoyed, because it's
trying to undo progress. Yes, IPS requires retooling and relearning, but
ultimately IMHO it's very worth it.
There are a number of blog posts on this topic by Stephen Hahn:
https://blogs.oracle.com/sch/entry/observations_on_packaging
(Click next through the blog posts as there's quite a few)
I think, supporting the minimal-interruption *migration*
from legacy (SVR4) systems would be more important to me
than an SVR4-based distro, especially if that option is
so firmly fought against.
However, comfortable migration "should" support running
legacy local (fullroot) zone roots provided as-is (i.e.
without IPS packaging), even if not directly supporting
installation of such (SVR4) zones with OI.
Do you loudly object even to that?
No, and if a sound implementation was presented for us to integrate I'm
sure we would.
However as unpaid volunteers working on a community project we need to
stay focused on what's important, and right now that's things like:
1. Getting our /stable release out
2. Sorting out /experimental and our release engineering processes
3. Updating software, fixing security holes, fixing bugs
Then to clarify:
1) SVR4 support: as I see - at the moment SVR4 are installable
on OpenIndiana "as is", including the pre/post-scripts, which
is good for those legacy users who can't/won't migrate for
whatever their reasoning is. Is this going to remain in place,
or are there plans to rip out pkgadd,etc. and still claim
being "the upgrade path"? ;)
There are no plans to rip it out.
One limitation that I see however, is that an SVR4 package
installed in GZ does not get auto-installed/updated in LZ...
Oh well, that's likely an IPS brand thing...
That's by design. SVR4 package installation is there as a compatibility
thing and not for general systems management. IPS branded zones are
effectively isolated containers with their own private package sets. A
fresh zone gets a minimal set of software.
2) Is there a documented and/or scripted upgrade path for
users of SVR4-based systems to export-import their zones
into an IPS system (i.e. use same-named SUNW* package names
if available via IPS and update them from an old SXCE/Sol10
image to the current OI baseline upon zone import)?
Something simple, working in-place on (a clone of) the old
zone dataset, and that would not require reinstalling the
whole set of zones and manually migrating the settings, data,
installed third-party programs (packaged or standalone)?
That would be a huge amount of work. Things have changed so very much
since Sol10 and SXCE that there is no 1:1 direct mapping any more and
most software would just break horribly.
There are however Solaris 10 branded zones. Potentially that brand could
be adapted to SXCE. The problem is that SXCE was a moving target with
lots of builds.
To the very least, it would suffice if the SXCE zones just
worked "as is" in OpenIndiana, allowing for quick upgrades
of the host OS and little downtime for tasks-in-zones being
upgraded later - alas, they don't, even after some hammering.
Again, you want an SXCE implementation of Solaris 10 branded zones.
The main problem is that the core system software (like the ifconfig,
zfs, etc) commands inside the zones have to be kept in sync with the
global zone. I am not sure how the S10 brand achieves this.
But once it's done you're left with this aging security nightmare
frankenstein of a zone, so why bother?
People are better off investing the time in properly migrating their
legacy apps and data into modern zones. That way you get the latest
software with the latest security updates, in a far more supported fashion.
I appeal to your logical side.
3) Regarding sparse-root zones: does the IPS theory firmly
forbid the sparse-root zones with their benefits of faster
provisioning, smaller footprint on disk/RAM/cache, fast
propagation of OS-wide updates, and whatever else people
liked about them? Or is it possible to tame IPS code into
compatibility with the concept of sparse read-only rootfs
(/usr, /lib...)?
As far as I know sparse zones support was never a design goal. Oracle
employ a team of people to maintain IPS and what you're asking for would
be a major deviation from their work, effectively a fork. If you're
volunteering to quit your job and work on it full time then perhaps it
might be viable, but otherwise it's probably not going to happen.
The easiest route to sparse zones on OI is to do a SmartOS-style branded
zone, which combines a zfs template supplying a skeleton filesystem
(/etc, /var etc) and loopback mount /usr from the global zone, perhaps
with a filter so only a defined list of files get passed through.
The user could then run whatever they want in the Zone, for example
pkgsrc or s10-userland.
Ultimately we have to be pragmatic with the resources we have. We can't
be all things to all people and we have to focus on what matters to our
wider user base.
PS: What is so inherently bad about SVR4 which is not bad
in DEB, RPM, etc.? :)
To be honest I hate all 3 of those package managers. I'm a massive IPS
convert. It just feels designed - like ZFS. It's packaging done correctly.
Like any system, IPS has drawbacks (it requires a lot of CPU grunt and
network resources), but these are not an issue in a modern datacenter
environment. We selected to use it for our business on Solaris 10 and
SmartOS and have been enormously pleased with the results:
http://s10.pkg.ec/
http://smartos.pkg.ec/
We have this deployed on hundreds of customer zones and it makes
administrating them a breeze.
What I dislike most about SVR4 isn't the package format itself, but the
people who whinge about wanting it back.
It's gone, what we've got is better, time to move on. Sorry for the pain
but you can't make an omelette without breaking a few eggs.
Cheers,
Alasdair
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
