Podman API takes a SpecGenerator rather than CreateOptions, why?

[cdoern]

@containers/podman-maintainers I have been grappling with this for a while when implementing different pod create options...

The last domino in redesigning the infra container for easier implementation of pod creation options seems to be podman-remote as well as the API itself.

Currently in cmd/podman/pods/create.go, the infra container's options are formed from the command line and turned into a spec generator in that file. If the user is executing the podman pod create command via podman-remote, all of this work is basically thrown out.

This is because pkg/api/handlers/libpod/pods.go PodCreate takes a PodSpecGenerator as the request input, decoding directly into one of these structs. This causes the process of creating the pod to be duplicated, filling out the specgen again, and manually inputting the infra information since we do not have flags to place the create options.

This also causes unecessary fields to be added to the PodSpecGenerator that are really container SpecGenerator fields that need to be carried over for the remote API...

A good example I am working on now is SysCtls:

1. cmd/podman/pods/create.go populates the create option for sysct of type []stringl and gives it to the infra container's spec via FillOutSpecGen, validating it as a []string map.

Step 1 is all we need for a regular podman and podman-remote approach technically, steps 2 and 3 are only done because of the requirements of the API

2. the original ContainerCreateOption of type []string is put back into the PodCreateOptions and then re validated and put into the PodSpecgen as a []string map for the remote path.

3. pkg/api/handlers/libpod/pods.go then receives the PodSpecgen, ignoring infra's if it is already filled out, and recreates infra's SpecGenerator manually and by marshaling/unmarshaling things that happen to match

This is a redundant process for every case except for the direct API usage.

I would like to have a conversation about either:

1. using create options rather than a Specgen for the API input

2. making a less roundabout way of populating a ContainerCreateOptions struct so infra is formed properly. Maybe there is a way to somehow map a PodSpecgen back to ContainerCreateOptions?

Looking at cmd/podman and pkg/api shows some commonality that should somehow be joined, and aren't the create options more "user friendly" instead of exposing the Specgen to the API users?