You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
Talk:Wikimedia Cloud Services team/EnhancementProposals/Operational Automation
Regarding the local setup I think it would be simpler and safer to just use the local SSH config that should already handle correctly both production hosts and OpenStack VMs including the StrictHostKeyChecking option: One could use:
clustershell: ssh_options: - '-F ~/.ssh/config'
dcaro: At least in my system that happens already by default (the including of the ssh config in the default path), but in my generic config I don't want to have to ignore the ssh hosts, as that one I use when sshing manually, so that's why the options are hardcoded in the cumin config only, so they only affect cumin when run from the laptop, when it would fail if the ssh host key does not match.
- True, but then I fail to see the need for that setting entirely. According to Production_access#Advanced:_operations_config VMs should be already having a similar setup that works in most cases. If it's a problem with re-used hostnames than we could limit that
StrictHostKeyCheckingat least to only
Host: *.wmflabs.org *.wmflabsright? Volans (talk) 12:41, 8 February 2021 (UTC)
- Yep, it could be restricted to the VM domains (those are more than the ones above), but I'm not sure it's a good idea to do so 'by default', as in your user ssh config. A better solution would be to disable it only when you know there can be an issue (after creating the new VM), but as far as I saw there's no easy way to tweak those dynamically (would be nice to add it though). David Caro (talk)