boaviztapi
boaviztapi copied to clipboard
SCALEWAY compute instances impacts
Problem
As we did for AWS (https://boavizta.github.io/boaviztapi/Explanations/devices/cloud/) we should be able to retrieve the impacts of Scaleway instances.
Solution
The same implementation as AWS instances.
Alternatives
Additional context or elements
I should be able to look at this :+1:
To add a new provider :
- add the provider in data/archetypes/cloud/providers.csv : https://github.com/Boavizta/boaviztapi/blob/dev/boaviztapi/data/archetypes/cloud/providers.csv
- add a csv file (data/archetypes/cloud/scalway.csv) which contains all the instances' configuration in the right format :
id | manufacturer | CASE.case_type | year | vcpu | platforme_vcpu | CPU.units | CPU.core_units | CPU.name | CPU.manufacturer | CPU.model_range | CPU.family | CPU.tdp | CPU.manufacture_date | instance.ram_capacity | RAM.capacity | RAM.units | SSD.units | SSD.capacity | HDD.units | GPU.name | GPU.units | GPU.TDP | GPU.memory_capacity | POWER_SUPPLY.units | POWER_SUPPLY.unit_weight | USAGE.instance_per_server | USAGE.time_workload | USAGE.use_time_ratio | USAGE.hours_life_time | USAGE.other_consumption_ratio | USAGE.overcommited | Warnings | configuration.disk.units | configuration.disk.type | configuration.disk.capacity |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
a1.2xlarge | AWS | rack | 2018 | 8 | 16 | 1 | 16 | Graviton | Annapurna Labs | Graviton | Graviton | 40 | 2018 | 16 | 16 | 2 | 0 | 0 | 0 | 2;2;2 | 2.99;1;5 | 2 | 50;0;100 | 1 | 35040 | 0.33;0.2;0.6 | 0 | 0 |
- If the CPU is not listed in https://github.com/Boavizta/boaviztapi/blob/dev/boaviztapi/data/crowdsourcing/cpu_specs.csv it is recommended to add it if you have the information. If not, the completion process will be used each time the instance is requested.
Feel free to ask any questions.
Adding new cloud providers and new cloud instance should now follow this process : https://doc.api.boavizta.org/contributing/cloud_provider/
Yes it looks great, thanks @da-ekchajzer. I am adding a boavizta-dump
command to this SCW + Boavizta PoC to generate the CSV files. Once that's done, I'll be able to copy-paste into a PR on this repo.
@da-ekchajzer, I see that in the server docs there is a field labelled CPU.threads
with a description Number of vCPU per CPU
. AFAICT this corresponds to the column labelled CPU.vcpu
in server.csv
, and so I'm pretty sure it's just a typo and should be CPU.vcpu
in the doc.
However, can I just double check that this is the correct assumption? I assume that the column CPU.vcpu
should be the max number of vCPUs allocated per CPU on that server type, and not the number of threads available on the CPU (which I guess is taken from cpu_specs.csv
).
I also don't see any Ampere CPUs in the CPU specs. I'm happy to add them too, but can I check I'm not missing something?
@da-ekchajzer, I see that in the server docs there is a field labelled CPU.threads with a description Number of vCPU per CPU. AFAICT this corresponds to the column labelled CPU.vcpu in server.csv, and so I'm pretty sure it's just a typo and should be CPU.vcpu in the doc.
Yes, you are right ! I just fixed it.
I also don't see any Ampere CPUs in the CPU specs. I'm happy to add them too, but can I check I'm not missing something?
You should indeed add the missing CPUs by following this doc: https://doc.api.boavizta.org/contributing/cpu/. I have just added the following note to the server contrib' page:
If CPU.name is set and the CPU is available in cpu_specs.csv, you do not need to fill in the other CPU attributes. The API will complete them based on the CPU.name.
However, can I just double check that this is the correct assumption? I assume that the column CPU.vcpu should be the max number of vCPUs allocated per CPU on that server type, and not the number of threads available on the CPU (which I guess is taken from cpu_specs.csv).
We assume that the max number of vCPU is equal to the number of thread (same value, different name depending on the context). If vCPU is not avaible in the server.csv, the API will complete vCPU with the number of threads taken from cpu_specs.csv based on the CPU name.
Is it a bad assumption ?
Awesome, thank you! Very clear.
Is it a bad assumption ?
No it's definitely sensible as a default. It's not always true though, so having the CPU.vcpu
field in server.csv
allows people to override it when it's not the case, which is perfect.