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