REST API RESOURCE LIMITS

[mageweaver]

Issue Description

Using the REST API for PODMAN v5.1.0
curl --header "Content-Type: application/json" --unix-socket /run/user/1000/podman/podman.sock --request POST --data '{"name":"test5", "resource_limits":{"cpu_period": 100000,"cpu_quota": 100000}}' http://d/v5.0.0/libpod/pods/create
{"Id":"a3af98b6bcd0d121d62f3c46601b8c5fd8adde9833626dc029c51b0d619b4f66"}

Unfortunately unlike when I use the CLI, the cpu_period and the cpu_quota are not listed when the pod is inspected. The same occurs for memory related settings. This is a major bug or I am missing something. I have also tried quoting the values and using smaller ones, there is not error everytime and the pod is created but with no values set for these. Again, if I use same values with the cli - it is a different story. When you inspect the cli pod creation with these same parameters it shows up. I don't believe the REST API supports typical CGROUP settings. I also tried this on version 4.4.1 of podman on another linux variant and had the same issue.

Steps to reproduce the issue

Steps to reproduce the issue

1. Tried the same values and attempts on the CLI vs REST API and compared results of inspect pod
2. Tried the same values and attempts on another Linux Variant with an earlier version of PODMAN and had same results

Describe the results you received

There seems to be no support in REST API for CPU and MEMORY settings on POD Creation while the CLI fully supports it.

Describe the results you expected

The REST API accepts the parameters as they respect the SPECGEN - I fully expected support for CPU and Memory pinning in the REST API for POD Creation

podman info output

[
     {
          "Id": "a3af98b6bcd0d121d62f3c46601b8c5fd8adde9833626dc029c51b0d619b4f66",
          "Name": "test5",
          "Created": "2024-04-13T01:01:43.126086363-04:00",
          "ExitPolicy": "continue",
          "State": "Created",
          "Hostname": "",
          "CreateCgroup": true,
          "CgroupParent": "/libpod_parent",
          "CgroupPath": "/libpod_parent/a3af98b6bcd0d121d62f3c46601b8c5fd8adde9833626dc029c51b0d619b4f66",
          "CreateInfra": true,
          "InfraContainerID": "72d5477d2c6ddef341527051d13931be464f40f58363d8634a7296119d254121",
          "InfraConfig": {
               "PortBindings": {},
               "HostNetwork": false,
               "StaticIP": "",
               "StaticMAC": "",
               "NoManageResolvConf": false,
               "DNSServer": null,
               "DNSSearch": null,
               "DNSOption": null,
               "NoManageHosts": false,
               "HostAdd": null,
               "Networks": null,
               "NetworkOptions": null,
               "pid_ns": "private",
               "userns": "host",
               "uts_ns": "private"
          },
          "SharedNamespaces": [
               "ipc",
               "net",
               "uts"
          ],
          "NumContainers": 1,
          "Containers": [
               {
                    "Id": "72d5477d2c6ddef341527051d13931be464f40f58363d8634a7296119d254121",
                    "Name": "a3af98b6bcd0-infra",
                    "State": "created"
               }
          ],
          "LockNumber": 0
     }
]

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Initial test on PODMAN 5.1.0 built from source on Ubuntu 22.04 LTS
Re-ran test on Ubuntu 22.04 with Podman package binary 3.4
Re-ran test on Fedora 36 with Podman package binary 4.4.1

Additional information

This behavior consistently happens

[mageweaver]

Ok - hunted this down - its a user error not a bug, there needs to be better documentation on the json spec. I basically had to create pods with the CLI and run generator with spec to see that i had the settings wrong and then had to search the internet on setting up the confs for cpuset... This is really a documentaiton issue

[baude]

mind doing a doc fix (fwiw, we have had a problem with our API docs lately not showing things correctly. A fix for that is being merged as I type this)