-
Notifications
You must be signed in to change notification settings - Fork 59
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
Implement STATUS #121
base: main
Are you sure you want to change the base?
Implement STATUS #121
Conversation
This commit implements the STATUS CNI verb. It adds a new function StatusDetail which returns a list with the status of each network. Signed-off-by: Michael Zappa <[email protected]> Signed-off-by: Archit Kulkarni <[email protected]> Co-authored-by: Michael Zappa <[email protected]>
67c32dd
to
a45b44a
Compare
cni.go
Outdated
var networks []*NetworkStatus | ||
|
||
for _, network := range c.Networks() { | ||
if network.config.Name == "cni-loopback" { |
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.
Why this specific magic name? Can we move it out to a constant with a comment explaining?
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.
@MikeZappa87 do you know the answer?
Actually, would it make sense to just delete this special case entirely? Even if the status will always just be "ready" for cni-loopback
, it might make the code cleaner and more futureproof.
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.
We are deprecating the cni-loopback and the return will always be the same regardless.
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.
Done, added a comment and moved it to a constant: be034ef
Signed-off-by: Archit Kulkarni <[email protected]>
Co-authored-by: Samuel Karp <[email protected]> Signed-off-by: Archit Kulkarni <[email protected]>
90ca69d
to
a7839ab
Compare
@@ -60,3 +60,8 @@ type DNS struct { | |||
// List of DNS options. | |||
Options []string | |||
} | |||
|
|||
type NetworkStatus struct { | |||
Network *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.
Do we need to expose anything else here? Right now all the fields of Network
are private.
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.
Is it enough to make ifName
public?
Lines 26 to 30 in a45b44a
type Network struct { | |
cni cnilibrary.CNI | |
config *cnilibrary.NetworkConfigList | |
ifName string | |
} |
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.
As a consumer of the Status API does making this private or public help? Exposing ifName might be useful especially if we ever begin to support multiple interfaces upstream.
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.
@MikeZappa87 The first use case that came to mind was just the error message, like if the kubelet sees that one of the entries of StatusDetail
has an error, in the log it can report ifName
along with the error. But there are probably other possible use cases I'm not aware of.
What about config
, should we expose the whole config
or just certain fields like Name
, CNIVersion
?
type NetworkConfigList struct {
Name string
CNIVersion string
DisableCheck bool
DisableGC bool
LoadOnlyInlinedPlugins bool
Plugins []*PluginConfig
Bytes []byte
}
cni.go
Outdated
return nil, err | ||
} | ||
|
||
var networks []*NetworkStatus |
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.
nit: rename to networkStatus ?
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.
Done, renamed to networkStatuses because it's a list: 03fbaaf
Signed-off-by: Archit Kulkarni <[email protected]>
Signed-off-by: Archit Kulkarni <[email protected]>
03fbaaf
to
b110ac0
Compare
I don't understand the linter errors that appeared after the last two commits, they seem unrelated. Any ideas? |
Dunno.. the last commit success build here was in june.. you could try an empty commit (1line doc change) and see if our current version of stretcher 1.8.0 , golang, lint all still work .. noting that the core repo has moved up with stretcher 1.9 now the latest |
A bit weird because it passed two commits ago on this PR last week: https://github.com/containerd/go-cni/actions/runs/11351584389/job/31572471088 But let me try what you suggested |
ikr.. sure enough though even trivial non code no longer passes |
let's see on the working run you linked for the linter 1.21.8 test we have: on the failure here for the same 1.21.8 bucket we have |
@@ -374,6 +376,12 @@ func TestLibCNIType120(t *testing.T) { | |||
|
|||
err = l.Remove(ctx, "container-id1", "/proc/12345/ns/net") | |||
assert.NoError(t, err) | |||
|
|||
statuses, err := l.StatusDetail(ctx) |
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 fake configuration that is being generated, is that 1.1.0? Can you verify that I don't think the Status verb is actually being executed.
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.
@MikeZappa87 Thanks for the comment, just want to make sure I understand everything -- In the approach currently taken by this PR, StatusDetail isn't called anywhere yet (the proposal was to have containerd call it), so you're right that the Status verb isn't executed unless we explicitly call StatusDetail. Since we do call StatusDetail in the test here, I think this line https://github.com/containerd/go-cni/pull/121/files#diff-6cdf85f441267859d068399676e5f0ad8946811bd7e951b4e80db98d9fd2489cR318 asserts that the (mocked) status verb is being executed.
I don't see 1.1.0 specified anywhere in the fake config, but I think that doesn't affect the test because the version check happens inside cni.GetStatusNetworkList, and this function is mocked out. Is that right?
Closed in favor of #123 |
we could probably still use detail for each of the plugins vs fail first..? |
Sure, reopening |
Based on @MikeZappa87's earlier PR #114.
This commit implements the STATUS CNI verb. It adds a new function StatusDetail to return the result of STATUS for each network.
Related info: