-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Decompress GZIP'd user data #1762
Conversation
176e80f
to
706489f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the change LGTM. doesn't seem like we are going to adopt decompressing individual parts, so can we do a doc update before merging?
3fceead
to
d741996
Compare
@ndbaker1 latest rev adds support for this, PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rewrote the unit tests for this config provider; they're more verbose but I think being explicit about the input is more clear and lets us more easily add test cases in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you do any integration testing here? Or is that covered by the existing integration tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i like the change, thanks for skipping over the junk to setup mime documents and testing the actual provider interface
if part.Header.Get(contentEncodingHeader) == "gzip" { | ||
decompressedNodeConfigPart, err := decompressIfGZIP(nodeConfigPart) | ||
if err != nil { | ||
return nil, err | ||
} | ||
nodeConfigPart = decompressedNodeConfigPart | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need to make a check that it's gzip
and then gracefully handle it not being gzip
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't just calling decompressIfGZIP
in all cases work better since its fallible in constant time and safe either way?
To not hit this branch you'd have to set the nodeConfig mediaType but forget to add the gzip encoding header, which im sure would only happen on accident. maybe handling it explicitly is more "proper", but not sure if its necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MIME semantics dictate that if the section is GZIP'd, this header needs to be there. If a user (or library) is creating MIME documents that use GZIP but omit this header, that should fail because it's not conformant to the spec.
Generally, folks are only using GZIP compression via a library which should implement this properly -- folks aren't hand-writing and hand-compressing their MIME docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out cloudinit doesn't care what the spec says, and just tries to base64-decode and gzip-decompress pretty much anything it handles at any scope. It's more important for us to match the cloudinit behavior than to follow the spec, for better or worse. Updated in latest rev
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you do any integration testing here? Or is that covered by the existing integration tests?
if part.Header.Get(contentEncodingHeader) == "gzip" { | ||
decompressedNodeConfigPart, err := decompressIfGZIP(nodeConfigPart) | ||
if err != nil { | ||
return nil, err | ||
} | ||
nodeConfigPart = decompressedNodeConfigPart | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't just calling decompressIfGZIP
in all cases work better since its fallible in constant time and safe either way?
To not hit this branch you'd have to set the nodeConfig mediaType but forget to add the gzip encoding header, which im sure would only happen on accident. maybe handling it explicitly is more "proper", but not sure if its necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i like the change, thanks for skipping over the junk to setup mime documents and testing the actual provider interface
/ci |
@cartermckinnon roger that! I've dispatched a workflow. 👍 |
@cartermckinnon the workflow that you requested has completed. 🎉
|
One flake:
Not related |
4936741
to
2900e9d
Compare
2900e9d
to
8071860
Compare
/ci |
@cartermckinnon roger that! I've dispatched a workflow. 👍 |
@cartermckinnon the workflow that you requested has completed. 🎉
|
if err != nil { | ||
return nil, err | ||
} | ||
nodeConfigPart, err = decompressIfGZIP(nodeConfigPart) | ||
if err != nil { | ||
return nil, err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: theres a custom error message around the calls above but not here :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the more i think on this, should we be more tolerant and break
on these errors so that we can try the remaining parts? maybe not if theres just a simple mistake and the user would prefer it doesn't continue if their config is not included
decodedLen, err := e.Decode(decodedData, data) | ||
if err != nil { | ||
return data, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so none of the possible errors here end up mattering?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh i guess it can only return CorruptInputError
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm as-is, one nit comment
decodedLen, err := e.Decode(decodedData, data) | ||
if err != nil { | ||
return data, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh i guess it can only return CorruptInputError
🤔
Issue #, if available:
Fixes #1734
Description of changes:
Adds support for GZIP-compressed user data.
The following scenarios are supported:
NodeConfig
that is compressed with GZIP.Content-Encoding: gzip
header).By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.