-
Notifications
You must be signed in to change notification settings - Fork 519
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
early-boot-config: Add guestinfo to available VMWare user data retrieval methods #1393
Conversation
^ Fixed up a failing test I missed... :) |
^ adds the platform dependency to |
^ un-nested the |
@@ -26,6 +27,10 @@ tokio = { version = "0.2", default-features = false, features = ["macros", "rt-t | |||
#tokio = { version = "0.3", default-features = false, features = ["macros", "rt-multi-thread"] } | |||
toml = "0.5" | |||
|
|||
[target.'cfg(target_arch = "x86_64")'.dependencies] |
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 if someone is doing a cargo build
(so, separate from #1404 solutions), what happens here? This dependency here would be skipped, but the code still references vmw_backdoor::bla
, so I think it'd have compile errors about unknown references, which could be pretty confusing. ARM developer machines are getting more common now, and vmware-dev is our first "local" variant, so I don't think this is "weird" enough to ignore. Do we need to conditionalize the VmwareDataProvider on target_arch?
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.
With #1431 in, this is a lot less important. I'm assuming we'd still have undefined references if cargo build
ing this on a non-x86 host, so It'd be nice to do something to clean that up and make it clearer that it's not supported, but it's not as big an issue now since we'd expect the person to use cargo make
to handle cross-compilation automatically.
Ok(Some(s)) => output.push(s), | ||
} | ||
|
||
// If we didn't find any user data in guestinfo, try CD-ROM |
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'm curious what others think here. If I specified user data in two locations, I'd expect both of them to be obeyed (in some order, but that's a different problem) rather than one taking precedence and ignoring the other. Perhaps I have a common user data CD that I use in all launches, and then I use guestinfo for more specific settings in some launches, or whatever.
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.
This seems good now, but I'm wondering where you think we should document this?
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.
Creating an issue for that now. We can probably comment on it here, but I the "main" documentation should happen in the variant's top level README
unless you think it belongs somewhere else.
Given that the CdRomDataProvider contained VMware-specific logic and more will continue to be added to it, naming it as such makes it clearer to the caller and still allows for the underlying logic to be factored out in the future should we deem necessary.
This adds a method to SettingsJson that takes in a string (expected to be TOML data), and attempts to parse it, remove the "settings" layer, and create a `SettingsJson` from it. This logic was previously sprinkled around in a few places, creating multiple identical error variants, etc.
This change adds an additional user data source to the VMWare provider; the guestinfo (host-guest) interface. This source will be checked after the CD-ROM, and override any settings set via CD-ROM.
^ Addressed all the comments and updated the testing! |
})?; | ||
|
||
// Decompress the data if it's compressed | ||
let decoded = expand_slice_maybe(&decoded_bytes).context(error::Decompression { |
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.
Here's another spot we could chain the OptionalCompressionReader and DecoderReader.
One note though - the error is no longer strictly related to decompression - it could fail base64 too - so I think we'd want a new variant that's a little more generic, maybe UserDataInput or something?
); | ||
} | ||
|
||
let json = SettingsJson::from_toml_str(&user_data_str, "user data from CD-ROM").context( |
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.
let json = SettingsJson::from_toml_str(&user_data_str, "user data from CD-ROM").context( | |
let json = SettingsJson::from_toml_str(&user_data_str, "user data from CD-ROM").with_context(|| |
nit: so we don't do the string conversion unnecessarily.
Issue number:
Closes #1369
Description of changes:
The changes aren't vast here, but it's probably easiest to read the commits separately.
I do think that there's some refactoring to be done in this program, namely to separate "platform" from "data provider", but that will be done in another PR.
Testing done:
aws-k8s-1.17
AMI to ensure I didn't break anything over therevmware-dev
image with a CD-ROM attached containing anovf-env.xml
file w/ user datavmware-dev
image with a CD-ROM attached containing a TOMLuser-data
filebase64
,b64
,B64
,Base64
andgz+b64
,Gz+B64
,gzip+base64
, andGzip+Base64
with user data set and unsetTerms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.