2 cents:
The reason I favor descriptive host naming conventions are because
they show up all over in logs, metrics consoles, alerts, etc.
I'd much rather click on something semantically useful when checking
to see if my database is indeed swapping, and getting an alert saying
"host i-ec45e683 is down" while I'm out to dinner doesn't tell me if I
need to go running for a laptop or not.
-s
On Tue, Apr 5, 2011 at 1:51 PM, Bryan McLellan < "> > wrote:
> On Tue, Apr 5, 2011 at 10:26 AM, Brian Akins < "> > wrote:
>> Not to start a naming convention war, but we used to use a scheme like that. Many hours were wasted arguing. Now*, we just name them simple things (like, host1, host48, web1, db8).
>> Since most of our configs are built using databags and searches and our "doit" scripts use knife, having "meaningful" hostnames is not terribly useful as noone every uses them directly much.
>>
>> *Note: "Now" meaning we do it some now and are moving towards it.
>
> We use EC2 instance IDs, or something similar in other environments
> calculated from GUIDs or other unique data for the node name and
> primary dns name, but set the hostname to something based on the role
> dynamically to stuff the shell prompt with useful information. Thus
> the DNS hostname is something like "i-82bca6a8.example.org" but
> /etc/hostname contains "server-environment-i-82bca6a8" It's helpful to
> be able to sit back down at my desk and visually verify I'm not about
> to do something nasty on a server in production.
>
> I'd agree hostnames are meaningless these days are server resources
> really are just reusable resources and 'knife ssh role:web screen' is
> easier than remembering and learning a custom naming scheme or
> managing one. Still, you can leverage naming in useful ways to get
> information to convenient places, like shell prompts. It's easy to get
> both with chef.
>
> Bryan
>
Archive powered by MHonArc 2.6.16.