fadam-csgroup

I just tested it against new high performance OVH endpoint https://s3.sbg.perf.cloud.ovh.net, without success. Bellow are the logs of lakefs container: ``` {"action":"create_repo","file":"build/pkg/api/controller.go:3483","func":"pkg/api.(*Controller).LogAction","host":"127.0.0.1:8000","level":"debug","message_type":"action","method":"POST","msg":"performing API action","path":"/api/v1/repositories","request_id":"3727e6b2-de89-4082-80f4-24ca4a5189a9","service":"api_gateway","service_name":"rest_api","time":"2022-09-16T13:48:16Z"} {"file":"build/pkg/logging/aws.go:8","func":"pkg/logging.(*AWSAdapter).Log","level":"debug","msg":"DEBUG: Request s3/GetObject Details:\n---[ REQUEST POST-SIGN...

Hi @arielshaqed In fact, I ordered the high performance OVH endpoint after reading your https://github.com/treeverse/lakeFS/issues/2471#issuecomment-1112956193. Before this, the error was the original "aws-chunked" one. To me, the 404 is expected:...

Using `quay.io/sustainable_computing_io/kepler:release-0.5` on Fedora Core 33 with cGroup v1 (`systemd.unified_cgroup_hierarchy=0` in grub) does not work as expected: See bellow an extract of the logs (verbose=5) where every container has the...

This Kubernetes environment has been deployed using Openstack Magnum on VMs.

@marceloamaral Yes, the command give me lots of PIDs: ``` $ kubectl -n monitoring exec -it ds/kepler -- ls /proc -1 | grep -E '^[0-9]+$' | wc -l 553 ```

@marceloamaral Here are the logs: https://pastebin.com/2i7RX0Y8

@rootfs It seems that Memory accounting in enable but CPU is not: ``` # systemctl show kubelet |grep -i accounting CPUAccounting=no IOAccounting=no BlockIOAccounting=no MemoryAccounting=yes TasksAccounting=yes IPAccounting=no ```