-
Notifications
You must be signed in to change notification settings - Fork 267
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
Converting the management cluster list and detail pages to be paginated #13170
base: master
Are you sure you want to change the base?
Conversation
4046f35
to
eb5daa5
Compare
@@ -283,97 +178,8 @@ export default { | |||
return info; | |||
}, | |||
|
|||
fakeMachines() { |
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 haven't seen the behavior described in the comment. It appears were able to scale up and down and the machines/machine pools sync properly without all of these extra hoops.
@@ -243,15 +138,15 @@ export default { | |||
}; | |||
}, | |||
|
|||
watch: { | |||
showNodes(neu) { |
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'll need this anymore especially with the new socket code.
if ( this.$store.getters['management/canList'](MANAGEMENT.NODE_TEMPLATE) ) { | ||
fetchTwo.nodeTemplates = this.$store.dispatch('management/findAll', { type: MANAGEMENT.NODE_TEMPLATE }); | ||
} | ||
this.clusterToken = await this.value.getOrCreateToken(); |
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 can prolly await on both this and the hasLocalCluster to speed things up slightly.
* This class allows us to fake a machine deployment - when created, we set additional properties (_cluster etc) | ||
* and use these in the getters. | ||
**/ | ||
class EmptyCapiMachineDeployment extends CapiMachineDeployment { |
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.
No longer used without the machinepool finagling.
@@ -691,26 +543,6 @@ export default { | |||
return day(time).format(this.dateTimeFormatStr); | |||
} | |||
}, | |||
|
|||
machineSortGenerationFn() { |
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 appears to only be necessary if we have the fake machines and nodes but neither appear to be necessary.
@@ -745,33 +577,22 @@ export default { | |||
@update:value="$emit('input', $event)" | |||
> | |||
<Tab | |||
v-if="showMachines" | |||
v-if="showMachines || 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.
This will be removed. Accidentally left this in.
return filterHiddenLocalCluster(this.rows, this.$store); | ||
// We no longer make the request for rows the paginated table does. We still need to access these rows for things like harvester. | ||
filteredRows() { | ||
return this.$refs.paginatedTable?.filteredRows || []; |
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.
Any thoughts on a better way to do this? I don't quite thing getters get us there unless we want to duplicate the filtering.
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 need to have a way to get the uses of rows and filteredRowes working in both local pagination and SSP.
SSP
rows & hiddenHarvesterCount - we can get row counts from the counts
object, we might need to make a specific http request to get the other count though (pageSize=1&filter=xyz)
rows & tokenExpiredData - i think we'll need to remove this feature with SSP on.
filteredRows & nonStandardNamespaces - this would need to be another http request
local pagination
i think maybe we continue with the code in the PR
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 actually need to change anything for hiddenHarvesterCount
and tokenExpiredData
?
Does harvester support SSP? Also, Is tokenExpiredData
Harvester specific? I don't see the banner label keys in our translations. Will SSP for Harvester be supported before the Harvester specific code is removed from shell?
I disabled it for nonStandardNamespaces
.
shell/utils/pagination-utils.ts
Outdated
if (setting.resource === enabledFor.resource?.id) { | ||
if (!!setting.context) { | ||
return enabledFor.resource?.context ? setting.context.includes(enabledFor.resource.context) : 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.
It's not obvious to me why this is necessary? It seems to cause problems if you want to use the PaginatedResourceTable on non-list pages.
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 whole block needs to stay.
if (setting.resource === enabledFor.resource?.id) {
- used to ensure the correct entry is found
if (!!setting.context) {
- the context was used to explictely block pagination outside of supported areas. For instance the prov cluster was only allowed in the side nav and home page and not the cluster management list
shell/utils/settings.ts
Outdated
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('provisioning.cattle.io.cluster'); | ||
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('cluster'); | ||
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('rke.cattle.io.etcdsnapshot'); |
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.
Temporary to allow paginated requests
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 theory the three above shouldn't change anything as they're in the cluster
store rather than management
.
to get these without code changes, and fix the prov and mgmt cluster contexts (which are now not needed) shell/config/settings.ts
serverPagination
can be updated and then the new button Populate with latest pagination defaults
can be used (and then applied). That process will soon be greatly updated (i have a PR, but it's in flux)
25db9c0
to
827d555
Compare
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.
It doesn't look like the list currently makes SSP requests. I fixed this by comment in shell/utils/settings.ts file.
Once enabled there were failed http calls to secondary resources given the filter wasn't supported by certain type (this is expected, added inline comment). i commented those filters out and the list shows however as there's no configured pagination the columns come from the schema attribute columns rather than matching what was there before. there's a fair few examples on how the pagination headers can be setup in the explorer product
shell/utils/pagination-utils.ts
Outdated
if (setting.resource === enabledFor.resource?.id) { | ||
if (!!setting.context) { | ||
return enabledFor.resource?.context ? setting.context.includes(enabledFor.resource.context) : 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.
This whole block needs to stay.
if (setting.resource === enabledFor.resource?.id) {
- used to ensure the correct entry is found
if (!!setting.context) {
- the context was used to explictely block pagination outside of supported areas. For instance the prov cluster was only allowed in the side nav and home page and not the cluster management list
shell/utils/settings.ts
Outdated
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('provisioning.cattle.io.cluster'); | ||
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('cluster'); | ||
r.serverPagination.stores.cluster.resources.enableSome.enabled.push('rke.cattle.io.etcdsnapshot'); |
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 theory the three above shouldn't change anything as they're in the cluster
store rather than management
.
to get these without code changes, and fix the prov and mgmt cluster contexts (which are now not needed) shell/config/settings.ts
serverPagination
can be updated and then the new button Populate with latest pagination defaults
can be used (and then applied). That process will soon be greatly updated (i have a PR, but it's in flux)
|
||
if (this.$store.getters[`management/paginationEnabled`]?.(args)) { | ||
const templateOpt = PaginationParamFilter.createMultipleFields([{ | ||
field: 'spec.clusterName', |
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 reference, and snapshot and machine deployments need adding to StevePaginationUtils.VALID_FIELDS and then also to rancher/rancher#48603
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.
Done for both
46cc4bc
to
752a239
Compare
Yeah, I really don't know what happened there. Anyway, it should be working now. |
I put this back in. I think it might be nice if we add dev warnings so it's a little more obvious why some resources aren't using the pagination API |
@@ -143,6 +143,21 @@ export default { | |||
} | |||
}, | |||
|
|||
async findPageOrAll(ctx, { |
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.
Is there an existing alternative to 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.
Interesting point. I've just used findPage when fetching secondary resources.
We can switch to this approach though
752a239
to
3259fb7
Compare
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's an error in console
Error in fetch(): TypeError: Cannot read properties of null (reading 'fields')
at steve-pagination-utils.ts:433:1
one of the filter values is null
. there'll be a bug somewhere, probably somewhere generic. let me know if you want me to track it down.
With latest head
i'm seeing an error when a filter is used ("unrecognized operator: ",
). Will check with the BE team
shell/config/settings.ts
Outdated
@@ -278,8 +278,10 @@ export const DEFAULT_PERF_SETTING: PerfSettings = { | |||
enableAll: false, | |||
enableSome: { | |||
enabled: [ | |||
{ resource: CAPI.RANCHER_CLUSTER, context: ['home', 'side-bar'] }, | |||
{ resource: CAPI.RANCHER_CLUSTER, context: ['home', 'side-bar', 'provisioning.cattle.io.clusters'] }, |
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 now be able to remove both home and side-bar contexts.
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 removed it but I know I needed it for my current version of rancher. I haven't tried the latest since we had that sort issue you pointed out.
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.
interesting. there's the filter issue in latest rancher. lets take a look at this once that's fixed (waiting on steve bump, though delayed a bit because i asked for rancher/rancher#48603 at same time)
shell/config/settings.ts
Outdated
{ resource: MANAGEMENT.CLUSTER, context: ['side-bar'] }, | ||
{ resource: CAPI.MACHINE, context: ['provisioning.cattle.io.clusters', 'provisioning.cattle.io.cluster'] }, |
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 two context entries here should be safe to remove (and from below 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.
I removed it but I know I needed it for my current version of rancher. I haven't tried the latest since we had that sort issue you pointed out.
return filterHiddenLocalCluster(this.rows, this.$store); | ||
// We no longer make the request for rows the paginated table does. We still need to access these rows for things like harvester. | ||
filteredRows() { | ||
return this.$refs.paginatedTable?.filteredRows || []; |
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 need to have a way to get the uses of rows and filteredRowes working in both local pagination and SSP.
SSP
rows & hiddenHarvesterCount - we can get row counts from the counts
object, we might need to make a specific http request to get the other count though (pageSize=1&filter=xyz)
rows & tokenExpiredData - i think we'll need to remove this feature with SSP on.
filteredRows & nonStandardNamespaces - this would need to be another http request
local pagination
i think maybe we continue with the code in the PR
@@ -143,6 +143,21 @@ export default { | |||
} | |||
}, | |||
|
|||
async findPageOrAll(ctx, { |
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.
Interesting point. I've just used findPage when fetching secondary resources.
We can switch to this approach though
@@ -143,6 +143,21 @@ export default { | |||
} | |||
}, | |||
|
|||
async findPageOrAll(ctx, { | |||
type, context, paginatedOpt, findAllOpt |
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 that findAllOpts isn't supplied where this is used.
however we should be safe just chopping out the pagination object and using the paginatedOpts (though it should be harmless)
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 not sure I'm understanding the ask here.
Are you just wanting me to remove the object de-structuring?
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.
sorry, that should read note
.
looking at where the findPageOrAll actions are dispatched there are only ever type, context and paginatedOpt properties, never findAllOpt.
i don't think findAllOpt is needed though. for the findAll case we could just chop out the pagination
property from the paginatedOpt
object
Error in fetch(): TypeError: Cannot read properties of null (reading 'fields') one of the filter values is null. there'll be a bug somewhere, probably somewhere generic. let me know if you want me to track it down. This one turned out to be my fault. I missed it because I had largely stopped verifying the |
3259fb7
to
a756d9a
Compare
26fd853
to
d13ac57
Compare
d13ac57
to
9f700e1
Compare
Summary
Fixes #9548
Occurred changes and/or fixed issues
Reduces the number of
findAll
calls and rely on the PaginatedResourceTable to do the paginated calls.Areas or cases that should be tested
The management cluster list and detail pages
Areas which could experience regressions
The management cluster list and detail pages
Checklist