cmd, pkg/podman: Introduce Image Interface and Unit Tests#1724
cmd, pkg/podman: Introduce Image Interface and Unit Tests#1724DaliborKr wants to merge 1 commit intocontainers:mainfrom
Conversation
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 06s |
debarshiray
left a comment
debarshiray
left a comment
There was a problem hiding this comment.
Thanks for working on this, @DaliborKr ! My apologies for the delay.
I am still reading through the changes, but one thing popped out at me.
src/pkg/podman/image.go
Outdated
| } | ||
|
|
||
| func (images Images) Len() int { | ||
| return len(images.data) |
There was a problem hiding this comment.
It might be better to change these pre-existing methods from ImageSlice that earlier had value receivers to pointer receivers.
I am not an expert on value versus pointer receivers, and I get confused all the time. It seems that the general advice is to not mix pointer and value receivers for a given type.
In the case of the Images type, the Reset() method must have a pointer receiver because it modifies a field of the type.
In case you wonder how the Swap() method was working, just like I did, it's because in Go slices are references to an underlying array and changing an element of a slice modifies the array and other slices see the same change. The value receiver copies the slice and the underlying array stays the same.
This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to export Image.FlattenNames() from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724
This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to export Image.FlattenNames() from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772
This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to export Image.FlattenNames() from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772
Subsequent commits will use isToolbx() for image labels. So, it can't be in a file that's specific to containers. containers#1724 containers#1772
This is a step towards eliminating or reducing the code in getImages() by doing everything or more in podman.GetImages(). If nothing else, this removes the need to keep a copy of the labels used to identify Toolbx images for getImages(). The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772
This is a step towards eliminating the code in getImages() by doing everything in podman.GetImages(). This removes the need to export the podman.ImageSlice type from the podman package. The getImages() function originated as listContainers(), when it invoked 'podman images --filter label=...' through podman.GetImages() separately for each label used to identify Toolbx images, and then joined and sorted the results. This changed in commit 2369da5 when getImages() started invoking 'podman images' only once through podman.GetImages() to get all available images, and then filtered them itself based on the labels. Before this change in commit 2369da5, it probably made some sense to keep podman.GetImages() only as a thin wrapper to invoke 'podman images' with different options, and to do everything else in getImages(). However, since then more is being done inside the podman package (eg., unmarshalling the 'podman images' JSON in commit 5f324d5 and flattening the images in commit 6aab0a6), and getImages() is the only caller of podman.GetImages(). Therefore, it looks awkward to have the code to get all Toolbx images split across two functions in different packages. containers#1724 containers#1772
debarshiray
force-pushed
the
image_interface
branch
from
5a6721a to
12863ee
Compare
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
debarshiray
left a comment
debarshiray
left a comment
There was a problem hiding this comment.
I noticed a few more relatively minor things while trying to rebase this against main.
In reaction to the conversation in PR containers#1707, I made suggested changes to the implementation in terms of how Image information, received from Podman, is represented and treated in the Toolbx code. I used the same procedure as in the case of representing Containers: - Commit e611969 - Commit ec7eb59 In short, the JSON from 'podman inspect --type image' and 'podman images' are different, so logically, there should be different implementations of the JSON.Unmarshaler interface [1] for them as well. The new Image interface provides access to the values parsed from the JSONs and two different concrete types, which are implemented separately to handle the differences in the JSONs. GetImages() now returns an Images iterator-like structure that handles image flattening and sorting internally. InspectImage() returns an Image interface instead of map[string]interface{}, and the IsToolboxImage() function was replaced with the IsToolbx() method on the Image interface. Tested were results of Podman starting on version 1.1.2, which should be sufficient since the minimum required Podman version is 1.6.4 (see commit 8e80dd5). Covered are structures representing podman commands 'podman inspect --type image' and 'podman images'. [1] https://pkg.go.dev/encoding/json#Unmarshaler containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
debarshiray
force-pushed
the
image_interface
branch
from
12863ee to
aa553fc
Compare
In reaction to the conversation in PR containers#1707, I made suggested changes to the implementation in terms of how Image information, received from Podman, is represented and treated in the Toolbx code. I used the same procedure as in the case of representing Containers: - Commit e611969 - Commit ec7eb59 In short, the JSON from 'podman inspect --type image' and 'podman images' are different, so logically, there should be different implementations of the JSON.Unmarshaler interface [1] for them as well. The new Image interface provides access to the values parsed from the JSONs and two different concrete types, which are implemented separately to handle the differences in the JSONs. GetImages() now returns an Images iterator-like structure that handles image flattening and sorting internally. InspectImage() returns an Image interface instead of map[string]interface{}, and the IsToolboxImage() function was replaced with the IsToolbx() method on the Image interface. Tested were results of Podman starting on version 1.1.2, which should be sufficient since the minimum required Podman version is 1.6.4 (see commit 8e80dd5). Covered are structures representing podman commands 'podman inspect --type image' and 'podman images'. [1] https://pkg.go.dev/encoding/json#Unmarshaler containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
debarshiray
force-pushed
the
image_interface
branch
from
aa553fc to
904a92e
Compare
|
I rebased this branch on top of |
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 09s |
In reaction to the conversation in PR containers#1707, I made suggested changes to the implementation in terms of how Image information, received from Podman, is represented and treated in the Toolbx code. I used the same procedure as in the case of representing Containers: - Commit e611969 - Commit ec7eb59 In short, the JSON from 'podman inspect --type image' and 'podman images' are different, so logically, there should be different implementations of the JSON.Unmarshaler interface [1] for them as well. The new Image interface provides access to the values parsed from the JSONs and two different concrete types, which are implemented separately to handle the differences in the JSONs. GetImages() now returns an Images iterator-like structure that handles image flattening and sorting internally. InspectImage() returns an Image interface instead of map[string]interface{}, and the IsToolboxImage() function was replaced with the IsToolbx() method on the Image interface. Tested were results of Podman starting on version 1.1.2, which should be sufficient since the minimum required Podman version is 1.6.4 (see commit 8e80dd5). Covered are structures representing podman commands 'podman inspect --type image' and 'podman images'. [1] https://pkg.go.dev/encoding/json#Unmarshaler containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
debarshiray
force-pushed
the
image_interface
branch
from
904a92e to
40496b2
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 11s |
+ Add Name() method to Image interface to encapsulate flattening
assertions:
- For imageImages, it returns the only present name (as it should be
flattened, otherwise it panics)
- For imageInspect, it returns the last name from the image
NamesHistory (according to the implementation, the latest name is on
index 0 -> see
https://github.com/containers/storage/blob/main/images.go)
+ Remove unnecessary setNames() private method
+ Move image name assertions from cmd into podman package
This addresses review feedback from @debarshiray in PR containers#1724.
Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
In reaction to the conversation in PR containers#1707, I made suggested changes to the implementation in terms of how Image information, received from Podman, is represented and treated in the Toolbx code. I used the same procedure as in the case of representing Containers: - Commit e611969 - Commit ec7eb59 In short, the JSON from 'podman inspect --type image' and 'podman images' are different, so logically, there should be different implementations of the JSON.Unmarshaler interface [1] for them as well. The new Image interface provides access to the values parsed from the JSONs and two different concrete types, which are implemented separately to handle the differences in the JSONs. GetImages() now returns an Images iterator-like structure that handles image flattening and sorting internally. InspectImage() returns an Image interface instead of map[string]interface{}, and the IsToolboxImage() function was replaced with the IsToolbx() method on the Image interface. Tested were results of Podman starting on version 1.1.2, which should be sufficient since the minimum required Podman version is 1.6.4 (see commit 8e80dd5). Covered are structures representing podman commands 'podman inspect --type image' and 'podman images'. [1] https://pkg.go.dev/encoding/json#Unmarshaler containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
+ Add Name() method to Image interface to encapsulate flattening
assertions:
- For imageImages, it returns the only present name (as it should be
flattened, otherwise it panics)
- For imageInspect, it returns the last name from the image
NamesHistory (according to the implementation, the latest name is on
index 0 -> see
https://github.com/containers/storage/blob/main/images.go)
+ Remove unnecessary setNames() private method
+ Move image name assertions from cmd into podman package
This addresses review feedback from @debarshiray in PR containers#1724.
Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
DaliborKr
force-pushed
the
image_interface
branch
from
0ab2f12 to
d197ff4
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 12s |
debarshiray
left a comment
debarshiray
left a comment
There was a problem hiding this comment.
I finally finished going through all the test cases for parsing the podman images --format json output. The tests have revealed some mistakes elsewhere in the code, and I have one or two minor comments and questions about the changes here in this PR.
|
|
||
| // Until Podman 2.0.x the field 'Created' held a human-readable string in | ||
| // format "5 minutes ago". Since Podman 2.1 the field holds an integer with | ||
| // Unix time. Go interprets numbers in JSON as float64. |
There was a problem hiding this comment.
On the surface, this comment about the field Created holding a human-readable string like 5 minutes ago until Podman 2.0.x doesn't match the reality exposed by the tests. :)
Speaking from memory, I think there are three cases. Older than Podman 2.0, the Podman 2.0.x releases, and Podman 2.1 onwards. We have to check this because I am not entirely sure.
Anyway, it's not the fault of this PR. So there's no need to block on fixing this. It's a note to ourselves to do something about this dissonance. :)
src/pkg/podman/imageImages_test.go
Outdated
| " \"registry.fedoraproject.org/f29/fedora-toolbox:29\"" + | ||
| " ]," + | ||
| " \"digest\": \"sha256:f324a546a5e894af041eea47f8f2392bf2a9e2d88ee77199b25a129174b7a0e1\"," + | ||
| " \"created\": \"2019-11-06T11:36:10.586442Z\"," + |
There was a problem hiding this comment.
The created field in Podman older than 2.0.x holds an ISO 8601 formatted string, not something like 5 minutes ago.
src/pkg/podman/imageImages_test.go
Outdated
| " \"sha256:1d1077ce12b6d45990709ab81543884838d71a3b2014d023b82fd465a3ce4e23\"" + | ||
| " ]," + | ||
| " \"Created\": 1619352159," + | ||
| " \"CreatedAt\": \"2021-04-25T12:02:39Z\"" + |
There was a problem hiding this comment.
Then, Created started holding a UNIX timestamp, and the ISO 8601 formatted string moved to CreatedAt.
src/pkg/podman/imageImages_test.go
Outdated
| " \"RepoTags\": null," + | ||
| " \"RepoDigests\": [" + | ||
| " \"registry.fedoraproject.org/fedora-toolbox@sha256:0a51adc6bab55d49ff00da8aaad81ca1f02315511ed23d55ee5bbbe1a976a663\"," + | ||
| " \"registry.fedoraproject.org/fedora-toolbox@sha256:8599f0c0d421c0dc01c4b7fb1c07b2780c0ab1931d0f22dd7b6da3b93ff6b77b\"" + |
There was a problem hiding this comment.
While playing with this, I learnt that the RepoDigest entries are duplicated if the second name is something like localhost/fedora-toolbox:41, but not if it's registry.fedoraproject.org/fedora-toolbox:41-test like in this test. I didn't expect that. :)
src/pkg/podman/imageImages_test.go
Outdated
| assert.Equal(t, expect.isToolbx, image.IsToolbx()) | ||
| assert.Equal(t, expect.labels, image.Labels()) | ||
| assert.Equal(t, expect.names, image.Names()) | ||
| assert.Equal(t, expect.repoTags, image.RepoTags()) |
There was a problem hiding this comment.
I wonder if there's an easy way to test the Created() method. It can be tricky because the relative time difference between the timestamp in the JSON and when the tests are run will keep increasing. So, 5 minutes ago will become 5 days ago, etc.
I think we hit the same problem with tests for containerInspect and that's why it's not tested there either. We can maybe simplify things a bit by using the same timestamp in the JSON for all the test cases.
It's not a big deal. Just a thought. I didn't investigate this much. It's not a blocker for this PR.
| expects: []expect{ | ||
| { | ||
| id: "c49513deb6160607504d2c9abf9523e81c02f69ea479fd07572a7a32b50beab8", | ||
| isToolbx: false, |
There was a problem hiding this comment.
This made me realize that our claim of supporting Podman 1.6.4 is invalid. :)
Due to commit 2369da5d31830e5c, Toolbx depends on the podman images JSON containing the labels, and this test case shows that they are not there with Podman 1.8.0. :D
Anyway, it's not the fault of this PR. So there's no need to block on fixing this. It's a note to ourselves to do something about this dissonance. :)
Fallout from 6aab0a6 and e772207 containers#1724
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. [1] https://pkg.go.dev/encoding/json#Unmarshaler containers#1724
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779
|
To keep things moving, I have split the changes introducing the |
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779
debarshiray
force-pushed
the
image_interface
branch
from
d197ff4 to
2af9ad1
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 20s |
A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779
Unmarshal the JSON from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [1]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [2], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [3]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. [1] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [2] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [3] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>
debarshiray
force-pushed
the
image_interface
branch
from
2af9ad1 to
62ba0aa
Compare
debarshiray
left a comment
debarshiray
left a comment
There was a problem hiding this comment.
Now onto the, hopefully, final round involving the imageInspect concrete type. :)
| type imageInspect struct { | ||
| created string | ||
| entrypoint []string | ||
| envVars []string |
There was a problem hiding this comment.
It looks like entrypoint and envVars are not needed to parse the output of podman inspect --type image into an Image implementation. I suppose you needed them for the changes in #1707 to address #1622 , right? If so, it might be better to move these parts to the pull request that needs them.
More importantly, don't we need to add methods to the Image interface to cover these?
|
Build succeeded. ✔️ unit-test SUCCESS in 2m 16s |
2 participants
Introduces an Image interface based on the conversation in PR #1707.
Similar to how container information is handled (introduced in commits e611969 and ec7eb59), this PR abstracts the representation of an image. This is necessary because
podman inspect --type imageandpodman imagesreturn different JSON structures. The Image interface provides a unified way to access image data, with two distinct implementations to handle the different JSON formats.Updates related functions:
Adds unit tests: This PR includes unit tests for the new Image interface implementation, covering the output of both
podman inspect --type imageandpodman images.