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