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.
Created attachment 1508498 [details] namespace2000
Created attachment 1508499 [details] namspace-request
Created attachment 1508500 [details] projects-request
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
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.
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.
I'm changing the component, since that's APIServer related rather than CLI.
This is RFE, not a bug, that was never supported.
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.