-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
[Dashboard] [Serve] Add application row with dropdown for deployment rows #43506
Conversation
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
application={deployment.application} | ||
.map((application) => ( | ||
<ServeApplicationRows | ||
key={`${application.name}__${application.deployments.length}`} |
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 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?
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.
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.
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.
Thanks, fixed be06ee8
}} | ||
/> | ||
<Pagination | ||
count={Math.ceil(serveDeployments.length / page.pageSize)} |
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.
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
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.
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.
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.
+1 to paginate based on application for 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.
Sounds good. Fixed 4a7d868
…e-app-row-dashboard Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
applicationName: name, | ||
application: application, |
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.
do we still need these properties. I think since we removed the application column, we might be able to get rid of 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.
Good call, we don't need it all because this part of the code is scoped to a single application. Fixed fdf617b
{/* placeholder for num_replicas, which does not apply to an application */} | ||
- |
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.
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
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 can start without showing it? If people ask for it, we can add
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.
+1 ^ I think it'll probably be more confusing than anything
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'll leave it out for now.
@@ -24,12 +24,10 @@ import { useViewServeDeploymentMetricsButtonUrl } from "./ServeDeploymentMetrics | |||
const useStyles = makeStyles((theme) => | |||
createStyles({ | |||
deploymentName: { | |||
fontWeight: 500, | |||
fontWeight: 400, |
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.
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; |
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.
showFirstColumn?: boolean; | |
showExpandColumn?: boolean; |
nit
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.
Fixed adaf486
application: { last_deployed_time_s, name: applicationName, route_prefix }, | ||
}: ServeDeployentRowProps) => { | ||
application: { last_deployed_time_s, name: applicationName }, | ||
showFirstColumn = true |
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.
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
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.
Thanks, good to know. Made the default false 6f8c0e3
> | ||
{applicationName} | ||
</Link> | ||
{/* placeholder for route_prefix, which does not apply to a deployment */} |
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.
let's add -
to represent "no value"
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.
Fixed 5fe1366
}} | ||
/> | ||
<Pagination | ||
count={Math.ceil(serveDeployments.length / page.pageSize)} |
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.
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}`} |
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.
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.
LGTM. Left a minor comment. |
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Co-authored-by: Huaiwei Sun <scottsun94@gmail.com> Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
…lkarni/ray into serve-app-row-dashboard Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
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.
awesome work!
key={`${application.name}-${deployment.name}`} | ||
deployment={deployment} | ||
application={application} | ||
showExpandColumn={true} |
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.
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.
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.
Thanks, good to know! Fixed bd1b086
<ServeApplicationRows | ||
key={`${application.name}`} | ||
application={application} | ||
startExpanded={true} |
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.
same nit
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.
Fixed bd1b086
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
…tests Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
Signed-off-by: Archit Kulkarni <architkulkarni@users.noreply.github.com>
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:
I also took a couple liberties which hadn't been discussed yet, but happy to revert them if they don't make sense:
TODO before merge:
Related issue number
Closes #43350
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.