Skip to content
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

Merged
merged 6 commits into from
Jan 26, 2024
Merged

Support routes.*.destination of gateway for App Graph #7079

merged 6 commits into from
Jan 26, 2024

Conversation

youngbupark
Copy link

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: #7038

Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
Signed-off-by: Young Bu Park <[email protected]>
@youngbupark youngbupark requested review from a team as code owners January 26, 2024 04:31
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 {
Copy link
Author

@youngbupark youngbupark Jan 26, 2024

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 @@
[
Copy link
Author

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.

Copy link
Contributor

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 {
Copy link
Author

@youngbupark youngbupark Jan 26, 2024

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch!

Copy link
Contributor

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-tests
Copy link

radius-functional-tests bot commented Jan 26, 2024

Radius functional test overview

🔍 Go to test action run

Name Value
Repository youngbupark/radius
Commit ref c940f16
Unique ID 81a82df449
Image tag pr-81a82df449
Click here to see the list of tools in the current test run
  • gotestsum 1.10.0
  • KinD: v0.20.0
  • Dapr: 1.12.0
  • Azure KeyVault CSI driver: 1.4.2
  • Azure Workload identity webhook: 1.1.0
  • Bicep recipe location ghcr.io/radius-project/dev/test/functional/shared/recipes/<name>:pr-81a82df449
  • Terraform recipe location http://tf-module-server.radius-test-tf-module-server.svc.cluster.local/<name>.zip (in cluster)
  • applications-rp test image location: ghcr.io/radius-project/dev/applications-rp:pr-81a82df449
  • controller test image location: ghcr.io/radius-project/dev/controller:pr-81a82df449
  • ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-81a82df449
  • deployment-engine test image location: ghcr.io/radius-project/deployment-engine:latest

Test Status

⌛ Building Radius and pushing container images for functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting daprrp functional tests...
⌛ Starting msgrp functional tests...
⌛ Starting shared functional tests...
⌛ Starting samples functional tests...
⌛ Starting datastoresrp functional tests...
⌛ Starting kubernetes functional tests...
⌛ Starting ucp functional tests...
✅ datastoresrp functional tests succeeded
✅ msgrp functional tests succeeded
✅ samples functional tests succeeded
✅ daprrp functional tests succeeded
✅ kubernetes functional tests succeeded
✅ ucp functional tests succeeded
✅ shared functional tests succeeded

ytimocin
ytimocin previously approved these changes Jan 26, 2024
@@ -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 {
Copy link
Contributor

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) {
Copy link
Contributor

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?

Copy link
Author

@youngbupark youngbupark Jan 26, 2024

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-tests
Copy link

radius-functional-tests bot commented Jan 26, 2024

Radius functional test overview

🔍 Go to test action run

Name Value
Repository youngbupark/radius
Commit ref 15b2478
Unique ID 2364f63704
Image tag pr-2364f63704
Click here to see the list of tools in the current test run
  • gotestsum 1.10.0
  • KinD: v0.20.0
  • Dapr: 1.12.0
  • Azure KeyVault CSI driver: 1.4.2
  • Azure Workload identity webhook: 1.1.0
  • Bicep recipe location ghcr.io/radius-project/dev/test/functional/shared/recipes/<name>:pr-2364f63704
  • Terraform recipe location http://tf-module-server.radius-test-tf-module-server.svc.cluster.local/<name>.zip (in cluster)
  • applications-rp test image location: ghcr.io/radius-project/dev/applications-rp:pr-2364f63704
  • controller test image location: ghcr.io/radius-project/dev/controller:pr-2364f63704
  • ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-2364f63704
  • deployment-engine test image location: ghcr.io/radius-project/deployment-engine:latest

Test Status

⌛ Building Radius and pushing container images for functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting shared functional tests...
⌛ Starting msgrp functional tests...
⌛ Starting samples functional tests...
⌛ Starting datastoresrp functional tests...
⌛ Starting kubernetes functional tests...
⌛ Starting ucp functional tests...
⌛ Starting daprrp functional tests...
✅ datastoresrp functional tests succeeded
✅ msgrp functional tests succeeded
✅ kubernetes functional tests succeeded
✅ samples functional tests succeeded
✅ ucp functional tests succeeded
✅ daprrp functional tests succeeded
✅ shared functional tests succeeded

// 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 {
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Author

@youngbupark youngbupark Jan 26, 2024

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.

Copy link
Contributor

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))
Copy link
Contributor

@rynowak rynowak Jan 26, 2024

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.

Copy link
Contributor

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.

Copy link
Author

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.

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

Copy link
Contributor

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.

@youngbupark youngbupark merged commit c262df7 into radius-project:main Jan 26, 2024
16 checks passed
@youngbupark youngbupark deleted the youngp/support-gateway branch January 26, 2024 18:13
willdavsmith pushed a commit to willdavsmith/radius that referenced this pull request Jan 26, 2024
…#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]>
sk593 pushed a commit to sk593/radius that referenced this pull request Jan 29, 2024
…#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]>
willdavsmith pushed a commit to willdavsmith/radius that referenced this pull request Mar 4, 2024
…#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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Application graph] data doesnt reflect correctly in graph for some data
3 participants