[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: February 26, 2018 11:21 AM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
Automation
> 
> On 2018-02-25 15:48:02 +0000, Kerry Main said:
> 
> >>
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> >> Stephen Hoffman via Info-vax
> >> Sent: February 24, 2018 7:10 PM
> >> To: info-vax at rbnsn.com
> >> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> >> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
> > Automation
> >>
> >> On 2018-02-24 20:52:20 +0000, Kerry Main said:
> >>
> >>> Never been much of an issue if its just the OS (modparams) and
> TCPIP
> >>> (tcpip$config).
> >>
> >> No, it's not.   Go try it.  We'll wait.
> >>
> >
> > If just changing the node name and the TCPIP address as part of a
new
> > OS deployment (e.g. gold image deployment - what we are talking
> about
> > here), then this is not a big deal.
> >
> > Done it many times.
> 
> Go try changing a host name of a previously-installed and non-trivial
> OpenVMS system.  Getting a domain-change request can be a real
> challenge, absent a strategy built on guests or containers.
> 

Mmm, we are talking in this thread about changing the server and tcpip
host names of a gold image which was just image copied to a system
partition?

It was already mentioned that if Apps are installed with no focus on the
environment being homogeneous and/or keeping things off the system disk,
then there will likely be challenges with changing names.

> 
> >>> If Apps involved, then it does get a bit more tricky, but that is
the
> >>> same on *NIX and Windows as well.
> >>
> >> When are apps not involved in a deployment?
> >>
> >
> > In most cases I have been involved with, you deploy apps after the
OS.
> > Ideally, not on the system disk but we all know there are poorly
> > written Apps that expect to be on the system disk.
> >
> > In fact using todays concepts, you deploy the OS image and "App
> > containers" separately on non-system disk partitions. Just need to
> > change a few start-up items.
> 
> Those other platforms are better about managing their host names than
> OpenVMS, and that rolling out servers with those platforms is easier
> than with OpenVMS, and that OpenVMS has no concept of isolating
> installed apps, nor does regenerating and testing monolithic masters
> work very well in environments that are getting updates as often as
> they're arriving now and into the future.  Among other details.
> 
> >>> Its certainly not a show stopper.
> >>
> >> Given that host names and DNS forward and reverse translations are
> all
> >> involved with network security, don't bet on that.
> >
> > The topic here is changing the server name and IP address of a new
> gold
> > image deployment.
> >
> > Regardless of how the server is deployed, the network implications
like
> > DNS AND FW rules still need to be addressed, but this also applies
to
> > VMware Windows/Linux images using templates.
> >
> > Btw, one idea that HP internal IT was talking about doing just
before I
> > left in 2012 was deploying gold images based on a server based DHCP
> > strategy for each NIC with long TTL's e.g. 5 days.
> >
> > Interesting idea, but I am not sure if they followed through on this
or
> not.
> 
> So... was HP / HPE IT doing that with OpenVMS?
> 

Not that it matters since the strategy is one that can be used on any OS
platform, but HP were planning on doing this with all their Wintel/Linux
environments (small amount of HP-UX as well).  Again, not sure if it was
ever implemented or not.

With the new IP stack, this should make it even less of an issue with
OpenVMS.