fixing dns server delete record in all roles#253
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the DNS record deletion logic across the Active Directory, FreeIPA, and Samba roles to query and delete records directly using provider-specific tools rather than relying on generic dig commands, and adds IPv6 support to the network device utility. However, the refactored deletion logic introduces several critical issues that must be addressed: multiple potential TypeError exceptions from slicing or checking None values, a logic inversion in Samba where deletion only occurs if no records are found, an AttributeError on self.zone, a typo in raise_on_error, and several Python runtime errors in FreeIPA (such as calling the non-existent trim() method and unpacking errors).
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
danlavu
force-pushed
the
ipv6
branch
4 times, most recently
from
86b2135 to
d96150a
Compare
danlavu
changed the title
|
|
||
| def add_device(self, ip: str, netmask: str = "255.255.255.0") -> IPUtils: | ||
| def add_device( | ||
| self, ip: str, netmask: str = "255.255.255.0", ipv6: str | None = None, prefix: str = "64" |
There was a problem hiding this comment.
I really do not like that we have different way to specify netmask for IPv4 and 6.
is is too late to change netmask to prefix and prefix to prefix6?
in my opinion it would be better to have it in connected string like:
add_device(self, ip: str, ipv6: str | None = None) where ip can be 1.2.3.4/24 or 1.2.3.4/255.255.255.0 and ipv6 can be like cafe::1/64. We can easily detect that "/" is missing and provide default for it.
What do you think?
There was a problem hiding this comment.
Updated, str or list, so we can link multiple ips to the device.
thalman
left a comment
thalman
left a comment
There was a problem hiding this comment.
Overall looks good. See my question about add_device.
danlavu
force-pushed
the
ipv6
branch
7 times, most recently
from
08891e8 to
a5bc137
Compare
spoore1
left a comment
spoore1
left a comment
There was a problem hiding this comment.
Overall looks good and from testing it's working. I have a few nit-picks (optional mostly) and one actual question about the version pinning for pytest-mh.
|
|
||
| If dig returns a result, iterate through the zones, if the zone is in the name, it's a forward record. | ||
| The return may be from the cache, search the zone for the record, if found, delete it. If "in-addr" is | ||
| in the zone name, it's a reverse record then follows the same steps as a forward record. |
There was a problem hiding this comment.
Nit-pick: the phrasing with the word then here sounds slightly off to me:
If "in-addr" is in the zone name, it's a reverse record then follows the same steps
Is this closer to the intent:
If "in-addr" is in the zone name, it's a reverse record and should follow the same steps
or more like this:
If "in-addr" is in the zone name, it's a reverse record that follows the same steps
| if records is not None: | ||
| for zone in zones: | ||
| if zone in name: | ||
| a_record = self.host.conn.run( |
There was a problem hiding this comment.
since you have to loop through a potential list of a records returned here, would it make more sense for the variable to be named a_records and change the for below from:
for j in a_record:
to:
for a_record in a_records:
There was a problem hiding this comment.
Yes, it does make sense, fixed.
| pytest | ||
| python-ldap | ||
| pytest-mh >= 1.0.29 | ||
| pytest-mh |
There was a problem hiding this comment.
Is this temporary? I believe we want it pinned to a minimum version don't we?
There was a problem hiding this comment.
Yea, I'm not sure what is going on. IDMCI is failing because sssd-test-framework has a conflicting version, which shouldn't be an issue since it's version 1.0.3 , needs further investigation.
danlavu
force-pushed
the
ipv6
branch
2 times, most recently
from
1702860 to
05fda02
Compare
|
I have to redo the entire ipa logic because it was only returning one record. Looking back on this, knowing how complex it is now, I would have added more methods to find the record, get the record, etc. It may be beneficial if the look-up is faster than the dig. I think this will work in the interim. |
|
Increasing the retry/delay to a total of 120 seconds, from the run in IDMCI. |
|
working in idmci |
3 participants
The dig query is insufficient because it may be cached, failing when called because it attempts to delete a record that doesn't exist in the zone.
The method logic, at a high level, goes like this: because we pass in one parameter, we need to resolve the IP address from the hostname, which may return multiple addresses. We then iterate through the zones to determine the type of record. There may be a case where the A record is deleted, but still needs to iterate through because the PTR record exists. Then we determine if it's an IPv4 or IPv6 address. Each type of record requires a different argument to delete it properly, and then there is a lot of formatting required.