[sdk] openstacksdk 0.99.0 breaks swift object header setting

Artem Goncharov artem.goncharov at gmail.com
Thu Jun 2 10:44:36 UTC 2022


Hey,

https://review.opendev.org/c/openstack/openstacksdk/+/844414 <https://review.opendev.org/c/openstack/openstacksdk/+/844414> should address the issue. For R1 of SDK we want to ensure all interfaces of SDK use same code branch and not 3 different like it was before. So with the latest changes we now rely here on the regular mechanism that actually watches how to handle each known parameter. All of the arbitrary parameters in Swift are managed as container/object metadata and should get X-Container-Meta- or X-Object-Meta- prefixes in order to be considered and returned back by manila Swift. This is sadly not the case for Rax as you rightfully mention.

So for now I have added header required by Rax into “known” exceptions and added explicit unit test for that. Would be cool to find way how I could test that really in Rax to ensure particular Zuul use case will work. 

Generally we would need to think whether SDK should continue “tell user he is wrong before reaching out to the server” approach or to switch to the “believe the user and let server reject” approach generally. This here is precisely one of those cases. Alternatively we would need to widen our concept of vendors and move all of the specific Rax logic over there. We surely have lot of OpenStack based clouds, which do not explicitly implement everything in the compatible way. So in order to make SDK/CLI working with all of them we either drop most of the validation logic in SDK or really start implementing cloud specific overrides as part of “extensions”.

Artem

> On 1. Jun 2022, at 19:55, Clark Boylan <cboylan at sapwetik.org> wrote:
> 
> Hello,
> 
> Last week the OpenDev team upgraded Zuul which deployed zuul-executors with openstacksdk==0.99.0 installed. After this, test job logs uploaded to the rackspace swift location were no longer viewable in the Zuul dashboard. The reason for this is these objects did not have properly configured CORS headers any longer. The objects uploaded to OVH appear to have been fine (potentially because the headers are not required for OVH).
> 
> Today we downgraded the version of openstacksdk on the zuul-executors to 0.61.0 and the rackspace uploaded job log objects have functional CORS headers again. For this reason we're fairly confident that something about the 0.99.0 release is impacting the setting of these headers.
> 
> The code that does these uploads with openstacksdk can be found here [0]. I suspect that the problem is going to be related to this header set on line 227 [1]. In particular that appears to be rackspace specific and this issue is rackspace specific under 0.99.0. However, I wasn't able to find anything in openstacksdk that would have a problem with this. Does anyone else have ideas? I'm somewhat concerned that this represents a class of data loss (metadata is going missing) for swift object uploads.
> 
> Additionally, we rely on setting the x-delete-after header to timeout, expire, and prune our logs in swift [2]. If there is a general problem with 0.99.0 setting headers on objects it is possible that all of the objects we created using 0.99.0 do not have this metadata set and will leak in their swift containers.
> 
> [0] https://opendev.org/zuul/zuul-jobs/src/commit/e69d879caecb454c529a7d757b80ae49c3caa105/roles/upload-logs-base/library/zuul_swift_upload.py
> [1] https://opendev.org/zuul/zuul-jobs/src/commit/e69d879caecb454c529a7d757b80ae49c3caa105/roles/upload-logs-base/library/zuul_swift_upload.py#L226-L227
> [2] https://opendev.org/zuul/zuul-jobs/src/commit/e69d879caecb454c529a7d757b80ae49c3caa105/roles/upload-logs-base/library/zuul_swift_upload.py#L224
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220602/41e65052/attachment.htm>


More information about the openstack-discuss mailing list