Enda O'Connor wrote:
Jerry Jelinek wrote:
I've been spending some time researching ideas for how we could upgrade
Solaris 10 once its installed in a solaris10 branded zone on S.next.
We won't need this capability until S10u9 is released, but I want to make
sure we do whatever we need to do now in order to enable this for the
future.
I have two possibilities in mind. Each of these is project level in its
own right, so I assume we will only actually be able to do one of the
options.
1) Make live-upgrade work inside the solaris10 branded zone
I've been looking at the LU code to try to see what might be
involved.
There is no way we can emulate for this. We would have to do a
project
in the S10u9 LU code to make it solaris10 branded zone aware and
enhance
the code to make it work for upgrade inside the zone. There are
various
issues, such as ZFS pool awareness, mnttab parsing, file system
mounting,
grub awareness, etc. which would have to be coded around or
changed. To
enable this for the future I think we would have to set up the
solaris10
zone now using a ZFS root dataset model similar to what we're
doing today
with the ipkg brand on OpenSolaris.
Pros:
a) The zone sysadmin would be in control of the upgrade.
b) The user would be using a S10 tool to upgrade the zone (even
though that tool will have been enhanced to be solaris10 zone
aware).
c) The zone admin could use LU ABEs to apply patches to their zone.
Cons:
a) We don't know this code.
b) This is S10-only code that would have be enhanced.
c) This is closed source so no community involvement.
d) This is complex, legacy code which is a hairball.
that is the mild way of putting it, this code is a tangle of scripts and
some C code, it took a a lot of work to iron out the issues that the
zones on zfs + sparc new boot features introduced in u6 prior to
releasing u6, and some work after release as well.
This code is hard to maintain as is, unfortunately.
While this would probably be the best way to go, I feel that that pain
might be unbearable for all involved.
I'd suggest talking to Mark Musante to get his opinion of LU as he did a
lot if not most of the zfs part of u6 LU integration.
Just my opinion
Enda
I always thought a LU respin/refratoring was in order(S10 time frame),
just to make it "more maintainable" and this would sure force the issue,
cuz this would seem to be a non-trivial addition... this would make the
customer base very happy, given the life that LU has take on due to the
advocacy some in the field organizations have supplied, but on the
other had from an engineering point of view is it really worth it??? Iv
hacked at it more than was my fair share given my former roles, but I do
know some REAL BIG sites that would love to see it...
for a market point of view it does put pressure on the transition to
S.next and the BE work, and uniformity and consistency is almost always
good...
just a view from the outside,
rich
e) This code is fragile and there might be strong pushback for
changing
it further in S10.
f) There is no re-use or other benefit to this work.
2) Enhance the zones "update on attach" code to do a real upgrade
The idea here is that we improve the 'update on attach' code so it
can
use a Solaris 10 CD image as the source of the pkgs instead of the
global zone. We would also enhance the code so it uses the full pkg
list from the CD image instead of just the system software pkgs that
have to be updated to sync the zone. The global zone admin would run
this new code to upgrade specific solaris10 branded zones. They
could
either upgrade the zone in place or clone the zone and upgrade the
clone,
providing similar functionality to LU.
Pros:
a) I think this would be a simpler project.
b) This code could be easily re-used to provide a true single zone
"upgrade on attach" feature for a S10 native zone backport -
lots of
people want that.
c) We know this code.
d) This code is open source and readily re-usable.
Cons:
a) Upgrade would be done by the global zone admin, not the zone
admin,
so the zone admin is no longer the one in control.
b) Because LU wouldn't work this might cause a perception of
incompatibility between the solaris10 branded zone and a bare
metal system.
c) This doesn't solve the problem of using LU to apply patches to
an ABE within the zone.
Please send me any comments on preferences for one solution or
the other, as well as any other thoughts on this topic.
Thanks,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
