Add host-container user-data setting #1244
Conversation
You can set settings.host-containers.NAME.user-data to a valid base64-encoded string to have the (decoded) data placed in a file accessible to the host container at /.bottlerocket/host-containers/NAME/user-data.
tjkirch
force-pushed
the
host-con-user-data
branch
from
d0d677d
to
1e21634
Compare
|
^ This push tries to address @zmrow's wording concerns above. |
|
|
||
| /// Older versions don't know about the user-data settings; we remove them so that old versions | ||
| /// don't see them and fail deserialization. | ||
| fn backward(&mut self, mut input: MigrationData) -> Result<MigrationData> { |
There was a problem hiding this comment.
Is there any reason to delete the user-data file(s) that might exist?
There was a problem hiding this comment.
I don't think so, but it's an interesting question to leave up for others to consider.
It seems to me that the worst case might be downgrading and still using a host container that understands the user-data file but tries to do something with it that isn't compatible with the older Bottlerocket version..? For example, maybe you're using the user-data to configure a host-container that makes API calls back to the parent, and those calls are no longer valid with the downgraded version. I think, in that case, you would have created an implicit dependency from the container to the host version, and so should remove/downgrade the host container before downgrading Bottlerocket.
I'm hesitant to delete things from host container persistent storage, so I'd like to have a decent reason, or fall back to leaving what (naively) seems to be a harmless file.
There was a problem hiding this comment.
It's a really interesting question and one that has some pretty good arguments both ways. For now I think we should leave the file there.
There was a problem hiding this comment.
I agree, I think it's far enough out there as an edge case that it doesn't justify deleting data from the persistent store.
This is a prerequisite for other upcoming work, but the basic idea is to allow easier customization of host-container agents.
Testing done:
I added this to my instance user data:
Here's the result, the basic functionality of this change:
Invalid base64 data is rejected:
To test the migration, I built a 1.0.4 image from the v1.0.4 tag, updated to a 1.0.5 image based on this branch, re-confirmed that the user-data setting worked, downgraded back to 1.0.4, and confirmed the user-data setting was removed and the host came back up OK.
I confirmed a pod runs OK after downgrade/upgrade cycles.
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.