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#Server.... 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#Datace... or https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Networ... 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 :)