-
Notifications
You must be signed in to change notification settings - Fork 347
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 InterfaceStore and podConfigurator #125
Conversation
Thanks for your PR. The following commands are available:
|
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.
LGTM, please merge this soon, it would make my life easier for some of the changes I have to make for Kind support.
/test-e2e |
I need to do one more small cleanup. Will push a PR soon. |
/test-e2e |
b4a39d4
to
79ac262
Compare
Also moved OVS port external ID generation and parsing from interface_cache to pod_configuration. |
/test-e2e |
6dd006a
to
3ab5e12
Compare
@jianjuns there is conflict need to be resolved after I checked in GARP fixes. |
@@ -33,7 +34,7 @@ func TestInitCache(t *testing.T) { | |||
|
|||
mockOVSBridgeClient.EXPECT().GetPortList().Return(nil, ovsconfig.NewTransactionError(fmt.Errorf("Failed to list OVS ports"), true)) | |||
|
|||
cache := NewInterfaceStore() | |||
cache := agent.NewInterfaceStore(ParseOVSPortInterfaceConfig) |
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.
@jianjuns interface_cache_test.go
is under pkg/agent/cniserver
while interface_cache.go
is under pkg/agent
, is it by intention?
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.
Yes. But the thing is the test actually tests mostly Pod interface configuration, and requires pod_configuration internal funds and structs after my changes. Let me know what you think.
BTW I just rename it to interface_store_test.go as it just references InterfaceStore but interfaceCache which is an internal struct.
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.
In my understanding, it's not common that go source file and its unit test file are not put together, guess people would still question where is interface_store.go after the renaming.
The test code in interface_store_test.go actually have two different scopes: one is for NewInterfaceStore.Initialize
and the other is for buildOVSPortExternalIDs
.
I think the former should be moved to pkg/agent/interface_cache_test.go and the required constants need to be public or maybe use raw strings as part of test inputs.
The later test case name is a little misleading, it's actually testing buildOVSPortExternalIDs, should we call it TestBuildOVSPortExternalIDs and keep it in pkg/agent/cniserver/pod_configuation_test.go?
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.
The problem is the test for NewInterfaceStore.Initialize - uses pod_configuration internal types to generate OVS ports (and the OVS port logic in my mind should belong to pod_configuration and should not be exposed outside), and requires ParseOVSPortInterfaceConfig from cniserver (and I could not import cniserver due to import cycle).
Let me know if you have suggestions on how to resolve the above.
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.
Maybe InterfaceStore.Initialize
mixes too much business code, it needs to hold ovsBridgeClient and know how to list Port, and hold containerInterfaceParser to know how to parse OVSPort while its other methods are all pure cache access operations taking the constructed InterfaceConfig
.
As a cache struct, maybe we can just let Initialize
take the parsed InterfaceConfigs
like AddInterface
, the listing and parsing can be done in setupOVSBridge
before calling InterfaceStore.Initialize
, this could make the cache face InterfaceConfig only, getting rid of OVS list and parse logic , also make unit test easier as we don't need to mock ovsBridgeClient any more.
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 could change InterfaceStore.Initialize (or just move the func to agent.go), but then the question is still what we want to test in TestInitStore? You just want to test inserting a set of InterfaceConfigs to the store and checking they are added?
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.
Isn't a good thing that the cache can be got rid of those dependencies and be so clean that we even think UT is not necessary? If we want to keep the original test code, they could be moved to pkg/agent/agent_test.go by testing setupOVSBridge or another method extracted from it.
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.
Sure. I agree it is cleaner to move OVS operations to agent.go (feel better to do another PR though if no other reasons for that as my current one adds more and more changes).
My question is on the test - do we want to keep a test that generates OVS port data from OVS mock, and initializes the InterfaceStore from that - if so the test might need to be in the cniserver package as it uses pod_configuration funcs and types (unless you have a way to resolve this esp. the import cycle). Or we just write a test only for inserting InterfaceConfig to the store and checking they are indeed inserted? Or maybe you want both?
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 think the problem is that currently pkg/agent mixes too many stuff (there are types needed by itself and its sub-package, which makes it can't even depend on its sub-package, and its sub-package depends on agent only because of these types).
Maybe we could move types like NodeConfig
, Gateway
, OVSPortConfig
to pkg/agent/types
as we already have it.
Also move interface_cache to separate package pkg/agent/cache
as it's depended by both agent and cniserver. Then agent can depend on cniserver as it's supposed to do.
The layout would be:
type
^
|
cache
^ ^
| |
cniserver <- agent
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 created another commit to refactor InterfaceStore and types. Please check.
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.
LGTM, just a comment about how to organize the test code in Go style. Let me if it makes sense to you.
/test-e2e |
a859156
to
9ceaf9e
Compare
Add a struct type - podConfigurator - to be the receiver of the Pod configuration funcs which use the podConfigurator struct fields.
Move InterfaceStore to a separate package. This could avoid sub-packages of agent depends on the agent package which could lead to import cycle. For the same reason, move NodeConfig and GatewayConfig from agent to agent/types. Move OVS port data initialization to agent.Initializer. Move OVS port external ID generation and parsing to podConfigurator. Change "MTU" in structs and func arguments to "mtu".
/test-e2e |
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.
LGTM
Before aggregating, validate data records if all the records have proper values after decoding.
Add a struct type - podConfigurator - to be the receiver of the Pod
configuration funcs which use the podConfigurator struct fields.