objects: partially revert e54703519#2160
Conversation
|
Build failed.
|
|
It looks like the failure is with the I'm thinking that |
8c9ee12 to
3cb4af3
Compare
|
Rebased and updated based on your suggestion @jtopjian |
|
Build failed.
|
|
@jtopjian it seems it couldn't find a host to test against? Just amending my commit to make it try again. |
Since this change you are no longer able to create objects with a / in them to create pseudo-folders. This behavior is relied upon by kOps documented as broken in kubernetes/kops#9933. fixes gophercloud#2159.
3cb4af3 to
ba5ba63
Compare
|
@cardoe Yes, there's been some hiccups with OpenLab since this PR first opened. If you can, please do a |
|
The failure happened when I was rebased atop of 9abac83 which is the current master commit. |
|
ah - well that's interesting! Let's hope it was a one-off issue. I'll dig into it if it fails again. Additionally, I'll look at testing this in a different environment and try to get this reviewed/merged quickly for you. |
|
Build failed.
|
|
The errors indicate that Devstack is still being created with Ubuntu Bionic, though there's no more mention of Bionic in the repo. I wonder if OpenLab/Zuul is not picking up the rebase somehow... I'll take a look at this shortly and try to run the tests in a separate environment. |
|
Thank you for the help with this. |
|
@cardoe I've added a commit with additional changes. I tested this on Vexxhost and ran into errors with the QueryEscape calls in general - I'm not sure how this is/was passing in OpenLab. I decided to just remove all QueryEscape calls from within Gophercloud. A dev/user is still able to escape the paths if they like by performing a Let me know your thoughts. I'm happy to merge this. |
|
Build failed.
|
Let's hope other dependent apps won't fail :\ |
|
There's a good possibility this will affect some applications - this is a breaking change. However, leaving this in is breaking functionality in other areas. From the behaviour I observed on Vexxhost, it's best to leave the URL encoding to the application so it can handle these situations in a more controlled and fine-grained manner. |
|
So I definitely feel that encoding the object name is wrong and bad. Playing with this further shows a number of valid objects that cannot be properly manipulated with GopherCloud. I'm less opinionated about the container name being escaped. I see with your changes I missed a spot in the bulk delete with the object name when it was in a loop which would have caused test failures with my change. |
|
OK, I'm going to merge this. I do understand that this is a breaking change. For anyone who reads this - I apologize. And if this behaviour is still not working correctly, please let me know and I'll do what I can to fix it. For anyone who was relying on URL encoded container or object names, you can still do this by encoding the name before passing the name to the object storage functions. |
Since the v1.19.0 release of kOps the OpenStack integration has been broken because gophercloud made a change to start escaping all path names for files stored in swift. kOps used a file with a slash in it which was getting escaped and then not handled correctly. This has been fixed in upstream gophercloud with gophercloud/gophercloud#2160 which was included in gophercloud v0.18.0. Bump to that version to fix kubernetes#9933.
Since the v1.19.0 release of kOps the OpenStack integration has been broken because gophercloud made a change to start escaping all path names for files stored in swift. kOps used a file with a slash in it which was getting escaped and then not handled correctly. This has been fixed in upstream gophercloud with gophercloud/gophercloud#2160 which was included in gophercloud v0.18.0. Bump is for issue kubernetes#9933.
Since the v1.19.0 release of kOps the OpenStack integration has been broken because gophercloud made a change to start escaping all path names for files stored in swift. kOps used a file with a slash in it which was getting escaped and then not handled correctly. This has been fixed in upstream gophercloud with gophercloud/gophercloud#2160 which was included in gophercloud v0.18.0. Bump is for issue kubernetes#9933.
Since the v1.19.0 release of kOps the OpenStack integration has been broken because gophercloud made a change to start escaping all path names for files stored in swift. kOps used a file with a slash in it which was getting escaped and then not handled correctly. This has been fixed in upstream gophercloud with gophercloud/gophercloud#2160 which was included in gophercloud v0.18.0. Bump is for issue kubernetes#9933.
Since the v1.19.0 release of kOps the OpenStack integration has been broken because gophercloud made a change to start escaping all path names for files stored in swift. kOps used a file with a slash in it which was getting escaped and then not handled correctly. This has been fixed in upstream gophercloud with gophercloud/gophercloud#2160 which was included in gophercloud v0.18.0. Bump is for issue kubernetes#9933. (cherry picked from commit 80da992)
Update the pin to gophercloud v0.18.0 so that we get a fix that came with gophercloud/gophercloud#2160. Also use a replacement for tencentcloud-sdk-go as they removed their tags and broke all downstream projects in the process (https://github.com/hashicorp/terraform#29021). This is needed in order to run `go mod vendor`.
Update the pin to gophercloud v0.18.0 so that we get a fix that came with gophercloud/gophercloud#2160.
Since this change you are no longer able to create objects with a / in
them to create pseudo-folders. This behavior is relied upon by kOps
documented as broken in kubernetes/kops#9933. fixes #2159.