Remove planned deprecated 'resolver.source' profile property#1343
Remove planned deprecated 'resolver.source' profile property#1343tgreenx merged 8 commits intozonemaster:developfrom
Conversation
mattias-p
left a comment
There was a problem hiding this comment.
It seems I went too fast reviewing this the first time. When I had a look at it again I realized there is a problem with how the resolver.source4 and resolver.source6 properties are defined.
|
@matsduf @mattias-p @marc-vanderwal As discussed in the meeting, I added a proper IP validation function to |
lib/Zonemaster/Engine/Util.pm
Outdated
| ); | ||
| } | ||
|
|
||
| sub validate_ip { |
There was a problem hiding this comment.
IMHO, having separate function for IPv4 and IPv6 would make for a better API.
There was a problem hiding this comment.
I didn't do that, because I couldn't see a major benefit. However, to go in that direction I renamed this function from validate_ip() to validate_ip_for_version().
There was a problem hiding this comment.
As discussed in group meeting, it is now done (in commit f29f884).
|
@mattias-p I'm integrating your comments, but I have one problem. I see now that I get a Do you have any clue on how to solve this issue (mutual/circular module imports)? |
mattias-p
left a comment
There was a problem hiding this comment.
I had another look at this PR and started questioning the use of an accessor for the source address. The following review comments are this topic.
Oh, this again. In general I think we should try to avoid circular module dependencies as much as possible, but I we do have a lot of them already. Zonemaster::Engine and Zonemaster::Engine::Util seem to be the worst offenders in this respect. As I refactor code to clean up or make room for other features I try to reduce the amount of circular dependencies. Maybe we should come up with some plan to reduce circular dependencies to sane levels. I'm sure that would involve deprecating a fair number of public methods. For this particular case maybe we could introduce a new Zonemaster::Engine::Validation module that doesn't import any other modules. Zonemaster::Engine::Profile would be able to import that module without problem. |
Now done. And your other comments have been addressed as well. Thanks for the good feedback ! @mattias-p @matsduf @marc-vanderwal please re-review. |
This commit also removes the 'source_address{4,6}' attributes of Zonemaster::Engine::Nameserver objects by using an unified one, 'source_address'.
I believe the change that introduced them was unecessary, as Zonemaster::Engine::Nameserver objects are tied to only one IP address (protocol).
Other tied changes:
- Changes 'resolver.source_address{4,6}' profile properties to not accept illegal values such as undefined or empty values.
- Removes now unused constant '$RESOLVER_SOURCE_OS_DEFAULT'
- Removes now unused function Zonemaster::Engine::Profile::check_validity()
- Rename Zonemaster::Engine::Nameserver::source_address() to Zonemaster::Engine::Nameserver::_build_source_address()
- Refactoring
- Updates documentation
- Updates unit tests
Co-authored-by: Mattias Päivärinta <mattias@paivarinta.se>
- Add constants IPV{4,6}_RE
- Add function Zonemaster::Engine::Util->validate_ip()
- Update documentation
- Update unit tests
f677fbb to
330914a
Compare
fab619f to
cb03801
Compare
…w IP address validation module
- Remove 'source_address' attribute in Zonemaster::Engine::Nameserver
- Rename function '_build_source_address()' to 'source_address()' and make it a public instance method
- Move IP address validation from Zonemaster::Engine::Util to a new module, Zonemaster::Engine::Validation
- Fixes for 'resolver.source{4,6}' properties in Zonemaster::Engine::Profile
- Update and add documentation
- Update unit tests for Zonemaster::Engine::Profile
- Add unit tests for Zonemaster::Engine::Validation
cb03801 to
2dd7139
Compare
mattias-p
left a comment
There was a problem hiding this comment.
I reviewing the test code I found one place where relevant tests are removed and a couple of places of missing tests that we should add. I feel bad about asking you to fix stuff in this PR that you didn't introduce. If you don't feel like fixing those, just say so and I'll make my own PR.
| # JSON representation of an example profile where all set values are sentinels | ||
| Readonly my $EXAMPLE_PROFILE_3 => qq( | ||
| { | ||
| "resolver": { | ||
| "source": "$RESOLVER_SOURCE_OS_DEFAULT" | ||
| } | ||
| } | ||
| ); | ||
|
|
There was a problem hiding this comment.
The empty strings for resolver.source4 and resolver.source6 are also sentinel values, so we need an example profile where those values are present.
# JSON representation of an example profile where all set values are sentinels
Readonly my $EXAMPLE_PROFILE_3 => qq(
{
"resolver": {
"source4": "",
"source6": ""
}
}
);| subtest 'from_json() parses sentinel values from a string' => sub { | ||
| my $profile = Zonemaster::Engine::Profile->from_json( $EXAMPLE_PROFILE_3 ); | ||
|
|
||
| is $profile->get( 'resolver.source' ), $RESOLVER_SOURCE_OS_DEFAULT, 'resolver.source was parsed from JSON'; | ||
| }; |
There was a problem hiding this comment.
We should test parsing of the sentinel values for resolver.source4 and resolver.source6 too.
subtest 'from_json() parses sentinel values from a string' => sub {
my $profile = Zonemaster::Engine::Profile->from_json( $EXAMPLE_PROFILE_3 );
is $profile->get( 'resolver.source4' ), '', 'resolver.source4 was parsed from JSON';
is $profile->get( 'resolver.source6' ), '', 'resolver.source6 was parsed from JSON';
};| subtest 'set() accepts sentinel values' => sub { | ||
| my $profile = Zonemaster::Engine::Profile->new; | ||
|
|
||
| $profile->set( 'resolver.source', $RESOLVER_SOURCE_OS_DEFAULT ); | ||
| is $profile->get( 'resolver.source' ), $RESOLVER_SOURCE_OS_DEFAULT, 'resolver.source was updated'; | ||
|
|
||
| $profile->set( 'resolver.source4', '' ); | ||
| is $profile->get( 'resolver.source4' ), '', 'resolver.source4 was updated'; | ||
|
|
||
| $profile->set( 'resolver.source6', '' ); | ||
| is $profile->get( 'resolver.source6' ), '', 'resolver.source6 was updated'; | ||
| }; | ||
|
|
There was a problem hiding this comment.
We should keep the checks for resolver.source4 and resolver.source6.
subtest 'set() accepts sentinel values' => sub {
my $profile = Zonemaster::Engine::Profile->new;
$profile->set( 'resolver.source4', '' );
is $profile->get( 'resolver.source4' ), '', 'resolver.source4 was updated';
$profile->set( 'resolver.source6', '' );
is $profile->get( 'resolver.source6' ), '', 'resolver.source6 was updated';
};|
@mattias-p @matsduf @marc-vanderwal Comments have been addressed, please re-review. |
Release testing for v2024.1I have verified that there is no more |
Purpose
This PR removes the planned deprecated
resolver.sourceprofile property. It also adds a proper IP validation module (and functions) inZonemaster::Engine::Validation.Other related changes to the
resolver.source{4,6}profile properties andZonemaster::Engine::Nameserver source_address{4,6}attributes are made. See the Changes section.Context
Fixes #1360
Also fixes Perl warnings from #1342
Changes
This PR removes the
source_address{4,6}andsource_addressattributes ofZonemaster::Engine::Nameserverobjects.Other related changes:
resolver.source_address{4,6}profile properties to not accept illegal values.$RESOLVER_SOURCE_OS_DEFAULTZonemaster::Engine::Profile::check_validity()RenameZonemaster::Engine::Nameserver::source_address()toZonemaster::Engine::Nameserver::_build_source_address()Zonemaster::Engine::Validation::validate_ipv{4,6}()How to test this PR
Unit tests are updated and should pass.