There are tons of different views on how to name a machine. And there is even an RFC on the subject [1]. Every idea has their own merit but I'll try and summarize my view:

Hostnames should be:
 - Short (This is of course relative, but I shouldn't have to type 35+ characters to reach a machine.)
 - Easily remembered ( see above ^ )
 - Human Readable ( Actually, pronounceable and writeable, thus dis-ambiguous  )
 - English Language
 - Preferably without numbers, there are accepted occasions like clusters etc.
 - Non-descriptive
 - Themed (if they "belong" with each other in some way)
 - Unique (within the complete domain structure / organization, not globally unique)

Hostnames should NOT:
 - Contain a location or "on premises"-identification (especially virtual, "on premise"-identification can be ok if these are "hidden" from the "public")
 - Contain VLAN information
 - Contain IP-information (Seriously, its DNS for a reason)
 - Be tied to a project name / function
 - Be tied to a brand from a vendor

Why is this good?
 - It makes it easy to remember
 - Easy to inform / communicate
 - Secure (does not give away information)
 - Does not add confusion
 - Does not introduce bugs

What is the easiest way to achieve this?
 - Themed hostnames, pick a well known theme, say, The Simpsons. Homer, Marge, Lisa, Bart, Grandpa, Selma etc.
 - Add this theme to a specific service, say, webservers.

I think you get the jest.

With that being said, we have a naming convention already, which in my mind looks a little something like:

Physical Servers:
<provider>#.ovirt.org

Virtual Servers:
<provider>#.ovirt.org

Service name:
<servicename>.ovirt.org

What I could argue, about the above, is that the convention for Virtual Servers should not be "<provider>#.ovirt.org" but rather a non-descriptive themed name.

Why is this?
Well, ponder the theoretical example that we want to remove our account at linode, thus, remove "linode01.ovirt.org" but we want to keep the services it provides. If we'd pick a non-descriptive neutral themed name, this VM can easily be moved elsewhere without any updates other then redirecting the DNS-name.

This is the point where people argue, "Sure, but we are smart and use CNAMEs for our services, noone uses "linode01.ovirt.org" as a reference directly." At which point I simply answer, "Im totally fine with that, but I dont think that's true. Its an ideal, a good one at that, but not how it works.".

Not only that, What if, say, we have... "oursupervm01.ovirt.org" that has a geo-replication between Alterway and Rackspace locations since it is super important to us. And then it moves in between these sites without us having to worry about it. (Sure, there are quite a bit of work needed to be done before this can be achieved, but I think you see my point).

Ah well that's my one, two, three ce... euros for this discussion.

[1] - http://tools.ietf.org/html/rfc1178


On Thu, Apr 4, 2013 at 1:37 AM, Karsten 'quaid' Wade <kwade@redhat.com> wrote:
On 04/03/2013 12:02 AM, Alexander Rydekull wrote:
> I vote for <non_descriptive_name_of_function> as a hostname, first of all.

Meaning, we pick a theme and name hosts based on that? Flowers, baked
goods, Asgardians, etc.

I suppose I'm the one who starting us on the <name_by_location> and
generally supported <descriptive_name_of_function>. Curious what your
objection is to the latter?

I think engine.alterway.ovirt.org has a nice flow to it, but I like long
subdomains. :)

- Karsten

> But to keep with the theme of what we have, I vote for engine01 or
> manager01 or whatever.
>
>
> On Wed, Apr 3, 2013 at 12:41 AM, Ewoud Kohl van Wijngaarden <
> ewoud+ovirt@kohlvanwijngaarden.nl> wrote:
>
>> On Mon, Mar 25, 2013 at 06:05:07AM -0400, Eyal Edri wrote:
>>> I'm guessing we'd want to give the instance a proper fqdn ->
>>> "manager01.ovirt.org", "engine.ovirt.org" ?
>>
>> I dislike those options. manager01 (to me) implies a cluster where each
>> managerXX is a node. engine implies there is only one which won't be
>> true since we'll set up another engine at rackspace. I'd prefer to have
>> one, but as far as I know this is currently not possible (and maybe due
>> to latency even a bad idea).
>>
>> How about engine.alterway.ovirt.org, engine-alterway.ovirt.org or
>> alterway-engine.ovirt.org?
>> _______________________________________________
>> Infra mailing list
>> Infra@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>
>
>
>
>
> _______________________________________________
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>


--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41


_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra




--
/Alexander Rydekull