Hi Gaëtan, Going back to your original question: have you tried to open downloaded with curl with a text editor? I am expecting that it is actually slightly bigger than the correct file downloaded with OSC, because it would include HTTP headers at the top. You should drop the `-i` option from your curl command line and try again: -i, --include (HTTP) Include the HTTP-header in the output. The HTTP-header includes things like server-name, date of the document, HTTP-version and more... Best wishes, Pierre Riteau (priteau) On Mon, 2 Mar 2020 at 15:21, <gaetan.trellu@incloudus.com> wrote:
Abhishek,
Thansk for your answer, I tried both CLIs (Train release) and the issue still the same.
Paste of the "curl" command: http://paste.openstack.org/show/790197/
Result of the "md5sum" on the file created by the "curl": $ md5sum /tmp/kernel.glance c3726de8e03158305453f328d85e9957 /tmp/kernel.glance
As Mark and Radoslaw, I'm quite surprised about OSC been deprecated. Do you have any release note about this?
Thanks for your help.
Gaëtan
curl -g -i -X GET http://10.0.0.11:9292/v2/images/de39fc9c-b943-47e3-82c4-bd6d577a9577/file -H "Content-Type: application/octet-stream" -H "User-Agent: python-glanceclient" -H "X-Auth-Token: $token" --output /tmp/kernel.glance -v Note: Unnecessary use of -X or --request, GET is already inferred. * Expire in 0 ms for 6 (transfer 0x557679b1de80) * Trying 10.0.0.11... * TCP_NODELAY set * Expire in 200 ms for 4 (transfer 0x557679b1de80) % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 10.0.0.11 (10.0.0.11) port 9292 (#0)
GET /v2/images/de39fc9c-b943-47e3-82c4-bd6d577a9577/file HTTP/1.1 Host: 10.0.0.11:9292 Accept: */* Content-Type: application/octet-stream User-Agent: python-glanceclient X-Auth-Token: gAAAAABeXRzKVS3uQIIv9t-wV7njIV-T9HIvcwFqcHNivrpyBlesDtgAj1kpWk59a20EJLUo8IeHpTdKgVFwhnAVvbSWHY-HQvxu5dwSFsK4A-7CzAOwdp3svSqxB-FdwWhsY_PElftMX4geA-y_YFZJamefZapiAv6g1gSm-BSv5GYQ0hj3yGY
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0< HTTP/1.1 200 OK < Content-Type: application/octet-stream < Content-Md5: 26c6d5c3d8ba9fd4bc4d1ee5959a827c < Content-Length: 5631728 < X-Openstack-Request-Id: req-e7ba2455-780f-48a8-b6a2-1c6741d0e368 < Date: Mon, 02 Mar 2020 15:03:53 GMT < { [32768 bytes data] 100 5499k 100 5499k 0 0 4269k 0 0:00:01 0:00:01 --:--:-- 4269k * Connection #0 to host 10.0.0.11 left intact
On 2020-03-02 04:54, Mark Goddard wrote:
On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane@redhat.com> wrote:
Hi Gaëtan,
Glance team doesn't recommend to use OSC anymore. I will recommend you to check the same behaviour using python-glanceclient.
That's not cool - everyone has switched to OSC. It's also the first time I've heard of it.
Thanks & Best Regards,
Abhishek Kekane
On Sat, Feb 29, 2020 at 3:54 AM Monty Taylor <mordred@inaugust.com> wrote:
On Feb 28, 2020, at 4:15 PM, gaetan.trellu@incloudus.com wrote:
Hey Monty,
If I download the image via the CLI, the checksum of the file matches the checksum from the image details. If I download the image via "curl", the "Content-Md5" header matches the image details but the file checksum doesn't.
The files have the same size, this is really weird.
WOW.
I still don’t know the issue - but my unfounded hunch is that the curl command is likely not doing something it should be. If OSC is producing a file that matches the image details, that seems like the right choice for now.
Seriously fascinating though.
Gaëtan
On 2020-02-28 17:00, Monty Taylor wrote:
> On Feb 28, 2020, at 2:29 PM, gaetan.trellu@incloudus.com wrote: > Hi guys, > Does anyone know why the md5 checksum is different between the "openstack image save" CLI and "curl" commands? > During the image creation a checksum is computed to check the image integrity, using the "openstack" CLI match the checksum generated but when "curl" is used by following the API documentation[1] the checksum change at every "download". > Any idea? That seems strange. I don’t know off the top of my head. I do know Artem has patches up to switch OSC to using SDK for image operations. https://review.opendev.org/#/c/699416/ That said, I’d still expect current OSC checksums to be solid. Perhaps there is some filtering/processing being done cloud-side in your glance? If you download the image to a file and run a checksum on it - does it match the checksum given by OSC on upload? Or the checksum given by glance API on download? > Thanks, > Gaëtan > [1] https://docs.openstack.org/api-ref/image/v2/index.html?expanded=download-bin...