For sure dashes are illegal characters in Puppet up-to-and-including P5+. See reserved words and acceptable https://puppet.com/docs/puppet/5.0/lang_reserved.html names https://puppet.com/docs/puppet/5.0/lang_reserved.html and the style guide https://puppet.com/docs/puppet/5.3/style_guide.html.
A name like "codfw2rbdev" or "codfwi2rb" is simply non-pronounceable for me. I could end summoning Sauron ... :-) The language is that of
What tends to happen is that things that cannot be phonetic become elongated.
i.e. "'dallas deployment 2'..is that a dev deployment? oh yeah it is."
But within a day or two you'll never have to look to verify if it's a dev deployment because we are unlikely have more than 5 deployments for the next few years. I very respectfully disagree that we'll be able to find a phonetic name that conveys the information here, and especially for deeper context to come, it's dense but I think it will be OK.
Perhaps we could reduce the amount of keywords. For example, site and region could be redundant, since a site implies a region.
codfw <-> na-center eqiad <-> na-east ulsfo <-> na-west esams <-> eu-center
Site and region are not analogous so it doesn't work to fold the identifier into one. We will certainly have 2 regions within codfw within the next 15m and possibly 2 within eqiad shortly thereafter. Even for AWS this doesn't work the way it seems on the surface in that while you choose a region+availability-zone it isn't really that persay, they mask what the underlying deployment is so us-west-1a for 2 companies can be different under the covers https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html. We won't have that abstraction to my knowledge. AWS does some interesting things to keep customer interfacing consistent even when it's not.
Also, it seems that all components are "variables" and there are no common keyword for referring to them. What about using 'cloudvps'? (or even, 'cloud')
Using all of the above, then the idea is:
cloudvps-eqiad1 <-- prod deployment in eqiad number 1 cloudvps-eqiad1b <-- prod deployment in eqiad number 1 row b cloudvps-eqiad1c <-- prod deployment in eqiad number 1 row c
(region is implied na-east)
cloudvps-dev-codfw2 <--devel deployment in codfw number 2 cloudvps-dev-codfw2b <--devel deployment in codfw number 2 row b cloudvps-dev-codfw2c <--devel deployment in codfw number 2 row c
(region is implied na-center)
I don't agree a prepend designating cloudvps is needed here. To my mind this would be like a prepend for WMF servers that indicate it is for WMF, since there isn't another option it is intrinsic.
Something like: '>cloudvps-eqiad1b <-- prod deployment in eqiad number 1 row b'
Wouldn't make sense as it's possible to have regions overlap rows in the future, site and deployment are not 1:1, and prefacing with cloudvps asks the question of: when is it not cloudvps to make the modifyer useful?
I agree with Bryan, what we are looking for is domains and subdomains. Using domains and subdomains could solve most of our problems with naming. Are we reinventing the wheel with all these naming schemes?
I don't think subdomains would solve all of our problems here, but in the case of a cloud vs cloudtest, yeah it may be a nicer model for sure. I don't think it's worth pursuing now as it would be serious effort for a little return and it doesn't move forward any of the things that we are stuck on.
I have been thinking on where we could incur some readability and not suffer a long series of painful context switching. I think potentially:
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 -> eqiad1-r --> eqiad1-rb --> eqiad1-rc
"eq one" "eqiad one" "eqiad one AV b" "eqiad one AV c"
# role::wmcs::openstack::codfw1dev::control codfw1dev -> codfw1-rdev --> codfw1-rbdev
# role::wmcs::openstack::codfw2dev::control codfw2dev -> codfw2-rdev --> codfw2-rbdev
"dallas deployment 2" "dallas 2 AV b"
# Future customer facing deployment # role::wmcs::openstack::codfw3::control codfw3 -> codfw3-r --> codfw3-rb