Commit Graph

8 Commits

Author SHA1 Message Date
Raphael Randschau 403ea9f6d7 provider/scaleway: work around parallel request limitation (#13045)
according to the official scaleway support, requests within the same session can
not be parallelized.

While I do not know for sure that this is a write-only limitation, I've
implemented it as a write-only limitation for now.

Previously requests like this would produce a 500 internal server error:

```
resource "scaleway_ip" "test_ip" {
  count = 2
}
```

now this limitation should be lifted, for all scaleway resources
2017-03-27 13:00:11 +03:00
Raphael Randschau 8183d4667a provider/scaleway: fix provider configuration (#11234)
properly fetch configuration from env - leftover from #10874
2017-01-17 12:50:10 +00:00
Ollie Ford ed2b959f7e Fix contradiction in terms with provider documentation (#10815) (#10874)
* Remove contradiction with Scaleway documentation

The parameters previously termed by Terraform:

1. Organization
2. Access key

Are referred to, respectively, by Scaleway [0] as:

1. Access key
2. Token

which is a confusing contradiction for a user.

Since Scaleway terms (1) both 'access key' [0] and 'organization ID' [1],
@nicolai86 suggested keeping the latter as already used, but changing (2) for
'token'; removing the contradiction.

This commit thus changes the parameters to:

1. Organization
2. Token

Closes #10815.

[0] - https://cloud.scaleway.com/#/credentials
[1] - https://www.scaleway.com/docs/retrieve-my-organization-id-throught-the-api

* Update docs to reflect Scaleway offering x86

Scaleway now provides x86 servers [0] as well as ARM.

This commit removes 'ARM' from various references suggesting that might be the
only option.

[0] - https://blog.online.net/2016/03/08/c2-insanely-affordable-x64-servers/
2017-01-17 12:02:55 +00: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 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 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