https://docs.docker.com/edge/engine/reference/commandline/manifest/
mostly for multi-arch images, but nothing is stopping this from being a way to map arbitrary mime-type objects to be pushing as opaque blobs to the registry as well and be included in the signed image.
Is this a BUG REPORT or FEATURE REQUEST?:
Uncomment only one, leave it on its own line:
/kind bug
/kind feature
Description
Steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
(paste your output here)
Output of podman info:
(paste your output here)
Additional environment details (AWS, VirtualBox, physical, etc.):
Does containers/image have support for this yet?
@mtrmac indicated that it did, I believe.
c/image does not really support arbitrary opaque blobs, it recognizes layers and config. Adding opaque blobs is plausible, if needed.
As for manifest lists, right now they are only read; writing and converting them is WIP in https://github.com/containers/image/pull/400 . Thec/image/manifest.List abstraction added in that PR could be easily extended for other read or edit operations.
@umohnani8 Could you take a look at this?
@mtrmac Is this something you could add to podman?
Bumping this for visibility. Need the equivalent of _docker manifest_ https://docs.docker.com/edge/engine/reference/commandline/manifest/
... for ? help us understand and prioritize the use case
My company's internal tooling builds multiarch images and then makes them available through our registry to customers. Relying on _docker_ commands is not ideal and our tooling is moving away to only use podman/skopeo/buildah.
@mtrmac PTAL
@mtrmac Any comment? @vbatts Is this still something you want?
@mtrmac Any comment?
Not really; we do need _something_ to create multi-arch images, but I obviously haven’t been working on it yet.
this would be not only for multi-arch. The use-case here is for additional metadata (e.g. a SWID manifest or gomtree output) to be attached to the image when pushed.
This would be very useful for us in building Red Hat CoreOS; see https://github.com/openshift/origin/pull/21998#issuecomment-461943604
@vrothberg @mtrmac Lots of interest in this. Need to bump up the Importance.
:+1:
On Fri, Mar 8, 2019 at 11:28 AM Daniel J Walsh notifications@github.com
wrote:
@vrothberg https://github.com/vrothberg @mtrmac
https://github.com/mtrmac Lots of interest in this. Need to bump up the
Importance.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/713#issuecomment-470989319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6Yl2RCO-5agqsAZvt5NCzHD_8vCOks5vUo-1gaJpZM4Tv38e
.
Progress seems to have stalled on this.
Need to bump up the Importance.
Something we can check maybe next sprint? As long as more things are added to the todo, it will be tough to start working on it. In any case, we need https://github.com/containers/image/pull/608 before.
Maybe having a look into https://github.com/estesp/manifest-tool could help?
For now someone can use it directly, e.g. in combination with buildah or podman.
If I remember correctly, that project was started before docker got the manifest command, but it works perfectly find also without docker, I use that on a regular basis.
If only we could convince @estesp to contribute to libpod. :^)
@mtrmac @vbatts @rhatdan this would also be useful to verify images in the Red Hat registry. For example, the other day, somebody told me there is no UBI for ARM. It's hard to verify if the right multi-arch images were pushed without this sub-command in podman. Also, it could be useful for pushing other artifacts into the registry, per our recent discussions.
https://medium.com/@mauridb/docker-multi-architecture-images-365a44c26be6
This came up in a meeting today, and should move up the priority list to at least get better support in contianers/image and containers/storage.
I believe @nalind is also working on this?
This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.
@nalind Added support for Buildah, need someone to copy that support into Podman.
@nalind @rhatdan you are working on this? If not, I want to work on this?
@raukadah Go for it.
Friendly ping. Any updates on this?
@vrothberg Sorry the late reply, I have started working on that, I will get the PR up by this week.
@raukadah Any progress?
/cc @zvonkok @sjug
@rhatdan I did not made any progress, got busy with other works, Please take over this issue. Thanks!
Just a thought: Would it be a viable workaround to _somehow_ detect the manifest command in the https://github.com/containers/libpod/blob/master/docker wrapper script and run buildah instead of podman?
Happy to share that podman manifest exists. Look forward to Podman v2 :birthday:
Most helpful comment
Happy to share that
podman manifestexists. Look forward to Podman v2 :birthday: