System Naming Schema

[Toshio Kuratomi]

On Fri, Apr 29, 2011 at 12:20:11AM -0400, seth vidal wrote:
> On Thu, 2011-04-28 at 15:25 -0600, Kevin Fenzi wrote:
> > Well, here's the simple way I imagine: 
> > 
> > - new machines increment number. 
> > - we setup CNAME aliases. 
> > - CNAMEs change when new machine is placed in service. 
> > 
> > For example: 
> > 
> > We have a log01. We make a new log02, get it all setup, working, etc. 
> > We have a 'collectd-server' cname that points to log01
> > We have a 'syslog-server' cname that points to log01
> > We have (optionally) a 'log-server' cname that points to log01.
> > 
> > When changing things, we just change the cnames. Admins learn to login
> > to the cname and it always goes to the live one. Although that doesn't
> > help for puppet. 
> > 
> 
> 
> I am in favor of the above wholeheartedly - it is, implicitly, what I've
> been doing with the single-server instances - like people.
> 
> we have people01 - which is accessed by people.fp.o or fedorapeople.org
> 
> when people02 is happy it will be where people.fp.o points to.
> 
Do CNAMES in our internal network propogate instantly or does it depend on
the DNS TTL?  If the latter, I could see us having problems with things like
db servers where we need to switch over from one db server to another and we
really can't have any requests going to the old host.

> now - what about for services which have more than one machine
> backending them.
> 
> if we have, for example, x86-01 -> x86-19 - which are builders - should
> we go to 20-25 and remove 01-06? or should we just replace and keep the
> same range.
> 
> I don't mind either, I just want a decision on those.
> 
The thing that I do like about the CNAME proposal above is that it allows
most configuration to stay the same (since the configured services point at
the host's CNAMES).  With that in mind, we wouldn't want x86-01 to change
here either.  With things like the builders we also have the ability to
rebuild a subset of the redundant hosts, try it out, and then decide whether
to revert to the old build or move everything to the new build so replace
works better here.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20110428/0a6a59d6/attachment-0001.bin