You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The sharding logic in the LTM currently assumes all child test appliances will use 2 CPUs. The PD-SSD quota limits are not even involved in the calculation (although the default 500GB PD-SSD quota limit is unlikely to be hit, as the scratch disk size change made the PD-SSD size of most configs be around 16 GB, except for the few LARGE configs requiring up to 56 GB).
For this reason, the "ext4/dax" config, and all variations in NR_CPU/MEM for the test appliance are disallowed. The sharding logic in the LTM could be updated to do more intelligent sharding of test appliances, and take into account more of these factors.
The text was updated successfully, but these errors were encountered:
The sharding logic in the LTM currently assumes all child test appliances will use 2 CPUs. The PD-SSD quota limits are not even involved in the calculation (although the default 500GB PD-SSD quota limit is unlikely to be hit, as the scratch disk size change made the PD-SSD size of most configs be around 16 GB, except for the few LARGE configs requiring up to 56 GB).
For this reason, the "ext4/dax" config, and all variations in NR_CPU/MEM for the test appliance are disallowed. The sharding logic in the LTM could be updated to do more intelligent sharding of test appliances, and take into account more of these factors.
The text was updated successfully, but these errors were encountered: