* 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/
* 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
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.
* 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
Raphael Randschau