-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expected fix for LeaseID missing not present in v0.12.0 #236
Comments
Speculation: the merge for the addition of c.o.ClientProvidedKeyOptions overwrote the change for c.o.AccessConditions.LeaseAccessConditions |
Tried it but still no change - the code in /opt/go/pkg/mod/github.com/!azure/[email protected]/azblob/chunkwriting.go (which is in my gocache) is still incorrect. |
hey @eccles , The changes which you mentioned has already been merged. Can you explain what issue you are facing now? |
To summaru=ise the state of the repo looks correct but when I do a go get I get a versuion without the #230 change which I need. I have tried @dev which gives me the v0.10.1-0.20201209071908-559b75bbc31d which is no good. |
go list -m -json github.com/Azure/[email protected] The time looks a little suspicious... or maybe not |
I was curious and had a look myself. I checkout out the repo.
Then diffed the entire tree using Meld with my go mod cache.
So the bytes that gets downloaded by go is not what's in the repo. Could this be the reason why I got the checksum mismatch in this issue that you closed: #237 |
So to summarize, @eccles I experience the same as you. |
It looks like the
As a workaround, you can instead refer to that commit by the pseudo-version
|
Probably the best fix going forward would be to |
@bcmills thanx - @mohsha-msft ? |
The tag for this module got yanked and now checksums are failing. Pin the version to the pseudo-version as described in Azure/azure-storage-blob-go#236 (comment).
The tag for this module got yanked and now checksums are failing. Pin the version to the pseudo-version as described in Azure/azure-storage-blob-go#236 (comment).
The tag for this module got yanked and now checksums are failing. Pin the version to the pseudo-version as described in Azure/azure-storage-blob-go#236 (comment).
The tag for this module got yanked and now checksums are failing. Pin the version to the pseudo-version as described in Azure/azure-storage-blob-go#236 (comment).
@mohsha-msft any chance for a 12.1 tag soon? |
This issue has become a matter of urgency for us - any chance of a 0.12.1 release which is properly tagged? |
I can confirm that using v0.11.1-0.20201209121048-6df5d9af221d as suggested by @bcmills does apparently work. |
The workaround works for me too. I would love to see 0.12.1 released though. |
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information.
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information. Signed-off-by: Ondřej Budai <[email protected]>
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information. Signed-off-by: Ondřej Budai <[email protected]>
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information. Signed-off-by: Ondřej Budai <[email protected]>
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information. Signed-off-by: Ondřej Budai <[email protected]>
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it introduced a non-compatible API change. This commit does the same thing as a67baf5 did for kolo/xmlrpc: We now have two wrappers around the affected part of the API. Fedora 32 uses the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its vendored deps) use the wrapper around the new API. The switch is implemented using go build flags and spec file magic. See a67baf5 for more thoughts. Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why? The maintainers of azblob probably tagged a wrong commit with v0.12.0 which breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit. See Azure/azure-storage-blob-go#236 for more information. Signed-off-by: Ondřej Budai <[email protected]>
That's quite a strange issue, we apologize for the inconvenience. A new release just went out: https://github.com/Azure/azure-storage-blob-go/releases/tag/v0.13.0 Please let us know if you are still encountering problems. |
Due to Azure/azure-storage-blob-go#236 , we had to use a weird version of this library (see 1b05192). A new release came out yesterday that's tagged correctly so let's use it so we can remove the hack from go.mod. Signed-off-by: Ondřej Budai <[email protected]>
HI - I can confirm that this is fixed by v0.13.0 |
Due to Azure/azure-storage-blob-go#236 , we had to use a weird version of this library (see 1b05192). A new release came out yesterday that's tagged correctly so let's use it so we can remove the hack from go.mod. Signed-off-by: Ondřej Budai <[email protected]>
Due to Azure/azure-storage-blob-go#236 , we had to use a weird version of this library (see 1b05192). A new release came out yesterday that's tagged correctly so let's use it so we can remove the hack from go.mod. Signed-off-by: Ondřej Budai <[email protected]>
Which version of the SDK was used?
0.12.0
Which platform are you using? (ex: Windows, Linux, Debian)
Linux
What problem was encountered?
Incorrect version tagged upstream - expected fix #230 not implemented
How can we reproduce the problem in the simplest way?
go get v0.12.0 and inspect chunkwriting.go - expecetd fix from #230 not present in line 187
Have you found a mitigation/solution?
No
Some explanation
Thanks for the release - however the tagging has gone awry - I change my go.mod file to:
github.com/Azure/azure-storage-blob-go v0.12.0
and inspection of my go cache:
vi /opt/go/pkg/mod/github.com/!azure/[email protected]/azblob/chunkwriting.go
shows the change has not been applied.
187 _, err := c.to.StageBlock(c.ctx, chunk.id, bytes.NewReader(chunk.buffer), LeaseAccessConditions{}, nil, c.o.ClientProvidedKeyOptions)
If I pull repo directly using git clone and inspect that all looks good:
paul@paul-Precision-7530:~/git/azure-storage-blob-go$ git log
commit 6df5d9a (HEAD -> master, tag: v0.12.0, origin/master, origin/HEAD)
Merge: 456ab47 559b75b
Author: Mohit Sharma [email protected]
Date: Wed Dec 9 17:40:48 2020 +0530
Merge pull request #235 from Azure/dev
Release v0.12.0
commit 559b75b (origin/dev)
Author: Mohit Sharma [email protected]
Date: Wed Dec 9 12:49:08 2020 +0530
v0.12.0 Release change logs (#231)
v0.12.0 Release ChangeLogs & BreakingChanges
Updated changelogs
Added mmf changes in ChangeLog.md
commit 0c35e97
Author: Mohit Sharma [email protected]
Date: Fri Nov 20 23:41:19 2020 +0530
Fixed #230 (#232)
and the fix is in:
186 _, err := c.to.StageBlock(c.ctx, chunk.id, bytes.NewReader(chunk.buffer), c.o.AccessConditions.LeaseAccessConditions, nil, c.o.ClientProvidedKeyOptions)
The text was updated successfully, but these errors were encountered: