-
Notifications
You must be signed in to change notification settings - Fork 18.8k
api/types/registry: move ServiceConfig
legacy field marshaling support into daemon backend
#50826
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
api/types/registry: move ServiceConfig
legacy field marshaling support into daemon backend
#50826
Conversation
Placing back in draft. Just realizing from the unit tests |
// MarshalJSON implements a custom marshaler to include legacy fields | ||
// in API responses. | ||
func (sc *ServiceConfig) MarshalJSON() ([]byte, error) { |
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.
It's used by the daemon to produce API responses for older API versions. If we remove this here, we probably need to create a wrapper struct with marshaling in the daemon API server; see
moby/daemon/server/router/system/system_routes.go
Lines 105 to 112 in ed8a6a8
if versions.LessThan(version, "1.47") { | |
// Field is omitted in API 1.48 and up, but should still be included | |
// in older versions, even if no values are set. | |
info.RegistryConfig.ExtraFields = map[string]any{ | |
"AllowNondistributableArtifactsCIDRs": json.RawMessage(nil), | |
"AllowNondistributableArtifactsHostnames": json.RawMessage(nil), | |
} | |
} |
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 recall I had a branch somewhere with a more generic package to allow "append old API fields" but not sure if I have preserved it 🙈
It should not be used by clients, only the daemon, but yeah, we need to find a good spot / approach for these. The general attempt here was to allow the daemon to continue serving "legacy" responses (where no sensible content is to be served, other than "the field is there") but being able to remove the fields from the structs before the API is a module (so basically no more opportunities to remove such fields if they're used by the client). |
Okay that makes more sense. Thanks @thaJeztah. Let me rework this to create a structure down in the daemon and have the legacy fields support there. |
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
aaef882
to
27040dd
Compare
27040dd
to
b97382c
Compare
ServiceConfig.MarshalJSON
ServiceConfig
legacy field marshaling support into daemon backend
…atability This change moves the logic that is used to marshal the legacy extra fields for `registry.ServiceConfig` type to the daemon backend. Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
b97382c
to
c9fdad2
Compare
- What I did
Partial of #50740
This change removes the
ServiceConfig.MarshalJSON
function from and moves the marshaling logic of legacy fields down into the daemon backend.- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)