James Carlson wrote:
> Better questions would be:
>
> - Can you use Live Upgrade?
>
>
I can, but I don't. I don't generally do 'upgrades' at all. Maybe it's
me but I just don't trust them.
With the totally repeatable Jumpstart I use, It's much easier, and
faster to just re-install fresh, and be able to trust that the machine
is in a totally known state.
When I had a large compute farm to take care of, I would not make
changes to the machines, instead I make
changes to the jumpstart, test, and then reinstall all the machines.
Flash archives would make this even faster.
With JumpStart I regularly install in a 'BE' that is less than 4GB. I
don't worry abotu future installs, or upgrades needing more space. It's
so easy to repartition when I re-Jumpstart. And while disk is cheap, I
don't want to waste 1.5GB waiting around for an upgrade... I usually
don't have more than 256MB free on my BE's. I don't add packages after
the install is done. And with some exceptions I don't add patches either
(they are installed when the next jumpstart happens.) - I do make sure I
have room for patches though.
As James said 5GB is more than enough for a BE, I get away with 3
sometimes since swap is shared. I make it apoint (almost a religion) to
not customize or install anything on any of the 'OS' filesystems. All my
data and apps are kept on a separate partition (if not a separate disk
in a separate enclosure... usually on a separate machine. :) ). The most
that gets changed in the OS are some config files in /etc (auto_master,
sendmail.cf, /etc/default/*, etc.) and some softlinks are created. All
of that is done by the Jumpstart. It's so simple.
I don't always but I have had JS preserve /export when there was local
data or apps on a machine. When I have used LU I leave /export out of
the BE, and anything I have installed local to the machine's boot disk
is there wating for me.
> - If not, then what specific issues are blocking you from using it?
>
As I said above I just don't trust upgrades. Upgrading from one build of
NV to the next might be ok since it's a 'test' machine anyway, and I'll
do a clean install when it's done.But I can't imagine taking some
machine that had had 2.5.1 on it an upgrading it to 2.6 then to 7 then
to 8... 9... 10??? And possibly upgrading to update release in the middle.
There are just too many questions about the state of the machines. I f I
had edited a config file, are the changes overwritten during the
install? or are they left, and the newer version of that config file
just isn't installed at all?
What am I missing out on? What am I losing that I had?
To make LU work for me:
1. I'd personally like to see a 'LiveJumpStart'. Where the ABE is wiped,
and a fresh install is done using all the jumpstart logic on a running
machine. Then I can have the speed and known state of JS, with the
limited downtime of LU.
All that said my Jumpstarts do partition the disk for LU. One thing I
noticed in NV is the ability to create an ABE during Jumpstart. I found
it too limiting though. so:
2. I'd like to be able to initialize the current Jumpstart install
location as BE in the JS profile. Basically, I'd like to be able to
define no 'filesystems', and only multiple BE's, and 'select' one of
them for the current install.
3. I'd like to be able to use the SVM 'mirror' keyword in the BE
definitions.
Maybe instead of creating partitions when defining a BE, I could create
all my partitions with the 'filesystem' keyword (using 'mirror' if I
like) and then build the BE from the already defined filesystems. I
currently create /, /lu, /var, and /lu/var. But maybe my filesystems
could instead be created as "[BE1]/" , "[BE2]/", "[BE1]/var", and
"[BE2]/var" and the BE's wouldn't need to be defined seperately?
-Kyle
