-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Fix incomplete Mounts attributes #25697
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
base: main
Are you sure you want to change the base?
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 |
---|---|---|
|
@@ -4,6 +4,7 @@ import ( | |
"time" | ||
|
||
netTypes "github.com/containers/common/libnetwork/types" | ||
pod_define "github.com/containers/podman/v5/libpod/define" | ||
define "github.com/containers/podman/v5/pkg/ps/define" | ||
) | ||
|
||
|
@@ -41,7 +42,7 @@ type ListContainer struct { | |
// Labels for container | ||
Labels map[string]string | ||
// User volume mounts | ||
Mounts []string | ||
Mounts []pod_define.InspectMount | ||
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. As I mentioned on the issue these are breaking changes to a user facing API and cannot be done. We canont just break things. 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. My 2cent: I understand, but at least for a major release. Each major release of all software could introduce breaking changes, but the fear to keep everything "unbreakable" just stops any improvement on the software itself (and on podman). But still, those "Mounts" attributes as-is, that are just destination directories, are unusable, simply because the same call does not return the related "Source", it is just an example. For this particular case, I'm happily spending my small free time to enrich those data. I don't do this only because I need, I do because I "believe" on podman project and I use it as a standard over docker 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.
This isn't a fear, this is plain and simple a breaking API change. An old remote client would be unable to parse this json and thus break podman ps and the other way around the same way. We cannot just break API users just because you happen to need different data in the field. There are ways to introduce new features without breaking existing ones, we do that all the time. New options and new fields would be fine (still assumes they make sense overall and are maintainable) but you cannot break the format of an existing one. Yes we can break things in a major release but a new major release is still far away, not even planned yet. And if we like to break things that there must be a strong reason and we should do a careful audit of similar problems in the list API. Otherwise we have the same issue on a different field again.
I am thankful that you take the time to contribute to the project, but compatibility is an important topic for us, so you would need to find another way to move this forward. Adding a new API field that has the data you need could be an option. |
||
// The names assigned to the container | ||
Names []string | ||
// Namespaces the container belongs to. Requires the | ||
|
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 is going to break upgrades from previous versions - you can't deserialize a JSON string into a
define.InspectMount
. It should be possible to, instead of this, make afunc (c *Container) InspectMounts() ([]define.InspectMount, error)
that takes the libpod ContainerConfig and converts it into InspectMount in the same way Inspect does (with a minor refactor, you could use the same code for both). That would probably be sufficient for your needs here, no?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 I can try. I understand it would be a breaking change. As I reported in my comment below, it would be great if, at least, it could be applied on the next major release.
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.
to which specific Inspect function you refer? This one?
podman/libpod/container_inspect.go
Line 39 in 490eb47