Skip to content
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

Fix duplicate check with different mac format #397

Merged

Conversation

fossedihelm
Copy link
Contributor

@fossedihelm fossedihelm commented Oct 24, 2023

A macAddress can be specified with different separators:

  • ":" e.g. "02:00:00:00:ff:ff"
  • "-" e.g. "02-00-00-00-ff-ff"
  • "." e.g. "0200.0000.ffff"

Currently, the duplicate mac check works only if the two compared mac address use the same separator.
The duplicate check is made looking at the existence of key of the macMap. The keys of the mapMap are the macAddress string.

With this commit, a macKey struct is introduced. The latter stores the normalized string of the macAddress and can be used as unique key and identifier of a macAddress.

What this PR does / why we need it:

Special notes for your reviewer:
Fixes https://issues.redhat.com/browse/CNV-30974

Release note:

Fix duplicate check with different mac address separator

@kubevirt-bot
Copy link
Collaborator

Hi @fossedihelm. Thanks for your PR.

I'm waiting for a k8snetworkplumbingwg member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fossedihelm
Copy link
Contributor Author

@RamLavi Can you have a look please? Thanks

Copy link

@maiqueb maiqueb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is required but IMO it doesn't do enough since there are other supported types of format for MAC addresses:

  • canonical (- separator, which your PR adds support for)
  • hexstring (: separator, the only thing currently accepted by kubemacpool)
  • dot notation (. separator, in 4 char segments - e.g. 0000.5e00.5301)
  • hexadecimal

Maybe the correct thing to do is to create a MAC address - net.HardwareAddr - using net.ParseMAC and then get the string from it (whatever that is) ?

@kubevirt-bot
Copy link
Collaborator

@maiqueb: changing LGTM is restricted to collaborators

In response to this:

This PR is required but IMO it doesn't do enough since there are other supported types of format for MAC addresses:

  • canonical (- separator, which your PR adds support for)
  • hexstring (: separator, the only thing currently accepted by kubemacpool)
  • dot notation (. separator, in 4 char segments - e.g. 0000.5e00.5301)
  • hexadecimal

Maybe the correct thing to do is to create a MAC address - net.HardwareAddr - using net.ParseMAC and then get the string from it (whatever that is) ?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fossedihelm
Copy link
Contributor Author

Maybe the correct thing to do is to create a MAC address - net.HardwareAddr - using net.ParseMAC and then get the string from it (whatever that is) ?

@maiqueb That's a great idea! IMHO we can also skip the err from ParseMAC function, since it has already been validated. WDYT?

@maiqueb
Copy link

maiqueb commented Oct 26, 2023

Maybe the correct thing to do is to create a MAC address - net.HardwareAddr - using net.ParseMAC and then get the string from it (whatever that is) ?

@maiqueb That's a great idea! IMHO we can also skip the err from ParseMAC function, since it has already been validated. WDYT?

Fine with me. I mean, there's nothing wrong in being redundant - checking against nil won't take long - but if you're sure that was already validated, all good. I just find it more readable / comforting to see the (ugly) golang pattern of if err != nil ; return err . It's up to the maintainer.

Copy link

@maiqueb maiqueb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good !

@kubevirt-bot
Copy link
Collaborator

@maiqueb: changing LGTM is restricted to collaborators

In response to this:

Looks good !

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@fossedihelm
Copy link
Contributor Author

fossedihelm commented Oct 26, 2023

Fine with me. I mean, there's nothing wrong in being redundant - checking against nil won't take long - but if you're sure that was already validated, all good. I just find it more readable / comforting to see the (ugly) golang pattern of if err != nil ; return err . It's up to the maintainer.

Yes, I generally agree! In this specific case, handling the error means to create something like this:

func NewMacKey(macAddressDashes string) (macKey, error) {
	macAddress, err := net.ParseMAC(macAddressDashes)
        if err != nil{
            return macKey{}, err
        }
	return macKey{normalizedMacAddress: macAddress.String()}, nil
}

This is not a problem at all, but this will not allow us to create inline entry in the macMap.
And the latter is very useful in tests, in addition to the fact that we should clearly always handle the return error.

@maiqueb
Copy link

maiqueb commented Oct 26, 2023

Fine with me. I mean, there's nothing wrong in being redundant - checking against nil won't take long - but if you're sure that was already validated, all good. I just find it more readable / comforting to see the (ugly) golang pattern of if err != nil ; return err . It's up to the maintainer.

Yes, I generally agree! In this specific case, handling the error means to create something like this:

func NewMacKey(macAddressDashes string) (macKey, error) {
	macAddress, err := net.ParseMAC(macAddressDashes)
        if err != nil{
            return macKey{}, err
        }
	return macKey{normalizedMacAddress: macAddress.String()}, nil
}

This is not a problem at all, but this will not allow us to create inline entry in the macMap. And the latter is very useful in tests, in addition to the fact that we should clearly always handle the return error.

Maybe it's best to add a comment to the NewMacKey func indicating it's inputs must be already validated MAC addresses ? And indicate all it does is parse from N mac address formats to "our" definition of canonical format.

This is just a nit. Consider adding it if someone else asks you to change the code.

@fossedihelm
Copy link
Contributor Author

Maybe it's best to add a comment to the NewMacKey func indicating it's inputs must be already validated MAC addresses ? And indicate all it does is parse from N mac address formats to "our" definition of canonical format.

This is just a nit. Consider adding it if someone else asks you to change the code.

I put this just before the ParseMAC func:

// we can ignore the error here since the string value has already been validated

but yes, I can insert the description above the func! Thanks, will do!

@fossedihelm
Copy link
Contributor Author

@maiqueb PTAL

@kubevirt-bot
Copy link
Collaborator

@maiqueb: changing LGTM is restricted to collaborators

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@RamLavi
Copy link
Member

RamLavi commented Oct 29, 2023

/ok-to-test

Copy link
Member

@RamLavi RamLavi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @fossedihelm, thanks for your contribution!
Please see comments added.

Also, note the e2e test failing is concerning - and suggests that we missed something.. If you need help ping me

pkg/pool-manager/macentry_test.go Show resolved Hide resolved
pkg/pool-manager/pod_pool.go Show resolved Hide resolved
pkg/pool-manager/pool.go Outdated Show resolved Hide resolved
pkg/pool-manager/virtualmachine_pool.go Show resolved Hide resolved
macPoolMap provides a save remove entry function
that could always be preferred respect the
directly `delete` function.

Signed-off-by: fossedihelm <ffossemo@redhat.com>
@RamLavi
Copy link
Member

RamLavi commented Oct 30, 2023

/hold

let's merge only after stable branches are introduced to KMP

@fossedihelm
Copy link
Contributor Author

Thanks @RamLavi for the review!
I am working on the relevant failing e2e tests. Thank you!

@fossedihelm
Copy link
Contributor Author

Changes:

  • Addressed comments
  • Fixed failing e2e test:
    -- there were a mixed comparison between iface.MacAddress and macKey.String()
    -- the first one was upper case, the latter in lower case.
  • Added MarshalJSON() ([]byte, error) to macMap struct to allow logger to correctly print the map

Copy link
Member

@RamLavi RamLavi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the changes!
Big like for the Marshal function added.

Added one more comment.

pkg/pool-manager/macpoolmap.go Outdated Show resolved Hide resolved
pkg/pool-manager/mackey.go Outdated Show resolved Hide resolved
@fossedihelm
Copy link
Contributor Author

thanks for the changes! Big like for the Marshal function added.

Added one more comment.

Thanks @RamLavi for the great suggestion! I addressed the commets. PTAL

Copy link
Member

@RamLavi RamLavi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

last one :)

pkg/pool-manager/virtualmachine_pool.go Outdated Show resolved Hide resolved
As per https://pkg.go.dev/net#ParseMAC, a macAddress can be specified
as an IEEE 802 MAC-48, EUI-48, EUI-64, or a 20-octet IP using the following formats:

- 00:00:5e:00:53:01
- 02:00:5e:10:00:00:00:01
- 00:00:00:00:fe:80:00:00:00:00:00:00:02:00:5e:10:00:00:00:01
- 00-00-5e-00-53-01
- 02-00-5e-10-00-00-00-01
- 00-00-00-00-fe-80-00-00-00-00-00-00-02-00-5e-10-00-00-00-01
- 0000.5e00.5301
- 0200.5e10.0000.0001
- 0000.0000.fe80.0000.0000.0000.0200.5e10.0000.0001

Currently, the duplicate mac check works only if the
two compared mac address use the same separator.
The duplicate check is made looking at the existence of key
of the macMap. The keys of the mapMap are the macAddress string.

With this commit, a `macKey` struct is introduced. The latter
stores the normalized string of the macAddress and can be used
as unique key and identifier of a macAddress.

NB: Currently KubeVirt does not allow EUI-64 and 20-octet IP mac addresses.

Signed-off-by: fossedihelm <ffossemo@redhat.com>
Copy link
Member

@RamLavi RamLavi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@fossedihelm does this change need to be backported?
If not, then I'll remove the old after the CVE storm passes and I add the appropriate stable branches...

@kubevirt-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RamLavi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@RamLavi
Copy link
Member

RamLavi commented Oct 31, 2023

/hold cancel

@kubevirt-bot kubevirt-bot merged commit 69258d0 into k8snetworkplumbingwg:main Oct 31, 2023
@RamLavi
Copy link
Member

RamLavi commented Nov 1, 2023

/cherry-pick release-0.42

@kubevirt-bot
Copy link
Collaborator

@RamLavi: new pull request created: #407

In response to this:

/cherry-pick release-0.42

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants