Giter Site home page Giter Site logo

ovh / terraform-provider-ovh Goto Github PK

View Code? Open in Web Editor NEW
181.0 49.0 132.0 18.03 MB

Terraform OVH provider

Home Page: https://registry.terraform.io/providers/ovh/ovh/latest/docs

License: Mozilla Public License 2.0

Makefile 0.09% Go 99.79% Shell 0.12%
terraform terraform-provider ovh hacktoberfest

terraform-provider-ovh's Introduction

Terraform OVH Provider

The OVH Provider allows Terraform to manage OVH resources.

Requirements

  • Terraform 0.12.x
  • Go 1.20 (to build the provider plugin)

Building The Provider

Clone repository to: $GOPATH/src/github.com/ovh/terraform-provider-ovh

$ mkdir -p $GOPATH/src/github.com/terraform-providers/; cd $GOPATH/src/github.com/terraform-providers/
$ git clone [email protected]:ovh/terraform-provider-ovh

Enter the provider directory and build the provider

$ cd $GOPATH/src/github.com/ovh/terraform-provider-ovh
$ make build

Using the provider

Please see the documentation in the Terraform registry.

Or you can browse the documentation within this repo here.

Using the locally built provider

If you wish to test the provider from the local version you just built, you can try the following method.

First install the Terraform Provider binary into your local plugin repository:

# Set your target environment (OS_architecture): linux_amd64, darwin_amd64...
$ export ENV="linux_amd64"
$ make build
$ mkdir -p ~/.terraform.d/plugins/terraform.local/local/ovh/0.0.1/$ENV
$ cp $GOPATH/bin/terraform-provider-ovh ~/.terraform.d/plugins/terraform.local/local/ovh/0.0.1/$ENV/terraform-provider-ovh_v0.0.1

Then create a Terraform configuration using this exact provider:

$ mkdir ~/test-terraform-provider-ovh
$ cd ~/test-terraform-provider-ovh
$ cat > main.tf <<EOF
# Configure the OVHcloud Provider
terraform {
  required_providers {
    ovh = {
      source = "terraform.local/local/ovh"
      version = "0.0.1"
    }
  }
}

provider "ovh" {
}
EOF

# Export OVHcloud API credentials
$ export OVH_ENDPOINT="..."
$ export OVH_APPLICATION_KEY="..."
$ export OVH_APPLICATION_SECRET="..."
$ export OVH_CONSUMER_KEY="..."

# Initialize your project and remove existing dependencies lock file
$ rm .terraform.lock.hcl && terraform init
...

# Apply your resources & datasources
$ terraform apply
...

Developing the Provider

If you wish to work on the provider, you'll first need Go installed on your machine (version 1.8+ is required). You'll also need to correctly setup a GOPATH, as well as adding $GOPATH/bin to your $PATH.

To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory.

$ make build
...
$ $GOPATH/bin/terraform-provider-ovh
...

Testing the Provider

In order to test the provider, you can simply run make test.

$ make test

In order to run the full suite of Acceptance tests you will need to have the following list of OVH products attached to your account:

You will also need to setup your OVH API credentials. (see documentation)

Once setup, please follow these steps to prepare an environment for running the Acceptance tests:

$ cat > ~/.ovhrc <<EOF
# setup ovh api credentials
export OVH_ENDPOINT="ovh-eu"
export OVH_APPLICATION_KEY="..."
export OVH_APPLICATION_SECRET="..."
export OVH_CONSUMER_KEY="..."
EOF
$ source ~/.ovhrc

In order for all the tests to pass you can run:

export OVH_IP_TEST="..."
export OVH_IP_BLOCK_TEST="..."
export OVH_IP_REVERSE_TEST="..."
export OVH_IP_MOVE_SERVICE_NAME_TEST="..."
export OVH_IPLB_SERVICE_TEST="..."
export OVH_CLOUD_PROJECT_SERVICE_TEST="..."
export OVH_CLOUD_PROJECT_REGION_TEST="..."
export OVH_CLOUD_PROJECT_LOADBALANCER_TEST="..."
export OVH_CLOUD_PROJECT_FAILOVER_IP_TEST="..."
export OVH_CLOUD_PROJECT_FAILOVER_IP_ROUTED_TO_1_TEST="..."
export OVH_CLOUD_PROJECT_FAILOVER_IP_ROUTED_TO_2_TEST="..."
export OVH_VRACK_SERVICE_TEST="..."
export OVH_ZONE_TEST="..."

$ make testacc

To run only one acceptance test, you can run:

$ make testacc TESTARGS="-run TestAccCloudProjectKubeUpdateVersion_basic"

To run one acceptance test and bypass go test caching:

$ TF_ACC=1 go test -count=1 $(go list ./... |grep -v 'vendor') -v -run  TestAccCloudProjectKubeUpdateVersion_basic -timeout 600m -p 10

To remove dangling resources, you can run:

$ make testacc TESTARGS="-sweep"

Contributing

Please read the contributing guide to learn about how you can contribute to the OVHcloud Terraform provider ;-).
There is no small contribution, don't hesitate!

Our awesome contributors:

terraform-provider-ovh's People

Contributors

amstuta avatar arnoways avatar bellionbastien avatar bigbigbang avatar dependabot[bot] avatar fehrnah avatar gaetanfl avatar galiley avatar goblain avatar grubernaut avatar hugueslepesant avatar lpatte avatar maelstrom96 avatar matprig avatar mircot avatar ovh-irobot avatar pgaxatte avatar radeksimko avatar rbeuque74 avatar remijouannet avatar scraly avatar skynewz avatar smortex avatar snigle avatar stoakes avatar vaxvms avatar wilfriedroset avatar yanndegat avatar yomovh avatar yvigara avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-ovh's Issues

[PROPOSAL] Switch to Go Modules

As part of the preparation for Terraform v0.12, we would like to migrate all providers to use Go Modules. We plan to continue checking dependencies into vendor/ to remain compatible with existing tooling/CI for a period of time, however go modules will be used for management. Go Modules is the official solution for the go programming language, we understand some providers might not want this change yet, however we encourage providers to begin looking towards the switch as this is how we will be managing all Go projects in the future. Would maintainers please react with ๐Ÿ‘ for support, or ๐Ÿ‘Ž if you wish to have this provider omitted from the first wave of pull requests. If your provider is in support, we would ask that you avoid merging any pull requests that mutate the dependencies while the Go Modules PR is open (in fact a total codefreeze would be even more helpful), otherwise we will need to close that PR and re-run go mod init. Once merged, dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@master
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

GO111MODULE=on might be unnecessary depending on your environment, this example will fetch a module @ master and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/. To remove dependencies from your project, simply remove all usage from your codebase and run:

$ GO111MODULE=on go mody tidy
$ GO111MODULE=on go mod vendor

Thank you sincerely for all your time, contributions, and cooperation!

Unable to use provider with no access to `/me` api endpoint

Expected Behavior

Having OVH Api application credentials I should be able to manage resources I have been granted access to.

Actual Behavior

If access to API on /me URI was not granted the provider fails to run with

* provider.ovh: OVH client seems to be misconfigured: "Error 403: \"This call has not been granted\""    

Suggested solution

For verification of client connection switch from /me to /auth/time which returns unix timestamp and does not require explicit access rights granted.
While no authentication is required to access this endpoint, if provided and invalid it will still fail.

New resource: ovh_domain

I currently use OVH as a registrar, but I would like to be able to use terraform up my domains to use another DNS provider (for exemple AWS Route53).

This does not seem possible at the moment, you only have resources to change the content of a zone, not nameservers.

An ovh_domain zone would be useful (only working if a domain exists on the account, obviously). It could be use to set up nameservers & DS records for a domain.

ovh_cloud_project_kube request OVH_CLOUD_PROJECT_SERVICE to be set

The new ovh_cloud_project_kube resource requires the environment variable OVH_CLOUD_PROJECT_SERVICE to be set.
Previously it was possible to specify cloud_project resources by <CLOUD_PROJECT_ID>/<RESOURCE_ID>.
Also if it is not set no error occurs when trying to import a resource. You can only see the error when running with DEBUG enabled and see that the API call goes to GET /1.0/cloud/project//kube/xxxxx and return 404.

OVH public cloud - Unknown body parameter serviceName

Hi,

I am using terraform to provision OVH instances.
Without changing terraform code, also using the same terraform binary that previously worked, I now receive the error: "Error 400: "Unknown body parameter serviceName""

Please note that upgrading to the latest terraform binary still gets the same error.
Unfortunately, I only have the latest ovh provider and I don't remember the ovh provider that worked in the past.

Terraform Version

terraform --version
Terraform v0.12.17 and also latest

  • provider.local v1.4.0
  • provider.ovh v0.8.0

Affected Resource(s)

  • ovh_cloud_user

Terraform Configuration Files

provider "ovh" {
endpoint = "ovh-eu"
application_key = "xxx"
application_secret = "xxx"
consumer_key = "xxx"
}

resource "ovh_cloud_user" "terraform" {
project_id = var.project_id
}

Debug Output

https://gist.github.com/mnicstr/b5b1de4c7b122cf99742694b7f7ab2c2

Expected Behavior

An Horizon OVH user should have been created

Actual Behavior

It seems that terraform is sending to OVH api an undefined parameter :

2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Host: eu.api.ovh.com
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: User-Agent: Go-http-client/1.1
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Content-Length: 67
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Accept: application/json
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Content-Type: application/json;charset=utf-8
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Ovh-Application: xxx
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Ovh-Consumer: xxx
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Ovh-Signature: xxx
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Ovh-Timestamp: 1598351006
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Accept-Encoding: gzip
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4:
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: {
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: "serviceName": "ed0a00ee80b84f218d5e7f4d9db4a379",
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: "description": ""
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: }
2020-08-25T13:23:27.184+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: -----------------------------------------------------
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: 2020/08/25 13:23:27 [DEBUG] OVH API Response Details:
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: ---[ RESPONSE ]--------------------------------------
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: HTTP/1.1 400 Bad Request
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Connection: close
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Content-Length: 77
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Access-Control-Allow-Methods: GET, POST
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Access-Control-Allow-Origin: *
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Cache-Control: no-cache, no-store
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Content-Type: application/json; charset=utf-8
2020-08-25T13:23:27.376+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Date: Tue, 25 Aug 2020 10:23:27 GMT
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: Server: nginx
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Content-Type-Options: nosniff
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Frame-Options: SAMEORIGIN
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Iplb-Instance: 21902
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Ovh-Queryid: EU.ext-4.5f44e69f.4259.ef1ea536-5976-4dc2-b731-ef8d1e182a22
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: X-Xss-Protection: 1; mode=block
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4:
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: {
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: "class": "Client::BadRequest",
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: "message": "Unknown body parameter serviceName"
2020-08-25T13:23:27.377+0300 [DEBUG] plugin.terraform-provider-ovh_v0.8.0_x4: }

Steps to Reproduce

  1. terraform apply

Important Factoids

In order to test you need an OVH cloud account

ovh-cli is archived

Hi,

The documentation says:

It is recommend to install ovh-cli to handle and manage all your secret keys.

But ovh/ovh-cli is an archived project with no commit since 2017. Please amend with instructions on how to acquire the credentials without ovh-cli (or have the provider do the authentication flow like other providers do).

thanks!

Allow to use ~/.ovh.conf file to setup provider

OVH provides an ovh-cli tool that stores the credentials in ~/.ovh.conf in that format:

[default]
endpoint=ovh-eu

[ovh-eu]
application_key=<my_application_key>
application_secret=<my_application_secret>
consumer_key=<my_consumer_key>

[ovh-cli]

It would be great if the OVH provider could fetch credentials from this file.
For example:

provider "ovh" {
  profile = "ovh-eu"
}

Juste like the aws providers allows:

provider "aws" {
  profile = "my_profile"
}

Terraform provider 0.10.0 : Error: section "ovh-eu" does not exist

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.14.0

  • provider registry.terraform.io/ovh/ovh v0.10.0
  • provider registry.terraform.io/terraform-provider-openstack/openstack v1.33.0

Affected Resource(s)

  • provider

Terraform Configuration Files

provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = "xxx"
  application_secret = "xxx"
  consumer_key       = "xxx"
}

Debug Output

https://gist.github.com/laurentgrangeau/83952fc99ee9beb5d4e35d76115755a5

Panic Output

Expected Behavior

Terraform apply the requested resources

Actual Behavior

An error message appear when I use the 0.10.0 provider

Steps to Reproduce

  1. terraform apply

Important Factoids

References

ovh_cloud_user should support role / roles arguments

Hi,

Right now, it's not possible to manage the role(s) of a given user created with ovh_cloud_user. Even more problematic, the actual default role is Administrator while one would expect no role to be attached at all.

Thanks in advance.

r/ovh_domain_zone_record, r/ovh_domain_zone_redirection silent errors

Affected Resource(s)

  • ovh_domain_zone_record
  • ovh_domain_zone_redirection

Description

The way some resources are handled by the OVH API is:

  • do changes (POST/PUT/DELETE)
  • launch a "refresh" task so that changes are applied

But on some resources, you cannot schedule more than one refresh at a time.
So you can encounter concurrency issues regarding refreshes, moreover by the way
terraform runs its changes in parallel

Currently, in "domain_zone" refreshes, refresh actions errors are silenced, so it seems that changes
are applied but factually, it may have failed.

We should handled refresh tasks for domain zones the way it is handled for the loadbalancing resources: as a separated & explicit resource.

Unable to use soyoustart endpoints

provider "ovh" {
  endpoint = "soyoustart-ca"
}

Terraform Version: 0.13.4
ovh provider version: 0.9.1

Error: soyoustart-ca must be one of map[string]string{"kimsufi-ca":"https://ca.api.kimsufi.com/1.0", "kimsufi-eu":"https://eu.api.kimsufi.com/1.0", "ovh-ca":"https://ca.api.ovh.com/1.0", "ovh-eu":"https://eu.api.ovh.com/1.0", "ovh-us":"https://api.us.ovhcloud.com/1.0", "runabove-ca":"https://api.runabove.com/1.0", "soyoustart-ca":"https://ca.api.soyoustart.com/1.0", "soyoustart-eu":"https://eu.api.soyoustart.com/1.0"} endpoints

id is a reserved field name

looks like domain resource is broken by directly setting a reserved id field

--- FAIL: TestProvider (0.00s)                       
        provider_test.go:29: err: 1 error(s) occurred:                                                    

                * resource ovh_domain_zone_record: id is a reserved field name                            
FAIL                                                 
FAIL    github.com/terraform-providers/terraform-provider-ovh/ovh       0.005s

tested with Terraform v0.11.7

Access Rights and Poor Documentation

Prior using the OVH provider, one need first create an API token IMHO it should be noted where to get the application_key, application_secret and consumer_key

The URL /createToken is hard to find and poorly documented. At lest be a bit kind with dev who now TF but not the specific Cloud Provider procedures.

In addition to that it should also be documented what access rights are needed from this plugin. Right its /* on GET,POST,DELETE. After of hours of trying I couldn't find all the URL and requests.

Btw. There is even an option where you could create a URL with arguments that would prefill the form with the right access rights:

e.g https://api.ovh.com/createToken/?GET=/*&POST=/*&PUT=/*&DELETE=/*

Does not work with Kimsufi-EU (or any other?)

Terraform Version

$ terraform -v
Terraform v0.12.28
+ provider.ovh v0.8.0

Affected Resource(s)

  • ovh_dedicated_server

Terraform Configuration Files

provider "ovh" {
  endpoint = "kimsufi-eu"
}

data "ovh_dedicated_server" "kimsufi" {
  service_name = "my-service-name"
}

Error Message

Error: kimsufi-eu must be one of map[string]string{"kimsufi-ca":"https://ca.api.kimsufi.com/1.0", "kimsufi-eu":"https://eu.api.kimsufi.com/1.0", "ovh-ca":"https://ca.api.ovh.com/1.0", "ovh-eu":"https://eu.api.ovh.com/1.0", "ovh-us":"https://api.us.ovhcloud.com/1.0", "runabove-ca":"https://api.runabove.com/1.0", "soyoustart-ca":"https://ca.api.soyoustart.com/1.0", "soyoustart-eu":"https://eu.api.soyoustart.com/1.0"} endpoints


  on main.tf line 1, in provider "ovh":
   1: provider "ovh" {

Expected Behavior

Should have worked with the specified endpoint configuration.

Actual Behavior

It complains that the endpoint configuration is not correct.

Steps to Reproduce

  1. terraform apply

Important Factoids

Account setup for ovh-cli is properly set up and works.

datasource ovh_cloud_regions now return swfit only regions

tests acc on some resources (eg: network/subnet) use the list of regions returned by
the datasource ovh_cloud_regions

as this datasource now also return region codes for regions which doens't support openstack networking, some acctests break.

We should at least use env var to define on which list of regions networking test acc shall be run
to fix the tests.

Publish a new release ?

Hi,

Is it possible to publish a new release of this provider?
For new collaborators, it's hard to use code instead of simple binary provider :-)

Thank you

Cannot delete subnets created with ovh_cloud_network_private_subnet

Hi,

I'm experiencing an issue regularly when deleting sub-net resources created with ovh_cloud_network_private_subnet: Resource deletion fails with a 500 Internal Server Error. This appears on several regions (tested with UK1 and GRA7). At first, I thought it was an "internal server error" (how clever?) and reach out to the support for issue reporting. However, they've been of no help and gave me this link.

I thought I will report here as you guys may have an idea/workaround/internal patch that may fix this recurring issue, as it forces me to delete the blocked resources (ovh_cloud_network_private being dependent of its sub-nets), and then corrupt my state file.

Terraform Version

Terraform Core: 0.13.2
terraform-provider-openstack: 1.32.0
terraform-provider-ovh: 0.9.1

Affected Resource(s)

Please list the resources as a list, for example:

  • ovh_cloud_network_private_subnet
  • ovh_cloud_network_private (dependency)

Terraform Configuration Files

resource "ovh_cloud_network_private" "global" {
  provider = ovh.ovh
  name = "global_${var.name}" 
  regions = var.regions
  project_id = var.project_id
}

resource "ovh_cloud_network_private_subnet" "public" {
  for_each = var.regions

  network_id = ovh_cloud_network_private.global.id
  project_id = var.project_id
  provider = ovh.ovh
  start = "10.0.4.0"
  end = "10.0.4.254"
  network = "10.0.4.0/24"
  dhcp = true
  region = each.value
}

Debug Output

My complete infrastructure is pretty massive, so I took the liberty to remove traces not related to the issue

----------------------------------------------------------------------------------------------------------------------------------
2020-10-08T07:29:32.480Z [DEBUG] plugin.terraform-provider-openstack_v1.32.0: 2020/10/08 07:29:32 [DEBUG] OpenStack Region is: GRA7
2020-10-08T07:29:32.480Z [DEBUG] plugin.terraform-provider-openstack_v1.32.0: 2020/10/08 07:29:32 [DEBUG] OpenStack Endpoint for compute: https://compute.gra7.cloud.ovh.net/v2.1/[MASKED]/
...
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ REQUEST ]---------------------------------------
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: DELETE /1.0/cloud/project/[MASKED]/network/private/5268d8d8-320e-4913-bedf-84ac67b6ff07/subnet/5268d8d8-320e-4913-bedf-84ac67b6ff07 HTTP/1.1
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Host: eu.api.ovh.com
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: User-Agent: Go-http-client/1.1
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept: application/json
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Application: [MASKED]
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Consumer: [MASKED]
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Signature: $1$32129426213bc149c85069e54392921cf5140346
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Timestamp: 1602142171
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept-Encoding: gzip
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:32.522Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
2020-10-08T07:29:33.303Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 2020/10/08 07:29:33 [DEBUG] OVH API Response Details:
2020-10-08T07:29:33.303Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ RESPONSE ]--------------------------------------
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: HTTP/1.1 500 Internal Server Error
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Connection: close
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Length: 73
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Methods: GET, PUT, DELETE
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Origin: *
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Cache-Control: no-cache, no-store
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Type: application/json; charset=utf-8
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Date: Thu, 08 Oct 2020 07:29:33 GMT
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Server: nginx
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Content-Type-Options: nosniff
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Frame-Options: SAMEORIGIN
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Iplb-Instance: 21900
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Queryid: EU.ext-4.5f7ebfdc.25849.d855b396-adf9-44ae-a7e9-4dc2a7477633
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Tracer: kjRgWjG9qNJe
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Xss-Protection: 1; mode=block
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: {
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "class": "Server::InternalServerError",
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "message": "Internal server error"
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: }
2020-10-08T07:29:33.304Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ RESPONSE ]--------------------------------------
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: HTTP/1.1 500 Internal Server Error
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Connection: close
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Length: 73
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Methods: GET, PUT, DELETE
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Origin: *
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Cache-Control: no-cache, no-store
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Type: application/json; charset=utf-8
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Date: Thu, 08 Oct 2020 07:29:40 GMT
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Server: nginx
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Content-Type-Options: nosniff
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Frame-Options: SAMEORIGIN
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Iplb-Instance: 21901
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Queryid: EU.ext-4.5f7ebfda.25849.eb0f484d-2172-4e3f-9505-9e4230548aad
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Tracer: 7mxyMSMVhgXp
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Xss-Protection: 1; mode=block
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: {
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "class": "Server::InternalServerError",
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "message": "Internal server error"
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: }
2020-10-08T07:29:40.174Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 2020/10/08 07:29:40 [DEBUG] OVH API Response Details:
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ RESPONSE ]--------------------------------------
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: HTTP/1.1 500 Internal Server Error
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Connection: close
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Length: 73
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Methods: GET, PUT, DELETE
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Origin: *
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Cache-Control: no-cache, no-store
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Type: application/json; charset=utf-8
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Date: Thu, 08 Oct 2020 07:29:40 GMT
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Server: nginx
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Content-Type-Options: nosniff
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Frame-Options: SAMEORIGIN
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Iplb-Instance: 21903
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Queryid: EU.ext-3.5f7ebfda.27636.a1c72466-8158-4c85-8e98-b5c93b74c904
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Tracer: CGQVeP7Qdpaq
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Xss-Protection: 1; mode=block
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: {
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "class": "Server::InternalServerError",
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "message": "Internal server error"
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: }
2020-10-08T07:29:40.219Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
2020-10-08T07:29:42.073Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ REQUEST ]---------------------------------------
2020-10-08T07:29:42.073Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: DELETE /1.0/cloud/project/[MASKED]/network/private/8efdd98c-ef12-4d23-abf3-d6b92c6bf61a/subnet/8efdd98c-ef12-4d23-abf3-d6b92c6bf61a HTTP/1.1
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Host: eu.api.ovh.com
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: User-Agent: Go-http-client/1.1
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept: application/json
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Application: [MASKED]
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Consumer: [MASKED]
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Signature: $1$b630891264e1d881b49345a45aca74b14acaef99
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Timestamp: 1602142181
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept-Encoding: gzip
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:42.074Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ REQUEST ]---------------------------------------
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: DELETE /1.0/cloud/project/[MASKED]/network/private/e4d536d7-332e-42e4-a20b-503c8d1c23f3/subnet/e4d536d7-332e-42e4-a20b-503c8d1c23f3 HTTP/1.1
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Host: eu.api.ovh.com
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: User-Agent: Go-http-client/1.1
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept: application/json
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Application: [MASKED]
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Consumer: [MASKED]
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Signature: $1$f6b149ac2635045a97a052e79d8e0111645e8f8d
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Timestamp: 1602142181
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Accept-Encoding: gzip
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:42.079Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:42.080Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ RESPONSE ]--------------------------------------
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: HTTP/1.1 500 Internal Server Error
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Connection: close
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Length: 73
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Methods: GET, PUT, DELETE
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Origin: *
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Cache-Control: no-cache, no-store
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Type: application/json; charset=utf-8
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Date: Thu, 08 Oct 2020 07:29:42 GMT
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Server: nginx
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Content-Type-Options: nosniff
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Frame-Options: SAMEORIGIN
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Iplb-Instance: 21902
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Queryid: EU.ext-5.5f7ebfdc.6804.d04d0d9e-f1de-46ef-a8c2-f2f8d8555908
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Tracer: nTZX4BNZysEB
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Xss-Protection: 1; mode=block
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: {
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "class": "Server::InternalServerError",
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "message": "Internal server error"
2020-10-08T07:29:42.619Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: }
...
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 2020/10/08 07:29:52 [DEBUG] OVH API Response Details:
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: ---[ RESPONSE ]--------------------------------------
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: HTTP/1.1 500 Internal Server Error
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Connection: close
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Length: 73
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Methods: GET, PUT, DELETE
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Access-Control-Allow-Origin: *
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Cache-Control: no-cache, no-store
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Content-Type: application/json; charset=utf-8
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Date: Thu, 08 Oct 2020 07:29:52 GMT
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: Server: nginx
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Content-Type-Options: nosniff
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Frame-Options: SAMEORIGIN
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Iplb-Instance: 21902
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Queryid: EU.ext-1.5f7ebfe6.2712.f3e15c70-c5ca-41ff-8aeb-084ebf2d11e1
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Ovh-Tracer: gXmJeH8WbN66
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: X-Xss-Protection: 1; mode=block
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: 
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: {
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "class": "Server::InternalServerError",
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1:  "message": "Internal server error"
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: }
2020-10-08T07:29:52.177Z [DEBUG] plugin.terraform-provider-ovh_v0.9.1: -----------------------------------------------------
...
Error: calling DELETE /cloud/project/[MASKED]/network/private/7b9f9ddf-5a3e-41a9-a577-e6df76e339f7/subnet/7b9f9ddf-5a3e-41a9-a577-e6df76e339f7:
	 "Error 500: \"Internal server error\""
Error: calling DELETE /cloud/project/[MASKED]/network/private/8efdd98c-ef12-4d23-abf3-d6b92c6bf61a/subnet/8efdd98c-ef12-4d23-abf3-d6b92c6bf61a:
	 "Error 500: \"Internal server error\""
Error: calling DELETE /cloud/project/[MASKED]/network/private/5268d8d8-320e-4913-bedf-84ac67b6ff07/subnet/5268d8d8-320e-4913-bedf-84ac67b6ff07:
	 "Error 500: \"Internal server error\""
Error: calling DELETE /cloud/project/[MASKED]/network/private/ee2a508d-1836-4065-85ee-672f94414d11/subnet/ee2a508d-1836-4065-85ee-672f94414d11:
	 "Error 500: \"Internal server error\""
Error: calling DELETE /cloud/project/[MASKED]/network/private/5573d895-2ab6-4e0e-8dc0-dca28b5f4c07/subnet/5573d895-2ab6-4e0e-8dc0-dca28b5f4c07:
	 "Error 500: \"Internal server error\""

Expected Behavior

Subnets (and then network) get deleted with error.

Actual Behavior

Subnet appears as deleted in Horizon, but the API call fails, and so Terraform abort and cannot retry as the state is corrupted (try to refresh states of a deleted subnet)

Steps to Reproduce

  1. terraform plan -destroy -out plan
  2. terraform apply plan

Important Factoids

Nothing to mention

ovh_cloud_network_private_subnet: missing import support for existing private subnet

Hi,

It seems that ovh_publiccloud_private_network_subnet resource doesn't support importing existing vRack subnet from OVH API.

I've tried using a import command with matching ADDR ovh_publiccloud_private_network_subnet.subnet_GRA3 (see HCL below) and the following internal ID format [PROJECT_ID]/[NET_ID]/[SUBNET_ID]

Terraform Version

Terraform v0.11.14

Affected Resource(s)

  • ovh_publiccloud_private_network_subnet

Terraform Configuration Files

resource "ovh_publiccloud_private_network" "private_net" {
  project_id = "${var.project_id}"
  name       = "${var.network_name}"
  regions    = ["GRA3", "SBG3"]

  # depends_on = ["ovh_vrack_publiccloud_attachment.attach"]
}

resource "ovh_publiccloud_private_network_subnet" "subnet_GRA3" {
  project_id = "${var.project_id}"
  network_id = "${ovh_publiccloud_private_network.private_net.id}"
  region     = "GRA3"
  start      = "10.96.1.2"
  end        = "10.96.1.254"
  network    = "10.0.0.0/8"
  dhcp       = true
  no_gateway = true
}

Expected Behavior

Should import resource into Terraform state (like ovh_cloud_network_private which seems to ork fine)

Actual Behavior

Error: ovh_publiccloud_private_network_subnet.subnet_GRA3 (import id: 579a2f811252455393ec9c0941832e22/pn-1046321_2/776b18fc-60bc-4379-b7bf-0d98410b0444): 1 error occurred:
        * import ovh_publiccloud_private_network_subnet.subnet_GRA3 result: 579a2f811252455393ec9c0941832e22/pn-1046321_2/776b18fc-60bc-4379-b7bf-0d98410b0444: ovh_publiccloud_private_network_subnet.subnet_GRA3: calling /cloud/project//network/private//subnet:
         "Error 404: \"Got an invalid (or empty) URL\""

Steps to Reproduce

TF_LOG=debug terraform import ovh_publiccloud_private_network_subnet.subnet_GRA3 579a2f811252455393ec9c0941832e22/pn-1046321_2/776b18fc-60bc-4379-b7bf-0d98410b0444

ovh_cloud_network_private id vs openstack network id

Terraform Version

Terraform v0.12.1

Affected Resource(s)

Please list the resources as a list, for example:

  • ovh_cloud_network_private # source
  • openstack_networking_port_v2 # affected

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "ovh_vrack_cloudproject" "attach" {

}

data "openstack_networking_network_v2" "public" {
  name = "Ext-Net"
}

# trying to get around the issue, causes more problems
data openstack_networking_network_v2 "k8s" {
  name = ovh_cloud_network_private.k8s.name

  depends_on = [
    ovh_cloud_network_private.k8s
  ]
}
# ISSUE HERE:
resource "ovh_cloud_network_private" "k8s" {
  name = "k8s_network"
  vlan_id = 3

  regions = [
    data.ovh_cloud_region.east_va_1.name
  ]

  depends_on = [
    ovh_vrack_cloudproject.attach
  ]
}

resource "ovh_cloud_network_private_subnet" "cplane" {
  network_id = ovh_cloud_network_private.k8s.id

  region = data.ovh_cloud_region.east_va_1.name

  network = "192.168.1.0/24"
  start = "192.168.1.10"
  end = "192.168.1.15"
  dhcp = false
  no_gateway = false

  depends_on = [
    ovh_cloud_network_private.k8s
  ]
}

resource "openstack_networking_port_v2" "cplane_private" {
  count = 2

  network_id = data.openstack_networking_network_v2.k8s.id

  admin_state_up = true

  fixed_ip {
    subnet_id = ovh_cloud_network_private_subnet.cplane.id
    ip_address = "192.168.1.${(10+count.index)}"
  }

  security_group_ids = [
    openstack_networking_secgroup_v2.k8s_cplane.id
  ]

  depends_on = [
    ovh_cloud_network_private_subnet.cplane
  ]
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

I would like to create core OpenStack resources, but the OVH private network does not provide the underlying OpenStack Network UUID

Actual Behavior

Expected openstack_networking_network_v2 to provide the underlying network uuid to be used with core resources

Steps to Reproduce

  1. terraform apply multiple times you will see the network_ports keeps being recreated because the data.network... is threaded like a different value all the time

Important Factoids

Not many, just trying to get public cloud instances on vRack

References

N/A

panic: interface conversion: error is *json.UnmarshalTypeError, not *ovh.APIError

Terraform Version

Terraform v0.12.16

  • provider.aws v2.39.0
  • provider.helm v0.10.4
  • provider.kubernetes v1.10.0
  • provider.local v1.4.0
  • provider.null v2.1.2
  • provider.ovh v0.5.0
  • provider.random v2.2.1
  • provider.template v2.1.2

Affected Resource(s)

  • ovh_domain_zone_record

Terraform Configuration Files

provider "ovh" {
  endpoint = "ovh-eu"
  application_key = "xxx"
  application_secret = "xxx"
  consumer_key = "xxx"
}

/*
 * Retreive the ovh_domain_zone object for the domain "group-bow.com"
 */
data "ovh_domain_zone" "group-bow" {
  name = "xxx.com"
}

#<<<<<<<<<<
# GRAFANA
#<<<<<<<<<<

/*
 * Retreive the service to get the external IP
 * The externalIP should be the DNS of the auto-generated ELB
 */
data "kubernetes_service" "grafana" {
  metadata {
    name = "prometheus-grafana"
    namespace = "monitoring"
  }
}

/*
 * Creates the CNAME OVH DNS record pointing to the ELB
 */
resource "ovh_domain_zone_record" "grafana" {
  zone = data.ovh_domain_zone.group-bow.name
  subdomain = "xxx.xxx"
  fieldtype = "CNAME"
  ttl = "0"
  target = "${data.kubernetes_service.grafana.load_balancer_ingress.0.hostname}."
}

Debug Output

https://gist.github.com/kerwanp/35cf4fe8beb0113502d1d1500cdc2da9

Panic Output

https://gist.github.com/kerwanp/35cf4fe8beb0113502d1d1500cdc2da9

Expected Behavior

This should plan with the current state.

Actual Behavior

terraform plan will just produce the error :
Error: rpc error: code = Unavailable desc = transport is closing

But terraform plan -target=ovh_domain_zone_record.grafana panic crash with the same error but with explicit log

Steps to Reproduce

  1. terraform apply, terraform plan, terraform destroy

Resource "ovh_domain_zone"

Is it possible to implement "domain_zone" as regular read/write resource with possibility to change "name_servers" and "dnssec_supported" fields ?

Bump version and generate new release

Hi everyone,

After some tests with the OVH provider, I take few minutes to open this issue.
It's not an usual issue opened to implement new feature or debugging some stuff, it's an issue to check with the maintainers of this repository if it's possible to generate a new release of this Terraform provider.

I have spent some time to debug the usage of the ovh_cloud_network_private resource to import some existing objects in my .tfstate file without understanding why it didn't work.

I worked with the following declaration in my pprovider.tf file:

provider "ovh" {
  version = "0.3.0"
  endpoint = "ovh-eu"
}

After discuss with @yanndegat, he advices me to build the provider in my Go environment and to rerun my code. And this was the solution's of all my problem ^^ย 

What is the step to ask properly new release regularly ?
It's possible to implement a workflow to generate automatically new release of this provider ?

Terraform Version

terraform --version
Terraform v0.11.13

Affected Resource(s)

At least, I haven't yet test other resource:

  • ovh_cloud_network_private

Actual Behavior

With the provider based on the 0.3.0 release tag:

import module.import.ovh_cloud_network_private.test1
result: xxxxxxxxx: ovh_cloud_network_private.test1: Error calling /cloud/project/xxxxxxxx/network/private/xxxxxxxxx:
         "Error 404: \"The requested network (id = xxxxxxxxx) does not exist\""

Expected Behavior

With the provider based on the last commit of this code repository:

Import successful!

/thanks for your work :)

Partial web documentation compared to Github sources

I was lookup for information about dns resources of OVH provider.

I found resource_ovh_dns_record.go and its documentation but no link from the official web documentation.

Expected Behavior

Documentation about dns resources on https://www.terraform.io/docs/providers/ovh/index.html

Actual Behavior

Nothing about dns resources on https://www.terraform.io/docs/providers/ovh/index.html

Steps to Reproduce

Go to https://www.terraform.io/docs/providers/ovh/index.html :-)

New release

Hi Everyone,

Would it be possible to create a new tag / release.
I am facing the same issue as #147 (issue fixed now but not part of the last release v0.9.1)
The last release is from August 28. I have compiled the provider and did some tests, everything works properly locally.
However, for CI / CD I use a gitlab runner, it would be easier if a new version was released for my runner to pull it.

Thank you,
Pierre

Enhancement: resource for redirection

I already use OVH provider to manage my domains, that works fine, except redirections are missing.

As I would like to work on this, I would be sure to work in the right direction:

I think I won't be able to execute acceptance tests.

Is it ok for you?

Add ovh_nasha_partition resource

It would be great if we could manage OVH's NAS-HA partitions with Terraform so that we can do something like that:

resource ovh_nasha_partition "foo" {
  service_name = "zpool-123456"
  partition_name = "foo"
  protocol = ["NFS", "CIFS"]
  size = "500"

  access {
    ip_blocks = ["1.2.3.4/32", "4.3.2.1/32"]
    type = "readwrite"
  }

  access {
    ip_blocks = ["5.6.7.8/32"]
    type = "read"
  }
}

missing RedirectLocation on IpLoadbalancingHttpFrontend

Hi,

The provider doesn't offer the option Redirect location on ovh_iploadbalancing_http_frontend ressource.
This option is available with the API ( /ipLoadbalancing/{serviceName}/http/frontend )

Resource:

  • ovh_iploadbalancing_http_frontend

Debug Output

Panic Output

Expected Behavior

Redirect location is provided with the resource

Actual Behavior

This option is not available

New release

Hi,
It would be nice to make a new release to be able to use new resources like ovh_iploadbalancing_refresh and ovh_iploadbalancing_tcp_frontend.

Reflect API path in resource naming

It would seem reasonable to keep names of resources a bit more in line with what can be found in OVH API.
For example, considering the URI in OVH API is
/cloud/project/{serviceName}/network/private/{networkId}/subnet
the resource name for private networks subnet would be
ovh_cloud_network_private_subnet
instead of
ovh_publiccloud_private_network_subnet

I could adapt that keeping previous naming for backward compatibility. It would also provide a clear guideline on how to name new resources.

TF provider fails with unexpected EOF

Hi there,

Unfortunately, I am not able to use the OVH provider as per version 0.2.0.
Docker is up-to-date, Terraform is too and i'm running the official hashicorp/terraform:latest image.

Thanks for your help and work.

Terraform Version

Terraform version: 0.11.2 a6008b8a48a749c7c167453b9cf55ffd572b9a5d

Affected Resource(s)

  • provider ovh
  • resource "ovh_domain_zone_record"

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

provider "ovh" {
	endpoint = "ovh-eu"
	application_key = "xxx"
	application_secret = "xxx"
	consumer_key = "xxx"
}

resource "ovh_domain_zone_record" "test" {
	zone = "mydomain.ovh"
	subdomain = "sub"
	fieldtype = "A"
	ttl = "3600"
	target = "192.168.1.1"
}

Debug Output

https://gist.github.com/wattshout/6dea68809569b7f66d4c519a1b1d3a12

Panic Output

n/a

Expected Behavior

The provider should have been set and the resource should have been checked.

Actual Behavior

Terraform throws back an error "provider.ovh: unexpected EOF"

Steps to Reproduce

  1. terraform plan

Important Factoids

Tried with provider v0.1.1 which works but doesn't handle ovh_domain_zone_record resources apparently.

References

Didn't seem to find any information about this on the internets.

Cannot create dns record of type NS

Hello,

I'm tying to create NS records with terraform using the ovh_domain_zone_record resource but it seems the NS fieldtype is not supported.

Here is an example where I want to delegate a subdomain to route53, and therefore need to add 4 NS entries in OVH.

resource "aws_route53_zone" "external" {
  name = "delegated.mydomain.ovh"
}

resource "ovh_domain_zone_record" "ns_records" {
    count = "${length(aws_route53_zone.external.name_servers)}"
    subdomain = ""
    zone = "delegated.mydomain.ovh"
    fieldtype = "NS"
    ttl = "0"
    target = "${aws_route53_zone.external.name_servers[count.index]}"
}

I got the following errors:

Error: Error applying plan:

4 error(s) occurred:

* module.delegated_subdomain.ovh_domain_zone_record.ns_records[0]: 1 error(s) occurred:

* ovh_domain_zone_record.ns_records.0: Failed to create OVH Record: Error 404: "This service does not exist"
* module.delegated_subdomain.ovh_domain_zone_record.ns_records[2]: 1 error(s) occurred:

* ovh_domain_zone_record.ns_records.2: Failed to create OVH Record: Error 404: "This service does not exist"
* module.delegated_subdomain.ovh_domain_zone_record.ns_records[3]: 1 error(s) occurred:

* ovh_domain_zone_record.ns_records.3: Failed to create OVH Record: Error 404: "This service does not exist"
* module.delegated_subdomain.ovh_domain_zone_record.ns_records[1]: 1 error(s) occurred:

* ovh_domain_zone_record.ns_records.1: Failed to create OVH Record: Error 404: "This service does not exist"

Thank you for your help

OVH vs OpenStack provider

Hello,

I can't find in which case should I use the OVH or the OpenStack provider.

Is there anywhere a note on that ?

For example, I need to create a network. For this, I can use openstack_networking_network_v2 or ovh_cloud_network_private.

Maybe there is a difference between the 2, but it is not clear for me what would it be.

Impossible to create a Swift container with 'history' versioning mode

Hi there,

Terraform does not seem to accept the history versioning mode on a Swift object storage container and I do not know if the issue comes from OVH or the OpenStack provider.

Terraform Version

Terraform v0.15.3
on linux_amd64
+ provider registry.terraform.io/hashicorp/cloudinit v2.2.0
+ provider registry.terraform.io/hashicorp/local v2.1.0
+ provider registry.terraform.io/ovh/ovh v0.13.0
+ provider registry.terraform.io/terraform-provider-openstack/openstack v1.42.0

Affected Resource(s)

  • openstack_objectstorage_container_v1

Terraform Configuration Files

# https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/resources/objectstorage_container_v1.
resource "openstack_objectstorage_container_v1" "terraform_state_files" {
  name   = "terraform-state-files"
  region = var.ovh_region

  versioning {
    # Copy the current version to the archive container then remove it from
    # the versioned container.
    #
    # See https://docs.openstack.org/swift/latest/api/object_versioning.html.
    type     = "history"
    location = openstack_objectstorage_container_v1.versioning.name
  }

  # Default: {}
  metadata = var.metadata
}

# https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/resources/objectstorage_container_v1.
resource "openstack_objectstorage_container_v1" "versioning" {
  name   = "versioning"
  region = var.ovh_region

  # Default: {}
  metadata = var.metadata
}

