Bug 1653160 - [admin] The MaxQuaryString limit does not take effect for ProjectList request
Summary: [admin] The MaxQuaryString limit does not take effect for ProjectList request
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Paul Weil
QA Contact: Xiaoli Tian
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-26 06:11 UTC by shahan
Modified: 2019-06-12 11:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-12 11:54:37 UTC
Target Upstream Version:


Attachments (Terms of Use)
project2000 (223.07 KB, image/png)
2018-11-26 06:11 UTC, shahan
no flags Details
namespace2000 (238.16 KB, image/png)
2018-11-26 06:16 UTC, shahan
no flags Details
namspace-request (313.91 KB, image/png)
2018-11-26 06:17 UTC, shahan
no flags Details
projects-request (340.95 KB, image/png)
2018-11-26 06:17 UTC, shahan
no flags Details

Description shahan 2018-11-26 06:11:01 UTC
Created attachment 1508497 [details]
project2000

Description of problem:
The ProjectList request url containing 'limit=250' query string as bellow:
https://$admin-console-route/api/kubernetes/apis/project.openshift.io/v1/projects?limit=250
It implies that one ProjectList request can get up to 250 projects. In fact, It will get all projects with one ProjectList request.
In the case of obtaining a large number of projects, there will giving a bad experience to response, It takes a heavy toll on the initial load time and even worse on a slow network.
In contrast, the NamespaceList request will give feedback to the user at an acceptable time. It splits into multiple requests based on limit so it doesn't affect the rendering of the data that has already been obtained. Also it is difficult for users to clearly perceive the subsequent loading process and greatly improve the user experience.
Although in the case of a small number (project<250) we may not be able to perceive the response gap between the two requests. But the larger the number, the more obvious the difference, and even the response time of the ProjectList request reaches an unacceptable state.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.creat 2000 projects
2. click project list page from other page
3. click namespaces list page from other page

Actual results:
2. The client will take nearly 7~9 seconds to respond to the page showing all projects and during this time the page is blank.
3. This request will quickly give a response to list some namespaces within 2 to 3 seconds, and load the remaining projects in the user is hard to perceive.

Expected results:
The MaxQuaryString 'limit=250' in Projectlist request should take effect to improve the user experience.

Additional info:
Give a few chrome peformance data maps for reference. see attachment.

Comment 1 shahan 2018-11-26 06:16:10 UTC
Created attachment 1508498 [details]
namespace2000

Comment 2 shahan 2018-11-26 06:17:08 UTC
Created attachment 1508499 [details]
namspace-request

Comment 3 shahan 2018-11-26 06:17:54 UTC
Created attachment 1508500 [details]
projects-request

Comment 4 shahan 2018-11-26 06:40:12 UTC
image version:
registry.reg-aws.openshift.com:443/openshift/ose-console                   v4.0                4ecf0ac05084        4 days ago          258 MB

cluster matrix:
master+etcd(one),compute(four) 
flavor: AWS EC2 m4.xlarge 
CPU 4
RAM 16
Storage 60

Comment 5 Jakub Hadvig 2018-11-26 09:59:43 UTC
I think this is a known issue, but until we will have a solid pagination solution I'm not sure limiting the list length makes sense.

Comment 6 Samuel Padgett 2018-11-26 15:12:57 UTC
I believe this is a known limitation in the projects API. Not all resources support pagination. Until the projects API supports it, there's nothing the console can do. Assigning to the master team for evaluation.


(In reply to Jakub Hadvig from comment #5)
> I think this is a known issue, but until we will have a solid pagination
> solution I'm not sure limiting the list length makes sense.

We do progressive loading for resources that support it. This way the UI doesn't block, and data fills in as we get it.

Comment 7 Maciej Szulik 2019-03-01 11:32:21 UTC
I'm changing the component, since that's APIServer related rather than CLI.

Comment 8 Maciej Szulik 2019-03-01 13:31:19 UTC
This is RFE, not a bug, that was never supported.

Comment 9 Kirsten Newcomer 2019-06-12 11:54:37 UTC
With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers.  Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant.

This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. 

If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new 

Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new 

As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.


Note You need to log in before you can comment on or make changes to this bug.