Git Product home page Git Product logo

terraform-provider-apigee's Introduction

terraform-provider-apigee

A Terraform Apigee provider.

Allows Terraform deployments and management of Apigee API proxies, deployments, products, companies/developers/apps, and target servers.

https://registry.terraform.io/providers/zambien/apigee/

TFVARS for provider

APIGEE_BASE_URI="https://someinternalapigee.yourdomain.suffix" # optional... defaults to Apigee's SaaS
APIGEE_ORG="my-really-cool-apigee-org-name"

# To authenticate with Apigee you can use user and password
APIGEE_USER="[email protected]"
APIGEE_PASSWORD="for_the_love_of_pete_please_use_a_strong_password"

# Or you can use an Access Token from Apigee OAuth
APIGEE_ACCESS_TOKEN="my-access-token"

Simple Example


# note, to test and build the plugin locally uncomment the lines below or do something like it
# provider_version=0.0.x
# mkdir -p ~/.terraform.d/plugins/local/zambien/apigee/${provider_version}/linux_amd64/
# mv terraform-provider-apigee-v${provider_version}-linux64 ~/.terraform.d/plugins/local/zambien/apigee/${provider_version}/linux_amd64/terraform-provider-apigee_v${provider_version}

terraform {
  required_version = ">= 0.14"

  required_providers {
    apigee = {
      # pull from registry
      source = "zambien/apigee"
      # test locally built plugin
      # source = "local/zambien/apigee"
      version = "~> 0.0.23"
    }
  }
}

variable "org" { default = "my-really-cool-apigee-org-name" }
variable "env" { default = "test" }

provider "apigee" {
  base_uri      = "https://someinternalapigeemanagment.yourdomain.suffix"      # optional... defaults to Apigee's SaaS
  org           = "${var.org}"
  user          = "[email protected]"
  password      = "did_u_pick_a_strong_one?"                # 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" "helloworld_proxy" {
   name  = "helloworld-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" "helloworld_product" {
   name = "helloworld-product"
   display_name = "helloworld-product" # The provider will assume display name is the same as name if you do not set it.
   description = "no one ever fills this out"
   approval_type = "auto"

   api_resources = ["/**"]
   proxies = ["${apigee_api_proxy.helloworld_proxy.name}"]

   # 1000 requests every 2 minutes
   quota = "1000"
   quota_interval = "2"
   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" "helloworld_proxy_deployment" {
   proxy_name   = "${apigee_api_proxy.helloworld_proxy.name}"
   org          = "${var.org}"
   env          = "${var.env}"

   # NOTE: revision = "latest" 
   # will deploy the latest revision of the api proxy 
   revision     = "latest"
   # OR revision = "1" # for specific 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" "helloworld_target_server_testing" {
   name = "helloworld_target_server"
   host = "somehost.thatexists.com"
   env = "testing"
   enabled = true
   port = 8080

   ssl_info {
      ssl_enabled = "false"
      client_auth_enabled = "false"
      key_store = ""
      trust_store = ""
      key_alias = ""
      ignore_validation_errors = false
      ciphers = [""]
      protocols = [""]

   }
}

# A developer
resource "apigee_developer" "helloworld_developer" {
   email = "[email protected]"                                  # required
   first_name = "helloworld"                                            # required
   last_name = "thelloworld1"                                           # required
   user_name = "helloworld1"                                            # required

   attributes = {                                                         # optional
      DisplayName = "my_awesome_app_updated"
      Notes = "notes_for_developer_app_updated"
	  custom_attribute_name = "custom_attribute_value"
   }
}

# A developer app

resource "apigee_developer_app" "helloworld_developer_app" {
   name = "helloworld_developer_app"                                    # required
   developer_email = "${apigee_developer.helloworld_developer.email}"   # developer email must exist
   api_products = ["${apigee_product.helloworld_product.name}"]         # list must exist
   scopes = ["READ"]                                                    # scopes must exist in the api_product
   callback_url = "https://www.google.com"                              # optional
   key_expires_in = 2592000000                                          # optional

   attributes = {                                                         # optional
      DisplayName = "my_awesome_developer_app"
      Notes = "notes_for_awesome_developer_app"
	  custom_attribute_name = "custom_attribute_value"
   }
}

# A company
resource "apigee_company" "helloworld_company" {
   name = "helloworld_company"                                          # required
   display_name = "some longer description for company"                 # optional

   attributes = {                                                         # optional
      DisplayName = "my-awesome-company"
   }
}

# A company app
resource "apigee_company_app" "helloworld_company_app" {
   name = "helloworld_company_app_name"
   company_name = "${apigee_company.helloworld_company.name}"
   api_products = ["${apigee_product.helloworld_product.name}"]
   scopes = ["READ"]
   callback_url = "https://www.google.com"
}

# Create the shared flow bundle pretty much the same way you create the proxy bundle.
data "archive_file" "sharedflow_bundle" {
   type         = "zip"
   source_dir   = "${path.module}/sharedflow_files"
   output_path  = "${path.module}/sharedflow_files_bundle/sharedflow.zip"
}

# The Shared Flow
resource "apigee_shared_flow" "helloworld_shared_flow" {
   name         = "helloworld-sharedflow-terraformed"                         # The shared flow's name.
   bundle       = "${data.archive_file.sharedflow_bundle.output_path}"        # Apigee APIs require a zip bundle to import a shared flow.
   bundle_sha   = "${data.archive_file.sharedflow_bundle.output_sha}"         # The SHA is used to detect changes for plan/apply.
}

# A Shared Flow deployment
resource "apigee_shared_flow_deployment" "helloworld_shared_flow_deployment" {
   shared_flow_name   = "${apigee_shared_flow.helloworld_shared_flow.name}"
   org                = "${var.org}"
   env                = "${var.env}"

   # NOTE: revision = "latest" 
   # will deploy the latest revision of the shared flow 
   revision     = "latest"
   # OR revision = "1" # for specific revision
}

Contributions

Please read our contribution guidelines.

Building

Should be buildable on any terraform version at or higher than 0.9.3. To build you would use the standard go build command. For example for MacOS:

GOOS=darwin GOARCH=amd64 go build -o terraform-provider-apigee-v0.0.X-darwin64

Windows: GOOS=windows GOARCH=amd64 go build -o terraform-provider-apigee-v0.0.X-win64

Linux: GOOS=linux GOARCH=amd64 go build -o terraform-provider-apigee-v0.0.X-linux64

Testing

To run tests, use the following commands. Note that you will need your credentials setup for the tests to run. You can authenticate with your username/password OR an access token from Apigee OAuth.

Set env vars for test using username/password:

APIGEE_ORG="my-really-cool-apigee-org-name"
APIGEE_USER="[email protected]"
APIGEE_PASSWORD="for_the_love_of_pete_please_use_a_strong_password"

Set env vars for test using access token:

APIGEE_ORG="my-really-cool-apigee-org-name"
APIGEE_ACCESS_TOKEN="my-access-token"

From the project root: TF_ACC=1 go test -v ./apigee

To run a single test: TF_ACC=1 go test -v ./apigee -run=TestAccDeveloperApp_Updated

Running in debug mode and capturing debug in a file: rm -f /tmp/testlog.txt && TF_ACC=1 TF_LOG=DEBUG TF_LOG_PATH=/tmp/testlog.txt go test -v ./apigee

Releasing

We use goreleaser to release versions. The steps to release are:

export GITHUB_TOKEN="A_GITHUB_TOKEN_THAT_HAS_CORRECT_ACCESS_ENTITLEMENTS"
git tag -a v0.0.x -m "Some description of the release"
export GPG_FINGERPRINT=[your_GPG_fingerprint]
touch /tmp/temp.txt && gpg --local-user ${GPG_FINGERPRINT}  --armor --detach-sign /tmp/temp.txt
goreleaser # actually create the release

You can read more about goreleaser here:

https://goreleaser.com/

Known issues

  • You will often find the need to run apply twice when updating a proxy. This has to do with how terraform handles state. This plugin will be rewritten to combine proxies and proxy deployments to resolve this issue in the future.

terraform-provider-apigee's People

Contributors

alexouy avatar daniel-ds avatar ftieben avatar jonohill avatar moredhel avatar pako-grape avatar zambien avatar zricethezav 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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-apigee's Issues

Error: [ERROR] resourceTargetServerRead error getting target servers: invalid character '<' looking for beginning of value

Terraform Version

Terraform v0.12.12
+ provider.apigee (unversioned)
+ provider.archive v1.3.0

Affected Resource(s)

  • resourceApiProxyCreate
  • resourceTargetServerCreate
  • resourceDeveloperCreate
  • resourceCompanyCreate

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

Terraform Configuration Files

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
}

Expected Behavior

Things should work.

Actual Behavior

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.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

401 unauthorized error running acceptance tests

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):
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.

Make credentials available on apigee_*_app resources after creation

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 Version

Terraform v0.12.9

Affected Resource(s)

  • apigee_developer_app
  • apigee_company_app

Expected Behavior

Credentials are set in the resource after creation.

Actual Behavior

Credentials are not available from terraform.

Important Factoids

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.

Managing multiple proxy deployments not working?

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

Ability to set a product's environments

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!

Feature Request: Vhosts

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.

Allow override of current revision

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.

Error: [ERROR] resourceApiProxyDelete error deleting api_proxy

Terraform Version

0.12.12
apigee 0.17

Affected Resource(s)

resourceApiProxyDelete

Expected Behavior

terraform destroy should delete all the resources.

Actual Behavior

Terraform cannot destroy api_proxys and will error until they are manually deleted via the UI.

Steps to Reproduce

  1. bring down the hello world code (I changed revision to latest)
  2. seed it with an exploded API zip in ~/proxy_files
  3. terraform apply
  4. validate everything looks good
  5. 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.

Error: Provider produced inconsistent result after apply

Hi there,

Terraform Version

0.12.12
apigee provider 0.17

Terraform Configuration Files

Use the examples, but explode a proxy zip into ~/proxy_files

Expected Behavior

It actually works...

Actual Behavior

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.

Steps to Reproduce

do the hello world code, explode a proxy into the ~/proxy_files dir

Important Factoids

Note that this is not a new apigee tenancy, this is me trying to bring automation to the existing tenancy.

Apigee provider is not working in alpine-based docker containers

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 Version

Terraform v0.12.15

Affected Resource(s)

all

Terraform Configuration Files

irrelevant

Debug Output

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

Expected Behavior

The provider can be started.

Actual Behavior

The provider cannot be started

Steps to Reproduce

Install the official build of apigee provider into an alpine-based docker container and try to use a terraform configuration that uses apigee provider.

Add Retry Logic to Client

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.

proxy deployment-fails-"Provider produced inconsistent final plan"

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

hashicorp/terraform:0.12.30
Plugin: terraform-provider-apigee_v0.0.23

Affected Resource(s)

  • A proxy deployment

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.

Terraform Configuration Files

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}"
}

Debug Output

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.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

before deployment on the prod, the revision was 3, i expect the revision 4 to be deployed to prod.

Actual Behavior

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.

Steps to Reproduce

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.

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • GH-1234

Import not supported?

Hi! Thanks for writing this provider. I noticed importing state is not supported - are there any restrictions that have blocked this being implemented?

Project Status?

Hi,

Is this project still maintained? Doesn't look like a lot of activity goes on. Appreciate any feedback.

no-outage proxy deployment results in error

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.

Unordered proxy names in API products prevent having empty terraform plan

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 Version

Terraform v0.12.13

Affected Resource(s)

apigee_product

Terraform Configuration Files

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"]
   ...
}

Expected Behavior

Don't detect change if the elements of these lists are the same and only the order differs.

Actual Behavior

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.

Steps to Reproduce

  1. Create an apigee_product with multiple proxies
  2. terraform apply
  3. terraform plan
  4. The plan should be empty, but it is not.

Error after creation of apigee_api_proxy_deployment

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.

Terraform Version

0.12.9

Affected Resource(s)

apigee_api_proxy_deployment

Terraform Configuration Files

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
}

Debug Output

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"

Expected Behavior

While the deployment of the api proxy deployment resource completes and the proxy deployment is deployed successfully, it fails with the noted error.

Actual Behavior

Threw the error above is thrown.

Steps to Reproduce

  1. terraform apply

Important Factoids

Using provider version 0.0.18

bundle and bundle_sha not set on api_proxy import

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.

400 Bundle is invalid. Empty bundle

I thought this was related to Issue #28 but I can reproduce it with the example code without my for_each mess.

Terraform Version

Terraform v0.12.13

  • provider.apigee (unversioned)
  • provider.archive v1.3.0

Apigee provider 0.0.17

Affected Resource(s)

  • api_proxy

Error text

...
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" {

Terraform Configuration Files

Just copypaste the example

Expected Behavior

Expected proxy files to be written to ~/proxy_files, and an appropriate archive created in ~/proxy_files_bundle

Actual Behavior

Nothing was created in ~/proxy_files and so an empty zip file was created in ~/proxy_files_bundle

Steps to Reproduce

  1. copypaste example code into a repo (fix the reference to var.env instead of testing)
  2. fill out access_key or whatever
  3. terraform apply

Query regarding dependency github.com/zambien/go-apigee-edge

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

State is removed if error occurs

Terraform Version

Any... recreated on terraform 0.11.1

Affected Resource(s)

All resources

Expected Behavior

If a connection error or some other error comes back from a resource read the state should be retained.

Actual Behavior

The state is removed. This is because only 404 errors should result in state being removed for the Apigee APIs.

Allow URIs for bundle and bundle sha

Bundles may be sourced externally so allow for a URI to be sourced instead of a local zip file.

  • create bundle_uri input
  • create bundle_sha input (optional?)

Feature request: terraform registry.

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.

apigee_product got struck in "Still creating" during terraform apply

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

  • provider.apigee v0.0.22

thank you

the latest macosx release reports version 0.0.0 with terraform v0.11.2

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
``

Unsupported block type in some resources

Terraform Version

Terraform v0.12.10
Apigee download: terraform-provider-apigee_0.0.16_linux_amd64.tar.gz
On AWS Amazon Linux 2

Affected Resource(s)

Please list the resources as a list, for example:

  • apigee_company
  • apigee_developer

Terraform Configuration Files

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"
   }
}

Debug Output

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

Expected Behavior

Successful plan.

Actual Behavior

What actually happened?
Error as above: Error: Unsupported block type

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform int
  2. terraform plan

Important Factoids

Failure is on AWS ECS - Amazon Linux 2
v.0.0.16 Darwin version works on on Mac with Terraform v0.11.8

Feature Request: Add Shared Flows

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?

Provider produced inconsistent final plan - cty.StringVal("")

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.

401 Unauthorized error. When trying to create targetServer using terraform.

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?

Must apply twice if referencing revision of a proxy from a proxy deployment

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

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.