Debug Output

Given that the debugging trace contains some references to my project that I do not want to share publicly, please find attached a GPG-encrypted version of the output: debug.gpg.log

Panic Output

N/A

Expected Behavior

The object storage container's versioning mode should be set to history.

Actual Behavior

The object storage container's versioning mode remains versions even after terraform apply.

Steps to Reproduce

  1. Run terraform apply to create the object storage containers.
  2. Run terraform plan or terraform apply to see that the versioning mode currently in use is not the one described in the HCL file despite the previous terraform apply:
Terraform will perform the following actions:                                                                                                                                                                      

  # module.tfstate.openstack_objectstorage_container_v1.terraform_state_files will be updated in-place
  ~ resource "openstack_objectstorage_container_v1" "terraform_state_files" {
        id            = "terraform-state-files"
        name          = "terraform-state-files"
        # (3 unchanged attributes hidden)

      + versioning {
          + location = "versioning"
          + type     = "history"
        }
      - versioning {
          - location = "versioning" -> null
          - type     = "versions" -> null
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Important Factoids

N/A

References

I have not found any issue related to this behaviour in the current repository nor in the one of the OpenStack provider.

ovh_cloud_project_kube version not optional

In the docs, it's said we can omit the version parameter, but

resource "ovh_cloud_project_kube" "cluster" {
  service_name = var.ovh_project
  name         = "kube-cluster"
  region       = var.ovh_region
}

gives us an error:

Error: calling Post /cloud/project/341edd7a85dd4fe0b0e2c63dacc09f95/kube with params kube-cluster-dev(GRA7): :
         "Error 400: \"Body parameter version isn't formated correctly\""

The version is passed as "" (empty string)
while (for example)

resource "ovh_cloud_project_kube" "cluster-dev" {
  service_name = var.ovh_project
  name         = "kube-cluster-dev"
  region       = var.ovh_region
  version      = "1.20"
}

seems to work ๐Ÿ‘

The `ovh_cloud_project_kube` resource is always recreated if the version is not specified

According to ovh_cloud_project_kube's documentation, the version argument is optionnal and defaults to the latest available version.

If I do not specify the version argument, the ovh_cloud_project_kube resource is always destroyed and recreated each time I execute terraform apply.

Terraform Version

Terraform v0.14.10
+ provider registry.terraform.io/hashicorp/aws v3.39.0
+ provider registry.terraform.io/ovh/ovh v0.12.0

Affected Resource(s)

  • ovh_cloud_project_kube

Terraform Configuration Files

resource "ovh_cloud_project_kube" "kube_cluster" {
   name         = "mycluster"
   region       = "GRA7"
}

resource "ovh_cloud_project_kube_nodepool" "kube_nodepool" {
   kube_id       = ovh_cloud_project_kube.kube_cluster.id
   name          = "mypool"
   flavor_name   = "b2-7"
   max_nodes     = 1
   min_nodes     = 1
   autoscale     = false
}

Output


$ bin/terraform plan
ovh_cloud_project_kube.kube_cluster: Refreshing state... [id=AAAA-redacted]
ovh_cloud_project_kube_nodepool.kube_nodepool: Refreshing state... [id=BBBB-redacted]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # ovh_cloud_project_kube.kube_cluster must be replaced
-/+ resource "ovh_cloud_project_kube" "kube_cluster" {
      ~ control_plane_is_up_to_date = true -> (known after apply)
      ~ id                          = "AAAA-redacted" -> (known after apply)
      ~ is_up_to_date               = true -> (known after apply)
      ~ kubeconfig                  = (sensitive value)
        name                        = "mycluster"
      ~ next_upgrade_versions       = [] -> (known after apply)
      ~ nodes_url                   = "redacted.nodes.c1.gra7.k8s.ovh.net" -> (known after apply)
      ~ status                      = "READY" -> (known after apply)
      ~ update_policy               = "ALWAYS_UPDATE" -> (known after apply)
      ~ url                         = "redacted.c1.gra7.k8s.ovh.net" -> (known after apply)
      - version                     = "1.20" -> null # forces replacement
        # (2 unchanged attributes hidden)
    }

  # ovh_cloud_project_kube_nodepool.kube_nodepool must be replaced
-/+ resource "ovh_cloud_project_kube_nodepool" "kube_nodepool" {
      ~ available_nodes  = 1 -> (known after apply)
      ~ created_at       = "2021-05-10T15:38:18Z" -> (known after apply)
      ~ current_nodes    = 1 -> (known after apply)
      - desired_nodes    = 1 -> null
      ~ flavor           = "b2-7" -> (known after apply)
      ~ id               = "BBBB-redacted" -> (known after apply)
      ~ kube_id          = "AAAA-redacted" -> (known after apply) # forces replacement
        name             = "mypool"
      ~ project_id       = "redacted" -> (known after apply)
      ~ size_status      = "CAPACITY_OK" -> (known after apply)
      ~ status           = "READY" -> (known after apply)
      ~ up_to_date_nodes = 1 -> (known after apply)
      ~ updated_at       = "2021-05-10T15:42:18Z" -> (known after apply)
        # (7 unchanged attributes hidden)
    }

Expected Behavior

The ovh_cloud_project_kube resource should not be destroyed.

Actual Behavior

The ovh_cloud_project_kube resource is recreated each time I run terraform apply.

Steps to Reproduce

  1. terraform apply
  2. โณ
  3. terraform plan or terraform apply

Refactor code

This is a macro issue and will be split into different issues for each task.

We need to do some refactoring and add some guidelines to keep a tidy code:

  • Split types in types_*.go matching one or two levels of the route on the API, e.g: types_dedicated_server.go, types_me.go, ...
  • Make sure the types are named consistently: ResourceName{} when the same struct is used for all HTTP verbs, ResourceNameCreateOpts{} when used only for POST, ResourceNameCreateUpdateOpts{} for POST and PUT, ...
  • Make sure the functions that interact with the API are all consistently named
  • Revamp the Attributes Reference in all docs to avoid repeating the arguments above
  • Make sure there are importers everywhere needed

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.