-
Notifications
You must be signed in to change notification settings - Fork 240
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
refactor: add receiver to iptables and create interface #2421
Conversation
eb89d40
to
25d5eab
Compare
343ceee
to
f26f229
Compare
bbbf7c5
to
25ef4c7
Compare
@@ -0,0 +1,9 @@ | |||
package network |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be in iptable package and export interface type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that's not how we do interfaces in Go. The interface exists to abstract the behavior that your code is using from the backing implementation of that behavior at your usage of that behavior. This package only needs this subset of behavior, so the interface should be defined in this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://go.dev/doc/effective_go#interfaces
"If something can do this, it can be used here."
Don't predefine an interface that simply matches a type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i guess iptables package used in other components like cns i guess.. if its just used in network package, then i agree
d9c7fff
to
7ed2c6e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some nits but mostly lgtm
type Client struct{} | ||
|
||
func NewClient() *Client { | ||
return &Client{} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are no fields (at all) being set in this struct, or other initialization magic - we don't need a constructor and can make the struct directly ... := &iptables.Client{}
_, err := client.plClient.ExecuteCommand(enableIPForwardCmd) | ||
if err != nil { | ||
return errors.Wrap(err, "enable ipforwarding command failed") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, I wish we didn't have this in the codebase already... I generally don't think that it's our responsibility to configure the host like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
talked with @QxBytes offline and clarified standard practice is to define interface in consumer side
eaad01c
e640d0a
to
43b4726
Compare
43b4726
to
d621c22
Compare
* Move network utils functions with iptables to new file * Add receiver to iptables and create interface * Resolve conflicts from rebasing * Add changes for building on windows * Address linter issues * Address windows linter issues * Invert if condition for linter nesting * Scope iptables interfaces to package * Rename iptables client to avoid stuttering * Move EnableIPForwarding to snat linux * Rename ipTablesClientInterface to ipTablesClient * Address linter issues from moving enable ip forwarding function * Rename after rebase
* Move network utils functions with iptables to new file * Add receiver to iptables and create interface * Resolve conflicts from rebasing * Add changes for building on windows * Address linter issues * Address windows linter issues * Invert if condition for linter nesting * Scope iptables interfaces to package * Rename iptables client to avoid stuttering * Move EnableIPForwarding to snat linux * Rename ipTablesClientInterface to ipTablesClient * Address linter issues from moving enable ip forwarding function * Rename after rebase
Reason for Change:
The iptables package is currently a set of functions without a receiver. Because of this, any code that uses the iptables package has a dependency on it, and proper unit tests cannot be written. This PR will add a receiver to the iptables methods and create an interface in the network folder so that in the future, unit tests can mock the iptables interface and methods that use iptables can be tested. This PR should not change the functionality of the codebase (for example, existing tests, if they use iptables, should still use a non-mocked version of the new iptables client).
Issue Fixed:
See above.
Requirements:
Notes:
New
function (ex:Client{ }
) has been checked to ensure either an iptablesClient is passed in if the struct now requires aniptablesClient
, or is part of testing code.