-
Notifications
You must be signed in to change notification settings - Fork 590
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
[WIP] feat: add constructor for full event lineage graph #7921
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Calum Murray <cmurray@redhat.com>
/cc @pierDipi |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cali0707 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 |
This is WIP because I want feedback on the approach before adding unit tests |
Signed-off-by: Calum Murray <cmurray@redhat.com>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7921 +/- ##
==========================================
- Coverage 67.87% 67.04% -0.83%
==========================================
Files 368 368
Lines 17551 17777 +226
==========================================
+ Hits 11912 11918 +6
- Misses 4894 5113 +219
- Partials 745 746 +1 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
|
||
g := NewGraph() | ||
|
||
for _, ns := range config.Namespaces { |
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 Backstage backend, we fetch brokers for all namespaces. It is a readonly view, so, should be fine.
We might add a config option in Backstage backend to consider specific namespaces.
However, there's still a need to fetch all brokers, all triggers, etc.
That can't be done by fetching all namespaces and then iterating over them though.
We should use brokers, err := clientset.EventingV1().Brokers(metav1.NamespaceAll).List(context.Background(), metav1.ListOptions{})
.
Can we add a config option for this?
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.
I was thinking for this you could just provide metav1.NamespaceAll
as the only namespace in the config list. Would that work?
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.
I think it would...
We might then need add a validation in the code to check if the list of namespaces contain "metav1.NamespaceAll" and if so, it should not have anything else.
pkg/graph/constructor.go
Outdated
if err != nil && !apierrs.IsNotFound(err) && !apierrs.IsUnauthorized(err) && !apierrs.IsForbidden(err) { | ||
return nil, err | ||
} |
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.
We should log with info/warn in case of apierrs.IsUnauthorized(err)
or apierrs.IsForbidden(err)
Signed-off-by: Calum Murray <cmurray@redhat.com>
pkg/graph/constructor.go
Outdated
ShouldAddBroker func(b eventingv1.Broker) bool | ||
ShouldAddChannel func(c messagingv1.Channel) bool | ||
ShouldAddSource func(s duckv1.Source) bool | ||
ShouldAddTrigger func(t eventingv1.Trigger) bool | ||
ShouldAddSubscription func(s messagingv1.Subscription) bool | ||
ShouldAddEventType func(et eventingv1beta3.EventType) bool |
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.
These are nice, but the resources are fetched anyway. If I am not interested in channels, that shouldn't be fetched at all.
Can you create separate entries like fetchBrokers
, etc defaulting to true?
pkg/graph/constructor.go
Outdated
if err != nil { | ||
return nil, fmt.Errorf("unable to list source CRDs: %w", err) | ||
} |
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.
This returns error in case of 404 (when there are no source CRDs)
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.
Another thing, in case of 404s or Auth issues when fetching resources other than sources, we write a Warn log and continue. It might be nice to be more consistent.
|
||
return g, nil | ||
} | ||
|
||
func (g *Graph) AddBroker(broker eventingv1.Broker) { |
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.
Can we actually embed the full broker resource in the graph here? Or make it a config option?
Because, for example in the Backstage backend, if I only have references, I will need to fetch the brokers again. But, we have the full resource here fetched anyway.
Kind of irrelevant for this PR, but it would be super nice if we have a
|
/cc @aliok |
Yeah 100%, I thought about this too but I wasn't sure how to show a vertex with an arbitrary number of edges using just strings... |
I added stringer impls for types now. It is ok-ish. Example:
|
Say we have an EventType: kind: EventType
metadata:
name: test-event-type
namespace: default
spec:
reference:
apiVersion: eventing.knative.dev/v1
kind: Broker
name: test-broker Currently the graph is constructed in a way that there is an edge from ET to Broker. I think it should be the other way around. Events of EventType is coming out of broker. cc @pierDipi |
|
||
v.AddEdge(to, dest, NoTransform{}, true) | ||
} | ||
|
||
func (g *Graph) AddEventType(et *eventingv1beta3.EventType) error { | ||
func (g *Graph) AddEventType(et eventingv1beta3.EventType) error { | ||
ref := &duckv1.KReference{ | ||
Name: et.Name, | ||
Namespace: et.Namespace, |
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.
Below this line, we have a APIVersion: "eventing.knative.dev/v1beta3"
.
This v1beta3
information is probably needed for this case for using as a map key. Group (eventing.k.d
) should be enough, as there can't be another resource with the same name and group, but in a different version.
Ignoring the version can make things easier. Would we lose important information to be provided to the clients of this library?
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.
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.
My only concern here is that if we get rid of the version, it might make it harder for clients of the library to understand what type to cast the interface{}
value we are storing with the object to...
for 3 entries, it was creating an array of 6 Signed-off-by: Ali Ok <aliok@redhat.com>
Signed-off-by: Calum Murray <cmurray@redhat.com>
Signed-off-by: Ali Ok <aliok@redhat.com>
Signed-off-by: Ali Ok <aliok@redhat.com>
Signed-off-by: Ali Ok <aliok@redhat.com>
192021c
to
d60a069
Compare
@Cali0707: The following test failed, say
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Fixes #7694
Proposed Changes