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.
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
Add two feature gates : Image based deployment and additional runtimeClasses #394
Add two feature gates : Image based deployment and additional runtimeClasses #394
Changes from all commits
27a7e94
b6bacc1
2559ba0
c4de12f
c69ccba
1fc86ae
36272dc
d1eea4b
fb547fe
0e53603
6c004fd
9e96e8d
c59f99b
27599db
9a30d74
5f47dc5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If we reconcile on Create I guess it would make sense to also reconcile on Delete, wouldn't it? I understand handling Create since we want to handle creation of both the feature gate master configmap and individual gated features' configmaps. With the same reasoning though, wouldn't we want handle their deletion as well?
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.
How do you think the deletion of configmaps be handled? Everything roll backed ? Or the configmap being recreated based on known state?
My thinking was to only handle create/update and document that on deletion the behaviour is not deterministic. And handle these cases when feature gate graduates to stable and part of KataConfig.
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 me start by stating the wider context so that we can be sure we're on the same page.
I assume that we're only watching configmaps because we want to support modifications on-the-fly (ie. while a KataConfig exists). If we didn't we'd just sample the configmaps during installation and then no further modification would be possible.
I believe it would then make sense to support all such modifications rather than a (pretty much arbitrary) subset. I mean, we could say "you can enable a gated feature subsequently if you didn't enable it initially but once you do that you're stuck with it, no disabling possible" but does it make much sense?
I'm not sure what you mean when you mention non-deterministic behaviour. The feature gates are booleans so they fundamentally switch between two states, both of which necessarily need to be well defined. If you delete a configmap that enabled both images and additional runtimeclasses I imagine that the controller should deterministically respond by switching back to extension and by deleting the extra runtimeclasses.
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.
What we say is you disable it by turning it off in the configmap and not by deleting the configmap.
I'm not comfortable to do a complete rollback for all extensions to default values if the configmap is deleted. IOW switching to extension, removing all runtimeClasses and other features we add going forward.
Will be a heavy operation for say an accidental delete. Although one can argue that it's an admin operation and need to be done carefully.
Do you think this is how we should handle or there is an alternative?
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.
The question is, do we even have a choice? Cluster admin can delete the configmap as they see fit. Our only choice that I can see is, do we handle the deletion or do we allow the cluster to stay in an inconsistent state?
It's true that depending on the gated feature set a complete rollback might be a heavy operation and it could be done in error. But the same is true of just about any KataConfig operation, including creation, modification and deletion.
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.
One approach I was thinking was to use the in-memory state of the featuregate to decide. But then it deviates from the using etcd as the source of truth. I'll do some experiments and update.
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.
In-memory state wouldn't be reliable enough, the controller could be restarted at any time. And yes, it could be rather confusing for cluster admin, too, if the controller is guided by its hidden in-memory state rather the visible cluster resources...
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.
Is there a k8s way to "lock" the CM once it's created? or to block its deletion (finalizers?)? would it help in this case?
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.
Adding a finalizer would indeed delay deletion, I'm afraid however that it would be quite a misuse (or even abuse) of finalizer.
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.
Yeah adding finalizer will not give us anything here imho..
Anyways I have added some changes to handle deletion.. PTAL
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.
Perhaps I'm confused but I don't see how this is related to feature gating. (?)