Skip to content
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

SCALEWAY compute instances impacts #228

Open
demeringo opened this issue Sep 29, 2023 · 7 comments
Open

SCALEWAY compute instances impacts #228

demeringo opened this issue Sep 29, 2023 · 7 comments
Labels
DATA functional help wanted Extra attention is needed

Comments

@demeringo
Copy link
Collaborator

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

@Shillaker
Copy link
Contributor

I should be able to look at this 👍

@da-ekchajzer
Copy link
Collaborator

To add a new provider :

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

Feel free to ask any questions.

samuelrince added a commit that referenced this issue Nov 29, 2023
…instances

Should help with the following issues #66, #145, #228 and #249
samuelrince added a commit that referenced this issue Nov 29, 2023
Should help with the following issues #66, #145, #228 and #249
@da-ekchajzer
Copy link
Collaborator

Adding new cloud providers and new cloud instance should now follow this process : https://doc.api.boavizta.org/contributing/cloud_provider/

@Shillaker
Copy link
Contributor

Shillaker commented Jan 18, 2024

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.

@Shillaker
Copy link
Contributor

Shillaker commented Jan 22, 2024

@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
Copy link
Collaborator

@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 ?

@Shillaker
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DATA functional help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants