Closed joaoarodrigues closed 3 years ago
@joaoarodrigues Can you point to where is this ratio defined in the RM? Thanks
@joaoarodrigues Can you point to where is this ratio defined in the RM? Thanks
@pgoyal01 https://cntt.readthedocs.io/en/latest/ref_model/chapters/chapter04.html#4.2.1
@joaoarodrigues Thanks but that just happens to be the pattern in the currently predefined flavors -- there is no specification for the ratio to be 1:2.
We also used to have a section (which was objected to by some and hence removed) where we could specify the desired flavour by specs for vCPUS, RAM, disk etc. So we could ask for an instance of size, using mnemonics, 6c24r300e1200d where the RAM and disk are in GB or represented as (key, value) pairs as in {(vCPU, 6), (RAM, 24), (ephemeral,300), (storage,1200)}. The scheme can be extended to even specify NUMA, bandwidth, etc.
@pgoyal01 Agreed the first paragraph.
Can we use different flavours with a different ratio (1:4 vCPU:RAM)?
The following statement is quite clear on the need to use the table as defined (ratio in use is 1:2 between vCPU & RAM).
"... The intent of the following Flavours list is to be comprehensive and yet effective to cover both IT and NFV workloads. The compute Flavours are specified relative to the “large” Flavour. The “large” Flavour configuration consists of 4 vCPUs, 8 GB of RAM and 80 GB of local disk, and the resulting virtual compute instance will have a management interface of 1 Gbps ..."
@joaoarodrigues @pgoyal01 I can understand Joao concerns about pre-defined flavors. As defined in table 4.13, the flavors are not dimensioned for VNFs with memory intensive needs. We can develop sets of flavors per VNFs needs, but I do not think it should be done in RM. As flavors are specific to OpenStack, RA1 would be a better place for that.
Thank you for all comments @karinesevilla @pgoyal01. I'll then propose either a fixed flavour (1:4 ratio) or the possibility of creating "dynamically" a flavour for an application
@joaoarodrigues I would prefer that we support dynamic flavours
@joaoarodrigues @pgoyal01 The 1:4 ratio will not provide a set of flavors covering the majority of VNFs requirements. For me, it is more realistic to remove the pre-defined flavors and write the section keeping the original intent which was to foster the cloud native design of applications
Agree that being less proscriptive and more descriptive is the correct approach.
On Wed, Feb 24, 2021 at 12:31 PM karinesevilla notifications@github.com wrote:
@joaoarodrigues https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_joaoarodrigues&d=DwMCaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=SRbTmUPL76bJeeepHmpXUwpTHHijZkQHEH2AzpWnb-I&s=oPT_DW7tW2BCJB486y2ZMMwNxN4Zu0bBAxW5K58zf9w&e= @pgoyal01 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pgoyal01&d=DwMCaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=SRbTmUPL76bJeeepHmpXUwpTHHijZkQHEH2AzpWnb-I&s=Q0MP4hCrtYPXLCp6PcfCrseM7gW23QCYcNioay9ENj8&e= The 1:4 ratio will not provide a set of flavors covering the majority of VNFs requirements. For me, it is more realistic to remove the pre-defined flavors and write the section keeping the original intent which was to foster the cloud native design of applications
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cntt-2Dn_CNTT_issues_2265-23issuecomment-2D785245181&d=DwMCaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=SRbTmUPL76bJeeepHmpXUwpTHHijZkQHEH2AzpWnb-I&s=kzvIFZuDNHB8LDZ3WQ9vRucHcDCZVk2q4wl_20Uu54k&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMN7IKT6UALS7UE3MSQD3BLTAUZYLANCNFSM4XNVDMPA&d=DwMCaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=zSPYRgoBij7eDdloAJpktY4pyBQRGnvgrz_9Wy3fyA4&m=SRbTmUPL76bJeeepHmpXUwpTHHijZkQHEH2AzpWnb-I&s=D3mIYyxi4GZ6MtUNy20mmM2qpMKe-Tueg6vD6epBAFA&e= .
--
[image: Verizon] http://www.verizon.com/
Beth Cohen DMTS - NFV/SDN Network Product Strategy Verizon Business Group
O 781.466.2055 M 781.434.8553 60 Sylvan Rd. Waltham, MA 02451
[image: Facebook] http://www.facebook.com/verizon [image: Twitter] http://twitter.com/verizon
@karinesevilla @bfcohen That approach existed in our earliest documents were moved to comments and then even the comments deleted.
In RM we can define in terms of <key, value> pairs as in:
Flavour <name, X> { <vCPU, number of vCPUs> -- Required, <RAM, size in GB> -- Required, <external_disk, size in GB> -- Required, <ephemeral-disk, size in GB> -- Optional, <root-disk, size in GB> -- Optional, <cpu_pinning, Y/N> -- Optional: Y is default, <cpu_SMT, Y/N> -- Optional: Y is default, <cpu_pinning, Y/N> -- Optional: Y is default, <cpu_alloc_ratio, n:m> -- Optional: 1:1 is default, n and m are positive integers >1 , <numa_alignment, Y/N> -- Optional: Y is default, <huge_pages, Y/N> -- Optional: Y is default, <network_DPDK, Y/N> -- Optional: N is default, <network_SRIOV, Y/N> -- Optional: N is default, <network_GPU, Y/N> -- Optional: N is default, <network_SmartNIC, Y/N> -- Optional: N is default, <network_FPGA, Y/N> -- Optional: N is default, <network_IPSec_Accel, Y/N> -- Optional: N is default, <network_Crypto_Accel, Y/N> -- Optional: N is default, <network_Transcode_Accel, Y/N> -- Optional: N is default, }
For the basic required items we can use a short-form as in: c6r16d320 for <vCPU,6>,<RAM,16>,<external_disk, 320>.
Thank you for all the comments.
So we all agree that default Flavors don't exist anymore (this was removed from OpenStack Newton onwards)
I'll then update the respective documentation with the details on how to create a comprehensive flavor (@pgoyal01 example), and then a basic one
Flavor
@joaoarodrigues Thanks. BTW RM defines a Basic (B) and Network Intensive (N) Profiles -- my example with CPU Pinning as a Y (default) applies to N profiles.
Discussions in RA1 and RA2 meetings identified an issue with the naming of the "Network Intensive" profile. The use of "network" is problematic.
Possible alternate profile name, "Resource Intensive", "High Performance", ...
The name change coupled with declarative flavours will provide the flexibility to meet many identified needs.
Thank you @pgoyal01 . I'll propose accordingly.
Current profiles defined in RM are using 1:2 CPU to memory ratio, while there are workloads which are more memory intensive. Let's figure out in this issue if we would like to introduce a new profile or we make the memory a varaible part of the profiles and enable high memory flavors.
This topic was discussed on the 2021-02-02 - Anuket - RM: Memory Optimisation sesion on the 2021 spring LFN DTF and in the RM Meeting on 2021.02.10.