containerz: UpdateContainerRequest contains duplicate params?

[LimeHat]

UpdateContainerRequest contains image_name and image_tag fields in the body of the request: https://github.com/openconfig/gnoi/blob/1cc12cd257e86908cc188a99d81cf34d76da0b45/containerz/containerz.proto#L567-L581

But the same parameters are included in the StartContainerRequest message, which is also part of the UpdateContainerRequest message https://github.com/openconfig/gnoi/blob/1cc12cd257e86908cc188a99d81cf34d76da0b45/containerz/containerz.proto#L391-L396

Could you please clarify how is this supposed to be used? Can we deprecate one of the sets (name+tag)?

@alshabib @robshakir

[alshabib]

They are both useful:

• The StartContainer one indicates to Containerz which image:tag to start a container on
• The UpdateContainer one indicates what image:tag to update the image to.

Does this help clarify?

[LimeHat]

Sorry, I'm not following.. IMO in either case it will be translated into a single docker run cmd (or equivalent). Can you provide an example how/where a second tag can be used with Docker syntax?

[LimeHat]

Just to clarify further, I don't question the standalone StartContainer RPC. All I'm saying is that in UpdateContainerRequest an image:tag combination can be included twice (because the update request already includes the StartContainerRequest, and then adds more fields.. which appear to be redundant)

[alshabib]

Oh I see - I think image:tag in update container is the one to honour. The start container in the update container request is just to pass start parameters to containerz.

[LimeHat]

Ok. Just to confirm, would it be fair to say that

• image_name and image_tag at the top level of UpdateContainerRequest are mandatory.
• we can silently ignore image_name and tag in the embedded StartContainerRequest when executing UpdateContainer RPC?

[alshabib]

Yes that is correct