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 instance with not default volumes #9254

Closed
webroboteu opened this issue Oct 6, 2016 · 15 comments
Closed

scaleway instance with not default volumes #9254

webroboteu opened this issue Oct 6, 2016 · 15 comments

Comments

@webroboteu
Copy link

I have this error with VC1M instance.

With scaleway_volume_attachment i can't resolve the problem.

The properties volumes is not a scaleway_server property

Error applying plan:

1 error(s) occurred:

  • scaleway_server.test: StatusCode: 400 Type: invalid_request_error Message: APIMessage: The sum of volumes sizes of VC1M instances must be between 51GB and 100GB

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

@nicolai86
Copy link
Contributor

nicolai86 commented Oct 7, 2016

Hey @webroboteu,

can you provide a terraform plan which reproduces this error?
scaleway_server does not have a volumes property - when you want to attach a separate volume to a scaleway_server instance, you need to do the following:

  • create a separate scaleway_volume
  • create a separate scaleway_server
  • use a scaleway_volume_attachment to attach the volume to the server. Note that this requires running scaleway_server instances to be restarted.

i.e.

resource "scaleway_server" "test" {
  name = "test"
  image = "aecaed73-51a5-4439-a127-6d8229847145"
  type = "C2S"
}

resource "scaleway_volume" "test" {
  name = "test"
  size_in_gb = 20
  type = "l_ssd"
}

resource "scaleway_volume_attachment" "test" {
  server = "${scaleway_server.test.id}"
  volume = "${scaleway_volume.test.id}"
}

I assume that from your error message you're trying to create a volume which exceeds the allowed size of the VC1M machines.

@seb2411
Copy link

seb2411 commented Oct 10, 2016

I have the same problem:

resource "scaleway_server" "minion" {
    name = "minion"
    image = "15fd0f74-c939-43c3-bf41-ee5f711b3bb4"
    type = "VC1M"
    dynamic_ip_required = true
}

resource "scaleway_volume" "additionalVolume" {
  name = "additionalVolume"
  size_in_gb = 20
  type = "l_ssd"
}


resource "scaleway_volume_attachment" "additionalVolume" {
  server = "${scaleway_server.minion.id}"
  volume = "${scaleway_volume.additionalVolume.id}"
}

** scaleway_server.minion: StatusCode: 400 Type: invalid_request_error Message: APIMessage: The sum of volumes sizes of VC1M instances must be between 51GB and 100GB **

@nicolai86
Copy link
Contributor

@seb2411 @webroboteu I assume this is a Scaleway API issue, as the above example works with C2S just fine, as does it with VC1. I'll loop in @moul , maybe he has an idea on how to triage this issue.

@seb2411
Copy link

seb2411 commented Oct 11, 2016

@nicolai86 : Yes. I think it's in relation with the way the extra disk is added for the VC1M and VC1L.
For this 2 if you check in the UI of Scaleway the system add automatically an additional disk. It's not the case for the VC1S and C2*.

@nicolai86
Copy link
Contributor

nicolai86 commented Oct 15, 2016

the official Scaleway CLI has the same issue:

$ scw create --commercial-type=VC1M ubuntu-precise
FATA[0000] cannot execute 'create': The sum of volumes sizes of VC1M instances must be between 51GB and 100GB

Digging a little deeper into the request payload, this works:

{
  "dynamic_ip_required": false,
  "tags": [],
  "commercial_type": "VC1M",
  "volumes": {
    "1": {
      "name": "Volume",
      "volume_type": "l_ssd",
      "size": 50000000000,
      "organization": "a"
    }
  },
  "organization": "a",
  "name": "scw-50ed96",
  "image": "75c28f52-6c64-40fc-bb31-f53ca9d02de9",
  "public_ip": "e6ee2eb1-70c6-49d1-aa17-93f8eaf96529"
}

but this doesn't:

{
  "dynamic_ip_required": false,
  "tags": [],
  "commercial_type": "VC1M",
  "volumes": {},
  "organization": "a",
  "name": "scw-50ed96",
  "image": "75c28f52-6c64-40fc-bb31-f53ca9d02de9",
  "public_ip": "e6ee2eb1-70c6-49d1-aa17-93f8eaf96529"
}

both terraform and the scaleway CLI generate the latter.
The issue is tracked in scaleway/scaleway-cli#360 remotely

@nicolai86
Copy link
Contributor

Digging a little deeper it seems that the Scaleway CLI masks the problem by implicitly adding volumes when certain offerings are created, as discussed in scaleway/scaleway-cli#403 .

Since this fix is added outside of the Scaleway SDK we would need to duplicate that same logic, or, alternatively, allow secondary volumes to be defined inside the scaleway_server resource, as proposed in #8678.

@seb2411
Copy link

seb2411 commented Oct 17, 2016

@nicolai86 Thx for the update. Defining the volume inside the scaleway_server resource can be a good idea.

@stack72
Copy link
Contributor

stack72 commented Oct 28, 2016

Hi @webroboteu / @nicolai86

Is this still an issue?

P.

@nicolai86
Copy link
Contributor

nicolai86 commented Oct 28, 2016

Hey @stack72

Yes, this is still an issue. VC1M and VC1L instances require an additional volume to be specified at creation time, which to my best knowledge can not be modelled with two resources;

I think we need to introduce a new scaleway_server attribute, similar to what is proposed in #8678 / #9499

@tboerger
Copy link
Contributor

So, this issue is resolved via #9695 :)

@stack72
Copy link
Contributor

stack72 commented Oct 29, 2016

Thanks for the nudge @tboerger

Closed vis #9695

@stack72 stack72 closed this as completed Oct 29, 2016
@seb2411
Copy link

seb2411 commented Oct 30, 2016

So the problem will be fixed on Terraform 0.7.8 ?

@nicolai86
Copy link
Contributor

@seb2411 yup, next release contains a fix for this. see #9695

@seb2411
Copy link

seb2411 commented Oct 31, 2016

@nicolai86 ok. Perfect Thank you guys for the responsiveness, Nice job.

@ghost
Copy link

ghost commented Apr 21, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants