[update] Fix IPv6 nameserver support in workload launch script#3616
[update] Fix IPv6 nameserver support in workload launch script#3616sathlan wants to merge 1 commit intoopenstack-k8s-operators:mainfrom
Conversation
|
@hjensas Hi, so I've tried to address the fallback with specific IPv6 DNS server or specific IPv4 DNS server. I couldn't find a better variable than (follow up on your question in #3498) |
| done | ||
| else | ||
| echo "Warning: No nameservers found, using public DNS fallback" | ||
| {%- if cifmw_polarion_jump_custom_fields.iprotocol|default("IPv4") == "IPv6" %} |
There was a problem hiding this comment.
I am not sure what else can be used, but I have another comment below.
| --subnet-range 192.168.0.0/24 \ | ||
| --allocation-pool start=192.168.0.10,end=192.168.0.100 \ | ||
| --gateway 192.168.0.254 \ | ||
| --dns-nameserver ${NAMESERVER} \ |
There was a problem hiding this comment.
So, the IP addressing for this subnet is IPv4 - so any workload launched will get an IPv4 address. How is an IPv4 only client supposed to communicate with an IPv6 DNS server?
There was a problem hiding this comment.
Do we need a nameserver on the subnet for the test to pass?
Is it possible the simple solution is to just remove the --dns-nameserver argument for the subnet create command entirely?
There was a problem hiding this comment.
Hum... good point.
But we used to have that script working in ipv6 only environment in downstream testing for osp17 and osp16. Based on that experience, I don't this that is a problem, at least I have some confidence that it worked in the past as is in similar ipv6 only environment. The only way to tell now is to have a testing run with the rhoso18 job, but it's currently broken by some other issue.
DNS resolving while not strictly necessary might cause issue/longer connection time during ssh connection - as I think by default ssh try to resolve the incoming ip. Also, I think that various services like to have DNS working. Again, I'd rather have it than come back to where DNS is not working as it eventually causes trouble.
Let's have a full check in an RHOSO18 ipv6 uni04delta update - when it's working again - environment to see how that behaves.
The workload launch script fails on IPv6-only RHOSO deployments because it uses an IPv4-only regex to extract nameservers from `/etc/resolv.conf`. This causes subnet creation to fail when only IPv6 nameservers are available. Replace the regex approach with `awk`-based parsing that: - Supports both IPv4 and IPv6 addresses automatically - Only parses actual `nameserver` lines (ignores comments) - Collects all nameservers for redundancy - Provides public DNS fallback if no nameservers found - Maintains backward compatibility Signed-off-by: Sofer Athlan-Guyot <sathlang@redhat.com> Closes: [OSPCIX-1114](https://issues.redhat.com/browse/OSPCIX-1114)
sathlan
force-pushed
the
update-ipv6-workload-dns
branch
from
b12ea58 to
6bb9431
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
2 participants
The workload launch script fails on IPv6-only RHOSO deployments because it uses an IPv4-only regex to extract nameservers from
/etc/resolv.conf. This causes subnet creation to fail when only IPv6 nameservers are available.Replace the regex approach with
awk-based parsing that:nameserverlines (ignores comments)Closes: OSPCIX-1114