For sure dashes are illegal characters in Puppet up-to-and-including P5+. See reserved words and acceptable

names and the style guide.

> 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. 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