-
Notifications
You must be signed in to change notification settings - Fork 26
Add larger memory flavors #938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
102b0a9
to
1647fa7
Compare
As discussed on Matrix (https://matrix.to/#/!xlFjWCAoQenuOeIVQw:matrix.org/$2bVMQjnP0QpGkOVtlVSusyt4gTQfaoGybYPkBUn2u2M?via=matrix.org&via=regio.chat&via=matrix.uhurutec.com) and suggested by @mbuechse: this is a good candidate to being discussed in the next Lean Coffee. The next Lean SCS Operator Coffee is on June 12. |
As discussed in the Lean SCS Operator Coffee on June 12, a survey of the SCS members and market analysis may be a good way to find out which additional (larger) default flavors are needed. @garloff recommended to add the new flavors as recommended first and make them mandatory later to give providers time to adapt. |
Signed-off-by: Marc Schöchlin <[email protected]>
68ff3c9
to
93d61aa
Compare
Converted this to draft because this is mainly a point for organizing the discussion. If the larger flavors are to be added, then the file(s) to be changed would be a little different. |
Hello there. I ran some statistics:
This is our current use in the currently most relevant one of our public cloud sites. Grouped by ratio:
Not sure if I can make it to this week's standardisation SIG, but there we go. All these flavors are dedicated thread (not dedicated core and not shared core). Needless to say, this cloud is not SCS compliant, also because of the flavors. And obviously, this is biased, as our customers can only use what we offer. Hence, there cannot be any usage of >=8:1 flavors or of flavors with more than 64 GiB of RAM in this particular site. (We are working on renewing the public cloud offering and are of course looking into the general direction of SCS flavors for inspiration of how we build it.) |
Further discussion in SIG Std/Cert meeting on 2025-07-10 with the following suggestion:
What would be the best place to add a brief explanation of what we mean by “recommended”? |
If you want to offer flavors only for specific memory sizes (e.g. 32 GB), you should include all recommended flavors for this specific memory size. "Recommended" does not mean that you should use all available flavors from the entire list. Instead, the recommendation only refers to the flavors for your desired configuration (e.g. 32 GB). Example: If you want to offer 32 GB instances, only include the flavors recommended for 32 GB - not all flavors from 2 GB to 128 GB that might be available in total. |
Thank you for the short and precise explanation. Another thing which popped into my head: Are |
The openstack flavor manager fetches the flavor definitions from the conformance test.
These definitions contain a "mandatory" and a "recommended" section.
I think it would be a good idea to have a set of default flavors in this file with the larger amounts of memory described, because in my opinion there is a high probability that something like this will be used very often (e.g. for database page caches). On the other hand, I don't think that variations of larger numbers of CPUs (apart from the existing ones) are needed very, because huge cpu workloads are often better distributed by multiple virtual machines (i.e. by using kubernetes).
I therefore advocate that we make flavors with larger amounts of RAM available in the recommended section of that file, as otherwise there will be more variants or SCS users will have to contact their provider every time.
From my point of view, it is very useful for SCS users if they can also expect larger flavors from different suppliers.