Currently the provider only support synchronous service instances provisionning/deprovisonning and binding/unbinding. The specs and Cf support async operations.

Migrated from story

Would prevents binding for succeeding
needs more UX work. E.g. blocking only when a dependency is expressed to the service instance

Happy to send a patch if you'd be open to this.

cf_service_binding resource lacks support for arbitrary params

Nb: arbitrary params are however supported in service bindings managed as part of the cf_app.service_binding resource

This is a split of #38

Missing error checks (found with errcheck), if these are meant to be explicit use _ and possibly comment as to why the error is discarded, and you should definitely log the error so it can be found in trace if desired

Hi,
We have come accross the following problem. In our environment we are using a database service with two service plans:
"v3.0-dev"
"v3.0-dev-small"

When reading the service plans into terraform via

data "cf_service" "sv_database" {
  name = "somedatabase"
}

Then I would expect that data.cf_service.sv_database.service_plans looks like this:

{ 
v3.0-dev = "some guid A"
v3.0-dev-small = "some guid B"
}

However, what is actually parsed (verifiable with the output command) is this:

{   v3 = {
       0-dev = "some guid A"
       0-dev-small = "some guid B" }
}

Which is obviously incorrect. The parser seems to get confused by the "." in the service plan name.

I am using https://github.com/mevansam/terraform-provider-cf/releases/tag/0.9.5 and Terraform 0.11.0

There doesn't appear to be a way to get the shared domain(s) offered by a provider, as the domain datasource requires one to provide a name.

A shared_domains resource might be useful to solve this?

See cf_app documentation

• ports - (Optional, Array of Number) A list of ports which the app will listen on.

Which seems rather implemented in the cf_route.port

Both documentation and attribute metadata in the code should be removed

Assigning 1.0 milestone to avoid backward compatibility post 1.0 release

The current cf_config resource is only containing feature flags and exposes an unnecessary nested structure:

resource "cf_config" "config" {

feature_flags {
user_org_creation = false
private_domain_creation = true
app_bits_upload = true
app_scaling = true
route_creation = true
service_instance_creation = true
diego_docker = false
set_roles_by_username = true
unset_roles_by_username = true
task_creation = true
env_var_visibility = true
space_scoped_private_broker_creation = true
space_developer_env_var_visibility = true
}
}

@mevansam was there other features that you were planning to add into this resource ?

The CF CLI config command includes locale and API timeout, however they fit within the provider attributes as they don't provision remote resources

$ cf config --help
NAME:
config - Write default values to the config

USAGE:
cf config [--async-timeout TIMEOUT_IN_MINUTES] [--trace (true | false | path/to/file)] [--color (true | false)] [--locale (LOCALE | CLEAR)]

OPTIONS:
--async-timeout Timeout for async HTTP requests
--color Enable or disable color
--locale Set default locale. If LOCALE is 'CLEAR', previous locale is deleted.
--trace Trace HTTP requests

This is follow up of #53 to prevent regressions in future PRs

This issue requests the implementation and documentation of the cf_service_instance data source.

Some work from @jcarrothers-sap is already available here: jcarrothers-sap@6273800

This is a split of #38

It seems like the repo package is pulling a release locally, modifying it, and then it will be pushed up to Cloud Foundry as part of the resource_cf_app, is that understanding correct?
[...]
FWIW you may want to try to integrate this using an addition to the GitHub provider, HTTP, or Archive providers so you aren't left having to implement things like this for every possible storage location.

In order to maintain good balance between:

• need to release 1.0 quickly
• need to preserve backward compatibility in the future
• reduce duplication between terraform-provider-cf and other providers: So that other providers can be improved to support CF use cases and relief the terraform-provider-cf from handling these cases.

We plan to mark the current git and github_release attributes as deprecated, so that users can choose not to rely on them to avoid future backward incompatibility. In addition, illustrate how other focused providers can be used to fetch the app binaries. See https://github.com/ArthurHlt/terraform-provider-zipper for a suggestion by @ArthurHlt

• Check support for local CF_app archive using the cf_app.url attribute as the documentation suggests below. Document the archive format (zip, gnu tar.gz). If possible, add test coverage into resource_cf_app_test.go

One of the following arguments must be declared to locate application source or archive to be pushed

• Check cf_app.url attribute specifying a local archive can be indeed combined with the cf_app.add_content attribute. If possible, add test coverage into resource_cf_app_test.go
• Submit issues to HTTP, Archive, github providers to add support needed by terraform-provider-cf
  • https://github.com/terraform-providers/terraform-provider-http : HTTP datasource only supports text/* or application/json content types.
    • It should be able to download any public archive,
    • expose an output attribute providing access to a local path on the file system, and possibly have it ephemeral (i.e. cleaned up upon TF process exit)
    • expose additional attributes to optimize case when attribute is not modified, eg.
      • ETag/Last modified date from HTTP headers
      • Hash of the content (e.g. MD5)
  • GitHub provider does not offer a repository or release datasource that can fetch either a git repo or a github release, be it public or private
• Deprecate git and github_release release attributes, explaining future support for other providers (Git, Github, HTTP)
  • Provide an example in documentation of leveraging an external provider to fetch cf app bits binary.

This is a follow up of #58 to factor out the external bits fetching and documentation between TF provider resources and with other providers

See related buildpack location doc section

See https://travis-ci.org/mevansam/terraform-provider-cf/builds/338978050#L658

@ArthurHlt can you please have a look ?

Hi,

There's a suspicious construction on the following lines:

https://github.com/mevansam/terraform-provider-cf/blob/7e8b22c70aab32a57ec5c668c0dcd7ad857b0a26/cloudfoundry/data_source_cf_domain.go#L58-L64

At first, I thought the lines wanted to exclude the first private domain from the search but according to the following golang snippet, it's not how it works.

Could this be a simple mistake that can be changed to the following ?

domains = append(sharedDomains, privateDomains...) 

Add a resource for CF container-to-container network policy. Migrated from Pivotal tracker story

See related documentation draft removed in #67

This is a split of #38

It seems like the repo package is pulling a release locally, modifying it, and then it will be pushed up to Cloud Foundry as part of the resource_cf_app, is that understanding correct? You should switch to using the ioutil.Temp* methods instead of having the case where it uses the home directory. Also, please make sure to clean up any temp files or directories the provider creates during its execution.

This is a split of #38

• check english spelling errors
• align wording with CF CLI when possible
• check relative resources/datasource URL broken links
  • potentially automatically for incoming PRs, see dkhamsing/awesome_bot
• use proper formatting for hints (apparently ~> see aws_db_instance sources and aws_db_instance rendering
• test the rendering using hashicorp/terraform-website

We have implemented #52 to cover #51 .

The only limitation is that the deprovisioning always happen asynchronously to allow the test of fake-async-plan (async provisioning and sync deprovisioning) from cf-acceptance-tests/service_broker to pass. Therefore the synchronous deprovisioning has been removed here 5f90fbf .

We should probably stick to CLI default (port). Assigning 1.0 milestone to avoid backward incompatibilities after 1.0

$ cf -v
cf version 6.35.2+88a03e995.2018-03-15

$ cf push --help| grep health-check
--health-check-type, -u Application health check type (Default: 'port', 'none' accepted for 'process', 'http' implies endpoint '/')

w.r.t. See https://github.com/mevansam/terraform-provider-cf/blob/master/website/docs/r/app.html.markdown

This is a split of #38

cloudfoundry/import_cf_service_instance_test.go:63:4 - for loop just has a return before looping?
cloudfoundry/provider_test.go:380:3 - the err value is never actually returned
cloudfoundry/resource_cf_app.go:462:3 - I imagine this is just still a work in progress?
cloudfoundry/resource_cf_evg.go:86:2 - err is assigned but not returned?

Updating or deploying a cf_app sometimes yields this error message:

Error: Error applying plan:

1 error(s) occurred:

• module.enterprise_fizzbuzz.cf_app.fizzbuzz_app: 1 error(s) occurred:

• cf_app.fizzbuzz_app: unexpected EOF

We could not create a test to reproduce it, as it seems to be an ugly race condition. @jcarrothers-sap provided a fix and he summarized very well the issue.

The problem is that the schema.ResourceData is not thread safe, even
for concurrent reads, due to internal memoization during reads. The
result was that app creation would sometimes fail mysteriously with an
"unexpected EOF" error due to the provider process crashing due to
either concurrent map writes or read/write.

There is a PR opened for this issue: #87

Dear contributors,

Binding an application to a service instance fails, when the service instance takes a long time to start.
Our service instances (such as postgresql) on our production environment takes approx. 5-7 mins to start. While the service instance is still starting, Terraform tries to bind the application to the service instance and it fails with following output.

2 error(s) occurred:

* module.ca-components.cf_app.a: 1 error(s) occurred:

* cf_app.a: Server error, status code: 409, error code: 60016, message: An operation for service instance db is in progress.
* module.ca-components.cf_app.b: 1 error(s) occurred:

* cf_app.b: Server error, status code: 409, error code: 60016, message: An operation for service instance db is in progress.

When a service instance is created, Terraform assumes that the service instance has been started, while this is not the case as shown previously.

I proposed a solution for this in #41. In this solution we request the CF API for the status of the created service instance. We wait until the service instance is started.

If there are any open questions, please free to ask.

Best,
Samed

The cf_network_policy resource is not implemented, see related documentation draft removed in #67

Terraform detects a plan change in a cf_application resource, uploads it, but fails starting it. It seems like the provider tries to start/restart the application, while it is restaging. After initiating a manual restart, the application successfully starts.

I have already proposed a fix for this in #22.

Logs:

REQUEST: []
POST /v2/apps/a13a7e29-273a-4213-aa05-6b68acafa473/restage HTTP/1.1
Host:
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Connection: close
Content-Type: application/json
User-Agent: go-cli 0.0.0-unknown-version / linux

RESPONSE: []
HTTP/1.1 400 Bad Request
Connection: close
Content-Length: 102
Content-Type: application/json;charset=utf-8
Date:
Server: nginx
X-Content-Type-Options: nosniff
X-Ratelimit-Limit: 80000
X-Ratelimit-Remaining: 79864
X-Ratelimit-Reset: 1513253212
X-Vcap-Request-Id: a2f45160-c72d-4bb9-438a-587d16421fed::a0d99008-b645-4967-8d31-ba6dff8ef47f

{ "description": "App has not finished staging", "error_code": "CF-NotStaged", "code": 170002 }

This is a split of #38

We need to validate that the website is correct and does not include broken links, especially after #85

We would need a documentation preview to be generated by the travis-ci build and published somewhere for manual inspection (e.g. through github pages https://pages.github.com/ )

More details about previewing providers website doc into https://github.com/hashicorp/terraform-website#previewing-changes-from-the-provider-or-core-repositories

This is a follow up of #38

For resource schema, if you have an optional attribute, typically (but not always) you would include a default.

It seems public providers (e.g. Pivotal's public offering) don't allow end users to call /v2/users. As such, the cf_user datasource doesn't work. This means one cannot get the GUID of a user for use in, e.g., cf_space role assignment.

A resource that allows the lookup of a user by name within an organisation might be helpful to solve this?

e.g. org, quota creation need admin role.

Migrated from story

Rename d.service into d.service_instance as to be consistent with r.service_instance

This is a split of #38

Support for terraform import would help TF-CF adoption when existing infrastructure are already created and need to be preserved, and start being managed by TF.

A workaround currently applied is to manually craft the corresponding tfstate file entries, which might be tedious and error prone.

Related tf documentation:

• https://www.terraform.io/docs/import/importability.html
• https://godoc.org/github.com/hashicorp/terraform/helper/schema#ResourceImporter

Importeability would be useful for all resources. We have immediately use cases for the following imports:

• org
• space
• service broker, service access
• domain
• asg

Dear contributors,

the deletion of a service instance having service binding, service keys etc. fails. Terraform outputs that service instances with bindings, service key etc. can not be deleted. In fact after deleting all bindings etc., one is able to delete the service instance.

I investigated and saw that the deletion request to the cf api accepts the parameter recursive, which leads to Will delete service bindings, service keys, and routes associated with the service instance.

I propose that we shall add an additional flag in the resource cf_service_instance, where users can choose between trying to delete the service instance or delete the service instance by deleting all dependencies.

I will create a PR for this issue/feature request asap.

I'd like to hear your opinion about that.

Best,
Samed

The cf_app.route is designed to support blue/green deployment but is not currently implemented.

See https://github.com/mevansam/terraform-provider-cf/blob/master/website/docs/r/app.html.markdown#routing-and-blue-green-deployment-strategy

TO BE IMPLEMENTED

stage_route - (Optional, String) The GUID of the route where the staged application will be available.
live_route - (Optional, String) The GUID of the route where the live application will be available.
validation_script - (Optional, String) The validation script to execute against the stage application before mapping the live route to the staged application.

Related issue is #25

This should be removed from documentation and from resource meta-data as to avoid breaking changes post 1.0 when the support gets implemented (or zero deployment support gets added instead)

As a consequence typing of the cf_app.route can simplified to remove unnecessary nesting

• route - (Optional) Configures how the application will be accessed externally to cloudfoundry.
  • default_route - (Optional, String) The GUID of the default route where the application will be available once deployed.

The current cf_quota resources tries to provision two distinct underlying CF resource types, and have users select among the two types using the org attribute

• Org quota definition /v2/quota_definitions
• Space Quota Definition /v2/space_quota_definitions

• org - (Optional) The Org within which this quota will be defined so it can be applied to spaces within that Org

The actual value of the org parameter is ignored, only its presence/absence seems used in the code:
https://github.com/mevansam/terraform-provider-cf/blob/0dfaf692eb587f5e94a1b44a129bde8f6bb7da67/cloudfoundry/cfapi/quota_manager..go#L85-L96

Since both the CF CLI and the CF CC API manage distinct objects (that may evolve independently), it would make more sense to expose two distinct CF resources. Also, trying to hide both concepts makes documentation wording complex and error prone.

$ cf help -a | grep quota
quotas List available usage quotas
quota Show quota info
set-quota Assign a quota to an org
create-quota Define a new resource quota
delete-quota Delete a quota
update-quota Update an existing resource quota
space-quotas List available space resource quotas
space-quota Show space quota info
create-space-quota Define a new space resource quota
update-space-quota Update an existing space quota
delete-space-quota Delete a space quota definition and unassign the space quota from all spaces
set-space-quota Assign a space quota definition to a space
unset-space-quota Unassign a quota from a space

Marking as 1.0 milestone to avoid backward incompatibilities

Hi,

This is a bit long, please bear with me as I get familiar with this provider and hopefully provide some useful testing feedbck if it works out.

We have our app setup in a dev Bluemix/IBM Cloud env manually using redis, postgres, a CUPS that stores encrypted passwords for the two dbs that the apps read at runtime, auto-scaling and dynatrace. We need to setup a few more envs similar to this (say test, production) and trying to figure out if it makes sense to use this provider. So far I 'm able to connect and print org id, space ids etc. (thanks to answers provided for #29)

This is the high level plan:

1. Use this provider to create various services with pre-determined names (the app's manifest.xml file will use the same names to bind when app is deployed via cf push). In the case of db services find a way to get the user host/port/user id/passwords into Terraform output variables.
2. Run some shell commands from Terraform (https://www.terraform.io/docs/provisioners/local-exec.html ) to:

• (a) update the db host/port/userid in the app's manifest.xml and
• (b) separate curl command store the encrypted database passwords in the CUPS. App will reference them via place holders in manifest.xml and populate them at run time by talking to the CUPS.

Will this work? Don't understand the purpose of cf_app resource in this provider given that the app can be deployed initially and subsequent times via cf push. Is cf_app an alternative way of deploying/re-deploying a CF app but using this provider?

And finally, I 'm not able to figure out how to create a new redis and postgres services. I think I should start with cf_service_instance. On its wiki page a couple of links under the Argument Reference section are broken.

https://github.com/mevansam/terraform-provider-cf/blob/master/website/docs/r/service_instance.html.markdown

Our Service Plans for redis and postgres are Enterprise, for auto scaling its Dedicated and for dynatrace is standard. Can I just hard code them when creating those service instances or do I need to read the redis service first using data and pass the id of the Enterprise service plan by pulling it from service_plans array using something like ${data.cf_service.redis.service_plans["enterprise"]} as shown on the service_instance wiki page linked above?

I first tried with

data "cf_service" "redis" {
  name = "Compose for Redis"
}

but got this error

Error: Error refreshing state: 1 error(s) occurred:

* data.cf_service.redis: 1 error(s) occurred:

* data.cf_service.redis: data.cf_service.redis: Service Compose for Redis not found

We have a service catalog that shows Compose for Redis, Dedicated and Compose for Postgres, Dedicated. How can I get this data statement work as I think this is needed to get service_instance to work.

I tried by supply the string "Dedicated" to the service_plan parameter of the service_instance resource. terraform plan didn't give any error and printed this:

Terraform will perform the following actions:

  + cf_service_instance.redis
      id:           <computed>
      name:         "redis"
      service_plan: "Dedicated"
      space:        "4de30f7a-9c62-4034-89cf-d5a362ba1ebc"

But when I ran terraform apply it gave this error:

* cf_service_instance.redis2: Server error, status code: 400, error code: 60003, message: The service instance is invalid: not a valid service plan

Hello!

My name is Paul, I'm a member of the Terraform team @ HashiCorp.

I’ve taken a look at the provider here and would like to say great work so far! I do have feedback outlined below that I’d like to see addressed before we move on to the next steps. I’m opening this issue as a sort of checklist for tracking remaining items and discussion. The review was done on the git commit c8532f9.

• The provider should be renamed to something less ambiguous than cf (cloudfoundry?) It does seem like the internal package is called cloudfoundry. Maybe this is due to conflicts with the other cloudfoundry provider?
• What is generate-schema? how is it meant to be used? Is that solely for use in intellij? Is it possible to split that out of the repository?
• What is the .test_env folder for?
• For the acceptance testing AWS infrastructure, it would be great if it used Terraform instead of the scripts.
• For imports, I wouldn't re-alias names (ie. terraform as tf) unless you have a conflict, as it will throw off contributors who are used to unaliased ones.
• Review Go’s CodeReviewComments doc. A common thing I see in the code is named result parameters. While functional, naked returns and named results are not the most common go practices and are a little harder to follow.
• Please at least run goimports on the code (many editors can do this automatically, vim-go, vscode, etc.), optionally you could also use golint or even gometalinter to help find additional issues. Passing gometalinter is unnecessary for CI, but it’s a good tool when developing, below is a sampling of other issues I found with the tools.
• Missing error checks (found with errcheck), if these are meant to be explicit use _ and possibly comment as to why the error is discarded, and you should definitely log the error so it can be found in trace if desired:

cloudfoundry/provider_test.go:168:30:	sm.ForceDeleteServiceBroker(serviceBrokerID)
cloudfoundry/resource_cf_app.go:417:16:	am.DeleteApp(app.ID, true)
cloudfoundry/resource_cf_app.go:706:14:	am.DeleteApp(d.Id(), false)
cloudfoundry/resource_cf_route.go:139:18:	rm.DeleteRoute(route.ID)
cloudfoundry/resource_cf_user.go:200:11:	um.Delete(id)

• Some additional issues found with the linters:
• cloudfoundry/import_cf_service_instance_test.go:63:4 - for loop just has a return before looping?
• cloudfoundry/provider_test.go:380:3 - the err value is never actually returned
• cloudfoundry/resource_cf_app.go:462:3 - I imagine this is just still a work in progress?
• cloudfoundry/resource_cf_evg.go:86:2 - err is assigned but not returned?
• Spell check the website docs
• The vendor dir seems to include some unused stuff and the vendor.json seems to be out of sync with it, but I may be missing something, probably worth taking a pass at your dependencies (especially once goimports cleans up your imports) and ensure they are all necessary.
• Are the cfapi and repo packages SDKs? If so, we traditionally keep the SDK’s outside of the provider repos.
• It seems like the repo package is pulling a release locally, modifying it, and then it will be pushed up to Cloud Foundry as part of the resource_cf_app, is that understanding correct? You should switch to using the ioutil.Temp* methods instead of having the case where it uses the home directory. Also, please make sure to clean up any temp files or directories the provider creates during its execution. FWIW you may want to try to integrate this using an addition to the GitHub provider, HTTP, or Archive providers so you aren't left having to implement things like this for every possible storage location.
• For resource schema, if you have an optional attribute, typically (but not always) you would include a default.

I realize this is a lot but I think overall this is in good shape. Some of these issues may be due to misunderstandings of your use cases so feel free to let me know if so, or if there are any other things you'd like an eye on in this issue.

Thanks again!
Paul

See cf_app

• timeout - (Optional, Number) Defines the number of seconds that Cloud Foundry waits for starting your application.

w.r.t. CLI:

cf push --help
[...]
ENVIRONMENT:
CF_STAGING_TIMEOUT=15 Max wait time for buildpack staging, in minutes
CF_STARTUP_TIMEOUT=5 Max wait time for app instance startup, in minutes

Currently, the cf_domain accepts a single org guid:

org - (Optional, String) The GUID of the Org that owns this domain. If provided then this will be a private domain.

We need to share private domains across multiple orgs in the similar to the cf share-private-domain test-org private-domain.example.com CLI commands support, see http://docs.cloudfoundry.org/devguide/deploy-apps/routes-domains.html#private-domains and related PUT /v2/organizations/:guid/private_domains/:private_domain_guid CC API call

Adding a new shared_with_orgs parameter with the following semantic could be a way to address this use-case

shared_with_orgs - (Optional, Array of String) The GUID of the Orgs that are shared the private domain owned by the org specified in the org argument. Errors if the org argument is undefined (i.e. if the domain is a public shared domain).

This is a split of #38 and an iceboxed pivotal tracker story

• Collect pain points and thing about improvement suggestion to CF CLI
• Submit an issue to CF CLI team to have the CLI CLI be more client-friendly and proposal for an official go-lang CF API repo
• Contribute back our code into the official go-lang CF API repo
• Remove cfapi and repo package in favor of contributed official go-lang CF API repo

This is a split of #38

To allow a tfstate to include both https://github.com/mevansam/terraform-provider-cf and https://github.com/orange-cloudfoundry/terraform-provider-cloudfoundry/ , the latter will be renamed to something like legacy_cloudfoundry, see orange-cloudfoundry/terraform-provider-cloudfoundry#33

Hello here,

I was having a look at this project as it would a very interesting addition to our tooling.

I noticed the following problem:

starting with the following user.tf configuration:

resource "cf_user" "test_group" {
	name = "test_group"
	password = "password"
	origin = "uaa"
	given_name = "claudio"
	family_name = "claudio"
	email = "[email protected]"
	groups = []
}

if I run terraform plan:

terraform plan -target=cf_user.test_group
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

  + cf_user.test_group
      email:       "[email protected]"
      family_name: "claudio"
      given_name:  "claudio"
      name:        "test_group"
      origin:      "uaa"
      password:    "<sensitive>"


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

followed by terraform apply:

terraform apply -target=cf_user.test_group
cf_user.test_group: Creating...
  email:       "" => "[email protected]"
  family_name: "" => "claudio"
  given_name:  "" => "claudio"
  name:        "" => "test_group"
  origin:      "" => "uaa"
  password:    "<sensitive>" => "<sensitive>"
cf_user.test_group: Creation complete (ID: 2eff0a1d-181a-4622-91db-eca3f20450d6)

and by another apply:

terraform apply -target=cf_user.test_group
cf_user.test_group: Refreshing state... (ID: 2eff0a1d-181a-4622-91db-eca3f20450d6)
cf_user.test_group: Modifying... (ID: 2eff0a1d-181a-4622-91db-eca3f20450d6)
  groups.#:          "16" => "0"
  groups.1118962009: "actuator.read" => ""
  groups.1249810534: "cloud_controller.user" => ""
  groups.1287305481: "scim.me" => ""
  groups.1552509220: "password.write" => ""
  groups.1606029128: "cloud_controller.read" => ""
  groups.2170006031: "profile" => ""
  groups.2533120156: "user_attributes" => ""
  groups.2687980593: "notification_preferences.write" => ""
  groups.2715234080: "approvals.me" => ""
  groups.3057528519: "roles" => ""
  groups.3121486004: "oauth.approvals" => ""
  groups.31680599:   "openid" => ""
  groups.3185394435: "uaa.user" => ""
  groups.3372606984: "notification_preferences.read" => ""
  groups.3598559816: "cloud_controller.write" => ""
  groups.884407440:  "cloud_controller_service_permissions.read" => ""
Error applying plan:

1 error(s) occurred:

* cf_user.test_group: 1 error(s) occurred:

* cf_user.test_group: Server error, status code: 403, error code: , message: 

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

the last apply fails trying to modify the groups which were not defined in the manifest (unless I set refresh to False)

Is this an expected behaviour?

Thanks!
Claudio

Hi,

To see this issue, here is the example resource I use:

resource "cf_app" "console_app" {
    name = "console"
    url = "https://github.com/orange-cloudfoundry/stratos-ui-cf-packager/releases/download/1.1.0/stratos-ui-packaged.zip"

    space = "${cf_space.ef_production_space.id}"
    route {
        default_route = "${cf_route.console_route.id}"
    }

    memory = 64 # MB
    disk_quota = 192 # MB
    timeout = 300 # seconds
    buildpack = "binary_buildpack"
    health_check_type = "port"

    depends_on = [ "cf_space.ef_production_space", "cf_route.console_route" ]
}

After a terraform apply the temporarily downloaded file is still there:

$ ls -ld /var/folders/j5/4jf9yvsj7w59djp8g__d13_w0000gn/T/*cfapp*
-rw-------  1 benjamin  staff  46699208 29 mai 19:35 /var/folders/j5/4jf9yvsj7w59djp8g__d13_w0000gn/T/cfapp137065753

And when testing it with unzip -t:

$ unzip -t /var/folders/j5/4jf9yvsj7w59djp8g__d13_w0000gn/T/cfapp137065753
Archive:  /var/folders/j5/4jf9yvsj7w59djp8g__d13_w0000gn/T/cfapp137065753
    ...
    testing: stratos-buildpack.yml    OK
    testing: stratos-dbmigrator       OK
    ...
    testing: user-info.so             OK
No errors detected in compressed data of /var/folders/j5/4jf9yvsj7w59djp8g__d13_w0000gn/T/cfapp137065753.

We can see that it's our stratos-ui-packaged.zip indeed.

The problem relies in the prepareApp() function in resource_cf_app.go because this function creates a temporary file and only returns its name. This makes no difference between a local Zip file to keep and a just-downloaded temporary file to delete. Once the prepareApp() function returns, there is no way for the calling code to know whether the file needs to be deleted or not.

This issue is related to designing correct resource ownership in the code. It's always tricky to have a function that creates resources and let the responsibility for the calling code to release those resources.

The fix could be to return a structure that holds both the path to the file and whether it is a temporary file to be deleted when it is uploaded.

Best

@mevansam I wonder background rationale for naming this resource cf_service_access w.r.t. cf_service_plan_access (since it manages access to individual service plan and not access to service definition) ? Maybe something to discuss prior to cutting 1.0 release, and ensure backward compatibility

(extracted from #20 (comment))

The following data sources are missing in order to reach feature parity with terraform-provider-cloudfoundry:

• Config (feature-flags)
• App
• Route
• Service broker
• Service binding

Using code like this:

data "cf_org" "myorg" {
  name = "${var.org_name}"
}

output "org_id" {
  value = "${cf_org.myorg.id}"
}

terraform plan triggers an error on the cf_org.myorg.id line:

Error: output 'org_id': unknown resource 'cf_org.myorg' referenced in variable cf_org.myorg.id

What can be fixed to make this work?

A second question is related to vars that collect passwords like:

variable "password" {
  description = "IBM Cloud Password"
  type = "string"
}

When terraform plan is run, and user is typing the password it shows it in clear text. Is there a type setting that can be used to mask the password with say *****?

To implements blue green deployment, I see for now three different ways:

1. Use v3 api to do blue green deployment as explained here (this will actually leverage the point about getting app id)
2. In Autopilot style, which is a straight forward approach by playing with multiple route attachment (like I did on https://github.com/orange-cloudfoundry/terraform-provider-cloudfoundry)
3. In bluemix style, which is actually prepared on this provider (you can see it here: https://github.com/mevansam/terraform-provider-cf/blob/master/cloudfoundry/resource_cf_app.go#L219-L238 )

I like the first approach and actual v3 api give the ability this kind of thing (see app and droplets resources in the v3 doc but on older versions of cloud foundry this could not be available.

In the third approach, have smoke test script is nice and can be also integrated with first approach.

The second one is, for me, a quick-win: easy to do and already experienced over https://github.com/orange-cloudfoundry/terraform-provider-cloudfoundry but doesn't implement smoke tests.

@mevansam @psycofdj Do you see other strategies ? What will a good approach for you ?

This is a split of #38

• Please at least run goimports on the code (many editors can do this automatically, vim-go, vscode, etc.), optionally you could also use golint or even gometalinter to help find additional issues. Passing gometalinter is unnecessary for CI, but it’s a good tool when developing, below is a sampling of other issues I found with the tools.
• The vendor dir seems to include some unused stuff and the vendor.json seems to be out of sync with it, but I may be missing something, probably worth taking a pass at your dependencies (especially once goimports cleans up your imports) and ensure they are all necessary.

Given the following service key of resource cf_service_key.example:

{
"client_id": "abc",
"client_secret": "fgj",
"plans": [ "someId"],
"resource_id": "someresource"
}

An output statement like

output "cf_service_key_example" {
  value = "${cf_service_key.credentials}"
}

Will result in the following output:

cf_service_key_example = {
 client_id = abc
 client_secret = fgj
 resource_id = someresource
}

The key "plans" is missing. The problem persists when the function "keys" or "jsonencode" is used, the key seems to be dropped when reading the resource.

Extract from the relevant part of the terraform.tfstate file, the "plans" key is missing:

 "cf_service_key.example": {
                    "type": "cf_service_key",
                    "depends_on": [
                        "cf_service_instance.example"
                    ],
                    "primary": {
                        "id": "xyz",
                        "attributes": {
                            "credentials.%": "3",
                            "credentials.client_id": "abc",,
                            "credentials.client_secret": "fqj",
                            "credentials.resource_id": "someresource"
   }

Using terraform 0.11.0 and version 0.9.5 of the terraform provider.

Dear contributors,
`
during deployment on our production environment, we faced the following issue:

1 error(s) occurred:

* module.storage_services.cf_service_instance.mongodb-deploymentapi: 1 error(s) occurred:

* cf_service_instance.mongodb-deploymentapi: Server error, status code: 400, error code: 10001, message: This service plan requires client support for asynchronous service operations. 

While deployment of a mongodb instance using development service plans is successful, the deployment using production-grade service plans fails. This is due to the production-grade service plan, which disallow the usage of synchronous service instance instantiation at the service broker.

The Open Server Broker API offers more information regarding asynchronous and synchronous provisioning docs.

I proposed a solution for this in #52 In this solution we request the CF API for the status of the created service instance with accepts_incomplete=true enabled as proposed in CF API. We wait until the service instance is started.

If there are any open questions, please free to ask.

Best,
Samed