Skip to content
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

Update ugorji/go/codec to v1.2.4 #31

Merged
merged 1 commit into from
Feb 11, 2021
Merged

Conversation

angdraug
Copy link
Contributor

@angdraug angdraug commented Feb 6, 2021

This is a continuation of hashicorp/packer#10146 that was submitted before the rpc code was moved from packer to packer-plugin-sdk.

When running Packer built with modern[0] version of ugorji using a plugin built from source and therefore with the 2015 version currently pinned in Packer's go.mod, I hit ugorji/go#269 when my plugin tries to pipe into a remote "cat > '%s'":

Build 'base-20201021-5f90bdf5-490e-582b-fb1d-b5d4315f5eaa' errored after 25 seconds 772 milliseconds: msgpack decode error [pos 274]: invalid length of bytes for decoding time - expecting 4 or 8 or 12, got 15

[0] As in, newer than ugorji/go@5a66da2 from 2017, e.g. Packer as packaged in Debian.

The same pipe works fine when either running Packer built from source (with the same pin to old ugorji), or forcing the plugin to build with the modern ugorji:

replace github.com/hashicorp/packer => github.com/angdraug/packer v1.6.4-ugorji-go-v1.1.13

Bringing ugorji in Packer to the current version will leap over this and other incompatibilities that have built up in ugorji over the years, will make custom plugins work out of the box with the Debian build of Packer, and will allow plugin writers to use modules that depend on newer versions of ugorji.

@angdraug angdraug requested a review from a team as a code owner February 6, 2021 20:57
Copy link
Contributor

@azr azr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello there, thanks for opening again 🙂 . This looks fine by me; I did some testing and some acceptance testing too.

I think we should merge this now before Packer 1.7.0 is released, since we bumped the API MAJOR version.
We should also probably do much more testing; and some reading of the diff for the lib.
This dependency could become a difficult tech debt; and even if we introduce a bug by merging this; the lib seems well maintained so that we could PR our way out of a bug.

I think that the whole Packer team needs to agree with this though !

For context: the codec is what marshals a go struct into a string and back. In core to plugins communications, it's used there:

func newClientWithMux(mux *muxBroker, streamId uint32) (*Client, error) {
clientConn, err := mux.Dial(streamId)
if err != nil {
return nil, err
}
h := &codec.MsgpackHandle{
WriteExt: true,
}
clientCodec := codec.GoRpc.ClientCodec(clientConn, h)
return &Client{
mux: mux,
client: rpc.NewClientWithCodec(clientCodec),
closeMux: false,
}, nil
}

and there:

// ServeConn serves a single connection over the RPC server. It is up
// to the caller to obtain a proper io.ReadWriteCloser.
func (s *PluginServer) Serve() {
// Accept a connection on stream ID 0, which is always used for
// normal client to server connections.
stream, err := s.mux.Accept(s.streamId)
if err != nil {
log.Printf("[ERR] Error retrieving stream for serving: %s", err)
return
}
defer stream.Close()
h := &codec.MsgpackHandle{
WriteExt: true,
}
rpcCodec := codec.GoRpc.ServerCodec(stream, h)
s.server.ServeCodec(rpcCodec)
}

So it's sort of simple, but we can't break these all the time 🙂 .

Copy link
Contributor

@azr azr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, a Github 500 caused a dupe review, and I can't delete this one.

@azr
Copy link
Contributor

azr commented Feb 11, 2021

Got confirmation during our weekly meeting !

@azr azr merged commit ee4391c into hashicorp:main Feb 11, 2021
azr added a commit to azr/packer-provisioner-goss that referenced this pull request Mar 31, 2021
A recent update in the packer-plugin-sdk was a breaking change in Packer's internal marshalling for communicating with plugins : hashicorp/packer-plugin-sdk#31

It could be that this project is not impacted, but updating to v0.1 will make sure it's not the case.
I didn't update the `go.sum` file, this will happen automatically next time you run `go ...` in the project folder.
azr added a commit to azr/packer-plugin-exoscale that referenced this pull request Mar 31, 2021
A recent update in the packer-plugin-sdk was a breaking change in Packer's internal marshalling for communicating with plugins : hashicorp/packer-plugin-sdk#31

It could be that this project is not impacted, but updating to v0.1 will make sure it's not the case.
I didn't update the `go.sum` file, this will happen automatically next time you run `go ...` in the project folder.
azr added a commit to azr/packer-builder-huaweicloud-ecs that referenced this pull request Mar 31, 2021
A recent update in the packer-plugin-sdk was a breaking change in Packer's internal marshalling for communicating with plugins : hashicorp/packer-plugin-sdk#31

It could be that this project is not impacted, but updating to v0.1 will make sure it's not the case.
I didn't update the `go.sum` file, this will happen automatically next time you run `go ...` in the project folder.
fishnix pushed a commit to YaleUniversity/packer-plugin-goss that referenced this pull request May 24, 2021
A recent update in the packer-plugin-sdk was a breaking change in Packer's internal marshalling for communicating with plugins : hashicorp/packer-plugin-sdk#31

It could be that this project is not impacted, but updating to v0.1 will make sure it's not the case.
I didn't update the `go.sum` file, this will happen automatically next time you run `go ...` in the project folder.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants