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