Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Handle update events with old resources#1736

Unanswered
rivamarco asked this question inQ&A
Jan 26, 2023· 3 comments· 4 replies
Discussion options

Hi everyone,

I'm trying to implement a system that is able to react to events in order to perform some operations.

I have started asking thisfabric8io/kubernetes-client#4789 because I had troubles if some connection issues / not responsive kubernetes API, and i think it can be also related to this:fabric8io/kubernetes-client#4781

Given that, I'm trying a different approaches and I've tried also to implement a "little" operator.

Seems all ok and it seems also more robust on lack of connection but the "issue" is that I don't know how (or if it's possible) to retrieve the old and the new resources on updates, basically similar to this:

class SimpleHandler extends ResourceEventHandler[Pod] {  override def onAdd(obj: Pod): Unit                                       = println("ADD")  override def onUpdate(oldObj: Pod, newObj: Pod): Unit                    = println("UPDATE")  override def onDelete(obj: Pod, deletedFinalStateUnknown: Boolean): Unit = println("DELETE")}

What I wrote is like this:

@ControllerConfigurationclass CRDExample extends Reconciler[MyCRD] with EventSourceInitializer[MyCRD] {  override def reconcile(resource: MyCRD, context: Context[MyCRD]): UpdateControl[MyCRD] = {    println(s"UPDATE ${resource.getStatus}")    UpdateControl.noUpdate()  }  override def prepareEventSources(context: EventSourceContext[MyCRD]): util.Map[String, EventSource] = {    val informerConfiguration = InformerConfiguration.from(classOf[MyCRD], context).build()    val informerEventSource   = new InformerEventSource[MyCRD, MyCRD](informerConfiguration, context)    EventSourceInitializer.nameEventSources(informerEventSource)  }}

But in this case I only have the "latest" resource, and not the previous one so I can't compare the status value in order to react to such events.

Am I doing the right thing or should i do something else?

Thank you very much for the big help! 😄

You must be logged in to vote

Replies: 3 comments 4 replies

Comment options

Hi@rivamarco pls take a look on this:
https://javaoperatorsdk.io/docs/faq#q-how-can-i-access-the-events-which-triggered-the-reconciliation

events are not there on purpose.

You must be logged in to vote
0 replies
Comment options

Out of curiosity, where is the first example coming from?

You must be logged in to vote
2 replies
@csviri
Comment options

That is the API of the informer event handler

@metacosm
Comment options

D'oh! 🤦🏼

Comment options

I had troubles if some connection issues / not responsive kubernetes API, and i think it can be also related to this:fabric8io/kubernetes-client#4781

note that this issue only happens after a while, and it's quite rare. Was not reported by other users of JOSDK.

What version of K8S are you using?

You must be logged in to vote
2 replies
@rivamarco
Comment options

Yes I wrote that just to give more context, the issue happened with fabric8 and not with JOSDK, that works well with reconnection but as you said I don't have access to "complete" events, so I can write the same code unfortunately.

And yes, it happens after a while and rarely but I would like if possibile to have a more bullet proof code in order to don't miss events that are important.

Anyway, k8s version is 1.23.5 for now

@csviri
Comment options

So just to clarify, it is not that case, that you would note receive an event if something changed. It can happen however that there were multiple events and you just receive the last one (still containing the latest resource). IMO it is impossible now to have all the events in all cases guaranteed. But that is why Kubernetes reconciliations are level based.

If your logic really depends on events and diffs that is kinda smell, but there are some usecases that might require that. At least heard before. Pls take a look on this issue:
#1727

Note this discussion on k8s slack:https://kubernetes.slack.com/archives/C0EG7JC6T/p1673376066590699

Basically there can be an additional periodic listing, however that won't assure that you don't miss an event in some case either.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
3 participants
@rivamarco@metacosm@csviri
[8]ページ先頭
©2009-2025 Movatter.jp