<div dir="auto">I've heard this from members of the glance team for the past few (maybe 3?) summits at least, and every time I try to correct them, but it feels like talking to a brick wall. OSC is the future direction, it should be supported, and there's not even any ambiguity that I'm aware of, other than some strange refusal to accept reality on behalf of a few people...<div dir="auto"><br><div dir="auto">Yes, my tone here is definitely a little aggressive, but this has been an ongoing frustration of mine as I've been hearing this for a while and it's actively harmful and misleading, so I won't apologize for it. Some folks need to wake up. <_<</div><div dir="auto"><br></div><div dir="auto"> --Adam</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020, 19:00 Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <<a href="mailto:akekane@redhat.com" target="_blank" rel="noreferrer">akekane@redhat.com</a>> 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 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 <<a href="mailto:mordred@inaugust.com" target="_blank" rel="noreferrer">mordred@inaugust.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> > On Feb 28, 2020, at 4:15 PM, <a href="mailto:gaetan.trellu@incloudus.com" target="_blank" rel="noreferrer">gaetan.trellu@incloudus.com</a> 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 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.<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, <a href="mailto:gaetan.trellu@incloudus.com" target="_blank" rel="noreferrer">gaetan.trellu@incloudus.com</a> 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>
>> >> <a href="https://review.opendev.org/#/c/699416/" rel="noreferrer noreferrer" target="_blank">https://review.opendev.org/#/c/699416/</a><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] <a href="https://docs.openstack.org/api-ref/image/v2/index.html?expanded=download-binary-image-data-detail#download-binary-image-data" rel="noreferrer noreferrer" target="_blank">https://docs.openstack.org/api-ref/image/v2/index.html?expanded=download-binary-image-data-detail#download-binary-image-data</a><br>
>> ><br>
>><br>
>><br>
<br>
</blockquote></div>