Commit Graph

20 Commits

Author SHA1 Message Date
Raphael Randschau 3954c1ecf0 provider/scaleway: delay between requests when waiting (#11184)
the CI sees many failing Scaleway tests due to request quotas being exceeded.
this PR aims to address this issue by switching from `resource.Retry`, which
waits 100ms between retries, to `resource.StateChangeConf` with a configured
delay of 5s between retries.

this should help us fixing the quota issue…
2017-01-13 10:49:16 +00:00
Raphael Randschau a422bf02f1 provider/scaleway: improve volume attachment (#10084)
* provider/scaleway: increase wait for server time

according to the scaleway community, shutdown/ startup might actually take an
hour. since a regular shutdown transfers data this is bound by the size of the
actual volumes in use.

https://community.online.net/t/solving-the-long-shutdown-boot-when-only-needed-to-attach-detach-a-volume/326

anyhow, 20 minutes seems quite optimistic, and we've seen some timeout errors in
the logs, too

* provider/scaleway: clear cache on volume attachment

the volume attachment errors quite often, and while I have no hard evidence
(yet) I guess it might be related to the cache that the official scaleway SDK
includes.

for now this is just a tiny experiment, clearing the cache when creating/
destroying volume attachments. let's see if this improves anything, really

* provider/scaleway: guard against attaching already attached volumes

* provider/scaleway: use cheaper instance types for tests

Scaleway bills by the hour and C2S costs much more than C1, since in the tests
we just spin up instances, to destroy them later on...
2016-11-17 15:08:05 +02:00
Raphael Randschau e5ff0f0cb2 provider/scaleway: update sdk (#9976)
the SDK updates includes an fix for the image cache, which might lead to wrong
images ids being returned on lookup...
2016-11-09 09:32:56 +00:00
Raphael Randschau b0772b9131 provider/scaleway: retry volume attachment create/ destroy (#9972)
this PR fixes a flakyness in the `scaleway_volume_attachment` resource, as
described below:

when attaching/ detaching a volume from a `scaleway_server`, the server needs to
be stopped. even though the code already waits for the server to be stopped, the
`PatchServer` calls gets a `400 server is being stopped or rebooted` error
response.

If the API returns the `400` we bail, leaving terraform in a broken state.

Assuming this is the only error that the API might return to us, as the payload
itself is correct, this retry behaviour should fix the issue.

\cc @stack72 PTAL
2016-11-08 21:57:33 +00:00
Raphael Randschau fc0455f63a provider/scaleway: fix `scaleway_image` datasource returning unknown images (#9899)
* provider/scaleway: expose scaleway_image lookup error

* provider/scaleway: fix image lookup error

fixes #9472
2016-11-05 11:37:02 +00:00
Raphael Randschau 98d84680b7 provider/scaleway server volume property (#9695)
* provider/scaleway: extract volume validation helpers

* provider/scaleway: add server volume property

fixes #9499

* provider/scaleway: update `scaleway_server` docu

* provider/scaleway: fix volume handling

this actually broken when merging the latest SDK update :(

* provider/scaleway: fix volume attachment

* provider/scaleway: fix volume expectation
2016-10-29 12:07:35 +01:00
Raphael Randschau 082ef04b9e provider/scaleway: update sdk for ams1 region (#9687)
* provider/scalway: update sdk for ams1 region

* provider/scaleway typecast volume size as of 472a493
2016-10-29 00:16:53 +02:00
Raphael Randschau d9a2e0dbb3 provider/scaleway: fix scaleway_volume_attachment with count > 1 (#9493)
* provider/scaleway: fix scaleway_volume_attachment with count > 1

since scaleway requires servers to be powered off to attach volumes to, we need
to make sure that we don't power down a server twice, or power up a server while
it's supposed to be modified.

sadly terraform doesn't seem to sport serialization primitives for usecases like
this, but putting the code in question behind a `sync.Mutex` does the trick, too

fixes #9417

* provider/scaleway: use mutexkv to lock per-resource

following  @dcharbonnier  suggestion. thanks!

* provider/scaleway: cleanup waitForServerState signature

* provider/scaleway: store serverID in var

* provider/scaleway: correct imports

* provider/scaleway: increase timeouts
2016-10-27 16:51:34 +01:00
Raphael Randschau ec20f800b2 provider/scaleway speedup server deletion (#9491)
* provider/scaleway speedup server deletion

using `terminate` instead of `poweroff` leads to a faster shutdown

fixes #9430

* provider/scaleway: extract server shutdown code
2016-10-27 12:37:40 +01:00
stack72 c4e2ff9cbb
provider/scaleway: Change bootscript datasource acceptance test
The tests were referencing an old bootscript - this just bumps the value
to the latest. The list of bootscripts can be found at
http://devhub.scaleway.com/#/bootscripts
2016-10-24 13:11:41 +01:00
James Nugent fc2d973e26 Merge pull request #9387 from nicolai86/feat/scaleway-import
provider/scaleway: add support for importing resources
2016-10-18 08:11:09 -05:00
Raphael Randschau fc4c848778
provider/scaleway: add importer support 2016-10-15 23:49:14 +02:00
Raphael Randschau 903170ddf3
provider/scaleway: add image data source 2016-10-15 19:32:08 +02:00
Raphael Randschau 1552c33033
provider/scaleway: add bootscript data source
bootscripts allow you to start Scaleway servers with a specific kernel version.
The `scaleway_server`  has always had a bootscript parameter, and the
`scaleway_bootscript` datasource allows you to lookup bootscripts to be used in
conjunction with the `scaleway_server` resource.
2016-10-15 19:32:01 +02:00
Raphael Randschau d98e5200cc
provider/scaleway: expose Region as user facing configuration 2016-10-10 20:02:32 +02:00
Raphael Randschau a5d105da36
provider/scaleway: use building DetachIP func 2016-10-10 20:02:10 +02:00
Raphael Randschau 9f598a68af
provider/scaleway: fix security_group_rule identification 2016-09-05 16:29:18 +02:00
Raphael Randschau 9f314a3c29 provider/scaleway: Expose IPv6 support, improve documentation (#7784)
* provider/scaleway: update api version

* provider/scaleway: expose ipv6 support, rename ip attributes

since it can be both ipv4 and ipv6, choose a more generic name.

* provider/scaleway: allow servers in different SGs

* provider/scaleway: update documentation

* provider/scaleway: Update docs with security group

* provider/scaleway: add testcase for server security groups

* provider/scaleway: make deleting of security rules more resilient

* provider/scaleway: make deletion of security group more resilient

* provider/scaleway: guard against missing server
2016-07-25 12:49:09 +01:00
Raphael Randschau 697828f81f Handle Scaleway tags correctly (#7682) 2016-07-18 10:12:15 +01:00
Raphael Randschau 9081cabd6e Add scaleway provider (#7331)
* Add scaleway provider

this PR allows the entire scaleway stack to be managed with terraform

example usage looks like this:

```
provider "scaleway" {
  api_key = "snap"
  organization = "snip"
}

resource "scaleway_ip" "base" {
  server = "${scaleway_server.base.id}"
}

resource "scaleway_server" "base" {
  name = "test"
  # ubuntu 14.04
  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.base.id}"
  volume = "${scaleway_volume.test.id}"
}

resource "scaleway_security_group" "base" {
  name = "public"
  description = "public gateway"
}

resource "scaleway_security_group_rule" "http-ingress" {
  security_group = "${scaleway_security_group.base.id}"

  action = "accept"
  direction = "inbound"
  ip_range = "0.0.0.0/0"
  protocol = "TCP"
  port = 80
}

resource "scaleway_security_group_rule" "http-egress" {
  security_group = "${scaleway_security_group.base.id}"

  action = "accept"
  direction = "outbound"
  ip_range = "0.0.0.0/0"
  protocol = "TCP"
  port = 80
}
```

Note that volume attachments require the server to be stopped, which can lead to
downtimes of you attach new volumes to already used servers

* Update IP read to handle 404 gracefully

* Read back resource on update

* Ensure IP detachment works as expected

Sadly this is not part of the official scaleway api just yet

* Adjust detachIP helper

based on feedback from @QuentinPerez in
https://github.com/scaleway/scaleway-cli/pull/378

* Cleanup documentation

* Rename api_key to access_key

following @stack72 suggestion and rename the provider api_key for more clarity

* Make tests less chatty by using custom logger
2016-07-13 21:03:41 +01:00