[Info-vax] Installing and using GNV - some feedback and questions

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of IanD via Info-vax
> Sent: 30-Oct-16 6:58 AM
> To: info-vax at rbnsn.com
> Cc: IanD <iloveopenvms at gmail.com>
> Subject: Re: [Info-vax] Installing and using GNV - some
feedback
> and questions
> 
> On Friday, October 28, 2016 at 12:23:35 PM UTC+11, Marty wrote:
> 
> <snip>
> 
> > It struck me the other day that use of the LD disks is
similar to
> how "The New Kids" are using the concept of containers and
> Docker.  Put everything you need to run an app, or a suite of
> apps, in an LD and you should not have to worry about the
> underlying OS stuff (as much).
> 
> This is how one form of Python distribution is done and it
makes it
> very easy to try out Python without polluting your environment
> 
> - Download the two container files (Python and required tools)
> - Mount them as LD disks
> - Compile (Python compile, required for first build run only)
> - Run the setup config (process level or system level logicals
/
> symbols)
> - Use
> 
> Distributing a release this way makes it dead easy for handling
> things like ODS5 volumes on older systems were the System disk
> is still ODS2 because you don't install anything on the system
disk
> and makes version upgrading / testing easy  as they are self
> contained.
> 

Agree - LD disks are great for this.

> One place I worked it would have taken months to get
traditional
> software installed because if it touched the system disk the
> change control process made it unbearable but having the
> software distributed in an LD device meant most of the
> objections from the systems folk went away
> 
> Container systems such as docker go one step further than what
> VMS distributions tend to use LD for, which can be just as a
> glorified saveset with random access ability. Docker
distributes a
> container as a running app with all the files required minus
the
> OS.

Yes, but container disks like Docker have their own issues:

Reference:
http://bit.ly/2eeBtD7
"Enterprise IT staff should speak with people within their own
mainframe and Unix support and development teams to learn what
they know about the use of partitions, such as VPARs and LPARS.
It is likely that they have developed a number of "rules of
thumb" that could be easily adapted to today's container
deployments supporting Windows and Linux workloads."

http://bit.ly/2eo849U
" Containers can be run within virtual machines or on traditional
servers. The idea is somewhat similar to that of a virtual
machine itself, except that while a virtual machine includes a
full copy of the operating system, a container does not, making
them faster and easier to load up.

The downside is that containers are less isolated from one
another than virtual machines are. In addition, because
containers are an easy way to package and distribute
applications, many are doing just that -- but not all the
containers available on the web can be trusted, and not all
libraries and components included in those containers are patched
and up-to-date."

The OpenVMS alternative is LD disks, Application stacking and
smart planning of UIC's and ACL's. Yes, it's not as automatic as
it could be and yes, does require pre-planning (what a concept),
but it has worked for many Customers for decades. Yes, there is
certainly room for improvement (bootable LD's??).

Let's be clear - the reason why commodity OS platforms are
looking to container technologies is because they are finally
waking up to the massive issues associated with VM sprawl.

Unfortunately, the reason for the popularity of VM's on commodity
OS's is because of both technical and culture issues, groups did
not want to share their Apps on a common OS which is
diametrically opposed to adoption of container technologies.

> 
> Python on VMS is about as easy as it gets for installation with
it's
> two container file distribution but what VMS lacks is a
> management layer / framework for automated deployment and
> installation of LD images, it's left up to the VMS admin to
manually
> install / configure, much like bringing a new disk online, not
hard
> but not automatic either which just makes automating a VMS
> environment harder than it needs to be. Pushing tasks down to
> the requester level and giving them everything they need to get
> the job done is where systems have been heading for a long time
> now
> 
> We might even get to a model where VMS can be totally group
> administered for each representative group / application (I
don't
> think it's entirely possible now is it?, for example, how do
you
> allow say a group manager to run jobs under a username of
> someone in their group only? You have to give them CMKRNL
> which allows them access to run under any username on the
> system. We need a GRPKNL privilege to limit the scope to be
> group bound)
> 

Given the security audit concerns associated with someone running
a job under someone else's name, I would suggest that jobs should
be designed and run under the username of the person who actually
submitted and/or ran the job.

> I guess some enhancements to LD containers might be to make
> them growable, shrinkable and compressible too, like what you
> can do with a VM disk

As mentioned above, I would like to see bootable LD images as
this will allow one to build "libraries" of known and standard
images which have the latest patches. As an example, boot / mount
a LD, patch it, put it back in the library with a new revision
number.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com