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

[Dashboard] [Serve] Add application row with dropdown for deployment rows #43506

Merged

Conversation

architkulkarni
Copy link
Contributor

@architkulkarni architkulkarni commented Feb 28, 2024

Why are these changes needed?

Adds back "application" rows to the top-level deployments page, which were removed in #42079. We keep the deployment rows as a dropdown under the application row, similar to how worker rows are a dropdown under node rows in the "Cluster" page (and we mimic the implementation from that part as well).

Per discussion offline:

  • Delete the "filters" component because it's not necessary for most use cases, and the user can always cmd-F to find in page if necessary
  • Start all the rows expanded
  • Replace the "deployments status" chip with "application status". If there's time, we can try to include both by making the metadata section number of columns configurable and set it to 4 instead of 3.

I also took a couple liberties which hadn't been discussed yet, but happy to revert them if they don't make sense:

  1. Un-bold the the deployment name, but keep the application name bold. This highlights the hierarchical nature and makes the "deployment" rows more visually distinct from the "application" rows.
  2. Make the number of replicas link to the deployment page where it shows the replicas. Reason: when I first saw "2" under replicas my first thought was "where can I see more about these 2 replicas", and I naturally wanted to click it.

TODO before merge:

  • Fix pagination calculation
  • Fix lint
  • Fix dashboard tests
  • (If time) configure num_columns for metadata section
Screenshot 2024-02-28 at 10 16 30 AM Screenshot 2024-02-28 at 10 17 19 AM

Related issue number

Closes #43350

Checks

  • I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
    • I've added any new APIs to the API Reference. For example, if I added a
      method in Tune, I've added it in doc/source/tune/api/ under the
      corresponding .rst file.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

Signed-off-by: Archit Kulkarni <[email protected]>
Signed-off-by: Archit Kulkarni <[email protected]>
Signed-off-by: Archit Kulkarni <[email protected]>
application={deployment.application}
.map((application) => (
<ServeApplicationRows
key={`${application.name}__${application.deployments.length}`}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not confident about this key. @alanwguo what would you recommend? Does it make sense to use deployments.length here to cause some kind of refresh if the number of deployments changes?

Copy link
Contributor

Choose a reason for hiding this comment

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

You should only use application name here.

key is not used to determine if something needs to refresh or not. React determines it if any of the properties that are passed in changes. key is only used to see if components can be re-used across renders. React can easily determine whether to re-use components if the number of components is static, but when it's dynamic like in a list, react struggles and key is used as a hint to tell react which components can be re-used.

If a component is not re-used, it is unmounted and a new component is mounted with the updated props.

If a component is re-used, the component does not get unmounted, but the new props do get passed into the component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, fixed be06ee8

}}
/>
<Pagination
count={Math.ceil(serveDeployments.length / page.pageSize)}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The pagination logic needs to be fixed before we merge. Right now it's calculating the count based on the number of deployments, but below we're using it to slice the Applications array.

One option is to get rid of the page component entirely. Another option is to somehow incorporate the total number of deployments and application rows into the page calculation. The thing to be careful about is we can't split a single application and its dropdown deployments across multiple pages.

Apart from that, this is ready for review @alanwguo @scottsun94. Feel free to suggest other reviewers as well

Copy link
Contributor

Choose a reason for hiding this comment

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

let's just show this as the count of applications instead of deployments. We'll paginate based on application.

The hope is that most applications won't have a huge amount of deployments.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to paginate based on application for now

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good. Fixed 4a7d868

Comment on lines 49 to 50
applicationName: name,
application: application,
Copy link
Contributor

Choose a reason for hiding this comment

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

do we still need these properties. I think since we removed the application column, we might be able to get rid of this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call, we don't need it all because this part of the code is scoped to a single application. Fixed fdf617b

Comment on lines +91 to +92
{/* placeholder for num_replicas, which does not apply to an application */}
-
Copy link
Contributor

Choose a reason for hiding this comment

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

let's instead calculate the total number of replicas from all the deployments in this application.

@scottsun94 @edoakes wdyt? On one hand it makes sense logically to do this, but one thing I wonder if people might get confused and think the application concept can have replicas

Copy link
Contributor

Choose a reason for hiding this comment

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

We can start without showing it? If people ask for it, we can add

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 ^ I think it'll probably be more confusing than anything

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll leave it out for now.

