Update microvm provisioning plan to ensure its idempotent & environment aware #66
Assignees
Labels
area/reconciliation
Indicates an issue or PR related to reconciliation
kind/feature
New feature or request
Comments
richardcase
changed the title
richardcase
added
the
area/reconciliation
|
Note: ensure that resources created based on initial values are cleaned up |
yitsushi
added a commit
to yitsushi/flintlock
that referenced
this issue
Oct 29, 2021
I tried to come up with a proper solution to this, but all of them had flaws. == Options I found and explored their possibilities 1. Add a new version argument to the Get function. That's just ugly as hell. I like the Options pattern. Much easier to update without breaking 300 calls in the codebase. 2. Add a new function on the Repo. It seems odd and I think it's unnecessary because Get can handle it. 3. Create a function only on the Containerd repo implementation. That would require checks and casting everywhere we want to use it. == Conclusion I picked options 1, because it causes less pain not and long term. It does not matter what content store we are using, it HAS to be able to manage versions somehow, even if it's an external service, the Repository implementation has to handle versions, without versions we are are playing with a bag of venomous snakes without any kind of antidote, maybe fun, but not safe. Related to liquidmetal-dev#66
4 tasks
yitsushi
added a commit
to yitsushi/flintlock
that referenced
this issue
Nov 2, 2021
I tried to come up with a proper solution to this, but all of them had flaws. == Options I found and explored their possibilities 1. Add a new version argument to the Get function. That's just ugly as hell. I like the Options pattern. Much easier to update without breaking 300 calls in the codebase. 2. Add a new function on the Repo. It seems odd and I think it's unnecessary because Get can handle it. 3. Create a function only on the Containerd repo implementation. That would require checks and casting everywhere we want to use it. == Conclusion I picked options 1, because it causes less pain not and long term. It does not matter what content store we are using, it HAS to be able to manage versions somehow, even if it's an external service, the Repository implementation has to handle versions, without versions we are are playing with a bag of venomous snakes without any kind of antidote, maybe fun, but not safe. Related to liquidmetal-dev#66
yitsushi
added a commit
to yitsushi/flintlock
that referenced
this issue
Nov 2, 2021
I tried to come up with a proper solution to this, but all of them had flaws. == Options I found and explored their possibilities 1. Add a new version argument to the Get function. That's just ugly as hell. I like the Options pattern. Much easier to update without breaking 300 calls in the codebase. 2. Add a new function on the Repo. It seems odd and I think it's unnecessary because Get can handle it. 3. Create a function only on the Containerd repo implementation. That would require checks and casting everywhere we want to use it. == Conclusion I picked options 1, because it causes less pain not and long term. It does not matter what content store we are using, it HAS to be able to manage versions somehow, even if it's an external service, the Repository implementation has to handle versions, without versions we are are playing with a bag of venomous snakes without any kind of antidote, maybe fun, but not safe. Related to liquidmetal-dev#66
richardcase
changed the title
yitsushi
added a commit
that referenced
this issue
Nov 3, 2021
I tried to come up with a proper solution to this, but all of them had flaws. == Options I found and explored their possibilities 1. Add a new version argument to the Get function. That's just ugly as hell. I like the Options pattern. Much easier to update without breaking 300 calls in the codebase. 2. Add a new function on the Repo. It seems odd and I think it's unnecessary because Get can handle it. 3. Create a function only on the Containerd repo implementation. That would require checks and casting everywhere we want to use it. == Conclusion I picked options 1, because it causes less pain not and long term. It does not matter what content store we are using, it HAS to be able to manage versions somehow, even if it's an external service, the Repository implementation has to handle versions, without versions we are are playing with a bag of venomous snakes without any kind of antidote, maybe fun, but not safe. Related to #66
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the solution you'd like:
Change the plan/steps so that it's aware of any changes in the environment to ensure it can re-create the desired state. For example, it should be aware that the Firecracker process has dies and create/config a new one.
Bug for specified issue: #178
The text was updated successfully, but these errors were encountered: