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

[David Froble]

Kerry Main wrote:
>> -----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
> 
> 
> 
> 

I see some issues, and possibilities.

If a user is to only be allowed in the container / application / whatever 
assigned to him, then logging into the base OS seems to be giving the user more 
than would be appropriate?

Should users logged into the base OS be allowed to access all containers? 
Perhaps a login to the container might be appropriate?

With one OS, the issue of multiple OS licenses seems to go away?

Being able to boot from a container doesn't seem to be very useful.  If only 
that container is to be run, then why use a container?  Yes, I understand 
testing a new OS version, and such, but that's what test systems are for, not 
production systems.

It seems to me that containers may be useful in some scenarios, but not so much 
otherwise.  I've loaded the Python containers, and yes, it was simple, and 
"contained".  But for production, it adds another layer of complexity.

A good capability to have, and already to some extent available, but, not to be 
used just because it's available.