-
Notifications
You must be signed in to change notification settings - Fork 522
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
imdsclient: return options for all IMDS fetch functions #1598
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Could we also boot variants without user data to check that behavior as well? |
zmrow
reviewed
May 25, 2021
webern
reviewed
May 25, 2021
|
Fixed typo in commit message. |
webern
approved these changes
May 25, 2021
I tested the change and it works:
|
jpculp
commented
May 26, 2021
zmrow
reviewed
May 26, 2021
|
This commit changes the return type for the IMDS fetch functions to options returning None when a 404 is encountered. This makes it easier for the caller to decide what to do when a 404 occurs and is closer to the behavior before imdsclient was written. `fetch_identity_document` and its associated `IdentityDocument` struct were removed in favor of separate `fetch_region` and `fetch_instance_type` functions. Instance-type is now fetched via IMDS meta-data as opposed to the identity document. We are returning to the original behavior as it is possible that the identity document can be absent in certain situations. Changes were also made to shibaken, pluto, and early-boot-config to accommodate the options detailed above.
Rebased and re-tested |
zmrow
reviewed
May 26, 2021
zmrow
approved these changes
May 26, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue number:
N/A
Description of changes:
This commit changes the return type for the IMDS fetch functions to
options returning None when a 404 is encountered. This makes it easier
for the caller to decide what to do when a 404 occurs and is closer to
the behavior before imdsclient was written.
fetch_identity_document
and its associatedIdentityDocument
structwere removed in favor of separate
fetch_region
andfetch_instance_type
functions. Instance-type is now fetched via IMDSmeta-data as opposed to the identity document. We are returning to the
original behavior as it is possible that the identity document can be
absent in certain situations.
Changes were also made to shibaken, pluto, and early-boot-config to
accommodate the options detailed above.
Testing done:
aws-k8s-1.19
ami and launched instance.host-containers.admin.user-data
contained a base64-encoded block./.bottlerocket/host-containers/admin/user-data
contained JSON.sudo sheltie
to verify root shell was still available.pluto
with it's sub-commands to verify functionality.Other testing:
aws-ecs-1
with no user data set.aws-dev
with no user data set. (tested by @arnaldo2792)vmware-k8s-1.20
with user data from guestinfo interface.Terms 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.