@@ -24,12 +24,10 @@ import { useViewServeDeploymentMetricsButtonUrl } from "./ServeDeploymentMetrics
const useStyles = makeStyles((theme) =>
createStyles({
deploymentName: {
fontWeight: 500,
fontWeight: 400,
Copy link
Contributor

Choose a reason for hiding this comment

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

good idea

deployment: ServeDeployment;
application: ServeApplication;
// Optional prop to control the visibility of the first column.
// This is used to display an expand/collapse button on the applications page, but not the deployment page.
showFirstColumn?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
showFirstColumn?: boolean;
showExpandColumn?: boolean;

nit

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed adaf486

application: { last_deployed_time_s, name: applicationName, route_prefix },
}: ServeDeployentRowProps) => {
application: { last_deployed_time_s, name: applicationName },
showFirstColumn = true
Copy link
Contributor

Choose a reason for hiding this comment

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

let's make default be false for booleans. This is the more expected behavior for component optional props.

If we want showing first column to be the default behavior, we should rename the property hideFirstColumn

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, good to know. Made the default false 6f8c0e3

>
{applicationName}
</Link>
{/* placeholder for route_prefix, which does not apply to a deployment */}
Copy link
Contributor

Choose a reason for hiding this comment

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

let's add - to represent "no value"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed 5fe1366

}}
/>
<Pagination
count={Math.ceil(serveDeployments.length / page.pageSize)}
Copy link
Contributor

Choose a reason for hiding this comment

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

let's just show this as the count of applications instead of deployments. We'll paginate based on application.

The hope is that most applications won't have a huge amount of deployments.

application={deployment.application}
.map((application) => (
<ServeApplicationRows
key={`${application.name}__${application.deployments.length}`}
Copy link
Contributor

Choose a reason for hiding this comment

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

You should only use application name here.

key is not used to determine if something needs to refresh or not. React determines it if any of the properties that are passed in changes. key is only used to see if components can be re-used across renders. React can easily determine whether to re-use components if the number of components is static, but when it's dynamic like in a list, react struggles and key is used as a hint to tell react which components can be re-used.

If a component is not re-used, it is unmounted and a new component is mounted with the updated props.

If a component is re-used, the component does not get unmounted, but the new props do get passed into the component.

@scottsun94
Copy link
Contributor

LGTM. Left a minor comment.

Copy link
Contributor

@alanwguo alanwguo left a comment

Choose a reason for hiding this comment

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

awesome work!

key={`${application.name}-${deployment.name}`}
deployment={deployment}
application={application}
showExpandColumn={true}
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: with react components, instead of sending in ={true} you can just do <Component showExpandColumn />.

This is also the reason why dropping the showExpandColumn should default the value to false.

Copy link
Contributor Author

@architkulkarni architkulkarni Feb 28, 2024

Choose a reason for hiding this comment

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

Thanks, good to know! Fixed bd1b086

<ServeApplicationRows
key={`${application.name}`}
application={application}
startExpanded={true}
Copy link
Contributor

Choose a reason for hiding this comment

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

same nit

Copy link
Contributor Author

@architkulkarni architkulkarni Feb 28, 2024

Choose a reason for hiding this comment

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

Fixed bd1b086

@architkulkarni architkulkarni merged commit 9e419f4 into ray-project:master Feb 29, 2024
9 checks passed
hebiao064 pushed a commit to hebiao064/ray that referenced this pull request Mar 12, 2024
…rows (ray-project#43506)

Adds back "application" rows to the top-level deployments page, which were removed in ray-project#42079. We keep the deployment rows as a dropdown under the application row, similar to how worker rows are a dropdown under node rows in the "Cluster" page (and we mimic the implementation from that part as well).

Per discussion offline:

Delete the "filters" component because it's not necessary for most use cases, and the user can always cmd-F to find in page if necessary
Start all the rows expanded
Replace the "deployments status" chip with "application status". If there's time, we can try to include both by making the metadata section number of columns configurable and set it to 4 instead of 3.
I also took a couple liberties which hadn't been discussed yet, but happy to revert them if they don't make sense:

Un-bold the the deployment name, but keep the application name bold. This highlights the hierarchical nature and makes the "deployment" rows more visually distinct from the "application" rows.
Make the number of replicas link to the deployment page where it shows the replicas. Reason: when I first saw "2" under replicas my first thought was "where can I see more about these 2 replicas", and I naturally wanted to click it.
---------

Signed-off-by: Archit Kulkarni <[email protected]>
Co-authored-by: Huaiwei Sun <[email protected]>
ryanaoleary pushed a commit to ryanaoleary/ray that referenced this pull request Jun 7, 2024
…rows (ray-project#43506)

Adds back "application" rows to the top-level deployments page, which were removed in ray-project#42079. We keep the deployment rows as a dropdown under the application row, similar to how worker rows are a dropdown under node rows in the "Cluster" page (and we mimic the implementation from that part as well).

Per discussion offline:

Delete the "filters" component because it's not necessary for most use cases, and the user can always cmd-F to find in page if necessary
Start all the rows expanded
Replace the "deployments status" chip with "application status". If there's time, we can try to include both by making the metadata section number of columns configurable and set it to 4 instead of 3.
I also took a couple liberties which hadn't been discussed yet, but happy to revert them if they don't make sense:

Un-bold the the deployment name, but keep the application name bold. This highlights the hierarchical nature and makes the "deployment" rows more visually distinct from the "application" rows.
Make the number of replicas link to the deployment page where it shows the replicas. Reason: when I first saw "2" under replicas my first thought was "where can I see more about these 2 replicas", and I naturally wanted to click it.
---------

Signed-off-by: Archit Kulkarni <[email protected]>
Co-authored-by: Huaiwei Sun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make Ray Dashboard serve page show both applications and deployments at the top level
4 participants