[glance] Different checksum between CLI and curl
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? Thanks, Gaëtan [1] https://docs.openstack.org/api-ref/image/v2/index.html?expanded=download-bin...
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...
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. 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...
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...
Hi Gaëtan, Glance team doesn't recommend to use OSC anymore. I will recommend you to check the same behaviour using python-glanceclient. 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...
Hi Abhishek, Abhishek Kekane wrote:
Glance team doesn't recommend to use OSC anymore. I will recommend you to check the same behaviour using python-glanceclient.
Whoa, so OSC suddenly fell out of support? When did that happen? I thought OSC is the future, not the other way around... -yoctozepto
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...
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...
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...
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder. More generally I observed a disconection between the needs of a few teams (Cinder and Glance for sure) and OSC, with a real split on the community and no apparent interest in trying to bridge the gap, which is very sad. -- Luigi
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder. osc support microverions but not the auto negociation.
On Mon, 2020-03-02 at 16:25 +0100, Luigi Toscano wrote: the microverion support is fully integrated with the help text generageion and you can specify the desired microverion with --os-<project>-api-version=X option when using osc.
More generally I observed a disconection between the needs of a few teams (Cinder and Glance for sure) and OSC, with a real split on the community and no apparent interest in trying to bridge the gap, which is very sad.
i know that it was hoped that using the sdk in osc would allow osc to inherit the auto negotiation capability but even without that it does fully support micorverions it just does not have the same behavior as the legacy project clients. i actully tought there was a cross project goal/resolution to move all project to osc a few releases ago so if glance are considering deprection there osc support i think that is problematic and need a much stonger justification then automatic micorverions support. i know there has been an ongoing effort form multiple cycles to stop using the project clients in all documentaiton where its possibel to use osc instead so it realy feels like this would be a regression.
Hi, On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to. Dmitry
More generally I observed a disconection between the needs of a few teams (Cinder and Glance for sure) and OSC, with a real split on the community and no apparent interest in trying to bridge the gap, which is very sad.
-- Luigi
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in. i do agree that it would be nice to have support for version negociation where by you could do somehting like --os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text. with that said if adding --os-image-api-version=auto was enough to get the glance team to fully adopt osc then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
More generally I observed a disconection between the needs of a few teams (Cinder and Glance for sure) and OSC, with a real split on the community and no apparent interest in trying to bridge the gap, which is very sad.
-- Luigi
On Mon, Mar 2, 2020 at 5:37 PM Sean Mooney <smooney@redhat.com> wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in.
Right, and it's a hard requirement for the CLI to be remotely usable.
i do agree that it would be nice to have support for version negociation where by you could do somehting like --os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text.
The "auto" must be a default. This is what the users expect: the CLI just working. Defaulting to anything else does them a huge disservice (been there, done that).
with that said if adding --os-image-api-version=auto was enough to get the glance team to fully adopt osc then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
Yep. We could not wait for OSC to implement it because the CLI is borderline unusable without this negotiation in place. I don't recall what prevented us from updating OSC, but I think there was a reason, probably not entirely technical. Dmitry
More generally I observed a disconection between the needs of a few
teams
(Cinder and Glance for sure) and OSC, with a real split on the community and no apparent interest in trying to bridge the gap, which is very sad.
-- Luigi
On Mon, Mar 2, 2020, at 11:01 AM, Dmitry Tantsur wrote:
On Mon, Mar 2, 2020 at 5:37 PM Sean Mooney <smooney@redhat.com> wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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.
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in.
Right, and it's a hard requirement for the CLI to be remotely usable.
i do agree that it would be nice to have support for version negociation where by you could do somehting like --os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text.
The "auto" must be a default. This is what the users expect: the CLI just working. Defaulting to anything else does them a huge disservice (been there, done that).
As a user I strongly disagree. I don't want an API to magically start acting differently because the cloud side has upgraded. Those changes are opaque to me and I shouldn't need to know about them. Instead I should be able to opt into using new features when I know I need them. This is easily achieved by setting the desired microversion when you know you need it.
with that said if adding --os-image-api-version=auto was enough to get the glance team to fully adopt osc then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
Yep. We could not wait for OSC to implement it because the CLI is borderline unusable without this negotiation in place. I don't recall what prevented us from updating OSC, but I think there was a reason, probably not entirely technical.
Dmitry
On Mon, Mar 2, 2020 at 8:46 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Mar 2, 2020, at 11:01 AM, Dmitry Tantsur wrote:
On Mon, Mar 2, 2020 at 5:37 PM Sean Mooney <smooney@redhat.com> wrote:
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com>
wrote:
On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote:
On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <
> 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.
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
akekane@redhat.com> wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in.
Right, and it's a hard requirement for the CLI to be remotely usable.
i do agree that it would be nice to have support for version
negociation where by you could do somehting like
--os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text.
The "auto" must be a default. This is what the users expect: the CLI just working. Defaulting to anything else does them a huge disservice (been there, done that).
As a user I strongly disagree. I don't want an API to magically start acting differently because the cloud side has upgraded. Those changes are opaque to me and I shouldn't need to know about them. Instead I should be able to opt into using new features when I know I need them. This is easily achieved by setting the desired microversion when you know you need it.
We're talking about CLI, not API. I agree with you when it comes to calling code, but CLI must just work. This is how all CLI in the world work: you either get a behavior or you get a clear failure. It's the other way around: if you want to fix the feature set, and you know what you're doing, you can set a specific version in your environment. And, Clark, you and I are not mere users even if we use our CLI regularly. Draw the border here: a regular user is someone who doesn't know what a microversion even IS, to say nothing about a way to find the required microversion for a feature. These are the users I've dealt with and they have all been frustrated by using microversions explicitly. For a probably clearer explanation let me refer you to the API SIG specification that covers how to expose microversions: https://specs.openstack.org/openstack/api-sig/guidelines/sdk-exposing-microv... (see specifically about high-level SDKs). Dmitry
with that said if adding --os-image-api-version=auto was enough to
get the glance team to fully adopt osc
then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
Yep. We could not wait for OSC to implement it because the CLI is borderline unusable without this negotiation in place. I don't recall what prevented us from updating OSC, but I think there was a reason, probably not entirely technical.
Dmitry
Folks, this is the *wrong* topic to discuss it. PS (basking in offtop): Thanks, Dmitry, I was looking for such a doc for jslib. -yoctozepto wt., 3 mar 2020 o 14:38 Dmitry Tantsur <dtantsur@redhat.com> napisał(a):
On Mon, Mar 2, 2020 at 8:46 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Mar 2, 2020, at 11:01 AM, Dmitry Tantsur wrote:
On Mon, Mar 2, 2020 at 5:37 PM Sean Mooney <smooney@redhat.com> wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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. >
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in.
Right, and it's a hard requirement for the CLI to be remotely usable.
i do agree that it would be nice to have support for version negociation where by you could do somehting like --os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text.
The "auto" must be a default. This is what the users expect: the CLI just working. Defaulting to anything else does them a huge disservice (been there, done that).
As a user I strongly disagree. I don't want an API to magically start acting differently because the cloud side has upgraded. Those changes are opaque to me and I shouldn't need to know about them. Instead I should be able to opt into using new features when I know I need them. This is easily achieved by setting the desired microversion when you know you need it.
We're talking about CLI, not API. I agree with you when it comes to calling code, but CLI must just work. This is how all CLI in the world work: you either get a behavior or you get a clear failure. It's the other way around: if you want to fix the feature set, and you know what you're doing, you can set a specific version in your environment.
And, Clark, you and I are not mere users even if we use our CLI regularly. Draw the border here: a regular user is someone who doesn't know what a microversion even IS, to say nothing about a way to find the required microversion for a feature. These are the users I've dealt with and they have all been frustrated by using microversions explicitly.
For a probably clearer explanation let me refer you to the API SIG specification that covers how to expose microversions: https://specs.openstack.org/openstack/api-sig/guidelines/sdk-exposing-microv... (see specifically about high-level SDKs).
Dmitry
with that said if adding --os-image-api-version=auto was enough to get the glance team to fully adopt osc then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
Yep. We could not wait for OSC to implement it because the CLI is borderline unusable without this negotiation in place. I don't recall what prevented us from updating OSC, but I think there was a reason, probably not entirely technical.
Dmitry
On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com <mailto:ltoscano@redhat.com>> wrote: On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote:
On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane@redhat.com <mailto: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.
From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers. There has been great progress with Manila to get shares included (https://review.opendev.org/#/c/642222/26/ <https://review.opendev.org/#/c/642222/26/>) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax. We had hoped for a project goal to get everyone aligned on OSC but there was not consensus on this, I’d still encourage it to simplify the experience for OpenStack cloud consumers. Tim
Folks, sorry to interrupt but I think we have diverged a bit too much from the subject. Only last Gaetan message is on topic here. Please switch to new subject to discuss OSC future. -yoctozepto pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell@cern.ch> napisał(a):
On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi,
On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote:
On Monday, 2 March 2020 10:54:03 CET 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.
From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers.
There has been great progress with Manila to get shares included (https://review.opendev.org/#/c/642222/26/) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax.
We had hoped for a project goal to get everyone aligned on OSC but there was not consensus on this, I’d still encourage it to simplify the experience for OpenStack cloud consumers.
Tim
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... 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. <_< --Adam On Mon, Mar 2, 2020, 19:00 Mark Goddard <mark@stackhpc.com> 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>
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
If I download the image via "curl", the "Content-Md5" header matches
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
wrote: the checksum from the image details. the image details but the file checksum doesn't. -
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...
On Mar 2, 2020, at 9:27 AM, Adam Harwell <flux.adam@gmail.com> wrote:
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...
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. <_
I fully agree. Users should not use python-glanceclient, they should use OSC. If there are bugs in OSC, we will fix them.
--Adam
On Mon, Mar 2, 2020, 19:00 Mark Goddard <mark@stackhpc.com> 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...
participants (12)
-
Abhishek Kekane
-
Adam Harwell
-
Clark Boylan
-
Dmitry Tantsur
-
gaetan.trellu＠incloudus.com
-
Luigi Toscano
-
Mark Goddard
-
Monty Taylor
-
Pierre Riteau
-
Radosław Piliszek
-
Sean Mooney
-
Tim Bell