Skip to content

Conversation

@mayuka-c
Copy link
Member

@mayuka-c mayuka-c commented Jan 13, 2026

  • Instead of returning concrete podman types from runtime methods, use the custom defined types so that the runtime methods can return this custom defined types inorder to achieve dependency inversion.
  • This will allow to extend the runtime pkg so that its interface methods can easily be implemented by others (Eg: k8s) other than podman.
  • Will be taking up replacing pod and container Inspect types in subsequent PRs as it requires lot of changes.

Signed-off-by: mayuka-c <Mayuka.C@ibm.com>
Signed-off-by: mayuka-c <Mayuka.C@ibm.com>
Copy link
Member

@mkumatag mkumatag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure we use the existing types instead of creating new ones

Status string
}

type CreatePodResp struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please avoid adding these array kind of structure variables.

RepoDigests []string
}

type PodInspect struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try to use the already existing Pod type

InfraContainerID string
}

type ContainerInspect struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let us see if we can use existing Container type

@mayuka-c
Copy link
Member Author

mayuka-c commented Jan 14, 2026

Make sure we use the existing types instead of creating new ones

Sure I was in a dilemma myself too :)

The main reason I added is because lets say as part of Create Pod Response, we might not be getting all the fields which we have defined in the Pod type. So I thought to define a new type so that the caller while consuming knows that these are the fields populated as part of a method response. With this it will be easier to know at the compile time itself instead of getting default values for those whose fields are not set and we consuming accidentally these fields.

@mkumatag Any suggestions?

@mkumatag
Copy link
Member

The main reason I added is because lets say as part of Create Pod Response, we might not be getting all the fields which we have defined in the Pod type. So I thought to define a new type so that the caller while consuming knows that these are the fields populated as part of a method response. With this it will be easier to know at the compile time itself instead of getting default values for those whose fields are not set and we consuming accidentally these fields.

I feel like it's a maintenance headache. All these functions return almost the same thing, except for which fields are optional or mandatory. At the call site, we should just use strict checks if we are expecting specific fields, rather than returning a different type.

Signed-off-by: mayuka-c <Mayuka.C@ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants