-
Notifications
You must be signed in to change notification settings - Fork 524
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: Simplify conditional compilation and make local_file
available to all platforms
#1576
early-boot-config: Simplify conditional compilation and make local_file
available to all platforms
#1576
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,6 +9,9 @@ use snafu::{OptionExt, ResultExt}; | |
use std::fs; | ||
use std::path::Path; | ||
|
||
#[cfg(bottlerocket_platform = "aws-dev")] | ||
use crate::provider::local_file::{local_file_user_data, USER_DATA_FILE}; | ||
|
||
/// Unit struct for AWS so we can implement the PlatformDataProvider trait. | ||
pub(crate) struct AwsDataProvider; | ||
|
||
|
@@ -82,7 +85,16 @@ impl PlatformDataProvider for AwsDataProvider { | |
|
||
let mut client = ImdsClient::new().await.context(error::ImdsClient)?; | ||
|
||
// Instance identity doc first, so the user has a chance to override | ||
// Attempt to read from local file first on the `aws-dev` variant | ||
#[cfg(bottlerocket_platform = "aws-dev")] | ||
{ | ||
match local_file_user_data()? { | ||
None => warn!("No user data found via local file: {}", USER_DATA_FILE), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think not having a user data file is the normal case - is it worth a warning-level message? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think for variants that have the ability to use a local file it's worth having the message so users know that nothing was found there, similar to what we do for other sources. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we have it as a info level message? I guess that would mean the message won't go to the console? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll keep it as |
||
Some(s) => output.push(s), | ||
} | ||
} | ||
|
||
// Instance identity doc next, so the user has a chance to override | ||
match Self::identity_document(&mut client).await? { | ||
None => warn!("No instance identity document found."), | ||
Some(s) => output.push(s), | ||
|
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 confused as to why local_file still has the cfg directive, since the PR says "It also makes local_file a common function that all platforms can use" - wouldn't we remove all conditionals on it, and let the data providers / platforms decide whether to call the function?
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.
We could for sure do that, but when compiling variants that don't use the code in the
local_file
module, we're going to get "unused" warnings like: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 not really sure how we get around it other than hiding the whole module behind a
cfg
directive like I've done here... perhaps someone knows a trick I don't know?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.
You could just silence the warning with
#[allow(dead_code)]
on the function that is sometimes unused. (need to look up the correct string there)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.
Hm - I suppose we could do that but I like it a bit less. Are those really the only two options 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.
This (very good) article suggests the pattern I'm using: putting
cfg
directives on module imports to keep the actual code clean and not ignore any valid warnings.IMHO let's keep the code as is unless we come up with something better.