Refactor TektonConfig Reconciler and Cleanup #421
Conversation
If clustertask and pipelines templates are disabled then due to return statement it used to return early without executing remaning code. Signed-off-by: Shivam Mukhade <[email protected]>
tekton-robot
added
release-note
|
The following is the coverage report on the affected files.
|
| PreReconciler, | ||
| ComponentsReady, | ||
| PostReconciler, |
There was a problem hiding this comment.
I assume these conditions are displayed on status and i think PreReconciler and PostReconciler words are more towards technical
May i know the reason behind removing old conditions
There was a problem hiding this comment.
PreReconciler and PostReconciler words are more towards technical
I agree with this. It would be great if we could rename it with something that indicates the objective/end result of the action. It doesn't has to be precise. Even PreInstall PostInstall will be better.
There was a problem hiding this comment.
yeah PreInstall PostInstall will also be nice
also we do want to break down the component status in some way
currently the componentsready cond will show any error
but in further interation we do want to find a better way for it
There was a problem hiding this comment.
Note that if we change what is written in the Status (the name of the condition, …), we need to validate other tools that are depending on this won't be broken (e.g. openshift console, …)
There was a problem hiding this comment.
(because we are changing the API)
There was a problem hiding this comment.
yeah in this case we are chaning the api
we have removed the manifest field from status
and updated conditions
what tools do we have to validate? 🤔
|
/approve |
tekton-robot
added
the
approved
|
/hold |
tekton-robot
added
the
do-not-merge/hold
| } | ||
|
|
||
| func (a Addon) IsEmpty() bool { | ||
| return reflect.DeepEqual(a, Addon{}) |
There was a problem hiding this comment.
Any reason to use reflect here instead of just len(a.Params) == 0 ?
We should avoid using reflect when we can, it's kind-of costly for.. not always a valid reason to be.
There was a problem hiding this comment.
yeah len of param would work...
@vdemeester how about using equality.Semantic.DeepEqual not in this case but here is that okay compared to reflect?
There was a problem hiding this comment.
Maybe yes ? My point is just that we should aim to use as less as possible reflect and those things.. but when we don't have the choice .. 😛
| PreReconciler, | ||
| ComponentsReady, | ||
| PostReconciler, |
There was a problem hiding this comment.
Note that if we change what is written in the Status (the name of the condition, …), we need to validate other tools that are depending on this won't be broken (e.g. openshift console, …)
| PreReconciler, | ||
| ComponentsReady, | ||
| PostReconciler, |
There was a problem hiding this comment.
(because we are changing the API)
| // GroupVersionKind returns SchemeGroupVersion of a TektonConfig | ||
| func (tp *TektonConfig) GroupVersionKind() schema.GroupVersionKind { | ||
| func (tc *TektonConfig) GroupVersionKind() schema.GroupVersionKind { | ||
| return SchemeGroupVersion.WithKind(KindTektonConfig) | ||
| } | ||
|
|
||
| // GetCondition returns the current condition of a given condition type | ||
| func (tps *TektonConfigStatus) GetCondition(t apis.ConditionType) *apis.Condition { | ||
| return configCondSet.Manage(tps).GetCondition(t) | ||
| func (tc *TektonConfig) GetGroupVersionKind() schema.GroupVersionKind { | ||
| return SchemeGroupVersion.WithKind(KindTektonConfig) |
There was a problem hiding this comment.
GroupVersionKind can be removed now.. will update !
There was a problem hiding this comment.
in generated code and internally in knative/pkg GroupVersionKind is used, in some transformer
GetGroupVersionKind is defined so that we can used in FilterController
tektonTriggerinformer.Get(ctx).Informer().AddEventHandler(cache.FilteringResourceEventHandler{
FilterFunc: controller.FilterController(&v1alpha1.TektonConfig{}),
Handler: controller.HandleAll(impl.EnqueueControllerOf),
})
so lets keep GroupVersionKind also
i will take a deep look and then remove
sm43
force-pushed
the
refactor-config
branch
from
8320c73 to
27b712d
Compare
|
The following is the coverage report on the affected files.
|
This updates the tektonconfig conditions and removes unnecessary code. Signed-off-by: Shivam Mukhade <[email protected]>
If TektonConfig has a deletion stamp, it won't be deleted unless the operator is up and running as the object has finalizer. waiting for it to get deleted will stop operator from running and object still won't be deleted. hence removing the condition for checking deletion timestamp and letting user to create a new instance of tektonconfig after deletion. Signed-off-by: Shivam Mukhade <[email protected]>
sm43
force-pushed
the
refactor-config
branch
from
27b712d to
77aea2b
Compare
|
The following is the coverage report on the affected files.
|
|
/hold cancel |
tekton-robot
removed
the
do-not-merge/hold
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nikhil-thomas, vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
Fixes addon component deletion
If clustertask and pipelines templates are disabled then
due to return statement it used to return early without
executing remaning code.
Updates TektonConfig Conditions and cleanup
This updates the tektonconfig conditions and removes
unnecessary code
Removes deletion timestamp check in Autocreation of TektonConfig
If TektonConfig has a deletion stamp, it won't be deleted
unless the operator is up and running as the object has
finalizer. waiting for it to get deleted will stop operator
from running and object still won't be deleted.
hence removing the condition for checking deletion timestamp
and letting user to create a new instance of tektonconfig
after deletion.
Signed-off-by: Shivam Mukhade [email protected]
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Release Notes