[Info-vax] VSI and Process Software announcement

[Dirk Munk]

Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
>> Of Stephen Hoffman via Info-vax
>> Sent: 24-Sep-16 1:19 PM
>> To: info-vax at rbnsn.com
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] VSI and Process Software announcement
>>
>> On 2016-09-24 15:49:14 +0000, Kerry Main said:
>>
>>>> Having a new server boot to USB stick — DVD drives are
>> failure-prone,
>>>> and are becoming less common, and don't and won't exist in
>> some
>>>> environments — or from local network boot services such as
>> InfoServer
>>>> or otherwise, and having the OpenVMS installation
>> environment support
>>>> DHCP networking and mDNS would be really nice, for instance.
>> (Yes,
>>>> there are boot-time security implications, of course.)
>>>
>>> If you are talking about new OpenVMS installs on SMB sites,
>> then yes,
>>> you are correct. I would also mention that every relatively
>> modern
>>> server I have seen has a local DVD, but that could change in the
>> future.
>>
>> There's likely a DVD drive in every one you've seen because of
>> past expectations and — particularly in the case of OpenVMS —
>> the operating system can't (yet) deal what I'm discussing and
>> what I'm suggesting here.
>>
>>> A more established OpenVMS site with config standards would
>> either:
>>> 1. - conversational boot from a different root on the local
>> common
>>> cluster system disk. Then make minor system specific changes
>> and
>>> reboot
>>> or-
>>
>> No, thanks.    Remote management and remote profiling works
>> far better
>> than that approach.
>>
>
> No it does not.  How is remote management /profiling better than secure console management?
>
> As an example, in your ideal scenario, how do you archive console messages, what someone has typed at the console before the OS is up and do console HW event alerting?
>
>>> 2. - local boot via DVD, then restore a backup to the target disk
>> with
>>> a previously built gold system image with all local customizations
>>> embedded. Then, do conversational boot, make system specific
>> changes
>>> and reboot. The gold image might even be a LD container for
>> quicker
>>> fixes in the gold image.
>>
>> Again, no.   I really don't want to take several steps backward
>> here.
>>
>
> VMware does essentially the same thing with predefined templates, but there is still OS specific customizations required.
>
>> The approach you describe is what (some) folks are doing now,
>> and — for not the first time — not an approach that's reasonable
>> or maintainable or even (hopefully) necessary going forward.
>>
>
> So, other than predefined templates, gold images, common system disks, network boots, LD type devices etc, it would be appreciated if you could enlighten me with how OpenVMS, VMware, Solaris, Windows, Linux and the other platforms should handle this?
>
>> For where this is headed, I'd rather have the server get its
>> configuration and criteria from a central server automatically, and
>> not involve people at all — the less I have to touch the server or
>> the rack
>> or the data center, the better.   The ability to remotely manage
>> and
>> provision systems is already commonplace on other systems —
>> the low-end gear I deal with from Apple provides this and rather
>> more — though this is certainly not something that most
>> OpenVMS folks have dealt with.
>> Yet.   But either OpenVMS gets dragged forward, or it gets
>> dragged out
>> back.
>>
>
> You seem to want to make it so easy that an end user could install an OS into a prod environment.
>
> Imho, that is just crazy. Regardless of the method, I want experienced SysAdmins to have their hands on new OS deployments. Yes, I know there is work to be done to make it easier than it is today, but the bottom line is there are just way to many variables and landmines that could impact other OS's to let a rookie deploy a new OS to a prod environment.

You're absolutely right. I've worked in an environment where everything 
was set up with easy to deploy templates. etc. The result was that no 
one understood what they were doing, they didn't understand all these 
settings because they didn't have to think about them. If there were 
problems, they didn't know where to look, or how to fix the problems.

That is the strange discrepancy. We want more and more intelligence in 
the OS and tooling, requiring competent staff, and when we have to 
deploy a system, any monkey must be able to do so without any insight of 
what he is doing.

I remember an Alpha 8400 cluster with a 4GB memory per system, huge in 
those days. It didn't perform well. The cache setting as still at the 
default 3MB (afaik), many batch jobs were set for a maximum memory usage 
of 2.5MB. Why? Nobody knew, "I don't know, it has always been like that"

I can give you many more examples like that, with Unix, Linux, Windows, 
it doesn't matter. Incompetent staff that has no idea what they are 
doing, trained to invoke scripts, not to understand what the scripts are 
doing.

>
>>> Multinet supports IPV6 (including IPsec) and DHCP4, so both are
>> likely
>>> part of the new VSI stack. See points 1 and 2 for new installs.
>>
>> Multinet does not support what I was referring to.   If Multinet
>> were
>> integrated into the distro and custom configured, a custom install
>> can
>> be tweaked to deal with this.   But so can TCP/IP Services.   As I
>> keep
>> writing here, I do not want to write or extend an operating
>> system, implement a network stack, a web server, a remote
>> server configuration tool and remote management and profile
>> management and the rest of what
>> I expect from the platform.   Because while various folks here can
>> certainly create and maintain and deploy all of that, other folks
>> can go get most or all that on some other platforms, and these
>> and other features are only going to become much more
>> common on other platforms
>> going forward.    That's where I'd like to see OpenVMS.   Not stuck
>> in
>> the present and the past.
>>
>
> Again, most large shops I have been in use templates (VMware), gold images, network boot, USB, DVD, LD etc. There are some commercial bare metal pkgs which might do this, but it still requires a means to install that third party pkg on the bare metal server which then integrates with a central server.
>
> Every Cust environment is different. Some environments require custom config's and there is usually a good reason for this.
>
>>> Note - With DHCP enabled on the various server LAN interfaces
>> in the
>>> gold / LD image (usually with long TTL values), the number of
>> steps
>>> required for each OS config is reduced. In larger sites, each OS
>> may
>>> have 4 or more different LAN interfaces and each would have a
>>> different subnet address (e.g. PROD, CLUS, BACKUP, MGMT)
>>
>> If gold masters still work for you, go for it.   But — again — what
>> I'm
>> referring to here is a step or two past that approach — not that
>> I'd even prefer to use all-inclusive master images.
>>
>>> Larger sites will also be adopting IPAM (IP address mgmt.)
>> solutions,
>>> but that is a different discussion. As example:
>>> http://www.solarwinds.com/ip-address-manager/
>>
>> That's part of software defined networking, which is another hole
>> in OpenVMS.
>>
>
> No its not. IPAM has been around for 15+ years and all the bigger shops use it. IPAM solutions are almost becoming mandatory if a site begins to adopt IPV6 internally.
>
> Popular IPAM vendors include Bluecat, SolarWinds, ManageEngine, InfoBlox, Cisco etc. More info:
> https://en.wikipedia.org/wiki/IP_address_management
> http://www.ipamworldwide.com/ipam/books.html
>
> SDN is just industry hype, which like "clouds", can be defined any way you  like.
>
> As an example, what Customer in their right mind is going to throw out all their existing network infrastructure from multiple vendors in order to implement SDN from one vendor?
>
>> All of what I'm describing here is already available and already
>> working, BTW.  There's nothing revolutionary here.  It's available
>> in the not-OpenVMS servers that I routinely manage and use.
>>
>
> I would be interested in hearing about what you are describe as "already available and already working".
>
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>
>
>
>
>
>