> lab => cloud
>
> cloudvirt1001
> cloudcontrol1001
> cloudservices1001
> cloudnodepool1001
>
> labtest => cloudi
>
> cloudicontrol2003
> cloudivirt2001
> cloudivirt2002
>
> Or open to suggestion, but we need to settle on something this week.
>

Let's be even more clear:

cloudvirt1001-dev
cloudcontrol1001-dev
cloudservices1001-dev
cloudnodepool1001-dev

or

cloudvirt1001-devel
cloudcontrol1001-devel
cloudservices1001-devel
cloudnodepool1001-devel

or

cloudvirt1001-test
cloudcontrol1001-test
cloudservices1001-test
cloudnodepool1001-test

This means, using a word suffix which is clear and meaningful to the eye.
If you don't like dashes '-', then without it.

cloudvirt1001devel
cloudcontrol1001devel
cloudservices1001devel
cloudnodepool1001devel

We could use the 'devel' keyword for new servers which are being
developed, before they get intro production.
And then, we could use the 'test' keyword for staging environments.
Of course we can use just one, I don't mind, the main point of my
proposal is the visual word prefix.

Thank you Arturo for reading and thinking about it :)

A few thoughts:

* Is dev or devel better than 'test'? I'm not sure. rebase-dev* variants do exist but I recall the gnashing of teeth at that situation. I don't have a strong opinion, I think dev is a little better than test.

* On server build pipeline:

> We could use the 'devel' keyword for new servers which are being
> developed, before they get intro production.

Small note that this isn't the workflow here (if I'm understanding correctly), servers go in with whatever name they will live with. We don't historically move servers along a pipeline in this way and server renaming is a pain in that it needs to follow down the path of puppet, rackspace, and all the way to the physical tag on the server via dcops.

* cloudvirt1001-dev I think is not a strong candidate as there is a strong precedent (probably a necessity) for not having anything after the numerical range assigned by site at https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Servers. I think anything like foo1001-dev will be enough of a special snowflake to break any reasonable regex in existence. The only similar example I can find is /^restbase-dev100[4-6]\.eqiad\.wmnet$/ (i.e. foo-dev1001).

* I hate dashes in places where it will translate to Puppet or another medium that cannot handle the character. I have gone down this road at a previous place and it turned into a nightmare of constantly replacing -'s with _ and interspersing them until your brain couldn't tell which was which. That's entirely my historical perspective though and I won't be persnickety if everyone feels differently. I'm thinking about the bleedover for names/roles/deployments/regions/availability zones at the moment and I acknowledge that for readability something could work out.

* A small thought on meaningfulness of prefixes, symbolism, and suffixes :) There is a battle between first 5 minutes obviousness and long term practical mental modeling IMO. Nothing at https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Datacenter_sites or https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Networking_&_miscellaneous_equipment passes the 'first 5 minutes most meaningful name' test, but still works well. It's after the first 5 minutes where we are going to be living the majority of the time so I'm OK with having to digest a keyword or indicator. Attempting to have verbose and obvious lamen indicators, vs symbolism or inferred meaning, isn't bad but it also isn't going to be practical. Readability and consistency are my hopeful standards. That being said cloudvirt2001 vs cloudivirt2001 vs cloudvirti2001 are all pretty crap for readability....so...counter proposal (assuming we like 'dev')...

lab => cloud*

cloudvirt1001
cloudcontrol1001
cloudservices1001

labtest => cloud*-dev*

cloudcontrol-dev2003
cloudvirt-dev2001
cloudvirt-dev2002

# Once the current nova-network setup is retired we end up at deployment 1 in eqiad

eqiad1

-> eqiad1r

--> eqiad1rb

--> eqiad1rc

# role::wmcs::openstack::codfw1dev::control

codfw1dev

-> codfw1rdev

--> codfw1rbdev

# role::wmcs::openstack::codfw2dev::control

codfw2dev

-> codfw2rdev

--> codfw2rbdev

# Future customer facing deployment

# role::wmcs::openstack::codfw3::control

codfw3

-> codfw3r

--> codfw3rb

A part of my heart hurts that things with 'dev' and not are named in the same numeric series but it's way more confusing to have codfw2 and codfw2-dev than to just make codfw2 and codfw3-dev IMO. It's true that server names do not make that many appearances in Puppet themselves. I don't love it but if we limit the use of dashes to there and the rest of the use cases are still readable that seems survivable to me. We end up with codfw2rbdev though :)