Hi,   I would change purpose and location.   Reasons: 1) You can see behind the unique ID whether that would be a test or live sytem (or whatever). 2) You have got the location in front of opensuse.org. So you can see directly in which data center the system would be hosted.      So you don't have to look between strange names (ID and pupose name) after the location. 3) That#s the same like we are doing it with our main page: https://de.opensuse.org/ and https://en.opensuse.org   We did that (at 1&1) with our systems in different data centers, too. That's a fantastic idea!   Best regards, Sarah   Gesendet: Donnerstag, 09. Februar 2017 um 13:30 Uhr Von: "Theo Chatzimichos" <tampakrap@opensuse.org> An: heroes@opensuse.org Betreff: [heroes] naming pattern

Hello,

I would like to start a discussion regarding the naming pattern of our VMs. Right now there is a total mess and we need to be consistent. So here is what I propose, after a discussion I already had in a SUSE-IT's team meeting. Please be aware that NONE of the things I describe below have actually been implemented yet, so everything is up for discussion. I would like to start implementing them soon though, so I'll give the topic a deadline of three weeks (until the next team meeting, 5th of March).

FQDN form proposal: $unique_ID.$location.$purpose.opensuse.org

### unique_ID

This is a unique name for every machine. When one name is used, it can NEVER be reused. Thus, we will need to list them somewhere (at the progress opensuse-admin-wiki for example) (both the current and the deprecated ones)

Proposals for the unique ID: 1) pattern like vmXY (X and Y being increasing numbers) 2) the cartoon names we currently have

I would prefer: - cartoon names for production instances - vmXY or workerXY for CI/OBS workers - whatever for testing instances, but not cartoon names

### location

This can be the country code, or city name. I would prefer the country code

### purpose

This could be:

- infra or prod for production instances (I prefer infra) - test for testing instances - worker for workers

Examples on how our instances' FQDNs will look like:

ariel.de.infra.opensuse.org donald.de.infra.opensuse.org goofy.cz.infra.opensuse.org daisy.us.infra.opensuse.org mediawiki.de.test.opensuse.org salt1.us.test.opensuse.org

https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/Naming_patte... -- Theo Chatzimichos <tampakrap@opensuse.org> <tchatzimichos@suse.com> System Administrator SUSE Operations and Services Team -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org

Hi Theo On Thu, 9 Feb 2017 13:30:47 +0100 Theo Chatzimichos wrote:

FQDN form proposal: $unique_ID.$location.$purpose.opensuse.org

I'm sorry, but I do not really see a reason for this at the moment - I'll explain my concerns below, but first start with some questions: * How many machines do you want to provide for openSUSE that it makes sense to think about such a scheme? * What exactly do you expect as benefit from this naming scheme? * Who will request/maintain all those DNS sub-domains or FQDN with a '.' in the name? I already have problems with the current cartoon naming scheme. It might be related to my age (Alzheimer is winking), but I do not really now why a host has to be named like a cartoon figure if the machine has just one single purpose/service. Especially, if in the end a "ssh $service.opensuse.org" has the same effect as "ssh $cartoon.opensuse.org" - because nobody cares about the correct firewall rules. So while I can live with that crazy name as DNS entry, I expect at least the PS1 and/or the console entry to point to the service of the machine instead of their cartoon name without any further information. I was already in a situation that I need to search through a console list to identify the host who is marked as red with its service. Luckily (or sadly, because in that case I would probably learn the names) I don't need to do this too often, because our services are very stable - but if I am already in emergency, I am not really happy to have a just list of cartoons in front of me - while I'm searching for a service. (...and yes: searching in an additional table which maps the cartoon name to it's service is also an additional job that I do not like). With kind regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org

Hello, Am Donnerstag, 9. Februar 2017, 13:30:47 CET schrieb Theo Chatzimichos:

I would like to start a discussion regarding the naming pattern of our VMs. Right now there is a total mess and we need to be consistent. So here is what I propose, after a discussion I already had in a SUSE-IT's team meeting. Please be aware that NONE of the things I describe below have actually been implemented yet, so everything is up for discussion. I would like to start implementing them soon though, so I'll give the topic a deadline of three weeks (until the next team meeting, 5th of March).

I love deadlines ;-) I'll try to sum up the other responses in this mail, but will also add my own comments.

FQDN form proposal: $unique_ID.$location.$purpose.opensuse.org

With $location and $purpose swapped (as proposed by Sarah), I like the general format -> $unique_ID.$purpose.$location.opensuse.org

### unique_ID

This is a unique name for every machine. When one name is used, it can NEVER be reused. Thus, we will need to list them somewhere (at the progress opensuse-admin-wiki for example) (both the current and the deprecated ones)

Proposals for the unique ID: 1) pattern like vmXY (X and Y being increasing numbers) 2) the cartoon names we currently have

As already mentioned by Lars and Per, the cartoon names are not really helpful. I'd prefer more useful names that describe the service + a number, for example wiki1.infra.en.opensuse.org. Ideally the name should be in sync with the role name we use in salt - at least for VMs that only have a single role. If a VM hosts multiple services, choose a name that fits all - and if you can't find a good name, it's probably a sign that you should split that VM ;-) Using the servicename + a number would also make it very easy to enforce not reusing an unique_ID - just increase the number to be on the safe side ;-) This scheme would also (mostly) avoid the need for a "historically used names" list. The only exception is dropping a servicename completely - in this case, we need to note down the servicename + last used number [1]. If there's only one VM for a service, a CNAME without a number might be nice, for example wiki.infra.en.opensuse.org -> wiki42.infra.en.opensuse.org

I would prefer: - cartoon names for production instances - vmXY or workerXY for CI/OBS workers - whatever for testing instances, but not cartoon names

With cartoon vs. non-cartoon, you'd make $purpose more or less superfluous ;-) However, it would also make us cartoon experts, because *lots of* names are used in cartoons, and I'm quite sure you don't know 50% of the names listed in the Disney wiki ;-)

### location

This can be the country code, or city name. I would prefer the country code

Assuming we have only one datacenter in each country, I agree. Otherwise using an unique datacenter name (which can be based on the country or the city) might be better. A small issue with using the country is that this technically makes all FQDNs subdomains of the german, czech and english wiki, but this is more a fun fact than a real problem.

### purpose

This could be:

- infra or prod for production instances (I prefer infra) - test for testing instances - worker for workers

I'd also add "metal" for low-level access to the bare metal layer. For the bare metal level, I'd even accept cartoon names because I expect that I won't have to deal with bare metal anyway ;-) I assume that VMs that get prepared for production use are allowed to have "infra" in the name from the beginning, right?

Examples on how our instances' FQDNs will look like:

ariel.de.infra.opensuse.org donald.de.infra.opensuse.org goofy.cz.infra.opensuse.org daisy.us.infra.opensuse.org mediawiki.de.test.opensuse.org salt1.us.test.opensuse.org

Ask a random non-admin (or even an admin coming back from a long vacation) what those machines do, and you'll understand why cartoon names are not the best idea ;-) Regards, Christian Boltz [1] Since this should happen very rarely, it could even be done on the DNS level to make sure it doesn't get overlooked. Just make it a CNAME of "gone.opensuse.org" or assign a ...:dead:beef:... IPv6 address to it ;-) -- Der von Ihnen vielleicht erwartete Input wird zu dem eines verstimmten Mitarbeiters oder eines Crackers der Monate Zeit hat, oder einer Katze, die über die Tastatur läuft in keinerlei Zusammenhang stehen. [http://php.net/manual/de/security.general.php] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org