You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Portal:Cloud VPS/Admin/VM flavors: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Arturo Borrero Gonzalez
(→‎General flavor guidelines: drop extra quoting)
imported>Andrew Bogott
No edit summary
Line 9: Line 9:


A flavor can be private or public.  Public flavors are available for use by all projects; private flavors are assigned for limited use by one or more specified project.  A private flavor cannot be made public, nor a public flavor made private.
A flavor can be private or public.  Public flavors are available for use by all projects; private flavors are assigned for limited use by one or more specified project.  A private flavor cannot be made public, nor a public flavor made private.
== Deprecating a flavor ==
When a flavor is deleted, VMs no longer display with their cpu/ram/disk usage in Horizon; rather they appear with an unavailable flavor.  For that reason it's best to avoid deleting flavors as long as any VMS still exist using that flavor.
To prevent new VMs from being created with a flavor, don't delete them; put them in the flavor graveyard:
* Mark the flavor as private. This can't be done via nova apis, you have to use the database directly:
<syntaxhighlight lang="shell-session">
root@cloudcontrol1003:~# mysql -u root nova_api_eqiad1
mysql:root@localhost [nova_api_eqiad1]> update flavors set is_public=0 where flavorid='<flavorid>';
</syntaxhighlight>
* Add to the graveyard:
<syntaxhighlight lang="shell-session">
openstack flavor set --project flavor-graveyard bd542f73-4fdb-4aa0-98dd-049406152392
</syntaxhighlight>
*Remove from all other projects, if any:
<syntaxhighlight lang="shell-session">
root@cloudcontrol1003:~# openstack flavor show <flavorid> | grep access_project_ids
| access_project_ids        | cloudvirt-canary, flavor-graveyard                                                                                                                  |
root@cloudcontrol1003:~# openstack flavor unset --project cloudvirt-canary <flavorid>
</syntaxhighlight>


== General flavor guidelines ==
== General flavor guidelines ==

Revision as of 21:45, 16 March 2021

Each VM created with Openstack Nova is assigned a flavor. Flavor determines the following characteristics for a VM:

  • Number of vcpus
  • Available RAM
  • Available disk space for local storage
  • Storage backend (ceph or non-ceph)
  • Disk access rate limits
  • Scheduling hints that associated flavors with particular host aggregates

A flavor can be private or public. Public flavors are available for use by all projects; private flavors are assigned for limited use by one or more specified project. A private flavor cannot be made public, nor a public flavor made private.

Deprecating a flavor

When a flavor is deleted, VMs no longer display with their cpu/ram/disk usage in Horizon; rather they appear with an unavailable flavor. For that reason it's best to avoid deleting flavors as long as any VMS still exist using that flavor.

To prevent new VMs from being created with a flavor, don't delete them; put them in the flavor graveyard:

  • Mark the flavor as private. This can't be done via nova apis, you have to use the database directly:
root@cloudcontrol1003:~# mysql -u root nova_api_eqiad1
mysql:root@localhost [nova_api_eqiad1]> update flavors set is_public=0 where flavorid='<flavorid>';
  • Add to the graveyard:
openstack flavor set --project flavor-graveyard bd542f73-4fdb-4aa0-98dd-049406152392
  • Remove from all other projects, if any:
root@cloudcontrol1003:~# openstack flavor show <flavorid> | grep access_project_ids
| access_project_ids         | cloudvirt-canary, flavor-graveyard                                                                                                                   |
root@cloudcontrol1003:~# openstack flavor unset --project cloudvirt-canary <flavorid>

General flavor guidelines

Flavor names begin with a generation count (e.g. 'g2' for 2nd generation flavors), followed by cores, ram, disk space. For example, a second generation flavor with 2 cores, 8 gigs of ram and 20Gb of disk space would be g2.cores2.ram8.disk20.

