✨ feat: introduce NodeReadinessEvaluation (NRE) CRD and controller by Karthik-K-N · Pull Request #345 · kubernetes-sigs/node-readiness-controller

Karthik-K-N · 2026-08-04T08:43:58Z

Description

Introduces the NodeReadinessEvaluation (NRE) custom resource and its dedicated reconciler. NRE provides a per-node, read-only mirror of the evaluated state of every applicable NodeReadinessRule, giving operators a single object to kubectl get nre <node-name> to see the full readiness picture of any node without having to cross-reference multiple rule statuses.

Discussion document: https://docs.google.com/document/d/1DOP1G6i__nQN8qbhlSvdswkUquMeSKQY4LU554AbcgM/edit?usp=sharing

Feature Flag

The controller is opt-in via: --enable-node-readiness-evaluation

Related Issue

Type of Change

Testing

Checklist

make test passes
make lint passes

Does this PR introduce a user-facing change?

Doc #(issue)

netlify · 2026-08-04T08:44:04Z

👷 Deploy request for node-readiness-controller pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	`b3210d0`

ajaysundark · 2026-08-09T06:58:42Z

+//   - Node objects (conditions, taints, labels)
+//   - NodeReadinessRule objects (enqueues all nodes matching the changed rule)
+func (r *NodeReadinessEvaluationReconciler) SetupWithManager(mgr ctrl.Manager) error {
+	return ctrl.NewControllerManagedBy(mgr).


@Karthik-K-N IIUC, this would trigger two parallel reconciliations for node updates (NodeReconciler and NREReconciler) and one is handling the output of the other. I wonder if a separate controller for NRE is a better fitting pattern for this or should be bridged into NodeReconciler's watch?

yes I thought about that and I missed to point out why I chose this way, here are my thoughts

Initially tried combining both into the NodeReconciler, but then when I checked with best practices of writing controller, if we do so we will be merging two different operations into one, Node controller adding/removing taints,NRE just storing the result, One failure should not cause requeue for other and I think NodeReconcile should be as quick as possible as it affects the workloads.

Followed the existing pattern of having separate controllers like NRR, Node and NRE

Even if there is race and NRE reconciles first and later the Node, Since the NRE also watches for condition, taint and label, if something updated by the Node Rec then eventually it triggers the NRE. We will be eventually consistent.

These are the thoughts and I lean towards keeping them separate, but let me know what do you think.

My concern with another reconciler is that we are reintroducing a shared (Node) state again between two controllers. looking at buildRuleEvaluation it is very similar to evaluateRuleForNode. reevaluating the node status between two controllers with caches seem like a bad idea (and that seems like repeating what we did and trying to change with rule.status). :/

I saw #343 emitting individual nodeStatusDelta in rule-reconciliation, which could make adding NRE even cheaper than before. Happy to discuss more / hear your thoughts further on this.

DsThakurRawat · 2026-08-11T13:06:34Z

i tested this branch and found two behaviours worth knowing about, plus one interaction with #315. all three are reproduced with runnable tests, happy to share them.

first, a rule-creation window that never heals. the NRE fan-out fires on the rule Create event (GenerationChangedPredicate only filters updates), but the shared ruleCache is only populated on the rule controller's second reconcile pass, because the first one adds the finalizer and returns RequeueAfter one second. so the NRE reconciles for every matching node run against a cache that cannot contain the new rule yet. for rules whose evaluation then changes a node, the taint write re-triggers the node watch and everything heals. but for a rule whose conditions are already satisfied everywhere, nothing mutates any node, the rule's status patch doesn't bump generation, heartbeats don't pass the node predicate (it compares only condition type to status), and informer resyncs are filtered as no-ops. the NRE just permanently misses the rule until some unrelated node change. deletion is fine, reconcileDelete empties the cache before dropping the finalizer. i think this is the concrete version of the question ajaysundark raised above: the reconciler's correctness depends on another controller's queue having run first. listing rules from the informer inside Reconcile instead of reading the private cache would remove the ordering dependency entirely.

second, this branch merges cleanly with #315, and the two disagree once combined. evaluateRuleForNode there honours conditionPolicy anyOf, while buildRuleEvaluation here ANDs every condition unconditionally. an anyOf rule with one of two conditions satisfied ends up enforced as satisfied (no taint) while the NRE for the same node reports it Unmatched. a shared evaluation helper honouring GetConditionPolicy() in both paths would keep them from drifting.

small one: nothing currently produces RuleStatusError, so the Errors count, State Pending, and the Evaluated False condition are unreachable in this iteration. fine if that's intentional groundwork, might deserve a TODO.

The controller side of the NRE proposal is still a draft, so nothing populates these objects yet. Writing them here makes the per-node datasource measurable now, since the payload is decided by the schema and by how many rules apply to a node. Refs kubernetes-sigs/node-readiness-controller#345

ajaysundark · 2026-08-21T03:47:52Z

@Karthik-K-N is this ready for review?

Karthik-K-N · 2026-08-21T04:36:11Z

@Karthik-K-N is this ready for review?

yes , its ready for review

DsThakurRawat · 2026-08-21T16:13:03Z

The rule-creation window I flagged here on Aug 11 has a second victim now, and this one is worse because it's the reporting surface. Walked the sequence on your head 7c0ecc42: a rule Create passes GenerationChangedPredicate into this controller too, ruleToNodeRequests enqueues the matching nodes immediately, but the NRE reconciler reads getApplicableRulesForNode, which serves only the private ruleCache, and the cache isn't populated until the rule controller's second reconcile, because the first one just adds the finalizer and returns RequeueAfter one second (nodereadinessrule_controller.go:118-125, cache write at :139). So for a rule whose conditions are already satisfied on every matching node and whose taint is absent everywhere, the NRE usually reconciles against the empty cache and writes state: Ready with zero rule entries. Nothing corrects it after that: evaluation mutates no node, so no node event fires, and resync updates die on your equality predicates in the For(). Until something else happens to touch that node, the NRE keeps telling any reader (#327's history story, dashboards) that no rule applies to it while one actively does.

The Aug 11 fix suggestion covers both consumers, and it got cheaper to justify: have this controller read rules through the informer instead of the private cache, and the ordering dependency disappears rather than getting patched around.

Separately, I reproduced prow's lint failure locally so it can be named precisely: gocritic ifElseChain on the four-way taint transition at nodereadinessevaluation_controller.go:290, and unparam's unused ctx in the test's sharedSetup at :91. Both trivial.

What I checked that holds: rule deletions do reach this controller (in controller-runtime v0.24.1 a nil DeleteFunc defaults to passing, so GenerationChangedPredicate only filters updates), and your D1 shows the prune works once a reconcile runs; the CEL immutability on nodeSelector makes mapping by selector safe across rule updates; node deletion is covered by the ownerReference; and the single-writer separation is real, this reconciler writes nothing but its own status. One RBAC nit: the marker asks delete on nodereadinessevaluations but nothing in the code ever calls it, GC does that work.

ajaysundark · 2026-08-24T07:39:44Z

+
+	for _, r := range status.Rules {
+		switch r.RuleStatus {
+		case readinessv1alpha1.RuleStatusMatched:


The Matched / Unmatched rules on status is bit unclear to me. Sorry I missed to get this at the doc, will look into it again.

So the RuleStatus field helps to understand "whether node satisfy every condition listed in the rule"
Matched - All rule.Spec.Conditions are satisfied - ideally no taint
Unmatched - Any condition is not satisfied - there is taint on node

Do you think we should use better field name to convey this?

Instead of Matched should I change that to RuleStatusSatisfied means the rule is satisfied by the node?

ajaysundark · 2026-08-24T07:45:26Z

+
+	status.Summary = readinessv1alpha1.EvaluationSummary{
+		MatchedRules:   &matched,
+		UnmatchedRules: &unmatched,


does 'unmatched' (node-selector escaped?) add value to the per-node status? As a node-owner I would less-likely be interested in rules that are not affecting my node.

Imagine a large cluster with many different node-pools. Setting the status of a node in pool-A for other rules associated with every other pools may be rather confusing to the user.

True, I think we can drop the UnmatchedRules field.

ajaysundark · 2026-08-24T07:48:07Z

+// SetupWithManager wires the reconciler to watch:
+//   - Node objects (conditions, taints, labels)
+//   - NodeReadinessRule objects (enqueues all nodes matching the changed rule)
+func (r *NodeReadinessEvaluationReconciler) SetupWithManager(mgr ctrl.Manager) error {


I expect, adding another controller will also increase the API interaction volume to a larger extent at scale.

I think if we can finalize on this aspect, then other things will be easy to tackle
Since we use controller-runtime and it uses a Shared Informer Cache, additional controller does not increase API server watch traffic or our memory footprint. but It does duplicate the reconcile queue (may be CPU usage) and small window of race, but it provides less blast radius and separate of concern, we have two controller doing different things.
Also I think we should consdier at what scale level we can expect this latency of having new controller

hmm. I maybe wrong about the API scale. but my primary concern is that NRE suppose to be a 'record' of what the controller enforced at node but a second reconciler recomputes the decision by further observations. This could bring other race and complexity of state handling.

For example, how do we distinguish even between kubelet added it vs another reconciler added it, when NRE is computed separately in its reconciler?

blast radius and separate of concern

I understand your concern on the implementation risks injecting this detail throughout the controller code. I was imagining #343 could simplify it for the rule, and maybe eventually #389 when we would have to handle the node updates all at just one place.

AnuragThePathak

Haven't got a chance to look into the controller code, which I will get back soon.

About the API, loved the recent update, to drop error and loading states (loading was unnecessary anyway for our controller as it's not time taking by nature). Error being displayed at the rule level solved a lot of problems.

AnuragThePathak · 2026-08-31T09:29:22Z

+	// +kubebuilder:validation:MaxLength=253
+	// +kubebuilder:validation:Pattern=`^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
+	// +kubebuilder:validation:XValidation:rule="self == oldSelf",message="nodeName is immutable and cannot be changed once set"
+	NodeName string `json:"nodeName,omitempty"`


Considering the fact that spec is usually meant for defining the desired state of a CRD, may I know if you considered the trade-offs while putting NodeName as a spec?

My first thought was that we will be better off using 1:1 metadata.name for node and nre.

With on-going updates, the line maybe slightly misplaced, putting the context in the comment only

NodeName string `json:"nodeName,omitempty"`

Yeah, The idea was to keep 1:1 mapping only and currently even the metadata.name is also set to nodename, We should be good to drop this field, but only thing is then the spec will become empty so I thought to keep the nodename as immutable field for better clarity.

Yes that's also right, spec will be empty. But unless there's some guideline or practice in common projects not to do so, we should be good I guess.

AnuragThePathak · 2026-08-31T09:44:14Z

+	// +listType=map
+	// +listMapKey=type
+	// +kubebuilder:validation:MaxItems=32
+	ReadinessConditions []ConditionEvaluationResult `json:"readinessConditions,omitempty"`


I would be against reusing the old ConditionEvaluationResult. When adding default status, I ran into an issue of not being able to properly provide visibility into what's the actual status and what's the status we are calculating after applying default status, because of the name 'CurrentStatus'.

Now that we have a chance to introduce new API, I think replacing 'CurrentStatus' with something like 'EffectiveStatus' and 'ObservedStatus' can improve the observability.

I tend to agree with you, I think instead of currentState we should rename it to ObservedState and we can possibly add another field as EffectiveState which can help the user to understand the effective state which will be ObservedState if present or Default state if CurrentState not present
but
I think if we do this we should do it at both NRE and NRR level to avoid further confusion and keep them simple, Given that both are bit dependent or it may give two different results to user. I can take this up as a follow up task.

Ah state suffix would be confusing I guess, status would be more consistent.

About the NRE and NRR, not quite sure about that. My personal preference would have been to do directly in NRR but obviously not possible due to schema constraints breaking existing schemas, so thought while introducing a new one, should be better doing it from day 1.

Anyway that's your call.

AnuragThePathak · 2026-09-11T12:18:08Z

+	// lastEvaluationTime records the exact moment the controller most recently assessed this rule.
+	//
+	// +required
+	LastEvaluationTime metav1.Time `json:"lastEvaluationTime,omitempty,omitzero"`


Randomly realized that we are putting suffix of "-At" everywhere except this one.

Nice catch, I updated it to LastEvaluatedAt

AnuragThePathak · 2026-09-11T12:18:50Z

+}
+
+// RuleEvaluation defines the outcome of evaluating a single NodeReadinessRule against this Node.
+type RuleEvaluation struct {


Personally I think ConditionPolicy is a value that may be worth adding here.

AnuragThePathak · 2026-09-11T12:28:05Z

+	//
+	// +required
+	// +kubebuilder:validation:Enum=NoSchedule;PreferNoSchedule;NoExecute
+	TaintEffect corev1.TaintEffect `json:"taintEffect,omitempty"`


Also do we keep Taint key and effect separate for cases where people may be interested in filtering by the effect?

Yes, Thats the idea.

AnuragThePathak · 2026-09-13T18:53:31Z

+	}
+
+	ruleStatus := readinessv1alpha1.RuleStatusSatisfied
+	if !allConditionsSatisfied {


You are completely ignoring conditionPolicy. Have to update that.

I have rebased and updated the code. Thank you

vishnukothakapu

Reviewing from the Headlamp plugin side, it looks good! The new NRE CRD with its 1:1 node mapping is exactly what we need for the UI. I've left a couple of quick inline suggestions (around DryRun and rule generations) to make the data even more powerful for the frontend

vishnukothakapu · 2026-09-26T11:34:26Z

+	// Rebuild the full rules slice from scratch on every reconcile.
+	// listType=atomic means the controller owns the whole slice.
+	newRules := make([]readinessv1alpha1.RuleEvaluation, 0, len(applicableRules))
+	for _, rule := range applicableRules {


I noticed in that we are skipping rules if rule.Spec.DryRun is true. From a Headlamp UI/Plugin perspective, DryRun is actually when users most want to look at the evaluation data to see what would happen if they enabled the rule.

Instead of skipping DryRun rules entirely, could we evaluate them and add a DryRun: true boolean to the RuleEvaluation struct? That way, in the Headlamp UI, we can show a special "Dry Run: Satisfied / Unsatisfied" badge on the Node without users getting confused about why the taint isn't actually applied.

yeah, dryrun handling as a whole could use some improvement. @Karthik-K-N Can we consider evaluating this as a follow-up to this PR?

I would be up for it if Karthik is aligned.

vishnukothakapu · 2026-09-26T11:40:05Z

+	// allowing the controller to detect and replace stale evaluation entries.
+	//
+	// +required
+	RuleUID types.UID `json:"ruleUID,omitempty"`


Should we also track ObservedRuleGeneration here? If a rule is edited, the UID stays the same. Having the generation would let our Headlamp plugin easily flag when a node's evaluation is out-of-sync with the latest rule updates (e.g., showing a 'Pending' badge)

ajaysundark · 2026-10-29T16:25:04Z

 			}
 		}
+
+		if r.EnableNRE {


I remember we discussed an option where the node-reconciler could watch the node-keys and handle updates as sole-writer. We could investigate if that's a better path in general. but not blocking this PR

sure, will work on that as a follow up item

ajaysundark · 2026-10-29T16:26:13Z

+	prevRules := make([]readinessv1alpha1.RuleEvaluation, len(nre.Status.Rules))
+	copy(prevRules, nre.Status.Rules)
+
+	patch := client.MergeFrom(nre.DeepCopy())


Does this need optimistic lock? xref previous issues we have been dealing with #343

yes, I think its better to use that to keep consistency, Can I take that in immediate follow up PR?

ajaysundark

/lgtm

AnuragThePathak

Also one more point that caught my eyes is that when a rule is deleted, we have no means to update the NRE object against nodes targeted by that rule.

Intentionally or unintentionally, that NRE update still happens when the node has a taint due to that rule, which is to be removed when the rule is deleted, which change triggers Node Reconciler resulting in NRE update for that node.

But in absence of the taint from the rule, that doesn't happen.

AnuragThePathak · 2026-11-03T16:13:31Z

 	//
 	// +required
-	LastEvaluationTime metav1.Time `json:"lastEvaluationTime,omitempty,omitzero"`
+	LastEvaluatedAt metav1.Time `json:"lastEvaluatedAt,omitempty,omitzero"`


I remember I pointed out the inconsistency of suffix at vs time. But renaming the existing required field was not what I expected. Hence wanted to check, is our plan to add this change with a new API version? Above NRE type file writes v1alpha1 only.

And if we rename the LastEvaluationTime in NodeFailure or NodeEvaluation, my understanding says during patch of the existing rule status, schema validation will throw error, especially during single node updates.

Let me know if you have already considered that aspect, I would be curious how we intend to deal with it.

Reverted the changed, in v1aplha2 lets have a conversion webhook and rename the field to avoid the breaking change.

AnuragThePathak · 2026-11-03T16:18:53Z

+			eval.TaintAddedAt = &now
+		case !taintPresent && prevTaintPresent:
+			// Transition: Present → Absent — NRC just removed the taint.
+			eval.TaintRemovedAt = &now


Should we not borrow the taintObservedAt and taintAddedAt from prev?

Updated to handle this by carry forwarding the values

AnuragThePathak · 2026-11-03T16:38:04Z

+	// listType=atomic means the controller owns the whole slice.
+	newRules := make([]readinessv1alpha1.RuleEvaluation, 0, len(applicableRules))
+	for _, rule := range applicableRules {
+		if !rule.DeletionTimestamp.IsZero() || rule.Spec.DryRun {


Should we not also make special adjustment for bootstrap-only mode where rule is in bootstrap completed state?

Updated to handle this case.

Karthik-K-N · 2026-11-11T05:36:22Z

@AnuragThePathak Apologies for late reply, i will check and address your queries soon.

kubernetes-prow · 2026-11-11T14:53:11Z

New changes are detected. LGTM label has been removed.

kubernetes-prow · 2026-11-11T14:53:16Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Karthik-K-N
Once this PR has been reviewed and has the lgtm label, please ask for approval from ajaysundark. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

AnuragThePathak · 2026-11-12T16:55:55Z

I just checked the update @Karthik-K-N, looks fine to me except two things

When a rule is deleted, NRE doesn't react to that on the spot when there's no taint due to that rule on that node because of the way the code execution works as of now. When there's a taint, obviously rule deletion mutates the Node to remove the taint and triggers a Node update event, and hence the NRE object is also updated that way fortunately.

I think personally, an ideal design should have made the node controller listen to Rule events and worked accordingly, but because I neither did spend time actually deep diving into the NRE feature, nor was part of earlier discussions with Ajay, I'll leave that idea here only (which you may have already considered). But perhaps, may be a good idea to think about NRE update of rule deletion situation.
Please run make crd-ref-docs

Karthik-K-N · 2026-11-12T17:12:30Z

I just checked the update @Karthik-K-N, looks fine to me except two things

* When a rule is deleted, NRE doesn't react to that on the spot when there's no taint due to that rule on that node because of the way the code execution works as of now. When there's a taint, obviously rule deletion mutates the Node to remove the taint and triggers a Node update event, and hence the NRE object is also updated that way fortunately.
  I think personally, an ideal design should have made the node controller listen to Rule events and worked accordingly, but because I neither did spend time actually deep diving into the NRE feature, nor was part of earlier discussions with Ajay, I'll leave that idea here only (which you may have already considered). But perhaps, may be a good idea to think about NRE update of rule deletion situation.

* Please run `make crd-ref-docs`

Thanks for the review, I just updated the code in the latest commit to handle the NRE delete on Rule delete, Please take a look and let me know your thought on this approach. Thanks

AnuragThePathak · 2026-11-12T17:48:31Z

I can see the delete handle being updated. Should you also not regenerate the crd-ref-docs? LGTM to merge otherwise by the way.

kubernetes-prow Bot requested a review from dchen1107 August 4, 2026 08:44

kubernetes-prow Bot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Aug 4, 2026

kubernetes-prow Bot requested a review from tallclair August 4, 2026 08:44

kubernetes-prow Bot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Aug 4, 2026

alanhuangch mentioned this pull request Aug 5, 2026

[FEATURE] Add opt-in heartbeat freshness enforcement for continuous Node conditions #357

Closed

Karthik-K-N marked this pull request as draft August 5, 2026 12:18

kubernetes-prow Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 5, 2026

LarytheLord mentioned this pull request Aug 6, 2026

[FEATURE] [LFX] Headlamp plugin for node-readiness-controller #327

Open

ajaysundark self-requested a review August 8, 2026 05:24

ajaysundark reviewed Aug 9, 2026

View reviewed changes

ajaysundark mentioned this pull request Aug 14, 2026

feat: Add bootstrap NRC duration metric #294

Open

2 tasks done

ajaysundark removed request for dchen1107 and tallclair August 17, 2026 04:27

This was referenced Aug 17, 2026

✨ Add nodereadinessrulereport CRD and controller #133

Closed

⚠️ Remove per node-data from rule status #131

Closed

ajaysundark mentioned this pull request Aug 21, 2026

Changes to handle Node taint mutation only through the node controller #389

Draft

2 tasks

Karthik-K-N marked this pull request as ready for review August 21, 2026 04:35

kubernetes-prow Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 21, 2026

kubernetes-prow Bot requested review from SergeyKanzhelev and ajaysundark August 21, 2026 04:35

ajaysundark mentioned this pull request Aug 22, 2026

fix: use optimistic locking on rule status patches #343

Merged

2 tasks done

ajaysundark reviewed Aug 24, 2026

View reviewed changes

AnuragThePathak reviewed Aug 31, 2026

View reviewed changes

Karthik-K-N force-pushed the feat-nre branch 2 times, most recently from 4cdd298 to 6c00c70 Compare August 31, 2026 14:11

AnuragThePathak reviewed Sep 11, 2026

View reviewed changes

AnuragThePathak reviewed Sep 13, 2026

View reviewed changes

Karthik-K-N added 3 commits September 15, 2026 11:17

Feature: Introduce nodereadinessevaluation CRD

ddc1d02

Integrate NRE to the existing controllers

9afd469

Rename LastEvaluationTime

ebd10d3

Karthik-K-N force-pushed the feat-nre branch from 6c00c70 to 7ed55ff Compare September 15, 2026 06:36

Rebase with main and add conditionpolicy

99a1ca2

Karthik-K-N force-pushed the feat-nre branch from 7ed55ff to 99a1ca2 Compare September 15, 2026 06:42

vishnukothakapu reviewed Sep 26, 2026

View reviewed changes

illume mentioned this pull request Oct 14, 2026

docs: add headlamp plugin design document #485

Open

3 of 4 tasks

vishnukothakapu mentioned this pull request Oct 18, 2026

node-readiness-controller-0.1.0-alpha draft release notes headlamp-k8s/plugins#1370

Open

ajaysundark reviewed Oct 29, 2026

View reviewed changes

kubernetes-prow Bot assigned ajaysundark Oct 29, 2026

kubernetes-prow Bot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 29, 2026

AnuragThePathak reviewed Nov 3, 2026

View reviewed changes

Rename field to avoid breaking change

5db4453

kubernetes-prow Bot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 11, 2026

Handle NRE delete on Rule delete

b3210d0

Conversation

Karthik-K-N commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Feature Flag

Related Issue

Type of Change

Testing

Checklist

Does this PR introduce a user-facing change?

Uh oh!

netlify Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

👷 Deploy request for node-readiness-controller pending review.

Uh oh!

ajaysundark Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ajaysundark Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DsThakurRawat commented Aug 11, 2026

Uh oh!

ajaysundark commented Aug 21, 2026

Uh oh!

Karthik-K-N commented Aug 21, 2026

Uh oh!

DsThakurRawat commented Aug 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Karthik-K-N Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnuragThePathak left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vishnukothakapu left a comment

Choose a reason for hiding this comment

Karthik-K-N commented Aug 4, 2026 •

edited

Loading

netlify Bot commented Aug 4, 2026 •

edited

Loading

ajaysundark Aug 9, 2026 •

edited

Loading

ajaysundark Aug 24, 2026 •

edited

Loading

Karthik-K-N Aug 24, 2026 •

edited

Loading

Karthik-K-N Nov 11, 2026 •

edited

Loading