Cut back gratuitous regulation

[mbuechse]

Resolves #1082.

The problems with entropy are widely solved. The standard was a bit gratuitous to begin with (also addressing external hardware random-number generators). The test is relatively costly (because it spawns a VM) and probably wouldn't work with architectures other than amd64.

Disk sizes within flavors could be more contentious. I think it could be better to push for disk-less flavors even more.

[jklare]

For me, the big question here is if those "recommendations" in terms of rng and disk sizes should be removed or should be required.

Regarding the disk sizes, I do not see any reason to require operators to use specific disk sizes, since those should IMHO be aligned with the underlying hardware, as well as customer needs instead of arbitrary numbers. Advertising diskless flavors in general works for quite many cases, but for some you will need direct local disk access to provide the needed IOPS (which are otherwise extremely costly when using network storage).

Regarding rng, I strongly agree that this should not be an issue any more, and it should have become best practice by now. Nevertheless, IMHO this does not mean that we should remove the test or the standard for it. I think this should be rather moved to be a required attribute to ensure it stays that way and is not neglected later on. In my experience, everything that is not tested will eventually break.

[mbuechse]

@jklare Agreed for the most part. Regarding entropy: let's keep the standard, but I would still advocate for removing the parts about rngd. Either it's a crutch that these days no one should use, or it's used for an external hardware rng, and that is quite fringe-y.

[garloff]

Regarding the disk sizes, I do not see any reason to require operators to use specific disk sizes, since those should IMHO be aligned with the underlying hardware, as well as customer needs instead of arbitrary numbers. Advertising diskless flavors in general works for quite many cases, but for some you will need direct local disk access to provide the needed IOPS (which are otherwise extremely costly when using network storage).

If we do not recommend disk sizes, any workload using diskful flavors will not be portable.
That's why we recommended the scheme with 5, 10, 20, 50, 100, 200, 500, 1000, ... GiB disk sizes.
Having some providers provide 250 and others 240 would just create pointless incompatibilities.

Note 1: With diskless flavors, that issue goes away of course, that's why we strongly prefer them.
Note 2: If customers have very specific requirements or the hardware suggests very specific disk sizes, providers will create them and that's fine: Additional flavors (ideally still following the SCS flavor naming scheme) are explicitly allowed. We'd still have a few standard ones hopefully ... Users would know that they would increase their chance of having a portable workload by using SCS-16V-64-100 rather than a custom SCS-12V-48-80 even though the latter would be perfectly allowed. (Yes, adapting a flavor is not a big deal, but then there's validation etc ... behind it.)

Quantization helps to reduce fragmentation even if only recommended.

[garloff]

Regarding rng, I strongly agree that this should not be an issue any more, and it should have become best practice by now. Nevertheless, IMHO this does not mean that we should remove the test or the standard for it. I think this should be rather moved to be a required attribute to ensure it stays that way and is not neglected later on. In my experience, everything that is not tested will eventually break.

I'm with Jan: Consider anything broken that you have not tested.

It used to be a not-so-uncommon issue and now fortunately is uncommon.
If the testing is too painful, we have several steps we could make:
(1) We may reduce test frequency on this particular test (marking it expensive and running it only weekly)
(2) We may even drop the test from our routine testing completely, but keep the requirement in the standard and ask providers to sign that they comply and reserve the right to manually run or reintroduce the test ...
This way we provide some motivation to not regress here. Spot check approach.

[mbuechse]

@garloff

1. For immediate portability, the disk sizes would have to be mandatory! Not just that, we would have to mandate a fixed set of flavors and disallow all others, which would be ludicrous. However, there will always be minor changes involved when switching CSPs. SCS cannot reduce porting costs to zero, because you will always have the cost of migrating the data and other stuff that cannot be prevented. With SCS, you can be sure that the general capabilities are present. I'm not sure that adjusting flavors in a minor way would be the deal breaker here.
2. After Jan's comment, I have reverted the change that would remove the entropy standard. May I remind you though that it was your idea to retire it: "I guess that newer kernels have largely addressed this. So the whole standard may be retired long-term."

[mbuechse]

Quantization helps to reduce fragmentation even if only recommended.

Citation needed. It's not what we observe in pracice...

To be fair, we don't know what the situation would be like without the recommendation. But still, the benefit for portability of a slighlty reduced fragmentation is quite vague, and the cost of the recommendation is real.

[garloff]

Citation needed. It's not what we observe in pracice...

Looking for the theoretical (statistical) argument or an empirical one?
For the latter, we could look at the distribution of root disk sizes inside and outside of the SCS ecosystem. Not sure we'll get enough data points to get statistically meaningful results ...