-
Initiative
-
Resolution: Done
-
Normal
-
None
-
None
-
Proactive Architecture
-
False
-
-
False
-
0
Feature Overview (aka. Goal Summary)
The customer will have the use case to add 100,000 entries to registries.conf by creating 100,000 ImageContentSourcePolicy or ImageDigestMirrorSet CRs.
We neeed to ensure how many ImageContentSourcePolicy or ImageDigestMirrorSet CRs with single source mirror mapping that the Openshfit can support.
Goals (aka. expected user outcomes)
provide the customer with a reasonable number of limit of ImageContentSourcePolicy or ImageDigestMirrorSet CRs, and the (registry, mirror) mapping entries in the registries.conf that are supported by crio.
Note: There is no tangible deliverable as this was to test if IDMS can create 1K entries.
- blocks
-
OCPSTRAT-160 ICSP migration to IDMS
-
- Closed
-
- is related to
-
MCO-777 Assess impact of lack of MachineConfig GC for ICSP and IDMS objects
-
- Closed
-
-
-
- Closed
-
[OCPSTRAT-899] Need to ensure scale of ICSP/IDMS when per image registry entries are created (thousands of entries)
julim for feature like this which does not have any code+doc+test so moving it as initiative so that it will not show up in your dashboard
There is no tangible deliverable as this was to test if IDMS can create 1K entries . The work is been done by MCO team MCO-777 ( rhn-engineering-skumari what is the status)
julim for feature like this which does not have any code+doc+test in a release . How we want to track ?
gausingh@redhat.com, the OCPNODE-1830 and MCO-777 should be considered together since both components (CRI-O and MCO) need to meet our performance requirements for the entire approach of using 100,000 registry entries to be feasible. We know now that CRI-O will behave well in one of the scenarios, and the more resources it has, the better the result will be. We need to wait for the MCO team to complete their analysis to get the whole picture.
gausingh@redhat.com, a more detailed summary is available at OCPNODE-1830. However, it can be surmised to the following:
The quoted number of 100,000 registry+mirror entries is feasible, and the customer should be able to work with that volume of entries.
The best outcome will be if they use a single file that contains all the entries so that the configuration file loading and parsing can take place in a single pass, so to speak, as this will have the least amount of impact on CRI-O and also consume a low to moderate amount of resources in terms of CPU time and memory usage. If needed, there can be room for improvements in the library CRI-O uses to optimise configuration file loading if we want to spend engineering resources on it. It's probably not worth the time and effort it will take, though.
rh-ee-kwilczyn please comment here on what is the finding on the scale ?
this feature is done