-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS update issues with repeated attempts to add the same node #125
Comments
Hmm, this may have already been fixed in ComputeCanada/puppet-magic_castle#69 |
Which version of Magic Castle are you using? The fix was released with 8.3. If you have a running cluster built with an older version of MC, you can cherry pick the fix and apply it to |
Not sure of the exact version - it's been running since late August (users very happy). Will look at the cherry pick fix. |
Hmm, that hasn't worked. While the DNS record resolves, and the new node is picked up via Consul and hence Slurm, DNS resolution of the new node still reflects an old IP. |
For clarification: was the new node added after the cherry-pick of the fix? While not ideal, you can always edit the DNS records using the FreeIPA web interface at : https://ipa.nameofyourcluster.domain.tld/ |
Yes, this is after the fix. Was aware of the ability to edit the records, thanks, just hoping to avoid it. I've just tried a name new to this cluster, and neither host nor DNS records have been created for it. Might be missing some other fixes? |
In the end I found that only re-enrolling the newly-added instance fixed all the issues, after editing the DNS record... (e.g. Slurm jobs failed owing to user-lookup errors) |
I discover this morning that sometime the ipa-client-install command fails to update the DNS, but still return 0. I have created an issue here : ComputeCanada/puppet-magic_castle#79 It could be related to your problem. I will probably need to add some check in puppet that the record A is created and corresponds to the ip address to avoid these kind of issues in the future. |
Yes, I saw that issue, thanks. If I have time tonight I'll try again and see what's in the logs. |
Now that #79 is fixed, I will close this. Feel free to re-open if the problem persists in coming versions. |
Owing to some local issues, a recent attempt to add a compute node to a cluster failed at the stage of provisioning keys.
I found that when I destroyed that node then re-added after the local issues had been fixed, the DNS for the new instance had the IP of the previous attempt, so logins to that node failed.
I had expected the DNS entry in IPA to be destroyed alongside the node.
The text was updated successfully, but these errors were encountered: