zambien / terraform-provider-apigee Goto Github PK
View Code? Open in Web Editor NEWA Terraform Apigee provider
License: MIT License
A Terraform Apigee provider
License: MIT License
Hi,
I am looking through your provider and see that you are maintaining a fork of the go-apigee-edge go library which you are using in your provider.
What is the purpose of doing this rather than depending directly on the upstream library?
I'm wanting to extend the underlying library to support additional services within ApiGee.
Alternatively, is there something I can do to help merge the two repos so we can depend pool our efforts.
Thanks
[0] github.com/zambien/go-apigee-edge
Terraform is still magical to me even after reading the provider tutorials.
I have tried to implement shared flows here: master...tibers:master
I'm probably pretty close as SharedFlows should act like proxy bundles but when I'm trying to use the existing code I'm getting the following error at compile time:
apigee/resource_shared_flow.go:71:2: SharedFlowRevision declared and not used
apigee/resource_shared_flow.go:98:2: SharedFlowRevision declared and not used
The line is the same, just repeated twice:
SharedFlowRevision, _, err := client.SharedFlows.Import(d.Get("name").(string), d.Get("bundle").(string))
Ideas?
I thought this was related to Issue #28 but I can reproduce it with the example code without my for_each
mess.
Terraform v0.12.13
Apigee provider 0.0.17
...
apigee_api_proxy.helloworld_proxy: Creating...
apigee_developer.helloworld_developer: Creating...
apigee_company.helloworld_company: Creating...
apigee_target_server.helloworld_target_server_testing: Creating...
apigee_company.helloworld_company: Creation complete after 1s [id=7c1dafd2-634b-4a47-9b17-7b1872450d70]
apigee_developer.helloworld_developer: Creation complete after 1s [id=da5244de-0ab6-4e11-be72-a4c01f93291e]
apigee_target_server.helloworld_target_server_testing: Creation complete after 3s [id=afe85c40-4074-430e-8b04-27b8e56f8fba]
Error: [ERROR] resourceApiProxyCreate error importing api_proxy: POST https://api.enterprise.apigee.com/v1/o/<env>/apis?action=import&name=helloworld-terraformed: 400 Bundle is invalid. Empty bundle
on builder.tf line 11, in resource "apigee_api_proxy" "helloworld_proxy":
11: resource "apigee_api_proxy" "helloworld_proxy" {
Just copypaste the example
Expected proxy files to be written to ~/proxy_files
, and an appropriate archive created in ~/proxy_files_bundle
Nothing was created in ~/proxy_files
and so an empty zip file was created in ~/proxy_files_bundle
var.env
instead of testing
)access_key
or whateverterraform apply
Unacceptable!!!
Write some tests.
currently developer apps always show a difference because new creds are generated. This should not happen.
During terraform apply apigee_product resource gets struck indefinitely . If I go to Apigee portal and see the product, it is created successfully. Did anyone see this behavior?
apigee_product.test_api_product: Still creating... [50s elapsed]
apigee_product.test_api_product: Still creating... [1m0s elapsed]
apigee_product.test_api_product: Still creating... [1m10s elapsed]
versions:
Terraform v0.12.24
thank you
Hi,
Is this project still maintained? Doesn't look like a lot of activity goes on. Appreciate any feedback.
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.
hashicorp/terraform:0.12.30
Plugin: terraform-provider-apigee_v0.0.23
Error: Provider produced inconsistent final plan
| When expanding the plan for
| apigee_api_proxy_deployment.payments_proxy_deployment to include new values
| learned so far during apply, provider "registry.terraform.io/-/apigee"
| produced an invalid new value for .revision: was cty.StringVal("3"), but now
| cty.StringVal("4").
| This is a bug in the provider, which should be reported in the provider's own
| issue tracker.
If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
variable "org" { default = "spg" }
#variable "env" { default = "stg" }
variable "apigee_user" { default = "username" }
variable "apigee_password" { type = "string" }
provider "apigee" {
# base_uri = "https://spg.nyt.net" # optional... defaults to Apigee's SaaS
org = var.org
user = var.apigee_user
password = var.apigee_password # Generally speaking, don't put passwords in your tf files... pull from a Vault or something.
}
# This is a normal terraform offering and serves as an example of how you might create a proxy bundle.
data "archive_file" "bundle" {
type = "zip"
source_dir = "${path.module}/proxy_files"
output_path = "${path.module}/proxy_files_bundle/apiproxy.zip"
}
# The API proxy
resource "apigee_api_proxy" "payments_proxy" {
name = "payments" # The proxy name.
bundle = "${data.archive_file.bundle.output_path}" # Apigee APIs require a zip bundle to import a proxy.
bundle_sha = "${data.archive_file.bundle.output_sha}" # The SHA is used to detect changes for plan/apply.
}
# A proxy deployment
resource "apigee_api_proxy_deployment" "payments_proxy_deployment" {
proxy_name = "${apigee_api_proxy.payments_proxy.name}"
# org = var.org
# env = var.env
env = "${terraform.workspace}"
# NOTE: revision = "latest"
# will deploy the latest revision of the api proxy
revision = "${apigee_api_proxy.payments_proxy.revision}"
}
Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.
If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log
.
before deployment on the prod, the revision was 3, i expect the revision 4 to be deployed to prod.
What actually happened?
for this proxy called payments, we did a deployment with few changes in the proxy.
before deployment both staging and production were on version 3,
when staging deployment is done, it has created version 4 and deployed the version.
now when trying to deploy production: the tfstate has version 3, but the stringvalu in the plan is 4, how ever if i rerun the job it deploy production with version 5.
Please list the steps required to reproduce the issue, for example:
for this proxy called payments, we did a deployment with few changes in the proxy.
before deployment both staging and production were on version 3,
when staging deployment is done, it has created version 4 and deployed the version.
now when trying to deploy production: the tfstate has version 3, but the stringvalu in the plan is 4, how ever if i rerun the job it deploy production with version 5.
Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
Hi All,
I'd like to automate the management of API proxies - including giving access to APIs for contracted partners on a managed way. When a new contracted partner comes in an apigee_company
and an apigee-company-app
resource will be created with a terraform script.
After this process, I'd like to save the created API keys and pass that to the contact person. However, currently the implementation does not map the credentials
section back onto the terraform resource, so I cannot output that. This means that after creation I still need to login to the console and copy the API keys from there.
Is there any specific reason for this behavior? Wouldn't it make sense to map back this info as well?
Terraform v0.12.9
Credentials are set in the resource after creation.
Credentials are not available from terraform.
The go-apigee-edge
library supports fetching the credentials, so it's just a question of if we map this info back into the terraform resource.
Hi there,
0.12.12
apigee provider 0.17
Use the examples, but explode a proxy zip into ~/proxy_files
It actually works...
apigee_api_proxy.helloworld_proxy: Creating...
apigee_company.helloworld_company: Creating...
apigee_developer.helloworld_developer: Creating...
apigee_target_server.helloworld_target_server_testing: Creating...
apigee_api_proxy.helloworld_proxy: Creation complete after 1s [id=ad0170dd-3276-4fdd-975a-aea54e6ad83d]
apigee_api_proxy_deployment.helloworld_proxy_deployment: Creating...
apigee_product.helloworld_product: Creating...
apigee_company.helloworld_company: Creation complete after 1s [id=31061393-ce1b-490f-9c7a-14cec04a5e97]
apigee_developer.helloworld_developer: Creation complete after 1s [id=53e169d7-9bd0-411e-8770-ec47ebdb5a76]
apigee_product.helloworld_product: Creation complete after 1s [id=434ba16d-3933-49a1-94bb-8b1881e0d989]
apigee_company_app.helloworld_company_app: Creating...
apigee_developer_app.helloworld_developer_app: Creating...
apigee_target_server.helloworld_target_server_testing: Creation complete after 3s [id=c8aa8590-c2b9-47c9-bb04-b26de8b9f916]
apigee_developer_app.helloworld_developer_app: Creation complete after 1s [id=c1825e45-17a5-435b-9f6f-951a77c3a811]
apigee_company_app.helloworld_company_app: Creation complete after 2s [id=ad649013-01cf-400b-8819-1abebb766ba8]
Error: Provider produced inconsistent result after apply
When applying changes to
apigee_api_proxy_deployment.helloworld_proxy_deployment, provider "apigee"
produced an unexpected new value for was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
do the hello world code, explode a proxy into the ~/proxy_files dir
Note that this is not a new apigee tenancy, this is me trying to bring automation to the existing tenancy.
The latest macosx release reports version 0.0.0 with terraform v0.11.2 and is not enabled giving then the "apigee not found error"
2018/01/31 22:19:20 [WARNING] found legacy provider "terraform-provider-apigee-v0.0.8_x4"
2018/01/31 22:19:20 [DEBUG] found valid plugin: "apigee-v0.0.8_x4", "0.0.0", "~/terraform/terraform.d/plugins/darwin_amd64/terraform-provider-apigee-v0.0.8_x4"
terraform init --plugin-dir=~/terraform/terraform.d/plugins/darwin_amd64
Initializing provider plugins...
Missing required providers.
The following provider constraints are not met by the currently-installed
provider plugins:
* apigee (0.0.8)
Terraform can automatically download and install plugins to meet the given
constraints, but this step was skipped due to the use of -get-plugins=false
and/or -plugin-dir on the command line.
If automatic installation is not possible or desirable in your environment,
you may manually install plugins by downloading a suitable distribution package
and placing the plugin's executable file in one of the directories given in
by -plugin-dir on the command line, or in the following directory if custom
plugin directories are not set:
terraform.d/plugins/darwin_amd64
``
Hi,
We are trying to use this provider to manage a proxy that has different revisions deployed (revisions with different base paths, so we can have v1 and v2 deployed at the same time).
Starting with an empty Proxy in Apigee, if we create the revisions and deployments using this Apigee Provider, it seems to work fine. But as soon as you try to do something on top of that, the provider gets confused with the actual revision of each "apigee_api_proxy_deployment". It does not keep track.
Easiest way to reproduce this:
1- Create two apigee_api_proxy_deployment resources (one with revision 1 and the other one with revision 2) using the provider.
2- Use "terraform refresh" and check how the revision of both apigee_api_proxy_deployment is now revision 2 but nothing has really been changed. They should still have revision 1 and revision 2.
Not sure if #21 will also fix this.
Thanks
currently if a proxy revision is already deployed and an update is made an error will be returned. Instead of erroring the provider should update state.
I am experiencing the following error after an apri proxy deployment. It looks like the proxy deployment completes successfully with all resources being created as expected, but (I suspect) it is an issue with calling "resourceApiProxyDeploymentRead" after the "resourceApiProxyDeploymentCreate" completes. Given the error, I think it has to do with the type associated with the environment in the "resourceApiProxyDeploymentRead".
I think this is also not writing this back to the TF state as well because of the failed call.
0.12.9
apigee_api_proxy_deployment
resource "apigee_api_proxy_deployment" "proxy_deployment" {
depends_on = [
apigee_api_proxy.proxy,
apigee_target_server.target_server
]
proxy_name = apigee_api_proxy.proxy.name
org = lookup(var.apigee_org, var.environment, (lookup(var.apigee_org, "default")))
env = lookup(var.apigee_environments, var.environment, (lookup(var.apigee_environments, "default")))
override = true
revision = local.apigee-revision
}
resourceApiProxyDeploymentUpdate error deploying: json: cannot unmarshal array into Go struct field ProxyRevisionDeployment.environment of type string
on apigee.tf line 82, in resource "apigee_api_proxy_deployment" "proxy_deployment":
82: resource "apigee_api_proxy_deployment" "proxy_deployment"
While the deployment of the api proxy deployment resource completes and the proxy deployment is deployed successfully, it fails with the noted error.
Threw the error above is thrown.
terraform apply
Using provider version 0.0.18
Terraform v0.12.12
+ provider.apigee (unversioned)
+ provider.archive v1.3.0
If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
I rewrote the example just to see if this thing would work at all and... it doesn't.
# This is a normal terraform offering and serves as an example of how you might create a proxy bundle.
data "archive_file" "bundle" {
type = "zip"
source_dir = "${path.module}/proxy_files"
output_path = "${path.module}/proxy_files_bundle/apiproxy.zip"
}
# The API proxy
resource "apigee_api_proxy" "tf_managed_proxy" {
name = "${var.customer_name}-proxy-terraformed" # The proxy name.
bundle = data.archive_file.bundle.output_path # Apigee APIs require a zip bundle to import a proxy.
bundle_sha = data.archive_file.bundle.output_sha # The SHA is used to detect changes for plan/apply.
}
# A product
resource "apigee_product" "tf_managed_product" {
name = "${var.customer_name}-product-terraformed"
approval_type = "auto"
api_resources = ["/**"] # allow base path and all sub paths
proxies = [
apigee_api_proxy.tf_managed_proxy.name
]
quota = var.requests_per_minute
quota_interval = "1"
quota_time_unit = "minute"
# See here: http://docs.apigee.com/api-services/content/working-scopes
scopes = ["READ"]
attributes = {
access = "public" # this one is needed to expose the proxy. The rest of the attributes = are custom attrs. Weird.
# custom1 = "customval1"
# custom2 = "customval2"
}
# environments = ["test"] # Optional. If none are specified all are allowed per Apigee API.
}
# A proxy deployment
resource "apigee_api_proxy_deployment" "tf_managed_proxy_deployment" {
proxy_name = apigee_api_proxy.tf_managed_proxy.name
org = var.org
env = var.env
# NOTE: revision = "latest"
# will deploy the latest revision of the api proxy
revision = apigee_api_proxy.tf_managed_proxy.revision
}
# A target server
# NOTE: If you want to use the import functionality the resource ID must follow {target_server_name}_{environment}
resource "apigee_target_server" "tf_managed_target_server_testing" {
name = "${var.customer_name}-server-terraformed"
host = var.target_server_hostname
env = var.env
enabled = true
port = var.target_server_port
ssl_info {
client_auth_enabled = false
ssl_enabled = true
ignore_validation_errors = false
}
}
# A developer
resource "apigee_developer" "tf_managed_developer" {
email = var.developer_email # required
first_name = var.developer_firstname # required
last_name = var.developer_lastname # required
user_name = var.developer_username # required
attributes = { # optional
DisplayName = "${var.developer_lastname}, ${var.developer_firstname} with ${var.customer_name}"
Notes = "${var.developer_username} - ${var.developer_email}"
}
}
# A developer app
resource "apigee_developer_app" "tf_managed_developer_app" {
name = "${var.customer_name}-developer_app-terraformed" # required
developer_email = apigee_developer.tf_managed_developer.email # developer email must exist
api_products = [apigee_product.tf_managed_product.name] # list must exist
scopes = ["READ"] # scopes must exist in the api_product
callback_url = var.callback_url # optional
key_expires_in = var.key_expires_in # optional
}
# A company
resource "apigee_company" "tf_managed_company" {
name = "${var.customer_name}-company-terraformed" # required
}
# A company app
resource "apigee_company_app" "tf_managed_company_app" {
name = "${var.customer_name}-company_app-terraformed"
company_name = apigee_company.tf_managed_company.name
api_products = [apigee_product.tf_managed_product.name]
scopes = ["READ"]
callback_url = var.callback_url
}
Things should work.
Error: [ERROR] resourceApiProxyCreate error importing api_proxy: invalid character '<' looking for beginning of value
on builder.tf line 10, in resource "apigee_api_proxy" "tf_managed_proxy":
10: resource "apigee_api_proxy" "tf_managed_proxy" {
Note that the char <
never actually occurs in the TF config or the code, which makes me suspect this is some breaking changes in their API.
Please list the steps required to reproduce the issue, for example:
terraform apply
Hi Team,
We are trying to deploy targetServers to Apigee X env using terraform. But im getting the below error.
Status 401: Message: Unauthorized: on target-server.tf line 1, in resource "apigee_target_server" "example": 1: resource "apigee_target_server" "example"
The Service Account that is used for deployment has Apigee org-admin access. But still this issue is occurring. Any insights on the issue?
Hi! Thanks for writing this provider. I noticed importing state is not supported - are there any restrictions that have blocked this being implemented?
In some cases when requests timeout or are closed prematurely the terraform apply will error out.
Add retry logic in order to decrease these errors if on a spotty connection.
Hi there,
I'm working on setting up CI/CD pipeline on Gitlab that uses hasicorp/terraform:light
docker image to execute terraform configurations. In the before_script
my pipeline downloads the official release of apigee provider and extracts that into the ~/.terraform.d/plugins/linux_amd64
directory.
terraform init
succeeds, but terraform plan
results in what you can see below. If I build the provider binary on my mac and use that one in the terraform container it works well.
After looking around I came across this issue which put me in the right direction in my investigations. The key difference between the two builds is that building with goreleaser
on mac results in a statically-linked binary, while the official release built by travis is dynamically linked for linux_amd64
architectures:
~ # file terraform-provider-apigee_v0.0.19.local
terraform-provider-apigee_v0.0.19.local: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=OpakQujwE-isFRYk06PL/6f6v6kbuTUO8EP-DmtMZ/yJe5Sp1_znQHmpRLusLP/9QtMOuLasAU1RcvsFyyc, stripped
~ # file terraform-provider-apigee_v0.0.19.official
terraform-provider-apigee_v0.0.19.official: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=6bnRxkSsmPZdWr2bD-d1/sFbduLa_Q7qT7wnshCay/pOweN8Bat3p0xb-uEWp6/6n2vJaN7B1H_jmylOWYx, stripped
When you cross-compile go, the CGO is disabled and thus, the binary will use static linking. However, travis is on linux_amd64, so when you build a binary for the same architecture CGO will be enabled and the build binary will be dynamically linked. In alpine-based images you don't have all the glibc
libraries, which results in the failure you can see below.
Suggestion:
As the builds for Mac and Windows platforms are statically linked anyway, it would make sense to disable CGO in the goreleaser configuration to build statically-linked binary for linux platform as well. The size of the binary will increase by cca. 1.5MB (23.7 -> 25.2), but this will enable users to use the official builds in official hasicorp/terraform docker images.
Terraform v0.12.15
all
irrelevant
2019-11-14T16:56:17.325Z [DEBUG] plugin: starting plugin: path=/root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19 args=[/root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19]
170 Error: Failed to instantiate provider "apigee" to obtain schema: fork/exec /root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19: no such file or directory
174 ERROR: Job failed: exit code 1
The provider can be started.
The provider cannot be started
Install the official build of apigee provider into an alpine-based docker container and try to use a terraform configuration that uses apigee provider.
Hi There,
Terraform Version
Terraform v0.12.20
apigee provider 0.0.21
Terraform Configuration Files
Use the examples, but explode a proxy zip into ~/proxy_files
Expected Behavior
Create Proxy's,Products,Developers and App's.
Actual Behavior
apigee_developer.helloworld_developer: Refreshing state... [id=dfa05cc1-a607-4a63-bedf-6830b4ee1d94]
data.archive_file.bundle: Refreshing state...
apigee_api_proxy.helloworld_proxy: Refreshing state... [id=fb601905-f48e-47af-bafd-2bd1f24cb327]
apigee_api_proxy.helloworld_proxy: Destroying... [id=fb601905-f48e-47af-bafd-2bd1f24cb327]
apigee_developer.helloworld_developer: Destroying... [id=dfa05cc1-a607-4a63-bedf-6830b4ee1d94]
apigee_api_proxy.helloworld_proxy: Destruction complete after 0s
apigee_developer.helloworld_developer: Destruction complete after 0s
apigee_api_proxy.helloworld_proxy: Creating...
apigee_developer.helloworld_developer: Creating...
apigee_api_proxy.helloworld_proxy: Creation complete after 0s [id=3a57c303-679d-4ae4-b043-bfbc99f47093]
apigee_developer.helloworld_developer: Creation complete after 0s [id=df2209ee-c744-4f5f-b632-fc619c5fb906]
Error: Provider produced inconsistent final plan
When expanding the plan for
apigee_api_proxy_deployment.helloworld_proxy_deployment to include new values
learned so far during apply, provider "apigee" produced an invalid new value
for .proxy_name: was cty.StringVal("helloworld-terraformed"), but now
cty.StringVal("").
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Error: Provider produced inconsistent final plan
When expanding the plan for apigee_product.helloworld_product to include new
values learned so far during apply, provider "apigee" produced an invalid new
value for .proxies[0]: was cty.StringVal("helloworld-terraformed"), but now
cty.StringVal("").
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Steps to Reproduce
Ran the hello world code,added proxies under proxies folder.
In an effort to facilitate blue/green deployments, it would be useful to be able move around vhosts. This also means when we bump into apigee API weirdness (like the whole retries thing) we can enable users to bump into that on the green deployment side, and once it's all happy, we can move the vhost from blue to green.
I started to beat out the TF code here but I am not good at TF or go:
https://github.com/tibers/terraform-provider-apigee
https://github.com/tibers/go-apigee-edge
This currently doesn't compile so no MR. However if anyone wants to steal the code (or point out where I'm doing it wrong) I hope it's useful.
I'm interested in contributing and building out test coverage for the current resources. I noticed when I was running acceptance tests that I was getting a fairly high rate of ephemeral, 401 unauthorized errors, i.e., the DELETE method would fail on one iteration and the GET method (via the Read... method invoked after Create) would fail on the next.
I'm on an evaluation account currently, but appear to be well below the Management API call limit even for that (see attached image):
I'm curious if you've encountered similar issues running acceptance tests and if so how you've worked around them—it does not appear that the 401 error is related to either the Terraform provider or Apigee Edge Go client since I can reproduce it somewhat consistently via a bash script with a series of API requests called by cURL in a loop.
With the upcoming terraform 13, it's possible for any provider to be automatically installed when configured if there's an appropriate registry entry.
This would save the need to manually install the provider.
Hey there - minor feature request:
When creating a product (apigee_product resource) there isn't an option to specify the environments it's for. This leads to a product being created with access to no environments.
I note that DinoChiesa/go-apigee-edge now has 'Environments' included in the product API but your fork doesn't have that yet.
Overall, this is an awesome library - such a good idea standing up Apigee resources via Terraform!
Terraform v0.12.10
Apigee download: terraform-provider-apigee_0.0.16_linux_amd64.tar.gz
On AWS Amazon Linux 2
Please list the resources as a list, for example:
provider "apigee" {
org = "${var.APIGEE_ORG}"
user = "${var.APIGEE_USER}"
password = "${var.APIGEE_PASSWORD}"
}
resource "apigee_company" "helloworld_company" {
name = "helloworld_company"
display_name = "some longer description for company"
attributes {
DisplayName = "my-awesome-company"
}
}
2019/10/09 19:11:45 [TRACE] buildProviderConfig for provider.apigee: using explicit config only
2019/10/09 19:11:45 [TRACE] GRPCProvider: GetSchema
2019/10/09 19:11:45 [TRACE] GRPCProvider: PrepareProviderConfig
Error: Unsupported block type
on main.tf line 11, in resource "apigee_company" "helloworld_company":
11: attributes {
Blocks of type "attributes" are not expected here. Did you mean to define
argument "attributes"? If so, use the equals sign to assign it a value.
2019/10/09 19:11:45 [TRACE] <root>: eval: terraform.EvalNoop
2019/10/09 19:11:45 [TRACE] <root>: eval: terraform.EvalNoop
Successful plan.
What actually happened?
Error as above: Error: Unsupported block type
Please list the steps required to reproduce the issue, for example:
terraform int
terraform plan
Failure is on AWS ECS - Amazon Linux 2
v.0.0.16 Darwin version works on on Mac with Terraform v0.11.8
https://github.com/goreleaser/goreleaser
https://goreleaser.com/
see other terraform plugin usage example:
https://github.com/ewilde/terraform-provider-runscope/blob/master/goreleaser.yml
Bundles may be sourced externally so allow for a URI to be sourced instead of a local zip file.
Hi,
When you query resources from Apigee API the string list properties are not returned in the same order you specify them during creation. If we don't take this into consideration in the resource read operation it might happen that our terraform plan will never be empty.
I'm going to send a PR for this in a few minutes - this should be handled on the same way it happens now with the company resource's api_products attribute.
Terraform v0.12.13
apigee_product
resource "apigee_product" "foo_product" {
...
api_resources = ["/**", "/dummy-resource"]
proxies = ["${apigee_api_proxy.tf_helloworld.name}", "${apigee_api_proxy.tf_helloworld_2.name}", "${apigee_api_proxy.tf_helloworld_3.name}"]
scopes = ["READ", "WRITE"]
environments = ["test", "prod"]
...
}
Don't detect change if the elements of these lists are the same and only the order differs.
When the order of these elements differ from the order specified during creation a change is detected by terraform on the resource, so the plan can never be empty.
terraform apply
terraform plan
0.12.12
apigee 0.17
resourceApiProxyDelete
terraform destroy
should delete all the resources.
Terraform cannot destroy api_proxy
s and will error until they are manually deleted via the UI.
latest
)~/proxy_files
terraform apply
terraform destroy
This will produce an error like:
...
apigee_company_app.helloworld_company_app: Destroying... [id=ad649013-01cf-400b-8819-1abebb766ba8]
apigee_target_server.helloworld_target_server_testing: Destroying... [id=c8aa8590-c2b9-47c9-bb04-b26de8b9f916]
apigee_developer_app.helloworld_developer_app: Destroying... [id=c1825e45-17a5-435b-9f6f-951a77c3a811]
apigee_target_server.helloworld_target_server_testing: Destruction complete after 2s
apigee_developer_app.helloworld_developer_app: Destruction complete after 2s
apigee_developer.helloworld_developer: Destroying... [id=53e169d7-9bd0-411e-8770-ec47ebdb5a76]
apigee_company_app.helloworld_company_app: Destruction complete after 3s
apigee_company.helloworld_company: Destroying... [id=31061393-ce1b-490f-9c7a-14cec04a5e97]
apigee_product.helloworld_product: Destroying... [id=434ba16d-3933-49a1-94bb-8b1881e0d989]
apigee_product.helloworld_product: Destruction complete after 1s
apigee_developer.helloworld_developer: Destruction complete after 2s
apigee_api_proxy.helloworld_proxy: Destroying... [id=ad0170dd-3276-4fdd-975a-aea54e6ad83d]
apigee_company.helloworld_company: Destruction complete after 1s
Error: [ERROR] resourceApiProxyDelete error deleting api_proxy: DELETE https://api.enterprise.apigee.com/v1/o/<org>/apis/joshtest: 400 Can not delete Revision 1 of ApiProxy joshtest in organization <org>. Undeploy the ApiProxy and try again.
Any... recreated on terraform 0.11.1
All resources
If a connection error or some other error comes back from a resource read the state should be retained.
The state is removed. This is because only 404 errors should result in state being removed for the Apigee APIs.
Right now if you rev your proxy bundle then apply your deployment will not update automatically if you reference that proxy rev (as in the example above).
To work around the issue you can apply twice:
terraform apply && terraform apply
Or manually change the revision number in a variable or in the script...
resource "apigee_api_proxy_deployment" "helloworld_proxy_deployment" {
proxy_name = "${apigee_api_proxy.helloworld_proxy.name}"
org = "${var.org}"
env = "${var.env}"
revision = 4 # the known next revision number
}
This is happening due to a known issue in Terraform that should be fixed soon: hashicorp/terraform#15857
Importing an api_proxy doesn't set the bundle and bundle_sha attributes.
This means that if you do e.g. terraform plan immediately after import, then terraform thinks it needs to create them on the imported resource.
when deploying with a no-outage proxy deployment, more than one proxy deployment is returned. This causes an error and the state is not updated. We should handle this more gracefully. We can recreate this issue by setting:
delay = 30
override = true
in a proxy deployment.
Allow an update of a proxy/deployment via an override of the revision. This is similar to what the Apigee UI does when you do a live update to a deployed proxy. This may also be a workaround for #1.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.