Each flavor must specify a scheduling pool (via aggregate_instance_extra_specs). An icinga alert will fire if a flavor is found without aggregate_instance_extra_specs.

Each ceph-enabled flavor must specify disk access rate limits. An icinga alert will fire if a flavor is found WITH aggregate_instance_extra_specs:ceph='true' but WITHOUT quota:disk_read_iops_secm quota:disk_total_bytes_sec, or quota:disk_write_iops_sec.

No public flavor should be created with any quota above the following: 8 cores, 16G RAM, 160G disk. Users may request instances with larger specs, but these should be private flavors, created on an as-needed basis and associated only with specific, approved projects.

Example of flavor creation command for a private flavor:

user@cloudcontrol1005:~$ sudo wmcs-openstack flavor create --ram 16384 --vcpus 8 --project wikidumpparse --disk 1120 --private --property "aggregate_instance_extra_specs:ceph=true" --property "quota:disk_read_iops_sec=5000" --property "quota:disk_total_bytes_sec=200000000" --property "quota:disk_write_iops_sec=500" g2.cores8.ram16.disk1120

2nd generation flavors

Generation 2 flavors were created in September of 2020 to support the move to Ceph. Each g2 flavor is presumed to schedule in the standard Ceph pool 'eqiad1-compute'.

Flavors that do NOT use Ceph should be tagged with '.local-storage.' For example, a Generation 2 flavor used for a database host might be named g2.cores16.ram64.disk3000.local-storage. Local storage flavors should be quite unusual, and typically reserved for WMCS staff use and/or custom hardware.

Some example of g2 flavors are:

g2.cores8.ram18.disk160
g2.cores4.ram8.disk80
g2.cores2.ram4.disk40
g2.cores1.ram2.disk20

1st generation flavors

Generation 1 flavors are legacy flavors that predate any attempt at standardization. Some use amazon-style 'm1' naming, some have usage-specific names. In addition, many have non-standard single-digit internal IDs rather than standard uuids.

Most of these flavors will be removed as soon as possible. Here is the complete list of 1st generation flavors as of September, 2020:

2: m1.small
3: m1.medium
4: m1.large
5: m1.xlarge
7: m1.gigantic
21e9047d-a60f-499d-b7f5-51f83ddf3611: bigdisk2
c39bc0a6-71a2-4512-926e-43cccf5f8b4c: mediumdb
e48a8d9d-e735-4742-981f-b55f293d4115: bigram
e7261773-a931-4a72-b725-3ccf71580b18: largedb
72116845-7941-4d3d-9eb1-11084b7b1927: cloudvirt-canary
bd542f73-4fdb-4aa0-98dd-049406152392: cloudvirt-canary-ceph
62a89635-8a60-40d7-9b58-56594a071b0a: justdisk
2d59cc0d-538c-4bbd-b975-8e696a4f7207: c1.m2.s80
8af1f1cc-d95f-4380-bf10-bcfa0321b10f: c8.m8.s60
4cf440b0-b4c7-42b5-a18e-7746b50390fc: dumps-temporary-file-storage
101: ci1.medium
3a6d6aa8-05de-4811-b882-72595a4d6529: mediumram-ceph
7b92dec5-e831-4eef-abc8-1ed585c59c66: mediumram
cc0f1723-38d7-42da-aa2c-cef28d5f4250: xlarge-xtradisk
857921a5-f0af-4069-8ad1-8f5ea86c8ba2: m1.small-ceph
6606e793-2949-4beb-9051-50341fcafbf7: m1.xlarge-ceph
e4c6fb0b-0cf7-4f50-9f1f-db3eea00fb2c: m1.large-ceph
7b7df879-9750-4516-8e84-1de9896963f0: transferpy-test
65de37ea-f087-48d7-9769-0cd741a7219b: wdqs.full
f34a542a-a933-4341-8f43-ff8442f48a01: t206636
15675a68-8f3d-450b-af4b-d661a486c926: parsingtest