LXD API is not creating operation

LXD
,
1

Hello Everyone,
For a project I’m currently working on I want to make a request to create a container from a remote image server. Other operations work fine even with a offical image server. But somehow it doesn’t with my own remote server. This is my curl and the corresponding information:

curl -s -k --cert /home/linuxluca/snap/lxd/common/config/client.crt --key /home/linuxluca/snap/lxd/common/config/client.key https://localhost:8443/1.0/containers -X POST -d ‘{“name”: “testRemote”,“source”: {“type”: “image”, “protocol”: “simplestreams”, “server”: “https://192.168.178.30:8443”, “alias”: “amdImage”}}’ | jq .

{
“type”: “async”,
“status”: “Operation created”,
“status_code”: 100,
“operation”: “/1.0/operations/86cbbfc3-8817-42bf-a560-8a813f1e1d4b”,
“error_code”: 0,
“error”: “”,
“metadata”: {
“id”: “86cbbfc3-8817-42bf-a560-8a813f1e1d4b”,
“class”: “task”,
“description”: “Creating instance”,
“created_at”: “2022-11-21T15:30:57.817928941+01:00”,
“updated_at”: “2022-11-21T15:30:57.817928941+01:00”,
“status”: “Running”,
“status_code”: 103,
“resources”: {
“containers”: [
“/1.0/containers/testRemote”
],
“instances”: [
“/1.0/instances/testRemote”
]
},
“metadata”: null,
“may_cancel”: false,
“err”: “”,
“location”: “none”
}
}

Everything seems fine here but if I check the operation all I get is this:

curl -s -k --cert /home/linuxluca/snap/lxd/common/config/client.crt --key /home/linuxluca/snap/lxd/common/config/client.key https://localhost:8443/1.0/operations/86cbbfc3-8817-42bf-a560-8a813f1e1d4b | jq .

{
“type”: “error”,
“status”: “”,
“status_code”: 0,
“operation”: “”,
“error_code”: 404,
“error”: “Operation not found”,
“metadata”: null
}

Can someone tell me what I’m doing wrong? When I’m just doing ‘lxc launch remote:amdImage testRemote’ it works but I need it to work with the API. Also I verified the connection and that the image is found as well.

Thank you.

2

Operations only hang around for 5s after they complete, so you have to be quick.

3

Thank you for your reply. I tried again and called 1.0/operations directly after and they show up under the tag failure, like below.

{
“type”: “sync”,
“status”: “Success”,
“status_code”: 200,
“operation”: “”,
“error_code”: 0,
“error”: “”,
“metadata”: {
“failure”: [
“/1.0/operations/31399c37-18f4-41b6-861b-b2f2920d53ce”,
“/1.0/operations/9ed5a763-3dc0-4af2-b5f7-a048c869f9fc”
],
“running”: [
“/1.0/operations/32ea3c7e-b13b-4c4a-ac31-b1c7ae130d35”
]
}
}

Can you tell me a way I can see what caused the failure? Is the curl command correct?

I added the --verbose flag to the command, thats the output:

  • Trying 127.0.0.1:8443…
  • Connected to localhost (127.0.0.1) port 8443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • TLSv1.0 (OUT), TLS header, Certificate Status (22):
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS header, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS header, Finished (20):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, Request CERT (13):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.2 (OUT), TLS header, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.3 (OUT), TLS handshake, Certificate (11):
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.3 (OUT), TLS handshake, CERT verify (15):
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: O=linuxcontainers.org; CN=root@linuxluca
  • start date: Nov 1 11:22:02 2022 GMT
  • expire date: Oct 29 11:22:02 2032 GMT
  • issuer: O=linuxcontainers.org; CN=root@linuxluca
  • SSL certificate verify result: self-signed certificate (18), continuing anyway.
  • Using HTTP2, server supports multiplexing
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • Using Stream ID: 1 (easy handle 0x5610d33b5e80)
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):

POST /1.0/containers HTTP/2
Host: localhost:8443
user-agent: curl/7.81.0
accept: /
content-length: 141
content-type: application/x-www-form-urlencoded

  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • We are completely uploaded and fine
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
  • TLSv1.2 (OUT), TLS header, Supplemental data (23):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    < HTTP/2 202
    < content-type: application/json
    < location: /1.0/operations/5e13a660-9987-4c60-b471-ea94ef04e031
    < content-length: 562
    < date: Mon, 21 Nov 2022 16:17:03 GMT
    <
  • TLSv1.2 (IN), TLS header, Supplemental data (23):
    {“type”:“async”,“status”:“Operation created”,“status_code”:100,“operation”:“/1.0/operations/5e13a660-9987-4c60-b471-ea94ef04e031”,“error_code”:0,“error”:“”,“metadata”:{“id”:“5e13a660-9987-4c60-b471-ea94ef04e031”,“class”:“task”,“description”:“Creating instance”,“created_at”:“2022-11-21T17:17:03.42970123+01:00”,“updated_at”:“2022-11-21T17:17:03.42970123+01:00”,“status”:“Running”,“status_code”:103,“resources”:{“containers”:[“/1.0/containers/testRemote”],“instances”:[“/1.0/instances/testRemote”]},“metadata”:null,“may_cancel”:false,“err”:“”,“location”:“none”}}
  • Connection #0 to host localhost left intact
4

If you request the failed operation, e.g /1.0/operations/31399c37-18f4-41b6-861b-b2f2920d53ce it should show the issue.

5

Seems I’m not fast enough to do that. I tried something else. Maybe that has something to do with it?

I just do simple import of a specific image over https. Thats the result:

lxc image import https://192.168.178.30:8443/1.0/images/d7670cdf62ab --alias tes1

Error: Head “https://192.168.178.30:8443/1.0/images/d7670cdf62ab”: x509: certificate is valid for 127.0.0.1, ::1, not 192.168.178.30

Could that be something why the curl command is failing?

6

Please can you post your reproducer script here so I can run it and see what the issue is.

7

I’m just trying to create a container on my host machine with an image on a private remote lxd server using a curl command. Not using any script, just the :
“curl -s -k --cert “certificate” --key “key” localhost -X POST -d {}”
I know I could just do a image copy but I’m trying to implement a JavaAPI (Jlxd) that is using curl commands.