-
Notifications
You must be signed in to change notification settings - Fork 97
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
Support routes.*.destination of gateway for App Graph #7079
Support routes.*.destination of gateway for App Graph #7079
Conversation
Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
// to other resources like databases. Conversely if the resource is a database then this function | ||
// will not find any connections (because they are inbound). Inbound connections are processed later. | ||
func connectionsFromAPIData(resource generated.GenericResource, allResources []generated.GenericResource) []*corerpv20231001preview.ApplicationGraphConnection { | ||
func resolveConnections(resource generated.GenericResource, jsonRefPath string, converter func(any) (string, corerpv20231001preview.Direction, error)) []*corerpv20231001preview.ApplicationGraphConnection { |
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 refactored the code to simplify the code for resolving connections, routes, and provides instead of repeating the same code multiple times.
@@ -0,0 +1,53 @@ | |||
[ |
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.
@nithyatsu @rynowak Please review this appgraph output carefully. To me, the result makes sense.
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.
Looks right to me 👍
@@ -356,8 +361,8 @@ func computeGraph(applicationName string, applicationResources []generated.Gener | |||
connectionsIn := connectionsByDestination[id] | |||
|
|||
entryConnections := make([]*corerpv20231001preview.ApplicationGraphConnection, len(connectionsIn)) | |||
for i, conn := range connectionsIn { |
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 is the code bug. &conn
refered to the same variable so that entryConnections array held the same pointer values.
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.
Great catch!
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.
Ugh.
The good news is that they are fixing this: golang/go#60078
I wasn't able to find the link, but we can use the Go compiler to detect these cases.
Radius functional test overview
Click here to see the list of tools in the current test run
Test Status⌛ Building Radius and pushing container images for functional tests... |
@@ -356,8 +361,8 @@ func computeGraph(applicationName string, applicationResources []generated.Gener | |||
connectionsIn := connectionsByDestination[id] | |||
|
|||
entryConnections := make([]*corerpv20231001preview.ApplicationGraphConnection, len(connectionsIn)) | |||
for i, conn := range connectionsIn { |
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.
Great catch!
// Not found, this is fine. | ||
return []*corerpv20231001preview.ApplicationGraphConnection{} | ||
func routesPathConverter(resources []generated.GenericResource) func(any) (string, corerpv20231001preview.Direction, error) { | ||
return func(item any) (string, corerpv20231001preview.Direction, error) { |
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't we have one function for all three and just pass in the resource type?
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't we have one function for all three and just pass in the resource type?
That way makes more complicated and each one has different logic for scanning resource. it is not worth.
Signed-off-by: Young Bu Park <[email protected]>
Radius functional test overview
Click here to see the list of tools in the current test run
Test Status⌛ Building Radius and pushing container images for functional tests... |
// For example if the resource is an 'Applications.Core/container' then this function can find it's connections | ||
// to other resources like databases. Conversely if the resource is a database then this function | ||
// will not find any connections (because they are inbound). Inbound connections are processed later. | ||
func connectionsResolver(resources []generated.GenericResource) resolver { |
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.
Not relevant for this review, but long term I'd like to make this behavior consistent across APIs by using Capabilities + Well-Known API shapes, or Well-Known Child resources.
Consider how we'd make this extensible 👍 When users can define their own types, they should be able to support all of the features of the built-in ones.
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.
Basically anyplace we write code that handles a specific resource type like Applications.Core/gateways
, we might need to reconsider in the future.
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 intentionally didn't try to refactor it further to keep this change short. Instead of strongly typed one, I would try to use jsonpointer to look up the connections.destination
. So, we can support multiple types. Also for custom resource, we can ask contributors to use the specific connection properties if they want to use appgraph. If you like this idea, I can make the change now.
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 don't think we should change it now - we should discuss during the design of user-defined-types. I just wanted to mention the idea.
connections := connectionsFromAPIData(resource, resources) // Outbound connections based on 'connections' | ||
connections = append(connections, providesFromAPIData(resource)...) // Inbound connections based on 'provides' | ||
// Resolve Outbound connections based on 'connections'. | ||
connections := resolveConnections(resource, connectionsPath, connectionsResolver(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.
Should we be checking the resource type here? It looks like all of these "resolvers" apply to all resource types. So if a resource has a property .properties.connections
this code assumes it works like Applications.Core/containers
, has the same schema, etc.
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 is similar to the design I was talking about here: https://github.com/radius-project/radius/pull/7079/files#r1467935133 but without being driven by Capabilities.
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.
Should we be checking the resource type here? It looks like all of these "resolvers" apply to all resource types. So if a resource has a property
.properties.connections
this code assumes it works likeApplications.Core/containers
, has the same schema, etc.
The original code didn't check the type. I was thinking that the original one might want to support multiple resource types which have the connection properties. So I didn't check the resource type as is. We can discuss it later when we work further for https://github.com/radius-project/radius/pull/7079/files#r1467935133
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'm good with this for now 👍 we will revisit when we do extensibility.
…#7079) # Description This is to support `routes.*.destination` property for App graph. It enables to show the connections between Gateway and the other resources in App Graph ## Type of change - This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional). Fixes: radius-project#7038 --------- Signed-off-by: Young Bu Park <[email protected]>
…#7079) # Description This is to support `routes.*.destination` property for App graph. It enables to show the connections between Gateway and the other resources in App Graph ## Type of change - This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional). Fixes: radius-project#7038 --------- Signed-off-by: Young Bu Park <[email protected]> Signed-off-by: sk593 <[email protected]>
…#7079) # Description This is to support `routes.*.destination` property for App graph. It enables to show the connections between Gateway and the other resources in App Graph ## Type of change - This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional). Fixes: radius-project#7038 --------- Signed-off-by: Young Bu Park <[email protected]>
Description
This is to support
routes.*.destination
property for App graph. It enables to show the connections between Gateway and the other resources in App GraphType of change
Fixes: #7038