--no-trunc options is needed for Podman events

[PavelSosin-320]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature
Description
--no-trunc options is needed for Podman events command to avoid Pod state monitoring complexity

##8930

Podman events command always emits the long object ID unlike other Podman commands like Podman pod ls, It lacs --no-trunc option to request either short or long ID in the event data.
When using Podman Pod create, ls without --no-trunc option and then /stop, start commands The Pod id in the event data never matches the ID used in the command never matches the long ID in the event data.
In the interactive mode, it creates the impression that pod and its container status are changed in the chaotic order and never match the podman pod ls command results. The default ID format in the Podman ls commands is short ID. The default Podman pod events ID format is long ID.
It creates redundant complexity in programmatic interface implementation because Event's observer has to keep ShortID - Long ID mapping at the client-side and passes --no-trunc option in the right context.

The Podman events --no-trunc option with the default value false will allow a more simple way to match action commands parameters, list commands parameters and Events stream data.

Steps to reproduce the issue:

1. Start event listening Podman events type=pod
2. Create a single container pod using --pod new: option podname
3. List pods using podman pod ls without --no-trunc to get short ID
4. Stop pod using short ID
5. Start pod using short ID
6. List pods again
7. List containers and their states running in the Pod.

Describe the results you received:
Stream of events containing long pod ID, "image", (???)
The pod is got from pod ls and used in the start / stop commands never appears.
An arbitrary number of events of unknown objects state changes.

Describe the results you expected:
I would like to select short / long ID format in the event data using --no-trunc option

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)

Output of podman info --debug:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman):

(paste your output here)

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes/No

Additional environment details (AWS, VirtualBox, physical, etc.):

[mheon]

I don't think we can make --no-trunc the default going forward - that would be a breaking change in established functionality. We can add an option to truncate IDs, but it would have to be enabled by a new flag and it cannot be the default.

[rhatdan]

Well add --no-trunk and default it to true.

[PavelSosin-320]

But other "display" command use --no-trunc options and truncate ID by default - see podman pod ls:
podman pod ls --help
List pods

Description:
List all pods on system including their names, ids and current state.

--no-trunc Do not truncate pod and container IDs

podman pod ls
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
1e666b1daefd devcontainerShare Created 8 hours ago 3 50caae355f77

but pod --no-trunc ls
Error: unknown flag: --no-trunc

But Podman list has --no-trunc flag and
podman pod list
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
1e666b1daefd devcontainerShare
podman pod list --no-trunc
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
1e666b1daefd9d5cc0bb7243ad9fbf39d6aeaad603ebd0cf361f70553fdd73c3 devcontainerShare

P.S.

Either Podman event or Podman Pod ls --no-trunc command has a bug or both.

Pod inspect shows podman pod inspect devcontainerShare
{
"Id": "1e666b1daefd9d5cc0bb7243ad9fbf39d6aeaad603ebd0cf361f70553fdd73c3",
"Name": "devcontainerShare",

CgroupPath": "machine.slice/machine-libpod_pod_1e666b1daefd9d5cc0bb7243ad9fbf39d6aeaad603ebd0cf361f70553fdd73c3.slice.

In the current situation Podman event command is not usable. There is no way to track Pod state neither by events no by list.

P.S. podman events --filter type=pod,name=devcontainerShare works but shows
1e666b1daefd9d5cc0bb7243ad9fbf39d6aeaad603ebd0cf361f70553fdd73c3 (image=, name=devcontainerShare)

[TomSweeneyRedHat]

can you add a better description for historical purposes and repush please?

[TomSweeneyRedHat]

@PavelSosin-320, see previous reply.

[TomSweeneyRedHat]

@PavelSosin-320 Ooops, never mind, I saw the PR in the title and thought it was a PR. I've edited the title of this issue.

[mheon]

@PavelSosin-320 I don't see how it's unusable - short and long IDs are completely interchangeable in all Podman commands. I am definitely not opposed to adding the ability for podman events to use short IDs, but doing so by default is a breaking change, and we can only make those when we absolutely have to to avoid breaking existing users.

[PavelSosin-320]

I tried to follow Podman objects lifecycle changes and status timing changes in the scenario where different containers have big differences in the creation and initialization times. It causes the sever service availability issue at the client-side. I suppose this is very common scenario. The client can't know when .the service provided by the pod is really available without observation of the event stream. To analyze the sequence and timing of the events resulting in service availability. I started the Event log piping And created a single container pod using --pod new:podname option Then I added additional containers to the already created pod, started, stoped and finally removed the pod. When I tried to follow pod and containers events I saw the random sequence of events containing Object ID's that occasionally matches the static picture created using Podman Pod list and Podman ps commands. This is an only visual aberration because long and short Pod IDs are used and displayed according to the context, not uniformly. If client-side observer will need to do the same job and resolve promises in the correct sequence it will need stable references of the Podman objects created and managed using the "action" commands.

…

On Tue, Jan 12, 2021 at 8:23 PM Matthew Heon ***@***.***> wrote: @PavelSosin-320 <https://github.com/PavelSosin-320> I don't see how it's unusable - short and long IDs are completely interchangeable in all Podman commands. I am definitely not opposed to adding the ability for podman events to use short IDs, but doing so by default is a breaking change, and we can only make those when we absolutely have to to avoid breaking existing users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM7YVKAOKPSNMSBLHI53Z5TSZSHRPANCNFSM4V7AFB3Q> .

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[baude]

@PavelSosin-320 any chance you can log onto libera #podman and we could discuss this? I want to make sure I have a better understanding of what you are asking for ... right now, I think you just want want the ctr id to be the short id by default and add a --no-trunc option that shows the full id. What I don't quite grasp is why ... this helps us write tests and implement the feature properly.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@baude @PavelSosin-320 Did this ever get resolved?

[vrothberg]

Since we're targeting 4.0, I think it's a good moment to make this change. Add a --no-trunc (default: false). I think it's unlikely to break existing users since the JSON output shouldn't truncate.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.