-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Support multiple cni plugin bin dirs #11311
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -87,7 +87,7 @@ func (c *criService) initPlatform() (err error) { | |
| i, err := cni.New(cni.WithMinNetworkCount(networkAttachCount), | ||
| cni.WithPluginConfDir(dir), | ||
| cni.WithPluginMaxConfNum(max), | ||
| cni.WithPluginDir([]string{c.config.NetworkPluginBinDir})) | ||
| cni.WithPluginDir(c.config.NetworkPluginBinDirs)) | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mikebrow actually I just realized one thing: we cannot switch the default here yet, as the old field is not yet removed. Say if a user only uses Giving this, how about let's keep the default value unchanged? And do the switch when we remove the old field? (we will still add a deprecation warning saying
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wait... actually the opposite also stands. If we keep the default
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. essentially we cannot figure out a field is set by default or explicitly by user. We can do something like this:
WDYT @mikebrow
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the way it works.. just to confirm... the concern about "default" should not be an issue unless the field doesn't work when unset... but even then we should not be .. "merging" defaults over unset fields with the exception of there is no config.toml at all
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so .. if bin_dir is set in a prior version.. migrate to bin_dirs[] to become the current version .. pls check my math :-) may require a version bump for the config for 2.1
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
yep that's right, no issue if a user migrates from verson 2 to 3, as Say a user has Since we move default from This will break our config validation which doesn't allow both fields non-empty. To the user it shouldn't break, becault they still only set up
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It will be:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
nod.. needs a new config "version" to migrate to otherwise user will have to do a manual migration.. to 3.0 containerd 2.0 to 3.0++ containerd 2.1 .. surprised we didn't do a bump yet missed we don't have a 4.0 config for 2.1 or some other process to handle new fields minor migrations for exclusive fields.. @samuelkarp @dmcgowan ... so hold off on merging till we get a migration solution from 2.0 to 2.1
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we could hold off on the migration feature until there is a bump.. keeping it a "manual" operation .. leave the default as it was.. originally.. add the new field description in to the docs with the deprecation.. indicating the old field will be migrated with the next version of the config.. something to that effect
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mikebrow could you PTAL the latest patch? especially this file: https://github.com/containerd/containerd/pull/11311/files#diff-e8d6dbb2c75752c173c570eabb9961d5b0f3273b682788f2d7eab2f5ffd5d7d6 This should handle the case where a user-set I think this will make the change backward compatible with 2.0, i.e., regardless if user set |
||
| if err != nil { | ||
| return fmt.Errorf("failed to initialize cni: %w", err) | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.