[Info-vax] VMS First-Boot on x86 Contest

[Stephen Hoffman]

On 2018-02-16 16:27:01 +0000, DaveFroble said:

> Bob Gezelter wrote:
>> Kerry,
>> 
>> LD type containers, fine (when I mentioned DVD, I was actually 
>> referring to ISO images, I too rarely pull out the DVD anymore, 
>> preferring to load it somewhere on a drive with free space).
>> 
>> However, this collection of infrequently used (*&^* should NOT be on 
>> the system drive.
>> 
>> Drives may have gotten larger, but filling the system drive with a pile 
>> of read-only, infrequently used bulk material is a poor idea for 
>> several reasons including:
>> 
>> - replication is not needed, access over the network is fine; and
>> - in a fast provisioning VM world, such common supporting material is 
>> dead weight when provisioning VMs and operating.
>> - Updating the kit images over time is a constant time chore (even with 
>> provisioning tools, it does not scale well and is a resource waste).
>> - This material becomes a significant part of backup (and restore volume).
>> 
>> Yes, storage is cheap. But to paraphrase the late Senator Dirksen, "A 
>> gigabyte here, a gigabyte there ...". Consider what happens when one is 
>> using tools to create a large number of virtual OpenVMS instances on a 
>> service such as AWS. Does one really want a multi-gigabyte collection 
>> of stuff for each instance? It adds up and increases ones monthly 
>> invoice (OPEX). Backing up the system disks becomes commensurately 
>> larger. A poor bargain. Much better to have a separate read-only disk 
>> that is shareable among all of the instances.


For discussion purposes, here is some pricing...   1 GB memory, 1 
virtual CPU, 25 GB, 1 TB transfer, US$5.    Or 4 GB memory 2 vCPUs, 80 
GB SSD, 4 TB transfer, US$20 per month.

For discussion purposes, the absolute you-really-don't-want-to-do-this 
minimum boot disk installation capacity for Windows Server 2016 
installations is 32 GB.

And what is an effectively-useless base installation of OpenVMS V8.4 is 
under 4 GB.  Figure we get to what, 16 GB if absolutely everything on 
two complete DVDs is decompressed and unpacked and installed?  And that 
install-everything approach not what I'm suggesting, BTW.  Not 
everything.   Though having the actual telemetry here would be very 
useful for these and other decisions at VSI, it's very likely that the 
product usage curve of who-uses-what drops off pretty quickly toward 
the margins of the layered product offerings.

>> Small system disks scale far better than large ones. We should be 
>> looking at minimizing what is on a system disk to improve the economies 
>> of scaling on services such as AWS.
...
> 
> I'm sort of with Bob on this.  Not that I have a problem with 
> everything in a VMS distribution being available.  I believe that there 
> should be a place for everything, and not have things all mixed 
> together.
> 
> I'd prefer to have the base OS in one location, and have separate 
> locations for the other things.  For example, a web server could be a 
> separate container.
> 
> Grouping things in such a manner would allow both concepts to co-exist. 
>  For those wanting everything, fine, and for those wanting just what 
> they use, such would already be there, whether the actual containers 
> were left on the system disk, or other disks, or not.
> 
> A simple configuration tool could make customization easy.

Pragmatically, y'all will spend more time futzing around with figuring 
out what's installed and what's not installed and what should be 
installed or not and what should be tailored off, what needs to be 
upgraded or patched and what doesn't, than you'll probably spend on 
running an entire and complete omnibus guest for a year or two.

This is all before we discuss the effort involved in doing more complex 
installations, in dealing with the dependencies, and the folks testing 
and troubleshooting all the permutations.   That's before we discuss 
the folks that will inevitably find it simpler to install a parallel 
copy as that avoids any discussions of dependencies, and now y'all have 
two or three or more copies of SSL — which already happens with 
products shipped from HPE and VSI BTW, and is only going to get worse.

I mean, seriously folks, how many folks around here bother with 
VMSTAILOR?  How many folks even know that exists?   And that's before 
even looking at how much added work — to do this stuff "right" — is 
involved with detecting and properly dealing with all the complexities 
of what's installed and what's not, or — as happens far too often — 
just tip over with an arcane error, as the usual response for a missed 
setting or missed dependency.

Or, you know, we spend less on our hosted OpenVMS installation per 
month than many IT folks spend in a week on coffee and snacks.

As for trimming stuff down for massive replication if y'all are doing 
embedded work, sure.  But how many of you really are?  And how many of 
you are doing embedded with OpenVMS and not with VxWorks or ilk?   And 
how are you managing all of those OpenVMS instances you're creating for 
your mass deployments here, particularly with what's out there now?  
And if you're really doing that, wouldn't you prefer a simpler 
packaging?

Oh, and who really backs up a system disk regularly?   Back up the 
several-dozen files that are active, and the rest is immutable and 
restorable from less-frequent backups, or from distro since removing 
installation complexity means that OpenVMS gets much easier to 
reinstall, and profiles and provisioning and easier migrations of user 
files means that the installations are far more repeatable and 
restorable.


-- 
Pure Personal Opinion | HoffmanLabs LLC